The parallel programming challenge will continue to grow as multicore platforms become more common and their complexity and number of cores continue to increase. The domination of sequential programming languages like C/C++ and, in some areas, Java must give way to extensions or new languages to manage multicore platforms.
Tools such as Intel’s Task Building Blocks (TBB) enhance C/C++. The latest version of TBB adds the parallel_do construct that operates like the foreach construct found in languages such as PHP, C#, and Java but in parallel (see “Parallel Processing Gets Terminated,).
TBB tries to address the dataflow challenge inherent in multicore systems where data moves between cores. It targets AMD and Intel x86 SMP cores, though its open-source C code lets developers port it to different platforms. Deep Shadows, a game studio, has ported TBB to the Microsoft XBox 360.
Graphics processing units from AMD and NVidia are also changing their stripes as their internal workings are made available to developers, allowing the creation of streaming applications other than graphics to be hosted on these platforms.
NVidia’s SIMT implements a parallel control flow system rather than pure dataflow (see “SIMT Architecture Delivers Double-Precision Teraflops” at, ED Online 19280). Its Compute Unified Device Architecture (CUDA) development environment is rooted in C, just like TBB.
Development tools like TBB and CUDA require programmers to explicitly identify parallelism within an application. Having a compiler do this instead is very difficult with sequential languages like C.
Turning to other languages is often a better alternative to take advantage of dataflow techniques. With its 20-year track record, LabVIEW (see “LabVIEW 8.6: More Multicore And More Embedded,” p. 58) is the quintessential graphical dataflow programming language (see “LabVIEW Embraces Graphical Object-Oriented Programming,” ED Online 13478). It still tends to be under the radar for many programmers, even though its talents in embedded and FPGA programming are hard to match with any other programming language or environment.
LabVIEW’s inherent dataflow semantics are often unknown to most LabVIEW programmers who are more interested in getting a good user interface to mate with their process control or testing application, but it’s there nonetheless. It can already take advantage of TBB, though its native multicore support is more interesting.
LabVIEW gets some company from the Microsoft Visual Programming Language (VPL). VPL first appeared with Microsoft’s Robotics Developer Studio (see “MS Robotics Studio,” ED Online 16631) a few years ago, so it’s not as refined as LabVIEW. Still, it definitely isn’t just for robotics.
Text-based programming mavens don’t have to turn to graphical programming to check out parallel programming and dataflow techniques. A host of production and research languages is out there as well.
Scala is a language that builds on Java (see “If Your Programming Language Doesn’t Work, Give Scala A Try,” ED Online 18172). Erlang, an open-source language that has been around since 1998, supports distributed, fault-tolerant, soft real-time applications. What flow will you go with?