Dennis Forbes on Pragmatic Software Development
Subscribe to RSS
 
Friday, November 16 2007

The just released first-person shooter Call of Duty 4 hit store shelves a couple of weeks ago, targeting a variety of platforms, surprisingly including the PC. I grabbed a copy to supplement my Battlefield 2 outings -- I still enjoy the odd late-night frag-fest to ease me gently into sleep.

I was pleased to find it priced at <$50 at my local electronic superstore: 20 years ago, terrible games for a ColecoVision cost $70-$80, so it's amazing to pay less for such an incredible product. It's even more amazing after factoring in 20 years of inflation.

CoD4 is a remarkable feat of software engineering, demonstrating significant technical excellence. As a business-class software developer, it's a bit humbling. It's pretty clear that the team is extraordinarily capable. The game is riddled with remarkable details that are easy to miss, but they're so impressive you're surprised that they didn't stop the action and highlight it to make sure the player savoured every laboriously created effect.

Probably worth mentioning that It also happens to be a lot of fun to play!

Featuring unparalleled visuals, incredibly intense combat, an interesting and immersing storyline, and a lot of gameplay variety, the single player game has been a pleasant surprise. I usually skip the often trite single-player games in first-person shooters, heading directly online for some multiplayer combat. For this one the single-player game has captured every moment of the few chances I get to game.

It isn't a perfect game, though. Like many games in the genre, the player is tightly coralled along a heavily orchestrated path (standing in stark contrast with even dated games like Operation Flashpoint, which allowed the player to basically do whatever they wanted within the confines of the island). The game features invisible triggers that cause predictable outcomes: When I pass this line the two guys will appear behind that door, and then I'll move right and the guy will run out at the top and the five guys will march in the door at the end of the hall.

It does randomize to a small degree, but I can't imagine that there's a lot of replayability.

One noteworthy attribute of the PC version -- what inspired me to write about it on here given the various entries about quad-cores over the past while -- is its ability to scale out across multiple cores. The following is a graph of CPU usage on my otherwise unladen quad-core PC.

Call of Duty 4 Multicore CPU Usage

The drop-off at the end was the period of time while it switched out to the desktop so I could take a screenshot of the task manager. While actual gameplay was underway, the application consumed about 75% of 3 cores at times, peaking up to 75% on the fourth core, using this to apply the physics model used extensively throughout the game. Further evidence of the technical excellence is the fact that they didn't just spin out threads for each core and then busy wait for the duration (which would have fixed each at 100%) -- as many games sadly do (Netscape Navigator's download manager used to do that) -- but instead they have some finite amount of calculations they perform and then they properly yield to any other tasks on the system that might have work to do.

A brilliant game, making great use of modern hardware.

Related Entries
Monday, November 12 2007

Some recent hardware upgrades left one of my PCs in a fragile state: While I had managed to avoid the time sucking irritation of an OS reinstall over generations of hardware changes, the latest hardware swaps -- or rather wholesale migrations -- pushed the crufty stack of refusing-to-vacate legacy drivers and confused minibuses over the edge.

It had become a fragile platform, with frequent crashes and unexplained behaviour.

Not surprising, given that the OS install had seen the platform go through a myriad of trasitions, including from a VIA chipset to an nforce chipset to a VIA chipset and then back to an nforce chipset; from nvidia to ATI to nvidia graphics.

Really it had dealt with change remarkably well, at least relative to the tradition of Windows being tightly bound to the installation hardware, with the slightest deviation demanding a reinstall.

Like many users, I'd been avoiding Vista. Actually that isn't entirely true: It wasn't that I was avoiding Vista, but rather that the benefits it offered just weren't compelling. Not compelling enough to reinstall a working system, or even to deal with the inevitable dev team just had to move stuff around to set their fingerprint search for traditional features.

When Flip 3D is a highlighted feature, you know that things can't be that great.

