All About Libpas, Phil's Super Fast Malloc
1–10 of 87 posts
Re: All About Libpas, Phil's Super Fast Malloc
#2Well the other browser's design doc is not anywhere near this detailed, but if you want to compare and contrast the overall design here is Chromium's PartitionAlloc.
https://chromium.googlesource.com/chromium/src/+/master/base...
Re: All About Libpas, Phil's Super Fast Malloc
#3I wonder how this compares to jemalloc, mimalloc, snmalloc?
Re: All About Libpas, Phil's Super Fast Malloc
#4I wonder how this compares to jemalloc, mimalloc, snmalloc?
I never got a chance to compare it to those, since I was most interested in beating bmalloc. And I mainly wanted to beat it on Safari workloads.
I believe bmalloc was previously compared against jemalloc and tcmalloc, also using Safari workloads, and bmalloc was significantly faster at the time.
Re: All About Libpas, Phil's Super Fast Malloc
#5> Consequently, passing a function pointer (or struct of function pointers), where the pointer points to an always_inline function and the callee is always_inline results in specialization akin to template monomorphization. This works to any depth; the compiler won't be satisfied until there are no more always_inline function calls. This fortuitous development in compilers allowed me to write very nice template code in C. Libpas achieves templates in C using config structs that contain function pointers -- sometimes to always_inline functions (when we want specialization and inlining) and sometimes to out-of-line functions (when we want specialization but not inlining). Additionally, the C template style allows us to have true polymorphic functions. Lots of libpas slow paths are huge and not at all hot. We don't want that code specialized for every config. Luckily, this works just fine in C templates -- those polymorphic functions just pass around a pointer to the config they are using, and dynamically load and call things in that config, almost exactly the same way that the specialized code would do. This saves a lot of code size versus C++ templates.
This document is incredible!
Re: All About Libpas, Phil's Super Fast Malloc
#6> Consequently, passing a function pointer (or struct of function pointers), where the pointer points to an always_inline function and the callee is always_inline results in specialization akin to template monomorphization. This works to any depth; the compiler won't be satisfied until there are no more always_inline function calls. This fortuitous development in compilers allowed me to write very nice template code…
[deleted]
Re: All About Libpas, Phil's Super Fast Malloc
#7I'm always suspicious of things that are named after the maker.
Re: All About Libpas, Phil's Super Fast Malloc
#8> Consequently, passing a function pointer (or struct of function pointers), where the pointer points to an always_inline function and the callee is always_inline results in specialization akin to template monomorphization. This works to any depth; the compiler won't be satisfied until there are no more always_inline function calls. This fortuitous development in compilers allowed me to write very nice template code in C. Libpas achieves templates in C using config structs that contain function pointers -- sometimes to always_inline functions (when we want specialization and inlining) and sometimes to out-of-line functions (when we want specialization but not inlining). Additionally, the C template style allows us to have true polymorphic functions. Lots of libpas slow paths are huge and not at all hot. We don't want that code specialized for every config. Luckily, this works just fine in C templates -- those polymorphic functions just pass around a pointer to the config they are using, and dynamically load and call things in that config, almost exactly the same way that the specialized code would do. This saves a lot of code size versus C++ templates.
I thought this was super interesting. Seems like a very nice technique for when you use function pointers in C for stuff like sort comparison. There was an earlier thread about PostgreSQL that discussed how they created multiple sort functions to avoid the overhead of a indirect function pointer call when sorting things like integers where the function call dwarfs the comparison cost. This seems like a technique that could have been used to avoid duplicating the sorting functions while still getting the benefits.
Re: All About Libpas, Phil's Super Fast Malloc
#9I'm always suspicious of things that are named after the maker.
From the top of my head: Linux, Bourne shell...
Re: All About Libpas, Phil's Super Fast Malloc
#10I'm always suspicious of things that are named after the maker.
It's called libpas, and pas stands for whatever you like.