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
- Values are times in seconds.
- AthC is the Athlon 2400XP with 1.5GB RAM from the article
- G5CWC is a Mac G5 2GHz with 1GB using CodeWarrior
- G5Java is a Mac G5 2GHz with 1GB using IDEA 4 (JDK 1.4)
- P4Java is a 1.8 GHz P4 with 512 MB using IDEA 4 (JDK 1.4)
- * 8b and 8e not run on G5-CWC -- just used from output from java run
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.