On Nov 8, 2007 9:59 PM, Aleksey Shipilev <aleksey.shipilev@gmail.com> wrote:
> Mikhail,
>
> > Aleksey, if JNI stub has no significant impact here we can check
> > another solution, that was already proposed by Maxim: process
> > 'Math.sqrt' instruction as API magic in JIT. It will eliminate all
> > negative sideeffects related to CC. What do you think about it?
> I'm pretty fine with that. Actually I'm proposing to go this way since
> first message :)
>
> > Another possible solution here is results caching in case of
> > quasiconstant parameters. Do you know if RI has such an optimization?
> I don't know if RI has such optimization. It sounds like a good idea
> for the sqrt() microtest, but not for real workload, since hit ratio
> would be extremely low. To illustrate that, I've printed all sqrt()
> arguments from NBody test and made quick (and funny :)) analysis:
>
> > cat output.log  wc
> 11426981 11426981 221723865
>
> > cat output.log  sort  uniq  wc
> 11426981 11426981 221723865
>
> You see, for >1 million of samples, all the values are unique.
> Even If we are rounding the results for 89 digits after the dot point
> (not the 1516 by default):
>
> > cat output.log  cut b 10  sort  uniq  wc
> 11163818 11163818 122801998
>
> ...we have 2.3% hit ratio (in ideal, if we assume unlimited cache).
> That mean 97.7% of native calls reside.
>
> Of course, the less the precision, the bigger the hit ratio  but we
> shouldn't throw accuracy away entirely for the performance.
>
> Thanks,
> Aleksey.
>
Thanks, that was very useful analysis. At least we will not think
about values caching opportunity in this case.
Do you need any help with implementation of sqrt as API magic in Jitrino.OPT?

Mikhail Fursov
