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

Eliot Miranda eliot.miranda at gmail.com
Mon Jun 22 17:47:41 UTC 2015


On Mon, Jun 22, 2015 at 10:40 AM, Eliot Miranda <eliot.miranda at gmail.com>
wrote:

> Hi Esteban,
>
>     you can set up a test using the LargeInteger comparison primitives.
> They're both named and numberd.  e.g.
>
> 23 primitiveLessThanLargeIntegers
>
> So you can write e.g.
>
> LargePositiveInteger>>#< anInteger
> "Primitive. Compare the receiver with the argument and answer true if
> the receiver is less than the argument. Otherwise answer false. Fail if the
> argument is not a SmallInteger or a LargePositiveInteger less than
> 2-to-the-30th (1073741824).
> Optional. See Object documentation whatIsAPrimitive."
>
> <primitive: 23>
> ^super < anInteger
>
> as
>
> numberedLessThan: anInteger
> "Primitive. Compare the receiver with the argument and answer true if
> the receiver is less than the argument. Otherwise answer false. Fail if the
> argument is not a SmallInteger or a LargePositiveInteger less than
> 2-to-the-30th (1073741824).
> Optional. See Object documentation whatIsAPrimitive."
>
> <primitive: 23>
> ^super < anInteger
>
>
> namedLessThan: anInteger
> "Primitive. Compare the receiver with the argument and answer true if
> the receiver is less than the argument. Otherwise answer false. Fail if the
> argument is not a SmallInteger or a LargePositiveInteger less than
> 2-to-the-30th (1073741824).
> Optional. See Object documentation whatIsAPrimitive."
>
> <primitive: 'primitiveLessThanLargeIntegers'>
> ^super < anInteger
>
> and test it with two suitable large integers.  Will you report back?  I'd
> like to know the answer.  Named primitive invocation should be slightly
> slower.  As Clément says, a return different address is written to the
> stack, overwriting the primitive code, but that return path is essentially
> the same as for numbered primtiives.  So I expect that there will be almost
> no measurable difference.
>
> This is all to do with callbacks.  Numbered primitives are assumed never
> to callback (so far that's a valid assumption).  But named primitives (such
> as an FFI call) may indeed callback and hence, by the time the primitive
> finally returns the code zone may have been compacted and the original
> method containing the callout may have moved.  So the VM can't simply
> return to a primitive that may have called back, and then have that
> primitive's code return form the primitive, because that codee may have
> moved.  The solution is to provide a piece of code at a fixed address that
> returns from a named primitive call, and have the return sequence run that
> code.
>

I should have said that numbered primitives other than 117
(primitiveExternalCall) &  120 (primitiveCalloutToFFI) are assumed never to
call-back.  In fact, the VM code in primitivePropertyFlagsForSpur:
& primitivePropertyFlagsForV3: won't set the required flags to tell the
Cogit to substitute the return address if you use primitiveCalloutWithArgs
as a named primitive instead of 120 as a numbered primitive.  So please use
120.  Anyway, the test should demonstrate that there's no difference.

If you /do/ want to use primitiveCalloutWithArgs instead of 120 then
primitivePropertyFlagsForSpur:
& primitivePropertyFlagsForV3: are going to get more complicated.  The
system is currently setup for the FFP plugin to be unloaded and hence the
system made secure by not shipping the FFI plugin.  But including a
reference to primitiveCalloutWithArgs in the main VM needs to be done
carefully to avoid having to link the FFI plugin into the VM.  So this
should be done with e.g. a
    self cppIf: PharoVM ifTrue: ...
idiom.


> On Mon, Jun 22, 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?
>>
>> cheers,
>> Esteban
>>
>>
>
>
> --
> best,
> Eliot
>



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


More information about the Vm-dev mailing list