Hi Joshua!

I will try to answer a few questions.

"Joshua Scholar" <jscholar at access4less.net> wrote:
> 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.

The new compiler is planned to enter 3.9alpha as soon as 3.8 goes final
or something similar.
Marcus Denker is holding that ball and can answer details.

> 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.

I think that page is less updated

> 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?

Not sure, Marcus probably knows.

> 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.

Well, as people has explained - you can do whatever you like in a
plugin/primitive but you need to be careful whenever you create/allocate
Squeak-stuff. The push/pop remappableOop thingy is your friend but it
can get tricksy. I have some code in my GtkPlugin experiment which
looks... hideous, and it took some time to get it right. :)

Let me just finish by saying that IMHO if you want to go for SPEEEED
then the most promising thing in Squeak country is Exupery by Bryce
Kampjes. That is where I would put my money. Trying to speed up the
regular VM is hard work and AFAICT it is hard to find cheap solutions.

Anthony claimed impressive speedups with his new stuff (Closures etc) -
so hopefully all that will go in - but what has been seen earlier from
the JIT-experiments by Ian is that only approximately half the time is
spent in the interpreter when you run real world stuff. IIRC Jitter-3
was 4-5 times faster at interpreting but when running the benchmarks it
went down to less than 2 times faster, because in the real world Squeak
spends a lot of time in primitives. 2 times is a lot of course, but...
for that amount of work (writing a full Jitter) it isn't much.

That is why I am more interested in Exupery which has quite impressive
numbers to show and promises to become an alternative to C-plugins, and
perhaps more.

regards, Göran