Are the Emperor's New Clothes Transparent or Just Invisible?

Surely some vendor should be able to come along and make the number of cores or processors transparent to our application. After all, isn't one of the operating system's jobs to hide the details of the hardware from the programmer?

Why can't we just do business as usual and let some piece of software hide or abstract the parallelism away? That is the goal, right? To be able to do parallel without really doing parallel.

You know just like one of those new fangled eat-whatever-you-like exercise-free weightloss programs. There's gotta be, or soon to be, some new high-level software doodad that will let the developer take full advantage of massive multicore configurations without doing any parallel programming at all. I mean we had third-generation languages that abstracted machine architectures away and paved the way for user programming (or at least that's how it was billed at the time). Fourth-generation languages appeared not long after third-generation languages with a similar promise. Why get bogged down in all of the procedural mess of a third-generation language when you can have the clarity and simplicity of a nice declarative fourth-generation language. At each stage, the promise was to make detail oriented programming obsolete. Not only was the goal to free the developer from the complexity and minutia of the previous generation technology but also with each higher level abstraction the theory was that there would be less and less reliance on, or need for, specially trained or highly skilled programmers.

With each level, tools cropped up that claimed even further freedom. There were code generation tools that automatically generated third-generation language code (3GL) without the need to do 3GL programming, database base tools appeared that seemed to require no database programming or even knowledge of database programming. Now we have Web-Site-In-A-Box (no web development or programming required!). Surely the horizon of parallel programming prognosticates a similar fate right? Presto! Instant Parallelism. Of course, there is a fallacy in all of this, or at the very least a little intellectual dishonesty. These Paradigm-In-A-Box solutions with No-Programming-Necessary usually only work on very well traveled roads. They usually only work for problems where the solutions have become so standardized and so commoditized that the vendor is doing little more than repackaging the obvious and providing a simple convenience for those up against deadlines or budgets. The Paradigm-In-A-Box approaches for the most part are not able to scale horizontally across platforms, vendor-specific products, or problem domains. The Paradigm-In-A-Box approaches also usually fail miserably when confronted with multiparadigm software development.

Ahem... Tracey and I tend to notice right-off-the-bat that the emperor is stark naked and that the new clothes are often the same old seductive see-through machinations that promise to take the "do" out of doing and "work" out of working. As one famous werewolf hunter once said "there is no silver bullet". The software development efforts needed to take true advantage of massively parallel configurations require a substantial paradigm shift from where we are now. That's not to say that our current models of concurrency that address multiuser scenarios, or client/web server scenarios don't have any place in our future parallel universe, but we are saying the manifestation and realization of massive parallelism in complex goal-driven software systems will require that we rethink some of our fundamental notions of what computer programming is at its core. While biologically-inspired, or nature-inspired parallelism is all the big craze in the research community and may very well yield fruit. Tracey and I are still (sadly) possibly (naively) stuck on the work, findings, and ghosts of ICOT and parts of the Fifth Generation project. The AI-Complete wild goose chases we're on right now are simply not compatible with the Transparent-Parallelism-In-A-Box solutions that some of the well intended vendors are producing at the moment. It's not that the emperor had no clothes on, it's just they were transparent (or was it invisible?).
http://www.deoxy.org/emperors.htm

Real World Parallelism Webinar Series
  • November 17, 2009
    Visual Effects for Animation - presented by DreamWorks Animation
    Speaker: Ron Henderson (Bio)

    Ron Henderson manages the FX Tools group at DreamWorks Animation, where he is responsible for developing physical simulation and procedural modeling tools. These systems have been used for key visual effects in recent films such as Kung Fu Panda and Monsters vs. Aliens (March 2009).

    Prior to joining DreamWorks in 2002 he was a senior scientist at Caltech with a joint appointment to the Applied Math and Aeronautics departments, where he worked on efficient techniques for the direct numerical simulation of fluid turbulence.

    Abstract:
    In this webinar, Ron Henderson will show examples of visual effects, from hair and feathers to smoke and fire, from a variety of DreamWorks Animation feature films. He will discuss in general terms the kinds of techniques used to achieve particular visual effects. Finally, Henderson will show a detailed breakdown of the dam-breaking scene from Madagascar: Escape 2 Africa, demonstrating how different elements of key frame animation, simulation, and rendering are combined in a real production shot.

  • December 1, 2009
    A Quick and Easy Way to Parallelize a Legacy Codebase with Intel® Threading Building Blocks (TBBs)
    Speaker: Bernard Laberge, Avid, Senior Principal Engineer (Bio)

    Bernard Laberge is a senior principal engineer in the video editors division at Avid. During his seven years with the company he has been actively involved in the replacement of the legacy video processing engines used by Avid editors with a common hardware-abstracted, component-based video processing engine currently running on the CPU with SIMD optimized code, GPU, and dedicated hardware.

    Abstract:
    Learn how to overcome the limitations of a thread-based scheduler, including dealing with the absence of recursive parallelism support and the inefficient handling of unbalanced processing load. Bernard Laberge addresses how Avid resolved the expensive refactoring of their thread-based scheduler into a task-based solution by choosing Intel® Threading Building Blocks (TBBs). He explores how Avid was able to easily integrate the Intel TBBs into their video editor applications and more than 5 million lines of code.

  • December 15, 2009
    How to Use Intel® Parallel Studio to Streamline Code Development in a Multicore Environment
    Speaker: Matt Dunbar, Director for Performance Technology, SIMULIA (Bio)

    Matt Dunbar is the director for performance technology at SIMULIA. Since joining the company in 1993, he has worked on parallelization of the Abaqus suite of products, initially for shared memory architectures and more recently for distributed memory architectures. Dunbar has also been intimately involved in selecting both the hardware and software tools used in the development of the Abaqus product line.

    Abstract:
    Resolve elusive, costly multithreading errors quickly and efficiently with Intel® Parallel Studio. While many coding problems that lead to bugs in software applications are typically straightforward logic errors, errors in managing memory and in multithreading code can sometimes take weeks to months to diagnose and fix. Matt Dunbar explores how and why taking advantage of multicore processors through multithreaded code is critical for compute-intensive applications. While spotlighting his work on SIMULIA's Abaqus finite element solver, Dunbar addresses the need for multicore execution and shares his experiences using Intel Parallel Studio to streamline code development in a multicore environment.