-
Notifications
You must be signed in to change notification settings - Fork 25
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
Insufficient Laziness? #35
Comments
https://hackage.haskell.org/package/vector says it has "a powerful loop optimisation framework " so I think the loop in the vector version should get fused. |
Using V.foldl' performs no better. |
And indeed Data.Vector does fuse very nicely in this example
|
I think you may not be understanding how laziness works. The reason that mwc-random allocates an entire vector of random data when you use If it's any comfort, your misunderstanding is common enough, but I don't think this bug report is the right place to debug and correct it (and sadly I don't have time to help you individually). You might consider asking for assistance with getting a better grasp in Good luck! |
Consider
This runs quite fast
and beats Matlab / Octave
But look at the space usage: 764 MB total memory. Maybe that is not surprising as we are using (unboxed) vectors. So let's try creating a list equivalent.
Notice that we only want the head of the list and we are creating only 10^7 samples rather than 10^8.
So not only does it run slower than the vector version (which has more samples) but it also consumes 905 MB total memory.
On the other hand if I use random-fu (https://hackage.haskell.org/package/random-fu) e.g.
Then it is very slow (x10 worse than the Vector version using mwc-random and x10 worse than Matlab) but look at the space usage: 1 MB total memory.
Now I believe random-fu uses mwc-random so it should be possible to create a sampler using mwc-random that consumes the same space as random-fu (i.e. 1 MB). How can this be done? Is it possible to get the speed of unboxed vectors and the space usage of random-fu? Now that I think about it shouldn't the production of (unboxed) vectors get fused with the consumption of them? So my list experiment is perhaps redundant and we should investigate why so much space is used with the (unboxed) vectors.
The text was updated successfully, but these errors were encountered: