Article: LabVIEW and the Multicore Crisis

[Jim Kring]

[cross-posted on ni.com]

Hi All,

I've written a new article, titled: LabVIEW and the Multicore Crisis. (Don't worry, there's no crisis for LabVIEW developers.)

I hope you enjoy it

-Jim

[Grampa_of_Oliva_n_Eden]

QUOTE(Jim Kring @ Sep 19 2007, 09:56 AM)

Hi All,

I've written a new article, titled: http://thinkinging.com/2007/09/19/labview-and-the-multicore-crisis/' target="_blank">LabVIEW and the Multicore Crisis. (Don't worry, there's no crisis for LabVIEW developers.)

I hope you enjoy it

-Jim

Nice article Jim.

What is REALLY cool about this is that sometime soon (maybe in my life-time) LabVIEW applications will be able to out perform application writtien in that other language.

:thumbup:

Ben

[Val Brown]

Nicely done. I for one am glad I've been programming with this "toy" instead of C/C++ for the last 9 or so years... ;-)

[Grampa_of_Oliva_n_Eden]

QUOTE(Val Brown @ Sep 19 2007, 10:29 AM)

Nicely done. I for one am glad I've been programming with this "toy" instead of C/C++ for the last 9 or so years... ;-)

:thumbup:

As was the case with the many times in the past...

The toys of today are the tools of tomorow!

Ben

[Gabi1]

QUOTE(Jim Kring @ Sep 19 2007, 03:56 PM)

Hi All,

I've written a new article, titled: http://thinkinging.com/2007/09/19/labview-and-the-multicore-crisis/' target="_blank">LabVIEW and the Multicore Crisis. (Don't worry, there's no crisis for LabVIEW developers.)

I hope you enjoy it

-Jim

Cool

i just had this discussion yesterday with a colleague. he kept telling that you can easily program c++ to process parallel, and that Labview is just annoying because one cannot easily access core functionnality. the "i want every option" guy. Fact is, he never actually passed beyond the beginner utilisation of LV. THat is to say, there must be a way to publish LV as a real functional programming language.

Yet, when one think of doing 3D apps or games, LV is just not fit for the task.

so, maybe if we had features like

1) a different kind, more efficient compiler - one that would not be "instantaneous", yet would make code run much faster.

2) a runtime engine preinstalled in the operating system(s).

we could explain and share it better?

[Jim Kring]

Hi All,

Thanks for the feedback

QUOTE(Ben @ Sep 19 2007, 07:26 AM)

What is REALLY cool about this is that sometime soon (maybe in my life-time) LabVIEW applications will be able to out perform application writtien in that other language.

Yes, Ben. I think that it will happen very soon. Hang in there!

QUOTE(Gabi1 @ Sep 19 2007, 08:09 AM)

so, maybe if we had features like

1) a different kind, more efficient compiler - one that would not be "instantaneous", yet would make code run much faster.

2) a runtime engine preinstalled in the operating system(s).

we could explain and share it better?

Yes, I agree. However, in order for this to happen, LabVIEW (or more specifically, graphical dataflow programming) needs to grow beyond test and measurement and become seen as a general purpose programming language and platform.

Cheers,

-Jim

[PaulG.]

QUOTE(Ben @ Sep 19 2007, 10:26 AM)

... LabVIEW applications will be able to out perform application writtien in that other language.

Unless I'm misunderstand all the hype at NI, LV is quite capable NOW of performing as well if not better than that "other language", especially in RT applications. And in my own experience I've gotten deterministic data without RT, with most of the limitations in performance coming from limitations in the Windows environment.

[Grampa_of_Oliva_n_Eden]

QUOTE(PaulG. @ Sep 19 2007, 01:29 PM)

Unless I'm misunderstand all the hype at NI, LV is quite capable NOW of performing as well if not better than that "other language", especially in RT applications. And in my own experience I've gotten deterministic data without RT, with most of the limitations in performance coming from limitations in the Windows environment.

Yes good point Paul.

The area of performance that LV is pushing now is the raw number crunching teritory.

We hvae alrady seen this performance jump in one of our apps that did a bunch of FFT's from multiple microphones at the same time. The initial app swamped the CPU of the first machine we ran it on. I had the engineer implement parallel code for each microphone's data and the CPU was still swamped. We advised the customer that the biggest bang-for-the-buck would be to get a more powerful machine rather than pay us to try and squeeze some of the fat out of the app.

So after deploying the app to a new machine with four hyperthreading cores and adjusting the "threadconfig" so that we were using (?) 32 threads, we observed about a 40% utilization on all of the CPU's.

We have not anymore comments about performance from that customer.

I have to comment on one slight draw-back. THe diagram looks a little funny with exactly the same code duplicated side by side eight times. At first glance you could say "That should be done in a loop." NOT!

