-O2 compile option can give speed increase over -O. Fasta shootout program test runs.
I have been playing with the Fasta program in the shootout to see if I can make it umm faster. Starting from dons program on this page and adding some timing calculations as suggested on this wiki page http://shootout.alioth.debian.org/gp4/benchmark.php?test=fasta&lang=ghc&id=2 http://www.haskell.org/haskellwiki/Timing_computations I added different OPTIONS into the top line of the program did a ghc --make fasta.hs and ran it each time with fasta 2500000 (This is one tenth of the shootout figure.) These runs all keep the existing OPTIONS of -fbang-patterns -fexcess-precision Seconds OPTIONS Added ------- ------------- 40.5 40.5 -funbox-strict-fields 40.4 {-# INLINE rand #-} 17.2 -O 17.0 -O -fvia-C 14.4 -O -optc-march=pentium4 11.5 -O2 11.2 -O3 11.5 -O3 {-# INLINE rand #-} 11.3 -O2 -optc-march=pentium4 There was a bit of variation, I've averaged over two runs. This is on an Intel Pentium D 2.66GHz running W2K and GHC 6.6.1. It seems the -O2 option can give a significant speed increase relative to just the -O option. This is contrary to the documentation which says http://www.haskell.org/ghc/docs/latest/html/users_guide/options-optimise.htm... http://www.haskell.org/ghc/docs/latest/html/users_guide/faster.html it won't make any difference. I guess it's program, architecture and operating system specific, but according to these figures the -O2 option seems well worth a try for programs that need speed. It may be that we sacrifice bounds checking or something important with -O2, I don't know. Richard.
r.kelsall:
I have been playing with the Fasta program in the shootout to see if I can make it umm faster. Starting from dons program on this page and adding some timing calculations as suggested on this wiki page
http://shootout.alioth.debian.org/gp4/benchmark.php?test=fasta&lang=ghc&id=2 http://www.haskell.org/haskellwiki/Timing_computations
I added different OPTIONS into the top line of the program did a ghc --make fasta.hs and ran it each time with fasta 2500000 (This is one tenth of the shootout figure.) These runs all keep the existing OPTIONS of -fbang-patterns -fexcess-precision
Seconds OPTIONS Added ------- ------------- 40.5 40.5 -funbox-strict-fields 40.4 {-# INLINE rand #-} 17.2 -O 17.0 -O -fvia-C 14.4 -O -optc-march=pentium4 11.5 -O2 11.2 -O3 11.5 -O3 {-# INLINE rand #-} 11.3 -O2 -optc-march=pentium4
There was a bit of variation, I've averaged over two runs. This is on an Intel Pentium D 2.66GHz running W2K and GHC 6.6.1.
It seems the -O2 option can give a significant speed increase relative to just the -O option. This is contrary to the documentation which says
http://www.haskell.org/ghc/docs/latest/html/users_guide/options-optimise.htm... http://www.haskell.org/ghc/docs/latest/html/users_guide/faster.html
it won't make any difference. I guess it's program, architecture and operating system specific, but according to these figures the -O2 option seems well worth a try for programs that need speed. It may be that we sacrifice bounds checking or something important with -O2, I don't know.
Yes, -O2 is getting better, as new optimisations like SpecConstr are enabled by it. For shootout problems, I'd selectively test with -O2, and if it is better, use that. Good work! And yes, I see that it is currently compiled with: -O fbang-patterns -fexcess-precision -fglasgow-exts -optc-march=pentium4 if -O2 is consistently better here, then we could happily switch. -- Don
On Tue, 2007-07-17 at 11:24 +1000, Donald Bruce Stewart wrote:
r.kelsall:
I have been playing with the Fasta program in the shootout to see if I can make it umm faster. Starting from dons program on this page and adding some timing calculations as suggested on this wiki page
http://shootout.alioth.debian.org/gp4/benchmark.php?test=fasta〈=ghc&id=2 http://www.haskell.org/haskellwiki/Timing_computations
I added different OPTIONS into the top line of the program did a ghc --make fasta.hs and ran it each time with fasta 2500000 (This is one tenth of the shootout figure.) These runs all keep the existing OPTIONS of -fbang-patterns -fexcess-precision
Seconds OPTIONS Added ------- ------------- 40.5 40.5 -funbox-strict-fields 40.4 {-# INLINE rand #-} 17.2 -O 17.0 -O -fvia-C 14.4 -O -optc-march=pentium4 11.5 -O2 11.2 -O3 11.5 -O3 {-# INLINE rand #-} 11.3 -O2 -optc-march=pentium4
There was a bit of variation, I've averaged over two runs. This is on an Intel Pentium D 2.66GHz running W2K and GHC 6.6.1.
It seems the -O2 option can give a significant speed increase relative to just the -O option. This is contrary to the documentation which says
http://www.haskell.org/ghc/docs/latest/html/users_guide/options-optimise.htm... http://www.haskell.org/ghc/docs/latest/html/users_guide/faster.html
it won't make any difference. I guess it's program, architecture and operating system specific, but according to these figures the -O2 option seems well worth a try for programs that need speed. It may be that we sacrifice bounds checking or something important with -O2, I don't know.
Yes, -O2 is getting better, as new optimisations like SpecConstr are enabled by it. For shootout problems, I'd selectively test with -O2, and if it is better, use that.
Good work! And yes, I see that it is currently compiled with:
-O fbang-patterns -fexcess-precision -fglasgow-exts -optc-march=pentium4
if -O2 is consistently better here, then we could happily switch.
Just to add as this was not addressed. -O2 -does not- turn off bounds checking or any other obvious safety mechanism.
Derek Elkins wrote:
Just to add as this was not addressed. -O2 -does not- turn off bounds checking or any other obvious safety mechanism.
although even just -O removes GHC's special 'assert'ions (unless you explicitly keep them on?) -- though they shouldn't be used in such a way that they could trigger, assuming that the code/library that employs them is non-buggy (or exports 'unsafe' things in which case a library's client also has to be non-buggy). Bounds checking is turned off iff you use functions named like unsafeAt, regardless of -O0, -O2 or any other optimization flags :) Isaac
| It seems the -O2 option can give a significant speed increase relative | to just the -O option. This is contrary to the documentation which says -O2 switches on SpecConstr, which has improved quite a bit in the last year or so. There's a paper on my home page about it ("Constructor specialization for Haskell"). Perhaps we should review the documentation you point to! Simon
participants (5)
-
Derek Elkins -
dons＠cse.unsw.edu.au -
Isaac Dupree -
Richard Kelsall -
Simon Peyton-Jones