LibVc with AVX

When libVc.a is compiled AVX code is added to it even though the target system only supports SSE. In order to understand why this is important one needs to understand the role of libVc and how Vc is used.

When Vc is built all that is actually created is a rather small static library that contains
  • constants
  • a library version check (you don't need impossible to debug errors if there's a mismatch between library and application code)
  • a function to check for the CPUs features
  • helper functions (math and sort are the ones that make sense here: if the function reaches a certain size it is better not to inline anymore - with larger vectors this can happen more often, because of combinatorics)

After Vc is built, libVc and the headers are installed and subsequently used in applications. Only when such an application is compiled must the user decide what system to target. This could be an SSE2 compatibility build, an AVX build for Intel Sandy-Bridge, an AVX build with FMA4 for AMDs Bulldozer CPUs, or even a build for a MIC system. When the application finally links with libVc it basically copies the things it needs out of libVc and into its own binary. Everything from libVc that is not required does not end up in the final executable.

This has an important implication on libVc, namely that it must work equally well regardless of the target system the application is compiled for later. Thus it must contain everything needed to create a non-SIMD, an SSE2, SSE3, ... , an AVX, an AVX + FMA4 + XOP, ... binary, even if the system where libVc is installed does not have the according hardware. (A common case where this can be really important is a cluster where the login nodes have different hardware than the compute nodes.)

Inclusion of full AVX support in libVc has a downside, though: Toolchain support (compiler, linker, assembler) for AVX is only good enough in recent toolchain releases. Many scientific systems use old or slow-moving distributions though, and thus have "broken" toolchains. Most of these problems can be circumvented by requiring GCC >= 4.5.3 for AVX, but there's no guarantee this will work for every borked system out there. This problem, of course, is the same for anybody that wants to compile an application for AVX, but most people that try Vc on a system without AVX will think about AVX only much later.

If libVc were not to contain the AVX support per default the intuitiveness of Vc would suffer. I.e. the headers allow to compile an application for AVX but at some point linking will stop with a useless error message. Thus I'd rather invest some effort to have AVX work out-of-the box whenever possible.