Ben

[Yair]

QUOTE(Ben @ Sep 19 2007, 07:41 PM)

I have to comment on one slight draw-back. THe diagram looks a little funny with exactly the same code duplicated side by side eight times. At first glance you could say "That should be done in a loop." NOT!

Isn't that code encapsulated in a reentrant VI?

Or, at the very least, in 8 file copies of the same VI?

[Grampa_of_Oliva_n_Eden]

QUOTE(yen @ Sep 19 2007, 03:25 PM)

Isn't that code encapsulated in a reentrant VI?

Or, at the very least, in 8 file copies of the same VI?

Sorry to disapoint you YEN but no.

Its 8 cut-n-pastes to the diagram.*

Ben

* Disclaimer: For the most part, I code by the hour. The customers dictate how their money will be spent. As soon as they tested the 8-copy version, they said "Done!" If it makes any difference, it was very pretty code :thumbup: until I asked the engineer to to do the cut-n-paste.

Done disclaiming.

[eaolson]

All my computers at this point are single-core because they are either (a) in my lab where they are a bit old or (b) at home where I am a bit poor, so I have not had the chance to do anything with the multicore capabilities of LV. I'm just wondering, how much effort is it to take advantage of this? Can I expect to just drop any old VI on a multicore computer and see a significant increase in speed, or would it have to be carefully optimized for multicore execution?

[Grampa_of_Oliva_n_Eden]

QUOTE(eaolson @ Sep 19 2007, 05:41 PM)

...how much effort is it to take advantage of this? Can I expect to just drop any old VI on a multicore computer and see a significant increase in speed, or would it have to be carefully optimized for multicore execution?

Most of what I KNOW came from http://zone.ni.com/devzone/cda/tut/p/id/3558' target="_blank">this document.

Ben

[Gary Rubin]

QUOTE(eaolson @ Sep 19 2007, 05:41 PM)

Can I expect to just drop any old VI on a multicore computer and see a significant increase in speed, or would it have to be carefully optimized for multicore execution?

I think the answer is "yes" to both. It depends on how parallel your processing is. You usually can see some increase in performance just by dropping it onto a multicore system, but you might be able to do much better by being careful with your threading and taking advantage of some of the thread priority settings.

[Grampa_of_Oliva_n_Eden]

QUOTE(Gary Rubin @ Sep 19 2007, 08:46 PM)

... you might be able to do much better by being careful with your threading ...

Two points

1) The scenario I reported above, we did not get full utilizatio of all CPU until we had more than enough threads configured. In LV 8.0 they fixed a bug that kept the thread count low.

2) Artifical code sequencing ( excessive seq structures, preventing simultaneous execution) will prevent mutlithreading.

It SEEMS the code should look like a river delta, sepearting out into multiple streams to take full advantage of multiple cores.

Ben

[PJM_labview]

QUOTE(Gary Rubin @ Sep 19 2007, 05:46 PM)

I think the answer is "yes" to both. It depends on how parallel your processing is. You usually can see some increase in performance just by dropping it onto a multicore system, but you might be able to do much better by being careful with your threading and taking advantage of some of the thread priority settings.

This is not quite that easy. In some instance your code may run faster, in other it may actually run slower. What I have noticed in LabVIEW 8.21 is that when you get a multicore the load end up spread more or less evenly between the two core, but for some reason it is "harder" to reach high processor usage. So in some situation, you may have some code that may use briefly 90% of a single core processor and take about 1s to run and the same code on the multi core will be balanced at about 50% on each core and take 2s to run.

With LabVIEW 8.5, if you use timed loop, you can explicitly point (if you want to) at which core the code inside the timed loop run. While this feature is market at RT systems, it appear to works just fine on window. I which NI had gone one step further though and did the same thing for while loop and for loop. It would be very nice if I could right click on a while loop and select "run on core1" for example. Fortunately, it seem that you can trick LabVIEW in doing so by wrapping the code you want to run on a specific core inside a time loop (not very elegant at all, but the test I run seem to indicate this work fine).

In conclusion, when you migrate some code from a single core to a multi core, it *may* run faster from the get go, but this is not an absolute certainty.

PJM

[orko]

QUOTE(PJM_labview @ Sep 20 2007, 08:54 AM)

Fortunately, it seem that you can trick LabVIEW in doing so by wrapping the code you want to run on a specific core inside a time loop (not very elegant at all, but the test I run seem to indicate this work fine).

You can also assign the processor in a http://zone.ni.com/reference/en-XX/help/371361D-01/glang/timed_sequence/' target="_blank">Timed Sequence.

[Gary Rubin]

QUOTE(PJM_labview @ Sep 20 2007, 11:54 AM)

