On Fri, 13 Jul 2001, Jie Gao wrote:
> On Thu, 12 Jul 2001, Doug MacEachern wrote:
>
> > pitty perl -V does not report usebincompat5005, if you are trying to build
> > modperl as a dso, Makefile.PL should have warned you:
> >
> > Your current configuration will most likely trigger core dumps,
> > suggestions:
> > *) Do not configure mod_perl as a DSO
> > *) Upgrade your Perl version to 5.6.0 or higher (w/ -Ubincompat5005)
> > *) Configure Perl with -Uusemymalloc (not recommended for performance)
>
> This is different from what I have been hearing for the past few years:
>
> Solaris' malloc is better than perl's.
fyi..
Message-ID: <[EMAIL PROTECTED]>
Date: Wed, 18 Jul 2001 11:40:07 +0100
From: Alan Burlison <[EMAIL PROTECTED]>
To: Doug MacEachern <[EMAIL PROTECTED]>
CC: [EMAIL PROTECTED], Alan Burlison <[EMAIL PROTECTED]>
Subject: Re: solaris malloc
Doug MacEachern wrote:
> seeing mixed reviews with regards to performance, README.solaris says:
> =head2 Malloc Issues with Perl on Solaris.
>
> Starting from Perl 5.7.1 Perl uses the Solaris malloc, since the perl
> malloc breaks when dealing with more than 2GB of memory, and the Solaris
> malloc also seems to be faster.
>
> but this message from alan says:
>
http://www.xray.mpe.mpg.de/mailing-lists/perl5-porters/2001-01/msg00465.html
> "A bit more can be squeezed out if you use the perl malloc"
>
> putting aside the 2GB limit issue, curious if there are any numbers out
> there on solaris malloc vs. perl malloc?
An interesting question. The answer as to which is faster is 'it
depends'.
The answer will depend on:
o Which Solaris version are you using (malloc has been changed more or
less
with every release)
o Is perl built MT or not and if so how many CPUs is it using.
o What is the allocation profile.
And I'm sure I could think of a few other variables as well. Perl
*should*
be better with its own malloc, as it has been written with knowledge of
the
likely allocation behaviour of perl.
As an aside, a paper was presented at this year's Usenix describing the
implementation of the Solaris kernel slab allocator, which is an
arena-based
object-caching allocator. It stores partially constructed objects, so
that
a malloc/free/malloc of the same object doesn't have to totally
de/reinitialise the object every time. A userland port of this allocator
is
also described, along with some performance comparisons of other malloc
implementations. The abstract is at
http://www.usenix.org/event/usenix01/bonwick.html, but you need Usenix
membership to download the paper. If anyone is interested, I'll try and
get
permission to send them a copy. The existing arena allocation in perl5 is
quite similar in intent to the slab allocator, so the paper might be
useful
background reading for the perl6 allocator.
Alan Burlison
