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

[Eliot Miranda]

On Mon, Jun 22, 2015 at 9:35 AM, David T. Lewis <lewis at mail.msen.com> wrote:

>
> 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 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.
>

Wow, it is indeed a significant difference.  Substituting the return
address must invoke all sorts of cost in an x86 cpu.  Here are 2 x 5 runs


| i | i := SmallInteger maxVal + 1.
(1 to: 6) collect: [:j| {[1 to: 10000000 do: [:k| i numberedLessThan: i]]
timeToRun. [1 to: 10000000 do: [:k| i namedLessThan: i]] timeToRun}]

#(#(191 283) #(211 375) #(281 405) #(300 411) #(281 421) #(296 409))
#(#(186 267) #(201 273) #(210 364) #(294 410) #(313 400) #(292 405))

So the overhead is of the order of (100ms / 10,000,000) per call.  e.g.
around 10ns per named primitive call.  Interesting :-)


>
> 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.
>
> 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/f411b3d3/attachment.htm