4 ms·
Because the 'efficiency' cores are actually optimised for silicon area efficiency (and not just low power usage, like is generally the case with things like ARM
by berkut 4y ago
Because the 'efficiency' cores are actually optimised for silicon area efficiency (and not just low power usage, like is generally the case with things like ARM big.LITTLE setups), and AVX-512 native takes up a lot of silicon space on the chips Intel has implemented it for.
And because it's not clear how OS schedulers could nicely switch on-the-fly between cores with different instruction set capabilities, it's essentially not use-able.
- moonchild 4y ago> it's not clear how OS schedulers could nicely switch on-the-fly between cores with different instruction set capabilities It is a software problem, and it could have been solved with software. It was simply assumed a priori that it couldn't be solved, so no one bothered to try.
- wmf 4y agoOr they talked to Microsoft who said it would take years to add that feature.
- undersuit 4y agoOr they talked with Microsoft who refused to add it to anything but Windows 11. Or maybe they can't handle it because of some difficiency in their Linux ports. The thing is it is possible and Intel knew for years that the E-cores wouldn't have AVX512.
- moonchild 4y agoLet it take years, then. Leaving it disabled in the bios by default is one thing, and a rather reasonable one at that. Fusing it off is quite another.
- Twirrim 4y agoThis isn't a new decision, it came out a few years ago that you'd end up with disparate instruction sets between the main and efficiency cores, and they got warned it would be a problem. Their disabling of the instructions to avoid it came about as a response. Both Microsoft and Linux devs warned them about the difficulties it'd present.
- pabs3 4y ago> it's not clear how OS schedulers could nicely switch on-the-fly between cores with different instruction set capabilities You would need a way for processes to signal the kernel that they have left a function that uses a higher instruction set and are thus available for moving to another core, plus a way for the kernel to signal processes to update their function pointers as appropriate for the new core they got moved to. https://wiki.debian.org/InstructionSelection https://wiki.debian.org/InstructionSelection
- _kbh_ 4y ago> And because it's not clear how OS schedulers could nicely switch on-the-fly between cores with different instruction set capabilities, it's essentially not use-able. Couldn't you implement the new instructions (even slowly) in microcode? so they support the instructions with minimal silicon, even if its as slow or slower then other vector instructions?.