Request for review: 6896617: Optimize sun.nio.cs.ISO_8859_1$Encode.encodeArrayLoop() on x86

[David Holmes]

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.Zibis at 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
>>
>>