3 ms·

I'd happily see performance, latency and stability of your allocators in massively multithreaded, long-living programs with workloads where hundreds or thousand

I'd happily see performance, latency and stability of your allocators in massively multithreaded, long-living programs with workloads where hundreds or thousands of parallel threads continuously create and destroy short-lived small and medium objects. Writing allocators for domain-specific access patterns is easy. Writing a general-purpose high performing, stable allocator with bounded P99 latency is hard. Give your friend, Dunning–Kruger, some better pills to keep him from speaking through you.

Pannoniae 15d ago
You're correct, but his point is that you don't need to solve the generic problem. Solving the generic problem is very hard. Grug doesn't like solving hard problem. What does grug do? Solve five easy problems. Make an arena for the short-lived objects, reuse the objects, use generic multithreaded malloc for the rest. Grug happy.
matheusmoreira 15d ago
Not everything needs to be general purpose. Allocation can be as easy as bumping a pointer, and it's hard to beat that.
cv5005 15d ago
>where hundreds or thousands of parallel threads continuously create and destroy short-lived small and medium objects. Should one even want a global, general purpose heap allocator for that? Seems like a crazy idea to even consider.
Mikhail_Edoshin 15d ago
I guess the point was that before you consider using a different allocator you should rule out a custom one. And that's rather hard, because a general purpose allocator makes all decisions based only on the requested size. This is a very simple interface and such a tool is worth having. But a custom allocator can both bake in a specific scenario and provide more nuanced interaction.
jonkerz 15d ago
>massively multithreaded, long-living programs with workloads where hundreds or thousands of parallel threads continuously create and destroy short-lived small and medium objects. My first thought would be to use per thread pool allocators.

Pannoniae 15d ago

You're correct, but his point is that you don't need to solve the generic problem. Solving the generic problem is very hard. Grug doesn't like solving hard problem. What does grug do? Solve five easy problems. Make an arena for the short-lived objects, reuse the objects, use generic multithreaded malloc for the rest. Grug happy.

matheusmoreira 15d ago

Not everything needs to be general purpose. Allocation can be as easy as bumping a pointer, and it's hard to beat that.

cv5005 15d ago

>where hundreds or thousands of parallel threads continuously create and destroy short-lived small and medium objects. Should one even want a global, general purpose heap allocator for that? Seems like a crazy idea to even consider.

Mikhail_Edoshin 15d ago

I guess the point was that before you consider using a different allocator you should rule out a custom one. And that's rather hard, because a general purpose allocator makes all decisions based only on the requested size. This is a very simple interface and such a tool is worth having. But a custom allocator can both bake in a specific scenario and provide more nuanced interaction.

jonkerz 15d ago

>massively multithreaded, long-living programs with workloads where hundreds or thousands of parallel threads continuously create and destroy short-lived small and medium objects. My first thought would be to use per thread pool allocators.