Need help?
<- Back

Comments (69)

  • Retr0id
    Related, and linked in the readme: https://github.com/xoreaxeaxeax/smiiiiiiiiiiiiiiii (using the slow instructions to break SMI)
  • kazinator
    Bus cycles can be arbitrarily long on any processor that has memory cycles with a hand shake requiring an ack, with no timeout.E.g. we can build a board around a MC68000 where we make it lock up forever in a bus cycle, waiting for a DTACK that doesn't arrive.Some early microprocessors had clocked bus cycles without handshaking. They would put out an address on some address lines and signal some line together with a read/write indication, and then expect the transfer to be completed within some clock cycles. If nothing is attached to the address, they would read whatever values are on the bus, like maybe all 1's if it is an open drain system that requires the transmitting device to pull to ground to indicate zero.I'd say that kind of thing belongs to a hall of shame; it requires software hacks to interface with anything that can't keep up with the prescribed bus cycle.
  • monocasa
    It says in the rules> Trapped/emulated/virtualized instructions may only time the trap, not the handler.But I feel like that 12ms write to an ACPI IO port at current leaderboard position 8 is probably trapping to SMM and being handled there.
  • layer8
    Nop should be #1, because it is infinitely slow for what it does. ;)
  • TomatoCo
    This author also has other things like: A compiler that emits only `mov` instructions and another compiler that deliberately messes with the control flow so that, if disassembled, common debuggers will draw symbols like skulls or threats. https://github.com/xoreaxeaxeax/repsych
  • markus_zhang
    Does that mean Chris Domas is ready for his next adventure?
  • codeshaunted
    what im seeing from this chart is that we should be using the nop instruction for everything
  • simonebrunozzi
    Related, somehow: Core War [0].[0]: https://en.wikipedia.org/wiki/Core_War
  • anon
    undefined
  • michalsustr
    Very cool! Also, huh interesting. I’ve used rdtsc to measure cycle diffs but had no idea its execution takes that long. Is that common across architectures?
  • vardump
    A great resource for any performance deoptimization.
  • metadat
    It’s crazy how computers still seem to get perceivably slow every few years, given how many instructions can be executed in 1ms. Shameful, even..What’s that law called about programmers wasting all the compute on abstraction?
  • 56767865678
    Sahil
  • baddash
    just curious, how much do these actually discover useful practices or pitfalls, on top of just being for fun?
  • spoocecow
    Oh wow, glad to see Chris Domas active online again!
  • achierius
    It'd be really interesting to see whether the winning (losing?) instructions/strategies would be different on other architectures. At least right now the top spot (`fxrstor64` on MMIO, starve PCIe) seems relatively architecture-independent, but maybe something about MMIO ordering rules on e.g. POWER would be different enough to change that -- or perhaps open up new avenues?I wonder what the actual limit on this `fxrstor64` is right now. If you can stall the PCIe bus for that long, then why not indefinitely? Certainly there's no forward progress guarantee here.
  • IshKebab
    Using MMIO is cheating and makes the results very boring.It would be much more interesting to know the results if you're only allowed to use main memory.
  • arn3n
    There’s definitely strategies here; A lot of the floating point operations use subnormals, and a lot of the worst instructions are slowed down by really, really fucking with MMIO.
  • eek2121
    This is neat!
  • 2_foos_in_a_bar
    [dead]
  • darksim905
    Seems like spam from this creator since there are two things on the front page?