Comment by Const-me | Hacker News Reader

Comment by Const-me | Hacker News Reader

Parent Full thread

When you compile stuff in Visual C++ with /arch:AVX or /arch:AVX2 setting, the compiler is using VEX for everything, including SSE instructions which can be encoded the old way. This eliminates the described problem completely. Also eliminates a few others as well, e.g. VEX-encoded unaligned memory access is guaranteed to work, with SSE encoding these same instructions might fail with “unaligned access” runtime exception.

AVX1 and VEX are supported by vast majority of CPUs made after 2011. Steam hardware survey says if you require AVX1, you gonna loose less than 7% of the audience. Maybe it’s time to move on already, and drop support for pre-AVX1 CPUs?

In one of my current projects (started as a green field about 1.5 years ago) the customer was willing to sacrifice compatibility for development cost, I told them I’ll ship sooner if we require AVX2 and D3D feature level 11.0 hardware, they agreed. Over these 1.5 years they only hit that once, trying to run my software on some 12-core Ivy Bridge Xeon, it doesn’t have AVX2 but it does support AVX1 and therefore VEX.

Yet, Intel still produces new CPU's without AVX/AVX2. 10th-gen.

Wow, you're right, 10th gen Pentiums and Celerons don't:

https://ark.intel.com/content/www/us/en/ark/products/199285/...

https://ark.intel.com/content/www/us/en/ark/products/199290/...

AVX2 is supported with i3s:

https://ark.intel.com/content/www/us/en/ark/products/199283/...

Welcome back to 2010. Even some Sandy Bridges had AVX.

Removed

It looks like the site you've mentioned is auto-generated. Anyways, g6600 has no avx.

This is so insane to me. I just don't understand it at all. Pervasive high performance SIMD would have provided a huge moat to porting compute heavy software away from x86.

But since you can't rely on it, nobody wants to maintain a slow path fallback. One that's going to be used on all the slowest machines anyway, so it had better be good too.

By the way, Intel’s SSE (the compatible vector stuff supported by 100% of modern CPUs) and ARM Neon both operate on 128-bit vectors, it’s usually not too hard to port between the two, did it more than once.

AVX code is much harder to port on ARM, as the registers are 256 bits. By disabling AVX in low-end CPUs, Intel is forcing many people to still maintain SSE 4.1 versions. This is making much easier to port software from Intel to ARM.

I think that’s an example of quarterly report-driven management, Intel picked short-term profits at the cost of long-term strategy.

Yes. Only the paranoid survive era Intel is rolling in its grave.

They used to do everything - legal or otherwise - to stay on top. Now they're not even bothering with the legal stuff.

AMD would have played ball, because it would have benefited them just as much.

Post Sandy Bridge the x86 license was probably proportionally more valuable to them than to Intel. If it went away, Intel still had their fabs, which at that time showed no sign of danger.

For code using intrinsics (not assembler) https://simd-everywhere.github.io/blog/ might be helpful, including on x86_64, though it doesn't provide runtime dispatch. GCC itself knows a level (sse4.2?) of x86_64 intrinsics on ppc64le.

Indeed, horrible marketing from Intel.

Probably these Pentiums and Celerons are used by the unfortunate 6.5% of Steam users without AVX1. If I would be working on a casual videogame instead of a resource-intensive CAM/CAE app, I probably wouldn’t want to require AVX.

For the enterprise software you need to support old hardware simply because clients (especially Swiss ones) often have a very old VMware environment running on Xeons without AVX. This is either because CPUs do not support AVX or there is a compatibility layer enabled for live migration that disables it.

Reply on news.ycombinator.com