I want to jump on this debate with a healthy MEE TOOO!!!

If Squeak is going to make it bigtime, it's VM has to stop sucking.

One very noteworthy example is that I would like to see what Croquet's
"Big Mesh Teapot" looks like but each time I try, the VM either crashes
or locks up!

Performance wise, I could go out and pay for a double-dual core (or even
quad-dual core for that matter) Opteron and wind up with a measly Athlon
64 as far as the VM is concerned.

There was a discussion about preemptive tasking in the image (that would
permit the image to run on a threaded VM) a few weeks ago but the few
(and I really mean few as in there are only a dozen people on this
planet who are qualified to actually do significant changes to the VM)
people who could make the improvements refused to by pointing out that
there was a simple hack that could make the priority-based scheduler
behave as if it were a preemptive scheduler... -- Of course that does
absolutely nothing to address the issues of data-exclusivity that is
required to make the thing truly "GO"...

And when I say Go, I mean when I tried to multithread a Nintendo 64
emulator (interpreter) I didn't get all that great results but what I
did get was 80-100% faster than it was beforehand,...

As for the VM code itself, it has one of the weirdest source layouts
I've ever seen. I tried to even look at it with Kdevelop and couldn't
make much progress. The source itself is undocumented (or only
documented in books sufficiently old as to have major inacuracies) --
Really, the documentation should be with (but not in!) the source itself!

It is long overdue for a major design review. -- Glancing through a
number of the source files indicates missing functionality in the Unix
VM (in MIDI playback). and a number of other deficiencies. -- XINE-Lib
is the de-facto standard for playing media files-- even playing DVDs
with a marginally legal descrambler, yet still it comes bundled with an
obsolete version of an obscure MPEG plugin... =\

Ideally, ffi can be overhauled into an efficient means for calling
external libraries and thereby obsolete most of the current VM code
while giving squeak access to high-performance math and graphics
libraries... (Croquet is an early example of a system that uses this
approach, albeit in a somewhat impractical manner.)

FFI does have its limitations on UNIX, meaning that the VM will have to
be restarted to upgrade to new versions of libraries. On operating
systems that Don't Suck(TM), (such as BeOS), a Squeak VM can, in theory,
run indefinitely because it can load and unload library "images" at
will. -- Of course the quality of the VM code will need to improve to
the point where that is feasible...

Another impediment is that the unix sources have been unstable for at
least the last six months. That is, I cannot produce a working (or even
non-working!) VM with Squeak3.8, the latest sources on Squeakmap, and
the SVN head...

Another issue, that doesn't have anything to do with squeak, is that the
default Linux compiler is continuing to get worse at an exponential
rate. The current stable release (3.4.4 at the time of this writing)
produces code that's 50% slower than 3.3.4. =(


In conclusion, I have alot of hope for the future of Squeak. I am
eagerly looking forward to experimenting with AI development on
Croquet... =)