LabVIEW compiler and modern CPUs

[cordm]

Recently, we tried to find ways how we could speed up a data analysis pipeline of ours and the topic of vectorization came up. LabVIEW seems to sit at the SSE2/SSE3 level of processor features, judging from the system requirements listing a Pentium 4 G1 as the minimum for the 64 bit version. (I am not sure which Processor that is, I think maybe the Prescott line from 2004?) There is a five-year-old idea to offer better support for SIMD instruction without comments. Then there is a ten-year-old topic on lavag (LLVM and LabVIEW) with a single response from an NI employee about the introduction of LLVM into LabVIEW. So I suppose it is not exactly a hot topic for LabVIEW users in general.

Is there any plan to surface more customization abilities of the underlying LLVM compiler concerning vectorization?

On a related note, does the LabVIEW-Runtime have different code paths for different architectures? I know Intel MKL can does runtime checks for this, so maybe lvanlys.dll and others can do something similar?

[rolfk]

There are two very different topics interwoven in your post. The first is the LabVIEW compiler itself. I'm pretty sure it does at least some SIMD if available but likely not a lot. However I'm also pretty sure that you will be hard pressured to find an example where that would be very much important.

Then there is the MKL you mention and how that might relate to the lvanlys.dll. Incidentially, lvanlys.dll is since about LabVIEW 7.1/8.0 a thin wrapper around the MKL. Its task is basically to interface between the MKL functions and the LabVIEW type of interface that was created by NI with their own Advanced Analysis library before they switched over to replace it with the Intel MKL.

So whatever the MKL does you will get gratis and free when you use LabVIEW AAL Analysis functions.  

[tst]

One interesting possibility I see from these links is Emscripten, which says it can compile any LLVM code into WebAssembly. I wonder if NI could use that to make LV code run web apps or whether LV uses LLVM just to generate the machine code for each VI and all of the infrastructure of calling and linking the VIs make this irrelevant. I'm guessing it's the latter and that NI probably wouldn't make the effort even if they didn't already have the G web development product.

[rolfk]

It definitely would need work by NI. I did not yet read the whole Emscripten documentation, but I would think it is basically simply another LLVM backend to create code from an LLVM FrontEnd. NI implemented a multi layer approach where the diagram is first translated to DFIR to be optimized in LabVIEW specific ways and then through an LLVM frontend is passed to the LLVM system. Then there is a LLVM backend for the specific CPU architecture and the code for that is fed back into the machine code execution system, either being stored in the VI itself or being committed to the compiled code cache with a unique identifier for the actual VI/architecture.

This all is in the dark and for us mere mortals not accessible. And it would also not be trivial to redirect this to a Web Server to be executed as a Web Assembly even if we had access to the selection of what backend is used for code generation.