ghc -fasm declared not too shabby
Got some initial nobench numbers for ghc head -fvia-C versus -fasm, on amd64: http://www.cse.unsw.edu.au/~dons/nobench/x86_64/results.html Overall all of nobench, ghc -fasm averages 3% slower. Not too shabby! There's some wider variation on the microbenchmarks in the imaginary class: one case 20% faster, another 30% slower, average 2% slower. On real programs though, 3% slower on average. The big benefit of course, no perl, no gcc and faster compilation times. -- Don
Donald Bruce Stewart wrote:
Got some initial nobench numbers for ghc head -fvia-C versus -fasm, on amd64:
http://www.cse.unsw.edu.au/~dons/nobench/x86_64/results.html
Overall all of nobench, ghc -fasm averages 3% slower. Not too shabby! There's some wider variation on the microbenchmarks in the imaginary class:
one case 20% faster, another 30% slower, average 2% slower.
nsieve is interesting... I'm looking into it now. Also the HEAD seems slower on that program.
On real programs though, 3% slower on average. The big benefit of course, no perl, no gcc and faster compilation times.
I'd thought that -fasm was a slight improvement over -fvia-C on x86_64, so this is a surprise to me. I know it's slower on x86, mainly due to the poor code generationg for floating point on x86. You might consider discounting the programs that run for less than 0.1 seconds from the average, that's what nofib-analyse does. BTW, what happened to imaginary/rfib? I find that a useful floating point microbenchmark. Cheers, Simon
simonmarhaskell:
Donald Bruce Stewart wrote:
Got some initial nobench numbers for ghc head -fvia-C versus -fasm, on amd64:
http://www.cse.unsw.edu.au/~dons/nobench/x86_64/results.html
Overall all of nobench, ghc -fasm averages 3% slower. Not too shabby! There's some wider variation on the microbenchmarks in the imaginary class:
one case 20% faster, another 30% slower, average 2% slower.
nsieve is interesting... I'm looking into it now. Also the HEAD seems slower on that program.
On real programs though, 3% slower on average. The big benefit of course, no perl, no gcc and faster compilation times.
I'd thought that -fasm was a slight improvement over -fvia-C on x86_64, so this is a surprise to me. I know it's slower on x86, mainly due to the poor code generationg for floating point on x86.
Initial x86 numbers now up, note the (known) floating point issues: http://www.cse.unsw.edu.au/~dons/nobench/i686/results.html
You might consider discounting the programs that run for less than 0.1 seconds from the average, that's what nofib-analyse does.
Good idea. Will do. I'll see if I can increase the runtime on a few others.
BTW, what happened to imaginary/rfib? I find that a useful floating point microbenchmark.
Ah right. It was subsumed with the 'recursive' benchmark, but it might be useful to have back since its smaller. I'll add it. -- Don
participants (2)
-
dons＠cse.unsw.edu.au -
Simon Marlow