Multicore processor and LV

[bsvingen]

This link from NI site describes LabVIEW's multicore functionality. But - I have a dual core PC, and i have yet not seen a labview application that runs on both cores simultaneously. Are there some special tricks i have to do in the programming ? two completely separated loops or something?

Yes, two separated loops will do it (just tested) Rather cool actually to watch the CPU use when one loop is turned off, and only one core is running. But, this brings up some questions about the usefulness of this in a practical application where i need to transfer data between the loops.

[Grampa_of_Oliva_n_Eden]

This link from NI site describes LabVIEW's multicore functionality. But - I have a dual core PC, and i have yet not seen a labview application that runs on both cores simultaneously. Are there some special tricks i have to do in the programming ? two completely separated loops or something?

Yes, two separated loops will do it (just tested) Rather cool actually to watch the CPU use when one loop is turned off, and only one core is running. But, this brings up some questions about the usefulness of this in a practical application where i need to transfer data between the loops.

It looks like you answered your own Q.

Yes it works just fine.

Ben

[bsvingen]

I don't really know how that happened. I pushed "add reply", and my reply ended up inside my first post although i wrote it at least 10 minutes after the first.

Anyway, are there any rules to this multitascing/multicore thing? Is two loops the only method, or are there more?

[Grampa_of_Oliva_n_Eden]

I don't really know how that happened. I pushed "add reply", and my reply ended up inside my first post although i wrote it at least 10 minutes after the first.

Anyway, are there any rules to this multitascing/multicore thing? Is two loops the only method, or are there more?

This NI KB article on Hyperthreading may help.

http://zone.ni.com/devzone/conceptd.nsf/we...6256e2900586d41

Ben

[Guillaume Lessard]

Anyway, are there any rules to this multitascing/multicore thing? Is two loops the only method, or are there more?

I think that most of it comes naturally as a side effect of good graphical style: eliminate artifical timing/data dependencies between parts of your block diagram and you're on your way there. Two loops are probably a good idea given the existence of event structures and threading, even in cases where you get no parallelism. UIs certainly feel better that way...

[Mike Ashe]

If you just want to take general advantage of having more than one core then you use multiple loops and good coding style to prevent the loops from interferring with each other. Where it gets harder is if you have an app that is straining your available resources even with 2 CPUs and you have to try to balance between the two. Sounds like you don't have to get into that for your application though.

[bsvingen]

Thanks for the info. When i got this PC some 3-4 months ago i was a bit puzled about why LV only used max 50% (only one core) in seemingly all applications i tried, since LV was supposed to be "inherently" multitasking etc. But then i forgot about the whole "problem", since all the other applications also seemed to be using only one core. Today I got NI-News with an article about multicore processors and i got curious again.

[Ton Plomp]

This link from NI site describes LabVIEW's multicore functionality. But - I have a dual core PC, and i have yet not seen a labview application that runs on both cores simultaneously. Are there some special tricks i have to do in the programming ? two completely separated loops or something?

Yes, two separated loops will do it (just tested) Rather cool actually to watch the CPU use when one loop is turned off, and only one core is running. But, this brings up some questions about the usefulness of this in a practical application where i need to transfer data between the loops.

Well this is very usefull, for instance you are acquiring data at a hight speed and need to process this as well. You could 'give' them both a different core, this would mean that data acquisition and calculation don't come in each others way..

Ton

[bsvingen]

Well this is very usefull, for instance you are acquiring data at a hight speed and need to process this as well. You could 'give' them both a different core, this would mean that data acquisition and calculation don't come in each others way..

Ton

That's the theoretical part of it. But in a practical situation the data acquisition is handled by dedicated hardware, so it's already paralleled and multiprocessed. Besides, analysis demands much more computing power than acquisition (seen from the PC), so the end result is still max 50% utilization of the PC's dual core processor.

I have yet not seen that LV uses both cores within one loop (maybe it uses several threads, but never both cores). This means that it is *extremely* hard to write an analysis package that uses both cores effectively, since you have to prallelize it by hand.

To detach the user interface from the rest of the program therefore seems to me to be the only thing that the dual cores can be used for in a practical setting. But then, this can be very useful in sutuations where you have lots of graphs and stuff, and guaranties 100% responsiveness.

