LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Overhead when calling DLL

Hi,
i created a C++ DLL in order to use libtorch tensors in LabVIEW and do tensor calculations on the GPU.
Everything works very well so far. I can create tensor, move them to and from the GPU, update the data in and do arithmetic manipulation to it.
I can also move the tensor back to the CPU and pull out the data to move it back into a LabVIEW array.
But i have a weird phenomenon.
If I call teh Pull VI in my testing vi, the VI needs around 400ms to execute. But if i time the content of the Pull VI within the VI itself, it only takes 30ms.(VI content see pictures)
Am I missing some sort of pre loading of the DLL? How can I reduce the execution time of the VI to match the VI content itself?

- KP

Download All
0 Kudos
Message 1 of 2
(238 Views)

Always very difficult to debug pictures. But I would say there is quite a bit going on besides the actual "Pull" Vis.

 

None of the Pull VIs should take significant time to execute  (unless there are inefficiencies in the according VIs, underlaying DLL functions, threading synchronization issues and such beautiful nasties) as it is just a read of a path and a pointer value. However your pulling out of the data array from the class is pretty useless other than to predefine the (hopefully) correctly sized array. A Create Array with the correct size, with the size possibly "pulled" out of the class with another pull VI would be performance wise exactly the same since LabVIEW has to create a copy of the array on the diagram to use for the Call Library Node and pass back to the caller. And that MoveMemory like Call Library Node could consume quite a bit of execution time in itself, depending on the size of that array.

 

Lots of hidden and unknown details, so a more detailed recommendation where the problem might be is almost impossible.

 

One thing to consider: You use the dynamic loading for the MoveMemory function. That DLL needs to be loaded of course, the first time you execute the VI. If the DLL is already in memory from other calls that should be fairly quick but if it is not, 400 ms loading time is nothing shocking if it has some dependencies. Once the VI is loaded it should be fairly quick. Also when you execute the VI again, the Call Library Node remembers what DLL it had loaded and does a quick comparison with the passed in path and if they are the same simply reuses the previously loaded DLL.

 

So in your testing VI you load the VI into memory, and the Call Library Node hasn't loaded your DLL yet and therefore does so. When you execute the VI a second time without unloading it it should be faster. In your real program this VI is one of many and the DLL was most likely already loaded by some other code somewhere. No need to load the DLL again and the necessary linking is done almost instantly to the already loaded DLL. Next time the VI is called again, LabVIEW notices that the path did not change and simply uses the already present linker information to call into your DLL.

 

In short, it seems an impressive work as indicated by the fact that you seem to have created class hierarchies for various array datatypes, and while it seems to be working (which is already a feat in itself) pulling out of the data arrays might still likely be suboptimal and for large arrays, that can really add up.

Rolf Kalbermatter  My Blog
DEMO, Electronic and Mechanical Support department, room 36.LB00.390
Message 2 of 2
(229 Views)