>Who is going to be making heavy use of x87 or MMX (both obsolete) along with AVX-512 mask registers? It seems extremely unlikely.
Wouldn't this be a performance issue if your linking an executable against libraries compiled for MMX, AVX.
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.
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.
Now that seems pretty unlikely.
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.
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.
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.
I got the idea you were arguing against the idea of CPUs supporting x87 code at all.
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.