Re: [MATH] Build Failure
Hello. Le mer. 22 déc. 2021 à 15:05, Avijit Basak a écrit : > > Hi All > > I am facing a build issue for PR #199 in commons-math library. Next time, please provide a direct link to the build log. Thanks. The last Travis build is here: https://app.travis-ci.com/github/apache/commons-math/builds/240925186 AFAICT, the complaints are (starting at line 8044): ---CUT--- [WARNING] Rule violated for bundle commons-math4-core ---CUT--- However, there is no "commons-math4-core" in the "master" branch: https://github.com/apache/commons-math/ Regards, Gilles > The > report summary is given below. Can anyone kindly look into the issue and do > the needful. > > [ [1;34mINFO [m] Apache Commons Math > [1;32mSUCCESS [m [ 8.501 s]*[ [1;34mINFO [m] Miscellaneous core > classes . [1;31mFAILURE [m [ 24.551 s]* > [ [1;34mINFO [m] Artificial neural networks . > [1;33mSKIPPED [m > [ [1;34mINFO [m] Transforms . > [1;33mSKIPPED [m > [ [1;34mINFO [m] Exception classes (Legacy) . > [1;33mSKIPPED [m > [ [1;34mINFO [m] Miscellaneous core classes (Legacy) > [1;33mSKIPPED [m > [ [1;34mINFO [m] Apache Commons Math (Legacy) ... > [1;33mSKIPPED [m > [ [1;34mINFO [m] Example applications ... > [1;33mSKIPPED [m > [ [1;34mINFO [m] SOFM ... > [1;33mSKIPPED [m > [ [1;34mINFO [m] Chinese Rings .. > [1;33mSKIPPED [m > [ [1;34mINFO [m] Traveling Salesman Problem . > [1;33mSKIPPED [m > [ [1;34mINFO [m] genetic algorithm .. > [1;33mSKIPPED [m > [ [1;34mINFO [m] examples-genetic-algorithm . > [1;33mSKIPPED [m > [ [1;34mINFO [m] examples-ga-math-functions . > [1;33mSKIPPED [m > [ [1;34mINFO [m] examples-ga-tsp > [1;33mSKIPPED [m > > > Thanks & Regards > -- Avijit Basak - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [MATH][GENETICS][PR-199] Decision on use and customization of RNG functionality for randomization
Hello.
Le mer. 22 déc. 2021 à 14:25, Avijit Basak a écrit :
>
> Hi All
>
> Please see my comments below.
>
> >> >Several problems with this approach (raised in previous messages IIRC):
> >> >1. Potential performance loss in sharing the same RNG instance.
> >> -- As per my understanding ThreadLocalRandomSource creates separate
> >> instances of UniformRandomProvider for each thread. So I am not sure how
> a
> >> UniformRandomProvider instance is being shared. Please correct me if I am
> >> wrong.
>
> >Within a given thread there will be *one* RNG instance; that's what I meant
> >by "shared".
> >Of course you are right that that instance is not shared by multiple
> threads
> >(which would be a bug).
> >The performance loss is because it will be necessary to call
> > ThreadLocalRandomSource.current(RandomSource source)
> >for each access to the RNG (since it would be a bug to store the returned
> >value in e.g. an operator instance that would be shared among threads (as
> >you suggest below).
>
> -- I tried to do a small test on it and here are the results. Output times
> are in milliseconds. According to my understanding the performance loss is
> mostly during creation of per thread instance of UniformRandomProvider.
> --*CUT*--
> @Test
> void test() {
> int limit = 1;
> long start = System.currentTimeMillis();
> for (int i = 0; i < limit; i++) {
> ThreadLocalRandomSource.current(RandomSource.JDK);
> }
> System.out.println(System.currentTimeMillis() - start);
>
> limit = 1000;
> start = System.currentTimeMillis();
> for (int i = 0; i < limit; i++) {
> ThreadLocalRandomSource.current(RandomSource.JDK);
> }
> System.out.println(System.currentTimeMillis() - start);
>
> limit = 1;
> start = System.currentTimeMillis();
> for (int i = 0; i < limit; i++) {
> ThreadLocalRandomSource.current(RandomSource.JDK);
> }
> System.out.println(System.currentTimeMillis() - start);
>
> limit = 10;
> start = System.currentTimeMillis();
> for (int i = 0; i < limit; i++) {
> ThreadLocalRandomSource.current(RandomSource.JDK);
> }
> System.out.println(System.currentTimeMillis() - start);
>
> limit = 100;
> start = System.currentTimeMillis();
> for (int i = 0; i < limit; i++) {
> ThreadLocalRandomSource.current(RandomSource.JDK);
> }
> System.out.println(System.currentTimeMillis() - start);
>
> limit = 1000;
> start = System.currentTimeMillis();
> for (int i = 0; i < limit; i++) {
> ThreadLocalRandomSource.current(RandomSource.JDK);
> }
> System.out.println(System.currentTimeMillis() - start);
>
> limit = 1;
> start = System.currentTimeMillis();
> for (int i = 0; i < limit; i++) {
> ThreadLocalRandomSource.current(RandomSource.JDK);
> }
> System.out.println(System.currentTimeMillis() - start);
>
> limit = 10;
> start = System.currentTimeMillis();
> for (int i = 0; i < limit; i++) {
> ThreadLocalRandomSource.current(RandomSource.JDK);
> }
> System.out.println(System.currentTimeMillis() - start);
> }
> --*CUT*--
> --*output*--
> 363
> 1
> 2
> 4
> 6
> 28
> 244
> 2423
> --*output*--
As I've already indicated, "ThreadLocalRandomSource" is, IMHO, a
sort of workaround for a multi-thread application that does not want
to bother managing per-thread RNG instance(s).
The library should not make that decision for the application since we
can care for both usages: Every piece of the GA that needs a RNG can
provide factory methods that either take a "RandomSource" argument
or create a default one.
Note that your above custom benchmark is likely to mean nothing
(please see e.g. "Commons RNG" on how to create JMH based
benchmarks).
>
> >> >2. Less/no flexibility (no user's choice of random source).
> >> -- Agreed.
> -- Do we really need this much flexibility here?
My main concern is that IMO the RNG is a prominent part of a GA
and it is not a good design to use "ThreadLocalRandomSource".
> >> >3. Error-prone (user can access/reuse the "UniformRandomProvider"
> >> instances).
> >>
> >> >Again: "ThreadLocalRandomSource" is an ad-hoc workaround for correct but
> >> >"light" usage of random number generation in a multi-threaded
> application;
> >> GAs
> >> >make "heavy" use of RNG, thus it is does not seem outlandish that all
> the
> >> RNG
> >> >"clients" (e.g. every "operator") creates their own instances.
> >
> >
> >> >IMHO, a more important discussion would be about the expectations in a
> >> >multithreaded context: E.g. should an operator be shareable by different
> >> >threads? And if not, how does the API help application developers to
> avoid
> >> >such pitfalls?
> >> -- Once w
[MATH] Build Failure
Hi All I am facing a build issue for PR #199 in commons-math library. The report summary is given below. Can anyone kindly look into the issue and do the needful. [ [1;34mINFO [m] Apache Commons Math [1;32mSUCCESS [m [ 8.501 s]*[ [1;34mINFO [m] Miscellaneous core classes . [1;31mFAILURE [m [ 24.551 s]* [ [1;34mINFO [m] Artificial neural networks . [1;33mSKIPPED [m [ [1;34mINFO [m] Transforms . [1;33mSKIPPED [m [ [1;34mINFO [m] Exception classes (Legacy) . [1;33mSKIPPED [m [ [1;34mINFO [m] Miscellaneous core classes (Legacy) [1;33mSKIPPED [m [ [1;34mINFO [m] Apache Commons Math (Legacy) ... [1;33mSKIPPED [m [ [1;34mINFO [m] Example applications ... [1;33mSKIPPED [m [ [1;34mINFO [m] SOFM ... [1;33mSKIPPED [m [ [1;34mINFO [m] Chinese Rings .. [1;33mSKIPPED [m [ [1;34mINFO [m] Traveling Salesman Problem . [1;33mSKIPPED [m [ [1;34mINFO [m] genetic algorithm .. [1;33mSKIPPED [m [ [1;34mINFO [m] examples-genetic-algorithm . [1;33mSKIPPED [m [ [1;34mINFO [m] examples-ga-math-functions . [1;33mSKIPPED [m [ [1;34mINFO [m] examples-ga-tsp [1;33mSKIPPED [m Thanks & Regards -- Avijit Basak
Re: [MATH][GENETICS][PR-199] Decision on use and customization of RNG functionality for randomization
Hi All
Please see my *changed* comments below.
>> > Mine is against using "ThreadLocalRandomSource"...
>> -- What is the wayout other than that. Please suggest.
>I think I did.
>>*--* The factory based approach would be useful only when we can have
separate copies of operators for each set of operations.
*--* *T*he factory based approach can introduce *custom* RNG, but it can
improve performance only when we can have separate copies of operators for
each set of operations which might lead to *memory issues* as explained in
previous mail.
Thanks & Regards
--Avijit Basak
On Wed, 22 Dec 2021 at 18:54, Avijit Basak wrote:
> Hi All
>
> Please see my comments below.
>
> >> >Several problems with this approach (raised in previous messages IIRC):
> >> >1. Potential performance loss in sharing the same RNG instance.
> >> -- As per my understanding ThreadLocalRandomSource creates separate
> >> instances of UniformRandomProvider for each thread. So I am not sure
> how a
> >> UniformRandomProvider instance is being shared. Please correct me if I
> am
> >> wrong.
>
> >Within a given thread there will be *one* RNG instance; that's what I
> meant
> >by "shared".
> >Of course you are right that that instance is not shared by multiple
> threads
> >(which would be a bug).
> >The performance loss is because it will be necessary to call
> > ThreadLocalRandomSource.current(RandomSource source)
> >for each access to the RNG (since it would be a bug to store the returned
> >value in e.g. an operator instance that would be shared among threads (as
> >you suggest below).
>
> -- I tried to do a small test on it and here are the results. Output times
> are in milliseconds. According to my understanding the performance loss is
> mostly during creation of per thread instance of UniformRandomProvider.
> --*CUT*--
> @Test
> void test() {
> int limit = 1;
> long start = System.currentTimeMillis();
> for (int i = 0; i < limit; i++) {
> ThreadLocalRandomSource.current(RandomSource.JDK);
> }
> System.out.println(System.currentTimeMillis() - start);
>
> limit = 1000;
> start = System.currentTimeMillis();
> for (int i = 0; i < limit; i++) {
> ThreadLocalRandomSource.current(RandomSource.JDK);
> }
> System.out.println(System.currentTimeMillis() - start);
>
> limit = 1;
> start = System.currentTimeMillis();
> for (int i = 0; i < limit; i++) {
> ThreadLocalRandomSource.current(RandomSource.JDK);
> }
> System.out.println(System.currentTimeMillis() - start);
>
> limit = 10;
> start = System.currentTimeMillis();
> for (int i = 0; i < limit; i++) {
> ThreadLocalRandomSource.current(RandomSource.JDK);
> }
> System.out.println(System.currentTimeMillis() - start);
>
> limit = 100;
> start = System.currentTimeMillis();
> for (int i = 0; i < limit; i++) {
> ThreadLocalRandomSource.current(RandomSource.JDK);
> }
> System.out.println(System.currentTimeMillis() - start);
>
> limit = 1000;
> start = System.currentTimeMillis();
> for (int i = 0; i < limit; i++) {
> ThreadLocalRandomSource.current(RandomSource.JDK);
> }
> System.out.println(System.currentTimeMillis() - start);
>
> limit = 1;
> start = System.currentTimeMillis();
> for (int i = 0; i < limit; i++) {
> ThreadLocalRandomSource.current(RandomSource.JDK);
> }
> System.out.println(System.currentTimeMillis() - start);
>
> limit = 10;
> start = System.currentTimeMillis();
> for (int i = 0; i < limit; i++) {
> ThreadLocalRandomSource.current(RandomSource.JDK);
> }
> System.out.println(System.currentTimeMillis() - start);
> }
> --*CUT*--
> --*output*--
> 363
> 1
> 2
> 4
> 6
> 28
> 244
> 2423
> --*output*--
>
> >> >2. Less/no flexibility (no user's choice of random source).
> >> -- Agreed.
> -- Do we really need this much flexibility here?
> >> >3. Error-prone (user can access/reuse the "UniformRandomProvider"
> >> instances).
> >>
> >> >Again: "ThreadLocalRandomSource" is an ad-hoc workaround for correct
> but
> >> >"light" usage of random number generation in a multi-threaded
> application;
> >> GAs
> >> >make "heavy" use of RNG, thus it is does not seem outlandish that all
> the
> >> RNG
> >> >"clients" (e.g. every "operator") creates their own instances.
> >
> >
> >> >IMHO, a more important discussion would be about the expectations in a
> >> >multithreaded context: E.g. should an operator be shareable by
> different
> >> >threads? And if not, how does the API help application developers to
> avoid
> >> >such pitfalls?
> >> -- Once we implement multi-threading in GA, same crossover and mutation
> >> operators will be re-use
Re: [MATH][GENETICS][PR-199] Decision on use and customization of RNG functionality for randomization
Hi All
Please see my comments below.
>> >Several problems with this approach (raised in previous messages IIRC):
>> >1. Potential performance loss in sharing the same RNG instance.
>> -- As per my understanding ThreadLocalRandomSource creates separate
>> instances of UniformRandomProvider for each thread. So I am not sure how
a
>> UniformRandomProvider instance is being shared. Please correct me if I am
>> wrong.
>Within a given thread there will be *one* RNG instance; that's what I meant
>by "shared".
>Of course you are right that that instance is not shared by multiple
threads
>(which would be a bug).
>The performance loss is because it will be necessary to call
> ThreadLocalRandomSource.current(RandomSource source)
>for each access to the RNG (since it would be a bug to store the returned
>value in e.g. an operator instance that would be shared among threads (as
>you suggest below).
-- I tried to do a small test on it and here are the results. Output times
are in milliseconds. According to my understanding the performance loss is
mostly during creation of per thread instance of UniformRandomProvider.
--*CUT*--
@Test
void test() {
int limit = 1;
long start = System.currentTimeMillis();
for (int i = 0; i < limit; i++) {
ThreadLocalRandomSource.current(RandomSource.JDK);
}
System.out.println(System.currentTimeMillis() - start);
limit = 1000;
start = System.currentTimeMillis();
for (int i = 0; i < limit; i++) {
ThreadLocalRandomSource.current(RandomSource.JDK);
}
System.out.println(System.currentTimeMillis() - start);
limit = 1;
start = System.currentTimeMillis();
for (int i = 0; i < limit; i++) {
ThreadLocalRandomSource.current(RandomSource.JDK);
}
System.out.println(System.currentTimeMillis() - start);
limit = 10;
start = System.currentTimeMillis();
for (int i = 0; i < limit; i++) {
ThreadLocalRandomSource.current(RandomSource.JDK);
}
System.out.println(System.currentTimeMillis() - start);
limit = 100;
start = System.currentTimeMillis();
for (int i = 0; i < limit; i++) {
ThreadLocalRandomSource.current(RandomSource.JDK);
}
System.out.println(System.currentTimeMillis() - start);
limit = 1000;
start = System.currentTimeMillis();
for (int i = 0; i < limit; i++) {
ThreadLocalRandomSource.current(RandomSource.JDK);
}
System.out.println(System.currentTimeMillis() - start);
limit = 1;
start = System.currentTimeMillis();
for (int i = 0; i < limit; i++) {
ThreadLocalRandomSource.current(RandomSource.JDK);
}
System.out.println(System.currentTimeMillis() - start);
limit = 10;
start = System.currentTimeMillis();
for (int i = 0; i < limit; i++) {
ThreadLocalRandomSource.current(RandomSource.JDK);
}
System.out.println(System.currentTimeMillis() - start);
}
--*CUT*--
--*output*--
363
1
2
4
6
28
244
2423
--*output*--
>> >2. Less/no flexibility (no user's choice of random source).
>> -- Agreed.
-- Do we really need this much flexibility here?
>> >3. Error-prone (user can access/reuse the "UniformRandomProvider"
>> instances).
>>
>> >Again: "ThreadLocalRandomSource" is an ad-hoc workaround for correct but
>> >"light" usage of random number generation in a multi-threaded
application;
>> GAs
>> >make "heavy" use of RNG, thus it is does not seem outlandish that all
the
>> RNG
>> >"clients" (e.g. every "operator") creates their own instances.
>
>
>> >IMHO, a more important discussion would be about the expectations in a
>> >multithreaded context: E.g. should an operator be shareable by different
>> >threads? And if not, how does the API help application developers to
avoid
>> >such pitfalls?
>> -- Once we implement multi-threading in GA, same crossover and mutation
>> operators will be re-used across multiple threads.
>I would be wary to go on that path; better consider making (deep) copies.
>We can have multiple instances of an operator, all being configured in the
>same way but being different instances with no risk of a multithreading
bug.
-- I don't think this would be a good design choice just to support
customization of RNG functionality. This will lead to too many instances of
the same operators resulting in lots of unnecessary memory consumption. I
think we might face memory issues for higher dimensional problems. As
population size requirement also increases with increase of dimension this
might lead to a major issue and need a thought.
So I think we have a design tradeoff here performance vs memory
consumption. I am more worried about memory as that might restrict use of
this library beyond a certain number of dimensions in some areas. Ho
