My current speed-testing validating technique

[Isaac Dupree]

Simon Marlow wrote:
>   ../../compiler/stage2/ghc-6.7.20070812 -B../.. +RTS -sstderr
> 
> i.e. bypass ghc-inplace and run the ghc binary directly, passing the 
> appropriate -B flag.

BTW. is -B still undocumented in the user's guide? Of course it's not 
obvious that it should be, but still.


Okay, that fits a little better with my timing observations!

In fact I was confused and had been thinking that "validate" only 
produces a stage1... not used to the fast speed of this computer, 
methinks :)  Looks like my validate.mk doesn't yet override the -Onot of 
GhcStage2HcOpts, which I'll fix to get better readings... anyway,

../../../compiler/stage2/ghc-6.7.20070810 -B../../.. --make Main +RTS 
-sstderr

unpatched:
stage1:
1,371,054,464 bytes allocated in the heap
324,667,904 bytes copied during GC (scavenged)
   7,835,924 bytes copied during GC (not scavenged)
  11,985,396 bytes maximum residency (24 sample(s))
stage2:
3,822,367,392 bytes allocated in the heap
546,902,824 bytes copied during GC (scavenged)
  20,709,864 bytes copied during GC (not scavenged)
  13,783,040 bytes maximum residency (40 sample(s))

patched:
stage1:
1,370,421,740 bytes allocated in the heap
322,563,552 bytes copied during GC (scavenged)
   7,785,660 bytes copied during GC (not scavenged)
  12,371,744 bytes maximum residency (23 sample(s))
stage2:
3,823,354,500 bytes allocated in the heap
547,835,340 bytes copied during GC (scavenged)
  20,729,980 bytes copied during GC (not scavenged)
  13,836,288 bytes maximum residency (40 sample(s))


though I'm still not sure which numbers are the most interesting. Looks 
like optimized versions allocate a little less, unoptimized versions a 
bit more (considering this still includes explicit Int# --> UNPACK, 
that's not a surprise). Aside from different versions of GHC, I'm sure 
the performance characteristics will be somewhat different for different 
haskell implementations, but we can worry about that once we've gotten 
that far!

Maybe I'll find a way to automate it more so I can enter one command and 
get all the timing differences for all my patches - then I might bother 
doing so, instead of generally testing a few of them together.

Isaac