LinuxQuestions.org
LinuxAnswers - the LQ Linux tutorial section.
Go Back   LinuxQuestions.org > Forums > LinuxQuestions.org > Linux - News > Syndicated Linux News
User Name
Password
Syndicated Linux News This forum is for the discussion of Syndicated Linux News stories.

Notices

Reply
 
Search this Thread
Old 11-17-2010, 09:20 AM   #1
LXer
LXer NewsBot
 
Registered: Dec 2005
Posts: 73,448

Rep: Reputation: 82
LXer: The Linux desktop may soon be a lot faster


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...
 
Old 11-18-2010, 07:26 AM   #2
dv502
Member
 
Registered: Sep 2006
Location: USA - NYC
Distribution: Whatever icon you see!
Posts: 642

Rep: Reputation: 57
Cool!
 
Old 11-18-2010, 07:36 AM   #3
H_TeXMeX_H
Guru
 
Registered: Oct 2005
Location: $RANDOM
Distribution: slackware64
Posts: 12,928
Blog Entries: 2

Rep: Reputation: 1269Reputation: 1269Reputation: 1269Reputation: 1269Reputation: 1269Reputation: 1269Reputation: 1269Reputation: 1269Reputation: 1269
I will install the kernel when the patch is merged.
 
Old 11-18-2010, 08:15 AM   #4
MrCode
Member
 
Registered: Aug 2009
Location: Oregon, USA
Distribution: Arch
Posts: 864
Blog Entries: 31

Rep: Reputation: 147Reputation: 147
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?

Last edited by MrCode; 11-18-2010 at 08:24 AM.
 
Old 11-18-2010, 08:42 AM   #5
Kenny_Strawn
Senior Member
 
Registered: Feb 2010
Location: /usa/ca/orange_county/lake_forest
Distribution: ArchBang, Google Android 2.1 + Motoblur (on Motortola Flipside), Google Chrome OS (on Cr-48)
Posts: 1,791
Blog Entries: 62

Rep: Reputation: 54
Quote:
Originally Posted by MrCode View Post
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.
 
Old 11-18-2010, 12:29 PM   #6
TobiSGD
Moderator
 
Registered: Dec 2009
Location: Hanover, Germany
Distribution: Gentoo
Posts: 15,438
Blog Entries: 2

Rep: Reputation: 4001Reputation: 4001Reputation: 4001Reputation: 4001Reputation: 4001Reputation: 4001Reputation: 4001Reputation: 4001Reputation: 4001Reputation: 4001Reputation: 4001
Quote:
Originally Posted by Kenny_Strawn View Post
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
Code:
make -j64
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.
 
Old 11-18-2010, 04:46 PM   #7
TobiSGD
Moderator
 
Registered: Dec 2009
Location: Hanover, Germany
Distribution: Gentoo
Posts: 15,438
Blog Entries: 2

Rep: Reputation: 4001Reputation: 4001Reputation: 4001Reputation: 4001Reputation: 4001Reputation: 4001Reputation: 4001Reputation: 4001Reputation: 4001Reputation: 4001Reputation: 4001
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
 
Old 11-18-2010, 05:18 PM   #8
Kenny_Strawn
Senior Member
 
Registered: Feb 2010
Location: /usa/ca/orange_county/lake_forest
Distribution: ArchBang, Google Android 2.1 + Motoblur (on Motortola Flipside), Google Chrome OS (on Cr-48)
Posts: 1,791
Blog Entries: 62

Rep: Reputation: 54
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.
 
Old 11-18-2010, 07:37 PM   #9
TobiSGD
Moderator
 
Registered: Dec 2009
Location: Hanover, Germany
Distribution: Gentoo
Posts: 15,438
Blog Entries: 2

Rep: Reputation: 4001Reputation: 4001Reputation: 4001Reputation: 4001Reputation: 4001Reputation: 4001Reputation: 4001Reputation: 4001Reputation: 4001Reputation: 4001Reputation: 4001
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).

 
Old 11-18-2010, 08:50 PM   #10
Jeebizz
Senior Member
 
Registered: May 2004
Distribution: Slackware 14.1 64-bit with multilib
Posts: 2,074

Rep: Reputation: 193Reputation: 193
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
 
Old 11-19-2010, 04:44 AM   #11
MrCode
Member
 
Registered: Aug 2009
Location: Oregon, USA
Distribution: Arch
Posts: 864
Blog Entries: 31

Rep: Reputation: 147Reputation: 147
Quote:
Originally Posted by Kenny_Strawn
If I only knew what programming language Compiz plugins are written in
C/C++ according to Wikipedia.

Quote:
...and how easy they are to create.
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.
 
Old 11-21-2010, 08:30 AM   #12
MrCode
Member
 
Registered: Aug 2009
Location: Oregon, USA
Distribution: Arch
Posts: 864
Blog Entries: 31

Rep: Reputation: 147Reputation: 147
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.

Last edited by MrCode; 11-21-2010 at 08:34 AM.
 
Old 11-21-2010, 08:50 AM   #13
H_TeXMeX_H
Guru
 
Registered: Oct 2005
Location: $RANDOM
Distribution: slackware64
Posts: 12,928
Blog Entries: 2

Rep: Reputation: 1269Reputation: 1269Reputation: 1269Reputation: 1269Reputation: 1269Reputation: 1269Reputation: 1269Reputation: 1269Reputation: 1269
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

Last edited by H_TeXMeX_H; 11-21-2010 at 08:51 AM.
 
Old 11-22-2010, 01:30 PM   #14
MrCode
Member
 
Registered: Aug 2009
Location: Oregon, USA
Distribution: Arch
Posts: 864
Blog Entries: 31

Rep: Reputation: 147Reputation: 147
Quote:
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.
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.

Last edited by MrCode; 11-22-2010 at 01:31 PM.
 
Old 11-22-2010, 01:53 PM   #15
easuter
Member
 
Registered: Dec 2005
Location: Portugal
Distribution: Slackware64 13.0, Slackware64 13.1
Posts: 538

Rep: Reputation: 62
Quote:
Originally Posted by MrCode View Post
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

Last edited by easuter; 11-22-2010 at 01:56 PM.
 
  


Reply


Thread Tools Search this Thread
Search this Thread:

Advanced Search

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
LXer: Linux 2.6.30 Gets Faster Boot - but is Fedora Faster? LXer Syndicated Linux News 0 06-11-2009 04:40 AM
LXer: Firefox 3.5 Speed Freak: Faster Development, Faster Performance LXer Syndicated Linux News 0 06-10-2009 02:42 AM
LXer: Firefox 3 Beta 4 is 5x faster than IE7, 3x faster than FF2 LXer Syndicated Linux News 0 03-12-2008 05:50 PM
LXer: Build a faster desktop with RAID LXer Syndicated Linux News 0 01-18-2008 12:51 AM


All times are GMT -5. The time now is 04:24 PM.

Main Menu
My LQ
Write for LQ
LinuxQuestions.org is looking for people interested in writing Editorials, Articles, Reviews, and more. If you'd like to contribute content, let us know.
Main Menu
Syndicate
RSS1  Latest Threads
RSS1  LQ News
Twitter: @linuxquestions
identi.ca: @linuxquestions
Facebook: linuxquestions Google+: linuxquestions
Open Source Consulting | Domain Registration