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

Re: Clause 10, Expression Evaluation



Malcolm Cohen schrieb:
Thorsten Siebenborn <7_born@xxxxxx> wrote:
I have attacked the image that it is impossible to test a Volvo
for testing a Porsche.

Maybe it would be better to think about my analogies instead
of blindly attacking them.

I have thought about your analogy. And every
possible understanding told me: Something is amiss.

I say: Translated in computer languages there
*are* Volvos which can be tested to verify that the Porsche
will function.

Well, since it's my analogy, I have to say that's just wrong.

No.

According to your description of FORTH, in the terms of my rather
simple analogy, FORTH doesn't allow PORSCHES, it only allows VOLVOS.
That's fine for FORTH, but has little to do with my comment.

That's heading in the direction of "There are slow languages and
there are fast languages. Fortran is fast, FORTH/Ocaml etc. not."

To compare speed, it is necessary to benchmark programs written
in the languages to compare. And there is a saying: Lies,
damn lies, benchmarks.

Which processor is used ? It is a single processor or multiple
processors ? Which compiler is used and how good are the implementors
of the compiler ? How proficient is the programmer in the language
and how good in knowing the details of optimization ? How much memory
is needed for the instructions (Can the program be hold in cache memory
and therefore be executed much faster ?).

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.

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.

And I added that these specifics Volvos are able
to use tools which are extraordinarily useful.

Let's not stretch analogies too far.  Volvos don't "use tools".

I didn't come up with this particular image.

Malcolm started his claim with ">>Furthermore<<,
it is not useful".

Obviously I didn't start anything with "Furthermore".

Reread your statement.

So the inherent inability of FORTRAN

You what?

??

to come up with a strict evaluation order is apparently not the
reason he came up with this image.

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.

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."

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.

I can send the paper on interest.

Regards,
Thorsten

754 | revision | FAQ | references | list archive