LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Increasing Execution Speed


@Serge1 wrote:

This extraction of bit from byte is indeed performed in the subVI. This is one of the most time consuming operation. The figure is attached.

 


 

This is NOT a time consuming operation and is still peppered with unnecessary coercion dots that can cause additional copies of data in memory (unless the compiler can untangle the mess!). How does it look for multiple channels? What else is happening? This part is most likely orders of magnitude faster than the communication overhead. I am pretty sure you are searching under the wrong rock. At this point is is extremely important that you learn about datatypes and coercion. So far you completely ignored that aspect. (read e.g. here , here, and here)

 

  • Which of your subVIs contain that code fragment? Is there a reason you cannot show all code?
  • Why does "get streaming values" only output scalars?
  • Where else does digitazing5 get new values to process? The array input shown is loop invariant.
0 Kudos
Message 21 of 31
(610 Views)

I have implemented all optimizations that has been suggested. It managed to get a considerable increase in speed. So, now I can work with extraction of one channel and searching 2 trigger, the minimum requirement fulfilled. Thank you to everybody for their suggestions. 

 

However, the safest way is to work with 3 separated digital channels. When I added extraction of other 2 bits the computer became slow again. So this subVI seems to take time. Is it possible to get these 3 bits in faster way? The current implementation is shown here and the code is attached.

first 3 bits.png

In the previous post this was all code of subVI digitazing5. The change from U16 to U8 was made to reduce the data for further use. 

 

>Where else does digitazing5 get new values to process? The array input shown is loop >invariant.

 

No, it is not invariant. The scope is in the streaming mode. So, this array of 1E6 integers is always updated with new values.

PicoScope3000aGetStreamingValues.vi gives the position of new data, which have not been proceed yet and the length of this new data. 

0 Kudos
Message 22 of 31
(577 Views)

@Serge1 wrote:

No, it is not invariant. The scope is in the streaming mode. So, this array of 1E6 integers is always updated with new values.

PicoScope3000aGetStreamingValues.vi gives the position of new data, which have not been proceed yet and the length of this new data. 


You need to explain to me where this array is updated. Not anywhere we can see!

 

altenbach_0-1598291433547.png

 


@Serge1 wrote:

However, the safest way is to work with 3 separated digital channels. When I added extraction of other 2 bits the computer became slow again. So this subVI seems to take time. Is it possible to get these 3 bits in faster way? The current implementation is shown here and the code is attached.

first 3 bits.png

In the previous post this was all code of subVI digitazing5. The change from U16 to U8 was made to reduce the data for further use. 


So now you are taking a I16 array and triplicating it, wasting 48bits for 3 bits of information! This is simply not right! I am sure there is a better way!

 

 

 

0 Kudos
Message 23 of 31
(572 Views)

@altenbach wrote:

@Serge1 wrote:

However, the safest way is to work with 3 separated digital channels. When I added extraction of other 2 bits the computer became slow again. So this subVI seems to take time. Is it possible to get these 3 bits in faster way? The current implementation is shown here and the code is attached.

first 3 bits.png

In the previous post this was all code of subVI digitazing5. The change from U16 to U8 was made to reduce the data for further use. 


So now you are taking a I16 array and triplicating it, wasting 48bits for 3 bits of information! This is simply not right! I am sure there is a better way!


Perhaps something like this? Note the parallelism enabled.

optimization.png

Redhawk
Test Engineer at Moog Inc.

Saying "Thanks that fixed it" or "Thanks that answers my question" and not giving a Kudo or Marked Solution, is like telling your waiter they did a great job and not leaving a tip. Please, tip your waiters.

0 Kudos
Message 24 of 31
(559 Views)

@FireFist-Redhawk wrote:
Perhaps something like this? Note the parallelism enabled


I have not tested, but my gut feeling is that the bitwise operation is so fast that splitting the problem into parallel instances, then reassembling the result will actually slow you down. (And I doubt that the inplace structure makes any difference. I count exactly the same number of allocation dots).

0 Kudos
Message 25 of 31
(547 Views)

@altenbach wrote:
I have not tested, but my gut feeling is that the bitwise operation is so fast that splitting the problem into parallel instances, then reassembling the result will actually slow you down. (And I doubt that the inplace structure makes any difference. I count exactly the same number of allocation dots).

I've never had to optimize something to this extent so maybe I'm just out of my depth here 😅 but I only added the IPES because it got rid of several allocation dots, most notably the one after the AND (which I thought was the one that might possibly speed things up a smidge). To be honest, I'm not even sure why the other 3 disappeared, but then again I do know enough to know how little I know about LV.

FireFist-Redhawk_0-1598300140547.png

 

Redhawk
Test Engineer at Moog Inc.

Saying "Thanks that fixed it" or "Thanks that answers my question" and not giving a Kudo or Marked Solution, is like telling your waiter they did a great job and not leaving a tip. Please, tip your waiters.

Message 26 of 31
(540 Views)

Altenbach - I haven't downloaded the drivers to check, but there was a discussion about PicoScope 3000a drivers breaking dataflow.   (data gets magically/asynchronously updated, changing the data on the wire magically in the background)  See - https://forums.ni.com/t5/LabVIEW/When-is-dataflow-not-data-flow-Updating-LabVIEW-Arrays-through/td-p...

 

That's the only way I can see his data being updated given the code shown.  If that's the case his code could be making attempts to use full/partial/empty arrays. 

0 Kudos
Message 27 of 31
(527 Views)

@FireFist-Redhawk wrote:
I've never had to optimize something to this extent so maybe I'm just out of my depth here 😅 but I only added the IPES because it got rid of several allocation dots, most notably the one after the AND (which I thought was the one that might possibly speed things up a smidge). To be honest, I'm not even sure why the other 3 disappeared, but then again I do know enough to know how little I know about LV.

FireFist-Redhawk_0-1598300140547.png

 


 

I also get an allocation dot on the right arrow input to the IPE. (LAbVIEW 2020). I am curious why you don't see that.

 

In any case, the 1D input array cannot be shared or re-used between instances, so a new copy needs to be made for each iteration, then reassembled into a 2D array which you then split up.

 

The original code does exactly the same parallelization if the compiler feels it is necessary.

 

In terms of array allocations, I see the following:

 

altenbach_1-1598304482189.png

 

Curious why you don't see some of them....

 

0 Kudos
Message 28 of 31
(510 Views)

@cstorey wrote:

Altenbach - I haven't downloaded the drivers to check, but there was a discussion about PicoScope 3000a drivers breaking dataflow.   (data gets magically/asynchronously updated, changing the data on the wire magically in the background)  See - https://forums.ni.com/t5/LabVIEW/When-is-dataflow-not-data-flow-Updating-LabVIEW-Arrays-through/td-p...

 

That's the only way I can see his data being updated given the code shown.  If that's the case his code could be making attempts to use full/partial/empty arrays. 


Ah, what a mess.

 

Still, can you explain in simple terms how the data looks like and what you are trying to get out of it. It seems you are trying to find all low-> high transition on a particular bit. How does the rest of the code look like if you do multiple channels?

0 Kudos
Message 29 of 31
(504 Views)

Thank you, it seems to be the case. We  never have partially or fully empty array. As far as I understand it, the data coming via USB3 are written by driver of Picoscope directly to the memory allocated for this array. So, we are getting dynamic update of the data. The new data writes to the end of the array and shift the old data to the beginning. 

0 Kudos
Message 30 of 31
(478 Views)