how slower is called a named primitive over a numbered primitive?

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.

On Mon, Jun 22, 2015 at 5:13 AM, Esteban Lorenzano <[hidden email]> wrote:

Hi,

Any idea how slower is? I mean, any measure/estimation/something around?

cheers,
Esteban

--

best,

Eliot

 

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…

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

Esteban

On 22 Jun 2015, at 19:16, Clément Bera <[hidden email]> 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 <[hidden email]>:

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 <[hidden email]> 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; [hidden email]; http://www.rowledge.org/tim
> Useful random insult:- Ready to check in at the HaHa Hilton.
>
>

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.

On Mon, Jun 22, 2015 at 5:13 AM, Esteban Lorenzano <[hidden email]> wrote:

Hi,

Any idea how slower is? I mean, any measure/estimation/something around?

cheers,
Esteban

--

best,

Eliot

 
On 23.06.2015, at 18:23, Eliot Miranda <[hidden email]> wrote:
>
> Hi Bert,
>
> On Jun 23, 2015, at 3:38 AM, Bert Freudenberg <[hidden email]> wrote:
>
>> On 23.06.2015, at 02:58, David T. Lewis <[hidden email]> wrote:
>>> On an interpreter VM, the results are as Tim and I initially expected:
>>>
>>> | 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}]
>>>
>>> ==> #(#(791 789) #(793 794) #(793 790) #(791 791) #(790 794) #(795 789))
>>>
>>> With a Cog VM, the numbered primitives are significantly faster:
>>>
>>> | 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}]
>>>
>>> ==> #(#(542 670) #(542 668) #(544 678) #(546 680) #(540 666) #(540 680))
>>
>> Looks like SqueakJS may need some caching for named prim lookup:
>>
>> ((54 535 ) (42 541 ) (42 536 ) (49 542 ) (44 527 ) (44 530 ) )
>
>
> I think this is an inlined apples vs oranges comparison :).  To be that fast surely the JS VM has optimized away the numbered primitive send entirely, leaving only the named primitive send, so this isn't the difference between the two at all.

Haha, no. I removed two zeroes from the iteration count ;)