LabVIEW (NI) dll - parallel processing (lvanlys.dll)

[James_W]

I've got some parallel processing going on - lots of it, and I seem to have a bottle neck that I can't get rid of in the call of LabVIEWs internal mathematical functions.

looking at the VI, it's calling lvanlys.dll (but this is not included in the compiled build output)...

I have already got Pre-allocate clones turned on and 50+ parallel calls but I can't get the processing time down.

I'm not convinced that I'm not losing time to a dll call out - but I could be mistaken.

Any optimisations with a 2D array/matrix that I might have missed or caveats with Maths functions for DLL calls that I might not know yet please.

(Can't post code - it's commercially sensitive unfortunately)

Thanks for any tips

James

[rolfk]

While everybody can understand that you might not want to post your actual code, and in fact rather does not want to open a 500 VI project and try to find where in that monster the problem might be that you describe, it is definitely helpful if you do a little more effort from your side to make it easier for the forum members to actually help you.

That usually means to cut down your problem to an absolute minimum set of VIs that actually still reproduces your problem. This you can then post here without spilling your company secrets. It also might prompt you to look at the problem from a different angle and actually find out on your own some possible problems.

An open ended request for the community's wisdom on performance bottlenecks or improvements is basically almost always doomed, since there are virtually an infinite amount of variables that can influence your specific program and cause the problem you see.

[altenbach]

It impossible to tell where the bottleneck could be without knowing significantly more about the program architecture AND the hardware it is running on.

Is each parallel instance churning bits like crazy or do they have breaks where the core can be used by other parallel instances? How many real CPU cores do you have? This will give you an upper asymptotic limit on parallelization advantage.

Are you (A) splitting up a big matrix operation into multiple parts or (B) is each parallel instance working on it's own isolated matrices? In case of (A), you might look into this toolkit.

[James_W]

Oooo,
Two replies from two of what I think of as "the big Guns"! 
I feel truely honoured.
I've inherited a project running on 40+ Cores of a Win Server machine.

Multicore and sparse analysis toolkit has already been put in play by a previous developer.
I thought timing was my issue.
I turns out that after my "optimisation" I've got a bigger problem, - I've multiplied a memory leak in the pre-processing funciton.

Hunting it down using DETT and Performance Profile Tool

I'm sure it's in the processing loop but my array sizes are 20K+ 2D DBL arrays and I'm processing 50 of them in parallel (using classes and re-entrant VIs).
Going through the code I'm trying to work out where Memory reallocation is taking place (and therefore loss of large contiguous memory chunks could be happening - which I think is the cause of my memory leak, although I am running at Max speed so the garbage collector doesn't have much time to act.)

(Also using lots of previous posts from both of you as guidance of good memory management practices to try and fix this)

(To answer your question Christian - it's B, but they are all a subset of the original mega dataset, so B&A may be possible)

Thanks Rolf & Christian,

James