But it isn't good enough. SIMD provides measurable improvements to some people's code. To those people what we had before isn't good enough. Sure for the majority SIMD provides no noticeable benefit and so what we had before is good enough, but that isn't everybody.

▲

johnklos 2 days ago | parent [-]

Are you SURE that nobody has figured out how to have code that uses SIMD if you have it, and not use it if you don't?

Your suggestion falls flat on its face when you look at software where performance REALLY matters: ffmpeg. Guess what? It'll use SIMD, but can compile and run just fine without.

I don't understand people who make things up when it comes to telling others why something shouldn't be done. What's it to you?

	▲	pabs3 2 days ago \| parent \| next [-]
		It definitely is, you can even do that automatically with SIMDe and runtime function selection. https://wiki.debian.org/InstructionSelection
	▲	wtallis 2 days ago \| parent \| prev [-]
		ffmpeg is a bad example, because it's the kind of project that has lots of infrastructure around incorporating hand-optimized routines with inline assembly or SIMD intrinsics, and runtime detection to dispatch to different optimized code paths. That's not something you can get for free on any C/C++ code base; function multiversioning needs to be explicitly configured per function. By contrast, simply compiling with a newer instruction set permits the compiler's autovectorization use newer instructions whenever and wherever it finds an opportunity.