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

61–70 of 87 posts

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

#61

Post by bool3max »

tialaramex wrote: post #30
thrtythreeforty wrote: post #12

Earlier quoted context omitted.

Like Linux, or gcc.godbolt.org? I kid, but I don't see it as a downside for software. Naming a scientific phenomenon after yourself is a red flag though, see also the Crackpot Index [1]. [1]: https://math.ucr.edu/home/baez/crackpot.html

Godbolt says Compiler Explorer right there, the fact people call it "Godbolt" is because that's the memorable name rather than because Matt Godbolt tried to name it after himself. He calls it Compiler Explorer. You can't control what people call things. My favourite example is Blackfriars Bridge in London. When that bridge was built, it was formally named after William Pitt. But like, who cares? In what way is this b…

People call it Godbolt because you access it via godbolt.org,

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

#62

Post by jstimpfle »

mananaysiempre wrote: post #53
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.

There are a couple of approaches that might legitimately be simpler than using a general-purpose allocator: in a single-pass batch process, just throw things on the floor and let the OS sort it out on exit[1] (I think the D compiler does this); in a multiple-pass batch process, make each pass litter its own room (arena, obstack, etc.) then demolish said room when done (GCC does this or at least did in the past). On t…

This "[2] vs [3]" is a good find. I have several possible explanations. It could be the difference of 7 years between those posts. It could also be that Windows Handles can't be cleaned up in userspace. Not how malloc chunks up the "handles" (i.e. pages / regions) that it got from Windows. This is, AFAIK, different than HANDLE's that have to be requested from the system one-by-one and can't be chunked up. (Or am I wrong? I actually don't know a lot about how this works under the hood).

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

#63

Post by akrymski »

Now if only I could limit the amount of memory a browser would consume! The fact that desktop browsers grind a 16GB machine to a halt, while on mobile devices having 1000s of tabs is a non-issue is plain wrong. Since I can't limit a process' memory on Mac OS (any OS?), why not give me a setting in preferences to do so? After all the browser is really just a VM at this stage. I'm quite certain I don't need 100 tabs in active memory at once.

While at it, why can't we hibernate tabs? Write the JSC heap and DOM state to disk, the way VMs do it?

What's taking up the majority of my memory anyway - the graphics / gpu side or the JS VM?

There's a whole spectrum of startups trying to solve the webkit memory consumption issues crudely, such as https://www.mightyapp.com

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

#64

Post by IshKebab »

KerrAvon wrote: post #49
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.

What's the workload where you found that to be the case? The system allocator is heavily tuned for general use, and should be very difficult to beat -- generally.

It was a non-traditional compiler written in C++.

> The system allocator is heavily tuned

Perhaps but it probably has more constraints than a custom allocator too, e.g. backwards compatibility with software that unwittingly depends on its exact behaviour.

I found a discussion of this where people reported various speedups (10%, 100%, 300%) on Mac by switching to a custom allocator: https://news.ycombinator.com/item?id=29068828

I'm sure there are better benchmarks if you Google it.

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

#65

Post by pizlonator »

akrymski wrote: post #63

Now if only I could limit the amount of memory a browser would consume! The fact that desktop browsers grind a 16GB machine to a halt, while on mobile devices having 1000s of tabs is a non-issue is plain wrong. Since I can't limit a process' memory on Mac OS (any OS?), why not give me a setting in preferences to do so? After all the browser is really just a VM at this stage. I'm quite certain I don't need 100 tabs in…

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. But it would require a lot of work to build specialized serialization functions for stuff that has native state attached to it that the browser doesn't control or have good visibility into.

I think that some websites use a lot of graphics memory while other websites use a lot of JS memory. And there are other categories of memory usage, too.

Maybe if they put the cloud browsers on the blockchain using machine learning, and then write them in Rust and compile them to wasm, then it will be even better.

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

#66

Post by tptacek »

akrymski wrote: post #63

Now if only I could limit the amount of memory a browser would consume! The fact that desktop browsers grind a 16GB machine to a halt, while on mobile devices having 1000s of tabs is a non-issue is plain wrong. Since I can't limit a process' memory on Mac OS (any OS?), why not give me a setting in preferences to do so? After all the browser is really just a VM at this stage. I'm quite certain I don't need 100 tabs in…

This is a thread about an allocator design, not really about Webkit.

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

#67

Post by tptacek »

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…

This is a pretty well-known CS truism, isn't it? One of the first papers I ever fell in love with covers it in detail: https://users.cs.northwestern.edu/~pdinda/ics-s05/doc/dsa.pd...

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

#68

Post by twoodfin »

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…

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.

I think this is a generally applicable lesson. Programmers overestimate their ability to statically optimize the dynamic behavior of their code, especially relative to a runtime that can access and act on dynamic state.

This comes up in the database world as application developers desiring to "pin" certain tables in memory. Experience has shown this to be an anti-feature: As the schema and workload of a database system evolves, these pinning decisions can become obsolete, starving more relevant tables of buffer space. Dynamic decisions, even made by simple heuristics like LRU, are an empirically winning strategy.

The failure of Itanium/EPIC and the "sufficiently smart compiler" to beat traditional OoO execution is another example from a different computing domain.

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

#69

Post by akrymski »

pizlonator wrote: post #65
akrymski wrote: post #63

Now if only I could limit the amount of memory a browser would consume! The fact that desktop browsers grind a 16GB machine to a halt, while on mobile devices having 1000s of tabs is a non-issue is plain wrong. Since I can't limit a process' memory on Mac OS (any OS?), why not give me a setting in preferences to do so? After all the browser is really just a VM at this stage. I'm quite certain I don't need 100 tabs in…

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.

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

#70

Post by akrymski »

tptacek wrote: post #66
akrymski wrote: post #63

Now if only I could limit the amount of memory a browser would consume! The fact that desktop browsers grind a 16GB machine to a halt, while on mobile devices having 1000s of tabs is a non-issue is plain wrong. Since I can't limit a process' memory on Mac OS (any OS?), why not give me a setting in preferences to do so? After all the browser is really just a VM at this stage. I'm quite certain I don't need 100 tabs in…

This is a thread about an allocator design, not really about Webkit.

It's also a thread about memory allocation in Webkit tho.
Post reply on HN