Does anyone have any data on Solaris 10's malloc() performance, esp.
wrt tcmalloc ()?

thanks
-frank

On Thu, 12 Jan 2006 00:30:59 -0800 Frank Cusack <fcusack@fcusack.com> wrote:
> Does anyone have any data on Solaris 10's malloc() performance, esp.
> wrt tcmalloc ()?

Should have been:
tcmalloc (http://goog-perftools.sourceforge.net/doc/tcmalloc.html)

thanks
-frank

Frank Cusack wrote:
> On Thu, 12 Jan 2006 00:30:59 -0800 Frank Cusack <fcusack@fcusack.com> wrote:
> 
>>Does anyone have any data on Solaris 10's malloc() performance, esp.
>>wrt tcmalloc ()?
> 
> 
> Should have been:
> tcmalloc (http://goog-perftools.sourceforge.net/doc/tcmalloc.html)
> 
> thanks
> -frank

I don't know anything about performance tests. But you might be 
interested to know that Solaris has a variety of malloc implementations. 
Take a look at their manpages (malloc, mtmalloc, libumem, watchmalloc, 
bsdmalloc, mapmalloc).
Additionally, Sun Studio delivers libfast, which is a very fast 
implementation of malloc that must be linked staticly, is only available 
for SPARC, and disables the preloading of another malloc implementation.

HTH,
Tom

Frank Cusack <fcusack@fcusack.com> writes:

>Does anyone have any data on Solaris 10's malloc() performance, esp.
>wrt tcmalloc ()?

I'd suggest looking at the other 200 malloc implementations
shipping in Solaris first:

	- libc malloc
	- -lmalloc
	- -lmapmalloc
	- -lbsdmalloc
	- -lmtmalloc
	- -lumem

Especially umem performes really well for threaded applications.
(And measuring against libc's malloc won't tell you much because it
is not the best performing malloc)


Casper
-- 
Expressed in this posting are my opinions.  They are in no way related
to opinions held by my employer, Sun Microsystems.
Statements on Sun products included here are not gospel and may
be fiction rather than truth.

Frank Cusack <fcusack@fcusack.com> writes:

>On Thu, 12 Jan 2006 00:30:59 -0800 Frank Cusack <fcusack@fcusack.com> wrote:
>> Does anyone have any data on Solaris 10's malloc() performance, esp.
>> wrt tcmalloc ()?

>Should have been:
>tcmalloc (http://goog-perftools.sourceforge.net/doc/tcmalloc.html)

I'd benchmark against libumem.

Casper
-- 
Expressed in this posting are my opinions.  They are in no way related
to opinions held by my employer, Sun Microsystems.
Statements on Sun products included here are not gospel and may
be fiction rather than truth.

Casper H.S. Dik <Casper.Dik@sun.com> wrote:
> Frank Cusack <fcusack@fcusack.com> writes:
> 
> >Does anyone have any data on Solaris 10's malloc() performance, esp.
> >wrt tcmalloc ()?
> 
> I'd suggest looking at the other 200 malloc implementations
> shipping in Solaris first:
> 
>         - libc malloc
>         - -lmalloc
>         - -lmapmalloc
>         - -lbsdmalloc
>         - -lmtmalloc
>         - -lumem
> 
> Especially umem performes really well for threaded applications.
> (And measuring against libc's malloc won't tell you much because it
> is not the best performing malloc)

Umem is great but... reallocs in umem are generally slow.

-- 
                                                Robert Milkowski
                                                rmilkowskiASDFDSF@wp-sa.pl
                                                http://milek.blogspot.com

Robert Milkowski <rmilkowski-NO-SPAM@wp-sa.pl> writes:

>> Especially umem performes really well for threaded applications.
>> (And measuring against libc's malloc won't tell you much because it
>> is not the best performing malloc)

>Umem is great but... reallocs in umem are generally slow.

Perhaps worthy of a bug?

Is it because shrinking is slow as well as growing or because it
allocates items which fit perfectly and it always need to allocate
and copy?

Casper
-- 
Expressed in this posting are my opinions.  They are in no way related
to opinions held by my employer, Sun Microsystems.
Statements on Sun products included here are not gospel and may
be fiction rather than truth.

Thomas Maier-Komor <maierkom@lpr.e-technik.no-spam.tu-muenchen.de> wrote:
....
> Additionally, Sun Studio delivers libfast, which is a very fast 
> implementation of malloc that must be linked staticly, is only available 
> for SPARC, and disables the preloading of another malloc implementation.

....and it's NOT thread-safe, and it sacrifices space for speed.
So I'd say it's not a fair comparison - 
if any MT-safe malloc library can beat libfast in speed, I'd be surprised.
-- 
#pragma ident "Seongbae Park, compiler, http://blogs.sun.com/seongbae/"

Frank Cusack wrote:
> On Thu, 12 Jan 2006 00:30:59 -0800 Frank Cusack <fcusack@fcusack.com> wrote:
>> Does anyone have any data on Solaris 10's malloc() performance, esp.
>> wrt tcmalloc ()?
> 
> Should have been:
> tcmalloc (http://goog-perftools.sourceforge.net/doc/tcmalloc.html)

Frank,

It's not clear from their web page ... does tcmalloc even work on 
Solaris (and other POSIX systems)? They imply in a couple of places that 
its generally portable but also compare only with glibc. Do you know?

TIA,
HT

On 12 Jan 2006 09:13:49 GMT Casper H.S. Dik <Casper.Dik@Sun.COM> wrote:
> 	- -lmtmalloc
> 	- -lumem
>
> Especially umem performes really well for threaded applications.

Better than the implied high performance of mtmalloc?  Is the performance
high with malloc(), or do you have to use the umem_* interfaces to get
the improved performance?

thanks
-frank

On Thu, 12 Jan 2006 13:15:45 -0500 Henry Townsend <henry.townsend@not.here> wrote:
> Frank Cusack wrote:
>> On Thu, 12 Jan 2006 00:30:59 -0800 Frank Cusack <fcusack@fcusack.com> wrote:
>>> Does anyone have any data on Solaris 10's malloc() performance, esp.
>>> wrt tcmalloc ()?
>> Should have been:
>> tcmalloc (http://goog-perftools.sourceforge.net/doc/tcmalloc.html)
>
> Frank,
>
> It's not clear from their web page ... does tcmalloc even work on
> Solaris (and other POSIX systems)? They imply in a couple of places
> that its generally portable but also compare only with glibc. Do you
> know?

My guess is that it's portable to Solaris, with the caveat that they
define a page as 4k, so it probably underperforms.  Of course the
documentation could be behind the implementation.

-frank

There are several dimensions to multi-threaded malloc
performance; what's important to your application may
not matter at all to mine.

Libumem's design center is very good scalability across
many physical processors; it's the kernel allocator ported
to user-land.  It's reasonably efficient, but not amazingly
so; it's startup speed is ok but not as good as the libc malloc.

Substantial benefits can be obtained by using libumem's
umem_* interfaces and creating specialized caches for
frequently created and destroyed objects; this is particularly
well suited for use w/ C++.

Choosing a single "best" or "fastest" memory allocated is
like choosing a best or fastest car... some folks want a
WRX, others an M5... - and some of us ride motorcycles :-).

- Bart


- Bart

Frank Cusack <fcusack@fcusack.com> writes:

>On 12 Jan 2006 09:13:49 GMT Casper H.S. Dik <Casper.Dik@Sun.COM> wrote:
>> 	- -lmtmalloc
>> 	- -lumem
>>
>> Especially umem performes really well for threaded applications.

>Better than the implied high performance of mtmalloc?  Is the performance
>high with malloc(), or do you have to use the umem_* interfaces to get
>the improved performance?

The performance with the ordinary -lumem interfaces is quite good but the
special purpose functions give better performance because they
cut out some overhead.

Casper
-- 
Expressed in this posting are my opinions.  They are in no way related
to opinions held by my employer, Sun Microsystems.
Statements on Sun products included here are not gospel and may
be fiction rather than truth.