February 2006 - Haskell-prime

RE: Test performance impact (was: The dreaded M-R)
by John Hughes 02 Feb '06

02 Feb '06

Summary: 2 programs failed to compile due to type errors (anna, gg). One program did 19% more allocation, a few other programs increased allocation very slightly (<2%). pic +0.28% +19.27% 0.02 Thanks, that was interesting. A follow-up question: pic has a space bug. How long will it take you to find and fix it? And how come speed improved slightly in many cases--that seems counter- intuitive. Let me make clear that what concerns me is not the impact of the M-R on space and time performance on average. What concerns me is the difficulty of debugging performance problems. Even if we Haskell programmers usually consider correctness first and performance later, when we want to actually use our beautiful code, we need to find and fix at least the worst performance problems. At that point, I'm reading the code and trying to understand--with the help of profiling tools--why it performs the way it does. I need the performance behaviour of the code to be *obvious*. When I pull out a common sub-expression into a let-binding, I want to *know* that it will be evaluated at most once. When I see a collection of variable bindings, likewise, I want to *know* that they are computed once only. When I see a seq on such a variable, I want to *know* that any pointers in its unevaluated form are thereby dropped. When I introduce or remove overloading in a function definition, I want to *know* that I have not thereby changed the sharing properties of a variable binding somewhere else, potentially introducing a space or time leak. I want to know these things by looking at the code in front of me, not by running the compiler with the right flags and reading its warning messages. Unexpected behaviour at this point is a trap, that can lead to many wasted hours as one reads the same code again and again, assuming it behaves as expected, only to eventually convince oneself, by long examination of profiles, that it cannot be doing so. If the unexpected behaviour is rare, that only means that when it *does* happen, it will take all the longer to find and fix. I find languages with such traps intensely frustrating to work with. If I can't even tell, *by reading it*, what my code means, then what hope have I got? There are plenty who will argue, quite reasonably, that lazy evaluation in itself makes understanding performance behaviour unreasonably difficult; that strict languages should be preferred because the space and time behaviour is much more obvious. I don't agree, because I find the software engineering benefits of lazy evaluation to be so large, that it's worth the cost in making performance reasoning more difficult --but I accept there is a trade-off there. I don't see benefits on anything like the same scale from dropping the M-R. Today's M-R has the merit that it at least makes it evident, in the code, where sharing may be lost. It's often a minor irritant, occasionally a bit more than minor. Were it to be removed with no replacement, then the irritation would go away, and the signs are that most of the time, performance would not change much. But occasionally--just occasionally--there would be a space or time bug caused by loss of sharing *somewhere* in a large body of code, and searching for it, we would descend into nightmare. I'll put up with the irritation any day, to be sure of being spared the nightmare. John

3 2

kind annotations
by S.M.Kahrs 02 Feb '06

02 Feb '06

It doesn't have a ticket yet, but I would propose that kind annotations were adapted. I have been bitten on a couple of occasions (working with HO type variables) by kind inference putting my type vars into *, and although there is usually a work-around, it is usually mesmerisingly ugly. Stefan

4 4

RE: The dreaded M-R
by Simon Marlow 02 Feb '06

02 Feb '06

On 31 January 2006 17:48, Andrew Pimlott wrote: > On Tue, Jan 31, 2006 at 10:17:57AM -0000, Simon Marlow wrote: >> On 30 January 2006 21:49, Andrew Pimlott wrote: >>> In the present case, people aren't (only) opposing the M-R out of >>> principle, but because they actually use overloaded variable >>> definitions and (at least sometimes) want to leave off the >>> signature. >>> >>> So I don't see how one could claim, as on the wiki, the warning >>> "wouldn't happen much". I suspect it would happen, and annoy >>> people, and defeat the reason that people want to remove the M-R. >> >> The assertion that it "wouldn't happen much" is based on the >> observation earlier in this thread that it was actually difficult to >> write some code that illustrated the problem. > > This indicates that the warning "wouldn't happen much" _when you want > sharing_. But it would happen all the time when you don't want > sharing, eg. in the case Malcolm Wallace just posted. So you either add a type signature, or turn off the warning. What's the problem? I suspect you're saying that you don't want a warning by default, and you don't want the langage to recommend that compilers issue a warning by default, right? If so, your objection is duly noted and I'll add the point to the wiki. Cheers, Simon

2 1

ClassMethodTypes
by Ross Paterson 02 Feb '06

02 Feb '06

As I read it, the POPL'05 paper cited by the wiki page asserts that there is a problem, but does not explain what it is. Is there a better reference?

2 1

RE: Test performance impact (was: The dreaded M-R)
by Simon Marlow 02 Feb '06

02 Feb '06

