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