On Wed, 9 Nov 2022 20:15:57 GMT, Xubo Zhang wrote:
> NativePRNG SecureRandom doesn’t scale with number of threads. The performance
> starts dropping as we increase the number of threads. Even going from 1
> thread to 2 threads shows significant drop. The bottleneck is the singleton
&
On Mon, 14 Nov 2022 16:37:41 GMT, Xubo Zhang wrote:
>> NativePRNG SecureRandom doesn’t scale with number of threads. The
>> performance starts dropping as we increase the number of threads. Even going
>> from 1 thread to 2 threads shows significant drop. The bottleneck is
On Mon, 14 Nov 2022 16:37:41 GMT, Xubo Zhang wrote:
>> NativePRNG SecureRandom doesn’t scale with number of threads. The
>> performance starts dropping as we increase the number of threads. Even going
>> from 1 thread to 2 threads shows significant drop. The bottleneck is
On Wed, 16 Nov 2022 21:12:09 GMT, Bernd wrote:
> Would it be easier to remove the state (singleton, thread local) caching
> completely? If somebody request a new instance just seed and return it. That
> might in some situations be even less seeding than once per thread and it
> decreases stat
On Wed, 16 Nov 2022 20:59:24 GMT, Volodymyr Paprotski wrote:
> Any ideas why it is not scaling linearly with number of threads? One would
> think that random numbers are the 'definition' of data-independent and should
> scale linearly with number of CPUs
it could be that the singleton RandomIO
On Mon, 14 Nov 2022 16:37:41 GMT, Xubo Zhang wrote:
>> NativePRNG SecureRandom doesn’t scale with number of threads. The
>> performance starts dropping as we increase the number of threads. Even going
>> from 1 thread to 2 threads shows significant drop. The bottleneck is
t.xml">
>
>
>
>
>
>
>
>
>
> #threads | singleton RandomIO | ThreadLocal RandomIO
> -- | -- | --
> 1 | 1269133 | 1279088
> 2 | 862923 | 1362066
> 3 | 819734 | 1630522
> 4 | 809128 | 1614500
> 5 | 821514 | 1594965
> 6 | 808795 | 15
NativePRNG SecureRandom doesn’t scale with number of threads. The performance
starts dropping as we increase the number of threads. Even going from 1 thread
to 2 threads shows significant drop. The bottleneck is the singleton RandomIO
instance. Making the RandomIO ThreadLocal helps in removing t
