4 ms·

> 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

> 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.
- vt240 6y ago
  >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.
- newacct583 6y ago
  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.
  - chrisseaton 6y ago
    Ah I see.
- zlynx 6y ago
  > 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. So pretty rare, but can obviously happen.

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.
vt240 6y ago
>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.
newacct583 6y ago
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.
- chrisseaton 6y ago
  Ah I see.
zlynx 6y ago
> 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. So pretty rare, but can obviously happen.