Begin forwarded message:
> From: Paul Baumann <[email protected]> > Subject: Re: [vwnc] [vw7.7] Perhaps unknown limitation of BlockClosure>>once > (in Assets) > Date: March 23, 2012 3:12:40 PM GMT+01:00 > To: Eliot Miranda <[email protected]>, Reinout Heeck <[email protected]> > Cc: "[email protected]" <[email protected]> > > It sounds similar to a technique I use in GS/S code to turn ComplexBlocks > into SimpleBlocks (different terminology from VW, but same idea). The > "Efficient GemStone Enumeration" framework has been enhanced and simplified > (http://techsupport.gemstone.com/entries/175923-efficient-gemstone-enumeration-2-1-002-0). > Sorry I haven't shared the updated version yet. One of the neat things about > the new version is that it is extended to optimize blocks for enumeration. It > effectively recompiles blocks to pass context into simpler blocks through > extended arguments rather than having a block closure reference external > context. The optimized blocks are cached for reuse. Amazing gains are > achieved in GS by using SimpleBlocks instead of ComplexBlocks. The framework > I mentioned makes it possible to write application code to use simple blocks > but it is still up to a developer to revise code to use the simple blocks. > Developers get it wrong. They sometimes go through a lot of effort to > refactor code but make a mistake in the optimization that makes all that work > moot. This automatic optimization eliminates those mistakes and existing code > can become much faster without having to tune application code. > > Collection>>including: including1 including: including2 > collect: threeArgBlock > "Extension of GS_CollectionPerformanceBase. plb 2011.06.27" > > | results optimizedBlock | > optimizedBlock := threeArgBlock forEnumerating: self. > results := self _newCollectResultForBlock: optimizedBlock. > self > _into: results > elective: including1 > elective: including2 > elective: nil > elective: nil > keyedCollect: optimizedBlock. > self _finishedCollect: optimizedBlock > started: 0 > results: results. > ^results > > This framework is for GS/S; however, the same performance gains can be > obtained in other dialects. > > Paul Baumann > > > > From: [email protected] [mailto:[email protected]] On Behalf Of > Eliot Miranda > Sent: Thursday, March 22, 2012 18:02 > To: Reinout Heeck > Cc: [email protected] > Subject: Re: [vwnc] [vw7.7] Perhaps unknown limitation of BlockClosure>>once > (in Assets) > > > > On Thu, Mar 22, 2012 at 10:13 AM, Reinout Heeck <[email protected]> wrote: > Trying to atone for that foot in my mouth, I concocted a sketch for fixing > #once. > > Clever! And that suggests a simple implementation for Squeak. Methods can > maintain a map in a their properties/pragmas/method tags to map closure > initial pc to cached value. Thanks!! > > Please find attached a workspace snippet that will alter the system without > immediately crashing it. > When evaluating the script it will complain about undeclared names, simply > hit 'leave undeclared'. > > > This implementation delegates the caching and becoming to the CompiledBlock > instances instead of the BlockClosure instances that the original used. It > should now work for both clean and copying blocks. > The simple test Steven Kelly supplied below should now yield true in both > cases. > > This code has hardly been tested, its just a sketch and needs some cleanup > (and it is developed on 771 FTW). > > In both the original and new versions I miss the flushing of the VM (JIT) > caches, > could someone here with knowledge about the JIT review this apparent omission? > > > > On 3/21/2012 1:32 PM, Steven Kelly wrote: > Object class>>onceClean > "self onceClean == self onceClean" "true" > ^[Object new] once > > Object class>>onceUnclean > "self onceUnclean == self onceUnclean" "false" > ^[self new] once > > Enjoy, Reinout > > > _______________________________________________ > vwnc mailing list > [email protected] > http://lists.cs.uiuc.edu/mailman/listinfo/vwnc > > > > > -- > best, > Eliot > > > This message may contain confidential information and is intended for > specific recipients unless explicitly noted otherwise. If you have reason to > believe you are not an intended recipient of this message, please delete it > and notify the sender. This message may not represent the opinion of > IntercontinentalExchange, Inc. (ICE), its subsidiaries or affiliates, and > does not constitute a contract or guarantee. Unencrypted electronic mail is > not secure and the recipient of this message is expected to provide > safeguards from viruses and pursue alternate means of communication where > privacy or a binding message is desired. > _______________________________________________ > vwnc mailing list > [email protected] > http://lists.cs.uiuc.edu/mailman/listinfo/vwnc
