UFFI/Sista/Scorch

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

UFFI/Sista/Scorch

Ben Coman

Just curious regarding Slide 16 [1] which indicates UFFI sequence is...
1. Generate bytecodes for marshalling
2. Re-send method invocation

Do the bytecodes get cached so that (1.) is only down once?

What impact is Sista/Scorch expected to have on UFFI?
Considering for example that the commonly used method...
    ffiCall: fnSpec
^ (self ffiCalloutIn: thisContext sender)
convention: self ffiCallingConvention;
function: fnSpec module: self ffiLibraryName
...has several message sends.



btw, Slide 2 gave me a nice chuckle to start the day.  Stabilization is a difficult/boring task with highly visible issues which Esteban bears the brunt of dealing with, along with accompanying pressures.  I'd like to take this random opportunity to thank Esteban for his continuing efforts, and also previous Consortium engineers (Igor) and those supporting them.  We wouldn't be where we are today without such a focal point.

cheers -ben
Reply | Threaded
Open this post in threaded view
|

Re: UFFI/Sista/Scorch

EstebanLM


On 13 Nov 2017, at 22:30, Ben Coman <[hidden email]> wrote:


Just curious regarding Slide 16 [1] which indicates UFFI sequence is...
1. Generate bytecodes for marshalling
2. Re-send method invocation

Do the bytecodes get cached so that (1.) is only down once?

What impact is Sista/Scorch expected to have on UFFI?
Considering for example that the commonly used method...
    ffiCall: fnSpec
^ (self ffiCalloutIn: thisContext sender)
convention: self ffiCallingConvention;
function: fnSpec module: self ffiLibraryName
...has several message sends.


we still do not sit to solve the problem, but we have a strategy: SISTA bytecode set contains bytecodes to invoque primitives which means possible to do a primitive call inside a method (it does not needs to be an independent method). This way, the optimiser can work also on methods that ends on primitives. 
As far as I know, adapting to SISTA will not be very complicated. But of course, there will be some work needed.


btw, Slide 2 gave me a nice chuckle to start the day.  Stabilization is a difficult/boring task with highly visible issues which Esteban bears the brunt of dealing with, along with accompanying pressures.  I'd like to take this random opportunity to thank Esteban for his continuing efforts, and also previous Consortium engineers (Igor) and those supporting them.  We wouldn't be where we are today without such a focal point.

thanks :)

Esteban


cheers -ben

Reply | Threaded
Open this post in threaded view
|

Re: UFFI/Sista/Scorch

Clément Bera-4
Hi Ben,

This is the work that Ronie did. You have lower level bytecodes in the SistaV1 bytecode set which can be used for parameters marshalling. Ronie has a prototype where the marshalling of FFI calls is generated image-side once and reused for all calls.

For now, if Scorch does not recognise the primitive (and it does not recognise FFI calls), the send is just marked as non inlineable. Hence this works but is not really optimised.

Cheers


On Tue, Nov 14, 2017 at 11:48 AM, Esteban Lorenzano <[hidden email]> wrote:


On 13 Nov 2017, at 22:30, Ben Coman <[hidden email]> wrote:


Just curious regarding Slide 16 [1] which indicates UFFI sequence is...
1. Generate bytecodes for marshalling
2. Re-send method invocation

Do the bytecodes get cached so that (1.) is only down once?

What impact is Sista/Scorch expected to have on UFFI?
Considering for example that the commonly used method...
    ffiCall: fnSpec
^ (self ffiCalloutIn: thisContext sender)
convention: self ffiCallingConvention;
function: fnSpec module: self ffiLibraryName
...has several message sends.


we still do not sit to solve the problem, but we have a strategy: SISTA bytecode set contains bytecodes to invoque primitives which means possible to do a primitive call inside a method (it does not needs to be an independent method). This way, the optimiser can work also on methods that ends on primitives. 
As far as I know, adapting to SISTA will not be very complicated. But of course, there will be some work needed.


btw, Slide 2 gave me a nice chuckle to start the day.  Stabilization is a difficult/boring task with highly visible issues which Esteban bears the brunt of dealing with, along with accompanying pressures.  I'd like to take this random opportunity to thank Esteban for his continuing efforts, and also previous Consortium engineers (Igor) and those supporting them.  We wouldn't be where we are today without such a focal point.

thanks :)

Esteban


cheers -ben




--
Clément Béra
Pharo consortium engineer
Bâtiment B 40, avenue Halley 59650 Villeneuve d'Ascq