21–30 of 50 posts
Earlier quoted context omitted.
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?
Extreme real-time control with total control over jitter etc. Not only fast response time but predictable.
> BareMetal OS is an exokernel-based operating system crafted entirely in x86-64 assembly and is designed to provide unparalleled levels of flexibility and efficiency.
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).
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.
There was a test with the 1BRC and it was shown that Rust was faster than Assembly (and likely C as well), meaning, a compiler will probably do a better job than a human optimizing code. How sure can someone be that this is indeed performant?
It’s always fun to see this get brought up on Hacker News! I’m the developer behind BareMetal OS. Keep in mind that this is all geared toward raw compute and throughput. No ring-3, no multitasking (we do support multiple cores though), and no higher-level abstractions like TCP/IP or full-featured file systems. While it’s all coded in X86-64 assembly, a rewrite to ARM/RISC-V would be interesting once that hardware is…
> ARM/RISC-V would be interesting once that hardware is standardized. Could you elaborate on this? Both ARM and RISC-V have standardized their hardware feature and different target versions. Is it more on the iterative angle given X86-64 now moves very slowly?
ACPI is available, but not widely supported.
Some hardware uses DeviceTree.
Other hardware just expects you to know what devices are connected and how to interact with them.
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).
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…
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.
It’s always fun to see this get brought up on Hacker News! I’m the developer behind BareMetal OS. Keep in mind that this is all geared toward raw compute and throughput. No ring-3, no multitasking (we do support multiple cores though), and no higher-level abstractions like TCP/IP or full-featured file systems. While it’s all coded in X86-64 assembly, a rewrite to ARM/RISC-V would be interesting once that hardware is…
Earlier quoted context omitted.
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…
> 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…
Earlier quoted context omitted.
> 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…
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.
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.