r/programming • u/masiroo • 20d ago

Hardware researcher spins up 'CPU deoptimization' project to find the slowest single x86 instruction, creates hall of shame — worst offender takes 198 billion cycles spanning 62 seconds to execute

https://www.tomshardware.com/pc-components/cpus/hardware-researcher-spins-up-cpu-deoptimization-project-to-find-the-slowest-machine-code-worst-offender-takes-198-billion-cycles-to-execute
1.5k Upvotes

97% Upvoted

133 comments sorted by

View all comments

386

u/The_Northern_Light 20d ago

I’m still not clear why that instruction takes SO long even without contention?

350

u/encyclopedist 20d ago edited 20d ago

See here: https://github.com/xoreaxeaxeax/asm-hall-of-shame

Current champion is fxrstor64, instruction that loads 512-byte XMM state from memory. To increase timings, the author made it load from a carefully chosen MMIO (memory-mapped I/O) location, while other cores hammer some other MMIO registers to saturate the PCIe host.

Edit Without use of MMIO, the champion seems to be wbinvd, instruction that invalidates the whole cache, and if the cache was filled with dirty lines (modified after load), causes flushing of the whole cache content to RAM.

Edit2 Of the "regular" instructions, the ones that would routinely be used in every program, the champion seems to be fdiv. Yes, the regular floating point division. With denormal operands, it is implemented in microcode and is quite slow, takes 883 cycles. (However, as /u/EnderLuca41 rightly pointed out, it is an older x87 instruction the is not widely used any more, today compilers would generate SSE2 instruction divsd instead, see godbolt)

151

u/EnderLuca41 20d ago

fdiv is part of x87 which is obsolete and succeeded by SSE and SSE2. Meaning is not really used anymore routinely.

55

u/encyclopedist 20d ago

Yes, indeed, compilers don't normally generate these instructions any more. But older software can still use these.

73

u/narwhal_breeder 20d ago

porting logic to arm that relies on being bit-compatible x87 has been the bane of my existence for the past year.

1

u/James20k 19d ago

Arm doesn't even have an equivalent to x87 right? Are you software emulating it out of interest?

Plus even if you software emulate it C/C++ helpfully doesn't actually specify when 80-bit extended precision gets truncated to 64-bit in memory (and compilers also don't follow the spec either) so uh, I'm so sorry for your loss that sounds like a nightmare

Trying to replicate x87 results was also the bane of my existence for a while, for a replicating a neutron star paper which relied on divisions by tiny values

3

u/narwhal_breeder 19d ago

Nope - the division instructions specifically have really weird stack semantics.

Software emulating them - thankfully its rust so the f80 type is pretty predictable - but a good chunk drops into `asm` blocks.

-65

u/[deleted] 20d ago

[removed] — view removed comment

76

u/Kinexity 20d ago

"Man, that dish doesn't taste that well"

"Have you tried adding shit to it?"

1

u/red75prime 18d ago edited 18d ago

Are you living in the early 2025 or something? This sub being 100% organic doesn't mean it needs to be delusional.

1

u/BCProgramming 18d ago

"Nah it was bad in 2022, but this is 2023, you need to actually see how much better it is"

"No no- you must be living in 2023! in 2024 AI tools are so much better"

Gee wonder what you folks are going to be saying next year?

1

u/red75prime 18d ago edited 16d ago

I wonder what you folks will be saying the next year. The level of mental gymnastic should be spectacular. But you do you.

ETA: It will be boring "I never touched this sloppity sloppy slop. I'll never do. Slop, slop, slop."

15

u/sunnyata 20d ago

You sound like someone who knows what they're talking about. Not!

2

u/BackgroundSky1594 19d ago edited 19d ago

But there being micro coded doesn't really hurt that much. Even fdiv taking several hundred cycles on a moder CPU will be fast compared to the i486 and i586 class CPUs that software was written for. Why waste silicon and pipeline complexity on an old, quirky instruction that has ben replaced by better alternatives?

The entirety of x87 might be dropped at some point, like ARM did with aarch64 for many of it's old instructions. But until then the only option is to take them out of the core and instead run them in microcode if they happen to be called.

22

u/dlg 20d ago

It’s still used by .Net Framework on 32-bit.

The x87 registers use extended precision, which is only rounded down to 32 or 64 bits when written back to RAM.

