Re: Glasgow haskell vs. Lispworks

Markus E L wrote:
Jon Harrop wrote:
Compilers should only do semantics preserving transformations. This
means that if a language designer chooses to support physical
equality, then they should not also co code transformations that are
only correct in its absence. If the language designer chooses not to
support it, more optimizations become valid.

This is exactly the kind of overly theoretical angle that I was
describing. There is certainly a remit for this kind of pedantry but I
see no merit in trying to impose it upon everyone.

This, excuse me, is nonsense, Jon. Building compilers is a discipline
thoroughly rooted in theory.

Sure. Compilers (that get used) are also thoroughly rooted in practical
matters like money.

If we'd all argued like you do now, we'd
still be programming in assembler or use gotos ("the equivalence of
gotos with block structured programming and the harmfulness of goto
'is exactly the kind of overly theoretical angle that I was describing
There is certainly a remit for this kind of pedantry but I see no
merit in trying to impose it upon everyone.'").

:-)

Bah, absolute rubbish. :-)

How many languages even have formally-defined semantics that a compiler must
adhere to by only making "semantics preserving optimizations" as Neel
claimed? Either "none" or you have to redefine "semantics" to "whatever the
previous version of the compiler did" exactly as Neel did.

What merit is there in deriving a proof about semantics only to leave the
definition of semantics itself up in the air?

And mind you, we're writing on c.l.l. here: Functional languages
basically have been invented to "do semantics preserving
transformations". This usually goes under the heading of "referential
transparency" and "equational reasoning", but I'm strongly convinced
it is what the compiler should do and should be able to do to automate
programm optimization. At the end of the day (which we haven't reached
yet) I do only want to specify the data flow and the compiler should
figure out how to do it (i.e. the exact sequence of operations). That
means: I want to use a pure functional language.

And WRT to your dislike of Haskell:

I like Haskell. I dislike silly claims.

I think, in the long run this is
the way to go. As Rainer Joswig already stated in the static typing
debate performance is not all for most applications (number crunching
being an exception so I'm not surprised that you chose ray tracing as
a benchmark) CPU power being cheap, readily avilable and mostly idle
these days.

In the context of my ray tracer, which is most interesting:

1. Haskell provides more opportunities for semantics-preserving
optimizations done by the compiler.

2. Despite best efforts, Haskell remains 3x slower on this benchmark in
practice.

In the context of suffix trees, which is most interesting:

1. Haskell provides more opportunities for semantics-preserving
optimizations done by the compiler.

2. Idiomatic Haskell is 100x slower than C in practice.

In the context of Intel's C++ compiler, what would their marketing
department rather hear:

1. The new version preserves the behaviour of programs that had undefined
behaviour.

2. The new version implements tail call optimization and runs some programs
much faster even though a running program could detect that this
optimization has been made.

All of these points boil down to which is more important:

1. Haskell is fast in theory.

2. Haskell is slow in practice.

Automatic transformation of code, maintainability and
checkability of code or at least parts is important, though, and I can
imagine that being easier in the pure case (if one has only to check
the integrity of the data flow).

Only if you gloss over the obfuscation introduced by shoehorning all
solutions into the purely functional paradigm and then neglect all of the
extra work required to regain the lost performance.

In reality, purely functional programming is a nice option to be able to
choose with minimal sacrifice but it is not a panacea.

--
Dr Jon D Harrop, Flying Frog Consultancy
OCaml for Scientists
http://www.ffconsultancy.com/products/ocaml_for_scientists/?usenet
.

Relevant Pages

  • Re: [EGN] Numerical Accuracy
    ... The advice worked because in fact the Microsoft compiler had a bug. ... The capabilities of the optimizer are not so ... The language standard itself says ... of "programming" as a nonprofession. ...
    (comp.programming)
  • Re: Brian Kernighan, maybe Im not worthy, maybe Im scum
    ... and just hone in on the stuff related to programming and this newsroup] ... moron that was taken from optimization which does hoist when to do so ... compiler design and optimization, including my 1976 text in graduate ... loop in a language in which the designers messed up, ...
    (comp.programming)
  • Re: Javas performance far better that optimized C++
    ... The compiler is extremely stupid. ... no memory leaks are guaranteed. ... However I have GC in my .NET programming. ... "C.9.1 Automatic Garbage Collection ...
    (comp.lang.cpp)
  • Re: Is C99 the final C? (some suggestions)
    ... This would violate the division between preprocessor and compiler too ... much (the preprocessor would have to understand quite a lot of C semantics). ... ...This is legal C (as per the Standard), but it overflows the stack on ...
    (comp.lang.c)
  • Re: Aspiring highest-order programmer
    ... book", Sherman's Programming and Coding for Digital Computers, was ... an IBM 7094 running IBSYS as an OS and with a Fortran compiler. ... Thus today I am confident that computer science students learn "all ... > long, very long, and not exactly focused on NP completeness). ...
    (comp.programming)