Commentary

Serdar Yegulalp
 

Red Hat In Boston, Part 1.1: Why 'Faster' Isn't Always Faster

My first actual panel for the opening day of the Red Hat Summit sported the eye-grabbing moniker Why computers are getting slower (and what we can do about it). With a title like that, I was worried I'd be in for a fluff panel about spyware 'n viruses on Windows being performance killers, with Linux as the panacea for that. I couldn't have been more wrong, thank goodness.

My first actual panel for the opening day of the Red Hat Summit sported the eye-grabbing moniker Why computers are getting slower (and what we can do about it). With a title like that, I was worried I'd be in for a fluff panel about spyware 'n viruses on Windows being performance killers, with Linux as the panacea for that. I couldn't have been more wrong, thank goodness.


More Software Insights

White Papers

More >>

Reports

More >>

Webcasts

More >>

Rik van Riel, senior software engineer for Red Hat, braved multiple interruptions by a hair-trigger fire-alarm system to tell us how, as counterintuitive as it might seem, faster components may lead to slower systems. The size and speed of your hard drive hasn't kept pace with the amount of data being retrieved from it and, no thanks to Moore's Law, the age of what van Riel called "hardware miracles" is pretty much over. From here on out it's an arms race -- hardware advances being unable to keep pace with the increasing demands put on them.

So what's the solution to this mess? Parallelism alone won't fix everything -- you can throw more cores at a problem, sure, but at the risk of introducing context-switching overhead and other delays into the mix. Van Riel highlighted several key areas where users, application authors, and Linux kernel/OS devs can all make improvements. One, changes to the scheduler -- for instance, to consolidate threads to a single core during idle periods so that the unused cores can be powered down. This goes hand in hand with other recent kernel developments, like the "tickless" kernel, to reduce the number of times the kernel has to poke the system to see if anything's up.

The best thing about the panel was a lot of agreement from the audience -- many of whom were doing kernelspace work of their own -- that what seems like a performance improvement on the surface may turn out to just make things worse. If you throw more memory at a system via NUMA, for instance, you may simply be taking work that is handled best in a single block, scattering it, and creating whole new kinds of latencies. (Plus, on the open source side, if you deal with these problems out in the open instead of behind closed doors, the tide you raise will lift all boats -- even the ones you're not riding in.)


Related Reading




Currently we allow the following HTML tags in comments:

Single tags

These tags can be used alone and don't need an ending tag.

<br> Defines a single line break

<hr> Defines a horizontal line

Matching tags

These require an ending tag - e.g. <i>italic text</i>

<a> Defines an anchor

<b> Defines bold text

<big> Defines big text

<blockquote> Defines a long quotation

<caption> Defines a table caption

<cite> Defines a citation

<code> Defines computer code text

<em> Defines emphasized text

<fieldset> Defines a border around elements in a form

<h1> This is heading 1

<h2> This is heading 2

<h3> This is heading 3

<h4> This is heading 4

<h5> This is heading 5

<h6> This is heading 6

<i> Defines italic text

<p> Defines a paragraph

<pre> Defines preformatted text

<q> Defines a short quotation

<samp> Defines sample computer code text

<small> Defines small text

<span> Defines a section in a document

<s> Defines strikethrough text

<strike> Defines strikethrough text

<strong> Defines strong text

<sub> Defines subscripted text

<sup> Defines superscripted text

<u> Defines underlined text

InformationWeek encourages readers to engage in spirited, healthy debate, including taking us to task. However, InformationWeek moderates all comments posted to our site, and reserves the right to modify or remove any content that it determines to be derogatory, offensive, inflammatory, vulgar, irrelevant/off-topic, racist or obvious marketing/SPAM. InformationWeek further reserves the right to disable the profile of any commenter participating in said activities.

Disqus Tips To upload an avatar photo, first complete your Disqus profile. | View the list of supported HTML tags you can use to style comments. | Please read our commenting policy.
T-Shirt Giveaway T-Shirt Giveaway: Each week we're selecting one great comment from our readers. The author of the comment will receive an InformaitonWeek Community t-shirt. So get posting!
Subscribe to RSS

Resource Links