Hacker News Reader

Comment by diogenes4 | Hacker News Reader

> Microsoft and Intel could literally do this today on existing hardware by trapping unsupported instructions and then having the OS scheduler promote the process but they don't because it takes so stupidly long and requires an immense burst of resources.

Why not just determine the right cpu to run on by examining the arch of the binary? Waiting for an instruction failure seems ridiculous.

View on HN

Microsoft’s implementation of C standard library routines like `memcpy` is checking for a global flag, and use AVX when available. The flag is initialized on startup by testing the output of `cpuid` instruction.

For this reason, most binaries built with modern Visual C++ are technically using AVX instructions even when compiled for SSE only. It doesn’t mean these binaries gonna fail without AVX support, it only means they’re capable of using AVX when available.

Because you don't want any AVX512 binary to get stuck on a P-core forever.

Also, if application developers got to choose all of them would build their apps to request the most performance. And then how do we put anything on an efficiency core if every application claims to need to run on a P core. Back to square one it is.

Why not use a prominent OS display "power efficiency" so the user can harass devs about a calendar app running on P core

Because your calendar app happens to use a jpeg decoding library that uses "high power" instructions.

Because the binary might contain a JIT, or even more simply, it might load a DLL with new code.

Both the library and the AVX512 generating JIT binary would have the arch set to AVX512 in the executable format header.

Well, but what if it doesn't? Also, who's supposed to set that bit? The programmer, or the compiler? In either case it's possible to set it wrong.

If the compiler generates the instructions, the compiler has to set the correct arch, if the JIT does that, the author has to override the arch in the build scripts.

If the arch is incorrect, it is a bug, and program will crash on illegal instruction. Ie like if you had an ARM binary that was incorrectly set to x64 and was run on x64.

This isn't an architecture, though. It's an instruction set.

What if the JIT generates new instructions dynamically and initially there are no AVX512 instructions but later on in the process' lifetime there are?

Then it crashes with an illegal instruction exception.

The instruction set is the major part of an architecture spec from the point of view of an userspace application. You can design the binary header flags to express instruction sub/set when you find that reasonable. In any case, regardless if the instructions are hardcoded to the text or generated during the runtime, you need to communicate the intention to use the specific instruction set to the kernel, so it can schedule your process on appropriate cores, and check if there are such cores present in the first place.

Reply on news.ycombinator.com