4 ms·
Should still be repeatable with a more modern benchmark suite and RT patch, but depends what your design constraints entail. https://people.mpi-sws.org/~bbb/pa
by Joel_Mckay 21d ago
Should still be repeatable with a more modern benchmark suite and RT patch, but depends what your design constraints entail.
https://people.mpi-sws.org/~bbb/papers/pdf/ospert13.pdf https://people.mpi-sws.org/~bbb/papers/pdf/ospert13.pdf
Personally, I would try something cheeky like porting classic cycletest to Rust, and run the two stripped versions under identical test loads to see if the skew is noticeable from user-space. Then re-run the test after an identical slight change affecting code motion. That should exclude most confounding variables like modern kernel language dependency injections etc.
Doesn't sound very fun, but should be relatively trivial to quantify. In my use-case, two concurrent register state change atomic operations order timing proved important. Heisenbugs are hard to replicate, but wishing them away doesn't help. Best of luck =3
- ErroneousBosh 20d agoI don't use Rust, it's a waste of time. I know about scheduling and latency. Can you explain why you think that using one compiler is likely to make the latency worse than a different compiler? Can you show Proof of Concept? Can you explain how to get a compiler that treats the "register" keyword as a no-op to pin a value to a particular register?
- Joel_Mckay 20d agoIn general, the code motion in C pushes the same local states of the registers like program counter return location onto the stack before entering each function. It is sometimes inefficient, but usually generates the same binary every time with optimizations off. By de-compiling the objects one may validate a set number of cycles have elapsed by counting the instructions. In an llvm, the abstraction may significantly change code motion or defer the function call event time in an unpredictable manner. This is not a bug, but rather compilers operating as defined. In my case, two registers that appear unrelated to the compiler, but share a coherent external dependent state. A lockup can occur when the order of operations do not follow a strict linear sequence of events. PoCs are not fun... Best of luck. =3 https://en.wikipedia.org/wiki/Sealioning https://en.wikipedia.org/wiki/Sealioning
- ErroneousBosh 20d agoYou're not actually answering the question. You are claiming that compiling with LLVM will make jitter worse than with GCC, but you're not actually explaining why you think that or demonstrating how it happens. Can you show me how to reproduce your findings?