19 ms·

Mmm. This sounds like you either know a hell of a lot more about the subject than me, or a hell of a lot less. If I point you at an example github repo, can yo

Mmm. This sounds like you either know a hell of a lot more about the subject than me, or a hell of a lot less. If I point you at an example github repo, can you devise a coherent and repeatable test for this "jitter"? Edit: > The current best solution is to side-load special fpga memory access modules into the multi-tasking kernel space for handling DSP data stream filtering on Zynq. Yeah, no. Also FIR? Really? Unacceptable.

Joel_Mckay 11d 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 10d ago
  I 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 10d ago
    In 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 10d ago
      You'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?

Joel_Mckay 11d 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 10d ago
I 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 10d ago
  In 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 10d ago
    You'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?