Re: Java is slower than C++!
Andrew Thompson
..
>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++)
--
Andrew Thompson
http://www.athompson.info/andrew/
Message posted via JavaKB.com
http://www.javakb.com/Uwe/Forums.aspx/java-general/200706/1
Tom Hawtin
>
> 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
Mark Space
> "Andrew Thompson" <u32984@uwe> writes:
>>> java.lang.System.out.println(( dt / 1000 / 1000 )+ " ms" ); }}}
>>> 358 ms
>> Wow! You must be running an old processor!
>
> 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.
>
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)
Daniel Dyer
wrote:
> Stefan Ram wrote:
>> 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).
...
> 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.
--
Daniel Dyer
http//www.uncommons.org
Kai Schwebke
> 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
Paul Tomblin
> 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.
--
Paul Tomblin <ptom...@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
> In a previous article, r...@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.
Or he has sense of humor !
Arne
Tom Hawtin
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
Lew
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.
--
Lew
Lew
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
--
Lew
Daniel Dyer
> 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.
Lew
> Lew <l...@lewscanon.nospam> wrote:
>
>> 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.
$ 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 . . .
--
Lew
Steve Wampler
> 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
--
Steve Wampler -- swam...@noao.edu
The gods that smiled on your birth are now laughing out loud.
Roedy Green
quoted or indirectly quoted someone who said :
> 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
wrote:
> On 9 Jun 2007 13:33:21 GMT, r...@zedat.fu-berlin.de (Stefan Ram) wrote,
> quoted or indirectly quoted someone who said :
>
> > 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
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
news:1181448634.3...@p77g2000hsh.googlegroups.com...
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
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.
Patricia Shanahan
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
Lew
>> 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.
--
Lew
Luc The Perverse
news:7M-dnbKstM9IZ_bb...@comcast.com...
Thanks guys!
I will try google next time.
--
LTP
:)
Twisted
> 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.
*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
ridiculous to even try to google for "Ant", and it was in this very
newsgroup (comp.lang.java.programmer).
Karl Uppiano
"Lars Enderin" <lars.e...@gmail.com> wrote in message
news:466C6774...@gmail.com...
> 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.
Lew
>> that link was the second major hit.
Twisted wrote:
> 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.
--
Lew
Twisted
> "Lars Enderin" <lars.ende...@gmail.com> wrote in message
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
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
>> *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
>> Not looking good.
>>
>> 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.
--
Lew
Luc The Perverse
news:tE2bi.2541$wL5.204@trndny04...
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
<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.
Arne Vajhøj
> 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
Arne Vajhøj
> 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
> Arne Vajhøj <ar...@vajhoej.dk> writes:
>> Since an assembler programmer could and should start by looking
>> at compiler generated code,
>
> 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
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
Martin Gregorie
> 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.
>
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.
--
martin@ | Martin Gregorie
gregorie. | Essex, UK
org |
Roedy Green
wrote, quoted or indirectly quoted someone who said :
>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
<mar...@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.
Arne Vajhøj
> On Sat, 16 Jun 2007 19:01:01 -0400, Arne Vajhøj <ar...@vajhoej.dk>
> wrote, quoted or indirectly quoted someone who said :
>
>> 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.
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
Boris Stumm
[...]
> 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.
Roedy Green
wrote, quoted or indirectly quoted someone who said :
>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.
Patricia Shanahan
> On Tue, 03 Jul 2007 23:34:26 -0400, Arne Vajhøj <ar...@vajhoej.dk>
> wrote, quoted or indirectly quoted someone who said :
>
>> 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.
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
wrote, quoted or indirectly quoted someone who said :
>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.
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.
Arne Vajhøj
> On Tue, 03 Jul 2007 23:34:26 -0400, Arne Vajhøj <ar...@vajhoej.dk>
> wrote, quoted or indirectly quoted someone who said :
>> 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.
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
wrote, quoted or indirectly quoted someone who said :
>Any assembler programmer (capable of using a disassembler) can
>make his assembler code as fast as the compiler.
In principle yes, in practice no.