3 ms·
From what I can see in the graphs on GitHub it seems really computationally intensive, only a few thousand 30-bit elements per second (for decoding if I underst
by Lichtso 6y ago
From what I can see in the graphs on GitHub it seems really computationally intensive, only a few thousand 30-bit elements per second (for decoding if I understand it correctly).
So I guess that is the catch which makes it impractical for more widespread use. Or am I wrong, is there an alternative speed wise?
- nullc 6y agoDepends on how you split it up: if you're synchronizing 100 differences at a time it's on the order of 100,000 differences per second per core which is plenty fast for many applications. If you're working on thousands of differences at a time, then IBLT's communications efficiency may be a acceptable, and it is considerably faster. [You can always decrease the amount you feed into reconciliation at once by using hashing to subdivide your inputs, at a small loss to efficiency due to imbalancing.]