So in some situation, you may have some code that may use briefly 90% of a single core processor and take about 1s to run and the same code on the multi core will be balanced at about 50% on each core and take 2s to run.

This sounds indicative of non-parallel dataflow. What you described sounds like each core is spending half its time waiting for the other to finish.

If you do not see total CPU usage over 50%, then you are not actually doing anything in parallel and would not expect any better performance than a single core.

[PJM_labview]

QUOTE(Gary Rubin @ Sep 20 2007, 09:39 AM)

This sounds indicative of non-parallel dataflow. What you described sounds like each core is spending half its time waiting for the other to finish.

If you do not see total CPU usage over 50%, then you are not actually doing anything in parallel and would not expect any better performance than a single core.

While I would not necessary expect improved performance, I certainly would not expect worse one. But this has happened.

You are probably correct regarding the code not doing anything in parallel though. This was a bunch of VI doing recursive CBR call.

PJM

[Gary Rubin]

QUOTE(PJM_labview @ Sep 20 2007, 02:28 PM)

While I would not necessary expect improved performance, I certainly would not expect worse one. But this has happened.

Hmmm, that does seem odd - maybe a difference in memory speed between the single-core and dual-core systems?

[PJM_labview]

QUOTE(Gary Rubin @ Sep 20 2007, 11:39 AM)

Hmmm, that does seem odd - maybe a difference in memory speed between the single-core and dual-core systems?

This was on a PXI chassis (1031 DC). The "Brain" was upgraded from a NI PXI 8196 to a NI PXI 8106 (dual core), and I believe they took the memory from the old one and put it on the new one (2Gb Total).

Other than these specific CBR recursive VIs, everything else run smoother and faster.

PJM

[robijn]

Keynote NIweek tuesday.

[Jim Kring]

QUOTE(robijn @ Sep 21 2007, 01:18 AM)

Keynote NIweek tuesday.

Thanks for the photos, Joris!

-Jim

[Grampa_of_Oliva_n_Eden]

[OT -slightly]

In this thread I adapted an old joke for LabVIEW after being inspired by this thread. It may be a little lame but after all I am just a bear and not a comic.

Ben

[LAVA 1.0 Content]

Modeling Concurrency with Graphs: Petri Nets

From the article:

Among many of the fascinating things that we computer scientists do with graphs is use them as a visual representation of computing devices. There are many subtle problems that can come up in all sorts of contexts where being able to see what's going on can make a huge difference. Graphs are, generally, the preferred metaphor for most computing tasks. For example, think of finite state machines, flowcharts, UML diagrams, etc.

One of the most interesting cases of this for one of the biggest programming problems today is visual representations of concurrency. Concurrent program is incredibly hard, and making a concurrency regime correct is a serious challenge - communicating that regime and its properties to another developer is even harder.

Biggest programming problem today is visual representation of concurrency? Hmmmm. Anyone have any ideas?

[Grampa_of_Oliva_n_Eden]

QUOTE(LV Punk @ Oct 2 2007, 08:39 AM)

Modeling Concurrency with Graphs: Petri Nets

http://scienceblogs.com/goodmath/2007/10/modeling_concurrency_with_grap.php' target="_blank">From the article:

Among many of the fascinating things that we computer scientists do with graphs is use them as a visual representation of computing devices. There are many subtle problems that can come up in all sorts of contexts where being able to see what's going on can make a huge difference. Graphs are, generally, the preferred metaphor for most computing tasks. For example, think of finite state machines, flowcharts, UML diagrams, etc.

One of the most interesting cases of this for one of the biggest programming problems today is visual representations of concurrency. Concurrent program is incredibly hard, and making a concurrency regime correct is a serious challenge - communicating that regime and its properties to another developer is even harder.

Biggest programming problem today is

visual representation

of concurrency? Hmmmm. Anyone have any ideas?

Not being a computer scientist, I am not familiar with all of the high level terms.

So in "Ben speak" I associate the term "concurrency" with the term"while" as in while this is happening this should happen.

Its one of those key words I listen for (spoken or implied) when developing architectures for my applications.

I use (Ben speak) interaction diagrams. These take many forms as I work through a design.

First they are simply fuzzy ballons that have arrows indicating what personality iss associated with each baloon and the basic nature of their interactions.

Example:

DAQ sub-system passes data to display baloon and logging baloon.

This will tell me I have three components that will be interacting.

AS the design proceeds and while detailing the nature of the interactions, I may go to (Ben speak) hand-shaking diagrams that have one componenet on the left side of the page and the other on the right. Time is rendered from top to bottom with arrows indicating what signals are asserted when etc.

I am currently studying UML in the hopes that I can get a handle on the proper terms for all of the stuff I do (and understand the new State Chart tool).

I would love to hear more about how others are documenting these systems as well!

Ben