Ground Up

[Hal Daume III]

Unfortunately I think I have to take issue with this statement :).

> Therefore, don't worry about this point. A haskell-user doesn't
> need to know the details of the haskell compiler ins and outs.

I think that at the beginning, a huser doesn't need to know the ins and
outs, but from personal experience, the more complicated your programs
become, and the more you begin worrying about speed, the more you need to
know about the compiler.  Personally, I find this quite aggrevating and I
think it is one of the least often expressed disadvantages to Haskell.  I
can see arguments against me immediately, so I'll save you time.

For instance, you could argue that it is easier to get "up and
running" (well, more like walking in Haskell) in Haskell than say C.  I
would probably agree.  But lets say it comes time to fine tune my
program.  In C I have (admittedly made up example, but see my recent post
the the mailing list on this subject):

void sumProdTo(int n, int*s, int*p) {
  int sum = 0;
  int i;
  for (i = 1; i <= n; i++)
    sum += i;
  &s = sum;
  int prod = 1;
  for (i = 2; i <= n; i++)
    prod *= i;
  &p = prod;
}

and in Haskell:

sumProdTo n = (sumTo n, prodTo n)
  where sumTo 1 = 1
        sumTo n = n + sumTo (n-1)
        prodTo...

etc.

Now, I want to optimize.  In C, I can fuse the loops so I'm only
traversing once, which would give me moderate speed improcement.  In
Haskell, I could also "fuse" the loops and say:

sumProdTo 1 = (1,1)
sumProdTo n = (n+s,n*p)
    where (s,p) = sumProdTo (n-1)

but this is actually *slower* but there's no way for me to know this
without actually running it.  in fact, in the discussion about this on the
list, no one was really able to give a definitive answer as to why.  there
was a lot of handwaving about pointers to the heap to pointers to other
things, and obviously it has to do with boxing and unboxing and stuff like
that, but I think this is a problem.

i'm not sure what the moral is.  obviously, each of these, in theory,
could have equal speed given a good enough optimizing compiler (and,
perhaps, no issues of undecidability).  however, since in C it's much more
clear exactly what is happeneing, you know when you write your code that
one thing is going to be faster than another (except when you get to uber
complex things when you're worrying about cache sizes, etc, but that's out
of the scope of this -- you could never even try to worry about something
like that in haskell).

i think the only real solution would be to put up a web page or something
that contains things like "this looks like it would speed up your program
but it will actually slow it down."  or at least some better tips on
getting your programs to run quickly.

okay, i'm done.  that's not to discourage the original poster to learn
haskell - i use it almost exclusively; it's just that i don't think it's
fair to say you don't have to understand what the compiler is doing to
write code.

 - hal

--
Hal Daume III

 "Computer science is no more about computers    | hdaume@isi.edu
  than astronomy is about telescopes." -Dijkstra | www.isi.edu/~hdaume

On Thu, 28 Feb 2002, Rijk J. C. van Haaften wrote:

> Jerry wrote
> 
> >However, my problems are:
> >* I still don't understand most of the codes I found, like the various
> >   haskell libraries
> Practice is the only answer to this problem, as Keith Wansbrough says.
> 
> >* I still have no clue of most (ok, almost all) of what is being
> >   discussed in this mailing list
> Though I am a CS student, being highly interested in Haskell and
> practising a lot, I didn't understand most of the discussions on
> this mailing list.
> I started understanding them only after I got involved in implementing
> a Haskell compiler.
> 
> Rijk-Jan van Haaften
> 
> _______________________________________________
> Haskell-Cafe mailing list
> Haskell-Cafe@haskell.org
> http://www.haskell.org/mailman/listinfo/haskell-cafe
>