Java Forum / General / July 2007
Java is slower than C++!
Stefan Ram - 09 Jun 2007 14:33 GMT Hotspot is being given Bytecode, which is as good as source code. Hotspot then translates this to the language of the hardware processor.
Therefore, a code segment, that does not allocate or release memory and does not call other methods, but only does double- and int-arithmetics, loops and branches should be compiled to machine code similar to the one created by a C++ compiler.
Thus, it should be approximately as fast as the C++ code (or even faster, because Hotspot knows more about the runtime environment than the C++ compiler does).
So why is the Java program in the following benchmark still slower than the C++ program?
(Most of the runtime is spent in the first function / method that does not call other functions / methods nor does memory allocations / deallocations.)
#include <stdio.h> #include "windows.h"
#define BAILOUT 16 #define MAX_ITERATIONS 1000
int mandelbrot( double const x, double const y ) { double cr = y - 0.5; double zi = 0.0; double zr = 0.0; int i = 0; while( 1 ) { ++i; double const temp = zr * zi; double const zr2 = zr * zr; double const zi2 = zi * zi; zr = zr2 - zi2 + cr; zi = temp + temp + x; if( zi2 + zr2 > BAILOUT )return i; if( i > MAX_ITERATIONS )return 0; }}
void main1() { char * p =( char * )malloc( 82 * 82 + 82 ); if( p ) { char * q = p; for( int y = -39; y < 39; ++y ) { *q++ = '\n'; for( int x = -39; x < 39; ++x ) *q++ = mandelbrot( x / 40.0, y / 40.0 )? ' ' : '*'; } *q++ = 0; // puts( p ); free(( void * )p ); }}
int main() { for( int i = 0; i < 20; ++i ) { long const start =( long )GetTickCount(); main1(); printf( "%ld ms\n",( long )GetTickCount() - start ); } system( "PAUSE" ); }
154 ms 149 ms 148 ms 149 ms 147 ms 147 ms 147 ms 146 ms 146 ms 146 ms 145 ms 150 ms 145 ms 145 ms 146 ms 145 ms 150 ms 148 ms 149 ms 148 ms
public class Main { final static int BAILOUT = 16; final static int MAX_ITERATIONS = 1000;
public static int iterate( final double x, final double y ) { final double cr = y - 0.5; double zi = 0.0; double zr = 0.0; int i = 0; while( true ) { ++i; final double temp = zr * zi; final double zr2 = zr * zr; final double zi2 = zi * zi; zr = zr2 - zi2 + cr; zi = temp + temp + x; if( zi2 + zr2 > BAILOUT )return i; if( i > MAX_ITERATIONS )return 0; }}
public static void main1() { final char[] sb = new char[ 82 * 82 + 82 ]; int q = 0; for( int y = -39; y < 39; ++y ) { sb[ q++ ]= '\n'; for( int x = -39; x < 39; ++x ) sb[ q++ ]= iterate( x / 40.0, y / 40.0 )== 0 ? '*' : ' '; } /* java.lang.System.out.println( new java.lang.String( sb )); */ }
public static void main( final java.lang.String[] args ) { for( int i = 0; i < 20; ++i ) { final long a = System.nanoTime(); main1(); final long dt = System.nanoTime() - a; java.lang.System.out.println(( dt / 1000 / 1000 )+ " ms" ); }}}
358 ms 220 ms 279 ms 214 ms 215 ms 214 ms 215 ms 214 ms 215 ms 215 ms 215 ms 214 ms 215 ms 214 ms 215 ms 214 ms 236 ms 214 ms 216 ms 214 ms
C++ 6,75 main1/s ********************************************************************
Java 4,67 main1/s ***********************************************
Based on code from
http://www.timestretch.com/FractalBenchmark.html
Andrew Thompson - 09 Jun 2007 14:43 GMT ...
>public class Main ...
> java.lang.System.out.println(( dt / 1000 / 1000 )+ " ms" ); }}} > >358 ms ...
>214 ms Wow! You must be running an old processor!
My figures for the Java ranged from 57-63 milliseconds, and that was on an AMD XP1800 Athlon CPU (w/ Java 6). (No capacity to compile and run the C++)
 Signature Andrew Thompson http://www.athompson.info/andrew/
