dataflow parent
Wow. Any chance you could share either an explanation or your benchmark code to show how you measured this reliably? I've never had to constrain benchmarks to within a time slice so I'm kind of fascinated how you got stable measurements out of that. Did you force a context switch prior to starting and then loop for a fixed number of times that wouldn't trigger another context switch? Or did you disable preemption on your thread, or something else?
Benchmark code is in the post! The trick is to limit the number of SHLX instructions before you re-initialize RCX. Doing it every 10,000 keeps it fresh enough. I didn't have to disable preemption or anything, perf shows 0 context switches and only ~50 page faults (probably all at startup).
Yeah, even an interrupt (that doesn't result in a thread switch) would cause a spill to the stack, right? That seems hard to control.
You should be able to prevent or at least strictly limit interrupts if you run a modern kernel, have a single threaded test process and cpu pin your test process to core X, while you've pinned everything else to not core X (and not core X's cpu threads if enabled), and you have no hardware interrupts routed to that core, either.
You might have to look into tickless kernels too, but I think that's pretty mainstream now. Tldr, if there's no contention for the core and there's no hardware interrupts, there's no need for a timer/scheduler tick on that core.
Yeah. I don't know how often interrupts happen to know how easy this would be to control for, but it certainly sounds like it could be tough. I suppose one way to mitigate these though is e.g. taking a min() of the execution times rather than the average?
except that we need max() here :)
Huh, why max()? Generally microbenchmarks want min() (or close to it).
because THIS code becomes faster once RCX is saved and restored during the interrupt call
Oh right, my bad, thanks. Totally escaped me when I wrote that :-)