Re[2]: New portion of improvements for Dual-Pivot Quicksort

[Vladimir Iaroslavski]

Hello Osvaldo,

I've prepared simple test which scans an array and does assignments for each element,
see attached Test class:

a[k] = a[less];
a[less++] = 0; // or a[less] = 0; less++;

The result of running "java -client Test" is:

a[less], less++;   Time: 6998
a[less++];         Time: 8416

It is much more than 1%. Is it bug in JVM? Note that under server VM
there is no difference between "a[less++]" and "a[less], less++".
I'm using JDK 7 on Windows XP:

java version "1.7.0-ea"
Java(TM) SE Runtime Environment (build 1.7.0-ea-b84)
Java HotSpot(TM) Client VM (build 17.0-b09, mixed mode, sharing)

Thanks,
Vladimir

Fri, 18 Jun 2010 13:03:50 -0300 письмо от Osvaldo Doederlein <opinali at gmail.com>:

> Hi,
> 
> 2010/6/18 Vladimir Iaroslavski <iaroslavski at mail.ru>
> Hello,
> 
> Here is next piece of improvements, see attached class.
> It is surprise but code
> 
> a[less++] = ak;
> 
> works slower (client VM) than
> 
> a[less] = ak;
> less++;
> 
> This is really surprising, even if it's C1 only - and bad, considering that "p[i++] = y" is a very popular Java idiom for sequential mutation of arrays (the equivalent of C's "*p++ = y". I wonder if this reveals some simple bug/weakness of C1 that should be investigated. Even a un-mighty, client-side JIT should have no problem with such minor code-ordering issue. I'm all in favor of micro optimization for critical stuff like DPQS (or most of the core actually), but the kind of change above borders gratuitous code churn... perhaps if the problem is simple to fix at the VM level, we gain this extra 1% not only in DPQS but in a gazillion other methods.
> 
> A+
> Osvaldo
> 
> In general, we save about about 1% on Bentley's test suite.
> Also I eliminate additional check of indexes k and less:
> 
> if (k != less) {
>   // swap a[k] and a[less]
> }
> For long type it gives additional one percent and works the same
> for other types.
> 
> If you don't have any comments/suggestions, I'm going to integrate
> the code into JDK repository on the next week.
> 
> Thanks,
> Vladimir
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Test.java
Type: application/octet-stream
Size: 1333 bytes
Desc: not available
URL: <http://mail.openjdk.java.net/pipermail/core-libs-dev/attachments/20100619/8d9bcceb/Test.java>