[Vm-dev] Re: [Pharo-dev] Random forest in Pharo

Esteban Lorenzano estebanlm at gmail.com
Fri Oct 16 12:19:27 UTC 2015


> On 16 Oct 2015, at 14:06, Robert Withers <robert.w.withers at gmail.com> wrote:
> 
> 
> 
> On 10/16/2015 07:58 AM, Esteban Lorenzano wrote:
>> 
>>> On 16 Oct 2015, at 13:53, Esteban Lorenzano <estebanlm at gmail.com> wrote:
>>> 
>>> 
>>>> On 16 Oct 2015, at 13:22, Robert Withers <robert.w.withers at gmail.com> wrote:
>>>> 
>>>> Bonjour Stef,
>>>> 
>>>> I believe the change everyone would be waiting for is a Multi-threaded VM, that supports threaded callouts and callbacks. So I suppose the questions become:
>>> 
>>> multi thread ffi vm exists as a prototype, and according to its author (Eliot) needs no less than 4 months of someone skilled working on it to finish it.
>>> 
>>>> - will existing NB syntax require change with the introduction of a MTVM?
>>> 
>>> nothing will be equal… why? because you will need to provide callbacks. There is no magic here, if you want something to happen while doing something else, you need to provide a way to be called back when that thing finishes.
>>> 
>>> now we have:
>>> 
>>> nbCall:module:
>>> 
>>> to call FFI (will change to a more generic ffiCall:module:, btw… but we’ll keep old notation some versions to provide backward compatibility)
>>> 
>>> So I can imagine an API like this:
>>> 
>>> ffiAsyncCall:callback:module:
>>> 
>>> So yes… you need change. But that’s inevitable… Of course you can do a fwk forking in image and starting a continuation, etc. But well, I will let you guys to think on that (also you still will need the fork) :)
>> 
>> Actually I just remembered that current prototype works attaching external call with an internal Process (with some special id inside).
>> But still, I do not expect call syntax will change at all.
> 
> Are you saying all FFI callouts would become threaded or would there be an unthreaded callout and a threaded callout?  I was assuming the second scenario.

I’m saying *the syntax* will not change. That means, if you want to call memcpy, syntax will still be: #(void *memcpy ( void* dest, void *src))

what can (and will) change is the method invoking it…  ffiCall:module: vs. ffiAsyncCall:callback:module: 

Esteban

> 
> Robert
> 
>> 
>> Esteban
>> 
>>> 
>>>> - to what degree will NB syntax need to be extended to support threaded callouts.
>>> 
>>> as described, I suppose. No exact idea until we implement.
>>> 
>>>> - what NB syntax changes are needed for callbacks.
>>> 
>>> NB used some magic there. Shadow classes and etc. We do not need/want that anymore.
>>> 
>>> now you have a new FFICallback api, where you can do:
>>> 
>>> FFICallback
>>> 		signature: #(int (int handle, int *pitch, int x, int y, int w, int h))
>>> 		block: [ :handle :pitch :x :y :w :h |
>>> 			pitch signedLongAt: 1 put: (self get_stride: handle).
>>> 			self get_data: handle ]
>>> 
>>> (I extracted that example from my ongoing port of Athens)
>>> 
>>>> - timing: when  is MTVM expected and can we operate on the leading edge?
>>> 
>>> we are lacking resources: Is just me (in the Pharo part, of course… Eliot and some others work also in the exclusively VM part, but they have other agendas).
>>> 
>>> So… my plan is:
>>> 
>>> - NB to FFI port (should be ready soon)
>>> - spur32 bits (should be ready soon, we are just waiting the NB to FFI)
>>> - spur64 bits (Eliot is working on the JIT, I need to manage the migration of Pharo)
>>> - FFI 64bits (0% done here… just some stubs waiting for effort). But we want to move Pharo to 64bits… we are losing a train here...
>>> - FFI MT
>>> 
>>> So… not very hight priority. According as how I see things now, I *think* I can have that some point of 2017… yes, as far as that. Also because I have a lot other stuff to do, not just the lowlevel parts.
>>> 
>>> Of course this is not good and we have talked with some people to speed up this. We talked with Igor about taking the MT stuff (yes, we also believe is VERY important), but he fade in the blur… I didn’t hear from him since 3 months (I’m still waiting for some feedback on OSWindow work he did, he)… yes I’m a bit frustrated.
>>> 
>>> If *anyone* wants to collaborate in any part of this list (is a MASSIVE effort), I would be very happy and willing to provide as much assistance/guiding/peer programming as I can.
>>> 
>>> hope this helps
>>> 
>>> Esteban
>>> 
>>>> 
>>>> Personally, in SqueakElib, I have my network and session layers working for encrypted connections, so I just have the presentation layer to go. Once done, I would be very interested in working in the VM with whomever is also interested with an eye towards threading (MTVM). I am no expert here so it will be a challenge I am looking forward to.
>>>> 
>>>> Regards,
>>>> Robert
>>>> 
>>>> On 10/16/2015 06:59 AM, stepharo wrote:
>>>>> 
>>>>> In pharodays presentations we explictly mentioned our strategy:
>>>>>    - we keep NB syntax
>>>>>    - we change the assembly generation to be able to get Spur.
>>>>> 
>>>>> Stef
>>>>> 
>>>>> I can tell you that if I could get a lua kind of jit now I would sign
>>>>> immediately and also for having pharo as a dll.
>>>>> Now it takes time to do soemthing.
>>>>> 
>>>>> Le 15/10/15 17:35, Robert Withers a écrit :
>>>>>> 
>>>>>> I am reticent to invest in learning FFI that is changing without an idea
>>>>>> of the direction of the change. So

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20151016/951f3dd6/attachment-0001.htm


More information about the Vm-dev mailing list