Request for review: 6896617: Optimize sun.nio.cs.ISO_8859_1$Encode.encodeArrayLoop() on x86 (original) (raw)
Ulf Zibis Ulf.Zibis at CoSoCo.de
Tue Jan 22 23:57:38 UTC 2013
- Previous message: Request for review: 6896617: Optimize sun.nio.cs.ISO_8859_1$Encode.encodeArrayLoop() on x86
- Next message: Request for review: 6896617: Optimize sun.nio.cs.ISO_8859_1$Encode.encodeArrayLoop() on x86
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
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
- Previous message: Request for review: 6896617: Optimize sun.nio.cs.ISO_8859_1$Encode.encodeArrayLoop() on x86
- Next message: Request for review: 6896617: Optimize sun.nio.cs.ISO_8859_1$Encode.encodeArrayLoop() on x86
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]