Begin forwarded message:
From: Paul Baumann <paul.baumann@theice.com> 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 <eliot.miranda@gmail.com>, Reinout Heeck <vwnclist@soops.nl> Cc: "vwnc@cs.uiuc.edu" <vwnc@cs.uiuc.edu>
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-enumeratio...). 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: vwnc-bounces@cs.uiuc.edu [mailto:vwnc-bounces@cs.uiuc.edu] On Behalf Of Eliot Miranda Sent: Thursday, March 22, 2012 18:02 To: Reinout Heeck Cc: vwnc@cs.uiuc.edu Subject: Re: [vwnc] [vw7.7] Perhaps unknown limitation of BlockClosure>>once (in Assets)
On Thu, Mar 22, 2012 at 10:13 AM, Reinout Heeck <vwnclist@soops.nl> 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 vwnc@cs.uiuc.edu 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 vwnc@cs.uiuc.edu http://lists.cs.uiuc.edu/mailman/listinfo/vwnc