Andy,
The GHC head can currently build against PAPI[1], a library for
gathering CPU statistics. At the moment you can only gather such
statistics for AMD Opteron but it shouldn't be difficult to port it
to other CPUs after a bit of browsing around the PAPI docs.
Installing PAPI requires installing a linux kernel driver though, so
it is not for the faint hearted.
We have used this library to find bottlenecks in the current code
generation and we have implemented ways of correcting them, so expect
some good news about this in the future.
I should get around to start a wiki page about using PAPI these days,
but meanwhile feel free to contact me if you need further information
or help.
Cheers,
Alexey
[1] http://icl.cs.utk.edu/papi/
On Dec 18, 2006, at 22:35, Andy Georges wrote:
Hi,
I have to dispute this Bulat's characterisation here. We can
solve lots
of nice problems and have high performance *right now*. Particularly
concurrency problems, and ones involving streams of bytestrings.
No need to leave the safety of GHC either, nor resort to low
level evil
code.
let's go further in this long-term discussion. i've read Shootout
problems
and concluded that there are only 2 tasks which speed is dependent on
code-generation abilities of compiler, all other tasks are
dependent on
speed of used libraries. just for example - in one test TCL was
fastest
language. why? because this test contained almost nothing but 1000
calls to
the regex engine with very large strings and TCL regex engine was
fastest
Maybe it would not be a bad idea to check the number of cache
misses, branch mispredictions etc. per instruction executed for the
shootout apps, in different languages, and of course, in haskell,
on the platforms ghc targets. Do you think it might potentially be
interesting to the GHC developing community to have such an
overview? It might show potential bottlenecks, I think.
-- Andy
_______________________________________________
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
_______________________________________________
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe