Re: [Gnu-arch-users] Re: darcs vs tla

[Andrew Suffield]

On Tue, Nov 09, 2004 at 06:54:02PM +0000, Kannan Goundan wrote:
> 
> > That sort of thing is why darcs is slow. Optimising Haskell programs
> > is more or less equally difficult as optimising C programs (functional
> > languages are not inherently any easier or harder to optimise), and
> > the problems are pretty much the same. tla even has analogous issues
> > (it tackles this problem differently, and I think does a little
> > better in the amortised case, but it's far from optimal).
> 
> Since Haskell is, in a way, more strict and more restrictive, wouldn't it be
> easier for a compiler to optimize Haskell programs (since the code is bounded 
> by
> stronger guarantees)?

Mmm. Sort of.

It is easier for a Haskell compiler to perform a wide range of common
optimisations, including all the ones that matter, on Haskell programs
than it is for a C compiler to perform the same operations on a C
program.

> Dealing with side-effects and aliasing is a major pain
> for C compilers.

Haskell doesn't have any real advantages here; these particular
problems don't exist but parallel ones do.

Also, the semantics of C permit a sufficiently intelligent compiler to
generate slightly more efficient code than an equivalent Haskell one,
on the order of 5-10%, simply due to overheads demanded by the
language. Not that any real-world compilers are up to that level.


However, that is no substitute for source-level optimisations which a
compiler cannot perform, and these are the ones I was referring
to. Most real-world performance problems fall into this class nowadays
- compiler improvements will never again give you an order of
magnitude gain in real-world performance, with current languages and
excluding pathological cases[0] (there are still worthwhile gains to be
had from improving the compiler, because it increases the value of
your hardware, but it won't solve your performance problems). This
sort of optimisation doesn't get any easier to do in Haskell; in fact,
we haven't yet found any language where they are easier.

[0] Pathological cases here include any which break existing
    optimisations or which tickle obscure hardware behaviour unless
    the compiler explicitly allows for them. These are classified as
    bugs in the compiler. gcc has a whole pile of these. Backends
    which nobody has bothered to finish implementing don't count
    either (ia64, gcc currently utilises less than half the
    instructions this monster of a processor has available).

-- 
  .''`.  ** Debian GNU/Linux ** | Andrew Suffield
 : :' :  http://www.debian.org/ |
 `. `'                          |
   `-             -><-          |

signature.asc
Description: Digital signature