Haskell Applications - reg
Hi List, I am planning a study on statistical properties of (static) call graphs for programs written in different languages; the idea is to compute a handful of "relevant" graph structural metrics and see what they have to say about the software/language. In this lieu, I am studying following languages - C, C++, Haskell, OCaml and hopefully Scheme and Java. I picked up a handful of Haskell applications from Haskell Apps repository [0] and computed the call graph for them [1]. But am not quite sure if the applications are representative; for one, the graphs are quantitatively distinct! In addition, this difference appears consistent across the Haskell applications I tried. Am not sure if its GHC compiler/runtime effect or Haskell effect though. Should the effects are artifact of disassembly, likely that OCaml graphs would have exhibited them too. Is there any particular application(s) that is quintessentially Haskell'sh that I could convince myself that my samples are representative?! I am fledging new to Haskell and would appreciate some pointers in picking up the "few, but ripe" ones. Hope it's fine. In case any list member is curious, I have got some preliminary plots hosted at http://agni.csa.iisc.ernet.in/nganesh/plots ; horizontal dividers represent language boundaries [top, bottom) and in/out/total stand for degrees. I have five Haskell applications enlisted: Yarrow, Frown, DrIFT, HaXml.{Validate/Extract}. Thanks -ganesh [0] http://www.haskell.org/haskellwiki/Applications_and_libraries; I picked up whatever I could compile. I am yet to get cabal running. [1] Am presently constructing the call graphs from disassembled application binaries; resultant graph includes ghc runtime library calls.
On Thu, Oct 04, 2007 at 05:32:31AM +0530, Ganesh Narayan wrote:
[1] Am presently constructing the call graphs from disassembled application binaries; resultant graph includes ghc runtime library calls.
Not necessary a good idea - Haskell's purity gives the compilers great license to reorder and rearrange code, and the laziness causes the dynamic call graph to differ wildly from the static call graph even without without optimizations. GHC's use of a private stack with very weird return conventions probably isn't helping either! Stefan
True, but I was of the opinion that -O0, -fno-state-hack and -fno-full-laziness would preserve the calling structure with minimal perturbance. Wouldn't it? Besides, I am hardly aware of any utility that generates source level call graph/expression dependence graph; suppose one can generate a module dependency graph, but guess its little too coarse! -ganesh On 10/4/07, Stefan O'Rear <stefanor@cox.net> wrote:
On Thu, Oct 04, 2007 at 05:32:31AM +0530, Ganesh Narayan wrote:
[1] Am presently constructing the call graphs from disassembled application binaries; resultant graph includes ghc runtime library calls.
Not necessary a good idea - Haskell's purity gives the compilers great license to reorder and rearrange code, and the laziness causes the dynamic call graph to differ wildly from the static call graph even without without optimizations. GHC's use of a private stack with very weird return conventions probably isn't helping either!
Stefan
-----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux)
iD8DBQFHBDCVFBz7OZ2P+dIRAnogAJ9m8Vv/NjUg50bJYdAGl2lzJQZMIwCgsXdq mwdCgw1AO7KMBVkKTXjymAM= =+aCh -----END PGP SIGNATURE-----
On 10/4/07, Ganesh Narayan <ganesh.narayan@gmail.com> wrote:
True, but I was of the opinion that -O0, -fno-state-hack and -fno-full-laziness would preserve the calling structure with minimal perturbance. Wouldn't it? Besides, I am hardly aware of any utility that generates source level call graph/expression dependence graph; suppose one can generate a module dependency graph, but guess its little too coarse!
You might have more luck with JHC, which (if I understand correctly) creates intermediate C code that somewhat resembles the Haskell source in structure. -- Dave Menendez <dave@zednenem.com> <http://www.eyrie.org/~zednenem/>
Yup, my call graph constructor jst tracks statically resolved call instructions and splices them to get the whole program graph; no indirections. I could rewrite the tool, but tracking jmp *%eax would be tad too complicated! I'd try JHC meanwhile. Stefen, Simon and David, thanks again for the inputs. -ganesh On 10/5/07, David Menendez <dave@zednenem.com> wrote:
On 10/4/07, Ganesh Narayan <ganesh.narayan@gmail.com> wrote:
True, but I was of the opinion that -O0, -fno-state-hack and -fno-full-laziness would preserve the calling structure with minimal perturbance. Wouldn't it? Besides, I am hardly aware of any utility that generates source level call graph/expression dependence graph; suppose one can generate a module dependency graph, but guess its little too coarse!
You might have more luck with JHC, which (if I understand correctly) creates intermediate C code that somewhat resembles the Haskell source in structure.
-- Dave Menendez <dave@zednenem.com> <http://www.eyrie.org/~zednenem/>
Stefan's last point is the key one. GHC compiles into code that doesn't use call/return instructions. Instead, it pushes explicit return addresses, and returns by doing an indirect jump. I bet this isn't what your tool expects. Simon | -----Original Message----- | From: haskell-bounces@haskell.org [mailto:haskell-bounces@haskell.org] On | Behalf Of Stefan O'Rear | Sent: 04 October 2007 01:15 | To: Ganesh Narayan | Cc: haskell@haskell.org | Subject: Re: [Haskell] Haskell Applications - reg | | On Thu, Oct 04, 2007 at 05:32:31AM +0530, Ganesh Narayan wrote: | > [1] Am presently constructing the call graphs from disassembled application | > binaries; resultant graph includes ghc runtime library calls. | | Not necessary a good idea - Haskell's purity gives the compilers great | license to reorder and rearrange code, and the laziness causes the | dynamic call graph to differ wildly from the static call graph even | without without optimizations. GHC's use of a private stack with very | weird return conventions probably isn't helping either! | | Stefan
participants (4)
-
David Menendez -
Ganesh Narayan -
Simon Peyton-Jones -
Stefan O'Rear