On Sun, Jul 31, 2011 at 11:31 AM, Stefan Marr <squeak@stefan-marr.de> wrote:

On 31/07/11 17:25, David T. Lewis wrote:

On Sun, Jul 31, 2011 at 04:38:39PM +0200, Stefan Marr wrote:
Any guess what the reason could be why the C compiler fails to do proper
inlineing?
I cannot really say, and I am not much of an expert of C compilers.
For the most part I was just concerned with the slang inliner itself
when I was doing this (it needed some tweaks and fixes before I could
get MemoryAccess to work properly). I was very impressed with how well
the slang inliner actually worked in practice, though I cannot say too
much about what it might take to get a C compiler to achieve similar
results. To be honest I would not much care about it, given how well
the slang inlining already works, and given that it is generating C
code that will work well on most any compiler. I also like the fact
that it is 100% Smalltalk, and does not rely on any hidden magic in
the external compiler.

Well, the interesting question for me is, does it pay of in terms of some percent speedup if I walk over the RoarVM codebase and add some more inline/force_inline hints here and there.

Perhaps I should just try it, the only question then is, where to start, and where to stop ;)

The experiment to do is to modify Slang so that you can get it to do no inlining but add the inline keyword to all methods marked inline and compare the performance of the C compiler inlined code vs the Slang inlined code. However, given Roar has architectural overheads I'd also do this experiment on the base interpreter.

Thanks
Stefan

Dave