Very low throughput

[nh2]

main = do
  let rs :: [Word8]
      rs = randoms (mkStdGen 42)

  print $ sum $ map (\x -> fromIntegral x :: Int) $ take 10000000 rs

gives me around 5 MB/s on my laptop.

main = do
  let rs :: [Int]
      rs = randoms (mkStdGen 42)

  print $ sum $ map (\x -> fromIntegral x :: Int) $ take 10000000 rs

gives me around 8 MB/s on my laptop.

This is very slow for a pseudorandom number generator.

/dev/urandom gives me 230 MB on the same machine.

[nh2]

I found this issue when trying to test my lz4 binding with QuickCheck (tests would take forever when generating reasonably sized input), so I started measuring the speed of random gens.

[idontgetoutmuch]

@nh2 don't use this package - see

#31
#29
https://ghc.haskell.org/trac/ghc/ticket/2280

Throughput is not its only problem.

I have made suggestions for replacing it and deprecating it.

@nh2 I thought QuickCheck used tf-random these days on account of this package not implementing split int a sensible way? Are you sure QuickCheck is actually using this package?

FYI - this runs about x10 faster for me.

import System.Random.MWC

main :: IO ()
main2 = do
    gen <- create

    let testUniform 0 !x = return (x :: Int)
        testUniform n x = do
            y <- uniform gen
            testUniform (n - 1) (x + y)

    total <- testUniform 10000000 0
    print total

[cartazio]

@nh2 master has a much more performant and good quality algorithm. Old random (current hackage ), Tf random and mwc all have poor statistical quality on any big crush. Addditionally, at no point have any of their Haskell interfaces been optimized for performance wrt batch throughout. Aka stream / unfold style interface Dominic: since you’ve done zero work of ever contributing to the new stuff, could you please just stop being involved on tickets and let’s just get you off the maintainer list? I can start doing drive by comments on stuff you do that I don’t help you on too otherwise. It’ll be really fun and demotivating. Just like you’ve been to meeeee. So please stop it. Please. You’re not helping accomplish anything except making an antagonistic dynamic that helps no one.

…

On Sun, Nov 25, 2018 at 6:13 AM idontgetoutmuch ***@***.***> wrote: @nh2 <https://github.com/nh2> don't use this package - see #31 <#31> #29 <#29> https://ghc.haskell.org/trac/ghc/ticket/2280 Throughput is not its only problem. I have made suggestions for replacing it and deprecating it. @nh2 <https://github.com/nh2> I thought QuickCheck used tf-random these days on account of this package not implementing split int a sensible way? Are you sure QuickCheck is actually using *this* package? FYI - this runs about x10 faster for me. import System.Random.MWC main :: IO () main2 = do gen <- create let testUniform 0 !x = return (x :: Int) testUniform n x = do y <- uniform gen testUniform (n - 1) (x + y) total <- testUniform 10000000 0 print total — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#51 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAAQwiBK8nB3XlNhbv0PD35UPII5Vt1jks5uyntQgaJpZM4Yxscq> .

[cartazio]

nh2: hey I can actually help you if you want on the rng stuff. If you want a fast decent rng today, use the pcg package. The next major version of random is gonna have some breaking changes and have a pcg variant as one of the recommended defaults. Pcg should be way faster / better quality than all the other non cryptographic rngs in hackage. What is the application domain / way of using rngs you have going on? On Sun, Nov 25, 2018 at 8:33 AM Carter Schonwald <[email protected]> wrote:

…

@nh2 master has a much more performant and good quality algorithm. Old random (current hackage ), Tf random and mwc all have poor statistical quality on any big crush. Addditionally, at no point have any of their Haskell interfaces been optimized for performance wrt batch throughout. Aka stream / unfold style interface Dominic: since you’ve done zero work of ever contributing to the new stuff, could you please just stop being involved on tickets and let’s just get you off the maintainer list? I can start doing drive by comments on stuff you do that I don’t help you on too otherwise. It’ll be really fun and demotivating. Just like you’ve been to meeeee. So please stop it. Please. You’re not helping accomplish anything except making an antagonistic dynamic that helps no one. On Sun, Nov 25, 2018 at 6:13 AM idontgetoutmuch ***@***.***> wrote: > @nh2 <https://github.com/nh2> don't use this package - see > > #31 <#31> > #29 <#29> > https://ghc.haskell.org/trac/ghc/ticket/2280 > > Throughput is not its only problem. > > I have made suggestions for replacing it and deprecating it. > > @nh2 <https://github.com/nh2> I thought QuickCheck used tf-random these > days on account of this package not implementing split int a sensible way? > Are you sure QuickCheck is actually using *this* package? > > FYI - this runs about x10 faster for me. > > import System.Random.MWC > > main :: IO () > main2 = do > gen <- create > > let testUniform 0 !x = return (x :: Int) > testUniform n x = do > y <- uniform gen > testUniform (n - 1) (x + y) > > total <- testUniform 10000000 0 > print total > > — > You are receiving this because you are subscribed to this thread. > Reply to this email directly, view it on GitHub > <#51 (comment)>, or mute > the thread > <https://github.com/notifications/unsubscribe-auth/AAAQwiBK8nB3XlNhbv0PD35UPII5Vt1jks5uyntQgaJpZM4Yxscq> > . >

[nh2]

I thought QuickCheck used tf-random these days on account of this package not implementing split int a sensible way? Are you sure QuickCheck is actually using this package?

I know, but tf-random is equally at least the way quickcheck-instances uses it, see: nick8325/quickcheck#234

don't use this package

