
One malloc to rule them all - parenthesis
http://blog.reverberate.org/2009/02/20/one-malloc-to-rule-them-all/
======
ComputerGuru
I'm looking at nedmalloc atm
(<http://www.nedprod.com/programs/portable/nedmalloc/>) and I'm really
impressed by what I'm seeing there.

Has anyone here had the opportunity to test nedmalloc in real life? What sort
of performance benefits did you see? Any problems you ran into?

I'm currently designing embedded systems in C, and am looking to get the most
performance out of strained resources as possible...

I'm wondering if this'll compile for AVR or not.....

------
scott_s
The title is inaccurate. It's a memory allocator specifically design for real-
time systems. This is an important and difficult problem, but it in no way
makes it an allocator "to rule them all." In particular, I'm thinking about
multithreaded allocation, which I think will become increasingly important.

Academic papers: <http://rtportal.upv.es/rtmalloc/node/71>

~~~
haberman
nkurz is right about the intention of the title, but if TLSF is only intended
for real-time systems, then why does it claim that it is general-purpose, and
not include any caveats of the sort you do? Like all memory allocators I've
encountered, none of them say "if you're doing X, you're probably better off
using a different allocator." The closest it comes to a caveat is:

> Although TLSF works rather well in many scenarios, it stands out in
> applications with hard/soft real-time application which uses explicit memory
> allocation with high flexibility requirements due to a high variability of
> the data size or adaptability to new situations.

Or paraphrased: "TLSF is great, but is _especially_ great when..."

~~~
scott_s
It was designed for real time systems, and evaluated in the context of real
time systems. (Check out the academic papers.) "General purpose" just means it
implements the malloc/free interface, and can be used in place of the standard
on your system.

In the case that most people care about, I think something like TCMalloc
(<http://goog-perftools.sourceforge.net/doc/tcmalloc.html>) is more
appropriate.

------
alexgartrell
Two TA tricks to make people not use malloc: 1) Have them write it 2) Force
them to check the return value of all system calls.

Static arrays aplenty will arise

Also) punish them for excessively large static arrays

------
liuliu
In my experience, the DSA took extensive use of x86 instruction ffs/fls which
is fairly slow in several CPU chips (slower than maintain a free-list).

------
vicaya
It's impossible. Baiting titles are annoying.

~~~
aminuit
This article will make you dumber. At least he linked to the jemalloc
whitepaper, which he clearly didn't read.

[http://people.freebsd.org/%7Ejasone/jemalloc/bsdcan2006/jema...](http://people.freebsd.org/%7Ejasone/jemalloc/bsdcan2006/jemalloc.pdf)

I especially like the part near the end of the post where it says, "It could
be that different implementations excel in different scenarios" as if that
wasn't completely obvious for anyone who has thought for more than a few
minutes about a malloc implementation.

~~~
haberman
Article author here -- apologies for making you dumber. I would love to hear
any data you have about when I should choose one malloc() implementation over
another; the theory that malloc implementations have trade-offs is basic
enough, but I've never come across a memory allocator that says "here are
situations where you _shouldn't_ use this allocator, and should use allocator
Y instead."

And since the malloc() that ships with any given libc is going to be used by
100% of applications that do not explicitly override malloc (and I have never
come across an application that does), understanding which is the best all-
around allocator seems like quite the worthwhile exercise.

I also don't necessarily buy the jemalloc paper's assertion that allocators
cannot be benchmarked in isolation. It's true that you can't measure the
effects that locality will have on the rest of the application, but you surely
can measure locality of allocations.

~~~
vicaya
General purpose malloc/free cannot "rule" in all situations due to its limited
interface hence any particular understanding of resource management
constraints. It's obvious that no malloc/free package can possibly outperform
an arena scheme when it makes sense.

