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

News
By
Published

Ironically, new advanced instruction sets could make for even slower commands.

Code on screen.
(Image credit: Getty Images)

To optimize how software runs on hardware, instruction latency analysis looks at the time it takes for low-level instructions to execute on a processor, either to optimize the architecture or to optimize applications to run on a particular architecture. One hardware researcher, Christopher Domas (@xoreaxeaxeax on GitHub), is taking a different approach with the CPU Deoptimization leaderboard, which looks not to make Assembly instructions run as fast as possible, but as slow as possible to measure the single instruction with the highest latency.

The winner here is fxrstor64, which took 62 seconds, or over 198 billion cycles, to complete. This instruction restores the state of registers used for SIMD calculations to a 512-byte memory location. To achieve the highest (slowest) score, Domas first used their own mmiotic tool to find a high-latency area in the internal PCIe fabric, then forced the CPU to load a 512-byte state from MMIO (Memory-Mapped I/O), essentially processing all of those 512 bytes as slow as possible. That took 74 billion cycles or just over 23 seconds to complete.

Then, they went further "by starving the fabric while the load is in flight." They did so by using a series of 4-byte reads from another high-latency MMIO register, overwhelming the CPU's PCIe root complex and forcing the state restore to queue behind frivolous read ops. The next step is to use the AMX instructions available in Intel's Sapphire Rapids for xrstore64. The state area is increased from 512 bytes to 8KB, which could cause the instruction to hang for more than 1 trillion cycles.

Latest Videos FromTom's Hardware

The x86 leaderboard is live on GitHub now, and it looks like Domas has ARM and RISC-V leaderboards planned, as well. There are a few rules for the runs. Domas says any setup is fine, so long as only the execution of a single instruction is scored. Interruptible instructions aren't allowed, nor is scoring emulated instructions run on the handler. All times are normalized based on the CPU's base clock, and the platforms were all run without hardware modifications.

We're dealing with assembly code here, so the ranking is less about the specific instruction and more about what you're doing with that instruction.

Domas primarily used two CPUs for testing: the Intel Core i7-8559U and AMD Ryzen 7 5800H (inside the Trigkey S5). For the rdmsr instruction, however, they used a VIA Eden chip, which was a series of embedded processors from the early 2000s. The rdmsr command is used to read a model-specific register, or MSR. According to Domas, VIA "uses an undocumented register at 0x133 that gives wildly high response time." That command took 202 microseconds or 161,602 cycles to execute.

This is not the developer's first foray into wild experimentation with low-level instructions. An earlier project, called movfuscator, is a C compiler that solely uses the mov (move) command.

Google Preferred Source

Follow Tom's Hardware on Google News, or add us as a preferred source, to get our latest news, analysis, & reviews in your feeds.

Jake Roach
Jake Roach
Senior Analyst, CPUs

Jake Roach is the Senior CPU Analyst at Tom’s Hardware, writing reviews, news, and features about the latest consumer and workstation processors.

6 Comments Comment from the forums
  • Zaranthos
    This is actually pretty awesome. Finding the Achilles heel of CPU instructions is a pretty good way to ultimately make them better going forward. It's also an example of thinking outside the box. It's also some fun canon fodder for CPU wars so people can poke holes in the competition.

    Who knows if this line of thinking is part of AI LLM's yet or if it's any good at this strategy? If not some of the next models will be because everything that hits the Internet is sucked up by AI for future use. Humans still have intuition, imagination, and creativity that AI is unlikely to master for a very long time if ever.
    Reply
  • theredgui
    Zaranthos said:
    This is actually pretty awesome. Finding the Achilles heel of CPU instructions is a pretty good way to ultimately make them better going forward. It's also an example of thinking outside the box. It's also some fun canon fodder for CPU wars so people can poke holes in the competition.

    Who knows if this line of thinking is part of AI LLM's yet or if it's any good at this strategy? If not some of the next models will be because everything that hits the Internet is sucked up by AI for future use. Humans still have intuition, imagination, and creativity that AI is unlikely to master for a very long time if ever.
    In all likelihood, attempting to optimize for these cases is pointless. If this came up very often, or ever, I am fairly certain that Intel and AMD would have corrected it already. Still there is reason to look into issues like this. I'm imagining something like a DOS attack.
    Reply
  • hwertz
    I wonder if this is a DOS risk? I mean (without the contrived PCIe fabric starvatio making it take over 60 seconds) a 23 second non-interruptable instruction sure seems like it could jack up your process scheduler LOL.
    Reply
  • chaos215bar2
    The winner here is fxrstor64, which took 62 seconds, or over 198 billion cycles, to complete. This instruction restores the state of registers used for SIMD calculations to a 512-byte memory location. To achieve the highest (slowest) score, Domas first used their own mmiotic tool to find a high-latency area in the internal PCIe fabric, then forced the CPU to load a 512-byte state from MMIO (Memory-Mapped I/O), essentially processing all of those 512 bytes as slow as possible. That took 74 billion cycles or just over 23 seconds to complete.

    Then, they went further "by starving the fabric while the load is in flight." They did so by using a series of 4-byte reads from another high-latency MMIO register, overwhelming the CPU's PCIe root complex and forcing the state restore to queue behind frivolous read ops. The next step is to use the AMX instructions available in Intel's Sapphire Rapids for xrstore64. The state area is increased from 512 bytes to 8KB, which could cause the instruction to hang for more than 1 trillion cycles.
    I don't think shame is quite the right word to use here. It's actually kind of incredible all that works at the instruction level if you stop to think about it.

    It doesn't really come across in the article (I'm not sure the author gets it), but this is obviously a bit tongue-in-cheek. No one is actually using an instruction like this in this manner. This isn't particularly interesting information if you're trying to optimize the hardware, because it's not representative of anything anyone with even the most basic understanding of a platform would do. What makes this contest interesting is, you have to have a really deep technical understanding of how a platform works to actually figure out how to make an instruction perform this poorly.

    In reality, this is a neat technical challenge, not a practical list of "bad instructions".
    Reply
  • derekullo
    In my country we do not tolerate CPU abuse!

    https://pbs.twimg.com/tweet_video_thumb/G_RXkxHWwAAPcnL.jpg
    Reply
  • ggeeoorrggee
    Clearly the solution is to xor everything else to speed up the process.
    Reply