Doubts about speed

[Stgo]

Hello gentlemans;

I have a couple of questions i would like to ask to the more experienced people here. I have a program running in a computer which has as a processor an i7. In this computer i program in LabVIEW, meanwhile in other lab we have another PC, a little more old, a dual core 2.3Ghz, in this pc we execute a test platform for a couple of modems, let us not enter in details, not necessary.

My problem is that i recently discovered that my program, which i programed in the i7 machine, works a lot more slow in the other machine, the dual core, therefore the timings are all wrong and the program does not run correctly. For example there is an array with 166 values, which in the i7 machine are filled quit fast, almost with no delay, however, in the dual core machine it takes a few miliseconds to fill around 20 values of the array, and because of the timing it cant fill more values and therefore the waveform i use is all wrong. This, of course, screws the whole program and i can not use it as a test that i need to integrate.

I create a .exe program in labview, and try it in the differents PCs that is how i got to this issue.

Now, i want to know if there actually is a big issue because of the computer characteristics, that the program is slow in one machine. I know that, for the program to work eficiently, i need to use states machines, sub-vi, producer-consumer idea and stuff. However i have discovered that is not a problem of the speed generated by the program, because, if it was the case, the array would be eventually filled up completely, however in the slow computer, it does not fills more than 20 values.

Other thing, does it help to hide useless variables in the frontal panel?, for the time beeing i keep track of a lot of variables inside the program, so when i create the .exe i still see them runing to keep it tracked. In the final version i wont need them so i will delete some and hide from frontal panel some. Does it help to require less requirements?

I would like to read your comments about it, if you have any ideas besides states-machines, sub-vi etc, if there is a way to force the computer to use more resources in the Labview program, etc.
I am not adding any VI because, at current state, i know you will tell me states-machines, sub.vi and so on, and i believe that the main problem is between the difference in the computers, and i am still working in the state/subvi/etc things.

Thanks again, let us talk this trough.

Kind regards,

Stgo.

[DFGray]

There are several ways to initialize and fill arrays.  Depending upon how you do it, you can get differences of up to four orders of magnitude in speed (see this post for a similar issue).

Also, front panel controls should never be used to store data.  For this purpose, they are slow and subject to race conditions.  In LabVIEW, the wires are the variables.  Variable storage can be done in many ways, but we need your code to determine what would be correct for your case.

I have done real-time audio processing using LabVIEW on a computer with a 233MHz Pentium.  Paying attention to your algorithms makes all the difference.  Use the buffer viewer to make sure you are not hitting the memory manager more than necessary.  Use the In Place Element Structure and array based operations as much as you can.

If you need more info, please post your code.  We can help a lot better when we know where you currently are.  We were all new programmers at one point or another.

[Yamaeda]

"A few miliseconds to fill around 20 values of the array" - that sounds very slow if it's done with code. If there's some instrument communication it's quite reasonable.

Even with a dual core creating a 2000 value array is less than 1 millisecond.

If you're using front panel objects as data storage, and especially if writing to them through property nodes it'd explain the slow speed. The solution in this case is ofc to store the array in shift registers, either in the main program or in an Action Engine, AE.

/Y

[RTSLVU]

You really need to post your code or at least the section that you feel is running too slow so we can offer alternatives.

[Stgo]

Ok, i will add the vi.

Consider the following,

What this vi does is that it generates a random impulse of 166 samples. Its activation is generated because of the probability chain in the same program, this is the center main structure in the vi. It depends on a random number (probability) in which, in every case is different probabilty.

So, we have 6 big structures.

1.- Decide if there will be an impulse or not ("Markov Chain")

2.- If there is impulse, generate values for the array, else, generates only 0 in the array.

2.1 .- The generation is limited by an Amplitude range structured, which also have probabilitys of being high or low.

2.2 .- Once the amplitude value and the fact that there will be an impulse are done, it generates the Array it self, and of course the graphic for the waveform.

3.- Send the data to my Hardware ( a signal generator which had drivers for Labview ), this one generates the waveform created by the program.

There are two small boxes which control the position of the array in order to move it from the first place and so the array be filled with different numbers. And there is the impulsive activation, which says to the program that if there is an impulse, generates the values, else, allx0 and i have 0 amplitud.

Please, be patience, i know i have to make some state-machines for the boxes inside Markov Chain ( in fact, that i discovered not so long ago ) and im thinking of making most of the parts as Sub-vi.

So, the problem is that, i run it in the fast computer and it generates the 166 values really fast, but in the other it fills around 40 now ( i have deleted a lot of things i had, some boolean leds that i used to keep track, some numerical variables that counted the loops and so on ... ).

I believe that if the problem was the states-machines, sub-vi and so on, the i would have the same problem in both computers, since the program would no be optimal for both cases, but since it just happens in the other computer i dont get it.

Any advice is welcome, again, be patience, i know i can improve it a lot.

Thanks for your comments.

kind regards,

stgo.

[RTSLVU]

Wow you really need to learn how to use data flow. You have a bunch of independent loops creating race conditions. No wonder you are having issues when using a different computer.

Lose all the stacked sequences

I suggest a state machine

Add a error cluster and use it for flow control

[camerond]

Well, not only are there so many semi-independent loops (interconnected by local variables), but four of them (all connected by some of these local variables) are all greedy, running as fast as they can and taking up all available CPU time that they can grab. This slows the program down and prevents user interaction (user "can't get a word in edgewise"), as well as producing the race conditions.

Do you realize that you took out all of your outputs (indicators and wires to other places in the program) in several of the frames of your middle (long) sequence (I assume there were some in there at some time), so they send answers to nobody?

Cameron

[Yamaeda]

I assume formula nodes are alot slower than G, and:

"y=x;
if(y<99)
z=0;
else{
z=1;
t=1;}
if(y<99)
t=0;"

Is easily reproduced as a case structure. (Also, the 2nd if should be included in the 1st).

It looks simple enough to make right, one big issue is the top generating loop, being greedy and only feeding the VISA loop in the bottom. Combine them so you only create an array once per VISA command.

/Y

[Stgo]

First of all, thank you for your answers.

Now i see a little more of what i should do, but there is a thing, this is not the first time someone told me about the dataflow, i will research about it right now but, can you explain me a little bit how to fix this in my VI ?. Anyway i will read about it.

I will work in the state-machine thing today, and probably in some more other issues, while i wait for more alternatives from you. Still, i have a couple of questions :

- Will it help making the state-machine?

- Will it help to put everything inside the same loop ?, hence, eliminating all the greedy loops?.

- Also, for Yamaeda, i tried to add the second if in the first but for some reason, at that time, the program didnt compile therefore, i just used this way. Can anyone confirm that the formula nodes is slower ?, if this is it i will change that.

Thanks again for your advices, i am currently working in the inprovements.

Kind regards,

stgo.

[RTSLVU · Accepted solution]

Well to start with using proper data flow like a state machine you can insure your big array would always be filled completely before moving on, no matter how long it takes. Believe it or not adding a delay to your loops will make the over all program run faster and smoother because while loops are greedy and can consume 100% of the CPU time just looping waiting for a button press, meanwhile all the other processes are struggling for CPU time.