John Dalton

I’ve been a bit quiet lately, but not because there’s nothing going on! I’m changing jobs in a few weeks time, and beginning a new adventure. More on that later. In the meantime here’s a tidbit from the world of High-Performance Computing, explaining a topic which is important to everyone in the industry as multicore CPUs go from being an exotic technology to becoming the default configuration.

Over on the Star-P blog they’re answering the question: “Multicore: Why all the Hubbub?”

If we tag 2006 as the widespread advent of general-purpose multicore (dual-core) chips and extrapolate with Moore’s Law (a factor of 4 every 3 years), that says 2009 will bring 8-core sockets and 2012 32-core sockets. And those cores may not be getting much faster from generation to generation, unlike the last several years, so delivered performance improvements will depend heavily on making use of those extra cores. In a computing world where parallelism was a niche technology until recently, this is a Big Deal.

It’s an accessible introduction to the challenges ahead of us as we move to multi-core architectures.

Technorati Tags: HPC, SMP, multicore, parallisation, parallel programming, concurrent programming

My friend (and ace python/javascript hacker) Tim Stebbing has only just dipped his toes in the water with LinkedIn, and was wondering how many people he’d find in his network when searching on his primary area of expertise.

I figured I’d give it a go too - while I’ve been slowly building my LinkedIn network I haven’t yet made much of an attempt to use it, and I guess the first step in using it is having some understanding of what sort of expertise is available to me.

So, here’s my first query:

That’s not too bad a result, I guess.  The next step is probably to go through the list identifying people I might be able to help, as well as people I’d like to be more like.

Searches for less specific terms (such as “linux”, or “php”, “python”, or even “grid”) bring up so many contacts that the list gets capped at 500.  Still, assuming those are sorted well for relevance, its useful to know there are a large number of potential contacts with whom I may have some friends or colleagues in common.

I just updated my Wordpress install for this blog, as it was running an old version. While I was at it I decided to install K2, even though I’d made a deal with myself that I wasn’t allowed to do anything with the layout until I’d actually started producing some content! So, I’m naughty.

Once Wordpress was updated I started having issues with the Apache rewrite rules it generates. The rules looked just fine to me, but they’re failed to determine whether a requested URI mapped to a real file. The generated rules look like this:

<IfModule mod_rewrite.c>
  RewriteEngine On
  #RewriteBase /
  RewriteCond %{REQUEST_FILENAME} !-f
  RewriteCond %{REQUEST_FILENAME} !-d
  RewriteRule . /index.php [L]
</IfModule>

That translates to “Rewrite all requests that don’t map to a real file or directory through to index.php”. The reason for this is that template content (images, stylesheets etc) live under /wp-content/, which is a real directory, but other things (such as /about, or URLs to individual entries) don’t actually exist in the filesystem.

However, what was happening on my blog was that everything was redirecting to index.php - including requests for stylesheets, the admin pages, and so on. This meant that “virtual” URLs produced the right content, but it all looked terrible. Plus, because wp-admin is a real directory I was unable to access the admin site.

After about two hours trying to figure out what was going wrong (with a RewriteLog turned on and gradually raised to RewriteLogLevel 5 ) I eventually twigged. Wordpress, in an effort to be as user friendly as possible, generates its rules for use in a .htaccess file. I dislike .htaccess files in general, and hate the thought of doing Rewrites from inside them, so I move the rules into my VirtualHost container instead.

This worked fine on my other blog (varrqnuht.net), but those rules were set up ages ago. The old ruleset is 40 lines long, but the new one is just the one rule with two conditions shown above. Somewhere along the line the Wordpress guys must have started parsing the REQUEST_URI to grab the info they need rather than using apache to rewrite the request as a query string.

That’s an improvement, but because their generated ruleset assumes it will be running in the Directory or .htaccess context, they only have to worry about relative paths. However I’ve moved the rules into the top level of my VirtualHost container, so now the %{REQUEST_FILENAME} is being treated as an absolute path - and that’s not going to work!

The fix is easy (once you’ve figured out what the problem is - usually the hardest part). I just prepend the document root to the rules, like this:

<IfModule mod_rewrite.c>
  RewriteEngine On
  #RewriteBase /
  RewriteCond %{DOCUMENT_ROOT}%{REQUEST_FILENAME} !-f
  RewriteCond %{DOCUMENT_ROOT}%{REQUEST_FILENAME} !-d
  RewriteRule . /index.php [L]
</IfModule>

So simple, and so frustrating to have wasted a couple of hours trying to sort it out! Plus, instead of writing the post I’d intended to write, I’ve written this instead. But hey, content is content!