Random forest in Pharo
Locked
123
123
Re: [Vm-dev] Re: Random forest in Pharo
 
|
Hi Ben,
... ^^ robert On 10/19/2015 11:06 AM, Ben Coman wrote: > > On Mon, Oct 19, 2015 at 7:55 PM, Robert Withers > <[hidden email]> 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 >>> <[hidden email]> 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 |
Re: [Vm-dev] Re: Random forest in Pharo
|
|
In reply to this post by Eliot Miranda-2
Hi Ken, I have this very paper on my desk, printed out from (alas, much) earlier in the year. Anyone who has energy to address this would be very very welcome. Writing a concurrent incremental mark-sweep that handles ephemeron is the task. Making it function both in small bursts, e.g. after scavenging, and in its own thread is I think important; a non-threaded solution can be extremely efficient in certain contexts. On Mon, Oct 19, 2015 at 12:04 PM, KenD <[hidden email]> wrote: On Mon, 19 Oct 2015 07:10:31 -0700 _,,,^..^,,,_ best, Eliot |
Re: [Vm-dev] Re: Random forest in Pharo
|
|
In reply to this post by Eliot Miranda-2
On Mon, Oct 19, 2015 at 11:05 PM, Ryan Macnak <[hidden email]> wrote:
It is conceptually simpler. It supports experiments more easily than the StackInterpreter. It reflects the language specification in the blue book and the image-level meta-circular interpreter much more closely. _,,,^..^,,,_ best, Eliot |
«
Return to Pharo Smalltalk Developers
|
1 view|%1 views
| Free forum by Nabble | Edit this page |