Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

All About Libpas, Phil's Super Fast Malloc

github.com

Post reply on HN
Print view View original

71–80 of 87 posts

Re: All About Libpas, Phil's Super Fast Malloc

#71

Post by pizlonator »

akrymski wrote: post #69
pizlonator wrote: post #65

Earlier quoted context omitted.

I think that desktop browser users expect that their tabs generally won't get reloaded. On mobile, users have generally accepted that their tabs will get reloaded. Maybe browsers should just reload tabs if anything fishy happens or you're not using them. Hibernating tabs to disk is hard because the JS heap (and the DOM heap) will contain lots of stuff that is tied to handles you got from the OS. It's not impossible.…

> I think that desktop browser users expect that their tabs generally won't get reloaded But they do get reloaded. There's absolutely no guarantee provided, and browser tabs will get swapped out of memory as necessary (eg opening lots of new tabs or apps). This is easily solvable though: let me pin tabs that I really need to persist.

Sure they do, but much less aggressively than mobile browsers. I think that desktop Safari will try to keep your tab live so long as nothing fishy happens. Based on my experiences using Chrome, it seems to do the same thing.

Re: All About Libpas, Phil's Super Fast Malloc

#72

Post by pcwalton »

pizlonator wrote: post #39
IshKebab wrote: post #29

Earlier quoted context omitted.

For other people who have never heard of bmalloc - it's a custom allocator used only by WebKit. I guess it's not surprising they added one since the Mac system allocator is extremely slow. A custom allocator is pretty much a free 20% speed up on Mac (depending on your workload) but I found they made no difference on Linux. Haven't tried on Windows.

Just some credit where credit is due. I measured the system malloc crushing all other mallocs on some workloads and they were the kind of workloads that some folks run every day. I measured the system malloc crushing most other mallocs on memory efficiency on most workloads. System malloc is really good at reusing memory and has very mature decommit policies that easily rival what I came up with. So there’s that.

macOS malloc was incredibly slow for Pathfinder, far behind every other OS. Everything became bottlenecked on it. It was a free 2x speedup if not more to switch to jemalloc.

I suspect this is because Pathfinder's CPU portion is a multicore workload and macOS allocator performs poorly when under heavy multithreaded contention. It probably just isn't the kind of workload that macOS allocator was tuned for.

Re: All About Libpas, Phil's Super Fast Malloc

#73

Post by pizlonator »

pcwalton wrote: post #72
pizlonator wrote: post #39

Earlier quoted context omitted.

Just some credit where credit is due. I measured the system malloc crushing all other mallocs on some workloads and they were the kind of workloads that some folks run every day. I measured the system malloc crushing most other mallocs on memory efficiency on most workloads. System malloc is really good at reusing memory and has very mature decommit policies that easily rival what I came up with. So there’s that.

macOS malloc was incredibly slow for Pathfinder, far behind every other OS. Everything became bottlenecked on it. It was a free 2x speedup if not more to switch to jemalloc. I suspect this is because Pathfinder's CPU portion is a multicore workload and macOS allocator performs poorly when under heavy multithreaded contention. It probably just isn't the kind of workload that macOS allocator was tuned for.

My understanding is that the system malloc is excellent under contention, but has a high baseline cost for every malloc/free call.

I don't remember exactly what workloads it performed really great at (and if I did I dunno if I could say), but I do remember they were parallel, and the speed-ups got bigger the more cores you added.

Everything else about your experience matches mine. Libpas is much faster than system malloc in WebKit and JSC. The difference isn't 2x on my preferred benchmarks (which are large and do lots of things that don't rely on malloc), but it is easily more than 2x on smaller benchmarks. So your 2x result sounds about right.

Re: All About Libpas, Phil's Super Fast Malloc

#74

Post by fmajid »

adamnemecek wrote: post #7

I'm always suspicious of things that are named after the maker.

Did you know the entire US Air Traffic Control system runs on long-discontinued computers and written in JOVIAL, "Jules' Own Version of the International Algebraic Language" (i.e. ALGOL), named after Jules Schwartz?

https://en.wikipedia.org/wiki/JOVIAL

