harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Aleksey Shipilev" <aleksey.shipi...@gmail.com>
Subject Re: [perf] Comparative benchmarking
Date Thu, 08 Nov 2007 15:59:31 GMT
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.

Mime
View raw message