Arthur Cole spoke with Jeff Meisel, product manager, National Instruments.

Cole: It seems like the need for parallel programming solutions hit a crisis point very suddenly, even though multicore development had been in the works for some time. Why was the software industry so unprepared?
Meisel: That's right, but I think the key difference now is almost every development team is faced with having to deal with writing code that can execute in parallel. That's a different intent than many of the early multithreaded applications that only helped out in interrupt situations to keep the application responsive. For one, since the OS has always handled the automatic load-balancing of processes, developers didn't really have to pay attention because as clock speeds kept getting faster, so did their application. Now with clock speeds hitting a wall, if you're a software developer and you want your application to run faster or just be more responsive with all the new features your customers are demanding, you have to partition your code so the application can utilize multicore processors. This means more sophisticated programming strategies.

Cole: Enterprise managers are looking at major overhauls of their network fabrics to accommodate the data loads brought on largely from multicore and virtualization technologies. If their application layers fail to keep up with these new environments, will all that investment have been in vain?
Meisel: I don't think so. As with any evolution of technology of this magnitude, there will certainly be some challenges. But what's really exciting is all the potential leaps in innovation and business efficiencies this is enabling. I feel that the business opportunity with technologies like multicore and virtualization is worth the growing pains that may come along with it. And be certain that the hardware/software industries are working to make sure all the technologies play nice together. In the case of the enterprise manager, each individual manager must put together a multicore strategy for their business and mitigate risks by looking at the entire scope of their problem.

Cole: NI has proposed a solution in the LabVIEW graphical language. How does it help languages like C and C++ overcome their multithread barriers?
Meisel: First, it's important to note that there is no silver bullet for multicore programming. From our perspective, the R&D efforts we have invested in the LabVIEW programming language make it an ideal option for parallel programming. It would be used instead of C or C++, or with a hybrid approach incorporating LabVIEW in addition to C. We've gone a long way toward tackling design challenges based on multicore hardware architectures (not to mention other parallel hardware architectures like FPGAs), so developers can focus on the application at hand.

LabVIEW is a graphical programming language, so when you begin creating code, it immediately starts to branch out in a two-dimensional block diagram, so the code source is inherently parallel. You can visually "see" the parallel paths in your code. When a LabVIEW application runs on any processor (single CPU, multiprocessor, or multicore), parallelism is achieved under the hood through multithreading. It is important to note that the concept of threading is abstracted from the developer, so many LabVIEW developers who have legacy applications that were originally intended for a single CPU will see some speed-up when they move to a multicore CPU, depending on how much parallelism is in the code.