Rendered at 06:48:41 GMT+0000 (Coordinated Universal Time) with Cloudflare Workers.
mandiantBob 15 hours ago [-]
This looks along the same lines as CyberEther, though CyberEther does have alot more features to enable massive compute of raw data and arguably nicer gui.(https://github.com/luigifcruz/CyberEther)
newspicel 12 hours ago [-]
[dead]
Retr0id 16 hours ago [-]
Is this GNU Radio vibe-ported to rust? How does it compare?
Joel_Mckay 15 hours ago [-]
In general, any llvm compiled language is going to have persistent unpredictable jitter related issues. Only the naive think Rust is a replacement for C/C++, but the same issues also occur with clang compilers for the same reasons.
They now have 2 DSP problems by porting to llvm languages like Rust, but will insist their work isn't worse than the C they attempted to "upgrade". =3
> 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 10 hours 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.
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.
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 9 hours 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
jeezfrk 2 hours ago [-]
Julia is not written in assembly.
Joel_Mckay 54 minutes ago [-]
"Julia programs automatically compile to efficient native code via LLVM" ( https://julialang.org/ )
Have a nice day =3
ronsor 4 hours 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 39 minutes 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
jath03 9 hours 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 8 hours ago [-]
All llvm compilers I have seen do this, and it includes one of my favorites Julia as well. =3
newspicel 12 hours ago [-]
[dead]
newspicel 12 hours ago [-]
[dead]
bmgxyz 15 hours ago [-]
I wonder how much of the signal graph feature set could be implemented as an SDR++ module. It could even be written in Rust with some FFI.
Rather than rewrite the entire SDR++ core in a separate project, maybe it would be better to incrementally port the existing code to Rust in a fork. I don't know what attitude the maintainers have toward Rust, though.
newspicel 12 hours ago [-]
[dead]
tamimio 8 hours ago [-]
Looks very similar in look and functionality to sdrangel, how’s it different? I remember running sdrangel in containter on a jetson nano and was eating the resources like crazy, any improvement over that?
They now have 2 DSP problems by porting to llvm languages like Rust, but will insist their work isn't worse than the C they attempted to "upgrade". =3
https://en.wikipedia.org/wiki/Metastability#Electronic_circu...
https://www.youtube.com/watch?v=T4Upf_B9RLQ
So if I compiled my own SDR software written in C with LLVM/Clang, it would suddenly have jitter issues?
Can you explain why?
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
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://www.analog.com/en/resources/evaluation-hardware-and-...
Best of luck, =3
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).
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
Have a nice day =3
SMM firmware can interrupt any time for whatever reason, meaning even a plain, unoptimized assembly program can have unpredictable latency.
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
Rather than rewrite the entire SDR++ core in a separate project, maybe it would be better to incrementally port the existing code to Rust in a fork. I don't know what attitude the maintainers have toward Rust, though.