memory and VM issues

Ed Boyce edboyce at bu.edu
Fri Jul 15 01:46:27 UTC 2005


Alan,

   Upgrade to Croquet 0.3 image.  BigMeshTeapot cranhed the VM for me too
under 0.2 + updates on Linux, but it loads just fine with the 0.3
image.  It also fixes a problem loading the MarsWorld in the
TeapotMorph and other demos that call for it.

       -- Ed

Alan Grimes said:
> 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... =)
>





More information about the Squeak-dev mailing list