gmane.comp.lang.haskell.cafe

Peter Lund | 20 Dec 11:54

[RFC] Preliminary benchmark graphs

I added Don's three benchmarks and redid all my benchmarks with:
  ghc 6.6.1
  ghc 6.8.2
  ghc 6.8.2 + bytestring 0.9.0.2
  ghc 6.9.20071119
  ghc 6.9.20071119 + bytestring 0.9.0.2
  ghc head-as-of-yesterday-around-noon
  ghc head-as-of-yesterday-around-noon + bytestring 0.9.0.2

I tried to get the draft emails with intro, methodology, discussion, and
conclusion completed yesterday but my brain simply wasn't up to it.

Unfortunately, it still isn't quite up to it :(

Since the perfect is the enemy of the good, I'll post the graphs for all
the above 7 runs now.

The rest will be forthcoming when I can think straight again, hopefully
some time in the evening.

I have scripts to help me install precisely the ghc version I want (and
to make it easy to duplicate my results).  I also have scripts to run
the benchmarks, get correct memory measurements (-sstderr doesn't seem
trustworthy), check the validity of each timing measurement, generate
I/O traces, generate reports, and finally merging reports from different
runs with or without rescaling.

This attached report uses rescaling since I'm compiling different
compiler/library combinations on the same machine.

(Continue reading)

headers

Don Stewart | 20 Dec 19:58

Re: [RFC] Preliminary benchmark graphs

firefly:
> I added Don's three benchmarks and redid all my benchmarks with:
>   ghc 6.6.1
>   ghc 6.8.2
>   ghc 6.8.2 + bytestring 0.9.0.2
>   ghc 6.9.20071119
>   ghc 6.9.20071119 + bytestring 0.9.0.2
>   ghc head-as-of-yesterday-around-noon
>   ghc head-as-of-yesterday-around-noon + bytestring 0.9.0.2

> One thing that shows up very clearly in the graphs is that the memory
> situation is bad and that Don's recent fix only really solves the
> problem on 6.8.2, not on head.

Can you pinpoint specific programs, with either ghc 6.8.2 or
head, that allocate too much? That's likely to be a library 
issue that I can address in ByteString.

I'd need the source program, whether it is with ghc 6.8.2 or ghc head,
and what compiler flags (and input size).

Low level loop/performance issues go to SimonM (i.e. if its allocating
fine, the core is perfect, but just too slow).

-- Don