I am currently using Haiku on a 15 year old 850mhz computer and Haiku runs so well on it! I am shocked at how quickly it operates. What is the secret sauce? Will Haiku be able to keep this speed as it gets developed? Is it because the system is still “bare bones”? I just find this aspect of Haiku to be so impressive and makes me confident that Haiku could be a real contender against other operating systems even in the modern day. Thoughts?
4 Likes
The system is not all that well optimized, uses a 15 year old compiler which does not uses any modern CPU features, and by default, the kernel is built in debug mode which makes it much slower than it could be.
How do other operating systems still manage to feel slower? I have no idea.
9 Likes
A 15 yr. old compiler that uses no modern CPU features?!? Um… why?
3 Likes
Because it have no idea about the new CPU features.
@Luposian: with maximal respect, please, don’t let us start again the argumentation about why gcc2 still supported.
No, I mean why is Haiku using a 15 yr. old compiler with no modern CPU features? Why ISN’T Haiku using a modern compiler? Or is this a compiler limitation for the x86 version of Haiku that cannot be compensated for?
1 Like
Hovewer one can backport the Support for newer CPU Features but it will be Way too much work, what almost nobody can Do, almost nobody will, and almost nobody want to risk, but i’m almost certain, nobody want to Support it, and nobody want to be responsible for a home-brew gcc fork.
But i’m sure no Haiku developer said: lets Support only ancient compiler and nothing else, because there is already gcc6 and gcc7 in Haikuports.
And i’m somewhat sure if one comes up with backported CPU Support, they won’t say no.
… coming back on topic, any ideas why Haiku runs so fast on my 850mhz computer? This aspect makes me really interested in sticking around. I only bothered trying to install it on my old laptop because that Chevalier guy was on The Lunduke Hour, mentioning that it will run well on old computers.
3 Likes
Most OS’s today have their roots in the 80’s and 90’s. If a time machine brought the latest version of Win/OSX/Linux to a user from that era, they would be familiar with all the concepts. BeOS was one of the most modern OS’s in the 90’s, using preemptive multitasking, C++ (pre 98 standard), optimised to run on multiple CPU’s. By extension, Haiku inherits a solid architecture not too different from modern OS’s, and since from the start it was designed to scale well across multiple CPU’s, it works very well on todays hardware.
The real reason Haiku feels faster is 2 fold - the AppServer creates a thread per application, and a thread per window, and is paired with another pair of threads private to app server. The communication between application and AppServer is via message ports, which feels more responsive (at the sacrifice of an additional queing/message delivery costs). In the end, it feels faster, but if you measured the response time from a mouse move/press until the application received it, it will actually be a few ns slower. But it feels more responsive, so I guess it’s a win for the user perception.
The second reason Haiku seems faster is that it’s very lean, with less bloat, less layers between the kernel and the application. This can be a good thing (speed) and a bad thing (features). Engineering is always a compromise, and at this point in the design features of Haiku are inline with the expectations of current users. I wouldn’t be suprised to see that the other mainstream OS’s come full circle, and drop the ‘designed for beginners’ features and bling, and revert to the a more traditional ‘designed for power users’ with less bling, making Haiku GUI modern again 
5 Likes
Haiku is using a modern compiler if you use the 64-bit version. The 32-bit version uses mostly gcc2, because there is no other way to make it run BeOS executables (remember it, the initial and main goal of the project). We will switch away from that, most likely by going 64-bit only, at some point.
But as you can see in this thread, there is still interest for running Haiku on old computers, so we won’t drop 32-bit just yet. And we won’t drop BeOS compatibility, either (not until R1, at least).
5 Likes
Also some not so old computers are 32-bit x86: the Intel atom Z5xx, Z6xx and N2XX run haiku very well - don’t leave them behind!
1 Like
I’m assuming the break in backwards compatibility with BeOS will happen with version 2 of Haiku?
Yes, R1 will still support BeOS programs. We will see what happens in R2, maybe they will still run, maybe not.
2 Likes
Why does it run so fast? Because it’s not made by Microsoft! 
But, seriously, I think it’s because it’s so simple, yet powerful at the same time. There’s no bloat running in the background, no updates trying to install while you’re working, stuff like that.
5 Likes
Right. The way the architecture is configured can offset some non-optimal compiler generated code, in a big way.
It’s the same way with RISCOS when it’s running on the Pi. RiscOS can use only one core, yet everybody claims its GUI is faster than the full Raspbian image - which has access to all the cores. It’s just pretty well architected, and closer to metal -no excessive layering. In the case of RiscOS, it natively doesn’t even use shared libraries.
3 Likes
Haiku inherits BeOS’s scheduler design which turns out to work pretty well. [0] In addition Haiku has added a bunch of code to use thread affinity to divy up the work best across multiple cores. [1]
[0] https://www.haiku-os.org/legacy-docs/benewsletter/Issue4-45.html
[1] https://www.haiku-os.org/blog/paweł_dziepak/2014-02-18_new_scheduler_merged/
3 Likes