problems using ghc-6.6.1
Dear Hets- and GHC-Developers, we have a problem using ghc-6.6.1. The created hets binary runs a couple of times slower than the one created using ghc-6.6. (see below) What might be the cause for this? Cheers Christian ghc-6.6.1: hets +RTS -H300m -M1g -p -RTS -o prf Basic/Numbers.casl total time = 1979.05 secs (39581 ticks @ 50 ms) total alloc = 167,752,167,576 bytes (excludes profiling overheads) COST CENTRE MODULE %time %alloc selectProofBasis Proofs.EdgeUtils 82.8 86.1 sl_sign CASL.Sublogic 5.3 3.7 compInclusion Logic.Grothendieck 3.2 3.2 getAllPathsOfTypesBetween Proofs.EdgeUtils 1.5 1.6 isSubOpMap CASL.Sign 1.2 0.9 primCoerce Logic.Coerce 0.8 1.1 ghc-6.6: hets +RTS -H300m -M1g -p -RTS -o prf Basic/Numbers.casl total time = 215.25 secs (4305 ticks @ 50 ms) total alloc = 20,691,103,008 bytes (excludes profiling overheads) COST CENTRE MODULE %time %alloc selectProofBasis Proofs.EdgeUtils 73.1 79.6 sl_sign CASL.Sublogic 6.8 4.2 compInclusion Logic.Grothendieck 3.7 3.8 getAllPathsOfTypesBetween Proofs.EdgeUtils 2.8 3.1 isSubOpMap CASL.Sign 1.6 1.1 sublogics_join CASL.Sublogic 1.5 1.1 primCoerce Logic.Coerce 1.3 1.4 isSameTranslation Proofs.Local 1.2 0.9
You seem to be generating 8x the garbage with the 6.6.1 version which could account for the 2x slowdown. On May 8, 2007, at 2:19 PM, Christian Maeder wrote:
ghc-6.6.1: hets +RTS -H300m -M1g -p -RTS -o prf Basic/Numbers.casl
total time = 1979.05 secs (39581 ticks @ 50 ms) total alloc = 167,752,167,576 bytes (excludes profiling overheads)
Christian Maeder wrote:
Dear Hets- and GHC-Developers,
we have a problem using ghc-6.6.1. The created hets binary runs a couple of times slower than the one created using ghc-6.6. (see below)
What might be the cause for this?
Very strange. The performance has decreased dramatically, but the profile looks the same: that is, performance has degraded more or less consistently across the whole code. I have to ask: did you turn on -O? Cheers, Simon
Cheers Christian
ghc-6.6.1: hets +RTS -H300m -M1g -p -RTS -o prf Basic/Numbers.casl
total time = 1979.05 secs (39581 ticks @ 50 ms) total alloc = 167,752,167,576 bytes (excludes profiling overheads)
COST CENTRE MODULE %time %alloc
selectProofBasis Proofs.EdgeUtils 82.8 86.1 sl_sign CASL.Sublogic 5.3 3.7 compInclusion Logic.Grothendieck 3.2 3.2 getAllPathsOfTypesBetween Proofs.EdgeUtils 1.5 1.6 isSubOpMap CASL.Sign 1.2 0.9 primCoerce Logic.Coerce 0.8 1.1
ghc-6.6: hets +RTS -H300m -M1g -p -RTS -o prf Basic/Numbers.casl
total time = 215.25 secs (4305 ticks @ 50 ms) total alloc = 20,691,103,008 bytes (excludes profiling overheads)
COST CENTRE MODULE %time %alloc
selectProofBasis Proofs.EdgeUtils 73.1 79.6 sl_sign CASL.Sublogic 6.8 4.2 compInclusion Logic.Grothendieck 3.7 3.8 getAllPathsOfTypesBetween Proofs.EdgeUtils 2.8 3.1 isSubOpMap CASL.Sign 1.6 1.1 sublogics_join CASL.Sublogic 1.5 1.1 primCoerce Logic.Coerce 1.3 1.4 isSameTranslation Proofs.Local 1.2 0.9
_______________________________________________ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Simon Marlow schrieb:
Christian Maeder wrote:
Dear Hets- and GHC-Developers,
we have a problem using ghc-6.6.1. The created hets binary runs a couple of times slower than the one created using ghc-6.6. (see below)
What might be the cause for this?
Very strange. The performance has decreased dramatically, but the profile looks the same: that is, performance has degraded more or less consistently across the whole code. I have to ask: did you turn on -O?
-O was turned off in both cases. (Optimization usually only accounts for a factor of 3 -- and not 8 or even more.) Sorry for my panic. The slow down is caused by the last change described in http://web.engr.oregonstate.edu/~erwig/fgl/haskell/CHANGES The additional loops in Data.Graph.Inductive.Graph (also added at the end of a possibly long list) make our algorithm slower. context1l' :: Context a b -> Adj b context1l' (p,v,_,s) = p++filter ((==v).snd) s context4l' :: Context a b -> Adj b context4l' (p,v,_,s) = s++filter ((==v).snd) p Cheers Christian
participants (3)
-
Christian Maeder -
Joel Reymont -
Simon Marlow