From: Peter Hickman <peter@...>
Date: 2006-08-04T01:53:41+09:00
Subject: Re: For performance, fix the Java program

Isaac Gouy wrote:
> 1) Over the past 3 or 4 days, people have said what's wrong with the
> way you're producing output in Java, and suggested what you should do
> instead. Is it that you don't know enough Java to follow their
> suggestions and fix the program?
>   
So far the only language that has come close to running as fast as the C 
is the Ocaml version and since then I have found other ways to speed up 
the C version. Just as I have posted the Ruby and Ocaml version if any 
certified Java expert cares to show me how it should be done (*cough* 
Charles O Nutter *cough*) then I will be happy to time it and check the 
output and report the results. That way we can get away from all this 
stupidity like the fact that I didn't use the correct naming convention. 
Which we all know hugely affects performance. But remember that the 
timings will be based on a program that produces output.
> A couple of days ago single measurements on my machine gave
> 0.820s user+sys, gcc -pipe -Wall -O3 -fomit-frame-pointer
> -funroll-loops -march=pentium4
> 4.444s user+sys, sun-jdk-1.5.0.07
>
> Simply writing Java that converts the double-byte Unicode Java
> outputStrings to single-byte /once/ instead of everytime there's a
> print statement, and following the usual Java pattern of wrapping
> output with a BufferedOutputStream, reduces that to
>
> 1.396s user+sys, sun-jdk-1.5.0.07
>
> Yesterday I emailed you another version of your Java generating Perl
> script that fixes those print problems, the output matches the C
> program output.
>   
If it was the email I replied to yesterday then reason that it got close 
to the speed of the C version was because it didn't do any output. Once 
I put the output back in it was only around 5 seconds faster than my own 
Java version and around 15 seconds slower than the C version. Hardly 
encouragement to drop C and pursue Java. Remember I am running the 
program to get the output.
>
> 2) If this is an application, and it has to produce output, and it has
> to produce output for something larger than 6x6, then I think you need
> a better algorithm.
>
> You've mentioned the 5x5 C program took  2.473s, and the 6x6 took 9900s
> - at that rate might we expect 7x7 in 15 months?
>   
Actually the real problem is the amount of disk space I need to store 
the output. 6 x 6 resulted in 32Gb of output. The 7 x 7 will probably 
eat my hard disk well before it completes. I'm not sure that the 1Tb I 
have will be enough so I am looking at removing the rotational and 
mirrored versions of the grids from the output.