[FFmpeg-devel] [PATCHv3 1/3] lavu/rand: add 64 bit random number generator
Ganesh Ajjanagadde
gajjanag at gmail.com
Tue Mar 15 23:26:45 CET 2016
On Tue, Mar 15, 2016 at 10:29 AM, Derek Buitenhuis
<derek.buitenhuis at 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.
[...]
More information about the ffmpeg-devel
mailing list