Porter Posted October 2, 2021 Report Share Posted October 2, 2021 I'm just going to throw this out there... LabVIEW's included mean value of array function calls and external dll (lvanlys). It takes close to twice as long (depending on array size) to execute than just doing a native sum of array elements then divide by array size. Is there any advantage that the lvanlys function has over this simple native mean? Why aren't most of the lvanlys functions implemented as native LV code instead of a dll? I'd imagine that we could get some performance boost on some of them by using inlining, VIMs, and parallelized loops. Mean Value Test.vi Mean Value Test SGL.vi Quote Link to comment
Antoine Chalons Posted October 2, 2021 Report Share Posted October 2, 2021 The lvanlys will return an error code if there is a NaN in the array, this extra feature probably explains a part of the difference in exec time. 1 Quote Link to comment
Lipko Posted October 2, 2021 Report Share Posted October 2, 2021 (edited) In case summing array elements then dividing with the array size, there can be overflow error if the array size is big (or whatever size). Maybe lvanlys uses the cumulative average method or whatever it's called. In short, don't use that "dumb" mean algorithm. Edited October 2, 2021 by Lipko Quote Link to comment
Porter Posted October 3, 2021 Author Report Share Posted October 3, 2021 9 hours ago, Antoine Chalons said: The lvanlys will return an error code if there is a NaN in the array I couldn't get it to return a non-zero error code. I tried Inf and NaN in the array. 8 hours ago, Lipko said: Maybe lvanlys uses the cumulative average method Dividing once for each element feels expensive. It doesn't seem like lvanlys uses it either. Both the native "dumb" mean algorithm and lvanlys overflow around the same value. Whereas a divide at each element algorithm can handle higher values. Mean Value Test.vi Quote Link to comment
Neil Pate Posted October 3, 2021 Report Share Posted October 3, 2021 Also I think the Mean VI coerces the inputs to DBL. This is not always desirable. Maybe time for a native VIM? Quote Link to comment
Porter Posted October 4, 2021 Author Report Share Posted October 4, 2021 Anything else that should be VIMed? Median, mode, standard deviation? Everything NI_GMath and NI_AALbase please. They greatly impact application build time. Quote Link to comment
mcduff Posted October 4, 2021 Report Share Posted October 4, 2021 (edited) It looks like the external dll call has an extra buffer allocation, don't know if it is real or not, just what NI is reporting, whereas, the native implementation does not. See below. That may account for the speed difference. EDIT: Execution Trace toolkit shows the same. Edited October 4, 2021 by mcduff Addition Quote Link to comment
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.