Your design bears significant similarity to my own work on an audio
streaming framework [1], which seems a bit more mature despite still
being the subject of significant experimentation on my part.
It looks like your elements do a lot of copying, which could have a
significant negative effect on performance. I approached the same
problem by having elements (Source in audiostream) return references
to mutable buffers (which may not be possible with Iterator). This
should allow elimination of most copies in real-world applications,
though at the moment my design calls for independent tasks for each
linear pipeline segment while will require a copy for each task.
I also found your Interleave block interesting, since I've been
working on squeezing performance out of my own Interleave block (I
expect most pipelines with have at least one of both Interleave and
DeInterleave, so vector optimizations are a good goal to reach for).
I'm pleased with the performance so far (10.5 GB/s on the ~3 GHz Core
i5 machine I'm testing on), but it might be useful to break that into
its own library so others can benefit from the vector optimizations.
Your connect! macro is nice; I've been planning to do something
similar (possibly define a whole DSL for pipeline specification which
can be used as a macro), but you beat me to it in this case. :)
Anyway, it looks like there are things we can learn from each other
here, and I'll be watching your project- might be a good excuse to get
some use out of my HackRF and contribute some components back.
[1] https://bitbucket.org/tari/audiostream.rs/
Post by Allen WelkieIf anyone is interested in software defined radios, I'm starting a project
called Rust Radio (very similar to GNU Radio). Take a look at
https://github.com/awelkie/rustradio. It's still pretty new, but critiques
and contributions are always welcome!
_______________________________________________
Rust-dev mailing list
Rust-dev at mozilla.org
https://mail.mozilla.org/listinfo/rust-dev
--
Peter Marheine
Don't Panic