[Rolf Kalbermatter]

That's the theoretical part of it. But in a practical situation the data acquisition is handled by dedicated hardware, so it's already paralleled and multiprocessed. Besides, analysis demands much more computing power than acquisition (seen from the PC), so the end result is still max 50% utilization of the PC's dual core processor.

I have yet not seen that LV uses both cores within one loop (maybe it uses several threads, but never both cores). This means that it is *extremely* hard to write an analysis package that uses both cores effectively, since you have to prallelize it by hand.

To detach the user interface from the rest of the program therefore seems to me to be the only thing that the dual cores can be used for in a practical setting. But then, this can be very useful in sutuations where you have lots of graphs and stuff, and guaranties 100% responsiveness.

Data acqusition is not just hardware. The data needs to be transfered by a kernel driver into some intermediate buffer and from there into the application buffer. At least the last operation will be executed in the context of an application thread and can contain scaling (DAQmx channels) and other things too. So there is certainly something a core could be doing eventhough it is for a large part IO/memory related and therefore not the best candidate to be parallelized with multiple cores or CPUs unless you would have separate memory busses too.

LabVIEW will not control the cores directly but instead use OS threads. How the OS distributes threads onto multiple cores is almost completely out of control of LabVIEW and can actually be tweaked by a power user.

So while multiple independant loops will allow LabVIEW to distribute each loop to a differnt thread it is usually very counterproductive to start distributing related code to multiple threads especially if data flow commands a certain execution order. Instead of just continuing execution of a logical dta flow LabVIEW has to suspend a thread and wait for the correct thread to be activated by the OS to continue the logical data flow. In addition to the costly execution context switch you are forcing onto a logical data flow, you incure additional delays since the OS might decide to activate a different thread first than the one that would suit the dataflow best.

However if you have a single loop with subVIs you could assign different execution systems to these subVIs and LabVIEW would be forced in that way to use a different thread. But please note that this will only really have any positive effect if you happen to have two different subVIs in the same loop that do both a computationally expensive operation.

Without subVIs parallelisme in LabVIEW is limited. All built in nodes that do not have some kind of wait or timeout function are exectued synchronously and in the same thread as the diagram they are contained in since their typical execution time is quite small in comparison to the context switch overhead to let the OS switch between multiple threads.

Most LabVIEW applications I write have anything from 2 to 6 or more parallel loops in the main diagram although sometimes some or all of the loops are located in specific subVIs that are called by the main VI once and terminate automatically all when the application wants to shutdown. This has never given me bad surprises (provided you do a proper design before you start with the actual coding) but results in applications that do DAQ, Analysis, logging, test sequence execution, image acquisition and instrument control all in parallel and still have an utterly responsive user interface.

Rolf Kalbermatter

[Mark Balla]

There is a ni podcast titled Intro to dual- and multi-core technollogy here

[Falevoz Y.]

Hi!

I just receved a quite new core 2 duo computer. I did some test in order to see the 2 core at work. My test work well with 2 wile loop, but only one core is runing with 2 timed loop. Did you see the same... Can you explain me...

Yann

[Neville D]

This NI KB article on Hyperthreading may help.

http://zone.ni.com/devzone/conceptd.nsf/we...6256e2900586d41

Ben

<rant>

I wish NI would update that OOOOOOLD junky App Note. It doesn't cover a whole host of issues related with modern PC hardware and even LabVIEW improvements. Hyperthreading is pretty irrelevant with dual and multicore processors now out.

Things not covered:

1 How to put two instances of the same VI on the BD on different threads (so they don't interfere).

2 Timed loops (like someone mentioned earlier) and how best to use those with multi-threading.

3 Using multi-threading on LabVIEW RT.. (I know, RT doesn't support it yet, but its about time NI got around to supporting multi-core on RT)

4 Multi-threading specifice types of applications especially vision, DAQ, (or even TCP communication).

5 What tools to use to debug applications (Execution Trace Toolkit? Does it work for RT?)

6 Multi-threading implications for DAQmx if any.

I just find with each new release, the documentation just seems to get worse.. no pdf's, no labview manuals, just terse "help" files which are no "help".

<end rant>

Neville.