[etoys-dev] Re: [squeak-dev] Teleplace Cog VMs are now available
eliot.miranda at gmail.com
Sun Jun 20 17:47:45 EDT 2010
On Sun, Jun 20, 2010 at 2:23 PM, Lukas Renggli <renggli at gmail.com> wrote:
> Thank you Eliot.
> This is wonderful, it feels like I just got a new laptop :-)
> I noticed some problems in the continuation tests of Seaside
> (WAContinuationTest, WAFlowPlatformTest and
> "Computation has been terminated" in MethodContext>>cannotReturn:
> Is this a known problem? Or is this maybe specific to Pharo on Cog?
This is a known area of problems. From my announcement:
The Cogit VM has been our sole VM at Teleplace for nearly a year. We do
occasionally find bugs and there are almost certainly areas of functionality
that we have not touched (*for example I know that co-routining does not yet
work*). If you find a bug please try and create a reproducible test case and
let me know. I can't promise to take a look or fix it but I am motivated to do
so and will try my best as time allows. Better still if you find and fix bugs
be sure to let me know.
The use of context-to-stack mapping is fundamental to the performance
improvements in Cog and it *should* be transparent, but so far I've only
fixed what issues we've encountered in our usage at Teleplace. I expect the
next few weeks to involve some bug fixing as it is used in a much broader
context (no pun intended). Y'all can help by giving me reproducible test
cases. This can be in the form of a precise specification of an image
configuration and a doit, but even easier is to save an image that exhibits
the crash on start-up. e.g.
Smalltalk saveAs: 'crash.image' thenQuit: true.
I also need to write the sequence of blog posts on the JIT I've been meaning
to write for over a year now, as others will want to understand and, I hope,
port Cog to other processors.
There's also the need to improve performance. Right now the code generator
is a very naive JIT where every there is no inter-bytecode optimization and
hence every push or pop in the bytecode is reflected in a real push or pop
in the native code. This makes loops such as
1 to: n do: [:i|... ]
very slow because the send: #<= (1 arg); jumpFalseTo: L2 in the underlying
code actually runs a non-inlined SmallInteger <= primitive which pushes the
actual true object, which the jump bytecode must compare against the actual
true false object. In the VisualWorks code generator the JIT spits out two
paths here, one that tests or SmallIntegers and then does the comparison and
jump directly branching on the condition codes. Consequently loops in
VsualWorks are much faster. Also, the object representation is convoluted,
compact classes being OK for reducing space overhead but bad at creating
overhead and complexity, so much so that Cog as yet lacks machine code
primitives for instance creation and at:put:.
So I hope that soon we'll upgrade the code generator and the object
representation and will see another significant jump in compute performance
to bring us up to VisualWorks levels. I hope that we'll also start working
on inlining and get the fastest Smalltalk VM ever. We have a really
exciting opportunity here with Exupery and Igor's Native Boost to do
inlining in a Klein-like way, i.e. having SMalltalk code do inlining and
code optimization. The only concern here is portability; keeping an
intermediate bytecode might be wise. But we'll see. I'm also going to be
working on the FFI, in part with my GSoC student, but also in Teleplace
where I have threaded/non-blocking/overlapped calls woking in prototype
form, but as yet lack proper calbacks.
So that speculation aside please do prepare reproducible cases of crashes or
differences in behaviour between the current VM and Cog (I've just
remembered that another difference is that Cog will produce Float infinity
for 1.0/0.0 instead of failing). Crashes need to be fixed. Some semantic
issues may need to change (for example I think the floating-point behaviour
is better, does this need a flag to control as in VisualWorks's case, etc).
But Cog being available is only the beginning, and now we can all be
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the etoys-dev