On 01 February 2006 11:42, Nils Anders Danielsson wrote: > However, to stand on more solid ground I suggest that someone runs > some performance tests, with and without > -fno-monomorphism-restriction, to see whether the M-R has any great > impact in practice. There are some performance test suites based on > real code out there, right? Nofib? Results below (ignore runtime differences, I was averaging over 5 runs but most of these benchmarks run too quickly to get any reasonable measurements). Summary: 2 programs failed to compile due to type errors (anna, gg). One program did 19% more allocation, a few other programs increased allocation very slightly (<2%). ------------------------------------------------------------------------ -------- Program Size Allocs Runtime ------------------------------------------------------------------------ -------- anna ----- ----- ----- ansi +0.00% +0.00% 0.00 atom +0.00% +0.00% -2.92% awards +0.00% +0.00% 0.00 banner +0.00% +0.00% 0.00 bernouilli -0.23% +0.00% -7.44% boyer +0.00% +0.00% 0.00 boyer2 +0.00% +0.00% 0.01 bspt +0.00% +0.00% 0.02 cacheprof +0.14% +0.00% -9.86% calendar +0.00% +0.00% 0.00 cichelli +0.00% +0.00% +0.99% circsim +0.00% +0.00% -0.93% clausify +0.00% +0.00% 0.01 comp_lab_zift +0.00% +0.00% +1.86% compress +0.00% +0.00% -5.58% compress2 +0.00% +0.00% -7.63% constraints +0.00% +0.00% -9.03% cryptarithm1 +0.00% +0.00% -6.27% cryptarithm2 +0.00% +0.00% 0.03 cse +0.00% +0.00% 0.00 eliza +0.00% +0.00% 0.00 event +0.00% +0.00% -7.04% exp3_8 +0.00% +0.00% -10.84% expert +0.00% +0.00% 0.00 fem +0.35% +1.76% 0.06 fft +0.00% +0.00% 0.08 fft2 +0.00% +0.00% 0.15 fibheaps +0.00% +0.00% 0.08 fish +0.00% +0.00% 0.03 fluid +0.12% +0.04% 0.02 fulsom -0.14% +0.00% -2.10% gamteb +2.47% +0.56% 0.15 gcd +0.00% +0.00% -5.88% gen_regexps +0.00% +0.00% 0.00 genfft +0.00% +0.00% 0.04 gg ----- ----- ----- grep +0.00% +0.00% 0.00 hidden +0.00% +0.00% -12.48% hpg +0.00% +0.00% -7.92% ida +0.00% +0.00% -12.50% infer +0.00% +0.00% 0.13 integer +0.00% +0.00% -9.81% integrate +0.00% +0.00% -5.47% knights +0.19% +0.00% 0.01 lcss +0.00% +0.00% -7.42% life +0.75% +0.00% -16.22% lift +0.00% +0.00% 0.00 listcompr +0.00% +0.00% -9.76% listcopy +0.00% +0.00% -8.33% maillist +0.00% +0.03% 0.06 mandel +0.00% +0.00% +0.00% mandel2 +0.00% +0.00% 0.02 minimax +0.00% +0.00% 0.01 mkhprog +0.00% +0.00% 0.00 multiplier +0.00% +0.00% -10.43% nucleic2 +0.61% (stdout) (stdout) para +0.00% +0.00% -2.51% paraffins +0.00% +0.00% -10.07% parser +0.00% +0.00% 0.06 parstof +0.00% +0.00% 0.01 pic +0.28% +19.27% 0.02 power +0.29% +0.00% -11.62% pretty +0.00% +0.00% 0.00 primes +0.00% +0.00% 0.13 primetest +0.00% +0.00% +0.77% prolog +0.00% +0.00% 0.00 puzzle +0.00% +0.00% -5.03% queens +0.00% +0.00% 0.06 reptile +0.00% +0.00% 0.03 rewrite +0.00% +0.00% 0.00 rfib +0.00% +0.00% 0.04 rsa +0.00% +0.00% 0.06 scc +0.00% +0.00% 0.00 sched +0.00% +0.00% 0.05 scs +0.54% +0.06% -11.14% simple +1.70% +0.00% -4.68% solid +0.00% +0.00% -2.03% sorting +0.00% +0.00% 0.00 sphere +0.06% +0.00% -1.74% symalg +0.00% +0.00% 0.13 tak +0.00% +0.00% 0.02 transform +0.00% +0.00% -7.73% treejoin +0.00% +0.00% -2.70% typecheck +0.00% +0.00% -1.29% veritas +0.12% +0.00% 0.00 wang +0.00% +0.00% -18.99% wave4main +0.00% +0.00% -9.04% x2n1 +0.00% +0.00% -2.84% ------------------------------------------------------------------------ -------- Min -0.23% +0.00% -18.99% Max +2.47% +19.27% +1.86% Geometric Mean +0.08% +0.23% -6.71%

3 2