[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
Re: Clause 10, Expression Evaluation
William Clodius wrote:
Thorsten Siebenborn <7_born@xxxxxx> wrote:
Malcolm Cohen schrieb:
Thorsten Siebenborn <7_born@xxxxxx> wrote:
<snip>
To compare speed, it is necessary to benchmark programs written
in the languages to compare. And there is a saying: Lies,
damn lies, benchmarks.
[Examples]
All very true and then ignored in the following.
Nope.
The easiest claim would be: All "Volvo" languages are inferior in terms
of speed against "Porsche" languages. But:
http://shootout.alioth.debian.org/gp4/benchmark.php?test=all&lang=g95&lang2=ocaml
Fortran G95 is in this test slower than OCaml, the deterministic
language. *Much* slower. OCaml is in the top ranking together with gcc.
Does it prove that OCaml is faster than FORTRAN in general ? No.
And I am not interested in exchanging the typical bickering of
how-fast-my-favored-language-is.
But it also proves that the claim that determisitic languages
are always slower is not true.
Strawman. That is NOT the claim of interest to Malcolm, or I hope,
this standards committee.
That is EXACTLY the claim.
As Malcolm said it: "FORTH doesn't allow PORSCHES, it only allows
VOLVOS". There is no misreading in that.
As I already told Nick, I have no problem with Malcolms comment that
non-determistic behaviour of compiling the source code to optimize
speed is very likely to gain speed. Malcolms oversimplification that if
a language enforces deterministic compiling (strict evaluation order)
is *automatically* slow (Volvo) compared to other languages who allow
non-determistic optimization was attacked, nothing else.
This is reinstated im my mail from 2007,June 12th, 15:39.
The history:
David Hough suggested source code reproducibility by strict
evaluation order. Malcolm said that it isn't useful because
fast running code requires optimization which defeats the given
evaluation order in the source code.
(subconsicously assuming that it is a necessary prerequisite).
I answered that contrary to his claim there are languages who
can guarantee that debug mode will execute exactly as the
optimized version and this is extremely useful for debugging.
Malcolm answer was: Fine, but then the language must be slow
to do that. That is the situation when I wrote my answer.
The claim is that an optimal implementation of non-deterministic
FLOATING POINT semantics will provide significant performance gains
on APPROPRIATE code, compared with an optimal implementation of
deterministic floating point.
Please cite one passage in my former mails which tries to
refute this alleged claim. I don't think your search will be
successful (because I thought it correct before).
Several people, including Malcolm, have provided detailed arguments
as to why this should be true. They have also argued that experience
has not only validated this argument,but indicated that the gains
are often significant. In particular I suspect the simple test of
turning determinism on an off for a given compiler processing a
given code would confirm this, for appropriate code (any citations
for this?).
But we are not talking about compiler switches. We are talking
about different languages, even different kinds of problem
approaches (functional, imperative).
[Discussion of benchmark result OCaml-Fortran on home computer].
First of all, the benchmark does not allow optimization because
it is the intent of the site to roughly compare languages, not
the skill of the optimizers in their language. So they allow only
"Average Joe" code with putting the weight on clarity and
readability. As said before on the beginning: Benchmarks are
inherently unfair.
And in this case Fortran is often defeated. If you may optimize
your code and use the state-of-the-art compiler, you may shift
Fortran to the first place. But that requires work *and* skill !
I attack the notion that anything in Fortran will run like
greased lightning (Porsche) compared to determistic-languages
-molasses (Volvos). Nothing more, but nothing less.
Ok,you may rant that you are talking about number crunching with
parallel processors and supercomputers where only FORTRAN is
an option. Well, I will answer to that later.
Rephrase: Malcolm, you may rise the point that benchmark
comparisons on home computers are pointless because you are
talking about heavy-duty number crunching on parallel processors
and supercomputers. And in that case you may think Fortran is
the only option. Let me first talk before you write a long reply; I am
aware of this counterargument.
So I haven't really claimed anything in my message; it is not
a proposition. There is no point to argument against it.
Ad hominem. I would not characterize Malcolm's response as ranting,
and, even if it were, it is not germane to the issue.
"you may rant" indicates the possibility that my answer triggers a
rant, but it doesn't state that Malcolm is ranting *now*. (see PS
down)
Error of fact. Malcolm knows that more than Fortran is available for
floating point processing as an option for those systems. Typically
C, C++, and Ada are available, if only as part of the gcc system.
I exaggerated a bit by stating that Fortran may be the only option in
Malcolms mind. I agree that it gives an incorrect impression, so sorry
for that.
Error of fact. That performance gains are only for those
systems. Memory hierarchies in todays desktops have affects on
performance similar to that of the hierarchies of the supercomputers
of ten to twenty years ago.
Strawman. I read this (and the following) as implying that only new
code is of interest to this committee. The committee should be
concerned about the effects of running old code on processors with
the 754r functionality.
Again, it is not a proposition.
Malcolm started his claim with ">>Furthermore<<,
it is not useful".
Obviously I didn't start anything with "Furthermore".
Reread your statement.
When someone challenges a quote chances are he has it right. Your
response was actually posted as a response to a message by Nick
MacLaren who did use the word "furthermore" followed by something
that (roughly) implies "it is not useful". Malcolm Cohen did not.
Read the answer of Malcolm Cohen to David Hough on the list; dated
July 12th [from time] 13:47:00 with the message ID:
<200707120215.l6C2FC83043320@xxxxxxxxxxxxxxxxxx>
Please cite the 27th line.
So the inherent inability of FORTRAN [citation shortened]
to come up with a strict evaluation order is apparently not the
reason he came up with this image.
The reference to "inability" is an error of fact. Fortran could
decide on an evaluation order, without changing the "defined"
semantics of existing code, but has chosen not to for performance
reasons. Similarly a Fortran implementation could impose defined
semantics, and some provide that as an option. Further some
implementations of languages with deterministic floating point
semantics have the option of compiling with limited forms of
non-determinism.
For high performance, requiring a strict evaluation order is
counter-productive! I don't see anything difficult to understand
there.
Fine that I have understood it correctly.
but stating it as an "inability" rather than a "choice" was incorrect.
That's true.
Are people inherently unable to walk from South Africa to Siberia ?
No, it is possible, therefore incorrect.
Is BASIC inherently unable to calculate eigenvalues of 1000x1000
matrices ?
No, it is possible, therefore incorrect.
Are boats inherently unable to use concrete as building material ?
No, it is possible, therefore incorrect.
If you apply such a strict standard, then most of my writings are
incorrect.
Fortran "could" decide on an evaluation order, but most implementations
does not support it, right ?
Your statement is effectively:
"I am a compiler writer. If I am enforced to slavishly imitate
the deterministic behaviour of my source code during run time,
I cannot write *really* fast programs. All other languages who
show this deterministic behaviour must be slow; there is no way to
bypass it. So I can safely compare determistic languages with
Volvos and my language with a Porsche."
Beware of putting words in other peoples mouth. You are not a mind
reader. I don't think Malcolm has argued from the authority of being
a compiler writer, though he is one. Instead he has argued on
technical merits using knowledge he has gained partly from being a
compiler writer. [Thinking what Malcolm could have meant].
As you are not a mind reader, too, it is uncertain if
your interpretation is more correct than my interpretation.
Well, it may be true for *imperative* languages like FORTRAN, but
it is perhaps not true for *functional* languages like OCaml
or Sisal. Sisal is a determistic language which is
capable to run as fast as optimized FORTRAN on supercomputers.
James R. McGraw has written an interesting paper named
"Parallel Functional Programming in Sisal: Fictions, Facts
and Future", Advanced Workshop: Programming Tools for Parallel
Machines, July 1993.
In this he ran Sisal solutions against FORTRAN ones on a Cray
YMP/864. While in single processor mode FORTRAN was faster, it
looses dramatically against Sisal during multi-processor mode.
He also explains what he is doing in the first-place so that
Sisal can achieve its speed.
Note there was a better known, slightly latter article in
Communications of the ACM. That article was discussed several times
when Malcolm followed comp.lang.fortran in detail. Are you certain
that the code generated by Sisal consistently imposed deterministic
floating point semantics?
p. 5:
"The semantics of the language enforce determinate execution behavior."
"The language definition precisely defines the result of every legal
Sisal program, including the specific ordering of all arithmetic
operations."
On page 22, McGraw iterates that results in Sisal are determinate.
FWIW during most of Sisal's active period it relied on C code
compiled using gcc, gcc was largely a K&R compiler, and K&R C had
looser floating point semantics than Fortran and C89. Note also that
there is a reason funding for Sisal stopped shortly after that paper
was written. For whatever reason, people (even at LLNL) were not
adopting Sisal instead of Fortran, although Sisal was available for
several years before funding stopped. At that time, those who left
Fortran largely went to C and C++, both of which largely have the
same non-deterministic semantics for floating point code. FWIW when
there are many languages claiming to be better, most people look
only at the better known ones.
Could be simply the avoidance of functional languages. Paul Graham,
(www.paulgraham.com) known LISP advocate, is talking his mouth blue
about the advantages of LISP over other programming languages.
C++ is bad, Java is garbage etc. He is right that people are more
powerful with Lisp and that for almost all normal applications
Lisp is good enough.
But people don't use Lisp. They simply don't use it.
I can send the paper on interest.
Are you the copyright holder, or are you certain of the distribution
restrictions imposed by the copyright holder?
"Distribution of this document is unlimited".
You can get it personally by
http://www.osti.gov/energycitations/purl.cover.jsp?purl=/10192282-4qoMxp/
Anyway, German law is very open about the use of scientific papers for
private use. I don't know how the situation in Anglo-Saxon countries is.
Regards,
Thorsten
PS:
That is a common misunderstanding between ad hominem and
(perceived) derogatory remarks and insults. Ad hominem means that
something is wrong by a) giving the impression that the person
lacks something in quality which negates his arguments (e.g. "mad")
or b) has a certain viewpoint ("leftist") or c) does something
against his own stated beliefs ("tu quoque").
If someone calls me "cheapskate", it is insulting, but not
necessarily an ad hominem because cheapskates could have perfectly good
arguments. But if someone indicates that I am an idiot/are talking
drivel/I am mad/etc. which should give the impression that my
conclusions are invalid or treat me with scorn/ridicule/contempt
to dismiss me, yes, that would be an ad hominem.