On Nov 8, 2007 9:59 PM, Aleksey Shipilev 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 side-effects 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
> > quasi-constant 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 8-9 digits after the dot point
> (not the 15-16 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