From: "Jon Hylands" jon@huv.com To: "Joshua Scholar" jscholar@access4less.net; "The general-purpose
Squeak developers list" squeak-dev@lists.squeakfoundation.org
Sent: Tuesday, November 30, 2004 9:03 AM Subject: Re: FIX: Making Set/Dictionary etc. loops more robust
On Tue, 30 Nov 2004 08:30:52 -0800, "Joshua Scholar" jscholar@access4less.net wrote:
You know, it occures to me to wonder why common looping constructs near
the
bottom of hierachies haven't been turned into primitives. Faster looping constructs (a SmallInteger to: do:, Float to: by: do:, Interval to: by:
do:,
Array do:, ByteArray do: etc.) would significantly speed up some code.
VisualAge has done this. They have a generic collection iterator
primitive,
with which all the built-in collection enumeration methods are
implemented.
Later, Jon
It would be fun to add primitives to speed up basic loops, but I'm confused about if, when and where the new closure compiler is going to come on line.
This might seem weird coming from someone like me who (if you look at my code) is obviously still learning the Smalltalk programming idioms... That atRandom: fix had an extra variable in it and an extra test because I knew about "whileTrue:" but not about "doWhileTrue:".
Anyway, is the new compiler going to be part of Squeak 4? (the VI4 (virtual image) page on Swiki hopes so, but the Squeak 4 pages don't say it will.
Is the rest of VI4 going to be in Squeak 4? Perhaps it's already in - the page is dated two years ago. Or was it abandoned?
How do I test the closure compiler? The page on Swiki says that the primitives went in to the VM back in 3.6.something, but someone complained that the new compiler was too slow on 3.7, and wondered if the primitives are in...
So, are the primitives in 3.7, 3.8 & 3.9?
So I'm not sure how to install the new compiler... Also, for the sake of speed testing, I'd like to be running the main classes recompiled with the new compiler - and I'm not sure what's the right way to rebuild the system if I did install the new compiler. I remember reading that EToys break if you recompile them with the new compiler - not that I'm using EToys.
It makes no sense to me to write looping primitive designed to work on a block structure that we are going to throw away. And I do prefer closures to what Squeak currently has.
Also I'm not conversant on exactly what problems primitives entail - my main question is what can't I do in a primitive for fear that a garbage collection will mess it up.
Another point is that some looping constructs might be better inlined than made into primitives. I have NO idea how to do that. Not that this should stop us from having an interim fix that's better than nothing...
Hey, that's a pretty good argument for making a loop primitive plug in for the current blocks. If the old system speeds up considerably because of a plug-in that will create pressure to make sure the new system has the same optimizations.