Hello Kirsten, Sunday, December 31, 2006, 7:47:18 PM, you wrote:
>> this don't say anything place. and these rules have their own source: it's >> hard to optimize using your path. but when program optimization is just >> adding a few options/pragmas to the program, it' becomes cheap enough to >> change these rules. didn't you thought about it? >> > In my experience, adding pragmas and toying with options without > insight into what they do is not "cheap", because it takes up the > programmer's time, and time is more important than anything else. using pragmas is much cheaper than profiling/reading low level code > Every minute spent typing in pragmas is a minute lost that could have it's a great loss :) > been spent thinking about how to write your code more elegantly, and > in my experience -- and again, maybe it's just that I'm slow -- adding > pragmas doesn't help. When it comes to inlining and specializing, GHC > tends to be smarter than I am. (Once more, maybe it's just that I'm > slow.) I'd rather focus my energies on doing the things GHC can't > (usually) do, like replacing an O(n^2) algorithm with an O(log n) > algorithm. in a minute? :) i don't agree with your arguments. if you want your program to become faster you should use various techniques. what i proposed is fastest one. i don't see meaning in opposing algorithm optimization to other techniques my own optimization experience was experimenting with variants of source code and once i understood which variants of code can't be inlined at all i just use inline pragma for all critical functions. i've learned how ghc generates STG code once and for all, and don't think that i need to see STG anymore -- Best regards, Bulat mailto:[EMAIL PROTECTED] _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
