single core

[nano_era]

Hello,

I would like to ask if anyone could refer me to some reading material that explains the difference in recommended LabVIEW programming for single core and multi core machines?

Assuming I had a multi VI program that runs fine on a quad core, but barely runs on a single core. Obviously the quad core is more likely to provide better performance, but I am vaguely aware of the different programming methods which are more suitable for the respective type of cpu.  

I do not ask for any specific help with any vi or issue, I would just like to read up on this subject. I looked around a little but did not find very much. Any links or suggestions would be greatly appreciated.


Thanks

[Ben]

Please tell more about what you think you should be finding but are are not finding.

I know of things to watch for when going from single core to multi-core but little "rings a bell" going the other way... EXCEPT adding a "zero-millisecond wait" to all loops. The presnece of a wait tell she secudler this loop can be interupted. Without the timer, LV will "read the code" as "please run as fast as possible, and if that means don't give up the CPU, so be it.".

See alos this search on "Cooperative multitasking".

Ben

[nano_era]

Thank you for the response and the suggestions.

I am referring to the difference in performance of a LabVIEW program for quad cores and singles cores. Like I said there will obviously be a difference when going from one to the other. I was wondering if that noticeable difference is strictly due to the processor/hardware, or if it may be at least partly due to the differences in programming methods associated with each? Like what sort of changes to the code should I look to make when trying to run it on a single core? You could say the significance of running it on a single core is to ensure the code can work on various types of machines, from one end to the other. Would I need different versions of the same code?


Just general questions like that.

[PhillipBrooks]

I would start here:

http://www.ni.com/multicore/

Your software implimentation will certainly affect performance depending on the number of processors. My first inclination is that you would need to create different versions of your software to optimize for each processor type.

[Yamaeda]

If your program is well design it'll only perform better on multicores, you shouldn't need to change it per se. LV is good at threading the code, unless you prohibit it through e.g. sequences (which isn't faster or better on a single core).

/Y

[altenbach]

Please clarify "barely runs". Are you benchmarking important math routines or are you talking about UI responsiveness? Does the program involve hardware e.g. DAQ? Remember, on a single core machine, the ui thread needs to share the cpu, so if you have greedy code sections, the ui will suffer.

[nano_era]

Yes it does use DAQ, and the UI does not update as fast in single core as it does in quad. Not that that surprises me. So that's why I was asking if that was more likely due entirely to the cpu or if maybe there were certain adjustments that must be made when running that same code on a single core. I would not expect a single core machine to match or exceed a quad core in performance or speed, I was merely asking if there were any common issues that LabVIEW programmers might face when going from multi to single core that I should consider, in order to make the best out of the hardware, even if it's not much.

[altenbach]

Properly programmed, a modern single core machine should provide equal performance unless you are really pushing the limits. Try to do some profiling.

Is the number of CPU cores the only variable or are there other differences between the two systems (CPU architecture, Cache size, RAM, OS, DAQ hardware, etc.)

[Mark_Yedinak]

---

@Ben wrote:

Please tell more about what you think you should be finding but are are not finding.

I know of things to watch for when going from single core to multi-core but little "rings a bell" going the other way... EXCEPT adding a "zero-millisecond wait" to all loops. The presnece of a wait tell she secudler this loop can be interupted. Without the timer, LV will "read the code" as "please run as fast as possible, and if that means don't give up the CPU, so be it.".

See alos this search on "Cooperative multitasking".

Ben

---

A wait is not always required. It won't hurt, but there are other pieces of code that will allow the scheduler to evaluate if other tasks are ready to run. If you have any queue or notifier VIs they will allow the scheduler to run as well. There are probably a few others. I am reasonably sure that any VI with a timeout input will allow the scheduler to run.

[nano_era]

Yes it is a different system, so the cpu is not the only difference. The code, DAQ, and OS are the same. I'm not able to share any code, but I can say that it is 5 VIs with a bunch of timed loops, DAQmx code, and global variables. Like I said, the UI is slow to start and to make rapid updates.

I am reading a few sources on this site and learning a few things.