Only if you run out of space in the amount of registers, and there are quite a lot of them so that's unlikely in a real world application. But in a very specific benchmark you probably could.
Not really, because the rename regs only limit you in very straight-line code with little else. Basically, very well behaved inner loops. If you are linking two different libraries into your code that alone probably adds enough control flow and other stuff to make something else limit the code.
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.
x87 and MMX are both so incredibly old that I think it's pretty unlikely that you will be linking code that combines these, unless you have a 'dusty' library that nobody has the source code for anymore.
> x86 was always all about backwards compatibility.
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!
Agreed. I was looking at the quoted article's comment about mmx and x87 being obsolete. No matter how obsolete or old you still have to find room on the die to mush in all this old cruft. Maybe eventually, it'll get pushed into some software emulation on top of more recent extensions.
I don't know who is downvoting you, but you are 100% correct that the behaviour is backwards compatible.
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.
MMX performance actually regressed somewhat between Haswell and Skylake, and Skylake is when the sharing described in this post was introduced and there might be a connection there.
Haha, I don't know if I buy that, since I've been around commercial EDA and ATE software, where you could have a decade of cruft and layered products to work on top of. But wider adoption of vendor tools such as MKL has certainly improved the issue.
x87 is still providing some functionality which is more convenient to be used in some specific scenarios. I've used it intentionally even for some 64-bit code, where it was a perfect fit to all other requirements of the whole environment and the goals of the project.
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.
> unless you have a 'dusty' library that nobody has the source code for anymore.
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.
> Running old binaries is absolutely routine in production systems.
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.
> But linking new binaries with old binaries, and at the same time being concerned with performance?
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.
>To not be using at least SSE we're talking about software from before the turn of the century.
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.
OK, I understand. You were talking about the specific performance regression of the shared register file in single instructions streams that try to combine both FPU architectures. Yeah, I agree.
I got the idea you were arguing against the idea of CPUs supporting x87 code at all.
> But linking new binaries with old binaries, and at the same time being concerned with performance?
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.
It's even less likely than that: you'd have to be using x87/MMX and AVX-512 in the same part of the code. Essentially using the most obsolete and least obsolete part of the ISA at the same time.
The D language still gives access to x87 code. The language defines a type called real which is supposed to give access to the highest precision the implementation allows, on x86 it is the x87 with its 80 bits. On other platforms it's 64 bits or 128 bits. float and double have defined sizes.
I knew that the server variant of the Skylake core tacked on a few extra sections to enable AVX-512 and the extra L2 cache. [0] But I wasn't aware that the base consumer Skylake core already had a blank spot reserved for the AVX-512 register file.
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.
Indeed - SKL has exactly the space for AVX-512, with one FMA unit. It is curious with the 10 nm delay that they never decided to release a client AVX-512 part other than the HEDT "X" series chips (which used the server die).
Why would you ever leave a blank spot for something on a chip?
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".
Modern chips are full of "logically blank" spots. That is, chips are often sold with 2 cores enabled when they physically contain 4 cores, sold with certain parts of the ISA disabled (AVX) even though the execution units are present, sold with less cache than physically present, etc.
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.
> Who is going to be making heavy use of x87 or MMX (both obsolete) along with AVX-512
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.)
Yes, that is interesting. fadd also uses a different port (p5) as compared to SSE/AVX FP stuff which uses p01, so it seems likely that there is separate dedicated hardware for the x87 stuff, probably in the slice between the main vector pipes and this can also handle the 80 bit stuff.
29 comments
[ 3.1 ms ] story [ 91.3 ms ] threadWouldn'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.
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.)