commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gilles <>
Subject Re: [math] Thread-safety and initialization overhead in distribution sample() methods
Date Wed, 08 Oct 2014 12:38:34 GMT

Sorry: I had not seen your post before adding yet another
unnecessary layer of comment to the JIRA issue for MATH-1154.

On Tue, 07 Oct 2014 17:38:34 -0700, Phil Steitz wrote:
> Comments in MATH-1154 (bad performance in test code) and the
> now-reopened MATH-1124 (slow initialization) point to the need to
> fix the problem we created when we moved sample() to the
> distribution classes with PRNG provided by a final field with
> default implementation initialized by the constructor.  Several
> suggestions have been made to improve things.
> 0) require that sample() take a RandomGenerator as an additional
> parameter

Looks fine.
But not for 3.x release.
Caveat: Not thread-safe.

> 1) improve initialization performance of the default RandomGenerator
> 2) Replace the default with a generator with negligible
> initialization latency

Both are worth doing, but do not address the issue, as there
could always be use-cases where the initialization time, however
small, will be too much, simply because it is not necessary.
[This kind of argument was used for FastMath.]

As long as initialization takes longer than whatever functionality
is requested, this does won't fix issues similar to MATH-1154.

> 3) Make either PRNG initialization or initialization [lazy]

We are talking of a low-level object; when a user intantiates
a RNG, it is not usually expected that he has called a "dummy"
constructor, and that actual work will be performed at some
unspecified later time.

> of the
> RandomGenerator field lazy

I'd much prefer to leave the choice to the user, through his own
selection of a "enhanced" RNG that _explicitly_ provides lazy
intialization (cf. Otmar's proposal). See also below.

> I may have missed some.

Yes: Otmar's proposal (part of the patch on MAH-1154 page).

> One thing to note is that the (default)
> Well generators are *not* threadsafe, so having things final,
> avoiding lazy init is not really buying us anything in the current
> setup.

Thanks for bringing that up again.

>  So unless 2) is done with a threadsafe generator, only 0)
> really makes sample() threadsafe (assuming the caller protects the
> instance that needs to be re-supplied on each call).

Sort of...
It would be nice to make the RNG implementation thread-safe.
Or to know that some (all?) of them cannot be thread-safe, in
That would narrow the set of possibilities for a design that
depends on the answer.

> I am +0 for adding a new method that takes a generator as an
> additional actual parameter, but as a user I like the convenience of
> just calling sample().  I never use distributions as singletons, so
> the lack of threadsafety does not concern me.

Thread-safety is not only about singletons.

Assuming that the RNG is thread-safe, the _same_ object can be used
throughout an application's life-time, paying the initialization cost
only once. [Which would in turn render the initialization bearable in
many cases.]

> It seems then that a
> reasonable approach might be to add the new method, keep the old one
> but move to lazy initialization with documentation that when you use
> the default, the provided PRNG it is not threadsafe.

With Otmar's feature, we get
  * lazy initialization (if needed)
  * backward compatibility
  * no API change

Why should it be one or the other?


>  I would also
> obviously be in favor or anything we can do in 1).
> Phil

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message