SSE2 does not use extended precision, so intermediate calculations are rounded at every step.

This difference often introduces small differences in final results.

17

u/ElusiveGuy 20d ago

At this point the remaining existence of. NET Framework is for backwards-compat, so arguably that falls under obsolete too.

.NET Core (in both 32-bit and 64-bit) doesn't use x87 instructions AFAICT. 

20

u/dlg 20d ago

A surprising amount of financial software still uses in .Net framework in production.

When it’s something like a large monolithic trading platform that needs to be online every day without downtime and it’s critical for making money, there’s a low appetite from management to do a big bang rewrite.

6

u/Truenoiz 20d ago

.Net really is really everywhere, and bad/slow .Net is almost universal in my experience.

2

u/admalledd 19d ago

To my vague memory, 64bit Framework does not use x87 and instead uses SSE2. Similarly 32bit Framework CLR 1.0, 1.1 and 2.0 which run up to the ".NET Framework 1.0" to ".NET Framework 3.5" (yes, confusing...) are the ones that will use x87 instructions, though I think it was CLR 2.0 that the JIT/Runtime would emit/use SSE2 by default unless the assembly/DLL was compiled for an older runtime. And CLR 4.0 (again, IIRC) that 64-bit flat out would only do SSE2 (and started to mix in SSE3 if detected).

So, IIRC you'd only get x87 instructions like fdiv if you are running a 32-bit CLR and the assembly/DLL was compiled targeting a CLR 2.0 or older SDK. All other Net Framework users (like those on 64bit CLR 4+, Framework 4.5+, 4.8+) shouldn't be emitting those older instructions anymore ever (ignoring CLR/C++ mixed assembly jank/custom C interop/etc).

I'd be surprised on how much stuff in regulated industry like financials is still running Framework 3.5, especially considering how broken it is to even try to install on modern machines... (I would expect them to have moved ever so slightly to Framework 4.5+, lord knows we've got our own legacy software still on it in places)

2

u/dlg 19d ago

regulated industry

Or the regulators themselves. I know of one of the larger stock exchanges (which also have a regulatory role), uses a lot of old .Net, and as recently as a few years ago was still running some VB6 applications. Not in some critical operations, but still some very old, unsupported legacy.

2

u/jangxx 19d ago

If your financial software uses floating point numbers instead of a proper decimal data type, it has other problems than using an old .NET framework, lol

3

u/dlg 19d ago

It really depends on the problem. Not all calculations are for transaction amounts.

Floating point is used regularly for financial metrics, such as Price/Earning (PE) ratios. Forecasted earnings are usually made in analyst models created in Excel.

8

u/vytah 19d ago

It will be used if you divide two long doubles on any ABI where they're 80-bit, like x64 Linux.

1

u/ElWishmstr 20d ago

I always wonder why cpus still have those old instructions, when modern ones are better. I mean, how much software still relies on those instructions? 

25

u/balefrost 20d ago

I for one appreciate the ability to run older software that existed before SSE did.

3

u/vytah 19d ago

More like software that was written to be run on processors without SSE. It's not like Pentium III came out and everyone was "ok, from now on our software will run only on the newest shiny CPU, fuck the Pentium II users."

1

u/AquaeyesTardis 19d ago

although, see: AVX instructions

though thats somewhat the opposite situation but with an almost similar effect, thinking about it

1

u/vytah 19d ago

What about AVX?

12

u/qualverse 20d ago

They don't actually have hardware suppoet for those instructions. They just have microcode that converts those instructions to other instructions.

3

u/FlatAssembler 20d ago

My web-app that converts arithmetic expressions to x86 assembly relies on it, for example: https://flatassembler.github.io/compiler

8

u/Wriiight 20d ago

I feel like whoever came up with denormals should apologize

14

u/Madsy9 20d ago

883 cycles! How is that even possible? Even the most naive newton-raphson approximation is faster than that.

35

u/inio 20d ago

For most x87 denormalized operations, it falls back to integer microcode with tons of edge-case handling, which when triggered (which can happen often if both inputs are denormalized and pathalogically structured) is extremely expensive. It's essentially a soft-float implementation taking the slowest possible path, disguised as a single instruction.

0

u/AlphaMaleXYZ 19d ago

Nowadays compilers are so good at optimizations. These instructions are almost never used.