<br><br><div class="gmail_quote">On Sun, Jun 20, 2010 at 2:23 PM, Lukas Renggli <span dir="ltr"><<a href="mailto:renggli@gmail.com">renggli@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
Thank you Eliot.<br>
<br>
This is wonderful, it feels like I just got a new laptop :-)<br></blockquote><div><br></div><div>:)</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
I noticed some problems in the continuation tests of Seaside<br>
(WAContinuationTest, WAFlowPlatformTest and<br>
WAPartialContinuationTest):<br>
<br>
"Computation has been terminated" in MethodContext>>cannotReturn:<br>
<br>
Is this a known problem? Or is this maybe specific to Pharo on Cog?<br></blockquote><div><br></div><div>This is a known area of problems. From my announcement:</div><div><span class="Apple-style-span" style="font-family: Times; font-size: medium; "><pre style="word-wrap: break-word; white-space: pre-wrap; ">
Status:
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 (<b>for example I know that co-routining does not yet
work</b>). 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.</pre></span></div><div>The use of context-to-stack mapping is fundamental to the performance improvements in Cog and it <i>should</i> 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.</div>
<div> Smalltalk saveAs: 'crash.image' thenQuit: true.</div><div> MyClass crashTheVM</div><div><br></div><div>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.</div>
<div><br></div><div>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</div>
<div> 1 to: n do: [:i|... ]</div><div>very slow because the <font class="Apple-style-span" face="'courier new', monospace">send: #<= (1 arg); jumpFalseTo: L2</font> 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:. </div>
<div><br></div><div>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.</div>
<div><br></div><div><br></div><div>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 involved.</div>
<div><br></div><div>cheers</div><div>Eliot</div></div>