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

[Robert Withers]

Hi Esteban,


On 10/19/2015 05:10 AM, Esteban Lorenzano wrote:
>
> Hi,
>
> just to be clear.
> When we talk about MTVM, we talk about a MT-FFI, *not* a MTVM in general.
> In general, a “common” approach to MT cannot be applied in Pharo (or Smalltalk in general) and to get a VM *and* an image working properly is an effort that makes what I called massive some mails above like a small stone compared to a mountain.

Could you please help me by talking further about the different models 
and scopes of what is meant by MT?

a) MT-FFI I believe gives the developer a way to call and be invoked on 
callback, asynchronously. Is it so?
b) General MTVM means other system services are threaded, like I/O 
events and scheduling and heartbeat.

I think that the right model (my stack/priQueue/pool intuition?) will 
change a Herculean task into a fairly straightfoward task and 
achievable. Change the problem, to get better answers.

I appreciate you and this MT discussion.


> Said that:
>
> - What is in plans is MT-FFI, and that will be available eventually.
> - There is an approach I want to re-work, that would allow us profit of multicores without going multithread: the “hydra” experiment made some years ago by Igor creates a good basis to this. But is also a lot of of work (but a lot less than a complete MT), and not a real priority for now… I hope to resume work on that area some day… just not anytime soon.

Yes, please. I recall those discussions. Hydra is cosmological.

Regards,
Robert

>
> Esteban
>
>> On 18 Oct 2015, at 17:56, Ben Coman <btc at openInWorld.com> wrote:
>>
>>
>> On Sat, Oct 17, 2015 at 2:25 AM, Robert Withers
>> <robert.w.withers at gmail.com> wrote:
>>> Yes, exactly. I do realize I was consciously changing that effort
>>> synchronization order.
>>
>> I see 64-bit being higher priority than multi-threaded for the wider
>> community.  Dealing with larger in-Image data opens the door to more
>> corporate project/funding opportunities. Also simplifying the install
>> on modern Linux platforms without requiring additional 386 libraries
>> will help acceptance there.
>>
>>> It is my humble opinion, without really knowing, that 64-bit would have to be redone after the MTVM completes.
>>
>> I would assume it was the other way around. Presuming that Eliot has
>> sponsors influencing his priorities, it seems given that 64-bits will
>> happen first.   I would guess any MTVM development on the old vm would
>> then need to be reworked.
>>
>>> I was doing so with the idea in mind that I and others
>>> might dig into working on the VM, for threading support, while Eliot
>>> maintains focus on 64-bits...a tall order, I know.
>>
>> The usual downside of splitting resources applies.  There are not that
>> many "others" and maybe they would be drawn away from helping with the
>> 64-bit vm.  If the 64-bit vm goes slower for lack of resources then
>> your footing for MTVM will shifting for a longer time.  You may
>> ultimately get where you want to go faster by helping with the 64-bit
>> vm.  The rapport built with other vm devs from working on 64-bit might
>> could then be applied to MTVM.  (Of course, its your free time, so you
>> should pursue what interests you.)
>>
>>> I was barely familiar with the VM, slang, interpreter, it years ago...
>>> I'm totally unfamiliar with cog.
>>
>> The experience you gain from working beside Esteban and Eliot on
>> 64-bit Cog/Spur could then be applied to a MTVM.
>>
>> btw, you may find these threads interesting...
>> * http://lists.pharo.org/pipermail/pharo-dev_lists.pharo.org/2015-April/108648.html
>> * http://forum.world.st/Copy-on-write-for-a-multithreaded-VM-td4837905.html
>>
>> cheers -ben
>>
>>> I believe another item on that list ought to be modernizing slang. So
>>> many big items!
>>>
>>> Robert
>>>
>>>
>>>
>>> On 10/16/2015 12:48 PM, Stephan Eggermont wrote:
>>>>
>>>>
>>>> On 16-10-15 14:05, Robert Withers wrote:
>>>>>
>>>>> Because of that assumption I've made and without the responsibilities
>>>>> you have, Esteban, but recognizing modernizing NB to FFI, my desired
>>>>> list is:
>>>>
>>>>
>>>> I would expect the least total effort to be needed by keeping the work
>>>> of Esteban and Eliot as much as possible aligned. That is what Esteban's
>>>> list achieves.
>>>>
>>>> Stephan
>>>>
>>>>
>>>
>