LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

For loop parallel computing

Solved!
Go to solution

Hi,

 

A small question. In Labview, those the for loop do parallel computing if the index isn't used? Exemple, I generate a random number in a for loop of size 100, will it generate the 100 random numbers at the same time or one at the time?

 

If one at the time, how could I generate a great number of random numbers at the same time?

 

Thank you. I'm new to labview but I have experience with matlab.

0 Kudos
Message 1 of 10
(2,984 Views)
Solution
Accepted by topic author RaphaelMT

You can enable parallelism in a FOR loop if you want to execute several iterations in parallel (assuming you have a sufficient number of CPU cores).

 

Still, just generating random numbers is very fast and probably will not benefit from parallelization, so do some benchmarks.

 

To generate an array of 100 random numbers, just use the tools in the signal generation palette. No loops needed.

0 Kudos
Message 2 of 10
(2,982 Views)

It was just an example to better understand how labview works so that in the futur, when speed is an issue, I have a better idea of how to program more efficiently.

0 Kudos
Message 3 of 10
(2,973 Views)

LabVIEW code, like C, Matlab, etc., runs "as fast as it can" unless you use one of LabVIEW's most interesting "primitives", the concept of Time.  In your sample code, you put in a "Wait for Notification" and specified 1 second to wait.  Without that, you would have seen your Loop counter running so fast you wouldn't be able to read the numbers.  With the exception of truly parallel threads running on separate cores in a multi-core machine, no digital computer does very much "at the same time" -- it just seems that way because it is so fast (in "human" terms).

 

So to generate 100 random numbers, just wire a For loop with N=100, put a Random Number function inside, bring the output through an Indexing Tunnel (the default), and when you push the Run button, you will "instantly" have 100 random numbers.

 

Bob Schor 

0 Kudos
Message 4 of 10
(2,968 Views)

What I mean is for exemple, on matlab, to generate a random numbers I could write it with a for loop and generate one number at the time:

for n = 1:1000000

rand(1);

end

 

or I could use the function:

 

rand(1000000,1);

 

Which will run about ten times faster on my current computer. The same way, I'm trying to learn the best way to write it as to not have labview wait unnecessarily when it's calculating.

 

Thanks for the help.

 

0 Kudos
Message 5 of 10
(2,961 Views)

I will admit that there are times when Speed is very important.  With LabVIEW, one way to speed things up is to do tasks in parallel, especially useful when some things (like File I/O and DAQ), things that use hardware, are often orders-of-magnitude slower than the "computing and logic units" in your computer.  You don't want a calculation (like an FFT) "slowed down" by being in the same loop that acquires the data, plots the data, and plots the spectrum (all three of which are likely to be slower than the FFT itself, even if you "code it by hand" without the optimization that NI probably is doing under the covers).

 

Otherwise, the other really important "speed waster" is Writing Sloppy Code.  Here the speed that is wasted is your time and effort (and trips to the Forum) trying to get the code to "do the right thing".  Simple, direct, straight-forward often takes much less time to code, much less time to debug, and will run at a speed within a few percent (probably) of a more complex "optimized" algorithm.

 

Get the code developed and "doing what you want" (as opposed to "doing what you told it to do" ... it should almost always do that, but it might not be what you want).  If it seems too slow, try to improve it, but if not, leave well enough alone.

 

Bob Schor

Message 6 of 10
(2,944 Views)

@RaphaelMT wrote:

 

Which will run about ten times faster on my current computer.


Unless your computer has at least 10 CPU cores, the explanation is NOT in the parallelization, but in a more efficient implementation. Maybe the upper code is inefficient and 10 times slower that it could be, even on a single core.

 

In general, writing code that avoids inefficiencies should be the goal. You can gain orders of magnitude in performance by a better implementation. Ensure inplaceness. Avoid data copies. You also cannot optimize code unless you have a way of reliable benchmarking. You can always parallelize it later. 

 

For some ideas, have a look at our presentation from a few years ago. I have code (details) that scales linearly with the number of CPU cores. Have a look at some of the benchmarks.

 

 

 

0 Kudos
Message 7 of 10
(2,922 Views)

@Bob_Schor wrote:

In your sample code, you put in a "Wait for Notification" and specified 1 second to wait.   


Where did you see "sample code"??? Did I miss something?

0 Kudos
Message 8 of 10
(2,921 Views)

Isn't the 10x speed diff in Matlab due mainly to .m scripts running in interpreter mode?  I recall how magically fast vectorized functions seemed to execute and used to commonly capture data in LabVIEW, post-process in Matlab.

 

I'll bet the LabVIEW explicit loop is closer in speed to vectorized Matlab than interpreted Matlab because LabVIEW code is *always* compiled.   Still, it'll be even better to use a built-in (and likely optimized) signal generation function as altenbach recommended.

 

 

-Kevin P

 

CAUTION! New LabVIEW adopters -- it's too late for me, but you *can* save yourself. The new subscription policy for LabVIEW puts NI's hand in your wallet for the rest of your working life. Are you sure you're *that* dedicated to LabVIEW? (Summary of my reasons in this post, part of a voluminous thread of mostly complaints starting here).
0 Kudos
Message 9 of 10
(2,920 Views)

@altenbach wrote:

@Bob_Schor wrote:

In your sample code, you put in a "Wait for Notification" and specified 1 second to wait.   


Where did you see "sample code"??? Did I miss something?


Oops, this is probably meant as a comment for another Post.  Traveling with Laptop (and working "en lap") can lead to misteaks ...

 

BS

0 Kudos
Message 10 of 10
(2,881 Views)