Front page | perl.perl5.porters |
Postings from August 2010
Quoth rurban@x-ray.at (Reini Urban):
> 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.
The test I referred to running under FreeBSD is at
http://groups.google.com/group/comp.lang.perl.misc/msg/9e373f4d1e755456
, and the benchmark in question is at
http://groups.google.com/group/comp.lang.perl.misc/msg/1e3c56e7c7360de3
. The difference between -Dusemymalloc and not is *huge*, for instance
5.8.8, system malloc
1E7 chars + 1E4 x 1E2 chars: 7159.0 ms
5.8.8, mymalloc
1E7 chars + 1E4 x 1E2 chars: 45.3 ms
Now, it's possible that benchmark is faulty, or that perl's allocation
strategy has changed significantly since 5.8.8, but you would need to
give some reason for believing that before blindly asserting that
FreeBSD's malloc is the fastest thing in the world and nothing could
possibly improve its performance.
> Uuh, nobody ever complained about freebsd realloc performance.
> It was always the fastest on the planet and still is.
Not for perl's usage patterns, apparently. This is borne out by the fact
that ports perl has been built with -Dusemymalloc forever.
> > Note thought that I added this remark for discussion about disabling it
> > under -Dusemyalloc:
> >
> > | b) Should the new over-allocation also be used under -Dusemyalloc. �It
> > | � �will provide less benefit there, but also come at a lower cost because
> > | � �the newlen can still fall inside the already allocated bucket size
> > | � �anyways. �I don't have any strong opinion if it should be disabled
> > | � �in this situation or not.
> >
> > But as I stated above, I don't think it will make much of a difference either
> > way for the -Dusemyalloc case, but would love to see some comprehensive
> > benchmarks.
>
> At
> http://groups.google.com/group/comp.lang.perl.misc/browse_thread/thread/b7c9133ff20009f2?pli=1
> were a lot of benchmarks and profiling data.
> He is testing string sizes of 1e5-1e7 byte not just pagesizes, piping
> a typical pdf to perl.
Are you saying this is a bad benchmark, for some reason? If you can
supply a better I'd be happy to run it for you.
Ben
Thread Previous
|
Thread Next