3 ms·

I bet it doesn’t do that well. Here’s an example. I have a program that does a lot of memory allocation and reallocation. The memory management strategies in m

I bet it doesn’t do that well. Here’s an example. I have a program that does a lot of memory allocation and reallocation. The memory management strategies in modern OS’s work wonders on this, better than a custom allocator I can write in a reasonable amount of time. In bare metal os I would lose this all for the advantage of not loading an os that tends to stay out of the way unless needed anyway. Where I see use for this is more likely in situations where time to boot is critical but actual resource requirements minimal. Things like a simple kiosk system or embedded hardware.

vdupras 2y ago
> Here’s an example. I have a program that does a lot of memory allocation and reallocation. It's likely that if memory allocation overhead is part of your bottleneck, that using malloc() is actually a bad idea. Other management strategies such as arenas or rolling buffer will likely perform better. They're also trivial to implement ad-hoc. Of course, you might arrive at the conclusion that the complexity overhead of custom allocation strategies[1] might not be worth it, but in this case, it means speed is not really an issue. [1]: as well as, maybe, the necessary redesign of the application to fit those allocation strategies more elegantly.
- AnotherGoodName 2y ago
  Fun fact I literally implemented a memory pool since most of the allocs were on the same sized structs and did worse than the os allocator.
  - vdupras 2y ago
    That's possible. Maybe that such OS "unfairly" stacks custom options against its malloc implementation. But I wouldn't be so sure to claim that such a pool, implemented in assembler on an OS that leaves everything to you, wouldn't outperform the os allocator you refer to. After all, there is fundamentally less information to manage.
Koshkin 2y ago
Then maybe a unikernel such as Nanos would work better for your use case. https://nanos.org/ https://nanos.org/

vdupras 2y ago

> Here’s an example. I have a program that does a lot of memory allocation and reallocation. It's likely that if memory allocation overhead is part of your bottleneck, that using malloc() is actually a bad idea. Other management strategies such as arenas or rolling buffer will likely perform better. They're also trivial to implement ad-hoc. Of course, you might arrive at the conclusion that the complexity overhead of custom allocation strategies[1] might not be worth it, but in this case, it means speed is not really an issue. [1]: as well as, maybe, the necessary redesign of the application to fit those allocation strategies more elegantly.

AnotherGoodName 2y ago
Fun fact I literally implemented a memory pool since most of the allocs were on the same sized structs and did worse than the os allocator.
- vdupras 2y ago
  That's possible. Maybe that such OS "unfairly" stacks custom options against its malloc implementation. But I wouldn't be so sure to claim that such a pool, implemented in assembler on an OS that leaves everything to you, wouldn't outperform the os allocator you refer to. After all, there is fundamentally less information to manage.

Koshkin 2y ago

Then maybe a unikernel such as Nanos would work better for your use case. https://nanos.org/ https://nanos.org/