LabVIEW and the Multicore Crisis

Posted on Wednesday 19 September 2007


Software developers and technologists everywhere are beginning to discuss the looming "multicore crisis".  In a nutshell, this crisis stems from the fact that processors are no longer getting faster due to heat issues; they are just getting cheaper, so, we're putting more of them in a single computer.  Today's multicore processors look like a single chip, but actually have several processors that run in parallel.  Unfortunately, most software was written in such a way that it cannot take advantage of multicore processors.  That means, most software programs that exist today will not run any faster on the latest and greatest computers 10 years from now, assuming that clock speed continues to remain constant.  They are frozen in time like dinosaurs, doomed to extinction -- and, that's the crisis.

Now, why can't most software run on more than one processor core?  The answer is that most traditional, text-based programming languages do not have easy ways to program applications that can execute different parts in parallel on multiple processor cores -- they are written as one big loop of sequentially executing code that can only run on a single processor.  And, many text-based programmers do not map problems into a parallel solution space -- parallelism isn't part of their programming toolbox.

Now, if you're like me, you're probably thinking, "I'm sure glad that I program in LabVIEW, which is inherently parallel."  The LabVIEW programming language is parallel at it's heart, with software written on a two-dimensional, graphical canvas of parallel data flow.  At NIWeek 2007, NI demonstrated a simple application written in LabVIEW, which had three While Loops communicating with each other: acquiring, processing, and presenting data.  They demonstrated how the application executed 3.8x faster when running on 4 cores as it did when running on 1 core -- that's a nearly linear increase in performance.  While more complicated applications will, of course, have a hard time scaling linearly, this achievement by NI is remarkable.

To learn more about how LabVIEW's parallelism allows code to take advantage of multicore processors, you should definitely read NI's white paper, Programming Strategies for Multicore Processing: Data Parallelism.

Concurrent, parallel, and distributed software applications are rapidly moving to the forefront of the software engineering word.  The community of text-based programming experts are struggling to find ways to deal with this problem with their tools of choice and some are predicting that it will take a decade before their tools are ready.  Aren't you glad that LabVIEW, which has been parallel since 1986, is 30 years ahead of them?

External Links:

7 Comments for 'LabVIEW and the Multicore Crisis'

    September 19, 2007 | 9:56 am

    Yeah, but you know we’ve been hearing this multi{whatever} crap for years. Multi-tasking, multi-threaded, Hyper-threaded, multi processor, multi-core. And every time they do this, NI goes on and on about the improvements in LV because of it.

    Personally I’m tired of them re-presenting the same line just wrapped up in new silicon. Yes I agree I love the fact that I get improvements just because I use LV, but I would much rather see LV not take up 100 Meg of memory just to be loaded, or multiple megabytes of memory for a VERY simple exe built in LV.

    Dave Grimshire
    September 20, 2007 | 5:09 am

    Odd that multi-core and parallelism is mentioned with an application like Labview. These are funcitions of the operating system. Without a good functional understanding of computer science principles we will see unrealistic expectations for our applications.
    Labview used to be a quick way to provide an excellent user interface to hardware. Single purpose but elegant.

    Scott Hannahs
    September 20, 2007 | 6:20 am

    Very true. I have to think that the term “crisis” is a bit harsh here. Even in textural languages one can fork and multi process. It is just that LV it is much easier to comprehend the code and avoid problems. This is an extension of the way that LV is easier to comprehend the code at a higher abstraction level of the 2-D graphic overview.

    I have been writing multi-CPU code since I did an FFT optimization on an SGI multi-cpu machine back in the lat ’80s. This hardly makes it a crisis but more of merely a shift of the multi-core programming mind set into the public awareness. I suppose it is merely that the windows folks are finally catching up with the high perforamance computing and other OSs (you know which OS I mean!! :-) ) that have had this for years.

    A good objective framework can lead to a simple multi-CPU, event driven program in a text based language.

    The advantage of LV is the easy visualization and avoidance of race conditions due to the way of looking at the code. The LV IDE takes care of the snchronization, memory allocation issues etc. Of course as Norm points out this comes at price of memory usage. That can be managed, but takes careful programming. I suppose if it were easy everyone would do it!

    However remember that the kernel of whatever OS you use, real time OS especially, needs to be multi-CPU optimized at a very basic level. This is true of the Mach kernel and some of the linux distributions. Otherwise you are putting lipstick on a pig and all this multi-cpu features only work in simple demos.

    Chris Clark
    September 20, 2007 | 9:35 am

    The theme of LabVIEW has something special reminds me of some article I read back in the early 90s comparing the exponential looking speed increase of computer hardware over time to the shallow slope of increases in the “power” of programming languages/tools over time. The increase of fragility with size looked like a crisis too. OOD was having some impact, Java was an improvement, because as Bill Joy said once, with C++ etc. languages your program really boils down to peeking and poking memory and that is not scalable. I think LabVIEW is a significant development. As a visual, high-level language LabVIEW brings a lot. Good essay about leveraging the multicore trend “for free.”

    Ken Roberge
    September 20, 2007 | 10:32 am

    Single but elegant purpose of LabVIEW is true. Unfortunately LabVIEW has an identity problem. I was looking to buy an advanced book on LabVIEW programming, and found 1 book at 3 major stores. They all had multiple shelves with many books of every other programming language. I would love to see LabVIEW expand into more than a single purpose package. It’s no advantage for LabVIEW to have multi-CPU capabilities for those who want to program applications beyond what LabVIEW does. If NI could only envision how powerful LabVIEW could truly be, included in WEB, Gaming, etc. You may ask why? I ask… why not? (rhetorically)

    Martin Kretschmar
    October 3, 2007 | 4:28 am

    I’m sad so say, that I’m not 100% convinced using LabVIEW, see Event Driven Programming

    I had far too many crashes, “half” refreshed screens, etc. And often ones code is broken
    but one can’t see where. Editing slightly larger nested structures can be a pain too, I
    killed a LV 8.2 during an insertation of an addtional case structure after 45 mintues
    with 100% cpu load. Also an change caused an internal recompile with takes ca. 5 seconds.
    With LB 8.2.1 the structure became editable and the compilation is done only while saving.

    And even with the inherent parallelism I still don’t quite see how I could implement
    a queue of worker threads. So for me LabVIEW is more a kind of a nice gadget.

    Gary Sloane
    November 9, 2014 | 8:02 pm

    What’s even funnier is that the LabVIEW compiler is NOT able to take advantage of multiple CPU cores. When my LabVIEW compiles, it can ‘lock up’ for 5-10 minutes while it completes it’s task. That’s because it BLOCKS (the IDE; the editor; everything you can do!!!) while it compiles. And if I look at the performance of my system (Win7, 8 CPU cores, 16GB memory) I show ONE core at 100% and the other SEVEN cores are IDLE. “Inherently parallel” my ass. Yes, applications written in LabVIEW take advantage of multiple processors. But the LabVIEW programming environment does NOT. If it didn’t impact my development schedule so completely it would be laughable.

Leave a comment



Information for comment users
Line and paragraph breaks are implemented automatically. Your e-mail address is never displayed. Please consider what you're posting.

Use the buttons below to customise your comment.

RSS feed for comments on this post |


Bad Behavior has blocked 772 access attempts in the last 7 days.