The Linux desktop is about to get a LOT faster

[Samuel Thurston]

On Thu, Nov 18, 2010 at 7:16 AM, Basil Chupin <blchupin at iinet.net.au> wrote:
> On 18/11/2010 16:41, Fred A. Miller wrote:
>
> http://www.zdnet.com/blog/hardware/the-linux-desktop-is-about-to-get-a-lot-faster/10372?tag=nl.e589
>
> Sorry, but it doesn't do a thing for me.

Can you explain how you know? first that you're certain the patch is
enabled on your running kernel and second that you've done LATENCY
testing (during a kernel build, or similar overhead situation) to
indicate that it doesn't do "a thing"?  Or is this just a feeling that
you have?

>
> If the second "test" showed the exact same input as used in the first video
> then there could be something to think about.

You can see pretty clearly that the same stuff is going on...
glxgears, phoronix test suite, kernel compile, dvd video and a
browser. So it is certain there _could_ be something to think about,
by your own admission.

>
> Right now I can video something and then speed it up on playback to show
> that it is all "works" faster.

That's true, however that's neither what you see happening in that
video, nor would it be consistent with what the patch claims to do.

You can watch the terminal output of the kernel compile going on for a
time reference.  The object files are consistently compiling at
roughly the same speed in both videos.  The difference between the two
is the movement of the 3rd window when both video and compile job are
running-- specifically the visibly improved repaint speed on the areas
where the window just "was."  Compile speed is not significantly
improved... what is improved by the patch is the scheduling of the
other processes to improve the latency response of the user interface.

Following the link from the article to Mike Galbraith's patch
submission to lkml (
http://marc.info/?l=linux-kernel&m=128978361700898&w=2 ) explains that
it isn't seeking for raw performance gains, but rather for
interactivity in high-overhead situations.

What I find most confusing about your last comment, however, is that
you seem to be accusing Phoronix (poster of both videos in the
article) of possible chicanery.  I can't fathom what interest a Linux
benchmarking company would have in claiming a benefit for a kernel
patch, when there is in reality no benefit.  There's no shortage of
hackers to debunk such a claim, were it in fact false... why would a
company like Phoronix that makes its money from its reputation risk
that reputation for something which, in the scheme of things, is
fairly inconsequential?

TL;DR:  You're probably looking at the wrong situation for
improvement, and there's no reason for an independent testing company
to fake it.

Regards,
Sam