Dennis Forbes on Pragmatic Software Development
Subscribe to RSS
 
Tuesday, September 04 2007

A recent article on the utility of multiple cores has been making the rounds. Despite being largely a copy/paste of other articles and graphics, with a smidge of editorial commentary, it is anxiously heralded by dual-core owners as purchase justification in the face of progressing technology.

[As fair disclosure, let me say that I'm about to purchase a quad-core processor based system, and this article and its sources did absolutely nothing to dissuade me from this choice]

The meat of the article (or rather the articles that are referenced by the article -- someone else did the dirty, arduous footwork work of benchmarking) is comprised of a showdown between a 2.4Ghz quad-core and a 3.0Ghz dual-core, which is reasonable given that they're comparable in price [at writing the 3.0Ghz dual-core E6850 can be had for $384 CDN, while the 2.4Ghz quad-core Q6600 is $319 CDN]. Given that many games and applications are effectively single-threaded as a legacy of lowest-common denominator development, the faster clock speed dual-core processor abstractly takes the lead in such fundamentally synthetic benchmarks for the pricepoint.

Aside from the questionable "it's good to have one extra core to allow you to kill bad processes" premise (what if those bad processes are multithreaded? Do you just have to buy bad-process-threads+1 cores? Maybe set the affinity such that you've dedicated a core solely for the task manager? In the real world of modern schedulers, the only time you can't get control of the machine to kill a rogue process is because of some absolutely atrocious elements of the implementation of Windows, and a scheduler that is effectively broken in the face of some situations. Neither is necessarily improved by more cores), what really gets me about the whole exercise is how utterly synthetic it really is, using contrived benchmarks instead of rationally considering how people actually use their PCs, and where their real need for more power comes from.

Firstly, it largely focuses on games benchmarks. Even if gaming performance is pertinent to the reader, for the majority of users playing the majority of games, their video card is far more of a bottleneck than their processor (even if their processor is a dated affair). I'm saying this as a long time computer gamer -- one that finds the stuttering framerate on even top of the line game consoles intolerable: unless you've turned every quality setting to low and you're running at 800x600, it's doubtful that you're going to even measure, much less notice, a difference between a modern 2.4Ghz core and a 3.0Ghz core. Indeed, the very first benchmark I looked at on the referenced article says exactly that: "For this test, we set Oblivion's graphical quality to "Medium" but with HDR lighting enabled and vsync disabled, at 800x600 resolution". They did that to create a scenario where the differences are measurable.

So if you plan to game in a contrived way for the purposes of demonstrating CPU differences in benchmarks, then you'd better pay attention to core speed.

In the real world of gaming, after you've adjusted the quality and resolution settings to appropriate settings for your video card, the primary slowdowns during gaming tend to come about because of external applications rudely stealing your thread quanta: I'm about to toss the grenade into the bunker in Battlefield 2 when suddenly Windows Search has decided that this is a good time to rebuild its index corpus, for instance, so instead it falls to the ground and I take out my entire squad (Seriously, Windows Search guys - when a full-screen DirectX game is running, it probably isn't a good time to decide that the PC is "idle").

For moments like that, more cores make a huge difference. Dual-cores would be sufficient for that simple scenario, but what if my PC is even more active, as it always is? Perhaps the blog updater is running an update, I'm FTPing some files, a download is happening, and I'm gaming.

Every core works towards the ultimate goal of eliminating the real world problem of cycle theft from my hardcore gaming.

Presuming that you've passed a reasonable bar -- long behind you when you're talking about a 2.4Ghz Core 2 -- more cores will realistically improve things for gamers enjoying their vice in the real world. One day we might even have a world where we don't have to shut down services and trawl taskmanager violently killing processes before launching a game, fearful that it will disrupt our immersion.

My second problem with the article is that it doesn't question what people are really waiting for nowadays. Personally I see almost no difference between virtually any mainstream PC for the overwhelming majority of day to day operations (and this is as a developer) -- most activities are so fast the difference is negligible. I just switched laptops from a single-core 1.6Ghz Pentium M to one with a Core 2 Duo T7200 -- a significant improvement -- and from a day to day perspective I've indeed notice that the new laptop has a better screen, a faster harddrive, and much better graphics, but the computational difference is largely unnoticed.

Until, humorously, I do something that is highly parallelizable, such as encoding a video pulled in from the miniDV video camera. In that case the dual-core processor strides to a massive lead over its single core predecessor. If it were a quad-core, it would storm even further ahead, even with the loss of frequency.

For something that I'm actually waiting on, more cores = more goodness.

I would definitely choose the quad-core processor for the software reality legacy that we have today, despite the many applications that in the singular fail to exploit the possibility. My conviction is amplified by the tremendous strides that application developers are making to parallelize their products. Once you've parallelized to 2 cores, it's generally a very small step to parallelize to 4 cores, or n cores for that matter.

Bring on the cores!

Reader Comments

> Once you've parallelized to 2 cores, it's generally a very small step to parallelize to 4 cores, or n cores for that matter.

What evidence do you have to support this statement?

The point of quoting all the benchmarks was to provide evidence for my claim that beyond 2 cores, it is VERY difficult for software to make use of 4+ cores. (Except in the specialized realm of encoding or rendering, which are both naturally amenable to parallelization.)
Jeff Atwood @ 9/4/2007 5:33:57 PM
>What evidence do you have to support this statement?

Evidence? It's an obvious facet of software development.

>The point of quoting all the benchmarks was to provide evidence for my claim that beyond 2 cores, it is VERY difficult for software to make use of 4+ cores

It was pretty unconvincing evidence, given that you've completely left out *single* core results. If four cores show little differentiation from two cores, I'll wager that for the same test there would be marginal difference between 2 and 1 core either, yet those numbers are completely missing. Now there may be a *small* natural advantage for single-threaded apps given that you get the advantage of cheap multithreading via overlapped I/O and the like (where the OS can offload its portion to a second processor), but that's fairly minor.
Dennis Forbes @ 9/4/2007 6:02:16 PM
> Despite being largely a copy/paste of other articles and graphics
> The meat of the article (or rather the articles that are referenced by the article -- someone else did the dirty, arduous footwork work of benchmarking)

I can't help feeling your blog entries deteriorate in quality when you discuss articles on Coding Horror, to the point where it distracts from the message you are trying to get across.
Dabbo @ 9/6/2007 11:39:24 AM
A very good day to you Dabbo.

Fair point. Indeed, content that largely consists of commentary about other people's commentary (as opposed to original research and content) is almost always low quality.

But it's easy. So very very easy.

It's very easy to whirl off a 1000 word comment-about-something-someone-else-said entry in minutes. Creating the same amount of original content from scratch would take hours. During the summer doldrums sometimes I guiltily admit to resorting to the former.
Dennis Forbes @ 9/6/2007 3:32:59 PM
> [Once you've parallelized to 2 cores, it's generally a very small step to parallelize to 4 cores] is an obvious facet of software development.

I think it's far less obvious than you make it out to be, otherwise all the benchmarks would show reasonable scaling from 2 to 4 cores. If it's so obvious, why isn't it happening?

> I'll wager that for the same test there would be marginal difference between 2 and 1 core either

True, but those benchmarks can be found lots of places. The single to dual jump is almost always 10% or more, regardless of application. Not quite "marginal" but enough to say there's some tangible benefit. As I said in the introduction, I think the move from single to dual-core has clear benefits for almost every user.

Whereas 2 to 4 core often produces literally 0% speed improvement.

> It's very easy to whirl off a 1000 word comment-about-something-someone-else-said entry in minutes.

As I see it, not all entries have to be 100% original content. I have no problem citing other people's excellent work and presenting it in a scannable fashion. This way it gets even more exposure for the excellent work that it is. Win-win.

Some excellent links on this:
http://www.knowing.net/CommentView,guid,e5aadb98-0a69-44e3-94cb-0afa583b0c0e.aspx

http://globalnerdy.com/2007/07/19/insights-gained-from-yesterdays-laws-of-software-development-article/
Jeff Atwood @ 9/7/2007 7:13:11 PM
Hey there Jeff.

>If it's so obvious, why isn't it happening?

What I indicated was obvious was that once you've started parallelizing, aside from occasional domain-specific limits in partitions, it's usually 1 thread, or n possible threads. Many developers still develop for the 1 thread model, which is why some compilers are trying to get smart enough in parallelizing what would otherwise be a single thread of execution.

>True, but those benchmarks can be found lots of places. The single to dual jump is almost always 10% or more, regardless of application.

I'm not so sure about that -- when dual cores first came out (before that when performance freaks bought into SMP dual-processor boards), there were *plenty* of artificial single-tasked-computer benchmarks posted by plenty of sites that demonstrated little or no gain with the second core/processor. Many of those benchmarks look extraordinarily similar to the 2->4 core benchmarks, and the gainers were virtually the same as well.

Of course it's a bit more difficult now given that I don't think you can even get a Core 2 with a single processor (though one could set the affinity to ignore the second core), however I repeat that I think that the same tests that showed little or no advantage from 2 to 4 would show little or no gain from 1 to 2.

>As I see it, not all entries have to be 100% original content.

Totally agree.
Dennis Forbes @ 9/8/2007 9:56:50 AM
> Fair point. Indeed, content that largely consists of commentary about other people's commentary (as opposed to original research and content) is almost always low quality.

Ironically I think you missed my point and did the same again, but nevermind. The subject and discussion are interesting, but not the poking at blogging styles... again... and again.
Dabbo @ 9/10/2007 6:43:39 AM
>Ironically I think you missed my point and did the same again

Hey there Dabbo. I'm sensing that you think that my comments relate to another as some sort of passive-aggressive criticism. They aren't. They are 100% internally directed, the point being that I find it much easier to pick at blogging styles, etc, when I don't have as much time or inclination to focus on posts.
Dennis Forbes @ 9/10/2007 8:36:42 AM
Not sure passive-aggressive is the right phrase, but yes you do seem to drop less than subtle critical comments about CodingHorror's blogging style rather than simply focusing on the content of the article. The fact I've wasted time returning to discuss this indicates how distracting it is. I'll stop now.
Dabbo @ 9/10/2007 4:44:11 PM

Add Comment

Name *:

Email Address:

(your email address is not displayed)
Website:

Comment *:


Dennis Forbes - Dennis Forbes is a Toronto-based software architect and technology writer