The FAA's been trying to replce it for ages, but AFAIK it's still ongoing.

Re: All About Libpas, Phil's Super Fast Malloc

#75

Post by thesz »

dragontamer wrote: post #44
latenightcoding wrote: post #32

Earlier quoted context omitted.

I've seen a few opensource projects archive their custom allocators because they were not beating the system's one or jemalloc. So if you have the skill and time then yeah go for it, else stick with general purpose ones.

Its very easy to beat the general purpose ones if you know your exact use case. Ex: 16-bit pointers is a 65536-sized heap. Assume 8-bytes per element, that's 512KB of space. A bit small, but large enough to so a lot of things. 65536 elements can be represented as a bitmask. The bitmask only takes up 8192-bytes (8KB), which fits inside of 16 AVX512 registers (Intel offers 32x AVX512/ZMM registers btw). Or it fits insi…

512 in AVX512 is the number of bits per register. You are off by factor of 8.

Re: All About Libpas, Phil's Super Fast Malloc

#77

Post by xenadu02 »

pizlonator wrote: post #19
dragontamer wrote: post #16

General purpose memory-allocation is a lie. Everything has use cases where they're faster than other libraries. I think that's why we keep seeing newer malloc schemes pop up, because the performance of the heap 100% depends on the use-case, and different people have different use cases. Still, studying everyone else's heaps (and garbage collectors, a closely related discussion) is probably good for high-performance p…

Yeah, you're totally right. Libpas beats other mallocs in WebKit. I also had benchmarks involving non-WebKit workloads and the results were all over the place (sometimes slower than other mallocs by a lot, sometimes faster by a lot - same thing with memory, sometimes more efficient, sometimes less). This didn't surprise me; I've seen this before when writing memory management code. I think it makes sense for large so…

We should have libmetamalloc that tracks a history of program invocations using the actual workload on the actual machine. Cycle through different malloc implementations for each execve(). After gathering enough statistical data select the optimal implementation. The next step would be a basic ML model that looked at a few variables like time of day, args, etc to determine when to switch allocators.

If an OS used such a thing by default it would figure out that it should use libpas on the programs that were faster in your tests. Since most programs have zero effort put into optimizing allocators (or much of anything else) it would likely be a win even given the complexity. Many things are branch predictors if you squint!

Note: Not even I can tell if I'm joking or serious with this comment.

Re: All About Libpas, Phil's Super Fast Malloc

#78

Post by djmips »

asveikau wrote: post #57
djmips wrote: post #50

Earlier quoted context omitted.

Premature optimization is not bad form when it's re-framed as good architecture. So it's not 'usually bad form' to architect something from the outset, using your experience, and that's something everyone understands. This pervasive disdain for premature optimization leads to bad architecture that often leads to expensive rewrites. So because the word optimization is so overloaded and treated with disdain it feels li…

That's one reason I point out a few comments above that certain niches will need to take it into account ahead of time. Eg. An a/v application will typically allocate all buffers up front and re-use them frequently rather than return them to the allocator. A lot of server applications will want to keep per-client memory usage low. For general purposes, there's the general purpose allocator.

Very true. Also video games, and particularly rendering.

Re: All About Libpas, Phil's Super Fast Malloc

#79

Post by irogers »

pizlonator wrote: post #51
ryanianian wrote: post #46

Are there any projects that surgically augment the memory APIs to be more cooperative? Sure `malloc` implementations will make various tradeoffs, but what if the malloc/free APIs were expanded to expose more programmer-intent or cooperative defrag, etc? - Perhaps `malloc` could ask for an intended lifecycle (think GC generation) that could swap arenas or other algo internals. This opens us up to meta-allocators. - Pe…

I've thought about this a lot. I think that overall, malloc/free/new/delete are already so hard to use that if you added more stuff, it would create too much cognitive load for the programmer. The result would be that the hints the programmer gave you would be more wrong than the malloc's best guess. Let me go through these point by point and offer some thoughts. - Perhaps `malloc` could ask for an intended lifecycle…

Not having cognitive load motivates something like the LLAMA work: https://research.google/pubs/pub49008/
Post reply on HN