Back to News
Advertisement
Advertisement

⚡ Community Insights

Discussion Sentiment

64% Positive

Analyzed from 443 words in the discussion.

Trending Topics

#instructions#nop#mmio#should#slow#https#com#using#interesting#code

Discussion (30 Comments)Read Original on HackerNews

markus_zhang•4 minutes ago
Does that mean Chris Domas is ready for his next adventure?
layer8•about 1 hour ago
Nop should be #1, because it is infinitely slow for what it does. ;)
jooops1•about 1 hour ago
It increments rip by one.
mito88•about 1 hour ago
Strategy: nop does nothing. It opens the leaderboard accordingly.

Score: 1 cycles Time: 0 nanoseconds

layer8•18 minutes ago
It opens the leaderboard as #27, so in the last place.
Retr0id•about 1 hour ago
Related, and linked in the readme: https://github.com/xoreaxeaxeax/smiiiiiiiiiiiiiiii (using the slow instructions to break SMI)
TomatoCo•about 2 hours ago
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
inigyou•about 1 hour ago
He also bruteforced the entire opcode space to find undocumented instructions (sandsifter).
spoocecow•about 2 hours ago
Oh wow, glad to see Chris Domas active online again!
michalsustr•about 1 hour ago
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?
inigyou•about 1 hour ago
AFAIK it acts as some kind of execution barrier, to give meaningful timing.
rrampage•about 1 hour ago
IshKebab•26 minutes ago
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.

codeshaunted•about 2 hours ago
what im seeing from this chart is that we should be using the nop instruction for everything
bee_rider•about 2 hours ago
Well the best code is no code. Nop could be second best though.
inigyou•about 1 hour ago
Instructions unclear. Set the NX bit to ensure no code, and got a general protection fault.
vardump•about 2 hours ago
A great resource for any performance deoptimization.
metadat•about 2 hours ago
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?

mwigdahl•about 1 hour ago
Wirth's Law I believe.
inigyou•about 1 hour ago
And remember to call him by name, not by value!
HappyPanacea•about 2 hours ago
The new windows notepad is a disgrace
adamrezich•5 minutes ago
The new mspaint fucked, then unfucked, then refucked my decades-old muscle memory of Win+R mspaint Enter Ctrl+E 1 Tab 1 Enter Ctrl+V to open Paint, resize canvas to minimum, then paste from clipboard. When you press Ctrl+E now, the Units control is selected by default, for some completely asinine reason!!!
inigyou•about 1 hour ago
Andy and Bill's Law
summarybot•about 1 hour ago
The OS should do less not more
LoganDark•about 2 hours ago
Huh? A millisecond is an eternity!
m463•about 1 hour ago
I remember reading once somewhere:

If some app responds in 10ms or less, it is INTERACTIVE.

makes you think.

Xirdus•about 1 hour ago
It is literally impossible to respond to input in 10ms on most platforms, for various reasons. The USB input lag of 12-30ms and the 60Hz refresh rate of most monitors being just the first two.
arn3n•about 2 hours ago
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.
Advertisement
achierius•about 2 hours ago
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.