[ 
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

        
  • [jira] [Issue Comment Edited] ... Luc Maisonobe (Issue Comment Edited) (JIRA)

Reply via email to