5 ms·

Disabling the E-cores apparently activates AVX-512. So it was planned and engineered to be there all along, but was disabled to match the marketing talking poin

by halz 5y ago

Disabling the E-cores apparently activates AVX-512. So it was planned and engineered to be there all along, but was disabled to match the marketing talking points. [https://www.phoronix.com/vr.php?view=30664 https://www.phoronix.com/vr.php?view=30664]

mastax 5y ago
I expect it was disabled so that the P&E cores have the same ISA support and threads can be moved freely between them. A large portion of people, especially at launch, would be running on a scheduler which isn't optimized for ADL which would be a disaster. Also complicated to market and explain: "supports AVX512 but only on windows 11." This way they don't have to characterize the AVX512 units and it makes binning easier. A shame because the ADL AVX512 units are much more efficient.
- rbanffy 5y ago
  > P&E cores have the same ISA support and threads can be moved freely between them. Wouldn't an illegal instruction fault suffice to flag a thread running on a mismatched core and allow it to be moved to a suitable one? Or do they lose state when the fault occurs?
  - mastax 5y ago
    People are going to be running existing software (Windows 10 and Linux) which do not have support for Alder Lake. These schedulers don't know to handle the SIGILL. What you'd get instead is applications randomly crashing as their threads migrate to the E-cores. I'm sure they'll get there eventually, but they probably just didn't have enough time.
    - rbanffy 5y ago
      No existing scheduler does that, but it wouldn't be impossible to implement one that does.
  - wmf 5y ago
    Maybe OSes could do that but they don't today.
    - rbanffy 5y ago
      At the moment they also don't differentiate between fast and slow cores either. It's interesting to route processes that need to be more responsive to the faster cores and dedicate the slower ones to more lag-tolerant things, a bit how mainframes route IO tasks to specialized processors or macOS routes system threads to the efficient cores, leaving the good ones to the user.
      - jdsully 5y ago
        They would also need to know which specific instructions are really invalid and which just don’t exist on this specific core. X86 doesn’t make that easy.
        rbanffy 5y ago
        CPU flags should take care of that. Besides, you can examine where the program counter was when the core encountered the invalid instruction. I wouldn't be surprised if the x86 would let us down here however. Wouldn't be the 8367th time.
        jdsully 5y ago
        There’s no CPU flag to say “this instruction exists on another core”. X86 disassemblers are very complex if you want to handle more than just the happy path. X86 instructions can be up to 15 bytes long. Then there is the issue with new instructions that get added.
- gpderetta 5y ago
  But the OS should be able to handle it by masking out the feature bits in cpuid (and/or preventing threads using AVX512 from being migrated to the E cores). Yes, you need OS support, but then again, you need support for the ThreadDirector anyway.
  - rbanffy 5y ago
    Wouldn't this break a lot of kernel-level code? OTOH, this could allow us to have very heterogeneous processors in a single system, each with an ISA tailored to a kind of task and the OS knowing which core can run which program.
brandmeyer 5y ago
Despite years of talk about heterogeneous computing, I don't think there are any production kernels for any general-purpose operating system that are instruction-set-feature aware. Linux and Windows both have partitioned schedulers, available through per-process and per-thread affinity masks. So it doesn't seem like it should be all that hard to implement. Its "just" a matter of expressing the process's (thread's?) requirements.
IanCutress 5y ago
To clarify here, it requires both the E-cores disabled and a specific option enabled in the BIOS. The option was removed from the Intel firmware provided to vendors, but all the motherboard vendors found what bit to flip to get it to work. MSI played safe and initial BIOSes didn't have the option, the rest put it in there from launch. MSI are now releasing BIOSes with the AVX-512 option. Beyond that, AVX-512 is not POR. It's not validated, checked for IEEE accuracy, and YMMV on whether it works at what frequency with the correct outputs. Source: AnandTech.... where I wrote about it :)
- merb 5y ago
  > Source: AnandTech.... where I wrote about it :) if you wrote it, it I wouldn't count it as a source /s isn't that than a bit risky to put something into the bios which might disable intels advances? and especially if not even intel tested it correctly? I mean as a consumer what would happen if I enable it and something breaks?

