So Many Cores, So Little Time

My new work laptop is a ThinkPad W510... a Core i7 Q 720 at 1.6GHz. It has four hyperthreaded cores which /proc/cpuinfo allows me to monitor as eight... meaning my system monitor looks awesome.

Now I'm at the bleeding edge (I guess) of hardware, as now everything requires the latest drivers. I had to manually acquire the firmware for my wireless NIC from Intel directly, then build the Linux wireless drivers from source and install them. Luckily the process was surprisingly easy... it was just that I had to track down and download kernel sources, the GCC build chain, firmware and the wireless driver package without Internet access on the laptop. Still, once that was done the Linux wireless source configure/build/install was quick and easy.

I also had to go directly to NVIDIA's beta driver portal and get the very latest binary drivers for the GPU as well... the console itself was being corrupted by display errors. Again, not hard to fix, just another step.

In the age of everything "just working" on Linux distros I was glad to see that the ancient art of configure/make/make install is still being practiced... in fact it works better than ever.

ARM and a Teg

It has been interesting to passively watch news concerning embedded processors and system-on-a-chip designs since I started my irrational rationalizations about smartphones. The landscape is much wilder than conventional notebooks/desktops.

The weird thing is that the Qualcomm MSM7201A gets anecdotal low marks on the speed of its accomplice platforms, but Qualcomm claims that it has an ARM11 processor, an ARM9 modem, Java acceleration and can do 3D acceleration with 4 million triangles per second with a 133 million pixels per second fill rate. Perhaps hardware sporting the Qualcomm chipset has similar problems to my old VIA EDEN - acceleration was largely borked at the driver level. There seems to be a resonant believe with many developers/users that the 3D acceleration just isn't there, although with Android maybe it is. Either way it doesn't inspire a lot of confidence.

NVIDIA's efforts with Google and Tegra are somewhat more reassuring, as NVIDIA is definitely wanting to get its foot in the Android/ChromeOS door with Google. NVIDIA already has great consumer-ready hardware with Tegra on the Zune HD. This sparring match will only get more interesting as Intel launches their systems-on-a-chip, which have a gazillion different chipsets crammed into one. Intel is even wedging the PowerVR chipset in their designs.

I just need to remember that all this nifty hardware comes with a big caveat... without driver support, all of this functionality just sits idle between transistors.

Intel Not Killing VPU After All

Looks like Intel isn't killing the VPU after all, but instead birthing it. Larrabee, their GPU/HPC processor, is supposedly an add-in proc slated for 2009/2010. Although I'm going to put myself out on a limb and say it will probably become part-and-parcel of their mainline CPU and, instead of being a discrete co-processor, will quickly be absorbed as additional cores of their consumer processor line. But I digress.

Additional information about Larrabee continues to trickle out, but it definitely seems to introduce vector processing instruction sets to be used by general computing, not just as a GPU.

Even if this comes out as a daughterboard or discrete chipset, it should be a compelling reason to pick up a good assembly programming book and start hacking again. How long will it take (non-Intel) compilers to optimize for the vector instruction sets?

Intel Killing the VPU?

I had faintly heard grumblings of Intel loathing Nvidia, but I didn't really put 2 and 2 together until listening to Gordon Mah Ung on this week's No BS Podcast.

Good ole' Gordo spelled out why Nvidia ultimately acquired AGEIA - because Intel deep-sixed Havok's use of GPU's that had been in development for several years. While Havok was an independent company they worked with both ATI and Nvidia to support GPU processing of their physics API. Once Intel bought them the interoperability was tossed in the trash. I'm sure this was a pretty big dig at the GPU makers.

So Nvidia purchases the #2 player in the market to ensure this doesn't happen again. Let's see who enjoys the #1 spot in shipping titles during Christmas of '08.

Exactly How Many PCI-E Slots Does One Need?

I'm pretty much hammering this subject into the ground, but then again so are component makers.

Recently we saw Ageia's physics accelerator come to market as an add-on expansion card, astride your existing video accelerator and sound card. Next we saw the Killer NIC reviewed by IGN, a "network interface accelerator" which promises to offload the assembly of TCP and UDP packets to take load off the CPU. It's actually an embedded Linux instance, assembling your TCP stack instead of Windows. Windows just sends the Killer NIC raw datagrams, then the Killer NIC does all the work to disassemble the datagrams into bare signals over the wire.

Now there's supposedly an accelerator in the works, the Intia Processor, dedicated to nonplayer character AI acceleration. It would offload AI processing from the CPU and instead have a dedicated API for pathfinding, terrain adaptation and line-of-site detection.

So let's count the possible gaming accelerators here:

Sound (i.e. Sound Blaser X-Fi)

Video (i.e. NVIDIA GeForce)

Video (additional NVIDIA GeForce for SLI)

Physics (Ageia PhysX)

Networking (Killer NIC)

AI (Intia Processor)

So that eats at least six slots, but if you have double-wide video cards, more like eight. Oh yeah, and you'll spend nearly $1,500 on just the above hardware accelerators alone.

This is a cycle that repeats itself in the computer world, tho. Popular software algorithms become API's. API's become baked into hardware. The hardware becomes to inflexible and becomes firmware. The firmware isn't flexible so it goes into software. And on and on we go.

But this hasn't necessarily happened for OpenGL or graphics acceleration. Why? Because there you're not baking an API into silicon, you're using a different type of processing unit altogether to solve a different genre of problems. Multiple vector processing pipelines can streamline linear algorithms much more effectively that complex instruction set CPU's. The same analogy can be made for floating point units when they were introduced along side elder CPU's that could only handle integer math.

Not only that, we're looking at chip makers shy away from raw clock speeds and instead looking at cramming as many CPU cores as possible on a single die. This allows for every CPU stamped out of the factory to be a multiprocessor machine. Once API's become more threadsafe, this crazy specialized hardware will instead just be an API call sent to one of the four idle CPU's on someone's desktop.

I think the eventual result of this crazy hardwareization (feel free to use that one) is that people are going to want to fit their algorithms into one of three processing units: the CPU pool (by "pool" I mean a pool of processors upon which to dump your asymmetric threads), the VPU (vector processing unit) or the FPU. The CPU & FPU have already become as one but as any C/C++ programmer can attest to, the decision to use integer based math as opposed to floating point math still rests heavily on the programmer's mind.

Given people are already compiling & running applications on a GPU that have nothing at all to do with graphics, it's only a matter of time before chipset manufacturers come up with a way to capitalize on the new general purpose processing unit.