On Tue, 22 Jun 2010, Eliot Miranda wrote:

<snip>

I can't say for sure without profiling (you'll find a good VM profiler
QVMProfiler in the image in the tarball, which as yet works on MacOS only).

This looks promising, I (or someone else :)) just have to implement #primitiveExecutableModulesAndOffsets under win32 (and un*x), but that doesn't seem to be easy (at least the win32 part).

But I expect that the reason is the cost of invoking interpreter primitives
from machine code.  Cog only implements a few primitives in machine code
(arithmetic, at: & block value) and for all others (e.g. nextPut: above) it
executes the interpreter primitives.  lcsFor:and: uses at:put: heavily and
Cog is using the interpreter version.  But the cost of invoking an
interpreter primitive from machine code is higher than invoking it from the
interpreter because of the system-call-like glue between the machine-code
stack pages and the C stack on which the interpreter primitive runs.

Three primitives that are currently interpreter primitives but must be
implemented in machine code for better performance are new/basicNew,
new:/basicNew: and at:put:.  I've avoided implementing these in machine code
because the object representation is so complex and am instead about to
start work on a simpler object representation.  When I have that I'll
implement these primitives and then the speed difference should tilt the
other way.

This sounds reasonable. #lcsFor:and: uses #at:put: twice in the inner loop. One of them (lcss at: max + k + 1 put: lcs) can be eliminated without affecting the computation, because that just stores the results. So without only one #at:put: it took me 2423ms to run the benchmark. Which is still a bit too high. I think only the profiler can help here.

Btw, is MessageTally less accurate with CogVM than with the SqueakVM?

Levente

Of course if anyone would like to implement these in the context of the
current object representation be my guest and report back asap...

best
Eliot

Levente