[Vm-dev] SiliconSqueak and RISC-V J Extension

David T. Lewis lewis at mail.msen.com
Thu Mar 29 03:53:19 UTC 2018


On Wed, Mar 28, 2018 at 06:25:29PM -0300, Jecel Assumpcao Jr. wrote:
>  
> 
> It would be nice to have data to guide the design of these extensions
> before all this work, but the fact that critical operations are done via
> macros in the OpenSmalltalk VM (as they should!) instead of subroutines
> make it hard to know how much time is spent on PICs or allocating new
> objects, for example.
>

The assumption that cpp macros are faster is one of those things that
we all believe to be true because everyone says it is so.

It ain't necessarily so.

The memory access macros used for the lowest level mapping of object memory
to process memory space are defined in platforms/Cross/vm/sqMemoryAccess.h.
These macros are essential for performance because they affect the efficiency
of memory access operations at the lowest levels of object memory functions.

Wrong.

If you replace the cpp macros with high level Smalltalk (slang), and rely
on the inliner in CCodeGenertor to unroll the Smalltalk into inlined C code,
then the performance of the resulting interpreter is essentially the same
as that of the interpreter implemented with cpp macros.

This is important for two reasons:

1) By getting rid of the cpp macros, you open up the possibility of doing
profiling and debugging of low level functions directly with generated C code
that is not obscured by cpp macros.

2) If you want to look at time spent in individual functions that normally
would be inlined (either because they are cpp macros, or because the
slang inliner unrolled them in similar ways), then you can do so by
disabling the inlining during C code generation. This produces a very
slow VM, but one that can be easily profiled to see time spent in the
individual functions.

I have only ever measured this in the interpreter VM (see package
MemoryAccess in the VMMaker repository), but it would be reasonable to
expect similar results with oscog, at least with respect to the base
interpreter and primitive functions.

Dave
 


More information about the Vm-dev mailing list