Nonetheless, given that a rebuild was in order anyways, and given that a professional in this field should generally ride the leading the edge of technology (though nothing like the days of old -- once upon a time we had to eagerly consume every Microsoft beta as a necessity for job security, whereas nowadays technologies like WPF are a complete and utter non-issue in the general tech industry), I figured I'd force myself to embrace Vista, warts and all.

I'd eat my industry's dog food.

To make things more interesting, I decided to go full bore and install the x64 version of Vista. I had a fully 64-bit capable processor, and despite only having 2GB of RAM (with two slots eagerly waiting to be populated), it would nonetheless allow me to start playing around with the extended x64 instructions and registers.

x64 is much, much more than just bigger pointers, so I wanted to play around with them in my favourite development environment (like many such transitions, it will take a few years before the benefits of x64 are fully realized, though in the .NET world the 64-bit runtime immediately takes advantage of the new features for platform neutral assemblies.)

The install and transition went very well. While I had to disable UAC quickly to make the experience marginally pleasant (I'd experienced Vista enough in dual-boots and virtual machines to quickly learn to despise this security "feature"), generally it just went well.

On the modern nforce4-based motherboard (featuring onboard sound and networking, all drivers installed by the single package of nvidia drivers), with a Q6600 quad-core processor and contemporary nvidia video card, everything simply worked after running a couple of driver packages. Even my dual-layer DVD burner just worked. All of the attached Canon printers, including the multifunction with faxing and scanning, auto-installed and immediately worked. Visual Studio 2005 worked great with the Vista patch, and while it's a 32-bit app it capably generates great 64-bit builds. Awesome!

Now I had IIS 7 to play around with, getting ready for the same in the server sphere. The integrated pipeline and web.config based configuration really is a wonderful step forward for the platform.

Several things didn't work. CameraWindow won't work with my Canon Digital Rebel XT, though by switching to PictBridge on the camera I found that Vista itself did a great job downloading and organizing the photos (and Windows Photo Gallery is a universe better than the terrible "Picture and Fax Viewer", not just for navigating and organizing photos, but moreso because the venerable XP viewer did a horrible job resizing photos for display at monitor resolutions, managing to make great shots look terrible). The bundled burning software that came with my DVD drive wouldn't install, but I was delighted to find that Vista actually had pretty decent burning capabilities built in, competently writing 9GB backups to my DL discs.

I hadn't really exploited the benefits of the 64-bit address space at this point, but then I booted up a copy of Battlefield 2 for some late night mental-diversion fragging.

Imagine my surprise when this game that ran very well on a vastly less powerful 1GB XP system now yielded frequent stutters while significant memory paging occurred. Despite having twice the RAM to draw from in the rebuilt machine (if you add in the system baseline, it really had about 2.7x as much RAM to draw from), somehow it was now hitting the ceiling on a machine that was almost completely dedicated to it.

So I grabbed 2GB more PC6400 DDR2 from a local retailer, plugged it in, and with 4GB everything is running pretty smoothly. Another $120 to upgrade the memory to have the same experience that I had with 1/4 the memory in XP.

Vista was hardly a surprise to me given that I'd been playing with it in various forms since the Longhorn days, and the technical feature list is entirely underwhelming compared to the early vaporware promises, however it isn't the travesty many are making it out to be. While it definitely needs work, it isn't going anywhere, and Microsoft isn't going to rollback to XP.

If you have modern, supported hardware, Vista x64 is a solid choice.

Tuesday, November 06 2007

I recently opted to throw together my own blog software (after going through the standard Build or Buy analysis), expediting deployment as a means of forcing follow-thru. The goals of this micro-project were to improve the authoring and content management experience, to improve searchability of the content (without having to cast content out from the blog to a static form), and to improve the usability and navigation from the user's perspective (for instance the classic "date" navigator common on most blogs is something that I've opted to remove).

