login
Search
While browsing some of the Hurd mailing lists recently I came across a discussion which mentions the issues of speed and its relation to competitiveness.
First off, since people are concerned about speed in the first place, I think it is reasonable to assume that the Hurd isn't targeted as a research OS (unless we're researching speed, I guess). I also don't think the single-user desktop is the intended audience either, since there's only a minimal amount of tooth gnashing about bloated programs like OpenOffice and Mozilla running on top of GNOME (or maybe Squeak would be a better example in this case). So I think it is relatively safe to assume that the Hurd is gunning for the multi-user server OS market (flame away!).
With that in mind, I was wondering how exactly we should measure measure the speed of a kernel to determine if it is good enough. On the one hand, you could gin up some microbenchmarks which try to compare something goofy like the number of kernel calls you could do in a second. That may be okay if the two OSes we are comparing have similar designs. But the whole point behind a new OS is that it should be doing some things differently. So maybe we should measure something more useful, like how big of a load Apache (or some other userspace program) can handle running under each OS in question. That's getting better, but if our new OS is different enough, why would we expect to get optimal performance from an application which wasn't specifically written to take advantage of its unique features. So maybe we'd really like to compare application categories (like web serving) instead of individual applications. But then we start to lose the apples to apples nature, and people will complain about unfairness and saying you shouldn't measure performance in this manner. So why were we caring about speed so much in the first place?
Thoughts?
Sadly, most people don't care
Sadly, most people don't care much about speed at all (or they wouldn't use Apache, Gnome, KDE, OpenOffice, Mozilla/Firefox, Java, to name a few). Functionality and features have always had a higher priority. But the difference between those apps and a kernel is that if the kernel is slow it can slow down everything. It's the middleman between hardware and software, it should stand in the way as little as possible.
What's sad about it? It is
What's sad about it?
It is, after all, one of the least important things, as long as it's usable...
If speed was most important, we'd still be looking at text only output...
It's of course quite another case if you are doing something like simulations, or other research work where speed actually matter...
The sad part isn't that thing
The sad part isn't that things became slower, the sad part is that they became much slower than needed. As most developers seem to have faster hardware, they tend to develop things that are usable on their computer, and happily ignore the bloat and the (for them unnoticable) slowness.
A lot slowness nowaday seems to come from insane memory usage with all bad side-effects, not direct cpu usage (which is easiest to fix).
Try running KDE or Gnome and Firefox on a 500 MHz pc with 128 Mb ram. FF shouldn't use much more than 50 Mb, so say the IDE has 50 Mb to use (the rest for miscellanious things, like X). 50 Mb for something that does nothing most of the time and is meant to improve the usage experience should be more than enough, wouldn't you say? But still it seems like a bad deal, giving most of ram away and receiving slowness in return.
Reality check: there are a li
Reality check: there are a limited number of developers and programmers that make useful software, and rather than spending those limited resources of manpower and hours making programs 1-2% faster, they add more features. They know that: 1) most people would rather have stable programs with lots of features then programs that go a little faster but crashes and makes their work harder because of less features, and 2) hardware will get faster. Remember when harddrives were small and everyone was trying to make programs smaller so that everything could fit on 10 mgs of space? With 500 gig drives no one does that anymore because its a waste of time. For most ppl, the speed of the CPU is not as big a deal as the speed (or lack thereof) of the harddisk itself.
Before everyone flames me to ashes, I know that in some cases (simulation, research, folding@home, games) speed is critical, and I use many applications where speed is critical, but most ppl are not "power" users and don't really care about every last hz of speed. At the end of the day, most programmers make their $$$ coding for the mass market who really doesn't know (or care) how many MIPS their CPU can crank out.
Then care to explain why Ubun
Then care to explain why Ubuntu on a 800 MHz pc with 256 Mb ram is dog slow? Trivial things like selecting different windows needs all cpu, starting up gconsole or whatever it's called takes seconds, even when it should be all cached in memory it takes long to start up. Let's not start about resizing windows or more demanding applications on such system. My 200 Mhz with fluxbox felt faster than that. Maybe it's some horrible bug somewhere, I don't know, but I suspect the insane memory usage is part of the problem.
I'm not talking about squeezing the most performance out of applications, I'm talking about decent speed. Even halfway the optimum would be nice, not the apparently current process of making things as slow as possible as long as they can get away with it. One where you don't have to wait unnecessarily long before mundane operations are performed.
People don't care about their MIPS, that's right. Then instead of demanding of them that they need many MIPS to get a usable system, why not let them get a slow but power efficient system which does everything they want? Why tell them that they need more, better hardware to run those simple things they want? Why is my old pc suddenly so slow doing things it used to do just fine? Sure, it looks slightly better now, but is the price for that reasonable at the moment?
The seek speed of harddisks hardly improved the last few years, to give one big performance bottleneck.
The applications you named which are performance critical are also applications which can assume they have the whole computer for themselves (except folding@home, but that was a wrong example anyway). Those aren't the problem, the problem are those applications which are always running while doing nothing and think they own the world, greedily consuming memory and other resources.
The problem is a wrong attitude by developers. They use the same argments as you do, and if they all make their little piece slow, when put together, the whole thing becomes slow and suddenly it's hard to blame anyone.
Basic optimisation is part of development, or so it should be. What if your app needs 20 Mb to draw a handful of icons? Go find out and fix it, don't start whining about hardware becomming better, that's still at least 15 Mb too much, to be very generous.
Full circle
Let's try to bring this back full circle. In the case of the Hurd, we have two different stories. On the one hand, we have Hurd on top of the GNU/Mach microkernel. It kind-of-sort-of mostly works but is (relatively) slow and buggy. On the other hand, we have the Hurd on L4 which should be faster than Mach. The only problem is that it is mostly vaporware. Should development effort be put towards speeding up an existing solution, or starting over from scratch? I guess that brings us back to the original question, how do we measure that our current system is fast enough and start concentrating on other things like adding features and fixing bugs? Is there an objective measure that we can use? Let's see if we can't phrase it another way. The current developers want the Hurd to be competitive in speed. But most surely they'd also eventually like to see it completed (or at least semi-usable). Where should they make that speed/completion trade off?
Fixing (known) bugs should ha
Fixing (known) bugs should have always priority one. It depends on the software, but in general there isn't much worse than unstable software.
GNU software tends to be bit bloated, but very stable. Most of the bloat seems to come from feature creep and can be found back in the million command line options. But overall it is good enough because the absolute resource waste is small enough, and it are a lot small independent applications.
Imagine a big group of bloated applications, and to run one you need most of them, thanks to cascading dependencies (which causes an exponential grow in dependencies, with enough layers): Welcome to GUI land.
If you have a stable base, then the features you do add shouldn't add unnecessary bloat, nor slow down the whole thing. Of course the feature itself could be unnecessary bloat, but that's another, easier to solve matter. So my point is that adding features and working on speed shouldn't be two seperate things, but that whenever something is added or changed it should be done well enough that it doesn't have an unproportional impact on the whole.
As for Mach versus L4: The part of Hurd that does the interaction with the micro kernel is probably small, assuming it is abstracted away for the rest of the code, so changing between microkernels shouldn't be that much work, relatively speaking (comparable to adding a new architecture support to Linux). I'm ignortant on this matter, so big disclaimer here. So assuming the above, why not support both? If that isn't possible, perhaps it's worth it to change the code so that it is? Abstraction has its cost, but it is one of the more pleasant kinds of bloat.
One man's bloat is another man's feature.
You're overgeneralizing to the point of idiocy. HAND.
I'm not talking about squeezi
I'm not talking about squeezing the most performance out of applications, I'm talking about decent speed. Even halfway the optimum would be nice, not the apparently current process of making things as slow as possible as long as they can get away with it. One where you don't have to wait unnecessarily long before mundane operations are performed.
I could not agree with you more, and I think developers should spend time optimizing applications, which can also help eliminate bugs. In my post I mentioned applications that were extremely computationally intense and one would assume they are optimized to take advantage of CPU power. When developers make applications, there is always a target system that they are shooting for, and whether this actually is or even corrospondes to the "minimum system requirenments" is another discussion, but sufice to say that when a system is below these specs, things can be "unresonably" slow. Unreasonably varies by personal tolorance and system specs, but I personally like things VERY snappy, as I would imagine most ppl here would.
As for your Ubuntu, while I have not used that specific distro (gentoo is my distro of choice these days), I'm assuming you turned off all unnessesary services, cleaned up the startup scripts and installed only the software you need. Both gnome and KDE are not known for their speed, although at least with KDE (which I use more than gnome) I have noticed that in 3.4 it "feels" faster than it did in 3.2-3.3 If you're super-performance starved, try going back to fluxbox, although you lose some of the pretty go-gas of the bloatier window managers.
No idea to many people I'm ta
No idea to many people I'm talking, but I guess more than one. :-)
There are two kind of optimisation: Sane design and hand tuned ugliness which speeds the thing up. The latter is only easy to do for CPU usage, other things need a more global solution to fix them. If something is designed wrong, with inherent slowness in it or awkward structure so that making it fast is very hard, then relative big and many parts need to be changed. But doing this is very hard because the whole picture must be seen and understood by the programmer who improves it. Something which could have been done much easier and more efficient by the initial developers who already have that big picture in mind. Later the second kind of optimisation is probably applied, and features are added, so the whole became only more complex and harder to understand. At one point it's less work to rewrite the thing in a better way from scratch than to fix the existing software, and that's the moment you know the programmers failed.
It's someone else's Ubuntu, I'm still running fluxbox, because I do most things from a terminal or use key bindings, and don't like unnecessary stuff cluttering and wasting screen space (no toolbar for me).I mentioned Ubuntu because I was appaled by its overal performance, it could probably have been be any distro with more or less a similar setup. I crept out from under my rock to see what things people use nowaday, and am scared away right back.
I've found Ubuntu to be one o
I've found Ubuntu to be one of the faster modern distros actually (faster than FC3, Suse 9.1 and Yoper IME).
I run it on a P3-550 with 192MB of RAM and it's useable, but a lot slower than I'd like. The Gnome team (particularly Federico Mena) are putting a lot of effort into optimisation now, although I'm not sure how deep they're going... most of the current work seems to be on Cairo and associated rendering issues.
It's primarily memory and unnecessary I/O that make Gnome slow IMHO... because a lot of Gnome stuff isn't written with performance in mind.
I think developers should test code on a system like mine.
It looks like the whole is so
It looks like the whole is so bloated that whenever you do something, it pushes out cached files (e.g. libraries and executable pages needed to run), and everytime you do something else, you need to wait on the harddisk to retrieve some pushed out pages. Though certain things use insanely lot of cpu too, like selecting windows, so the IO thing isn't the whole problem. It's so bad that I suspect there are some bugs here and there which cause it. It's not like there is no hardware 2D acceleration, then I'd expect to see redraws happening...
Luckily some Gnome people are optimizing things now, but as I said before, optimisation and feature adding shouldn't be two seperate things. Because adding bloat is so much easier than removing it, it is doomed to fail because most won't devs are busy with adding new things, not improving existing ones, or so it seems.
They should test on 500 MHz computers with 128 Mb ram. Then the other hardware resources can be used by a really demanding application, something different than background bells and whistles. Only things that are actively used and do something may use more resources.
Before someone makes the obvious point that if I seem to know so well how it must be done, then why not fix it myself? First, I don't use Gnome or KDE, so why should I be the one to help improving them? Even if they weren't bloated I wouldn't use them. Second, developers should learn to take a step back and take a good look at their creation, and make sure that it isn't too resources hungry.
Agreed. KDE & Gnome should b
Agreed. KDE & Gnome should be engineered to fly with 128 MB of RAM.
Linux platforms probably have the largest install base of KDE/Gnome, but Linux is also touted for old systems and for developing countries where good hardware is scarce.