RaptorQ encode cost: investigate SIMD GF(256) / systematic-only encode to cut the ~24µs setup #31
Labels
No labels
bug
documentation
duplicate
enhancement
good first issue
help wanted
invalid
question
wontfix
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set
Reference
femboy/yip#31
Loading…
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
The dominant per-packet CPU term when FEC is active is RaptorQ
Encoder::new(~24 µs, the intermediate-symbol solve over GF(256)). Object batching (separate issue) amortizes the per-object setup across N packets, but the absolute encode cost is still the biggest lever for the FEC-active path.Investigate reducing it directly: (a) whether the
raptorqcrate's GF(256) matrix math is SIMD-accelerated and whether a faster backend / crate exists; (b) a systematic-encode fast path that generates repair symbols without the full intermediate-symbol solve for small objects; (c) upstreaming an optimization toraptorq. Deep/exploratory — the crypto (AEAD) is already SIMD (~2 µs, not a lever), so FEC is where the remaining per-packet CPU is. Measure with thepipeline_profileexample.Obsolete after the FEC codec swap in #50: RaptorQ was replaced by a small-K systematic Reed–Solomon codec (encode ~26 µs → ~1.33 µs). The ~24 µs RaptorQ per-object setup this issue targets no longer exists, so the motivation is gone. Closing.