3 ms·

> In general, any llvm compiled language is going to have persistent unpredictable jitter related issues. So if I compiled my own SDR software written in C wit

> In general, any llvm compiled language is going to have persistent unpredictable jitter related issues. So if I compiled my own SDR software written in C with LLVM/Clang, it would suddenly have jitter issues? Can you explain why?

Joel_Mckay 12d ago
In C, even without inline assembly or "volatile" to gaurentee the same code motion every time, it is still possible to bake what is placed in "register" a priori. In llvm binaries, the code is abstracted/re-ordered, optimized/deduplicated, and flow may operate completely differently with minimal changes. One may gain 11% to 15% raw computational throughput performance, but have no latency guarantees on what the pipeline will do or when. This will often eventually cause intermittent CDC mismatch under load, as the compiler pseudo-randomly decides to do something silly every time something is updated. https://en.wikipedia.org/wiki/Clock_domain_crossing https://en.wikipedia.org/wiki/Clock_domain_crossing 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. https://en.wikipedia.org/wiki/Finite_impulse_response https://en.wikipedia.org/wiki/Finite_impulse_response https://www.analog.com/en/resources/evaluation-hardware-and-software/evaluation-boards-kits/adalm-pluto.html#eb-overview https://www.analog.com/en/resources/evaluation-hardware-and-... Best of luck, =3
- acuozzo 12d ago
  Is it possible you're confusing LLVM with JIT compilation? Clang targeting LLVM, despite the name, produces binaries compiled 100% ahead-of-time. The "LLVM" is just the intermediate representation used by the compiler. GCC uses GIMPLE and RTL. > In C... it is still possible to bake what is placed in "register" a priori By what mechanism? Even ancient GCC circa 1989 ignored the "register" keyword/storage-class. Automatic register allocation algorithms have been the default for a long time. You have to go back to the K&R days to find a compiler willing to honor it (or find an esoteric compiler like AZTEC C for the 6502).
  - Joel_Mckay 11d ago
    JIT is even worse, as if you have ever built a compiler one already knows about why backpatching is needed during the generator stages. I cringe every time someone brings up embedded python, and lose hope for future coders. I agree it is subtle, so takes some people a few hours to understand, and for others never. If you work in Application user-space, than it usually won't matter. Note I like Julia, but it is also not a good fit for SDR or low-latency DSP. People seem upset for some reason, but one may want to check out Analog Devices training documentation as a student. =3
    - ErroneousBosh 10d ago
      > People seem upset for some reason, but one may want to check out Analog Devices training documentation as a student. =3 You're making some pretty interesting and unusual claims. Can you show a Proof-of-Concept of what you're talking about?
    - jeezfrk 11d ago
      Julia is not written in assembly.
      - Joel_Mckay 11d ago
        "Julia programs automatically compile to efficient native code via LLVM" ( https://julialang.org/ https://julialang.org/ ) Have a nice day =3
    - acuozzo 11d ago
      I'm not a student. I work with SDRs and in latency-critical problem domains at a telecommunications research laboratory. I'm also not upset. I just want to know which compilers you're using which honor the "register" keyword in C.
- jath03 11d ago
  Interesting, so some of LLVM's optimization passes change the program in ways that introduce subtle latencies that can matter for DSP applications? Does this apply to clang-compiled C, or only some other languages with llvm back-ends?
  - Joel_Mckay 11d ago
    All llvm compilers I have seen do this, and it includes one of my favorites Julia as well. =3
- ronsor 11d ago
  I think if we're going that deep about latency, you really ought to stay away from traditional x86 (and ARM64!) platforms entirely. SMM firmware can interrupt any time for whatever reason, meaning even a plain, unoptimized assembly program can have unpredictable latency.
  - Joel_Mckay 11d ago
    RTLinux kernel works fine on both platforms, and includes external synchronous scheduling context clock peripheral input on arm64 (the kernel scheduled tasks are synchronized across all RT processors.) Indeed, people can write shit code in any language. Trying to avoid a problem is fine, but sometimes people still do silly things for irrational reasons. =3
    - Retr0id 11d ago
      SMM doesn't care what kernel you're running, it will preempt you anyway.
- ErroneousBosh 11d ago
  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

Joel_Mckay 12d ago

In C, even without inline assembly or "volatile" to gaurentee the same code motion every time, it is still possible to bake what is placed in "register" a priori. In llvm binaries, the code is abstracted/re-ordered, optimized/deduplicated, and flow may operate completely differently with minimal changes. One may gain 11% to 15% raw computational throughput performance, but have no latency guarantees on what the pipeline will do or when. This will often eventually cause intermittent CDC mismatch under load, as the compiler pseudo-randomly decides to do something silly every time something is updated. https://en.wikipedia.org/wiki/Clock_domain_crossing https://en.wikipedia.org/wiki/Clock_domain_crossing 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. https://en.wikipedia.org/wiki/Finite_impulse_response https://en.wikipedia.org/wiki/Finite_impulse_response https://www.analog.com/en/resources/evaluation-hardware-and-software/evaluation-boards-kits/adalm-pluto.html#eb-overview https://www.analog.com/en/resources/evaluation-hardware-and-... Best of luck, =3

acuozzo 12d ago
Is it possible you're confusing LLVM with JIT compilation? Clang targeting LLVM, despite the name, produces binaries compiled 100% ahead-of-time. The "LLVM" is just the intermediate representation used by the compiler. GCC uses GIMPLE and RTL. > In C... it is still possible to bake what is placed in "register" a priori By what mechanism? Even ancient GCC circa 1989 ignored the "register" keyword/storage-class. Automatic register allocation algorithms have been the default for a long time. You have to go back to the K&R days to find a compiler willing to honor it (or find an esoteric compiler like AZTEC C for the 6502).
- Joel_Mckay 11d ago
  JIT is even worse, as if you have ever built a compiler one already knows about why backpatching is needed during the generator stages. I cringe every time someone brings up embedded python, and lose hope for future coders. I agree it is subtle, so takes some people a few hours to understand, and for others never. If you work in Application user-space, than it usually won't matter. Note I like Julia, but it is also not a good fit for SDR or low-latency DSP. People seem upset for some reason, but one may want to check out Analog Devices training documentation as a student. =3
  - ErroneousBosh 10d ago
    > People seem upset for some reason, but one may want to check out Analog Devices training documentation as a student. =3 You're making some pretty interesting and unusual claims. Can you show a Proof-of-Concept of what you're talking about?
  - jeezfrk 11d ago
    Julia is not written in assembly.
    - Joel_Mckay 11d ago
      "Julia programs automatically compile to efficient native code via LLVM" ( https://julialang.org/ https://julialang.org/ ) Have a nice day =3
  - acuozzo 11d ago
    I'm not a student. I work with SDRs and in latency-critical problem domains at a telecommunications research laboratory. I'm also not upset. I just want to know which compilers you're using which honor the "register" keyword in C.
jath03 11d ago
Interesting, so some of LLVM's optimization passes change the program in ways that introduce subtle latencies that can matter for DSP applications? Does this apply to clang-compiled C, or only some other languages with llvm back-ends?
- Joel_Mckay 11d ago
  All llvm compilers I have seen do this, and it includes one of my favorites Julia as well. =3
ronsor 11d ago
I think if we're going that deep about latency, you really ought to stay away from traditional x86 (and ARM64!) platforms entirely. SMM firmware can interrupt any time for whatever reason, meaning even a plain, unoptimized assembly program can have unpredictable latency.
- Joel_Mckay 11d ago
  RTLinux kernel works fine on both platforms, and includes external synchronous scheduling context clock peripheral input on arm64 (the kernel scheduled tasks are synchronized across all RT processors.) Indeed, people can write shit code in any language. Trying to avoid a problem is fine, but sometimes people still do silly things for irrational reasons. =3
  - Retr0id 11d ago
    SMM doesn't care what kernel you're running, it will preempt you anyway.
ErroneousBosh 11d ago
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