Re: [boost] Boost.Uuid and header-only support

Subject: Re: [boost] Boost.Uuid and header-only support
From: James E. King, III (jking_at_[hidden])
Date: 2017-11-05 05:40:17

On Sun, Nov 5, 2017 at 12:55 AM, Peter Dimov via Boost <
boost_at_[hidden]> wrote:

> James E. King, III wrote:
>
>> On Sat, Nov 4, 2017 at 10:59 PM, Peter Dimov via Boost <
>> boost_at_[hidden]> wrote:
>>
>> > James E. King, III wrote:
>> >
>> > Benchmark Times reusing a generator (1M loops):
>> >>   old implementation:
>> >>  0.021822s wall, 0.031250s user + 0.000000s system = 0.031250s CPU >>
>> (143.2%)
>> >>   new implementation:
>> >>  0.373160s wall, 0.375000s user + 0.000000s system = 0.375000s CPU >>
>> (100.5%)
>> >>
>> >> Benchmark Times using a new generator for each uuid (10K loops):
>> >>   old implementation:
>> >>  1.168479s wall, 1.171875s user + 0.000000s system = 1.171875s CPU >>
>> (100.3%)
>> >>   new implementation:
>> >>  0.010272s wall, 0.015625s user + 0.000000s system = 0.015625s CPU >>
>> (152.1%)
>> >>
>> >
>> > These results look odd to me. What code exactly is being tested?
>> >
>> >
>> I went over it a number of times to be sure, and stepped through with the
>> debugger to make sure it was actually going into the right code paths. I'll
>> have to recreate the test as a separate benchmark that I can submit and
>> build as part of the project.
>>
>
> I was confused by the first set using 1M loops, and the second one using
> only 10K. Didn't catch that at first, so the results didn't make any sense.
> Need to multiply the second test by 100 for the two to be comparable.
>
> Have you tried RtlGenRandom by any chance?
>
>
You cannot compare the 1M and 10K loops with much meaning:

In the 1M loop the generator is constructed once then operator() is called
1M times.
In the 10K loop the generator is constructed on each loop and operator() is
called one time.
The test would take way too long to be reasonable if I ran the latter 1M
times.

The intention is to show that seeding the mersenne twister (default
random_generator) is expensive
so you do it once, then it is relatively cheap to make random uuids from
it.  Conversely, bypassing
the PRNG and using a random_device directly is quite slow when you go
through wincrypt.
In other words, the existing implementation may be optimal using a PRNG.

I have not tried RtlGenRandom yet, but I am worried about removing Wincrypt
in favor of that because
it will break any implementation that uses its own entropy provider, for
example a wincrypt driver that
hooks up to a hardware entropy generator based on project requirements
(government, etc).

It's worth testing how fast it is however, so I will add that to the bench
test I am putting together.

I also have not tried the same on a POSIX system (urandom).

- Jim