-
Notifications
You must be signed in to change notification settings - Fork 139
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
Some operations are slow due to fusion oriented definitions (replicateM) #113
Comments
@mgsloan 1) what GHC version 2) what optimization levels 3) do we currently have any rewrite rules that should have accomplished this? |
either way, thanks for including the unrolling of the definitions on the ticket, that will help contextulize discussing this |
I'm not sure what to do about this, we can either prioritize fusion working or prioritize normal vector performance. It would be interesting to benchmark how well some multi-step fusion thing performs with the non-fusion definition of |
since i'm on 8.0Tip atm, I'll have a go at digging into this this weekend (if you or @dolio or @hvr nudge me), since build times etc for vector are much more pleasant in 8.0 land. I do agree with what you're saying, and that does remind me of some of the other improvements for making imperative ish code much nicer to write in vector, esp since fusion isn't a cureall (though it can be darn nice) |
@mgsloan did you have any good comparative conclusions here? |
if you have some some benchmarking code you can share comparing implementations/performance, please share, closing for now |
replicateM
round trips through a list, even though we immediately know the size of the result and could allocate it. It's much faster (5x for my application) to do something like thisRelevant chunks of code:
From
Data.Vector
:From
Data.Vector.Generic
:The text was updated successfully, but these errors were encountered: