immintrin.h support in LabWindows/CVI?

[Cklai]

I have previously used GCC compiler to compile my dll and it worked flawlessly when it is run inside the host PC. However, when I move the same vi into the RT target (PharLap OS), it couldn't run and give me an error 1097. (Any advice on this as well?)

So, I suspect that this has something to do with the compiler, and hence decide to compile using LabWindows/CVI with built-in clang 3.3 compiler as it has the option to compile to real-time-only runtime. When I tried to create a custom compiler and additionally enabling -mavx flag for the build-in clang 3.3 compiler (see attachment below), the immintrin.h file couldn't be found.

Does LabWindows/CVI compiler support AVX instructions? If so, how do I add the immintrin.h file into it?

[Cklai]

edit*:  For some resason, clang couldn't resolve -mavx and -march=arch flag? Is there really a limitation in using dll in real-time target?

[rolfk]

Yes there certainly is. There are two main problems:

1) The Pharlap ETX OS only supports a subset of the Win32 API. It is basically the Windows NT 4 API except support for OLE,  user permission stuff and other such things that make not so much sense on an embedded system.

2) If you compile your DLL with anything but Visual Studio 6, (that includes just about every version of GCC derived compiler too), your DLL links with a compiler version specific C Runtime library. This runtime library needs to be installed on the Pharlap ETS, but all modern C Runtime libraries make use of some Win32 APIs for runtime initialization, exception handlers and such that are not supported by the Pharlap ETS Win32 API.

NI purchased the right from Microsoft to port their C Runtime library to Pharlap ETS and it has created certain versions of it that you can install on the Pharlap ETS. There are no other C Runtimes available to install on the Pharlap ETS system and porting another C Runtime version for any compiler, while not impossible is a very substantial work.

[Cklai]

Hi rolfk,

Thanks for replying to my message. I now understand the severe limitation in using PharLap ETS, and LabWindows/CVI too as it is designed for outdated compilers. This means that LabWindows is a no-go for compiling AVX instructions.

As AVX instruction sets only started from 2010 onwards, is it true to say that the only way to compile this and get it work in PharLap OS is to compile through Visual Studio 2010? (the link you provided did mention support for 2010 version) 

As I am planning to implement the controller to PXie8880 and 8135, one possible solution to do this is to migrate the OS to Linux RT for PXIe8880 so I may have the chance to use gcc compiler. What is the limitation for Linux RT for dll then? Will migrating it help fix the problem?

If it's still not possible, is there any other suggestions in implementing this algorithm in RT target? I am thinking in downgrading AVX to SSE2 if there is no other choice...

[rolfk · Accepted solution]

You really like to run cutting edge border line, don't you?

The first AVX capable chips were in the Intel Sandy Bridge/Ivy Bridge and AMD Bulldozer/Piledriver with Sandy Bridge being presented in January 2011 and Bulldozer/Piledriver in October 2011. So even if Microsoft was blazing fast to add support to their C compiler for this new architecture (which they usually aren't), it would be impossible to have that added in Visual Studio 2010.

And it is not enough that a compiled object code makes use of the according instructions, the OS on which it runs needs to be able to recognize and initialize the CPU correctly for this to work. Which Pharlap ETS definitely and positively won't do. Pharlap ETS was put in maintenance mode somewhere around 2008 and completely discontinued in around 2013. Only customers with an existing and valid license agreement at that time were still able to get the SDK downloads and technical support. And since 2013 you only can buy runtime licenses from them if you have an active agreement with them and you can't enter such an agreement anymore.

SSE2 should be ok on Core2 or newer CPUs as well as AMD K8. Your 8880 controller uses the Xeon E5-2618L CPU which is a Haswell core and would support up to AVX2. But you would need the variant with Windows 7 or Windows 10 or with NI Linux RT installed to have any chance. As far as NI Linux RT goes it should be ok, although I'm not sure if the NI variant is compiled with AVX support enabled. The first kernel which had support was apparently 2.6.30 and NI Linux RT uses normally at least 4.1 or higher. But during the compilation of the kernel that needs to be enabled and there might be reasons not to enable that for a RT system. 

[Cklai]

Well, apparently my project requires high performance and thus every performance counts. 😞 I only have submitted one of the dll, and there are more .dll that uses AVX coming along.

I don't really understand your last paragraph... do you mean that NI Linux RT might not have AVX support as well? This is a bummer for such powerful hardware, to be honest.

Regardless, I have decided to try it out on the 8881 controller first before migrating it to Linux OS for the 8880. Currently I have Windows 10, so it hope it should turn out well.

[gdargaud]

If you need high performance, what are you doing playing with PharLap ? It's convenient to be able to develop on CVI and compile/execute remotely with the click of a button, but seriously, get a Linux board that fits your needs (with or without accelerated GPU you can tap into), and cross compile with "gcc -native" to get fully optimized code for your architecture.

Some cross compiling toolchains can be setup in a few minutes. Then use CVI as a control/command post and communicate via USB, TCP, whatever...

Of course, for real-time performance, get a board with an on-board FPGA and do all the real-time stuff there, no need to mess around with 'real-time kernel' shenanigans.

[rolfk · Accepted solution]

---

@Cklai wrote:

I don't really understand your last paragraph... do you mean that NI Linux RT might not have AVX support as well? This is a bummer for such powerful hardware, to be honest.

---

Well, first let me state that I do not know if the NI Linux RT kernel comes with what AVX support enabled, if any. It's a simple switch in the kernel compilation configuration that controls this. And NI Linux RT is not necessarily meant to squeeze out the latest and greatest CPU features. RT has other requirements that weight a lot more, such as being able to respond within a guaranteed time limit to any event as well as high reliability. If a CPU feature might possibly compromise any of these criteria, no matter how small the chance, it is simply disabled. That's not a bummer but a conscious choice!

If you want RT then you have to live with certain limitations, if you want highest super duper performance, that comes with other limitations. In technology it's almost never that you can get the cookie and can keep the cake too. 😀

[Cklai]

Update for Linux RT: Based from the development Tools C/C++ for Eclipse downloaded from National Instrument, it appears that immintrin is indeed supported in the built-in gcc compiler. -fma and -mavx2 flag works too. I guess Linux RT is the way forward then. Will further update when I verify my dll code in the target.

[rolfk]

Definitely check on the hardware. The fact that the compiler toolchain supports a feature doesn't mean that a specific kernel version needs to enable it.

Basically unless the kernel guys decide to hack in assembly, which they don't do for a long time already, in order to support a feature in the kernel the according GCC toolchain must support it. The opposite is not true however. Such features are simply a configuration switch during the kernel build and can easily be disabled for any reasons when building your own kernel. You would have to check in the build scripts for the NI Linux RT kernels to be sure.

Kernel sources: https://github.com/ni/linux

Kernel build tools repository: https://github.com/ni/nilrt

The problem is that there are various kernel versions that relate to specific LabVIEW RT versions and there is of course a potential difference between them too.