The outlandish requirements of gaming and media applications have not only changed the way PCs are configured they have also driven an expansion of the x86 instruction set and on-chip registers that practically creates a CPU within a CPU (or a core within a core).
The same technology that game developers use to make virtual basketballs bounce like the real thing also does a bang-up job of cryptography and compression. The media extensions to the x86 instruction set could help push business analytics towards real-time. Searches and transforms on massive in-memory data sets would get a major speed-up from SIMD (Single Instruction Multiple Data). Despite the fact that every living PC has SIMD extensions by now, I am sure that those extensions aren’t used where they could make the greatest difference.
I understand a few of the reasons why. At the root of it, I think, is a tendency on the part of developers to think that if they’re not writing games or financial analysis software they’re “not doing maths”. Every application does maths. Developers usually rely on their preferred language’s libraries to handle math for them, but the dirty secret of default language libraries is that they often make poor use of the advanced capabilities of modern CPUs.
The origins of SIMD on the x86 tainted its image. SIMD definitely came into being to serve video games and DVD playback; AMD’s variety goes by the name 3DNow. That sounds more like laundry detergent than the potential brainpower behind computing-intensive business applications.
SIMD has also been segregated in Windows developer tools and documentation and another factor interfering with a broader use of x86 SIMD is that the majority of people use of dynamic languages. SIMD is strictly native fare. You can build SIMD into maths libraries, as Apple and Intel have done, and then link those to dynamic code. But the overhead of wrapping individual SIMD machine language operations as functions practically nulls the performance benefit. The greater the number of SIMD instructions that can be run before surfacing to the high-level language layer or having the OS switch to another context (which can wipe out the contents of registers used for SIMD operations), the better.
I haven’t yet encountered development tools that adequately analyse ordinary C or Fortran code for opportunities to optimise their performance with SIMD. Developers have to hunt down those opportunities themselves, but they’re plentiful. A contrived example would involve iterating through a huge array of price data, applying a fixed mark-up or discount. But there are uses for SIMD that have no apparent relation to maths. I imagine using it to accelerate memory management or forensic analysis of a partially erased disk.
Problems outside the digital media, gaming and visualisation realms are rarely going to make a developer snap his fingers and say, “Now that’s a job for SIMD!” I think that CPU-level SIMD will give way to GPUs (graphics processing units). But to extract the greatest value from the use of GPUs as compute co-processors, developers must first learn to identify patterns of code that lend themselves to SIMD and related streaming arithmetic functionality.