Stefan Ram - 09 Jun 2007 14:47 GMT >>java.lang.System.out.println(( dt / 1000 / 1000 )+ " ms" ); }}} >>358 ms >>214 ms >Wow! You must be running an old processor! For privacy, the measured times all where scaled by the same factor and, randomly, »1«, »0« or »-1« was added, in order not to make public information about the hardware I use.
All that matters here is the /relative/ speed of the C++ and the Java implementation.
Mark Space - 09 Jun 2007 16:03 GMT >>> java.lang.System.out.println(( dt / 1000 / 1000 )+ " ms" ); }}} >>> 358 ms [quoted text clipped - 7 lines] > All that matters here is the /relative/ speed of the C++ and > the Java implementation. init: deps-jar: compile: run: 24 ms 24 ms 23 ms 23 ms 22 ms 23 ms 23 ms 23 ms 22 ms 22 ms 22 ms 22 ms 22 ms 22 ms 23 ms 22 ms 22 ms 22 ms 22 ms 22 ms BUILD SUCCESSFUL (total time: 0 seconds)
Paul Tomblin - 09 Jun 2007 17:13 GMT In a previous article, ram@zedat.fu-berlin.de (Stefan Ram) said:
> For privacy, the measured times all where scaled by the same > factor and, randomly, »1«, »0« or »-1« was added, in order not > to make public information about the hardware I use. Either you are testing some weird hardware under an NDA, or you're an idiot.
 Signature Paul Tomblin <ptomblin@xcski.com> http://blog.xcski.com/ Either way, it'll remind the clued that there's only one letter difference between 'turkey' and 'turnkey'. -- Mike Andrews
