4 ms·

Wasn't the issue that efficiency cores don't support AVX-512 and that operating system schedulers/software don't deal with this yet and end up running AVX-512 c

Wasn't the issue that efficiency cores don't support AVX-512 and that operating system schedulers/software don't deal with this yet and end up running AVX-512 code on the efficiency cores?

deleted 4y ago
[deleted]
bogwog 4y ago
That was the exact same story I read, probably on this site.
cogman10 4y ago
That's a terrible CPU design. You might as well ship arm cores if you are going to have a mismatch of instruction set support on efficiency vs power cores. Especially since apps using AVX-512 will likely sniff for it at runtime. So now, you have a thread that if rescheduled onto an efficiency core it will break on you. So now what, does the app dev need to start sending "capabilities requests" when it makes new threads to ensure the OS knows not to put it's stuff on an efficiency core? What a dumb design decision.
- crote 4y ago
  It could be done dynamically by the scheduler: whenever a thread tries to use AVX-512 on the efficiency core, move it to the power core and keep it there for a certain amount of time. If I am not mistaken, the CPU also exposes instruction counters, which would allow the OS to determine whether a thread has tried using AVX during its last time slice. In our modern multithreading world, many applications already have separate idle and worker threads. I would not be surprised if such an approach could be implemented with negligible performance drawbacks.
  - magicalhippo 4y ago
    It could also be done by the application. At least on Windows, you can provide the OS with a bitmask of which (virtual) processors you want it to be scheduled on. So the application could detect which cores had AVX-512 and change it's scheduling bitmask before doing the AVX-512 work. The OS probably should do the dynamic stuff you mentioned, this would then be to avoid the initial hit for applications that care about that.
  - colejohnson66 4y ago
    I initially thought the same, but then realized the big issue with that. The x86 architecture, as it is (see below), requires that both core types appear to be homogenous. Therefore, if the E cores claim support for AVX-512 with CPUID (which would be a lie), then every application using glibc will try to use AVX-512 for memcpy (or whatever) when they shouldn't. As a result, they'd end up pinned to a P core when they should remain on an E core. This whole mess is because AVX-512 was initially released on hardware where this distinction didn't exist. If AVX-512 was released during or after the whole P/E core thing last year, it would be possible to have applications using AVX-512 state their intentions to the scheduler (as @magicalhippo suggests). The application could say, "hey, OS, I need AVX-512 right now," and all would be well. As it is now, we're stuck with it.
- layer8 4y ago
  > it will break on you Not necessarily, if the illegal-instruction interrupt maps it onto an emulation routine — or transfers the thread back to a performance core.
  - saagarjha 4y ago
    At that point, why even bother?
pantalaimon 4y ago
That's why it was only enabled if you disabled the efficiency cores - until Intel fused it off. And if Intel would have wanted this, they could have deviced the kernel to handle the fault and pin the process to the big cores.
- formerly_proven 4y ago
  This wouldn’t work, at least on Linux because libraries like glibc will put AVX512 usage into every process.

Wasn't the issue that efficiency cores don't support AVX-512 and that operating system schedulers/software don't deal with this yet and end up running AVX-512 code on the efficiency cores?

deleted 4y ago

[deleted]

bogwog 4y ago

That was the exact same story I read, probably on this site.

cogman10 4y ago

That's a terrible CPU design. You might as well ship arm cores if you are going to have a mismatch of instruction set support on efficiency vs power cores. Especially since apps using AVX-512 will likely sniff for it at runtime. So now, you have a thread that if rescheduled onto an efficiency core it will break on you. So now what, does the app dev need to start sending "capabilities requests" when it makes new threads to ensure the OS knows not to put it's stuff on an efficiency core? What a dumb design decision.

crote 4y ago
It could be done dynamically by the scheduler: whenever a thread tries to use AVX-512 on the efficiency core, move it to the power core and keep it there for a certain amount of time. If I am not mistaken, the CPU also exposes instruction counters, which would allow the OS to determine whether a thread has tried using AVX during its last time slice. In our modern multithreading world, many applications already have separate idle and worker threads. I would not be surprised if such an approach could be implemented with negligible performance drawbacks.
- magicalhippo 4y ago
  It could also be done by the application. At least on Windows, you can provide the OS with a bitmask of which (virtual) processors you want it to be scheduled on. So the application could detect which cores had AVX-512 and change it's scheduling bitmask before doing the AVX-512 work. The OS probably should do the dynamic stuff you mentioned, this would then be to avoid the initial hit for applications that care about that.
- colejohnson66 4y ago
  I initially thought the same, but then realized the big issue with that. The x86 architecture, as it is (see below), requires that both core types appear to be homogenous. Therefore, if the E cores claim support for AVX-512 with CPUID (which would be a lie), then every application using glibc will try to use AVX-512 for memcpy (or whatever) when they shouldn't. As a result, they'd end up pinned to a P core when they should remain on an E core. This whole mess is because AVX-512 was initially released on hardware where this distinction didn't exist. If AVX-512 was released during or after the whole P/E core thing last year, it would be possible to have applications using AVX-512 state their intentions to the scheduler (as @magicalhippo suggests). The application could say, "hey, OS, I need AVX-512 right now," and all would be well. As it is now, we're stuck with it.
layer8 4y ago
> it will break on you Not necessarily, if the illegal-instruction interrupt maps it onto an emulation routine — or transfers the thread back to a performance core.
- saagarjha 4y ago
  At that point, why even bother?

pantalaimon 4y ago

That's why it was only enabled if you disabled the efficiency cores - until Intel fused it off. And if Intel would have wanted this, they could have deviced the kernel to handle the fault and pin the process to the big cores.

formerly_proven 4y ago
This wouldn’t work, at least on Linux because libraries like glibc will put AVX512 usage into every process.