I have never used BeOS; it is not usable on my computer because it can’t detect my USB keyboard and mouse. I know everyone says BeOS had legendary responsiveness and speed, and I also know that Haiku is not fully optimized yet. I’m just wondering if the experience of Haiku is something close to what they were talking about, or is there room for it to get even better when the optimizations are applied?
It is indeed true that the R1Alpha1 release has a lot of debugging facilities still turned on in the kernel. If memory serves, I recall Ingo mentioning about 20% increase in speed if those are turned off. Even with those compile time options turned on, Haiku is several times faster than BeOS at performing certain tasks. In other areas it is slower.
Compiling a Haiku image is one of the interesting tasks, and when I last tested it, Haiku was several times faster than ZETA 1.2 when I still had that running on one of my computers. I compared it in terms of performance versus Linux. At the time, Haiku was about 5 times slower than Linux at compiling an image, while ZETA was about 20 times slower, if memory serves. It would be interesting to do some up to date tests. In the meantime, Haiku has caught up to about 2.5 to 3 times the compile time compared to Linux on the same hardware. I think those numbers may be with debugging facilities turned off, I am not sure.
The app_server of Haiku is a mixed bag compared to BeOS. On one hand, the comparisson is difficult, since Haiku does anti-aliasing for all drawing primitives, which is of course more demanding compared to BeOS. For example, Haiku random line rendering is slower compared to BeOS/ZETA. But on the other hand, I optimized straight line rendering (horizontal and vertical lines), which make up a large percentage of rendering in the GUI, and those are actually faster than ZETA (and ZETA was faster than BeOS). Bitmap rendering is also slightly faster compared to ZETA, about 20% if I recall correctly. Text rendering, though, is a lot slower, while also more advanced. for example, BeOS had 16 levels of anti-aliasing, while Haiku does 256 levels and optionally sub-pixel anti-aliasing (not much of a performance hit, though). B_OP_COPY text rendering can be about 5 to 7 times faster on BeOS compared to Haiku, but the fancier GUI in Haiku requires B_OP_OVER text rendering, and Haiku is almost as fast as ZETA in that disciplin, though I don’t remember the exact numbers there.
The overall screen update mechanism/cycle in ZETA seems to be much better than Haiku though, which can be seen when moving windows around and watching the smoothness and CPU load. You can see that Haiku is more stressed and I still have to optimize that a lot. But since the principles that made BeOS as a system so responsive (threading and message passing) apply 100% to Haiku, and since Haiku has some message passing optimizations of it’s own, Haiku as a system feels just as responsive as BeOS. Since some of our application loading seems to be faster than BeOS and ZETA, the system can even feel more responsive. For example, on my main development machine, I have a 4ms drive installed, and Firefox launches in about 1.5 seconds from the drive (uncached) on Haiku. On the same computer, it takes 7 to 11 seconds to launch Firefox in ZETA, and launching Firefox in Linux is nowhere near 1.5 seconds uncached, though I have not measured it. I think even cached it’s slightly more than 1.5 seconds. That’s Firefox 3 versus Firefox 2, though. But if I am not wrong, Firefox 3 is more optimized than Firefox 2, so it should be faster in Linux, not slower.
The Haiku app_server will of course perform very differently when we are able to switch to a 3D texture based window rendering. Then the screen update cycle becomes irrelevant and no CPU is involved when windows are moved on screen. The current work on porting Gallium3D and the DRM/DRI support, that is being worked on, will make this path viable.
all things considering, Haiku has HUGE potential to be a really great operating system, the only thing that needs to be adopted is Be INC’s determination to move forward and implement new technologies (may i suggest Grand Central dispatch)
Thanks for your great reply. What is the option to turn those facilities off? I am a developer, and am running Haiku from source, however on the occasion when it crashes on me, I’m not deep enough into the kernel yet to really know or care exactly why, and just reboot. So does it sound like maybe I really don’t need those options?
I have noticed that the window motion when dragging seems a bit smoother than certain other operating systems. The responsiveness of some apps, such as Bon Echo, was a little disappointing after all the BeOS reviews I’d read lauding the “instant UI response time”, but I don’t think that’s really Haiku’s fault and is no worse than it is on any other OS. After all, Bon Echo isn’t even using native menus.
The whole “3D texture” thing seems a little weird to me because it feels like it would cause antialiasing around all the windows. This is just based on my limited experience programming OpenGL games, and I know that it is in fact wrong, as several mainstream OS’s are using this method. It seems ironic that we’ve come full circle from computers like Amiga that had a video coprocessor for everything, to just slow-cpu’d video-game consoles having one and computers doing everything in software, to computers having a “3D Accelerator” for games only, and now the accelerators are ubiquitous enough they’re starting to get used for everything again.
Stippi, wasn’t there some talk on the mailing lists a year or so ago (when Haiku first became self hosting) that the primary culprit of low compile speeds under Haiku was the process of updating the FS attribute database? Compilation and SVN update was the worse possible use-case scenarios for a database like filesystem. It wasn’t a priority at the time, but there was some talk about possible future optimisations that can be done to accelerate compilation times.
In the top-level source folder, you can copy and modify the build headers (into user_build_headers or similar) under the same name. The build system includes the headers from the user location and falls back to the default headers. So you can modify them without causing SVN to check in your modifications. The main header has a global switch at the top. Just define KDEBUG=0 or something like that.
Hope this helps.
I’ve conducted some performance comparisons that measure system/kernel performance lately. Have a blast here.