Ground Up

[Jay Cox]

First off, let me say that I'm not near the expert that Simon Peyton
Jones, Simon Marlow, John Hughes (Related to Sarah the olympic gold
metalist? No probaby not.) and many, many others on these haskell lists
are.  I think many of those experts have Masters or PhD Degrees relating
to the subject.  (I wouldn't mind earning one myself!)  I just came upon
this language (through some help with another person on this list), found
it to be exteremely expressive and orthogonal in design, and frankly, fell
in love with it.

Now then:


On Thu, 28 Feb 2002, Hal Daume III wrote:

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

well, your arguments can be applied to any high level language.  (That's
kinda the point.)  I do wish there were more to help the user learn more
about details of compiler and optimization techniques and such, (like what
about these rewrite rules? How would one (sanely) write them? Does Haskell
implement any kind of deforestation? How about this strictness analysis
business) But part of the problem, I think, is we dont have a concise,
well developed set of rules and when to apply them.  That's part of the
research that's going on.

<snip>

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

yes, but then again, you could probably say same kinds of statements about
C (because perhaps for some code A the compiler might be smart enough to
allocate a register for a variable, etc. but for other code B, the rule of
thumb that was fired for the first code doesn't fire for B.  No, I can't
give examples since I am not a C compiler expert either.)


> 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've heard of times when some C (that or C++) compiler  might inline and
partially execute code when using optimization flags.  (point being you
may not know what's going on with that compiler either)


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

I guess that's what the Haskell Wiki is attempting to do.  We do need some
central repository of haskell information, tips, and the like, I agree.
Is the Haskell Wiki what everybody agrees upon?


Jay Cox