> > When I implemented a similar change previously (in my old > > non-CVS speceval > > branch) results suggested that it made little difference to > > non-speculative execution. > > > > The problem was that most closures were either thunks, or, if > > they had already > > been > > evaluated, indirections. As a result, semitagging usually > > failed and so didn't on average win anything. > > There's an important difference between this kind of semi-tagging and > the version you implemented before: this version doesn't need to > dereference the pointer to determine whether it is evaluated or not. I > think that should be a win. > > We know from ticky results that around 50% of enters are to evaluated > objects (varies wildly from program to program, but 50% seems about > average), so I'd be surprised if avoiding these enters does not save > some memory accesses. I'm not surprised that the old kind of > semitagging didn't win: looking in the info table is just as bad as > entering the thing.
But didn't that 50% include those that went through indirections (which aren't caught by bitwise semitagging) ? Of course, the best way to answer this question is to get some numbers :-) If I don't use the "-fspec-eval" flag on the spec branch, then it behaves in essentially the same way as the HEAD. Virtually all my changes only take affect when "-fspec-eval" is used. I can thus see how bitwise semi-tagging affects a non-speculative branch without having to patch the HEAD first :-)) If it does turn out to be a big win, then I'll patch it in. Although looking at the info table is expensive, the old style semi-tagging was still a win for speculation code, so speculation does seem to affect the usefulness of semitagging. -Rob _______________________________________________ Cvs-ghc mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/cvs-ghc
