[Vm-dev] Re: primitiveDigitCompare is slow (was: Re: [squeak-dev] The Inbox: Kernel-dtl.1015.mcz)

Nicolas Cellier nicolas.cellier.aka.nice at gmail.com
Sat Apr 16 22:48:36 UTC 2016


2016-04-17 0:36 GMT+02:00 Levente Uzonyi <leves at caesar.elte.hu>:

>
> I just played around a bit with the code generator and I think there other
> reasons why the code is slow:
> - the use of function calls instead of macros for isIntegerObject,
> slotSizeOf, success, failed, stackValue. I suspect that the VM internally
> uses macros for these in numbered primitives.
>


Hi Levente,
But currently we generate single code source for plugins whatever VM
flavour, so the macro if any should be defined in VM specific repository...
That sounds a bit like what Eliot was suggesting for fetching the class
though (if I understood correctly).

My opinion is that suppressing function call overhead will make little
difference since these calls  are pre-conditions sent once or twice per
primitive.


> - #cDigitCompare:with:len: doesn't get inlined, even though it's a tail
> call. That's probably a limitation of the Slang inliner, or a bug.
>
>
I'm working on Slang type inference and inlining (they are closely bound),
but I don't think it really matters for this specific call. More so for
unsafeDigitAt & co which might be used in tight loops.


> Some functions are generated as static, even though they are never called,
> because they have been inlined during the code generation. E.g.:
> #digitCompareLarge:with:.
> While this doesn't have a direct effect on execution time, it may affect
> the CPU cache.
> I think the best would be to not generate any C code from such methods.
>
>
I wonder if I did not see code for eliminating these... I'll check again.


> Levente
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20160417/8a4e76de/attachment.htm


More information about the Vm-dev mailing list