Hacker News Reader

Hacker News

Comment by pjmlp | Hacker News Reader

Full thread

pjmlp

All features that make C look high level nowadays, contrary to what many think.

None of them are exposed on ANSI C.

View on HN

Well, you can still use them in C/C++ code via:

#include <mmintrin.h> // Intel MMX

#include <xmmintrin.h> // Intel SSE

#include <emmintrin.h> // Intel SSE2

#include <pmmintrin.h> // Intel SSE3

#include <tmmintrin.h> // Intel SSSE3

#include <smmintrin.h> // Intel SSE4.1

#include <nmmintrin.h> // Intel SSE4.2

#include <ammintrin.h> // Intel SSE4A

#include <wmmintrin.h> // Intel AES

#include <immintrin.h> // Intel AVX

#include <zmmintrin.h> // Intel AVX-512

#include <arm_neon.h> // ARM NEON

#include <mmintrin.h> // ARM WMMX

And a full list of what is possible in Microsoft Visual C: http://msdn.microsoft.com/en-us/library/hh977022.aspx

Now the reason why they are not in ANSI C is that low-level CPU features (just like raw instructions) are not portable by nature.

Where are the headers for out-of-order execution, cache levels, execution pipelines, ...?

Additionally not all C compilers provide such headers.

Even if one programs in assembly, such features are a "black box" because instruction sets rarely provide any instructions for controlling these things, apart from issuing cache prefetching hints which are not mandatory for the CPU to honour.

There are a lot of prefetch instructions and write-barriers in the available intrinsics:

http://msdn.microsoft.com/en-us/library/hh977022.aspx

I do not think one has full control over OOO execution on x86-64 processors. Also I do not believe one has control over the execution pipeline even in assembly, although I do not know exactly what you mean by that, so it could just be a misunderstanding.

My whole point is that this isn't C any longer, it is Assembly.

But assembly doesn't have instructions for "out-of-order execution, cache levels, execution pipelines, etc"

That is what Assembly data sheets provide.

And headers for memory subsystem (DDR SDRAM)! I mean, I know usually there's cache line sized interleaving repeating for each memory channel, but it would sure be nice to reliably control which memory access goes to which memory module.

With NUMA physical memory ordering gets even uglier, usually each physical socket's memory is in a big chunk, but sometimes it's also interleaved every 4 kB.

ANSI C doesn't expose any intrinsics, but once you get used to GCC extensions and attributes, it starts to feel a lot more "low-level". Think of __builtin_expect, __builtin_prefetch, alignment attributes, etc.

That is compiler specific without any portability guarantee to another compiler, you can just write Assembly instead, for what is worth.

It's not quite like writing assembly because these intrinsics are meant to translate to the "best" instructions for the particular ISA that the code is targeted for. You are able to compile the same chunk of code for two different architectures, for example. If you were to write inline assembly, you would be forced to have a separate chunk of code for each architecture and surround them with #ifdefs.

Assuming the same compiler is used.

The code can be made portable with a few simple macros (which is why they are implemented they way they are in GCC), though the optimizations will not be.

From the Linux kernel:

    struct boot_params boot_params __attribute__((aligned(16)));

    #if !__GNUC__
    #define __attribute__(x)
    #endif

I think that's a better way to do it than ASM (which totally hoses your portability).

For alignment yes, but that is not the case across all extensions.

Some of them are no different than just writing plain Assembly.

The __builtin_ methods mentioned by the grandparent are functionally identical to the associated libc methods, so they can be #defined away as well.

Are there any 'finished' language giving access to the whole machinery ?

As far as I know, no.

Hence why even if C looks like a portable high level Assembler, there are many modern CPU features not available.

Even most common extensions just cover part of them.

So who uses these features then?

Wild guess: libs (intel cilk?), compiler intrisics through reified assembly.

I've used a lot of SSE2 and prefetch instincs in Visual C++ for math / data heavy high performance computing applications. It can make a fairly big different -- like more than 50% performance improvements for key parts of the code.

That depends heavily on with CPU and memory subsystem combination you're running it on. You need to know how far to prefetch and how to order your data in memory.

Games on consoles, where the hardware architecture is frozen and you can optimize to the metal all you want.

Not all titles do this, since most titles are cross-platform and you're not going to do tons of optimization for a specific one unless there is a huge payoff.

It is done on PC as well, but we can't assume very recent instruction sets. We'll have to do with semi recent instruction sets.

Specialized HPC workloads

Many of the capabilities described in the article are just hardware features which don't need any control from application developers, but their effectiveness can be improved if the developers are aware of them (e.g. caches, TLBs). Others properties are exploited automatically by compilers (e.g. instruction scheduling for improving throughput in a superscalar processor)

Instruction set extensions (which I believe might be what you were thinking of) are used via intrinsics and assembly programming by pretty much any performance-oriented code. For example look at the dozens of architecture-specific implementations of glibc functions: x86-64[0], arm[1].

[0] https://sourceware.org/git/?p=glibc.git;a=tree;f=sysdeps/x86... [1] https://sourceware.org/git/?p=glibc.git;a=tree;f=sysdeps/arm...

> Even most common extensions just cover part of them.

The headers I linked to here: https://news.ycombinator.com/item?id=8873764 Cover most useful Intel CPU extensions. And you can use them easily in code, it just sucks when you have to do CPU feature detection and have different code paths for different CPUs.

> it just sucks when you have to do CPU feature detection and have different code paths for different CPUs.

In the Linux kernel they went so far as to actually replacing instructions at boot-time at known locations, based on the capabilities of the CPU the code is executing on. This prevents them from maintaining many paths in the compiled code.

Yes, but as I answered they are compiler specific and cover only part of the CPU.

Reply on news.ycombinator.com