Published at LXer:

Linux is fast. That's why 90%+ of the Top 500 fastest supercomputers run it. What some people don't realize is that Linux is much better at delivering speed for servers and supercomputers than it is on the desktop. That was by design. But over the last few years, there's been more interest in delivering fast desktop performance. Now there's a Linux kernel patch that may give you a faster, much faster, desktop experience.

Read More...

Cool!

I will install the kernel when the patch is merged.

So what exactly does this apply to? Just overall graphical responsiveness? One little pet peeve I've always had with GTK+ in particular is that it seems rather CPU-time-hungry when it comes to anything involving smooth movement (scrolling, resizing, etc.), at least on 32-bit systems...I don't seem to have that problem (in as many situations) on my 64-bit lappy (and no this isn't because I'm reading the CPU graph/percentage wrong...I know that 100% on a single-core CPU is 25% on a 4-core CPU or MT dual-core). This could be due to the fact that it's callback-driven...but are other graphical toolkit APIs the same way? And moreover, is this part of what the new kernel patch is supposedly going to help fix when it's merged?

Well Qt (at least on KDE) is *REALLY* unresponsive (even more so than GTK+) on my 32-bit Atom netbook. Yes, I do get occasional hangs/crashes in GNOME -- but even then, they only occur when Compiz and visual effects are enabled. I think the reason why KDE is so unresponsive is because (especially with version 4) it is bloated like Windoze Vi$ta.

Hopefully this patch will fix KDE's unresponsiveness.

This patch will group applications to the TTY they are started from, so that you can start a on the kernel, and can browse the web and it will be snappy. KDE, and all other desktops, have to be fitted to this patch, to get its full potential. In the demo video from Phoronix, the moderator has started all apps (kernel compile, HD-video, browser) from different TTYs to demonstrate the patch on his 6-core Core i7 970. How much performance the "normal" desktop user will gain has to be tested.

There seems to be an alternative that is usable now and don't need any kernel patch. According to the link on that side to the LKML it seems to be even better. http://www.webupd8.org/2010/11/alter...nel-patch.html

I definitely would go with this patch though. However, I don't use KDE anymore -- I think GNOME (along with the Unity, panel, or GNOME 3 shells) is much faster than KDE, not to mention more customizable. You can have it as minimal or as full-featured as you wish.

However, I think either Xfce or LXDE are much better bets -- and it would be even better to create a DE out of nothing more than (very unbloated) Compiz plugins that serve as widgets. If I only knew what programming language Compiz plugins are written in and how easy they are to create.

You don't need to program to make your own DE (OK, may be a little bit scripting). I always make it, when I make a new install. First a Debian minimal install, then adding Xorg, Openbox and then all the apps I want to use. The picture below is how my laptop is actually looking. It is Openbox, xcompmgr (I use compositing only for transparent terminals), Conky and AWN, with all my favorite apps, mostly started with hotkeys (the Windows-key has a function on my systems).

I can't help be reminded of the patches from Andrew Morton (-mm patches). I wonder if Linus this time will actually consider incorporating desktop patches of this kind. Andrew Morton's patches had the exact same goal, but from what I can remember never really adopted into the mainline kernel tree, and remained an 'unofficial' patch. http://www.kernel.org/patchtypes/mm.html

C/C++ according to Wikipedia.

Last time I looked (which was a while ago, mind you), there was little/no documentation on how Compiz's plugin structure works from a programmer's perspective. Things *may* have changed for the better, though...I don't know.

Just one thing I'd like to add...I don't actually know if this means what I think it means, but I have a guess as to why CPU usage seems to be "lower" on my lappy than on either of my desktops when I'm doing something that involves smooth graphical movement (in software only, that is): instruction cache size. Probably has to do with speed overall, actually...

My lappy's Core i5 has a 32 KiB L1 cache, 256 KiB L2 cache, and 3 MiB L3 cache, whereas the Pentium 4 in the machine I'm writing this post from has only an 8 KiB L1 cache and a 512 KiB L2 cache. Doesn't this mean the poor P4 has to fetch instructions from memory way more often than the i5? Or am I just blindly guessing here?

EDIT: I think I might actually be right about this one...Wikipedia seems to confirm my own ideas as to what the heck the L1/2/3 caches actually are.

With newer processors I always check the cache size, it may actually be more important than the processor speed / frequency. Technically I also check FSB, which for sure is more important than processor speed.

FSB > Cache > Freq

I've always figured that operating frequency isn't the primary measure of processor performance. For example, GPUs typically run at lower clock speeds than CPUs, but they're more parallelized(?), so in many tasks they can be faster than general-purpose CPUs.

Intel Core i5 430M: 2.27 GHz
Intel Pentium 4: 2.66 GHz

...and yet the Core i5 is many times faster. Hmm, I wonder why? Might have something to do with the fact that it has two physical cores, multithreading (for two more "virtual cores"), and much bigger internal caches.

There are a few factors determining the processor's performance, like H_TeXMeX_H already said, FSB and cache are very important.
Another thing particular to Pentium 4s is their huge instruction pipeline which turns out not to be very effective since a lot of time is wasted when the pipeline stalls.
Pentium 4s also had a relatively small cache size when compared to today's CPUs.

About cache: it will effectively limit what your CPU can do. There is no point having a blazingly fast CPU if it has to sit and wait for data from slow RAM.
Even though many newer processors have large caches (and many cores), badly written software can thrash the cache and negate any performance gains that could have been obtained.

So basically good performance comes from hardware that's really just a bunch of hacks to compensate for limitations in our technology, and from well written software that does an overly elaborate balancing act on this hardware