block rewriting...

Previous Topic Next Topic
classic Classic list List threaded Threaded
1 message Options
Reply | Threaded
Open this post in threaded view

block rewriting...

Stéphane Ducasse

Begin forwarded message:

From: Paul Baumann <[hidden email]>
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 <[hidden email]>, Reinout Heeck <[hidden email]>

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 ( 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.
                                _into: results
                                elective: including1
                                elective: including2
                                elective: nil
                                elective: nil
                                keyedCollect: optimizedBlock.
                self _finishedCollect: optimizedBlock
                                started: 0
                                results: results.
This framework is for GS/S; however, the same performance gains can be obtained in other dialects.
Paul Baumann
From: [hidden email] [mailto:[hidden email]] On Behalf Of Eliot Miranda
Sent: Thursday, March 22, 2012 18:02
To: Reinout Heeck
Cc: [hidden email]
Subject: Re: [vwnc] [vw7.7] Perhaps unknown limitation of BlockClosure>>once (in Assets)


On Thu, Mar 22, 2012 at 10:13 AM, Reinout Heeck <[hidden email]> 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
[hidden email]


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
[hidden email]