I did not mean to encourage a battle about this, and certainly not in the context of channel selection fairness.
The top N-bits of the worst LCG would be just fine for selecting among 2^N alternatives. Though unstated, my comment back in October was that it would be nice to have all pseudo-randomness come from a well-respected source whose quality exceeds any "practical" non-specialist requirement solely for the purpose of allowing all Go developers--language implementers or application developers--to be blissfully ignorant of the details yet well-protected against mysterious woes. That was a position statement, and while it came with a suggestion for my carefully considered preference, any other suitable choice would be fine. I only had one library to offer, so I did, but it has been tested in the most stringent ways and I felt it was worthy. (In fact, have suggested PCG every few years when the topic comes up) The speed topic feels a little false to me, even as a speed demon myself. It is presently possible to do about 3 million channel receives on my machine. Selects are slower. The range of PRNG times under consideration are 0.5ns to 10ns per value. It seems unlikely that any choice on this 20:1 speed scale would make a meaningful difference in detectable program performance when actually selecting things and transferring values. On Sat, Dec 30, 2017 at 3:55 AM, Юрий Соколов <funny.fal...@gmail.com> wrote: > Xorshift32 is not faster than PCG32. Xorshift64+ in a sense 2x32 is at > least as fast as PCG32, and that is used in a tip. Multiplication used > after rng to calculate integer in a range 0<=x<N. > > Statistical properties are not so important in this use case. It shouldn't > be obviously flawed as it was, but nothing like "it should pass BigCrush". > > 30 дек. 2017 г. 9:21 AM пользователь "Matt Harden" <matt.har...@gmail.com> > написал: > > It was stated earlier in the thread that tip was using > xorshift32+multiplication. I assumed that was what you were saying that PCG > was not faster than. I have not tested myself but I have no reason to > isbelieve the results on the PCG site. It's a red herring to compare > against xorshift128+ or xoroshiro128+, as that is not what's (said to be) > used at tip currently. I mistakenly left out the "32" when referring to it. > Admittedly the specific kind of PCG was not stated either, which would be > important for any comparison. > > This is not an area that I claim to have much knowledge of; it just > appeared to me that you were dismissing PCG without citing evidence when my > cursory review suggested that it did have advantages. > > On Fri, Dec 29, 2017 at 10:00 PM Юрий Соколов <funny.fal...@gmail.com> > wrote: > >> I've said nothing about "multiplication". Where you take "multiplication" >> from? Xorshift+ is already good enough for most usages. >> >> PCG performance page didn't include results neither for xorshift128+, nor >> for xoroshiro128. >> >> But xoroshiro page has comparisons: http://xoroshiro.di.unimi.it/#speed >> >> And, did you measure by yourself? >> >> 30 дек. 2017 г. 6:44 AM пользователь "Matt Harden" <matt.har...@gmail.com> >> написал: >> >> PCG isn't faster than xorshift+multiplication? Do you have a rebuttal to >> their website that indicates it is? (called xorshift* on that page) >> http://www.pcg-random.org/rng-performance.html >> >> Or are you just saying it's not meaningfully faster for the purpose of >> channels because the other channel overheads are high enough to make the >> difference irrelevant? Or maybe that it isn't faster with current Go >> compliers? >> >> They also claim it's better statistically, but perhaps if we only care >> about fairness it's essentially the same. >> >> On Mon, Oct 30, 2017 at 12:34 AM Sokolov Yura <funny.fal...@gmail.com> >> wrote: >> >>> > it would be great to move to pcg. >>> >>> Why? PCG isn't faster, isn't simpler and isn't better (though not worse >>> either). >>> >>> -- >>> You received this message because you are subscribed to the Google >>> Groups "golang-nuts" group. >>> To unsubscribe from this group and stop receiving emails from it, send >>> an email to golang-nuts+unsubscr...@googlegroups.com. >>> >>> For more options, visit https://groups.google.com/d/optout. >>> >> > -- > You received this message because you are subscribed to the Google Groups > "golang-nuts" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to golang-nuts+unsubscr...@googlegroups.com. > For more options, visit https://groups.google.com/d/optout. > -- Michael T. Jones michael.jo...@gmail.com -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
