I've been working on a faster implementation of Py-ART's region-based velocity dealiasing algorithm and wanted to check whether it would be useful upstream before going further with integration.
The implementation is here: https://github.com/FahrenheitResearch/region-global-dealias
On the same synthetic 720 x 1200 sweep (864,000 gates), both single-threaded:
- Py-ART 2.2.0
dealias_region_based: 48.2 ms median, about 17.9 million gates/sec
- Native Rust implementation: 5.2-5.7 ms median, about 150-165 million gates/sec
Fixture construction and radar decoding were excluded from both timings. The Rust process used roughly 6.7 MiB of additional peak working memory above the prepared input for this case. I would also want to benchmark a public collection of real sweeps before making any broader performance claims.
The speedup mostly comes from keeping the sweep in flat buffers and replacing repeated region/edge scans with union-find, indexed neighbor tracking, and a lazy priority queue. It is still the same general region-based approach rather than a different dealiasing method.
I do not want to force a new language or build dependency into Py-ART without discussing it first. The two integration paths that seem reasonable are:
- Port the optimized core to Cython so it fits Py-ART's existing build system.
- Keep it as an optional compiled backend, with the current implementation remaining available as the fallback.
Either way, I would preserve the existing dealias_region_based public API and keep the Python layer responsible for Radar objects, field metadata, masks, ref_vel_field handling, and keep_original. The private native boundary would operate on one sweep and return fold counts rather than replace the whole public function.
Before submitting a PR I would also cover the existing controls and edge cases: custom interval limits/splits, gap settings, centered behavior, forced/automatic ray wrapping, masks and missing gates, sector scans, varying Nyquist velocity, and reference-field anchoring. The test plan would include deterministic parity tests plus a redistributable set of real Level II sweeps.
Would either of these approaches be welcome? If so, is Cython strongly preferred, or would an optional Rust backend be reasonable?
I've been working on a faster implementation of Py-ART's region-based velocity dealiasing algorithm and wanted to check whether it would be useful upstream before going further with integration.
The implementation is here: https://github.com/FahrenheitResearch/region-global-dealias
On the same synthetic 720 x 1200 sweep (864,000 gates), both single-threaded:
dealias_region_based: 48.2 ms median, about 17.9 million gates/secFixture construction and radar decoding were excluded from both timings. The Rust process used roughly 6.7 MiB of additional peak working memory above the prepared input for this case. I would also want to benchmark a public collection of real sweeps before making any broader performance claims.
The speedup mostly comes from keeping the sweep in flat buffers and replacing repeated region/edge scans with union-find, indexed neighbor tracking, and a lazy priority queue. It is still the same general region-based approach rather than a different dealiasing method.
I do not want to force a new language or build dependency into Py-ART without discussing it first. The two integration paths that seem reasonable are:
Either way, I would preserve the existing
dealias_region_basedpublic API and keep the Python layer responsible for Radar objects, field metadata, masks,ref_vel_fieldhandling, andkeep_original. The private native boundary would operate on one sweep and return fold counts rather than replace the whole public function.Before submitting a PR I would also cover the existing controls and edge cases: custom interval limits/splits, gap settings, centered behavior, forced/automatic ray wrapping, masks and missing gates, sector scans, varying Nyquist velocity, and reference-field anchoring. The test plan would include deterministic parity tests plus a redistributable set of real Level II sweeps.
Would either of these approaches be welcome? If so, is Cython strongly preferred, or would an optional Rust backend be reasonable?