develooper Front page | perl.perl5.porters | Postings from August 2010

Re: Patch to make string-append on win32 100 times faster

Thread Previous | Thread Next
From:
Reini Urban
Date:
August 17, 2010 02:19
Subject:
Re: Patch to make string-append on win32 100 times faster
Message ID:
AANLkTin++avyjxko0U8NSruo-_gMjDkw2OQ4v1mP_HL_@mail.gmail.com
2010/8/16 Jan Dubois <jand@activestate.com>:
> On Mon, 16 Aug 2010, Reini Urban wrote:
>> 2010/8/16 Jan Dubois <jand@activestate.com>:
>> > Could you provide some evidence for this claim?  The only way a
>> > "better malloc" can prevent this slowdown is by doing some kind
>> > of overallocation itself.  Since the algorithm in this patch
>> > is not necessarily cumulative with the overallocation by malloc()
>> > it is very well possible that the change has no effect at all
>> > on systems with a overallocating malloc().
>>
>> This is just theory. I KNOW that plain gnumalloc and freebsd realloc
>> do work fine.
>> But now that we have the mess someone can test it. I don't have such systems
>> so I cannot test it.
>
> I'm getting a bit tired of you discarding Ben's actual test based on
> some "knowledge" you imply to have that you can't even verify because
> you don't have access to those systems.  This is a technical issue, not
> a religious belief!

I just studied the technical papers which discuss different system mallocs.

>> > Because then it wouldn't be applied to other platforms, like FreeBSD.
>>
>> Uuh, nobody ever complained about freebsd realloc performance.
>> It was always the fastest on the planet and still is.
>
> I pointed out *twice* to you that Ben did actually measure it and came up
> with pretty bad numbers for the freebsd reallocator.  You will need to come
> up with some evidence why his benchmarks should be discarded.

Sorry Jan and Ben. So I seem to have misread that thread.
I'm satisfied with Wolfram's patch.

> To provide similar numbers for Linux and GNU malloc I've compiled bleadperl
> just before and after the patch in question, both with usemymalloc=y
> and usemymalloc=n.  The results are just for the "1E7 chars + 1E5 x 1E1 chars"
> benchmark, as that is the slowest of the bunch.  I've run the benchmark
> script 100 times for each Perl build and show the min/max runtimes to show
> that there is quite a bit of noise:
>
> Before, GNU malloc:  Min=38.6 Max=45.4 Avg=41.20
> Before, Perl malloc: Min= 7.9 Max=14.2 Avg=11.14
>
> After, GNU malloc:   Min= 9.7 Max=12.7 Avg=11.45
> After, Perl malloc:  Min= 9.4 Max=13.2 Avg=11.16
>
> It shows that GNU malloc on its own takes 4 times as long as GNU malloc with
> the patch.  GNU malloc with this patch matches the time used by the Perl
> malloc (usemymalloc=y), which doesn't seem to be affected by the patch.

> You seem to have Cygwin available to you.  Why don't you just test the
> patch and report on any actual problems instead of spreading bad attitude?

Because I have other problems with blead right now.
Somehow my markstack is corrupted, so I get crashes in the simpliest
dynaloader boot_ calls.

Sorry for my bad attitude. I thought there were no benchmarks for this
patch on the general platforms.
-- 
Reini Urban

Thread Previous | Thread Next


nntp.perl.org: Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at ask@perl.org | Group listing | About