Hi Joshua!
I will try to answer a few questions.
"Joshua Scholar" jscholar@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