3 ms·
When an invalid instruction exception occurs, it is very easy to identify whether the invalid instruction was an AVX-512 instruction, because those start with a
by adrian_b 4mo ago
When an invalid instruction exception occurs, it is very easy to identify whether the invalid instruction was an AVX-512 instruction, because those start with a prefix different from any other instructions.
After that happens, the thread can be marked as requiring AVX-512 and then it can be scheduled only on P-cores.
Moreover, one can define a new flag for the ELF header of executable files, specifying the AVX-512 requirement, which will be set by the compiler, depending on the compilation options, and then the OS knows from the beginning how to schedule a process.
Of course, the best solution is still to implement a uniform ISA. If a lower performance is accepted, the execution of the AVX-512 instructions can be implemented at a negligible additional cost over the previous x86_64 ISA.
What has scared the E-cores designers into not implementing AVX-512 was not the execution part, but the instruction decoding part. The instruction decoder for x86_64 is already horrendously complicated when many instructions must be decoded concurrently in a single clock cycle and adding the need to handle the completely distinct encoding of the AVX-512 makes it even more complicated.
Nonetheless, the competition from AMD has eventually forced Intel to give up in their attempt of reducing production costs by saving die area with a simpler instruction decoder in the E-cores, so the E-cores of Nova Lake will have the same ISA as its P-cores.
- menaerus 4mo agoAnd what happens when E-core decoder encounters the AVX-512 instruction set? Does this mean that E-cores will have to implement some sort of (downsized) vectorized execution engine too? Otherwise, I don't see how this would work. Migrating on the HW core level would be too complicated.
- murderfs 4mo ago> When an invalid instruction exception occurs, it is very easy to identify whether the invalid instruction was an AVX-512 instruction, because those start with a prefix different from any other instructions. You're missing the point: the processes executing AVX-512 do not have any particularly strong requirement for AVX-512 instructions, they're just optimistically using them to improve performance because CPUID claimed they were supported. It would be pathologically bad behavior to control scheduling behavior with this, because in practice it would result in things like glibc deciding to use AVX-512 for string functions resulting in every program that uses memcpy (i.e. every program) not being allowed to be scheduled on the little cores.