by halz 5y ago

mastax 5y ago

I expect it was disabled so that the P&E cores have the same ISA support and threads can be moved freely between them. A large portion of people, especially at launch, would be running on a scheduler which isn't optimized for ADL which would be a disaster. Also complicated to market and explain: "supports AVX512 but only on windows 11." This way they don't have to characterize the AVX512 units and it makes binning easier. A shame because the ADL AVX512 units are much more efficient.

rbanffy 5y ago
> P&E cores have the same ISA support and threads can be moved freely between them. Wouldn't an illegal instruction fault suffice to flag a thread running on a mismatched core and allow it to be moved to a suitable one? Or do they lose state when the fault occurs?
- mastax 5y ago
  People are going to be running existing software (Windows 10 and Linux) which do not have support for Alder Lake. These schedulers don't know to handle the SIGILL. What you'd get instead is applications randomly crashing as their threads migrate to the E-cores. I'm sure they'll get there eventually, but they probably just didn't have enough time.
  - rbanffy 5y ago
    No existing scheduler does that, but it wouldn't be impossible to implement one that does.
- wmf 5y ago
  Maybe OSes could do that but they don't today.
  - rbanffy 5y ago
    At the moment they also don't differentiate between fast and slow cores either. It's interesting to route processes that need to be more responsive to the faster cores and dedicate the slower ones to more lag-tolerant things, a bit how mainframes route IO tasks to specialized processors or macOS routes system threads to the efficient cores, leaving the good ones to the user.
    - jdsully 5y ago
      They would also need to know which specific instructions are really invalid and which just don’t exist on this specific core. X86 doesn’t make that easy.
      - rbanffy 5y ago
        CPU flags should take care of that. Besides, you can examine where the program counter was when the core encountered the invalid instruction. I wouldn't be surprised if the x86 would let us down here however. Wouldn't be the 8367th time.
        jdsully 5y ago
        There’s no CPU flag to say “this instruction exists on another core”. X86 disassemblers are very complex if you want to handle more than just the happy path. X86 instructions can be up to 15 bytes long. Then there is the issue with new instructions that get added.
gpderetta 5y ago
But the OS should be able to handle it by masking out the feature bits in cpuid (and/or preventing threads using AVX512 from being migrated to the E cores). Yes, you need OS support, but then again, you need support for the ThreadDirector anyway.
- rbanffy 5y ago
  Wouldn't this break a lot of kernel-level code? OTOH, this could allow us to have very heterogeneous processors in a single system, each with an ISA tailored to a kind of task and the OS knowing which core can run which program.

brandmeyer 5y ago

Despite years of talk about heterogeneous computing, I don't think there are any production kernels for any general-purpose operating system that are instruction-set-feature aware. Linux and Windows both have partitioned schedulers, available through per-process and per-thread affinity masks. So it doesn't seem like it should be all that hard to implement. Its "just" a matter of expressing the process's (thread's?) requirements.

IanCutress 5y ago

To clarify here, it requires both the E-cores disabled and a specific option enabled in the BIOS. The option was removed from the Intel firmware provided to vendors, but all the motherboard vendors found what bit to flip to get it to work. MSI played safe and initial BIOSes didn't have the option, the rest put it in there from launch. MSI are now releasing BIOSes with the AVX-512 option. Beyond that, AVX-512 is not POR. It's not validated, checked for IEEE accuracy, and YMMV on whether it works at what frequency with the correct outputs. Source: AnandTech.... where I wrote about it :)

merb 5y ago
> Source: AnandTech.... where I wrote about it :) if you wrote it, it I wouldn't count it as a source /s isn't that than a bit risky to put something into the bios which might disable intels advances? and especially if not even intel tested it correctly? I mean as a consumer what would happen if I enable it and something breaks?