On 23/01/2013 10:14 AM, Vitaly Davidovich wrote:
Personally, optimizing for interpreter (or even C1) doesn't seem worth it.
If something's truly hot and best perf is desired then use C2 or tiered.
If the method isn't hot enough to trigger the C2 threshold, then why
bother? You're already behind the 8 ball in terms of performance. Maybe
this is heresy though :).
Not all platforms/products have C2.
David
Sent from my phone
On Jan 22, 2013 6:58 PM, "Ulf Zibis"<ulf.zi...@cosoco.de> wrote:
Am 22.01.2013 21:20, schrieb Vladimir Kozlov:
Thank you, Ulf
I will rename method to encodeISOArray and add comment that it could be
replaced by intrinsic by JVM.
Thanks, that's much better. Thinking about, I would more like
encodeArrayToISO or just encodeToISO_8859_1.
The same arrays were use intentionally in test to get performance of code
without effect of CPU's cache/memory subsystem.
I worry about, if the overhead of recalculating sp and dp + comparing ret
!= len + complicated calculation of len will come to effect on short
strings, at least on C1 and interpreter. So why not choose the best code
for all these cases?
The method encodeArrayLoop() is also compiled because it is invoked>
10000 times.
That is what I assumed.
But I see 2 corner cases:
- Programs with sparse use of ISO-8859-1 encoding will not profit of it,
if the compile threshold becomes not reached. Also think about C1.
- I worry, that on small strings the performance of the the intrinsic
surrounding code would come to some account, even if JIT-compiled, but
specially on C1 and interpreter.
So would it hurt, to include those cases while tuning?
-Ulf
