Hello Lennart, Sunday, December 31, 2006, 10:26:24 PM, you wrote:
> I think you can be much more productive in optimizing your code > if you actually understand what's going on. I usually don't go as > far as looking at compiler intermediate code; I usually stick with > profiling (or look at assembly code if it's a really performance > critical inner loop). for GHC??? :) if we say about optimizing C programs, old days i usually looked into asm code and then darken and go to rewrote it in asm :) nowadays i look only at memory access patterns, it's enough, at least for a few programs i optimized this year for GHC, i usually know which functions need to become faster, so i personally don't need profiling. moreover, program should be optimized for wide variety of situations, while profiling run shows only one execution scenario. i don't think that looking into STG (don't even said about C--/asm) may help me to optimize program. which program-specific things i can find here, after i've once learned how generation of STG code works? > Then you can start optimizing. That can be > by changing algorithm, changing data representation, strictness > annotations, etc. yes, i don't use profiling because i use more specific instruments to investigate performance bottlenecks > It can also be by inserting some INLINE or SPECIALIZE > pragmas, but that's more rare (don't get me wrong about those pragmas, > I introduced them in Haskell with hbc). But I think just adding pragmas > willy-nilly is a bad idea; I find that most serious performance problems > cannot be solved by those means, instead you need a higher level > approach. i proposed it as fast approach to raise performance, as alternative to your suggestion to profile and read code, where you not said anything about changing algorithms :) -- Best regards, Bulat mailto:[EMAIL PROTECTED] _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe