[Vm-dev] how slower is called a named primitive over a numbered primitive?

[Eliot Miranda]

Hi Esteban,

On Mon, Jun 22, 2015 at 10:32 AM, Esteban Lorenzano <estebanlm at gmail.com>
wrote:

>
> I’m just trying to understand the cost difference between prim 120 and
> #primitiveCalloutWithArgs so it should be easy to set up a test :)
> but… judging #primitiveDoNamedPrimitiveWithArgs… I suppose something like
> Athens will need a numbered primitive, in order to keep it performant…
>

What Tim said.  Both the Interpreter and the Cogit go to some lengths to
cache named primtiiev calls so that the complex linking machinery is used
only on the first call.  In particular primitiveDoNamedPrimitiveWithArgs is
used only in the debugger to call named primitives.  It *isn't* used at all
in a normal named primitive call.  Only primitiveExternalCall is used on
the *first* invocation of a named primitive.  Subsequent invocations likely
invoke the primitive directly.  If the named primitive gets dropped from
the method cache (or for generated code) but the plugin module has not been
unloaded then the function pointer will still be in the named primitive's
first literal and will be fetched from there, and the method lookup cache
updated to point to the function pointer, avoiding any need to lookup the
name in the plugin module.


but well, after I have numbers I will send a proposition (if needed), to
> remap #primitiveCalloutWithArgs into a number… :P
>

Like I said earlier in the thread, the issue is likely not to do with
numbers.  It is to do with providing the right flags as the result
of primitivePropertyFlagsForSpur: & primitivePropertyFlagsForV3: so that
the Cogit can generate code that is robust in the face of callbacks.  See
SimpleStackBasedCogit>>#compileInterpreterPrimitive:


HTH

P.S.  Great that you're working on the FFI!!


> Esteban
>
>
> On 22 Jun 2015, at 19:16, Clément Bera <bera.clement at gmail.com> wrote:
>
> Well it also depends if the primitive is generated by the JIT. If you
> rewrite SmallInteger>>#+ from primitive 1 to a named primitive the overhead
> will be more important than just the searching/loading/linking because
> the JIT won't compile it to n-code anymore.
>
> So make a test with a primitive not compiled by the JIT.
>
> 2015-06-22 18:35 GMT+02:00 David T. Lewis <lewis at mail.msen.com>:
>
>>
>> That sounds right to me too. But it would be a worthwhile experiment to
>> set up a test to confirm it. Maybe take one or more methods that call
>> numbered primitives, and recode them to call the primitives by name. Then
>> measure and see if anything got slower.
>>
>> Dave
>>
>> >
>> > On 22-06-2015, at 5:13 AM, Esteban Lorenzano <estebanlm at gmail.com>
>> wrote:
>> >
>> >>
>> >> Hi,
>> >>
>> >> Any idea how slower is? I mean, any measure/estimation/something
>> around?
>> >
>> > After the initial searching/loading/linking it should be pretty much
>> > identical. It’s just a jump to a pointed-at program location.
>> >
>> >
>> > tim
>> > --
>> > tim Rowledge; tim at rowledge.org; http://www.rowledge.org/tim
>> > Useful random insult:- Ready to check in at the HaHa Hilton.
>> >
>> >
>>
>>
>>
>
>
>


-- 
best,
Eliot
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20150622/f679d5dc/attachment.htm