LabVIEW
Search and Erase Element from Array
@altenbach wrote:The use of Mathscript is no longer recommended and will probably cause a huge performance penalty in this case. For any graphical LabVIEW programmer, your code is incomprehensible and even mild dyslexia would interfere even more.
Well, MATLAB is not the fastest, but the code is clear more or less and compact. In my humble opinion, it's a bit too early to completely step away from text-based programming languages. Especially In terms of performance when compared to C, it is opposite situation - the native LabVIEW code incurs significant performance penalties. LabVIEW-generated code is generally quite slow.
Let me illustrate with this example. If I take your code and simply wrap it in a DLL, then perform simple benchmark:
The code behind the DLL call is quite simple:
typedef struct {
int32_t dimSize;
double elt[1];
} TD1;
typedef TD1** TD1Hdl;
ARRAYCLEANER_API void fnArrayCleaner(TD1Hdl LVarr)
{
int size = (*LVarr)->dimSize;
double* arr = (*LVarr)->elt;
size_t write_index = 0;
for (size_t read_index = 0; read_index < size; read_index++) {
if (arr[read_index] != 0.0 && !isnan(arr[read_index])) {
arr[write_index] = arr[read_index];
write_index++;
}
}
if (write_index < size) {
MgErr resize_err = NumericArrayResize(fD, 1, (UHandle*)&LVarr, write_index);
(*LVarr)->dimSize = (int) write_index;
}
}
Then I get around an 8x performance boost:
LabVIEW needs approximately 9 seconds for a 1GB array on my i7-4940MX, but the DLL takes only one second. For me, this is a huge improvement.
Just one more thing. Nowadays, I don't need to type text code completely. The cycle above was generated by AI; I just asked to remove zeroes and NaNs from the array, and the rest was done with Copilot. It works quite well:
It noticed that I was resizing a LabVIEW array and suggested the proper code, so I just hit <Tab> instead of typing. Amazing and looks like kind of magic
And here we have a disadvantage of modern graphical "ahead of time" programming — you can't get this kind of AI assistance at the moment at all. Previously, I usually wired LabVIEW code much faster than typing equivalent C/C++/C# code, but today this "gap" is not as large as before.
And that's not all. I'm pretty sure that I can break the one-second mark and get over a 10x improvement if I use SIMD commands. For example, with AVX2, I can compare 4 array elements against NaN and zeroes with just single command mm256_cmp_pd (the intrinsics will be turned into single CPU command):
The code will be faster (I need 4x less iterations):
__m256d zero_vec = _mm256_setzero_pd();
for (; read_index + 4 <= size; read_index += 4) {
__m256d vec = _mm256_loadu_pd(&arr[read_index]);
__m256d is_zero = _mm256_cmp_pd(vec, zero_vec, _CMP_EQ_OQ);
__m256d is_nan = _mm256_cmp_pd(vec, vec, _CMP_UNORD_Q);
...
but less readable, and as you wrote above, "this code 'is incomprehensible and even mild dyslexia would interfere even more," which is true, I agree. And in additional, I can do loop unroll, perform profiling with Intel VTune, etc...
This doesn't mean at all that every loop needs to be rewritten as a DLL, but if I have gigabytes of data for processing and need to process it really fast, then LabVIEW sometimes is not the best option. I can give more examples; for instance, SHA256 digest can be 5 times faster, etc., but this would be off-topic.
And I always remember the great quote from Donald Knuth: — 'Premature optimization is the root of all evil'
@Andrey_Dmitriev wrote:
@altenbach wrote:The use of Mathscript is no longer recommended and will probably cause a huge performance penalty in this case. For any graphical LabVIEW programmer, your code is incomprehensible and even mild dyslexia would interfere even more.
Well, MATLAB is not the fastest, but the code is clear more or less and compact. In my humble opinion, it's a bit too early to completely step ll evil'
Mathscript != Matlab
I did not say anything about Matlab. 😄
