4 ms·

>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 performan

by vt240 6y ago

>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.

t0mas88 6y ago
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.
Tuna-Fish 6y ago
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.
chrisseaton 6y ago
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.
- rrmm 6y ago
  x86 was always all about backwards compatibility. It's the whole reason why it's such an ugly agglomeration of weird features. lucky for us the clean sheet ia432...err i960, er itanium will save us all!
  - chrisseaton 6y ago
    > 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! These are all dead architectures.
    - rrmm 6y ago
      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.
    - reitzensteinm 6y ago
      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.
      - BeeOnRope 6y ago
        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.
        reitzensteinm 6y ago
        Right, but I'm saying that the regression in performance doesn't cause a backwards compatibility issue. 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.
- vt240 6y ago
  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.
- acqq 6y ago
  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.
  - BeeOnRope 6y ago
    It also provides the 80-bit precision stuff which I guess could be useful for something.
- newacct583 6y ago
  > 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.
  - chrisseaton 6y ago
    > 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.
    - BeeOnRope 6y ago
      > 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.
    - 6y ago
- BeeOnRope 6y ago
  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. Now that seems pretty unlikely.
gallier2 6y ago
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.

by vt240 6y ago

t0mas88 6y ago

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.

Tuna-Fish 6y ago

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.

chrisseaton 6y ago

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.

rrmm 6y ago
x86 was always all about backwards compatibility. It's the whole reason why it's such an ugly agglomeration of weird features. lucky for us the clean sheet ia432...err i960, er itanium will save us all!
- chrisseaton 6y ago
  > 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! These are all dead architectures.
  - rrmm 6y ago
    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.
  - reitzensteinm 6y ago
    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.
    - BeeOnRope 6y ago
      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.
      - reitzensteinm 6y ago
        Right, but I'm saying that the regression in performance doesn't cause a backwards compatibility issue. 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.
vt240 6y ago
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.
acqq 6y ago
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.
- BeeOnRope 6y ago
  It also provides the 80-bit precision stuff which I guess could be useful for something.
newacct583 6y ago
> 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.
- chrisseaton 6y ago
  > 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.
  - BeeOnRope 6y ago
    > 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.
  - 6y ago
BeeOnRope 6y ago
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. Now that seems pretty unlikely.

gallier2 6y ago

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.