Re: [Math] FastMath preset tables

2011-09-15 Thread Ted Dunning
Resources are likely to be considerably faster and more compact than class files. The issue is that the class files actually compile into code that inserts values one by one. Better to just read the whole table in a single go directly into an array. On Thu, Sep 15, 2011 at 9:21 AM, wrote: > >

Re: [Math] FastMath preset tables

2011-09-15 Thread luc . maisonobe
Hi Gilles, - Mail original - > Hello. > > > > > > >People taking part to this discussion[1] seem to have a hard time > > >being > > >explicit about what they are trying to achieve. > > > > > >(1) > > >>From information gathered so far, the issue raised seems to have > > >>been solved > >

Re: [Math] FastMath preset tables

2011-09-14 Thread Gilles Sadowski
On Wed, Sep 14, 2011 at 08:02:20PM +, Ted Dunning wrote: > On Wed, Sep 14, 2011 at 7:57 PM, Phil Steitz wrote: > > > > No. But it is easy to code up some warmup in the startup part of the > > life > > > cycle. That should be a penalty paid once when the server starts, not > > later > > > on

Re: [Math] FastMath preset tables

2011-09-14 Thread Gilles Sadowski
Hello. > > > >People taking part to this discussion[1] seem to have a hard time being > >explicit about what they are trying to achieve. > > > >(1) > >>From information gathered so far, the issue raised seems to have been solved > >by taking advantage of the fact that the JVM loads classes at firs

Re: [Math] FastMath preset tables (Was: Re: svn commit: r1169437 - [...])

2011-09-14 Thread Ted Dunning
On Wed, Sep 14, 2011 at 7:57 PM, Phil Steitz wrote: > > No. But it is easy to code up some warmup in the startup part of the > life > > cycle. That should be a penalty paid once when the server starts, not > later > > on the first request. In the worst case, you can build a simple startup > >

Re: [Math] FastMath preset tables (Was: Re: svn commit: r1169437 - [...])

2011-09-14 Thread Phil Steitz
On 9/14/11 12:43 PM, Ted Dunning wrote: > On Wed, Sep 14, 2011 at 7:27 PM, sebb wrote: > >> On 14 September 2011 20:16, Ted Dunning wrote: >>> This is a red herring. No web server I know of restarts Java processes >> like >>> this. The JVM is kept hot and classes are not unloaded lightly. >> Tr

Re: [Math] FastMath preset tables (Was: Re: svn commit: r1169437 - [...])

2011-09-14 Thread Ted Dunning
On Wed, Sep 14, 2011 at 7:27 PM, sebb wrote: > On 14 September 2011 20:16, Ted Dunning wrote: > > This is a red herring. No web server I know of restarts Java processes > like > > this. The JVM is kept hot and classes are not unloaded lightly. > > True, but the server does not normally load al

Re: [Math] FastMath preset tables (Was: Re: svn commit: r1169437 - [...])

2011-09-14 Thread sebb
On 14 September 2011 20:16, Ted Dunning wrote: > This is a red herring.  No web server I know of restarts Java processes like > this.  The JVM is kept hot and classes are not unloaded lightly. True, but the server does not normally load all the classes in all its libraries, surely? In which case

Re: [Math] FastMath preset tables (Was: Re: svn commit: r1169437 - [...])

2011-09-14 Thread Ted Dunning
This is a red herring. No web server I know of restarts Java processes like this. The JVM is kept hot and classes are not unloaded lightly. A one minute startup due purely to this one library would be an issue. I haven't heard that definitively demonstrated here at all. A micro-benchmark would

Re: [Math] FastMath preset tables (Was: Re: svn commit: r1169437 - [...])

2011-09-14 Thread Luc Maisonobe
Le 14/09/2011 17:31, Gilles Sadowski a écrit : Hi. People taking part to this discussion[1] seem to have a hard time being explicit about what they are trying to achieve. (1) From information gathered so far, the issue raised seems to have been solved by taking advantage of the fact that the

[Math] FastMath preset tables (Was: Re: svn commit: r1169437 - [...])

2011-09-14 Thread Gilles Sadowski
Hi. People taking part to this discussion[1] seem to have a hard time being explicit about what they are trying to achieve. (1) >From information gathered so far, the issue raised seems to have been solved by taking advantage of the fact that the JVM loads classes at first use (i.e methods will n