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:Bulat.Ziganshin@gmail.com