Despite having close to no time to allocate to this task, my tendency to over-engineer still showed through: The easiest option would have been a content-management system defined entirely in code (it's as easy for me to change and deploy code than it is to change templates and metadata), and of course to build it for a single author. Instead it supports many blogs through the same URLRedirector, blog aggregations (where a blog is a publication of a set of blogs, each with distinct authors) each using its own templates and configurations.

Which brings me to templates -- failing to find a decent Smarty-type templating system for .NET (basic ASPX is really a templating system, but I'm speaking more towards something that can enumerate sections, retrieving data based upon an object structure of relationships and containment).

So I had to build a basic templating system, yielding the templates that follow. The first for HTML output--

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" 
   "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8"></meta>
<title>{#blog.Title} {#docTitle}</title>
<link rel="stylesheet" type="text/css" media="screen, projection" 
   href="http://www.yafla.com/dforbes/style/css/blog.css"></link>
<script type="text/javascript" src="http://www.haloscan.com/load/dforbes"> </script>
</head>
<body>
<div class="clsHeader">
<div class="clsBlogHeader"><a href="{#blog.BaseUrl}">{#blog.Title}</a></div>
<div class="clsSubheader">{#blog.Description}</div>
</div>
<div class="clsBody">
{foreach $entry in $entries}
<div class="clsEntry">
   <div class="clsDate">{#entry.EntryContent.PublishDateUTC|dddd, MMMM dd yyyy}</div>
   <div class="clsTitle"><a href="{#entry.Permalink}">{#entry.EntryContent.EntryTitle}</a></div>
   <div class="clsBody">{#entry.EntryContent.EntryContent}</div>
   <div class="clsKeywords">{foreach $keyword in $entry.EntryKeywords}&nbsp;
      <a href="{#blog.BaseUrl}{#keyword.KeywordText|escape}">{#keyword.KeywordText}</a>&nbsp;{/foreach}
   </div>
   <div class="clsPermalink">
      <a href="javascript:HaloScan('{#entry.MappingId}');" target="_self">
      <script type="text/javascript">postCount('{#entry.MappingId}'); </script></a>&nbsp;
      <a href="{#entry.Permalink}">permalink</a>
   </div>
{foreach $relatedentry in $entry.RelatedEntries}
{ifcond $LoopFirst = "True"}
<center>
<div class="clsRelatedEntries">
Related Entries
{/ifcond}
<div class="clsRelatedEntry">
   <a href="{#relatedentry.Permalink}">{#relatedentry.EntryContent.EntryTitle}</a>
</div>
{ifcond $LoopLast = "True"}
</div>
</center>
{/ifcond}
{/foreach}
</div>
{/foreach}
<div class="clsAdBlock">
{#adBlockHorizontal}
</div>
<div class="clsNavigator">
   <span class="clsNavigateEarlier">{#moveEarlier}</span><span class="clsNavigateLater">{#moveLater}
   </span>
</div>
</div>
<br/>
<div class="clsAttribution">
   <a href="mailto:{#entry.EntryContent.ContentAuthor.EmailAddress}">
      {#entry.EntryContent.ContentAuthor.Name}
   </a> - 
   {#entry.EntryContent.ContentAuthor.Description}
</div>
</body>
</html>

The next template is for RSS consumers--

<rss version="2.0">
  <channel>
    <title>{#blog.Title|escape}</title>
    <link>{#blog.BaseUrl}</link>
    <description>{#blog.Description|escape}</description>
    <lastBuildDate>{#buildDate|r}</lastBuildDate>
    <language>en-us</language>
		{foreach $entry in $entries}
		<item>
		  <title>{#entry.EntryContent.EntryTitle|escape}</title>
		  <link>{#entry.Permalink}</link>
		  <guid>{#entry.Permalink}</guid>
		  <pubDate>{#entry.EntryContent.PublishDateUTC|r}</pubDate>
		  <description><![CDATA[{#entry.EntryContent.EntryContent}]]></description>
		</item>
		{/foreach}
  </channel>
</rss>

All in all, I think it works pretty good, and I can successfully run the W3C validations on the vast majority of generated pages and get the comforting green checkmark.

Tuesday, October 30 2007

My original foray into the land of blogging was delayed while I stumbled towards the goal of building my own blogging software: like many software developers, I have a sometimes irrational desire to build it myself rather than admit “defeat” and use one of the many (and in the realm of blogging, there are many) available products.

I took a couple of stabs at building it myself originally, but due to another common foible – a tendency to over-engineer (I couldn’t simply write some blog software to post and publish my own thoughts. No…it had to be a full multi-author aggregation and collaboration suite, meaning that weeks went by while I mentally debated the database model for such a machination) – it just never seemed to get finished.

Other priorities always trumped it, and the little time I did allot towards this goal saw me solving absurd edge conditions.

I finally set a deadline for myself, and when I couldn’t find the time to finish anything before my marker (billable hours always came first), I went and bought a copy of Radio Userland and started publishing content the blog way.

That worked well enough for a while, but Radio Userland is a venerable publishing tool that is really showing its age. Authoring to it is a less than pleasant experience – which has been a huge contributor towards the dearth of content (it’s always a bit of a roll of the dice to see which characters it randomly replaces in posts, or which carefully authored HTML blocks it’s decided to mangle) – and simple tasks like cross-linking posts (e.g. a “related posts” sidebar to allow users to easily see follow-ups) was just far too manual to be worth the bother.

Now that I have a powerful, fully dedicated server, it’s also grossly under-featured for users, making the experience of consuming and navigating through the information far less usable than it should be.

So I’ve gone and built my own blogging software, this time quickly bringing it to a sort of beta release.

Given that this is the venue with which I will publicize a ton of changes elsewhere on the site, I really considered this a roadblock on the critical path to the release of other web application functionality elsewhere on yafla.

With some focus, it took only a couple of hours this time, mostly accomplished while putting my toddler son to bed over the weekend. It was so ridiculously quick and easy that I kick myself for not having done it sooner.

I’m extremely pleased about the functionality built out (hey it isn't rocket science, and definitely falls within the realm of "trivial", but there's lots of little "gotchas" with software like this), though most of the kudos go towards .NET 2 and SQL Server 2005: A couple of tools that make short work of what would once have been an enormous task, bringing a robust, secure, high performance web application to a usable stage in less time than it takes to watch the Lord of the Rings trilogy.

Right now you’ll probably notice that – at this moment at least – the HTML version of the blog looks absolutely terribly. That is somewhat by design (or rather an intentional time compromise)…momentarily. I’m working on the template (it’s of course parameterized template driven), and wanted to force myself to follow through by deploying (perhaps prematurely).

So what are the features of the blog software?

Well, firstly I migrated 100% of the old content over (including metadata such as categorization), running it all through Tidy first to try to make it a little more XHTML legitimate. Using an identifier mapping structure, every single link to the legacy content still works (which was important to me: I didn’t want to give link followers the frustrating “We moved everything so have fun trying to find it” 404 experience).

Everything works via URL remapping, and for now I’ve set it to redirect from old links to the new links where possible. E.g. http://www.yafla.com/dforbes/categories/softwareDevelopment/2005/09/28.html redirects to http://www.yafla.com/dforbes/Clean_Code. All new entries Will follow that more transparent and obvious structure.

But the URLs aren’t limited to just single documents – All entries in June of 2006 can be accessed via http://www.yafla.com/dforbes/2006/06. Add in a category and you can refine further – http://www.yafla.com/dforbes/2006/06/.NET (or http://www.yafla.com/dforbes/.NET/2006/06. Whatever makes you happy).

Want that in RSS form?   http://www.yafla.com/dforbes/2006/06/.NET/rss.xml.  Add in the day if you wanted to refine further.

Of course, no longer are entries limited to the archaic “categories”. Now they’re basically keywords, so if you want to see the posts where I’ve abused categories and multi-tagged, take a look at

http://www.yafla.com/dforbes/.NET/SQL/Blogging/SoftwareDevelopment/Personal/IT/

Yikes!

So the tagging will be much more logical now that there aren’t broad categories, and given that anyone can filter content however they want (stick rss.xml on the end and you can get a feed of whatever you want).

There’s also search, though I’m not comfortable enough with the finality of the API to publish anything about that.

Entries now have versioning, given that I want to be more transparent with edits that I make (I’m endlessly doing minor corrections and improving wording, and for those who consider that deceptive there’ll be a little version history to see what changed and when, along with a label of why the change was made). All links are auto-parsed and logged, so every entry has a list of posts that link into it, making for much more elegant self follow-ups without resorting to post-editing some “UPDATE: See also…“ notes into old entries, and without resorting to the ugliness of trackbacks.

Extensive caching ensures that it’s still spritely and capable of handling peak loads with no fuss.

Oh, and the system supports many blogs by many authors, including publishing multiple authors into one system…so I still over-engineered, but in the end it was workable and I’m extremely happy with the core structure.

Great things lie ahead.

Monday, September 17 2007

One of my PCs is a bit of a Frankenstein, having gone through countless small upgrades over the years.

A video card here. Some memory modules there. A replacement primary harddrive here (thank you g4u). A supplementary hard drive there. Half a dozen different CD and then DVD and then Dual-Layer DVD burners.

Every now and then it'd see a larger upgrade that mandated a motherboard replacement alongside a new CPU. Often that would require new memory modules as well. Maybe even a new power supply as connection standards changed.

Motherboard replacements have always been the most disruptive, and it's been interesting to watch as each has negated the need for some add-in or other. First the USB+firewire board got punted, having been replaced by onboard functionality. Then the network card. Then the Soundblaster card. The only true add-in card usually needed nowadays is the video card, and I'm sure it's only a matter of time before the on-board video reaches a credible level of performance, eliminating even that.

I've pursued this piecemeal approach to upgrading primarily because it minimized the software disruption in my life, usually requiring just a quick module swap, some driver updates, and it's up and running again. I actually enjoy the modular, hybrid-PC pursuit, individually scoping out and replacing components with the best bang-per-dollar option available at the time. It's a bit of a hobby.

[Clearly I'm not alone: A local "Tiger Direct" store opened recently in my town, featuring a huge floorspace stocked with esoteric power supplies, mod cases, and other components for DIY builders. I'm surprized that the demand is still there, having thought that the self-builder was an endangered species]

I've been negligent, however. Over the past while this PC had seen little attention. Running on an extremely dated Athlon XP 1800+ (overclocked to equal a 2200+), with a "measly" 1GB of DDR1 RAM and a dated collection of complimentary components, it had fallen so far behind the times that it has dropped far off the current CPU charts. While it served its casual gaming task well (the video card is quite contemporary, and given that few games are constrained by the CPU, it held its own), and admirably provided the network storage for photos and videos, its anemic standings were a bit embarrassing. Sure, it didn't need to be decent given the various home and business laptops -- powerful, modern units that saw most of my computing activity -- but I felt like I was letting it down.

So following up the entry from a couple of weeks ago, I finally got around to ordering a new CPU and motherboard on Tuesday, ordering a retail boxed Intel Core 2 Quad Q6600 2.4Ghz processor from Direct Canada for the extraordinarily low price of $279.99 CAD. I'd been directed to their site from a search-engine yielded link to "Shopbot.ca", so I was a bit wary placing my order with this unfamiliar provider, but at 1pm the next day the box arrived at my door, amazingly delivered less than 24 hours after I ordered, coming from a shop 3000km away. I'm very satisfied with the price and speed. (I received no considerations for that comment, and know nothing about the shop beyond the fact that they sold me a killer piece of hardware at a great price, delivering it very quickly. Your mileage may vary.)

In the end I discovered that some new memory modules would be in order to fully yield the speed (going with 2GB to correlate with the oft claimed speed advantage that often flies in complete contradiction to actual memory usage metering). Oh, and a new case as it might make the whole process a little easier.

In the end, the only legacy pieces that made the migration to the "upgraded" box are the hard drives, and the video card.

Minutes later the full-retail copy of Windows was running the right drivers, and after a quick re-activation it was storming along.

I booted up.

In a word (and a punctuation) - Wow!

What a tremendous amount of computational power on the cheap. Day to day activity really feels no different than it did before -- browsing is the same fast browsing that it was before, and given that I don't try to use Excel as a warehousing database, Office seems the same as well. Battlefield 2 plays the same given that I have the same video card, albeit now with absolutely zero stutters or hiccups as other threads demanding timeslices are generally satisfied by one of the other cores.

For the things that actually keep me waiting -- encoding a home video from the MiniDV, or building firefox from CVS, as I do regularly -- the improvement is enormous. Not only are these operations massively sped up by the four cores available to them, better still I can configure them to only use one, two, or three threads of parallel executions (via the -j build option for Firefox, for instance), constraining them as a coarse fix for the deficiencies of the Windows scheduler. I can now run a full Firefox 3 build in just 12 minutes with full parallelism, or run it (or other demanding applications) with little or no impact in the usability and functionality of this PC for other tasks.

Parallel Building Firefox
Full Build Times on Quad Core Processor
(Bars represent time. Shorter=better)

 -j1 (default)    24 minutes 12 seconds
 -j2 (1 to 2 threads)    16 minutes 52 seconds
 -j4 (1 to 4 threads)    14 minutes 34 seconds

The build continued to speed up with more possible parallel operations, albeit with a decreased rate of return, with the fastest test build occuring in just over 12 minutes with the highest option tested: -j12. Having more parallel operations than cores can yield benefits when it increases the time utilization of a saturated resource, which in this case was the hard drive. At this point the cores were left twiddling their thumbs waiting for the storage to catch up.

Limiting the build process to two cores via the process CPU affinity had it CPU starved beyond -j2, yielding no benefit via more parallelism.

You can find a stacked graph detailing core processor usage for the above -j4 run (on 4 cores) at http://www.yafla.com/dforbes/images/Firefox_build_j4_4core.png. You can also look at a chart of building Firefox using the -j4 option, but setting the processor affinity to only allow the build access to two cores.

Not only is the build performance fantastic, but better still I can throttle it back to only run at most two parallel operations (-j2), getting a build in a still impressive 17 minutes while leaving two cores completely available for other tasks, like browsing the web with full responsiveness. I can even launch Battlefield 2, and remarkably it plays flawlessly...despite the fact that a full-scale, parallel build is going on in the background.

(Sidenote: Threads can still be left stalled, stranded waiting for a shared resource like the limited memory bandwidth and I/O paths, for instance. In the sample above my build was on a second harddrive -- a configuration that I recommend for all power users -- and clearly the other shared resources didn't impact the game to a perceivable degree)

What a revolution in computer usage. What a discount-priced computational powerhouse.

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!

Monday, August 27 2007

Summer is waning here in the Northern hemisphere. 

While it's sad that the warm weather and summer activities will soon be packed in the garage for another year, it's almost the time for fall fairs, rich soups, apple picking, walks in the gorgeous escarpment country when the leaves have changed color, pumpkins and costumes.

IMG_2741

'Tis a wonderful season ending, to be replaced by another great time of year.

With the decrease in outdoor activities, I'll be posting more frequently. I've been kicking SQL Server 2008 around, and look forward to writing about it (I'm excited about its new hierarchical functionality, which has echos of versatile high performance hierarchies), along with many other thoughts that have percolated in my head.

Earlier EntriesLater Entries

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