Arne Vajhøj - 09 Jun 2007 17:23 GMT > In a previous article, ram@zedat.fu-berlin.de (Stefan Ram) said: >> For privacy, the measured times all where scaled by the same [quoted text clipped - 3 lines] > Either you are testing some weird hardware under an NDA, or you're an > idiot. Or he has sense of humor !
Arne
Tom Hawtin - 09 Jun 2007 15:58 GMT > So why is the Java program in the following benchmark still > slower than the C++ program?
> Based on code from > > http://www.timestretch.com/FractalBenchmark.html Someone blogged about this the other day (but didn't have comments turned on for non-blogspot users).
A problem with the original code is that it included I/O which added a little to the time.
Also it used an unspecified implementation of ye olde 1.4. Using the Server HotSpot on an AMD64 with Sun 1.6.0_01, I found performance over twice that of Sun 1.4.2_14 with default options. I note you don't specify versions or options for your tests.
Once you use modern implementations with reasonable options, the differences mostly disappear. IIRC, the Java version can come out ahead.
There are reasons why Java should be slower. It defines reasonably well how floating point should work, so it can be difficult to compile for hardware that is less accurate. Also as the compilation is done at runtime, some compromises are made to reduce the compile time.
Tom Hawtin
Daniel Dyer - 09 Jun 2007 16:06 GMT >> So why is the Java program in the following benchmark still >> slower than the C++ program? [quoted text clipped - 4 lines] > Someone blogged about this the other day (but didn't have comments > turned on for non-blogspot users). ...
> Once you use modern implementations with reasonable options, the > differences mostly disappear. IIRC, the Java version can come out ahead. I read the same article, just found the link:
http://paulbuchheit.blogspot.com/2007/06/java-is-faster-than-c.html
Dan.
 Signature Daniel Dyer http//www.uncommons.org
Tom Hawtin - 09 Jun 2007 17:48 GMT >> Once you use modern implementations with reasonable options, the >> differences mostly disappear. IIRC, the Java version can come out ahead. > > I read the same article, just found the link: > > http://paulbuchheit.blogspot.com/2007/06/java-is-faster-than-c.html That's the monkey.
That points to the original article which has a JavaScript version (comment out the first line). Even *without a warm up*, using the JDK 1.6 JavaScript implementation does give some interesting timings.
$ time ~/sun/jdk1.6.0_01-amd/bin/jrunscript -J-server -J-d64 -f mandel.js >/dev/null
real 0m11.878s user 0m11.737s sys 0m0.116s $ time ~/sun/jdk1.6.0_01-amd/bin/jrunscript -J-server -J-d64 -f mandel.js >/dev/null
real 0m11.801s user 0m11.621s sys 0m0.116s $ time ~/sun/jdk1.6.0_01-amd/bin/java -server -d64 Mandelbrot >/dev/null
real 0m0.470s user 0m0.404s sys 0m0.016s $ time ~/sun/jdk1.6.0_01-amd/bin/java -server -d64 Mandelbrot >/dev/null
real 0m0.259s user 0m0.192s sys 0m0.032s
(Timings on an Ultra 20 with Opteron 148 running Ubuntu 7.04.)
Tom Hawtin
Kai Schwebke - 09 Jun 2007 16:26 GMT > So why is the Java program in the following benchmark still > slower than the C++ program? I got different results (using MAX_ITERATIONS 10000, only latest stable timing listed)
java version "1.6.0_01" (-client) 200 ms
java version "1.6.0_01" (-server) 147 ms
g++ (GCC 3.4.6, no optimizations) 260 ms
g++ (GCC 3.4.6, -O3 -mpentiumpro) 160 ms
So on my system there is no difference between optimized Java (server vm) and optimized C++ code in this bench.
Kai
Lew - 09 Jun 2007 19:21 GMT >> So why is the Java program in the following benchmark still >> slower than the C++ program? [quoted text clipped - 17 lines] > optimized Java (server vm) and optimized C++ code > in this bench. Given the breathlessly flame-baiting nature of the headline and original post, I am unsurprised to find the truth to be more complex or even to contradict the OP.
Also, OP, please consider a more standard indentation style.
 Signature Lew
Lew - 09 Jun 2007 20:08 GMT I rewrote the loop to time 100 iterations and give the total and average elapsed time, on a 2 GHz AMD-64 running Linux Fedora 6, Java version 1.6.0_01 and g++ 4.1.1:
g++ -O3: $ ./mandelbrot Elapsed: 4550 ms iteration: 45.50 ms
g++ -O: $ ./mandelbrot Elapsed: 5140 ms iteration: 51.40 ms
g++ unoptimized: $ ./mandelbrot Elapsed: 8320 ms iteration: 83.20 ms
javac -g:none: $ java -cp build/classes testit.Mandelbrot Elapsed: 8133 ms Iteration: 81.33 ms
FWIW, here are my timings with the original algorithm, modified for UNIX - this measures each test cycle separately:
$ java -cp build/classes testit.Mandelbrot 57 ms 122 ms 52 ms 47 ms 171 ms 45 ms 160 ms 45 ms 43 ms 151 ms 43 ms 154 ms 45 ms 43 ms 145 ms 46 ms 150 ms 45 ms 43 ms 157 ms
$ ./mandelbrot (optimized -O3) 40 ms 50 ms 40 ms 50 ms 40 ms 50 ms 40 ms 50 ms 50 ms 50 ms 40 ms 40 ms 50 ms 40 ms 50 ms 50 ms 40 ms 50 ms 40 ms 50 ms
 Signature Lew
Daniel Dyer - 09 Jun 2007 20:45 GMT > I rewrote the loop to time 100 iterations and give the total and average > elapsed time, on a 2 GHz AMD-64 running Linux Fedora 6, Java version > 1.6.0_01 and g++ 4.1.1: ...
> javac -g:none: > $ java -cp build/classes testit.Mandelbrot > Elapsed: 8133 ms > Iteration: 81.33 ms How about with the "-server" switch? As I understand it, there isn't such a big difference between the client and server VMs in Java 6 as there was in 5, but I'd guess it is still likley to be faster on the server VM.
Dan.
 Signature Daniel Dyer http//www.uncommons.org
Lew - 09 Jun 2007 21:48 GMT >> I rewrote the loop to time 100 iterations and give the total and >> average elapsed time, on a 2 GHz AMD-64 running Linux Fedora 6, Java [quoted text clipped - 9 lines] > there was in 5, but I'd guess it is still likley to be faster on the > server VM. $ java -server -cp build/classes testit.Mandelbrot Elapsed: 8073 ms Iteration: 80.73
I had run it before but didn't feel the need to cite the results. For one thing, isn't "-server" better suited to long running processes?
Maybe if I up the loops to a few thousand cycles . . .
 Signature Lew
Steve Wampler - 09 Jun 2007 22:01 GMT > How about with the "-server" switch? As I understand it, there isn't > such a big difference between the client and server VMs in Java 6 as > there was in 5, but I'd guess it is still likley to be faster on the > server VM. In one of my worlds, with 1.6.0-b105 (Linux, CentOS4, dual-cpu Athlon), the server VM is slower at this than the client VM:
->java -client Main 47 ms 50 ms 48 ms 48 ms 49 ms 48 ms 48 ms 49 ms 48 ms 48 ms 49 ms 48 ms 48 ms 49 ms 48 ms 48 ms 48 ms 49 ms 48 ms 48 ms ->java -server Main 72 ms 64 ms 64 ms 62 ms 58 ms 56 ms 56 ms 56 ms 56 ms 56 ms 56 ms 56 ms 56 ms 56 ms 56 ms 56 ms 56 ms 56 ms 56 ms 56 ms
Both are slower than g++4.1.1 (-O3):
->a.out 20 ms 20 ms 20 ms 20 ms 20 ms 20 ms 20 ms 30 ms 20 ms 20 ms 20 ms 20 ms 20 ms 20 ms 20 ms 30 ms 20 ms 20 ms 20 ms 20 ms
*However*, running the same code/options/OS/compilers/VMs on a dual Opteron yields much better results for Java (the C++ times are indistinguishable from above [~same clock speed on both systems]) and the server VM seems to win (over both client and C++):
->java -client Main 93 ms 26 ms 24 ms 23 ms 23 ms 24 ms 23 ms 23 ms 24 ms 23 ms 23 ms 24 ms 26 ms 24 ms 23 ms 23 ms 23 ms 23 ms 23 ms 24 ms ->java -server Main 88 ms 20 ms 31 ms 18 ms 18 ms 21 ms 18 ms 19 ms 18 ms 18 ms 18 ms 18 ms 18 ms 18 ms 19 ms 18 ms 18 ms 18 ms 18 ms 19 ms
 Signature Steve Wampler -- swampler@noao.edu The gods that smiled on your birth are now laughing out loud.
Roedy Green - 10 Jun 2007 00:28 GMT > Thus, it should be approximately as fast as the C++ code (or > even faster, because Hotspot knows more about the runtime > environment than the C++ compiler does). I discovered the Jet optimiser produces better code that hand tuned assembler. See http://mindprod.com/jgloss/jet.html -- Roedy Green Canadian Mind Products The Java Glossary http://mindprod.com
Twisted - 10 Jun 2007 05:10 GMT On Jun 9, 7:28 pm, Roedy Green <see_webs...@mindprod.com.invalid> wrote:
> > Thus, it should be approximately as fast as the C++ code (or > > even faster, because Hotspot knows more about the runtime [quoted text clipped - 5 lines] > Roedy Green Canadian Mind Products > The Java Glossaryhttp://mindprod.com Yup. Computers can now routinely beat the best humans at chess and code-optimization, and they're even getting somewhere with Go now.
Luc The Perverse - 10 Jun 2007 08:19 GMT > On Jun 9, 7:28 pm, Roedy Green <see_webs...@mindprod.com.invalid> > wrote: [quoted text clipped - 11 lines] > Yup. Computers can now routinely beat the best humans at chess and > code-optimization, and they're even getting somewhere with Go now. I'm pretty sure the last part was a joke - but I don't get it. (And somehow I don't think searching google for "go" is going to help)
-- LTP
:) Lars Enderin - 10 Jun 2007 09:20 GMT Luc The Perverse skrev:
>> On Jun 9, 7:28 pm, Roedy Green <see_webs...@mindprod.com.invalid> >> wrote: [quoted text clipped - 12 lines] > I'm pretty sure the last part was a joke - but I don't get it. (And somehow > I don't think searching google for "go" is going to help) Somebody in another newsgroup made the same mistake about another common word used as a program name, and refused to search for it. Actually, you find the relevant links very early among the Google search results: http://en.wikipedia.org/wiki/Go_(board_game)
And I don't think there was a joke in the reference.
Lew - 10 Jun 2007 14:21 GMT Luc The Perverse skrev:
>> I'm pretty sure the last part was a joke - but I don't get it. (And >> somehow I don't think searching google for "go" is going to help) Go, Weiqi, Baduk - the best board game ever invented.
You cannot gain respect in Asia ignorant of this game, in the way you cannot gain respect in America ignorant of golf.
You need to improve your Google-fu - it is not hard to add qualifying words to your search, as in "Go board game".
But to recap Lars Enderin's comment about searching just on "Go":
>> Somebody in another newsgroup made the same mistake about another common >> word used as a program name, and refused to search for it. Actually, you >> find the relevant links very early among the Google search results: >> http://en.wikipedia.org/wiki/Go_(board_game) that link was the second major hit.
 Signature Lew
Luc The Perverse - 10 Jun 2007 18:02 GMT > Luc The Perverse skrev: >>> I'm pretty sure the last part was a joke - but I don't get it. (And [quoted text clipped - 15 lines] > > that link was the second major hit. Thanks guys!
I will try google next time.
-- LTP
:) Twisted - 10 Jun 2007 21:25 GMT > Luc The Perverse skrev: > [quoted text clipped - 5 lines] > You cannot gain respect in Asia ignorant of this game, in the way you cannot > gain respect in America ignorant of golf. *sputter* You can too. In intellectual circles, you can't gain respect in Asia ignorant of Go, or in America ignorant of chess, perhaps. But golf?!
> You need to improve your Google-fu - it is not hard to add qualifying words to > your search, as in "Go board game". Given that the person in question didn't know I was referring to Go- the-board-game, why exactly would it have ever occurred to him to use "board game" in his search query? :)
I'm afraid I must find for the question-asker here: given that he was unfamiliar with that usage of the word "Go" (arguably surprising, but not an indictable offense), and given that there were no real hints at qualifying terms to add to the query (chess being mentioned could suggest "board game", but code optimization being mentioned could suggest "compiler" or even, ObTopic, "java", instead), and given that Google queries of short, common English words without qualifying terms will tend to be a crapshoot at best (specific known exceptions notwithstanding), I'd say he did the right thing in asking me to clarify what I meant.
And if I'd gotten to it before anyone else had done so I'd have answered him, honestly and unsnarkily.
> that link was the second major hit. And who would have guessed that, without prior knowledge? Not the question-asker and not I.
Lars Enderin - 10 Jun 2007 22:04 GMT Twisted skrev:
>> Luc The Perverse skrev: >> [quoted text clipped - 34 lines] > And who would have guessed that, without prior knowledge? Not the > question-asker and not I. I made a mistake in my comment. I think you were the one who thought it ridiculous to even try to google for "Ant", and it was in this very newsgroup (comp.lang.java.programmer).
Karl Uppiano - 10 Jun 2007 22:12 GMT > I made a mistake in my comment. I think you were the one who thought it > ridiculous to even try to google for "Ant", and it was in this very > newsgroup (comp.lang.java.programmer). I think the rule should be, Google first, then ask. I am seldom disappointed with Google results, even for obscure references.
Twisted - 11 Jun 2007 02:58 GMT > > I made a mistake in my comment. I think you were the one who thought it > > ridiculous to even try to google for "Ant", and it was in this very > > newsgroup (comp.lang.java.programmer). > > I think the rule should be, Google first, then ask. I am seldom disappointed > with Google results, even for obscure references. Obscure references aren't the problem, if they are just plain obscure, but fairly specific. For those, there's nothing better than Google -- there's a reason "Who Wants to Be a Millionaire?" never had a "search Google" lifeline. ;)
*Ambiguous* references are the problem, especially when there's a) a very common meaning and b) a very obscure one and you're fairly certain the latter is meant. The expectation is that common meaning usages will dominate the search results, and worse, even if various different meanings or usages are apparent from the results, it still may not be clear which of these is the one. On occasion, there are exceptions, but obviously they can't be counted on.
If you know "ant" is Java-related, a search for "ant" may well turn up a reference to the Java-related one as well as the bug, and you can recognize the relevant usage from the two. That apparently does occur, but it's the exception to the rule, not the rule. Moreover, the same thing that lets you tell which "ant" results are the "right" results also lets you use a better query to begin with, e.g. "ant java".
If you know very little about "Go", other than that someone didn't apparently mean the usual thing by it, a bunch of Google results some of which refer to travel, some to the board game, and some to who knows what else won't elucidate matters any. In this case, it may be the case that "computer go" would give a useful result set focused around the game; then again it might not, since "go" is such a common word. (An actual test produces mostly references to game software and AI, but there are some unrelated results mixed in as well, in the first ten hits.) Some browsing might reveal that the game software and AI problem are connected, and suggest that it fits in with the computer chess I mentioned, but who has time for that much random link- chasing with precious little indication of what was meant? I for one am not bothered if I say something like I did and someone asks me for clarification! It takes me less time to provide it, civilly at that, than it would probably take them to do a bunch of searches, follow some links, and guess, and they end up with a truly certain answer besides, since it comes from the horse's mouth. Much more efficient use of man-hours.
And of course there's the cases, the vast majority, where it's completely useless. Consider "woody":
Woody Allen - Wikipedia, the free encyclopedia
Woody - Wikipedia, the free encyclopedia Sheriff Woody, a character in the Toy Story movies; ...
Welcome to the Official Woody Guthrie Website
Official Woody Guthrie web site
Debian GNU/Linux 3.0 "woody" Release Information
WOODY'S TORONTO
Woody Woodpecker DVD
Woody's Office Portal - wopr.com
Woody Harrelson
Woody's Tavern - Ft. Worth, TX
There's a ton of "woody" hits. In the top ten hits, reprinted above, are nine different meanings: three different celebrities, two different fictional characters from animated films, two different bar- type venues in separate cities (and most of the 6.5 billion potential searchers are nowhere near either and nowhere near rich enough to travel to either on a whim, besides), one office-supplies company (or something; with a cute War Games reference -- how did they, of all people, manage to snag THAT domain name? Arrrgh! I wanted it), and one piece of software.
If it had come up in a computer discussion, without elaboration, good luck. The Debian distro would probably be the correct reference (and it's the one I was thinking of when I picked it for my test case). It's lucky that Debian Woody is even in the top ten results, given the numerous less obscure meanings of this common English word. The office supplies hit is another candidate, since computers are among the commonest of office tools; if "woody" came up in a discussion around the water cooler or on the internal Usenet server at the office, it would be a strong candidate indeed. And given the penchant people have for slipping pop culture references in all kinds of places however irrelevant they may be there, you'd not be able to discount the celebrities and fictional characters entirely. That means you'd eliminate the tavern and the club and leave 8 possible hits, with 7 different meanings.
Not looking good.
I rest my case.
(Interesting that the slang meaning of "woody" that is R-rated doesn't crop up. Is Google biasing its results for common terms against pornographic results, and perhaps in favor of tech-related results?)
Karl Uppiano - 11 Jun 2007 03:42 GMT >> > I made a mistake in my comment. I think you were the one who thought it >> > ridiculous to even try to google for "Ant", and it was in this very [quoted text clipped - 99 lines] > crop up. Is Google biasing its results for common terms against > pornographic results, and perhaps in favor of tech-related results?) Yeah, I get all that, and I have had some frustration when searching for specific things, but far more often than not, Google does turn up results that answer my question. At worst, it gives me a bunch of interesting links, if I'm looking for some entertaining reading! :-)
Lew - 11 Jun 2007 04:38 GMT "Twisted" wrote
>> *Ambiguous* references are the problem, especially when there's a) a >> very common meaning and b) a very obscure one and you're fairly [quoted text clipped - 3 lines] >> >> I rest my case. And yet one quick post to the group disambiguated all those to the second major hit on the board.
Yes, the "Go" reference was a tad too hip for the room, perhaps, but it's a well-known game, particularly among engineers, so the introduction of the reference was not such a shot in the dark in context.
 Signature Lew
Luc The Perverse - 11 Jun 2007 04:40 GMT >>> > I made a mistake in my comment. I think you were the one who thought >>> > it [quoted text clipped - 105 lines] > that answer my question. At worst, it gives me a bunch of interesting > links, if I'm looking for some entertaining reading! :-) In my defense, I did not know Go was a board game. If I'd known it were a game I'd have likely tried google - I thought it was some obscure joke.
-- LTP
:) Twisted - 11 Jun 2007 07:58 GMT On Jun 10, 11:40 pm, "Luc The Perverse" <sll_noSpamlicious_z_XX...@cc.usu.edu> wrote:
> In my defense, I did not know Go was a board game. If I'd known it were a > game I'd have likely tried google - I thought it was some obscure joke. Not that you should need a defense. Asking a question when you don't know something isn't criminal. Although perhaps *not* asking one should be.
Lew - 10 Jun 2007 23:35 GMT Lew wrote:
>> that link was the second major hit.
> And who would have guessed that, without prior knowledge? Not the > question-asker and not I. That link was the second major hit on the word "go" by itself.
 Signature Lew
Patricia Shanahan - 10 Jun 2007 14:16 GMT >> On Jun 9, 7:28 pm, Roedy Green <see_webs...@mindprod.com.invalid> >> wrote: [quoted text clipped - 12 lines] > I'm pretty sure the last part was a joke - but I don't get it. (And somehow > I don't think searching google for "go" is going to help) Go, in this context, is a board game. See http://en.wikipedia.org/wiki/Go_(board_game).
Incidentally, you underestimate Google. That Wikipedia page is the second hit in a search for "go".
I read "getting somewhere with Go now" as meaning "Making progress on a notoriously difficult EXPTIME-complete optimization problem compared to humans who have studied that one problem for their whole lives, starting in childhood."
Patricia
Arne Vajhøj - 17 Jun 2007 00:02 GMT > Yup. Computers can now routinely beat the best humans at chess and > code-optimization, and they're even getting somewhere with Go now. Obvious not since the humans could and should start by looking at the compiler generated code.
Arne
Arne Vajhøj - 17 Jun 2007 00:01 GMT > I discovered the Jet optimiser produces better code that hand tuned > assembler. See http://mindprod.com/jgloss/jet.html Since an assembler programmer could and should start by looking at compiler generated code, then that sentence does not make much sense.
Arne
Stefan Ram - 17 Jun 2007 00:17 GMT >Since an assembler programmer could and should start by looking >at compiler generated code, An assembler programmer does not do this on a regular base, just like a Java programmer does not code a GUI by looking at code generated from a GUI-builder (unless he has not got a clue).
Arne Vajhøj - 17 Jun 2007 00:19 GMT >> Since an assembler programmer could and should start by looking >> at compiler generated code, > > An assembler programmer does not do this on a regular base, > just like a Java programmer does not code a GUI by looking at > code generated from a GUI-builder (unless he has not got a clue). If the reason for using assembler is to make it run faster than compiler generated code - sure he will.
Arne
Arne Vajhøj - 17 Jun 2007 00:23 GMT >>> Since an assembler programmer could and should start by looking >>> at compiler generated code, [quoted text clipped - 5 lines] > If the reason for using assembler is to make it run faster > than compiler generated code - sure he will. Your GUI example is equivalent to looking at the generated code to get something that will assemble.
The equivalent GUI example of what I am talking about is to study other GUI's that people like to see what works and what does not work for GUI's.
Arne
Stefan Ram - 17 Jun 2007 00:41 GMT >If the reason for using assembler is to make it run faster >than compiler generated code - sure he will. Usually, manually crafted assembler /will/ be faster, even if the assembler programmer did not take a look at the compiler generated code before. Just by coding reasonable and knowing the machine.
At least, it used to be this way.
The whole point of Roedy was, that with Jet, the programmer now would need to read the Jet code indeed, in order to write faster code.
But this is something new. It did not used to be this way.
Martin Gregorie - 17 Jun 2007 13:24 GMT >> If the reason for using assembler is to make it run faster >> than compiler generated code - sure he will. [quoted text clipped - 5 lines] > > At least, it used to be this way. Back in the early '80s I wrote a lot of 6809 assembler before getting a PL/9 compiler. For the older hands, PL/9 was similar to PL/M. The PL/9 compiler was an integrated editor, compiler and source level debugger that ran in 32Kb of RAM, but I digress.....
The code it generated per statement was well optimized and was almost impossible to beat for size and speed. With care you could sometimes beat it by rewriting complete functions in assembler but usually the best you could do was to eliminate instructions that saved registers at the end of one statement and reloaded them at the start of the following statement.
IOW the hand optimization did little more than the keyhole optimizer that formed part of older C compilers - and PL/9 never claimed to be an optimizing compiler.
 Signature martin@ | Martin Gregorie gregorie. | Essex, UK org |
Roedy Green - 29 Jun 2007 16:49 GMT On Sun, 17 Jun 2007 13:24:37 +0100, Martin Gregorie <martin@see.sig.for.address> wrote, quoted or indirectly quoted someone who said :
>IOW the hand optimization did little more than the keyhole optimizer >that formed part of older C compilers - and PL/9 never claimed to be an >optimizing compiler. I have written lots of "perfect" X86 assembler code. By this I mean code sequences were fed to Michael Abrash's try ALL possibilities to get the same effect optimiser. I learned all kinds of X86 specific tricks.
X86 was designed for hand assembly. All works great if you put things in just the right magic registers. It is extremely non-orthogonal which must make life difficult for the automated optimisers. -- Roedy Green Canadian Mind Products The Java Glossary http://mindprod.com
Roedy Green - 29 Jun 2007 16:44 GMT >Since an assembler programmer could and should start by looking >at compiler generated code, then that sentence does not make >much sense. I suggest you go look at some of the Jet generated code and you will see why that is not feasible. The code becomes too fragile to maintain, and VERY complex.
For example a loop may be implemented as several variations on the same code with switching at the start to decide which one to use. You have not the patience for that degree of repetition in hand-coded assembler. -- Roedy Green Canadian Mind Products The Java Glossary http://mindprod.com
Arne Vajhøj - 04 Jul 2007 04:34 GMT >> Since an assembler programmer could and should start by looking >> at compiler generated code, then that sentence does not make [quoted text clipped - 8 lines] > You have not the patience for that degree of repetition in hand-coded > assembler. No one has said anything about it being practical to handwrite large apps in assembler.
But if they were to handwrite a certain piece of code, then they can always make it at least as fast as the compiler for the reasons described.
Arne
Roedy Green - 04 Jul 2007 14:19 GMT >No one has said anything about it being practical to handwrite >large apps in assembler. > >But if they were to handwrite a certain piece of code, then they >can always make it at least as fast as the compiler for the >reasons described. I challenge you then look at some Jet compiled code and see if you would have the patience to use it techniques even for small pieces. There is also the problem or readabilty and maintainability. -- Roedy Green Canadian Mind Products The Java Glossary http://mindprod.com
Patricia Shanahan - 04 Jul 2007 14:58 GMT >> No one has said anything about it being practical to handwrite >> large apps in assembler. [quoted text clipped - 6 lines] > would have the patience to use it techniques even for small pieces. > There is also the problem or readabilty and maintainability. In the 1980's and early 90's I was a hot-shot code tuner, using assembly language programming and detailed knowledge of the target hardware. I would monitor the main buses with a logic analyzer so that I could see what data accesses were happening when. I studied how the memory accesses interacted with refresh.
I gave up on that activity when optimizers got so good that I could have worked for weeks to squeeze out a percentage point, and had to produce totally unmaintainable code to get even that.
Patricia
Roedy Green - 04 Jul 2007 19:43 GMT >In the 1980's and early 90's I was a hot-shot code tuner, using assembly >language programming and detailed knowledge of the target hardware. I [quoted text clipped - 5 lines] >worked for weeks to squeeze out a percentage point, and had to produce >totally unmaintainable code to get even that. I had a similar experience. My magnum opus was a 32 bit forth than ran twice as fast anyone else's with every cycle tuned to death.
See http://mindprod.com/jgloss/benchmark.html
We were checking out just how various Java implementation were implementing a signum method. I discovered to my bafflement that Jet wrote better code than the best assembler I could come up with. The code was very clever, but hideous. You could never hand write and hand maintain it. -- Roedy Green Canadian Mind Products The Java Glossary http://mindprod.com
Arne Vajhøj - 04 Jul 2007 21:51 GMT >> No one has said anything about it being practical to handwrite >> large apps in assembler. [quoted text clipped - 6 lines] > would have the patience to use it techniques even for small pieces. > There is also the problem or readabilty and maintainability. You don't seem to get the point.
Any assembler programmer (capable of using a disassembler) can make his assembler code as fast as the compiler.
Whether there are any benefits from using assembler or not is irrelevant.
Arne
Roedy Green - 04 Jul 2007 22:05 GMT >Any assembler programmer (capable of using a disassembler) can >make his assembler code as fast as the compiler. In principle yes, in practice no. -- Roedy Green Canadian Mind Products The Java Glossary http://mindprod.com
Boris Stumm - 04 Jul 2007 09:49 GMT [...]
> So why is the Java program in the following benchmark still > slower than the C++ program? [...]
> C++ 6,75 main1/s > Java 4,67 main1/s Have you tried Java with the -server switch? Reduces runtime on my PC from ~24ms to ~18ms, using Java 6.
Free MagazinesGet these publications absolutely FREE for up to 12 months. There are no hidden fees and no obligation. Simply choose a title, complete the application form and submit it. Read more ...
|
|
|