tools for comparing ghc's debug outputs?
What tools are there for facilitating comparisons of ghc's debug output? I have reduced a performance problem in my code to a case where switching two lines of code doubles or halves the performance (the results of those lines are stored in record fields that never get used in this reduced example.., see ghc trac ticket #2463). So it should be easy to take the outputs of -ddump-simpl, etc. for both variants and run them through a diff viewer, but there are way too many irrelevant differences and details. I seem to recall someone mentioning a tool for normalizing the output of things like -ddump-simpl to make diffs easier by reducing irrelevant differences due to gensym-generated names. Was that just wishful thinking, or does such a thing exist?-) Also, it might be useful if one could translate the transformed code back to highlevel (ghc-)Haskell that would generate the same low-level code (ie, pretending that the source-to-source transformations actually happened at source level). Not only would that blend out irrelevant details, it would also give a direct indication of how to modify the source to get better performing code. What tools are there, and which do you use/recommend for tasks like this? Thanks, Claus
2008/7/31 Claus Reinke
What tools are there for facilitating comparisons of ghc's debug output? I have reduced a performance problem in my code to a case where switching two lines of code doubles or halves the performance (the results of those lines are stored in record fields that never get used in this reduced example.., see ghc trac ticket #2463). So it should be easy to take the outputs of -ddump-simpl, etc. for both variants and run them through a diff viewer, but there are way too many irrelevant differences and details.
I seem to recall someone mentioning a tool for normalizing the output of things like -ddump-simpl to make diffs easier by reducing irrelevant differences due to gensym-generated names. Was that just wishful thinking, or does such a thing exist?-)
I would also find such a tool very useful, but to the best of my knowledge there's nothing out there yet. You can get quite far by using the -dsuppress-uniques flag, which removes irrelevant differences due solely to the unique numbers assigned to names. However, I've found that diff output from that is still hard to deal with because GHC reorders functions in the Core output under some circumstances. I've been meaning to find the time to try and fix this. Cheers, Max
I seem to recall someone mentioning a tool for normalizing the output of things like -ddump-simpl to make diffs easier by reducing irrelevant differences due to gensym-generated names. Was that just wishful thinking, or does such a thing exist?-)
I would also find such a tool very useful, but to the best of my knowledge there's nothing out there yet.
Surprising - how do all of you optimization tuners manage without?
You can get quite far by using the -dsuppress-uniques flag, which removes irrelevant differences due solely to the unique numbers assigned to names. However, I've found that diff output from that is still hard to deal with because GHC reorders functions in the Core output under some circumstances. I've been meaning to find the time to try and fix this.
Thanks. Simon PJ also mentioned that (undocumented?) flag, but I must be using it wrong, because ghc --make -O2 Main.hs -dsuppress-uniques -ddump-simpl >simpl-slow still gives me plenty of _labels in the output (6.9.20080514). How is this flag supposed to be used? I've had some success by simply doing a brute-force #s/_[^ _]*\>//g' over the files before diffing, to remove anything that looks like a final addon-label. That isn't quite right (__inline_me becomes __inline, etc), but at least it helps to fold away lots of unwanted detail. Claus
claus.reinke:
I seem to recall someone mentioning a tool for normalizing the output of things like -ddump-simpl to make diffs easier by reducing irrelevant differences due to gensym-generated names. Was that just wishful thinking, or does such a thing exist?-)
I would also find such a tool very useful, but to the best of my knowledge there's nothing out there yet.
Surprising - how do all of you optimization tuners manage without?
I use the ghc-core tool, and occasionally piping code into vimdiff, particularly for assembly. http://hackage.haskell.org/cgi-bin/hackage-scripts/package/ghc-core
participants (3)
-
Claus Reinke -
Don Stewart -
Max Bolingbroke