Much thanks for your comments John.
The in bug 6984886 mentioned isHigh/LowSurrogate methods are frequently used in small loops of
charset de/encoders, so I expect a measurable performance improvement there.
-Ulf
Am 06.09.2014 um 01:25 schrieb John Rose:
On Aug 30, 2014, at 7:17 AM, Ulf Zibis <ulf.zi...@cosoco.de> wrote:
Am 30.08.2014 um 01:33 schrieb John Rose:
On Aug 29, 2014, at 1:05 PM, Ulf Zibis <ulf.zi...@cosoco.de
<mailto:ulf.zi...@cosoco.de>> wrote:
Thanks for explaining this, but a very little nit: the immediate (I.e. -1) uses
additional 32/64 bits in code which must be loaded from memory and wastes space in
CPU cache or am I wrong? This could be saved with >= 0.
I have to say you're more wrong than right about this. Optimizers routinely change the form of constants. For example, a constant 0 will often
show up as something like "xor eax,eax", not a 32-bit literal zero that loads from somewhere in memory. A comparison of the form
"x > -1" will be freely changed to "x >= 0" and back again; the latter form may (or may not, depending on chip version)
transform to "test eax", with no "-1" or "0" in sight.
1. Thanks for the hint about "x > -1" ===> "x >= 0". But I'm afraid this would apply on
the "x != -1" case we are discussing here.
The equality comparison would be less likely to transform to a non-equality comparison. But
it is still possible in principle, if the JIT could prove that values "x < -1"
are impossible.
2. Are you really sure this optimization is always implemented, as following
bug is still open:
JDK-6984886 : Transform comparisons against odd border to even border
<http://bugs.java.com/bugdatabase/view_bug.do?bug_id=6984886>
Well, I'm pretty sure that no optimizations is "always" implemented; there are
usually corner cases which prevent optimizations. There is always a possibility of
deoptimization to the interpreter, for example. And there are lots of nice-to-have
optimizations that don't make a difference to real applications. Much of compiler
development is driven by observing actual speed bottlenecks and removing them.
But the bug reference is useful; thanks! I added a comment to show where the optimization occurs
now—disappointingly little I grant you—and where to start looking to improve it. The bug is rated P5 (lowest
rating) probably because the reporter said "it should be faster"; "wouldn't this be nice"
is a far weaker argument than "I'm spending too much on hardware because this loop is slow".
My comments about the unpredictability of optimizers still stand. The most
robust way to manage such problems is, first confirm it is a real performance
problem (not a micro-nano thing), and second get the optimizer to make all
equivalent inputs produce good code. The tiny place where this optimization is
done in HotSpot suggests that that was a place where the transform actually
mattered the most.
— John
