[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: A 21st Century Apple II?

On 2009-03-09 08:23:06 +0700, mdj <mdj.mdj@gmail.com> said:

On Mar 7, 10:51 pm, apple2fr...@gmail.com wrote:
On Mar 7, 3:11 pm, mdj <mdj....@gmail.com> wrote:> On Mar 6, 9:48 pm, apple2fr...@gmail.com wrote: 
Well sure, if you don't actually *read* the benchmarks and see what
the results are you can pretend they say whatever you like ;-)


Now you're getting a little testy here.  I did in fact read the
benchmarks which you specifically picked to illustrate your point.  I
responded with specific benchmarks using the Java 6 client because I
think that is much more representative of what the average person will
use in order to run Java programs.  And the benchmarks I picked
illustrate my point quite clearly.


The only point you've made is that one environment with the optimiser
turned on can beat another with the optimiser turned off.
This made me curious, so I went to the language shootout web site mentioned earlier to see for myself.
I see they have six different variations of Java on the site. One v1.4, four v6, and one gcj (if you consider that Java).
Of the four different versions of Java v6 they benchmark, I see the following options present: 

-client
-server
-Xint
-Xms64m
In all cases except for the -Xint, the HotSpot (JIT) compiler is active. As I recall, the -client optimises for minimum startup time, -server optimises for maximum speed, and the -Xms64m simply tells the interpreter to pre-allocate 64 megabytes of memory for the heap -- so that the JRE won't have to repeatedly allocate more memory with mmap() or equivalent.
If -Xms64m provides significant performance gains, it is likely because the overhead of repeated system calls to the operating system to extend the heap are avoided. Many statically compiled languages would receive a similar performance gain if they included a statement to pre-allocate 64 megabytes of memory on the heap as their first statement, which is in effect what -Xms64m is doing for the Java version.
I went to the site, clicked on the results for Java 6 -Xms64m and was presented with some performance figures. Next, I set the compare-to drop-down to C++ Intel and clicked on the show button.
For the 14 benchmarks available, the results on the graph displayed show that Java 6 -Xms64m ranges anywhere from around 40% faster (for binary-trees) to 900% slower (for partial-sums). The average difference is probably not far off from a factor of 2 faster, but I'm too lazy to calculate it exactly.
I see that if you use the best of the five or six variations of Java and compare against the best of the two versions of C++, the performance difference would probably narrow somewhat. In that case, I'd suggest that two new versions of C++ code be produced where the startup code is configured to pre-allocate 64 megabytes on the heap. I'm guessing that this would eliminate the relative advantage that Java has with the -Xms64m argument.
In any event, I'm interested to know what Matt has to say about this, because maybe Im missing something. 


My selection metric was simple: display all the results, and pick the
best result for each language, and use that as the basis for
comparision. Fairly obviously, if it's performance we want to compare,
this is the only useful metric.
It seems to me that both of you should have made your selection criteria clear from the beginning. 

Please also keep in mind what I said about about the -Xms64m argument.


If you want to compare the performance of the GNU compiler versus the
Intel compiler, then look at the average performance across all
benchmarks for the GNU compiler and the Intel compiler.  If you do the
math, you'll see that the Intel compiler is significantly faster.
Congratulations, you have located a statistical anomaly above.


And that's exactly it. If you do the math and compare the best results
of the two languages you'll see that your entire conclusion is based
upon such a statistical anomaly.
To me it looks like his conclusion is based on a different selection criteria for the benchmarks. 


I tend to find that threads that become large and develop digressions
are good indicators of the level of interest in the original point and
don't find it particularly bothersome to filter out that which I
consider "noise". And whilst it may be considered an unwanted by some
the fact remains that if you stand on a public soapbox, you are going
to be heckled by the crowd. For future reference you might find it
easier to simply retract a fallacious remark then to continue to argue
it, particularly in light of your "most programmers today are crap"
position.
I haven't read the entire thread, but it appears to me to be a central part of his argument that C++ is faster than Java. Unless I missed something obvious, that appears to be supported by the benchmarks at the language shootout web site if you look at them in aggregate. 

Jason