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