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

Robert Withers robert.w.withers at gmail.com
Mon Oct 19 11:55:44 UTC 2015


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.

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. 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? Certainly the discussion about what 
exactly MT is seems alright.

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.

As well, thanks so much for those links! Those are gold and will be 
reread recursively.

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