Hacker News Reader

Comment by bufo | Hacker News Reader

"There are possible improvements still to be made on bigger buffers for example, where we could make better use of SIMD, but at the moment rustc still targets baseline x86-64 CPUs (SSE2) so that's a work item left for the future."

I don't understand this. The vast majority (I would guess 95%+) of people using Rust have CPUs with AVX2 or NEON. Why is that a good reason? Why can't there be a fast path and slow path as a failover?

View on HN

Because it requires some kind of fat binaries.

Some C and C++ compilers offer this and it requires some infrastructure to make it happen (simd attribute in GCC), or explicitly loading different kinds of dynamic libraries.

I found most precompiled C++ libraries target a specific minimum microarchitecture because it swells the binary size if you do fat binaries, and for most users they wouldn’t know anyway. Companies always get complaints when they bump up the minimum though - I remember reading some articles about some games requiring SSE4.1 or AVX and gamers complaining they couldn’t play it on their ten year old machine.

Not playing on their 10 year old machine is the main reason why OpenGL 3.3 keeps being the baseline when using GL.

Although maybe GL 4.1 would do it nowadays.

Rust already has runtime CPU feature detection. But that would require hand writing the SIMD code.

Higher baseline and failovers are possible in Rust, just not the default.

The default configuration for the "x86-64" target is really meant to run on every x86-64 CPU. I know at lest Debian has the same policy. SSE2 is as old as x86-64 itself, so it can be assumed to be available in every x86-64 CPU, but nothing else can.

There has been some movement to define pseudo-targets like x86-64-v1, x86-64-v2, x86-64-v3 for higher baselines.

Reply on news.ycombinator.com