Phoronix has conducted some preliminary benchmarks, comparing Debian GNU/Hurd to Debian GNU/Linux. “There was only a handful of tests that could be successfully run under Debian GNU/Hurd and in those results the numbers were generally close, though Debian GNU/Linux was running about 4% faster in some and with the MP3 encoding the Linux OS was nearly 20% faster. Debian GNU/Hurd is an interesting project but for now its support is still in shambles, the hardware support is vastly outdated, and there is also no SMP support at this time. Regardless, it will be interesting to see how Debian GNU/Hurd turns out for the 7.0 Wheezy milestone.”
Not a good start when you need to benchmark the OS on a VM because you don’t have any 2002 era hardware to run it natively.
Well gee, isn’t hardware/driver support the biggest problem with all new OSes?
Honestly, I was surprised to see that the benchmarks they ran were as close as they were.
Edit: (and yes, for all intents and purposes, Hurd is a “new” OS, since nobody uses it for anything practical yet)
Edited 2011-07-21 15:05 UTC
I was going to point out that Hurd is older than Linux, then I spotted your edit.
However with pedantics cast aside, I do agree with your point. I’d sooner see tests inside a VM than tests on varying hardware.
Edited 2011-07-21 15:24 UTC
Ultimately, I want to see more varied tests – exercising graphics (assuming there are any drivers), networking, disk I/O performance, etc. One of the things I’ve always read is that microkernel OSes based on the likes of Minix and Hurd are going to be noticeably slower due to all the overhead of message passing between processes, etc.
CPU intensive testing doesn’t interest me as much between kernels – and even disk-based testing on a VM is sort of pointless due to host caching, etc.
When Hurd finally gets SMP support, maybe then some CPU-related tests will be interesting – to see how well a thread scheduler can cope in such an environment.
Security and stability are probably the longer-term goals of Hurd over Linux, obviously.
I don’t think that must be a given. QNX for instance uses a message-passing, small-privileged-kernel model, and it is known for its real-time performance — even on 8086 CPUs.
That’s probably not the same kind or performance as raw throughput in MPEG encoding, say, and maybe that’s why little effort has been put into OSes in this vein outside of research. Or maybe it is that doing this type of OS model is hard, and nonportable (much assembly required). But in today’s heightened interest in security and reliability, on hardware so fast that a few % difference in raw throughput makes little difference to most people, maybe more effort ought to be put into this and similar approaches (witness the Genode/L4/Fiasco efforts on ARMish _cell phones_).
[ tongue-in-cheek ]
hmmmmm… don’t we already have BSD’s for that ?
[ /tongue-in-cheek ]
Not all that surprising when you look at them – for most of those benchmarks, the OS isn’t contributing much. All it has to do is stay out of the way, and let the CPU crunch numbers…
Ironically, for the purpose of the exercise it is an ideal setup since it allows a consistent baseline for the scores.
The Hurd Project has always interested me, it’s unfortunate that it never gained any momentum. I’m curious how it would fare against darwin or QNX If it had more resources devoted to it over the past few years.
It never gained momentum because it was never finished. They kept changing the micro kernel they were going to use.
I think one day Hurd will become a major player.
I wish them luck at what theyre doing! Although I totally love linux, I can barely wait until Hurd is stable and working well
*Think* it will, or just *hope* it will? Because this project has been going over twenty years already, and after all that, has very little to show for it. Indeed, it’s actually getting worse over time – according to the FAQ, it used to support SMP, but the code no longer works.
Ultimately, I don’t think the project will ever achieve anything, unless they get an influx of new contributors. Because with just the current handful of people working on it, they’re not going to keep up, no matter how hard they work.
The major problem with Hurd from my small research is the choice of uKernel. But what is worse is the Hurd is tightly coupled to Mach (the same mistake as MacOSX). On the other hand GenodeOS is portable to various uKernels. Even if GNU-Mach supports various modern CPUs and drivers are moved to the user-space then the performance will be slow and possible have many other problems. Hurd is totally built for Mach, and this is a fatal design flaw.Even if they choose the in-kernel embedding of Mach, another fatal design fault of Apple they will still have problems. The FOSS software depends a lot on modularization and Hurd made the fatal decision not to follow it.
In my understanding they could go with NOVA and create a thin a Mach-portability layer for IOKit and Hurd. But I may be wrong.
along with just about any non mainstream OS.
How hard would it be to port Linux divers to Hurd? Would it be possible to make driver interface layer in Hurd compatible with Linux? Now, I’m obviously not talking about any level of binary compatibility, just source compatibly.