J J writes: > >From: <[EMAIL PROTECTED]> > >The problem with arithmetic primitives is > >they're already manually inlined. The SmallInteger inlining needs to > >be moved to use a generic primitive inlining mechanism. > > Won't the Exupery image disable all Squeak inlining (at least in later > versions)? I would expect it too, since the profiling code will cause > Exupery to quickly inline anything Squeak would inline itself anyway, no?
Exupery will not disable Squeak's current inlining. Exupery works from bytecodes, Squeak inlines when generating bytecodes. Exupery needs passable interpreted performance to compile the first few methods. Exupery's story tests clear out Exuperys code cache before each test to ensure that the test is only testing the intended compiled code. That said, I'd expect that with Exupery, many of the inlinings done now would be removed just not ifTrue: and whileTrue: and friends. And I'm sure some people will want to remove ifTrue: and whileTrue: from their images to allow for easier experimentation. Having decent interpreted performance is nice even with dynamic inlining. It'll take dynamic inlining some time to figure out what should be inlined and there are a handful of places where Exupery can not be used. Even with dynamic inlining interpreted performance will matter for the first few minutes or on machines without an Exupery port. Bryce _______________________________________________ Exupery mailing list [email protected] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/exupery
