[jira] [Commented] (MATH-579) FastMath.pow much slower than Math.pow
[
https://issues.apache.org/jira/browse/MATH-579?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13036004#comment-13036004
]
Arne Plöse commented on MATH-579:
-
{quote}This does not answer my question, which could be restated as: How can
100 ms matter when the JVM can take several seconds to start up?
I'm curious of what real applications (that use CM) would run for less than a
few seconds...{quote}
I could imagin of an GUI app where the users put some values (maybe a 3x3
matix) ant hit the calc button and wait. In a GUI 100 ms are a long time.
So the developer can load FastMath (if she really want to use FastMath) in a
separate thread at startup ...
Thist hwole issue is more about usabillity and expected behavior and not the
fact that it takes up to 100ms to initialize FastMath.
If I use a lib where I am not really satified with, I will try to replace it.
If I know there is a startup penalty, I know it, and I can put the startup time
in a place where it does not hurt - its fine.
> FastMath.pow much slower than Math.pow
> --
>
> Key: MATH-579
> URL: https://issues.apache.org/jira/browse/MATH-579
> Project: Commons Math
> Issue Type: Bug
>Affects Versions: 3.0
> Environment: java version "1.6.0_22"
> OpenJDK Runtime Environment (IcedTea6 1.10.1) (6b22-1.10.1-0ubuntu1)
> OpenJDK 64-Bit Server VM (build 20.0-b11, mixed mode)
> java version "1.6.0_24"
> Java(TM) SE Runtime Environment (build 1.6.0_24-b07)
> Java HotSpot(TM) 64-Bit Server VM (build 19.1-b02, mixed mode)
>Reporter: Arne Plöse
> Fix For: 3.0
>
>
> calculating FastMath.pow(10, 0.1 / 20) is approximately 65 times slower as
> the Math.pow() function.
> Ether this is a bug or a javadoc comment is missing.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (MATH-579) FastMath.pow much slower than Math.pow
[
https://issues.apache.org/jira/browse/MATH-579?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13035648#comment-13035648
]
Gilles commented on MATH-579:
-
{quote}
hosted application, in environments like [...] web servers, [...]
{quote}
>From what I've just been reading, servlets are only reloaded when their
>".class" file has changed. And they refer to this as a feature (to allow code
>to be modified without needing a server restart) but also as a hack (because
>the usual class loader of the JVM does not do that)...
I don't know how Eclipse or Android works but I don't see why a class would be
reloaded inside a given application. For Android, the recompilation argument
doesn't even apply.
> FastMath.pow much slower than Math.pow
> --
>
> Key: MATH-579
> URL: https://issues.apache.org/jira/browse/MATH-579
> Project: Commons Math
> Issue Type: Bug
>Affects Versions: 3.0
> Environment: java version "1.6.0_22"
> OpenJDK Runtime Environment (IcedTea6 1.10.1) (6b22-1.10.1-0ubuntu1)
> OpenJDK 64-Bit Server VM (build 20.0-b11, mixed mode)
> java version "1.6.0_24"
> Java(TM) SE Runtime Environment (build 1.6.0_24-b07)
> Java HotSpot(TM) 64-Bit Server VM (build 19.1-b02, mixed mode)
>Reporter: Arne Plöse
> Fix For: 3.0
>
>
> calculating FastMath.pow(10, 0.1 / 20) is approximately 65 times slower as
> the Math.pow() function.
> Ether this is a bug or a javadoc comment is missing.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (MATH-579) FastMath.pow much slower than Math.pow
[
https://issues.apache.org/jira/browse/MATH-579?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13035501#comment-13035501
]
Luc Maisonobe commented on MATH-579:
{quote}
This does not answer my question, which could be restated as: How can 100 ms
matter when the JVM can take several seconds to start up?
I'm curious of what real applications (that use CM) would run for less than a
few seconds...
{quote}
I think mainly about hosted application, in environments like Eclipse, web
servers, service oriented architectures, perhaps even Android devices. The JVM
is already started but I'm not sure the class are reused between requests, I
think a new fresh context is set up with a new classloader, which involves
reloading the class.
For sure, micro-benchmark should be avoided. Despite it is quite old, the paper
about flawed micro benchmark by Brian Goetz
[http://www.ibm.com/developerworks/java/library/j-jtp02225/index.html] is
really enlightening.
If we get further reports about this latency, we may look at a way to
pre-compute the tables at compile time rather than at runtime to see if we can
save some milliseconds.
> FastMath.pow much slower than Math.pow
> --
>
> Key: MATH-579
> URL: https://issues.apache.org/jira/browse/MATH-579
> Project: Commons Math
> Issue Type: Bug
>Affects Versions: 3.0
> Environment: java version "1.6.0_22"
> OpenJDK Runtime Environment (IcedTea6 1.10.1) (6b22-1.10.1-0ubuntu1)
> OpenJDK 64-Bit Server VM (build 20.0-b11, mixed mode)
> java version "1.6.0_24"
> Java(TM) SE Runtime Environment (build 1.6.0_24-b07)
> Java HotSpot(TM) 64-Bit Server VM (build 19.1-b02, mixed mode)
>Reporter: Arne Plöse
> Fix For: 3.0
>
>
> calculating FastMath.pow(10, 0.1 / 20) is approximately 65 times slower as
> the Math.pow() function.
> Ether this is a bug or a javadoc comment is missing.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (MATH-579) FastMath.pow much slower than Math.pow
[
https://issues.apache.org/jira/browse/MATH-579?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13035464#comment-13035464
]
Gilles commented on MATH-579:
-
{quote}
In answer to your question, Gilles, there are some applications where 100ms is
a big deal and if they just make one or two calls [...]
{quote}
This does not answer my question, which could be restated as: How can 100 ms
matter when the JVM can take several seconds to start up?
I'm curious of what real applications (that use CM) would run for less than a
few seconds...
{quote}
If we get a lot of feedback from users indicating that this latency is a
material practical problem for them, or prevents them using the library, we may
want to consider making the embedded use configurable.
{quote}
I surely hope that micro-benchmarks are not going to be taken into
consideration...
{quote}
I am thankful to Arne for having pointed it out [...]
{quote}
At the time "FastMath" was introduced, I had already pointed out the relative
slowness of some functions, to which it had been answered that the "fast" in
"FastMath" would kick in only when doing several millions calls (i.e. after the
JIT compiler would compile the methods to native code).
{quote}
I am thankful to [...] Luc for improving the documentation.
{quote}
+1
> FastMath.pow much slower than Math.pow
> --
>
> Key: MATH-579
> URL: https://issues.apache.org/jira/browse/MATH-579
> Project: Commons Math
> Issue Type: Bug
>Affects Versions: 3.0
> Environment: java version "1.6.0_22"
> OpenJDK Runtime Environment (IcedTea6 1.10.1) (6b22-1.10.1-0ubuntu1)
> OpenJDK 64-Bit Server VM (build 20.0-b11, mixed mode)
> java version "1.6.0_24"
> Java(TM) SE Runtime Environment (build 1.6.0_24-b07)
> Java HotSpot(TM) 64-Bit Server VM (build 19.1-b02, mixed mode)
>Reporter: Arne Plöse
> Fix For: 3.0
>
>
> calculating FastMath.pow(10, 0.1 / 20) is approximately 65 times slower as
> the Math.pow() function.
> Ether this is a bug or a javadoc comment is missing.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (MATH-579) FastMath.pow much slower than Math.pow
[ https://issues.apache.org/jira/browse/MATH-579?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13035426#comment-13035426 ] Phil Steitz commented on MATH-579: -- I think Luc did a great job providing the right information to users. In answer to your question, Gilles, there are some applications where 100ms is a big deal and if they just make one or two calls, the associated latency will be surprising and could cause problems for them. If we get a lot of feedback from users indicating that this latency is a material practical problem for them, or prevents them using the library, we may want to consider making the embedded use configurable. I can think of only a few cases in my experience where this might be an issue; but I am thankful to Arne for having pointed it out and Luc for improving the documentation. > FastMath.pow much slower than Math.pow > -- > > Key: MATH-579 > URL: https://issues.apache.org/jira/browse/MATH-579 > Project: Commons Math > Issue Type: Bug >Affects Versions: 3.0 > Environment: java version "1.6.0_22" > OpenJDK Runtime Environment (IcedTea6 1.10.1) (6b22-1.10.1-0ubuntu1) > OpenJDK 64-Bit Server VM (build 20.0-b11, mixed mode) > java version "1.6.0_24" > Java(TM) SE Runtime Environment (build 1.6.0_24-b07) > Java HotSpot(TM) 64-Bit Server VM (build 19.1-b02, mixed mode) >Reporter: Arne Plöse > Fix For: 3.0 > > > calculating FastMath.pow(10, 0.1 / 20) is approximately 65 times slower as > the Math.pow() function. > Ether this is a bug or a javadoc comment is missing. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (MATH-579) FastMath.pow much slower than Math.pow
[
https://issues.apache.org/jira/browse/MATH-579?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13035259#comment-13035259
]
Gilles commented on MATH-579:
-
In the end, it is the _absolute_ running time that counts. If you call "pow"
_once_ in an application, why would it matter that it takes 100 ms or 1 ms?
Could it be that the "Math" class is already loaded (as part of the JVM
initialization), so that "FastMath" is at a disadvantage in your benchmark
(because it still needs to be loaded at the first call to "pow")?
I maintain that such a disclaimer ("large scale usage") provides more confusion
that it clears: What is large-scale? People who are worried will profile their
(complete) application and can decide which implementation (of any interface)
to use, based on realistic timings, not on a micro-benchmark (which can provide
contradictory results).
What we could do is add a link to the performance test class.
> FastMath.pow much slower than Math.pow
> --
>
> Key: MATH-579
> URL: https://issues.apache.org/jira/browse/MATH-579
> Project: Commons Math
> Issue Type: Bug
>Affects Versions: 3.0
> Environment: java version "1.6.0_22"
> OpenJDK Runtime Environment (IcedTea6 1.10.1) (6b22-1.10.1-0ubuntu1)
> OpenJDK 64-Bit Server VM (build 20.0-b11, mixed mode)
> java version "1.6.0_24"
> Java(TM) SE Runtime Environment (build 1.6.0_24-b07)
> Java HotSpot(TM) 64-Bit Server VM (build 19.1-b02, mixed mode)
>Reporter: Arne Plöse
> Fix For: 3.0
>
>
> calculating FastMath.pow(10, 0.1 / 20) is approximately 65 times slower as
> the Math.pow() function.
> Ether this is a bug or a javadoc comment is missing.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (MATH-579) FastMath.pow much slower than Math.pow
[ https://issues.apache.org/jira/browse/MATH-579?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13035213#comment-13035213 ] Arne Plöse commented on MATH-579: - How it I stumbled over it: I did debug my app, and came across the call to FastMath.pow() (first call) it took some time (100 ms) to complete the call. Then I searched the javadoc for pow - nothing the same for class FastMath - nothing. So I decided must be a bug. As you wrote FastMath is no general replacement of Math as the name Fast* would suggest, but it is intended for large scale operation. If you want prevent confusion by end users (developers), a hint would be fine. > FastMath.pow much slower than Math.pow > -- > > Key: MATH-579 > URL: https://issues.apache.org/jira/browse/MATH-579 > Project: Commons Math > Issue Type: Bug >Affects Versions: 3.0 > Environment: java version "1.6.0_22" > OpenJDK Runtime Environment (IcedTea6 1.10.1) (6b22-1.10.1-0ubuntu1) > OpenJDK 64-Bit Server VM (build 20.0-b11, mixed mode) > java version "1.6.0_24" > Java(TM) SE Runtime Environment (build 1.6.0_24-b07) > Java HotSpot(TM) 64-Bit Server VM (build 19.1-b02, mixed mode) >Reporter: Arne Plöse > > calculating FastMath.pow(10, 0.1 / 20) is approximately 65 times slower as > the Math.pow() function. > Ether this is a bug or a javadoc comment is missing. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (MATH-579) FastMath.pow much slower than Math.pow
[ https://issues.apache.org/jira/browse/MATH-579?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13035103#comment-13035103 ] Gilles commented on MATH-579: - I don't think that a remark like "targets large scale computation" adds any more information here (i.e. for "FastMath") than it would on any other class (slow initialization and JIT compiler behaviour is the same). Also, I guess that if one fires up a Java application that only does a few math functions calls, there wouldn't be any noticeable time differences; they will be dwarfed by the JVM startup time. OK for "won't fix". > FastMath.pow much slower than Math.pow > -- > > Key: MATH-579 > URL: https://issues.apache.org/jira/browse/MATH-579 > Project: Commons Math > Issue Type: Bug >Affects Versions: 3.0 > Environment: java version "1.6.0_22" > OpenJDK Runtime Environment (IcedTea6 1.10.1) (6b22-1.10.1-0ubuntu1) > OpenJDK 64-Bit Server VM (build 20.0-b11, mixed mode) > java version "1.6.0_24" > Java(TM) SE Runtime Environment (build 1.6.0_24-b07) > Java HotSpot(TM) 64-Bit Server VM (build 19.1-b02, mixed mode) >Reporter: Arne Plöse > > calculating FastMath.pow(10, 0.1 / 20) is approximately 65 times slower as > the Math.pow() function. > Ether this is a bug or a javadoc comment is missing. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (MATH-579) FastMath.pow much slower than Math.pow
[ https://issues.apache.org/jira/browse/MATH-579?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13035029#comment-13035029 ] Arne Plöse commented on MATH-579: - If you add a hint in the javadocs of class FastMath -> usage for large scale (and initilaization time up to 100 ms) this issue is FIXED So having small numbers of computation, stick with Math.* , except you need asinh, ... ;-) > FastMath.pow much slower than Math.pow > -- > > Key: MATH-579 > URL: https://issues.apache.org/jira/browse/MATH-579 > Project: Commons Math > Issue Type: Bug >Affects Versions: 3.0 > Environment: java version "1.6.0_22" > OpenJDK Runtime Environment (IcedTea6 1.10.1) (6b22-1.10.1-0ubuntu1) > OpenJDK 64-Bit Server VM (build 20.0-b11, mixed mode) > java version "1.6.0_24" > Java(TM) SE Runtime Environment (build 1.6.0_24-b07) > Java HotSpot(TM) 64-Bit Server VM (build 19.1-b02, mixed mode) >Reporter: Arne Plöse > > calculating FastMath.pow(10, 0.1 / 20) is approximately 65 times slower as > the Math.pow() function. > Ether this is a bug or a javadoc comment is missing. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (MATH-579) FastMath.pow much slower than Math.pow
[ https://issues.apache.org/jira/browse/MATH-579?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13035012#comment-13035012 ] Sebb commented on MATH-579: --- AIUI FastMath is also targetted at faster calculation over the full range of the operands. The performance test does not (currently) use suitable ranges for all the functions. > FastMath.pow much slower than Math.pow > -- > > Key: MATH-579 > URL: https://issues.apache.org/jira/browse/MATH-579 > Project: Commons Math > Issue Type: Bug >Affects Versions: 3.0 > Environment: java version "1.6.0_22" > OpenJDK Runtime Environment (IcedTea6 1.10.1) (6b22-1.10.1-0ubuntu1) > OpenJDK 64-Bit Server VM (build 20.0-b11, mixed mode) > java version "1.6.0_24" > Java(TM) SE Runtime Environment (build 1.6.0_24-b07) > Java HotSpot(TM) 64-Bit Server VM (build 19.1-b02, mixed mode) >Reporter: Arne Plöse > > calculating FastMath.pow(10, 0.1 / 20) is approximately 65 times slower as > the Math.pow() function. > Ether this is a bug or a javadoc comment is missing. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (MATH-579) FastMath.pow much slower than Math.pow
[ https://issues.apache.org/jira/browse/MATH-579?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13034996#comment-13034996 ] Luc Maisonobe commented on MATH-579: This is normal and is probably the same for all FastMath methods (I just checked for sin, abs and sqrt, knowing that FastMath.sqrt simply calls Math.sqrt). The initialization occurs at class loading as many tables are computed, so this overhead occurs only one per program run and does not change with the number of calls. The number of calls is also important as the native code optimizing compilers kicks of only after the same part of code has been used many times. FastMath relies heavily on this and attempts to be fast for large scale computation. The side effect you see is that it is much slower for very short programs like the benchmark above. Also note that 10 runs is far too low with regard to both the resolution of currentTimeMillis (one can use System.nanoTime() instead) and for results significance. So I would like to close this as WONTFIX. Perhaps we should add in the javadoc that FastMath targets large scale computation. > FastMath.pow much slower than Math.pow > -- > > Key: MATH-579 > URL: https://issues.apache.org/jira/browse/MATH-579 > Project: Commons Math > Issue Type: Bug >Affects Versions: 3.0 > Environment: java version "1.6.0_22" > OpenJDK Runtime Environment (IcedTea6 1.10.1) (6b22-1.10.1-0ubuntu1) > OpenJDK 64-Bit Server VM (build 20.0-b11, mixed mode) > java version "1.6.0_24" > Java(TM) SE Runtime Environment (build 1.6.0_24-b07) > Java HotSpot(TM) 64-Bit Server VM (build 19.1-b02, mixed mode) >Reporter: Arne Plöse > > calculating FastMath.pow(10, 0.1 / 20) is approximately 65 times slower as > the Math.pow() function. > Ether this is a bug or a javadoc comment is missing. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (MATH-579) FastMath.pow much slower than Math.pow
[
https://issues.apache.org/jira/browse/MATH-579?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13034952#comment-13034952
]
Arne Plöse commented on MATH-579:
-
This happens only on the first! run.
So take a separate project and run this test case:
@Test
public void testPowDuration() {
int n = 10;
long t1 = System.currentTimeMillis();
for (int i = 0; i < n; i++) {
double x1 = FastMath.pow(10, 0.1 / 20);
}
long t2 = System.currentTimeMillis();
for (int i = 0; i < n; i++) {
double x1 = Math.pow(10, 0.1 / 20);
}
long t3 = System.currentTimeMillis();
double d1 = t2 - t1;
double d2 = t3 - t2;
if (d2 == 0) {
d2 = 1;
}
if (d1 / d2 > 2.0)
throw new RuntimeException("pow(10, 0.1 / 20) ratio" + (d1 / d2));
}
Looks like some initialization takes quite long ...
> FastMath.pow much slower than Math.pow
> --
>
> Key: MATH-579
> URL: https://issues.apache.org/jira/browse/MATH-579
> Project: Commons Math
> Issue Type: Bug
>Affects Versions: 3.0
> Environment: java version "1.6.0_22"
> OpenJDK Runtime Environment (IcedTea6 1.10.1) (6b22-1.10.1-0ubuntu1)
> OpenJDK 64-Bit Server VM (build 20.0-b11, mixed mode)
> java version "1.6.0_24"
> Java(TM) SE Runtime Environment (build 1.6.0_24-b07)
> Java HotSpot(TM) 64-Bit Server VM (build 19.1-b02, mixed mode)
>Reporter: Arne Plöse
>
> calculating FastMath.pow(10, 0.1 / 20) is approximately 65 times slower as
> the Math.pow() function.
> Ether this is a bug or a javadoc comment is missing.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (MATH-579) FastMath.pow much slower than Math.pow
[ https://issues.apache.org/jira/browse/MATH-579?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13034948#comment-13034948 ] Luc Maisonobe commented on MATH-579: This is strange. Could you run the FastMathTestPerformance junit test (in the utils package). On my personal computer (which is also a 64 bits machine running Ubuntu), FastMath.pow is about 28% faster than either StrictMath.pow or Math.pow on Java 5 and 26% faster on Java 6. > FastMath.pow much slower than Math.pow > -- > > Key: MATH-579 > URL: https://issues.apache.org/jira/browse/MATH-579 > Project: Commons Math > Issue Type: Bug >Affects Versions: 3.0 > Environment: java version "1.6.0_22" > OpenJDK Runtime Environment (IcedTea6 1.10.1) (6b22-1.10.1-0ubuntu1) > OpenJDK 64-Bit Server VM (build 20.0-b11, mixed mode) > java version "1.6.0_24" > Java(TM) SE Runtime Environment (build 1.6.0_24-b07) > Java HotSpot(TM) 64-Bit Server VM (build 19.1-b02, mixed mode) >Reporter: Arne Plöse > > calculating FastMath.pow(10, 0.1 / 20) is approximately 65 times slower as > the Math.pow() function. > Ether this is a bug or a javadoc comment is missing. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
