You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@commons.apache.org by "Luc Maisonobe (Issue Comment Edited) (JIRA)" <ji...@apache.org> on 2012/02/11 13:45:59 UTC
[jira] [Issue Comment Edited] (MATH-650) FastMath has static code
which slows the first access to FastMath
[ https://issues.apache.org/jira/browse/MATH-650?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13206095#comment-13206095 ]
Luc Maisonobe edited comment on MATH-650 at 2/11/12 12:44 PM:
--------------------------------------------------------------
I would like to resolve this issue.
I think everybody agreed pre-computation was an improvement, and the remaining discussions are about the way the pre-computed tables are loaded. We have two competing implementations for that: resources loaded from a binary file and literal arrays compiled in the library. In both cases, the data is generated beforehand by our own code, so in both case users who wants to re-generate them with different settings can do so.
The advantages of resources are that they are more compact (binary) and don't clutter the sources with large tables.
The advantages of literal arrays are that the can be checked by mere human beings and don't require any support code.
The speed difference between the two implementation exists but is tiny.
Two people have already expressed their preferences (one favoring resources the other one favoring literal arrays). I don't have a clear cut preference myself (only a slight bias toward one solution which I prefer to keep for myself).
I would like to have the opinions of newer developers and users on this before selecting one approach. Could someone please provide another opinion ?
was (Author: luc):
I would like to resolve this issue.
I think everybody agreed pre-computation was an improvement, and the remaining discussions are about the way the pre-computed tables are loaded. We have two competing implementations for that: resources loaded from a binary file and literal arrays compiled in the library. In both cases, the data is generated beforehand by our own code, so in both case users who wants to re-generate with different settings them can do so.
The advantages of resources are that they are more compact (binary) and don't clutter the sources with large tables.
The advantages of literal arrays are that the can be checked by mere human beings and don't require any support code.
The speed difference between the two implementation exists but is tiny.
Two people have already expressed their preferences (one favoring resources the other one favoring literal arrays). I don't have a clear cut preference myself (only a slight bias toward one solution which I prefer to keep for myself).
I would like to have the opinions of newer developers and users on this before selecting one approach. Could someone please provide another opinion ?
> FastMath has static code which slows the first access to FastMath
> -----------------------------------------------------------------
>
> Key: MATH-650
> URL: https://issues.apache.org/jira/browse/MATH-650
> Project: Commons Math
> Issue Type: Improvement
> Affects Versions: Nightly Builds
> Environment: Android 2.3 (Dalvik VM with JIT)
> Reporter: Alexis Robert
> Priority: Minor
> Fix For: 3.0
>
> Attachments: FastMathLoadCheck.java, LucTestPerformance.java
>
>
> Working on an Android application using Orekit, I've discovered that a simple FastMath.floor() takes about 4 to 5 secs on a 1GHz Nexus One phone (only the first time it's called). I've launched the Android profiling tool (traceview) and the problem seems to be linked with the static portion of FastMath code named "// Initialize tables"
> The timing resulted in :
> - FastMath.slowexp (40.8%)
> - FastMath.expint (39.2%)
> \- FastMath.quadmult() (95.6% of expint)
> - FastMath.slowlog (18.2%)
> Hoping that would help
> Thanks!
> Alexis Robert
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira