You can find an example at: graphics.cs.ucdavis.edu/~sdillard/newtype-maybe-bug.tar.gz Here's my session with it: ghc --make -O2 -DFAST Test time ./Test +RTS -tstderr <<ghc: 21120 bytes, 2 GCs, 32768/32768 avg/max bytes residency (1 samples), 1M in use, 0.00 INIT (0.00 elapsed), 7.52 MUT (8.70 elapsed), 0.00 GC (0.00 elapsed) :ghc>> real 0m8.827s user 0m7.520s sys 0m1.224s ghc --make -O2 -DSLOW Test -no-recomp time ./Test +RTS -tstderr <Ctrl-C> Test: interrupted <<ghc: 13476104656 bytes, 25762 GCs, 36864/36864 avg/max bytes residency (1 samples), 1M in use, 0.00 INIT (0.00 elapsed), 91.19 MUT (92.85 elapsed), 0.22 GC (0.36 elapsed) :ghc>> real 1m33.232s user 1m31.410s sys 0m1.020s If you do ghc -c -O2 -DFAST -ddump-simpl Test.hs | grep VecMath.V you won't find any occurrences/pattern matches on the constructor, but with ghc -c -O2 -DSLOW -ddump-simpl Test.hs | grep VecMath.V you'll see lots, due to a call to peek that is not inlined. This is with ghc-6.8.1 and ghc-6.8.2 (no difference) Thanks for any light you can shed on this, Scott On Dec 12, 2007 1:48 PM, Don Stewart <dons@galois.com> wrote:
stefanor:
On Wed, Dec 12, 2007 at 11:02:15AM -0700, Scott Dillard wrote:
with strictness annotations and INLINEs for everything. I also tried automatic newtype deriving, with no luck. Why does a newtype defeat so much of the optimization?
Thanks, Scott
(Not a GHC developer, but someone fairly familiar with how the Simons work)
What version of GHC are you using? The implementation of newtypes was completely redone in the 6.7.x period.
Do you have a fairly small complete working example? If so, link to or attach a tarball - will make their jobs much easier.
Stefan
Yeah, this sounds like maybe a bug, or maybe something wrong. We need to investigate! An example please.
-- Don