[
https://issues.apache.org/jira/browse/RNG-104?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16867831#comment-16867831
]
Alex D Herbert commented on RNG-104:
------------------------------------
For completeness I have added the use of the fair and unfair lock to the
performance table for creation of a single int or long using various
thread-safe methods:
||Type||Method||1 thread||4 threads||
|int|ThreadLocalRandom_nextInt|1.39|1.67|
|int|ThreadLocalSplitMix_nextInt|4.03|33.08|
|int|ThreadLocalRNG_nextInt|4.28|24.42|
|int|ThreadLocalSequenceMix_nextInt|4.41|20.82|
|int|AtomicInt_getAndIncrement|4.82|62.61|
|int|volatileInt_increment|4.83|143.45|
|int|SyncSplitMix_nextInt|6.54|69.60|
|int|Random_nextInt|7.48|326.74|
|int|FairLock_XorShift1024StarPhi_nextInt|15.05|42,808.57|
|int|UnfairLock_XoRoShiRo128Plus_nextInt|15.15|212.06|
|int|UnfairLock_XorShift1024StarPhi_nextInt|15.25|233.13|
|int|FairLock_XoRoShiRo128Plus_nextInt|15.36|43,605.65|
|int|Sync_XorShift1024StarPhi_nextInt|17.04|312.60|
|int|Sync_XoRoShiRo128Plus_nextInt|17.21|350.46|
|int|Sync_Well44497b_nextInt|18.67|494.17|
|int|UnfairLock_Well44497b_nextInt|19.74|320.05|
|int|FairLock_Well44497b_nextInt|20.04|43,465.64|
|int|System_identityHashCode|38.02|41.17|
|int|SeedFactory_createInt|54.56|821.41|
|long|ThreadLocalRandom_nextLong|1.39|1.66|
|long|ThreadLocalSplitMix_nextLong|4.00|26.13|
|long|ThreadLocalRNG_nextLong|4.41|4.86|
|long|ThreadLocalSequenceMix_nextLong|4.57|21.31|
|long|AtomicLong_getAndIncrement|4.83|69.25|
|long|volatileLong_increment|4.83|148.76|
|long|SyncSplitMix_nextLong|6.58|87.68|
|long|UnfairLock_XoRoShiRo128Plus_nextLong|14.38|196.20|
|long|UnfairLock_XorShift1024StarPhi_nextLong|14.67|255.93|
|long|FairLock_XorShift1024StarPhi_nextLong|15.18|43,880.36|
|long|FairLock_XoRoShiRo128Plus_nextLong|15.19|42,316.21|
|long|Sync_XorShift1024StarPhi_nextLong|16.77|294.09|
|long|Sync_XoRoShiRo128Plus_nextLong|16.78|332.61|
|long|Random_nextLong|17.07|500.79|
|long|FairLock_Well44497b_nextLong|29.00|43,504.11|
|long|UnfairLock_Well44497b_nextLong|29.11|342.99|
|long|Sync_Well44497b_nextLong|29.31|442.95|
|long|SeedFactory_createLong|63.79|777.90|
|long|System_nanoTime|564.86|2,191.90|
|long|System_currentTimeMillis|564.91|2,191.36|
There is some inconsistency with the use of ThreadLocal<> on 4 threads.
Sometimes it is almost as fast as a single thread (see
ThreadLocalRNG_nextLong). At other times it is a lot slower but still among the
fastest methods. Just nowhere close to ThreadLocalRandom.
The use of a fair lock policy on multiple threads is very slow. On a single
thread it is close to the fair lock policy.
Here the use of the {{ReentrantLock}} is faster than using a synchronized block
around a single generator both on a single thread and on multiple threads.
Don't use System nanoTime or currentTimeMillis. They are slow and not random.
One item to note is that the use of an atomic long as the state for a split mix
algorithm is faster than using a ReentrantLock around a generator. So this
would be a candidate for a thread-safe fast seed generator for single int or
long values with minimal coding. It would have a period of only 2^64 but no
start-up cost. A bit more coding would create the better performing
ThreadLocal<> variants. These have a start-up cost for creation on a thread but
perform better when more than a single value is required on the thread.
The recommendation would be to use ThreadLocalRandom for fast local seeding
which effectively does the same thing (but requires Java 1.7).
This table can be updated if the SeedFactory is changed as per the
recommendations above. Currently it is slow as it combines synchronisation with
the System_identityHashCode method.
> SeedFactory seed creation performance analysis
> ----------------------------------------------
>
> Key: RNG-104
> URL: https://issues.apache.org/jira/browse/RNG-104
> Project: Commons RNG
> Issue Type: Task
> Components: simple
> Affects Versions: 1.3
> Reporter: Alex D Herbert
> Assignee: Alex D Herbert
> Priority: Minor
> Attachments: t1.jpg, t4.jpg, well_lock_vs_sync1.png,
> well_lock_vs_sync4.jpg, well_sync_performance.jpg,
> well_unfair_performance.jpg, well_unfair_vs_fair.jpg, xor_unfair_int1.png,
> xor_unfair_long1.png
>
>
> The SeedFactory is used to create seeds for the random generators. To ensure
> thread safety this uses synchronized blocks around a single generator. The
> current method only generates a single int or long per synchronisation.
> Analyze the performance of this approach. The analysis will investigate
> generating multiple values inside each synchronisation around the generator.
> This analysis will also investigate methods to supplement the SeedFactory
> with fast methods to create seeds. This will use a fast seeding method to
> generate a single long value. This can be a seed for a SplitMix generator
> used to create a seed of any length.
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
