[openbeos] Re: Article on BeOS vs MacOS X
- From: lists@xxxxxxxxxx
- To: openbeos@xxxxxxxxxxxxx
- Date: Wed, 19 Dec 2001 15:46:50 -0600
Guillaume <guillaume.maillard@xxxxxxxxxxx> wrote:
> > It also seems to have the same unix-like scheduling problems. Resizing
>> a terminal with top is a very nice test.
>
> It makes me smile :)
>Because you see that a graphical operation take more than 3%
>of your cpu, you conclude that the scheduling is the cause...
I'm not sure whether Mark-Jan was obsessed about a specific CPU load
factor (he didn't mention anything about 3% or n%, if I remember
correctly). I think specific CPU loads are sort of irrelevant to the
main point, actually.
The experiment he mentioned is is not merely a "graphical
operation"...it shows you what happens in the system under some
degree of load, therefore scheduling complexity. (Try the same
experiment in Linux with an FTP session open and playing an MP3, and
I bet the experiment gets even more interesting.)
The key here, and what I think (forgive me, M-J) Mark-Jan was getting
at, is that the Linux kernel handles scheduling very differently from
BeOS, leading to different user experiences. "Slow" becomes a matter
of perception, not a CPU load percentage. (I don't care if a redraw
takes 90% of the CPU in some cases, as long as the user experience is
responsive in ways I want it to be, e.g., a typical BeOS experience.)
Linux has great networking throughput, partly due to scheduling. BeOS
makes a different compromise between making the GUI seem snappy under
loads (something I find important, given my occasional forays into
legacy Mac OS, in which the screen stops when I mouse down on a menu,
and how nuts that makes me), but does so at the sacrifice of
networking. Simple example. (On top of it, BeOS 5 networking
is...um...subomptimal on its own, contributing to performance
trouble, but I'm talking kernel scheduling issues.)
As for "better performance" on Linux versus BeOS or any system, it
all depends on what you feel is important. Last time I tried Linux
(yesterday), it sucked (800-something PIII). It all comes down to
your, in this case my, criteria for what makes a system feel fast.
Creaky slow screen updates and resizes aren't what I look for (and
it's *not* simply a windowing system problem, although that's part of
it).
Mark-Jan (if he doesn't mind my speaking for him) is interested for
professional reasons in a responsive scheduler with a preemptible
kernel--most Linux distros are simply not up to the task Mark-Jan
needs.
Other related posts:
