-
Notifications
You must be signed in to change notification settings - Fork 61
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Request for a new Release #53
Comments
On second thought it seems as though master is much slower than the current Here's a comparison of master with rse_benchmark vs On Master
On 3.1.1 the only change I've made is
and it benchmarks really well
without the
I guess for now we're going to fork this repo and run without rayon. |
Sorry I've just started my PhD, so schedule's a bit hectic. But I am trying to clear issues this week as promised to others as well.
The current master core code is implemented for polymorphic type with trait bound (I think), which is done by the various people who added the Galois 16 backend. I wasn't previously sure of the performance implication of not implementing code for Do you have some numbers on how slow master is compared to your 3.1.1 branch without Rayon? |
Oh that's pretty great! I can imagine finding time for pet projects must be hard :) My previous comment shows the benchmark(parameters included) on master vs the benchmark on 3.1.1 and also the massive improvement by disabling the outer rayon loop. Take a look at it again? Lmk if I can help clarify. |
Whoops sorry! Yep I read it properly now. I just remembered master (here) disables SIMD by default now, mind if you add feature `"simd-accel" for master and try again in rse-benchmark? That might remove a large part of the discrepancy. |
Alright I'll give that a shot. I'm afk for the next few hours but I'll post here when I've got the numbers :) |
Thanks very much! |
@darrenldl that seems to have done it!
Super fast now and lines up with the non-rayon impl I forked. So that makes sense now. :) |
Thanks! Since master here doesn't use rayon as well, I'm guessing the trait way of doing things are causing slight slow down maybe, but benchmarking this lib has always been very sensitive to noise, so I'll confirm later. In any case, 100MB/s performance degradation seems acceptable if it means the architecture can support more backends (gf8 + gf16). |
I'm sure it needs a wider data set of testing to confirm but this definitely speeds everything up within margin of error of our fork of I think as soon as you're able to make a new release we'll drop our fork and switch to this. |
4.0.0 has been released, closing this issue But feel free to let me know if there are stuff still to be resolved via here or other channels |
Hi @darrenldl!
We over at https://github.com/solana-labs/solana are seeing some major slowdowns with
reed-solomon-erasure's
use of rayon on3.1.1
(possibly related to rayon-rs/rfcs#5).Our use case hurts particularly badly since our data size is much smaller(set to MTU) than those used in the
rse-benchmarks
project.We were about to fork this project to get rid of the rayon usage but I just noticed that master has moved on from rayon and doesn't rely on it anymore.
Is it possible that you can make a release any time soon ?
The text was updated successfully, but these errors were encountered: