On Sat, Jul 05, 2008 at 10:56:19PM +0300, Igor Stasenko wrote:
> 2008/7/5 David T. Lewis <lewis at mail.msen.com>:
> > btw, I do have the memory access methods working now, and with all the slang
> > inlining applied I'm within about 20% of the performance of the interpreter
> > using C macros. It's surprising how many little bugs got flushed out in the
> > process, although I suspect there is not a great deal of demand for a VM that
> > features a 20% performance degradation ;)
> >
> 
> Is there chance that degradation because you broken gnuifier step?
> I experienced same degradation, when gnuifier fails to find and
> replace text in interp.c,
> so gnu-interp.c is just a copy of interp.c w/o modifications.
> 
> If not, then we should blame GCC for being incapable to inline simple things :)

No, it's certainly nothing to blame on gcc or gnuify. I'm using Ian's build tools
without modification. I just rewrote the memory access routines as Smalltalk translated
to C. It was a big step just getting it to work at all (simple though it might sound).

When I first got something working in the form of methods translated to simple C
functions, I was seeing perhaps 40% of the performance of the normal access routines
(CPP macros or static inline functions). By gradually convincing the slang translator
to inline these functions, and by fixing up the various unintended side effects, I'm
now up to the point where I've recovered perhaps 80% of the performance of the
original CPP macros.

I'm pretty happy to have gotten this far with it. I do not yet know if it will be
possible to achieve the performance of the CPP macros, maybe yes maybe no. I'm not
being very scientific about this, just running '0 tinyBenchmarks' as I proceed.

To be clear, the inlining I was referring to is the inline performed by the
Smalltalk to C slang translation process, nothing to do with the later gnuify
phase or anything that gcc might do with it afterwards.

Dave