On Mon, Oct 19, 2015 at 7:55 PM, Robert Withers robert.w.withers@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
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.
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
Certainly the discussion about what exactly MT is seems alright.
Sure. MT has several meanings. Its good to scope a common understanding.
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/
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@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...
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