On Tue, Mar 15, 2016 at 10:29 AM, Derek Buitenhuis <derek.buitenh...@gmail.com> wrote: > On 3/15/2016 4:46 AM, Ganesh Ajjanagadde wrote: >> Concretely, it is nearly as fast as av_lfg_get (which only returns 32 bits), >> and has a much smaller cache (128 bits). Thus, the timings should also >> be more stable. >> >> This is needed because av_lfg_get<<32 | av_lfg_get is far slower, and >> likely less random as measured by BigCrush - most LFG's perform >> quite poorly on the BigCrush suite: >> http://www6.tw.freebsd.org/distfiles/testu01.pdf. >> In particular, FFmpeg's seems to be Ran055 in the paper, see pg31. > > This doesn't explain how it benefits our uses of PRNGs. We are a set of > multimedia > libraries, not a general utilities library. Most of our use is for noise > generation > or unit tests, neither of which benefits much/at all from this.
If one wants good Gaussian samples, then yes, I need a 64 bit rng. Please also note that I can use av_lfg_get, it does not result in slowdown, since speed benefits here come from the ziggurat algo. Concretely, it is 82 cycles vs 81 cycles; too little to clearly distinguish. I was just not too happy with av_lfg_get << 32 | av_lfg_get as it resulted in some bad values in the Anderson Darling tests. I don't know if good quality Gaussian samples are needed, I welcome comments from AAC coding people. In particular, I have already mentioned in the patch notes that this yields ~ 1-2% in aac encoding speed. If you do a profile run, av_bmg_get does show up with nearly 2-3% time spent in it overall. [...] _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
