16 ms·

A low-overhead environment like this must be perfect for HPC applications, i.e., when you want to use a computer in its primary function (to perform calculation

A low-overhead environment like this must be perfect for HPC applications, i.e., when you want to use a computer in its primary function (to perform calculations, as fast as possible).

miohtama 2y ago
This is a really interesting approach. What are the main bottlenecks something like BaremetalOS solves? Context switches? Copying data forth and back userland? Something else?
- actionfromafar 2y ago
  Extreme real-time control with total control over jitter etc. Not only fast response time but predictable.
  - megiddo 2y ago
    Control over jitter would be less ideal for very tight deadlines due to branch prediction, cache misses, instruction counting, etc.
    - actionfromafar 2y ago
      Yes?
- ianseyler 2y ago
  Correct. BareMetal (the kernel) doesn't have context switching or userland. Think of the kernel as just a hardware abstraction layer.
AnotherGoodName 2y ago
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/

A low-overhead environment like this must be perfect for HPC applications, i.e., when you want to use a computer in its primary function (to perform calculations, as fast as possible).

miohtama 2y ago

This is a really interesting approach. What are the main bottlenecks something like BaremetalOS solves? Context switches? Copying data forth and back userland? Something else?

actionfromafar 2y ago
Extreme real-time control with total control over jitter etc. Not only fast response time but predictable.
- megiddo 2y ago
  Control over jitter would be less ideal for very tight deadlines due to branch prediction, cache misses, instruction counting, etc.
  - actionfromafar 2y ago
    Yes?
ianseyler 2y ago
Correct. BareMetal (the kernel) doesn't have context switching or userland. Think of the kernel as just a hardware abstraction layer.

AnotherGoodName 2y ago

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/