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

Robert Withers robert.w.withers at gmail.com
Mon Oct 19 23:30:49 UTC 2015


Hi Ben,


... ^^
robert


On 10/19/2015 11:06 AM, Ben Coman wrote:
>
> On Mon, Oct 19, 2015 at 7:55 PM, Robert Withers
> <robert.w.withers at gmail.com> wrote:
>>
>> Thank you for your response, Ben. I'm here to help where I may be helpful,
>> so let me know where. I have interest in the Pi and the ARM simulator was
>> expressed as an area needing more resources. 64-bit is the strategic effort,
>> so if I can help.
>
> You may find these interesting...
> * http://forum.world.st/ARM-Cog-progress-td4827195.html
> * http://markmail.org/message/tfqa4lgriw6xchh3
> * http://www.slideshare.net/esug/pharo-arm-status

Thank you, their in my vm list of reading.

>
>> I'd hope we could agree that whether is goes 64-bit then MT (which is what's
>> up) or MT then 64-bit (as I was so rashly suggesting) there will be an
>> integration cost.
>
> Agreed, but I guess the former shares that cost amongst more people.

Yes, good point. I am happy with having the MY discussion, only at this 
time, and helping the broader effort as you point out so that cost is less.

>
>> As 64-bit is a Spur ObjectMemory effort and MT is a
>> process/stack oriented facet, are they not orthogonal and fairly
>> non-interfering, aside from a few touch points. If there is integration
>> cost, why not proceed in parallel?
>
> Naturally you'll get more support working in an area where the vm devs
> *need* more help, but I can't judge this. I'm not familiar with what
> the interference points might be.
> Maybe this helps...
> http://lists.squeakfoundation.org/pipermail/vm-dev/2014-October/016781.html

Thank you again, for later consumption.

>
>> Certainly the discussion about what exactly MT is seems alright.
>
> Sure.  MT has several meanings.  Its good to scope a common understanding.

Yes, it's good.

>
>> I'm guessing the answer to that you have mentioned: resources. We need a
>> bunch of hardcore CompSci students to catch the fire.
>>
>> Please let me know where I can help best. Rapport is key to team, this I
>> have experienced.
>
> I learn a lot listening in on [vm-dev], but I've still only dabbled
> around the fringe of the vm.  The best reference is Eliot overall and
> Esteban from a Pharo perspective.
> btw, have you seen...
> * http://www.mirandabanda.org/cogblog/cog-projects/

I had seen those. Sista sounds interesting as does an event vm. Isn't 
the event vm solved by the MTVM?

Cheers,
Robert

>
> cheers -ben
>
>
>> Regards,
>> Robert
>>
>>
>> On 10/18/2015 11:56 AM, Ben Coman 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


More information about the Vm-dev mailing list