4 ms·

Many recent CPUs eliminate NOPs without executing them, so using NOP may work on a CPU but be ineffective on another. A double BSWAP is equivalent with a NOP,

Many recent CPUs eliminate NOPs without executing them, so using NOP may work on a CPU but be ineffective on another. A double BSWAP is equivalent with a NOP, but no existing CPU does any special optimization for it and it is very unlikely that any future CPU would do something special with it, as it is mostly obsolete (nowadays MOVBE is preferable instead of it). NOP cannot ensure a certain slow-down factor, except on exactly the same model of CPU.

deleted 1y ago
[deleted]
201984 1y ago
Even modern CPUs still have to read the NOPs to skip them, and that's what he was talking about. Decode bandwidth.
yorwba 1y ago
> Many recent CPUs eliminate NOPs without executing them The elimination will still take some amount of time, and the smaller this amount is, the better, because it allows dialing in the slowdown more precisely. Of course how many NOPs you need for a particular basic block needs to be measured on the CPU you're profiling on, but that's also the case if you use a more consistently slow instruction, since the other instructions won't necessarily maintain a consistent speed relative to it.
- sweetjuly 1y ago
  That's not necessarily true. Many modern CPUs have uop caches, and it's reasonable to assume implementations will eliminate NOPs before placing lines in the uop cache. A hit on the uop cache loses any slowdown you hoped to achieve since now the NOPs are neither fetched nor decoded.
  - tux3 1y ago
    That's an interesting question, because the uop cache is filled early in the pipeline, but zero-idioms are only detected around the rename stage. They might be able to skip a plain 0x90, but something like mov rax, rax would still emit a uop for the cache, before being eliminated later in rename. So at best it would be a fairly limited optimization. It's also nice because rename is a very predictable choke point, no matter what the rest of the frontend and the backend are busy doing.
    - sitkack 1y ago
      Instead of arguing about it, you people could have run an experiment and written a paper.

deleted 1y ago

[deleted]

201984 1y ago

Even modern CPUs still have to read the NOPs to skip them, and that's what he was talking about. Decode bandwidth.

yorwba 1y ago

> Many recent CPUs eliminate NOPs without executing them The elimination will still take some amount of time, and the smaller this amount is, the better, because it allows dialing in the slowdown more precisely. Of course how many NOPs you need for a particular basic block needs to be measured on the CPU you're profiling on, but that's also the case if you use a more consistently slow instruction, since the other instructions won't necessarily maintain a consistent speed relative to it.

sweetjuly 1y ago
That's not necessarily true. Many modern CPUs have uop caches, and it's reasonable to assume implementations will eliminate NOPs before placing lines in the uop cache. A hit on the uop cache loses any slowdown you hoped to achieve since now the NOPs are neither fetched nor decoded.
- tux3 1y ago
  That's an interesting question, because the uop cache is filled early in the pipeline, but zero-idioms are only detected around the rename stage. They might be able to skip a plain 0x90, but something like mov rax, rax would still emit a uop for the cache, before being eliminated later in rename. So at best it would be a fairly limited optimization. It's also nice because rename is a very predictable choke point, no matter what the rest of the frontend and the backend are busy doing.
  - sitkack 1y ago
    Instead of arguing about it, you people could have run an experiment and written a paper.