3 ms·
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.
by valleyer 2y ago
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.
- dataflow 2y agoYeah. 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?
- Bulat_Ziganshin 2y agoexcept that we need max() here :)
- dataflow 2y agoHuh, why max()? Generally microbenchmarks want min() (or close to it).
- Bulat_Ziganshin 2y agobecause THIS code becomes faster once RCX is saved and restored during the interrupt call
- dataflow 2y agoOh right, my bad, thanks. Totally escaped me when I wrote that :-)
- toast0 2y agoYou 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.