@idontgetoutmuch I'm aware of the issues but I cannot easily patch it out all the way down to QuickCheck -- as you can imagine, this issue is just a sidetrack in my 5-levels deep recursion stack of what I actually want to work on :)

master has a much more performant and good quality algorithm

@cartazio This is nice, but for it to have a real impact it must be on Hackage and libs like QuickCheck must be using it.

What is the application domain / way of using rngs you have going on?

Right now, I just want QuickCheck to work at reasonable speeds. I'm writing an lz4 binding and wanted to test it with it, for which I need to generate lots of input ByteStrings, including large ones. I found that I cannot write a Gen ByteString that exceeds 8 MB/s, which makes my tests take forever.

So I started measuring the underlying libraries (random and tf-random and found that they are all slow).

Pcg should be way faster / better quality

Good hint, appreciated!

I have already implemented a workaround based on pcg-random (with a seed and target length generated by QuickCheck's choose) to generate the ByteStrings. I've measured that this works at ~300 MB/s, even faster than /dev/urandom.

But of course having to do this using this workaround isn't great; I am already many hours into a complete side-project -- I had expected this stuff to just work (tm).

could you please just stop being involved on tickets and let’s just get you off the maintainer list?

Let's not get bitter about things, we all want the same thing in the end. It is understandable that people are frustrated because a core component that they must rely on (by choice or dependency) doesn't work out of the box, for a long time. I too am frustrated because I didn't expect I'd be spending many hours of my weekend dealing with random number generation.

Pointing out problems with the current state is also a useful contribution (this is what my ticket here does, too). Let's not get discouraged by it, but rather encouraged to get things fixed.

[cartazio]

Nh2 I’m gonna be doing a release later this holiday season. Maybe this week. There’s some portability issues in the current interface that means you don’t get reproducible results on every platform. This holiday season Unless some work or personal emergencies derail stuff Additionally : there isn’t a a well defined split operation for pcg, or at least not one that’s well studied.

…

On Sun, Nov 25, 2018 at 12:16 PM Niklas Hambüchen ***@***.***> wrote: I thought QuickCheck used tf-random these days on account of this package not implementing split int a sensible way? Are you sure QuickCheck is actually using *this* package? I know, but tf-random is equally at least the way quickcheck-instances uses it, see: nick8325/quickcheck#234 <nick8325/quickcheck#234> don't use this package @idontgetoutmuch <https://github.com/idontgetoutmuch> I'm aware of the issues but I cannot easily patch it out all the way down to QuickCheck -- as you can imagine, this issue is just a sidetrack in my 5-levels deep recursion stack of what I actually want to work on :) master has a much more performant and good quality algorithm @cartazio <https://github.com/cartazio> This is nice, but for it to have a real impact it must be on Hackage and libs like QuickCheck must be using it. What is the application domain / way of using rngs you have going on? Right now, I just want QuickCheck to work at reasonable speeds. I'm writing an lz4 binding and wanted to test it with it, for which I need to generate lots of input ByteStrings, including large ones. I found that I cannot write a Gen ByteString that exceeds 8 MB/s, which makes my tests take forever. So I started measuring the underlying libraries (random and tf-random and found that they are all slow). Pcg should be way faster / better quality Good hint, appreciated! I have already implemented a workaround based on pcg-random (with a seed and target length generated by QuickCheck's choose) to generate the ByteStrings. I've measured that this works at ~300 MB/s, even faster than /dev/urandom. But of course having to do this using this workaround isn't great; I am already many hours into a complete side-project -- I had expected this stuff to just work (tm). could you please just stop being involved on tickets and let’s just get you off the maintainer list? Let's not get bitter about things, we all want the same thing in the end. It is understandable that people are frustrated because a core component that they must rely on (by choice or dependency) doesn't work out of the box, for a long time. I too am frustrated because I didn't expect I'd be spending many hours of my weekend dealing with random number generation. Pointing out problems with the current state is also a useful contribution (this is what my ticket here does, too). Let's not get discouraged by it, but rather encouraged to get things fixed. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#51 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAAQwkHd_9ipFkK0eZFlkh9GTp4xWdWcks5uytBPgaJpZM4Yxscq> .

[ecthiender]

@cartazio was this pcg version released? Just curious to know if the fast version has landed on hackage.

[cartazio]

atm not yet, but the split-mix and pcg packages on hackage should be decent today
(i had to work though how to make sure stuff is forward migrable, and now its on my release queue again once i suss things out with relevant CLC members)

[cartazio]

this is definitely my fault, but its one of those things where i need to / want to navigate evolving the ecosystem and breakages carefully

[ecthiender]

Ok, thanks for the update.

[lehins]

For anyone that is interested in this ticket, apparently it has been a problem for 12 years almost 15 years and there is finally a solution in #61

All we are waiting for now is getting it reviewed and released, right @cartazio ?

[cartazio]

There’s a bunch of fixes and improvements indeed.

…

On Tue, May 26, 2020 at 5:45 AM Alexey Kuleshevich ***@***.***> wrote: For anyone that is interested in this ticket, apparently it has been a problem for 12 years <https://gitlab.haskell.org/ghc/ghc/issues/2280> and there is finally a solution in #61 <#61> All we are waiting for now is getting it reviewed and released, right @cartazio <https://github.com/cartazio> ? — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#51 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAABBQTIMVSD2WFNCLZ2U4LRTOFR7ANCNFSM4GGGY4VA> .

[lehins]

@nh2 I am really happy to let you know that this is no longer an issue! 😄 random-1.2 is now on hackage.

Let me know the results if you get a chance to try out your throughput benchmark comparison against the /dev/urandom ;)