Java News from Tuesday, November 16, 2004

Sun's posted the first snapshot release of Mustang, a.k.a Java 1.6, a.k.a Java 2 6.0, a.k.a Java 6, a.k.a Java Who The Fuck Knows What They'll Call This? Version numbering aside, this is actually fairly cool. This is basically an early development release that includes source code. It's currently published only under the Java Research License. It's available on the usual Sun-supported platforms: Linux, Solaris, and Windows.

Randy Giedyrcz let me know that BookPool is selling the third edition of Java Network Programming for $22.75, a 43% discount, and quite a bit cheaper than Amazon. This is the lowest price I've seen yet.

Xan Gregg took up my challenge to port the prime number finding code to Java. According to Gregg:

I ported these to Java this week-end. Results are below for various machines. Java holds up pretty well and even finds an index-out-of-bounds error in the C code. As a benchmark, these programs test 64-bit arithmetic, i/o, array access, and general program flow.

#    AthC  G5CWC  G5Java  P4Java  Test
1.   83.8  237.0   113.5   176.6   brute force to 10,000,000
2.   18.2   50.5    15.1    32.8   linked list
3.   16.6   45.9    14.1    31.0   #2, skipping multiples of 2
4.   16.4   45.3    14.0    30.4   #2, skipping multiples of 2, 3, 5
5.    2.3    2.2     3.4     3.7   sieve with bytes
6.    4.5   11.7     5.0     8.4   sieve with bits and division
7.    2.2    1.9     2.8     3.4   sieve with bits and bit shift
8a.  23.0   23.9    25.1    33.1   #7 to 100,000,000
8b.   0.1     *      0.4     0.1   write 1,000,000
8c.  11.8   24.8    13.5    18.5   paged search to 100,000,000
8d. 249.6  283.0   259.0   335.6   #7 to 1,000,000,000
8e.   1.9     *      4.0     4.0   write 10,000,000
8f. 225.9  291.4   186.4   255.0   paged search to 1,000,000,000

I couldn't get CodeWarrior to use G5 64-bit instructions -- I wonder if the G5 JVM was taking advantage of them. In theory, that would be an advantage for Java since C compilers usually produce code that will run on any version of the processor but the JIT can tune the code it produces to the particular processor version it's running on.

The author doesn't say why 8a is often slower than 8b+8c, even though the former is memory-only. I think it's because the 8c passes start with the under 1,000,000 primes in a regular array instead of scattered throughout a bit array. Finding the next prime for testing is just a matter of incrementing the index into the array instead of scanning through bits in the bit array.

I've uploaded Gregg's source code if anyone feels like seeing if they can improve on these numbers. On the only same hardware comparison in these tests, Java executes about twice as fast as C, but that may just reflect the weakness of the C compiler used. It's also possible the overhead of running in an IDE hurt the numbers all around.