AVX-512 Mask Registers, Again
travisdowns.github.io
travisdowns.github.io
In hindsight it makes sense, but it raises the question why in 5 years of iterating on the Skylake core, Intel hasn't tried to fill in that blank and implement at least one AVX-512 execution unit on their consumer chips. It seems like they could have gone for something running at half rate to avoid the severe down-clocking the server cores require when powering up the full AVX-512 unit, and they'd gain the benefits of the mask registers and other new AVX-512 features and stay years ahead of AMD (expected to deliver AVX-512 in 2022?). Instead, this seems to be another feature that has been delayed by Intel's 10nm failures.
[0] https://images.anandtech.com/doci/11544/skylakedie_changevsc...
Die area is expensive, yet transistors on it are free. Might as well take a crack at implementing it, and later disable it with fuses on models that 'shouldnt' have the feature.
Smells to me like perhaps corporate inefficiency making its way into the silicon - space was reserved in the layout for this feature, but then the team was late shipping a design, but they wouldn't allow anyone else to use that area either, because "we'll be ready any day now".
Sometimes this is a necessary result of binning (e.g., those cache slices didn't work), but mostly it is a result of pricing strategy: you want to charge more to the customers who are willing to pay more, while still capturing those who will pay less.
Building chips is expensive, but not that expensive on a unit basis, so whether you sell a die for $100 or $20,000 you are still making a (marginal) profit.
Given that context, it's not surprising that chips can also have actually blank spots which are not enabled on any chip: in this case because the SKX and SKL designs are tightly bound, so the floorplan is almost the same for both chips.
This is probably either as a result of co-design, where SKL was designed with the future SKX in mind, meaning that SKX needed minimal changes to the core port over SKL, or as a result in a change of strategy: perhaps most SKL parts were originally slated to have AVX-512, on 10nm, but when 10nm was repeatedly delayed, the power or other impact was too high for most of the 14nm line and so AVX-512 was relegated to the SKX family. Who knows.
What is clear is that SKL was definitely laid out with AVX-512 in mind.
Edge case and still not likely to cause contention: x87 fadd has 3-cycle latency while AVX has 4-c lat through ICL. If you need to prepare some constant with a chain of high-precision additions to broadcast into an AVX reg, it's faster. (Especially if the alternative is compensated addition.)
Wouldn't this be a performance issue if your linking an executable against libraries compiled for MMX, AVX.
In general, being limited by regs is a very happy problem to have, as it usually means your code is already extremely tight and well optimized.
lucky for us the clean sheet ia432...err i960, er itanium will save us all!
This is backwards compatible in terms of functionality. It doesn't not work, you just may not get the performance you hope for from taking the instruction set at face value. The same as you won't with memory access due to the cache hierarchy. The performance characteristics of Intel's chips has always been changing.
> lucky for us the clean sheet ia432...err i960, er itanium will save us all!
These are all dead architectures.
Intel chips have here and there reverted operations to microcode, but a Skylake era chip executing MMX instructions in microcode is going to absolutely blow a contemporary chip out of the water. MMX was introduced in Intel processors before out of order execution.
It would surprise me if real world performance of any program had regressed even since Core 2.
You've written some MMX code twenty years ago on a P5 Pentium? It's still going to run 50x faster on a modern CPU.
When you don't need it, of course you should use your defaults. But there are still some specific scenarios where it definitely has its uses.
Just as an example of the advantages, x87 code is very compact and the numeric manipulations happen on the implicit hardware floating point stack, allowing for complex formulas fitting in only a few bytes (as the addresses are implicit). Also, as some ABIs still depend on it, targeting such ABIs makes the use of x87 unavoidable.
Running old binaries is absolutely routine in production systems. You're just saying that no one would write new code to use this, and that's true.
But to Intel, refusing to support that stuff means that no one will migrate their existing system running some old 32 bit code to a modern cloud system, and that's lost revenue.
But linking new binaries with old binaries, and at the same time being concerned with performance?
> You're just saying that no one would write new code to use this, and that's true.
No, you're confused - it's not about writing software, it's about compiling it. To not be using at least SSE we're talking about software from before the turn of the century. And it's not software written before the turn of the century, it's software compiled before the turn of the century, and then also linked into a modern executable.
(Hand-written assembly is an exception, but people write assembly for last-ditch optimisations, and if you need last-ditch optimisations why would you be using ancient instructions?)
So to clarify - this is only a problem if both:
1. you're after high performance
2. you're linking against a binary compiled in the last century
How many people do you think that really covers? These seem like extremely disjoint sets of people
> refusing to support that stuff means that no one will migrate their existing system running some old 32 bit code to a modern cloud system
The code does work, it's just not as fast as you may think it would be from a superficial understanding. If you were previously running on a turn of the century processor, it's still going to be faster for you.
It's more than that: it's using both old obsolete code and AVX-512 using code in very tight alternation. I.e,. using both within a loop of a few hundred instructions or less. This is much less likely that linking an old library and occasionally calling into it.
No, we're just talking about software, which was compiled targeting MMX/x87 code generation. It could have been made last week. Not that my original question really matters at all, asked and answered, but there are a whole host of other performance issues with mode switching from mixing libraries compiled for the various SIMD targets.
I got the idea you were arguing against the idea of CPUs supporting x87 code at all.
I know of at least one case where a developer linked an ancient Fortran object with a fresh C++ object file in order to fuzz test both against each other.
The C++ code had to not only match the specification, it had to be bug for bug compatible at the same time, even down to the possible bugs in the 1990s Fortran compiler used to build the machine code. Or, if a bug was fixed it had to be fully documented as to the behavior change.
I don't think the Fortran code used MMX but it could have in theory.
So pretty rare, but can obviously happen.
Now that seems pretty unlikely.