Multi-core x86 processors only appeared well after PCI-E had taken hold
True, but SMP systems are older. I used a dual P3-700 for years, which I picked up cheaply on eBay because not many people searched for 'duel processor' (I think eBay now does some phonetic matching in their search). Before that, the ABit BP6 (1999) was quite popular. It ran two Celerons, so you could get a dual-processor machine for cheaper than a single-processor one (though you needed to run Windows NT or *NIX to be able to use the second one, as XP was the first SMP-capable consumer OS from MS). The 300MHz Celerons overclocked to 450MHz by bumping the FSB from 66MHz to 100MHz, making it quite competitive with the P2 (the L2 cache in the Celeron was half the size, but twice the speed, and the core was the same).
God I miss 80's computing.
I don't, but if you want to get the same fun without all of the old annoyances there are two things I'd recommend:
The first is to get an FPGA dev board. BlueSpec is a nice proprietary high-level HDL that is free for academic use, but if you don't qualify for that then CHISEL from Berkeley is also not bad - they're both a nice step above Verilog / VHDL.
The second is the mbed boards from various ARM partners. Some ARM folks handed me one of these to play with a few months back. These are aimed at getting embedded development to people who don't normally do it. They've got all of the fun I/O stuff from the BBC micro (plus some new stuff like USB and Ethernet) and a nicely put together development environment.
I've seen a few things recently that have taken an amusing middle ground and bought ARM cores and used them to run a Z80 emulator, because it was cheaper to get the associated peripherals to attach to the ARM core.
I expect Google to die in the same way that IBM died: it will still be a huge and influential player for a long time, but won't be the company that defines an industry that people care about. The same sort of path as Microsoft.
When I interviewed at Google a few years I was reminded of something that JWZ wrote about Netscape, claiming that it started to decline when it started hiring people who were there because it was a cool place to work, not because they wanted to change the world and believed in the things that the company was doing. Everyone I met at Google told me that I should would there because it was a cool place to work...
'sides, I'd get fired for Clarksoning their UI team.
Google has a UI team now?
There's one more reason, which is that there are sometimes good reasons for writing your own sort routine. Specifically, if you have data that has a known distribution that lets you beat a comparison sort. One of the questions I was asked in a Google interview was along these lines. The point was not to see how well I could write code on a whiteboard or reproduce an algorithm from a textbook, it was to see if I could understand that the problem wasn't the same as 'sort arbitrary data', see if I could extract what properties of the problem made it amenable to optimisation, and see what tools I had for approaching that kind of optimisation.
And sometimes it's not about knowing if you can reproduce an algorithm, but about knowing whether you understand the limitations of a particular approach. Do you understand when that off-the-shelf quicksort library would do a terrible job on certain input data? In one interview, I discovered that my interviewer didn't know about hopscotch hash tables, but did know about cuckoo hashing, so we ended up with a discussion about what the overheads of the two approaches are and when either would be better.