OSnews is running an
interview
with the dot's very own
Waldo Bastian.
Besides his long-running contributions to a large range
of the KDE libraries and other desktop infrastructure, Waldo is
well known as the KDE 2 "release dude", for helping keep the KDE
infrastructure operating, and as an inexhaustible supply
of knowledge and tips to other developers on IRC. In his at times
serious and at times tongue-in-cheek interview,
Waldo talks about the growth of Linux, his employer
SuSE,
GNOME competition and cooperation,
the role of
UnitedLinux, and KDE's performance,
and also reveals a secret way to get
Trolltech
to add requested features to Qt: "Catch a live Troll, lock it up
and feed it beer till it promises to make whatever you need."
Dot Categories:
Comments
Here are my own point of view on "Why Linux+X+KDE is slower than Windows on the same machine ?"
1) First, it is not the fault of Linux. Every test I have seen gives the Linux kernel faster than any version of Windows and Windows NT on equivalent functions.
2) Windows is faster in graphics drawing, because it is integrated in its kernel, and because its drivers are made by the constructors, so there are highly optimized.
3) Windows is faster in graphics drawing, because graphics seems to have a higher priority than the other system tasks. (It is a psychological choice).
But maybe I'm wrong on this point (X-Windows has a higher priority too).
4) X-Window is slower, because when you send it a primitive, it is marshalled, sent to a socket, unmarshalled, and then managed by the X server. It is many times slower than making a system call ! Especially when you just want drawing a line or a rectangle...
5) X-Window is slower, because its drivers are sometimes, on some functions, not optimized.
6) X-Window is slower, because when you want to deal with a bitmap, you must download it from the X-server to your program, process it, and then upload it to the X-server. When the bitmap is huge, the unnecessary data copy is a bottleneck. With the X-SHM extension, this process is a bit quicker, but stays not optimal.
7) Graphics application under Linux may be slower, because of not using the special instructions of x86 processors (MMX, SSE, etc.). They can't because they must be compiled on other processors than the x86 ones.
8) Linux is slower in launching programs because of the well-known dynamic library loader in glibc. This problem should be adressed with GCC 3.1. I hope so !
9) Windows is faster in lauching programs because of many internal optimizations :
- Dynamic libraries are preloaded.
- Many dynamic libraries are preloaded at the same address for every process that use them.
- Programs like Explorer or Office are preloaded (it is a psychological optimization !)
These optimizations are possible because, under Windows, 90% of the executed code comes from Micro$oft, and because dynamic libraries of Windows have less
functionalities than the ELF format used under Linux.
It is not possible to do the same thing in a free OS like Linux. Maybe you could do these optimizations with glibc, which is used everywhere. But you couldn't go as far as Microsoft did.
The KDE guys did their best with kdeinit. With GCC 3.1, the things will be better. But I think the major bottleneck resides in X-Window.
I'm optimistic. I think graphics under Linux will be faster than Windows in a few years, with a transformed X-Window, or an alternative.
Be patient ! Freedom is more important than speed...
I already forgot about the gcc 3.1 sutff because, as Waldo said, this has been mostly solved by kdeinit. After all, gcc people don't have the fault of KDE loading slow. A lot of people should apologise to gcc people I think.
I hope we don't blame now X if it's not their fault!
> Windows is faster in graphics drawing, because it is integrated in its kernel,
In kernel space doesn't automatically mean faster!
> Windows is faster in graphics drawing, because graphics seems to have a higher
> priority than the other system tasks.
So renice -15 `pidof X` will make everything faster? I've hardly noticed any improvement in performance. And except when drawing big animations, X uses very little to almost no CPU power.
> 4) X-Window is slower, because when you send it a primitive, it is
> marshalled, sent to a socket, unmarshalled, and then managed by the X server.
Most of the data (pixmaps) are locally transferred using shared memory.
> 7) Graphics application under Linux may be slower, because of not using the
> special instructions of x86 processors (MMX, SSE, etc.).
All the Linux video players I've seen (Mplayer, Xine, etc.) have *heavily* optimized using assembly. Even Gdk-Pixbuf contains MMX code.
And how much difference does it really make if MMX/SSE/3Dnow is used in drawing static graphics? Windows are only drawn once every expose, and CPUs these days are 2+ Ghz.
> They can't because they must be compiled on other processors than the x86
> ones.
All you have to do is
#ifdef PENTIUM_MMX
// optimized assembly code
#else
// portable C/C++ code
#endif
> > Windows is faster in graphics drawing, because it is integrated in its kernel,
>
> In kernel space doesn't automatically mean faster!
No, but it helps a lot...
>
>
> > Windows is faster in graphics drawing, because graphics seems to have a higher
> > priority than the other system tasks.
>
> So renice -15 `pidof X` will make everything faster? I've hardly noticed any improvement in performance. And except when drawing big animations, X uses very little to almost no CPU power.
On my PII-400, X has a -10 priority.
Moving the mouse takes about 2.5% of CPU
Moving a window with contents easily takes 30% of CPU
Graphics advantage is evident under Windows. Under Windows NT, I do not know if graphics are managed by
a special kernel thread, or something equivalent.
>
>
> > 4) X-Window is slower, because when you send it a primitive, it is
> > marshalled, sent to a socket, unmarshalled, and then managed by the X server.
>
> Most of the data (pixmaps) are locally transferred using shared memory.
Yes, but primitives does not use shared memory. When a window must be redraw, it send
a lot of line, rectangle, pixmap, font drawings. I think if the primitive stream sent
each time a window is redraw was cached by the X-server, drawing speed with X could
greatly improve.
>
>
> > 7) Graphics application under Linux may be slower, because of not using the
> > special instructions of x86 processors (MMX, SSE, etc.).
>
> All the Linux video players I've seen (Mplayer, Xine, etc.) have *heavily* optimized using assembly. Even Gdk-Pixbuf contains MMX code.
> And how much difference does it really make if MMX/SSE/3Dnow is used in drawing static graphics? Windows are only drawn once every expose, and CPUs these days are 2+ Ghz.
>
You are completely right. I didn't say that -no- application use MMX/SSE/3Dnow. For example, reading
a DivX ;-) movie with mplayer under Linux is faster than reading the same DivX under Windows XP,
even if you use the -same- codec (on my PII-400).
>
> > They can't because they must be compiled on other processors than the x86
> > ones.
>
> All you have to do is
> #ifdef PENTIUM_MMX
> // optimized assembly code
> #else
> // portable C/C++ code
> #endif
Yes. If you have time... And this kind of optimizations is mainly needed in video codecs, image effects
and sound effects. Using them under other free software seems to be recent.
Maybe under a fast machine (like I do not have), the bottleneck is more in
disk access and library loadings, and on slow machines it is in graphics
drawing.
But the slowness of kde is not only in the graphics and in the loading of applications. Try suppressing 1000 files in a directory or move 1000 files from a directory to another, under windows or in a shell under linux, it is going fast (time measures in second). Under Konqi, it needs several 10 minutes, especially to move the files.
You will tell me that we do not move 1000 files every day. But I do.
I am really disturbed by all these talks. I use KDE and love using it, the brilliance it adds to the functionality, the integrated file and web browsing... I have a PIII 667MHz with 64 MB RAM, and KDE has been working well on this machine. Applications take some time to load, but once loaded they are fast. Will I get a similar performance with KDE3 which I am going to upgrade to, or is KDE3 significantly slower than KDE2. But sure, from my experience with many desktops I have used I can tell KDE is simply the best. Windows Desktop and the whole OS are only toys compared to KDE/Linux
> Moving the mouse takes about 2.5% of CPU
> Moving a window with contents easily takes 30% of CPU
I really hate it when people talk about how much CPU% a process takes up.
Any running process, no matter how simple, will take up 100% of CPU time for the duration it is running.
plain CPU usage is one of the most pointless measurements there is.
_Average_ CPU usage over X seconds where X is actually mentioned along with the CPU usage does mean something, but a CPU usage number on it's own means nothing.
> All you have to do is
> #ifdef PENTIUM_MMX
> // optimized assembly code
> #else
> // portable C/C++ code
> #endif
And this code will not get used by most people, since none of the common binary distros requires a MMX-capable CPU on IA-32 targets. The right way to do this is with CPUID and runtime testing.
A small question. Is it possible to put the trash-icon in KDE onto the panel and then use it from there with all the functionality? Even in real life, I prefer not putting the trash onto my desk.
LOL. Funny off-topic :-)
Just drag and drop it from desktop to kicker.
It looks to work on my system
hehe... good one :o)
What exactly does tounge-in-cheek mean?
Johnny,
http://www.dictionary.com/search?q=tongue-in-cheek
It means jokingly or not seriously.
Cheers,
GK
Thanks! I even managed to spell it wrong. ;)
help
What kind of help do you need:
a) physical
b) mental
c) emotional
d) all of the above
It's just something that bloody idiots that can't spell say when they're quipping.