RE: computer language shootout
So am I. Have any haskell-performance gurus looked at any of the code? Many of the slowest entries are written in a very elegant, high-level style that is probably also relatively slow.
I've looked at a few. The most common factor in the worst performers seems to be the performance of String-related operations. I tried converting a few to use PackedStrings but that didn't help much. I suspect our PackedString implementation could do with some tuning, and we could gain considerable benefit from having an hGetLinePS function (like hGetLine but gets a PackedString). Cheers, Simon
On Mon, 30 Jul 2001, Simon Marlow wrote:
I've looked at a few. The most common factor in the worst performers seems to be the performance of String-related operations. I tried converting a few to use PackedStrings but that didn't help much. I suspect our PackedString implementation could do with some tuning, and we could gain considerable benefit from having an hGetLinePS function (like hGetLine but gets a PackedString).
Well, I think the common factor is I/O. The lazy I/O seems to be a real bottleneck here. Trying to improve that would gain even more, I think. I'm saying this because I did quite a bit of fiddling with some of the examples (including trying PackedStrings). The conclusion I drew from doing this was that the I/O performance was the problem. Having said that I must also say that I think that ghc's I/O is fast *enough*. It's just that it doesn't compare very well with other languages. I've never had problems caused by slow I/O in Haskell. Anyway, don't let this stop you from tuning and expanding that PackedString library. I would love to see a PackedString library for ghc which is as complete as hbc's ;-) Cheers, /Josef
Josef Svenningsson wrote:
On Mon, 30 Jul 2001, Simon Marlow wrote:
I've looked at a few. The most common factor in the worst performers seems to be the performance of String-related operations. I tried converting a few to use PackedStrings but that didn't help much.
Well, I think the common factor is I/O. ...
Couldn't it sometimes also be really simple things, like how much time is spent in the garbage collector? As illustrated below, it first appears that HBC is faster than GHC (5.00.2) on a simple I/O & String manipulation benchmark, but, as the last test shows... linux% cat interact.hs main = interact (unlines . lines) linux% hbc -O interact.hs linux% time a.out < Input500 > Output500 7.870u 0.210s 0:08.08 100.0% 0+0k 0+0io 159pf+0w linux% ghc -O2 interact.hs linux% time a.out < Input500 > Output500 10.010u 0.190s 0:10.26 99.4% 0+0k 0+0io 150pf+0w linux% time a.out +RTS -H2M < Input500 > Output500 6.220u 0.140s 0:06.35 100.1% 0+0k 0+0io 163pf+0w linux% rpm -q ghc ghc-5.00.2-1 The file Input500 is http://www.bagley.org/data/shootout/wc/Input, repeated 500 times. /Thomas Hallgren
participants (3)
-
Josef Svenningsson -
Simon Marlow -
Thomas Hallgren