Smalltalk › Pharo › Pharo Smalltalk Developers

Random forest in Pharo

‹ Previous Topic Next Topic ›
 
classic Classic list List threaded Threaded
♦
♦
 43 messages Options
123
Robert Withers
Reply | Threaded
Open this post in threaded view
♦
♦
|

Re: Mult-language browsers - MLB

Robert Withers
Thanks for your reply, Torsten. This looks really interesting and in
Pharo, as well.  It's in my little list of links for this topic.

cheers,
Robert

On 10/15/2015 05:29 PM, Torsten Bergmann wrote:

> Hi Robert,
>
> did you see http://scg.unibe.ch/research/helvetia?
>
> Bye
> T.
>
>> Gesendet: Donnerstag, 15. Oktober 2015 um 18:33 Uhr
>> Von: "Robert Withers" <[hidden email]>
>> An: [hidden email]
>> Betreff: [Pharo-dev] Mult-language browsers - MLB (was: Re: Random forest in Pharo)
>>
>>
>>
>> On 10/15/2015 11:57 AM, Robert Withers wrote:
>>>
>>>
>>> On 10/15/2015 11:46 AM, Esteban Lorenzano wrote:
>>>>
>>>> but well… in the mean time we learn and do steps. We will have a cool
>>>> FFI, don’t worry… sooner than later :D
>>>
>>> I was thinking about ASMJIT and it's audience. You may attract a broader
>>> audience with JVMJIT, including JNI. That would be something, then
>>> support cross-calling between Pharo, Newspeak, Groovy, Scala and Java
>>> plus dynamic jar loading. You'd need an army to pull that off though.
>>
>> Please excuse the reply to the reply, but I was thinking about a JVMJIT
>> and cross-calling. The key to me, experientially, is to have the same
>> browser for all languages. We need a multi-language browser, a MLB.
>>
>> Depending on the CompiledMethod selected, pick the right set of parsers:
>> compiler, pretty printer, code completion, type inferencer and the MLB's
>> method pane would be an editor for the language specified in the
>> compiled method.
>>
>> Furthermore, to support cross-calling, when you are working is a
>> specific language, you can set that as the interaction language and the
>> browser will present interfaces from other languages in the language you
>> have selected, such that a cross-call is really just a native call to an
>> auto-generated wrapper around the other language.
>>
>> Think of Cincom's Distributed Smalltalk talking Corba with their I3
>> (Implicit Invocation Interface):
>> http://www.cincomsmalltalk.com/main/documentation/VisualWorks/DSTAppDevGuide.pdf
>>
>> I found this thread on Corba and Squeak:
>> http://squeak-dev.squeakfoundation.narkive.com/AbWTL8Kh/smalltalk-and-corba.
>> Bringing I3 support, into the browser would offer the foundations for
>> the MLB.
>>
>> Any feedback is really appreciated!
>>
>> Regards,
>> Robert
>>
>>
>

stepharo
Reply | Threaded
Open this post in threaded view
♦
♦
|

Re: Random forest in Pharo

stepharo
In reply to this post by EstebanLM
Personally I do not want to be forced to deploy R or whatever when I deploy Pharo. Period.
We have enough dependencies to external libraries dll and other.
If for one of your project you want to use a hyper cool super hyper coool external libraries then perfect. Not for Pharo.

Now we should focus on what is important for core pharo and my remark is about the core.

About the FFI, would be good that people stop complaining and help.
    We supported Igor NB (Laurent wrote a tutorial that I spent time to revisit even if I never did a FFI call) so where were you?

    Where are you pharoers when it is about to write something for the community?

    For your information we are in discussion with ronie (I do not know the status of his back-end),
    esteban spent 4 months working on a new FFI front-end using NB syntax and back end using FFI. The idea is that we can plug the back-end of ronie.

    Our team on his **own** money will invite ronie to work with us (Now we lost the money of our of our sponsors so times will be difficult).

Stef


Le 15/10/15 14:18, Esteban Lorenzano a écrit :
yeah but if this is a special case there is no problems on doing FFI bindings and using an external library. 
Precisely for that is FFI.

not that we have to integrate everything into the image :)

but… I would not be so fast in assume pharo performance will not be enough. Unique form to know it is to do it and then see how you can optimise, if needed :)

Esteban

On 15 Oct 2015, at 09:51, stepharo <[hidden email]> wrote:

We do not want to be bound to install and maintain connection with fifteen different libs.

Stef

Le 14/10/15 18:01, [hidden email] a écrit :

Not sure you would get enough performance on Pharo per se. Xe may be better off leveraging a multicore enabled external lib. Like caret and doMC on R.

Le 14 oct. 2015 17:49, "Serge Stinckwich" <[hidden email]> a écrit :
I don't think so.

I followup your message on SciSmalltalk mailing-list.
This is something that might interested us ;-)



On Wed, Oct 14, 2015 at 4:54 PM, Damien Cassou <[hidden email]> wrote:
> Hi,
>
> did anyone implement a Random Forest algorithm in Pharo?
>
>     https://en.wikipedia.org/wiki/Random_forest
>
> --
> Damien Cassou
> http://damiencassou.seasidehosting.st
>
> "Success is the ability to go from one failure to another without
> losing enthusiasm." --Winston Churchill
>



--
Serge Stinckwich
UCBN & UMI UMMISCO 209 (IRD/UPMC)
Every DSL ends up being Smalltalk
http://www.doesnotunderstand.org/
stepharo
Reply | Threaded
Open this post in threaded view
♦
♦
|

Re: Random forest in Pharo

stepharo
In reply to this post by Robert Withers

In pharodays presentations we explictly mentioned our strategy:
     - we keep NB syntax
     - we change the assembly generation to be able to get Spur.

Stef

I can tell you that if I could get a lua kind of jit now I would sign
immediately and also for having pharo as a dll.
Now it takes time to do soemthing.

Le 15/10/15 17:35, Robert Withers a écrit :
>
> I am reticent to invest in learning FFI that is changing without an idea
> of the direction of the change. So


Robert Withers
Reply | Threaded
Open this post in threaded view
♦
♦
|

Re: Random forest in Pharo

Robert Withers
Bonjour Stef,

I believe the change everyone would be waiting for is a Multi-threaded
VM, that supports threaded callouts and callbacks. So I suppose the
questions become:
- will existing NB syntax require change with the introduction of a MTVM?
- to what degree will NB syntax need to be extended to support threaded
callouts.
- what NB syntax changes are needed for callbacks.
- timing: when  is MTVM expected and can we operate on the leading edge?

Personally, in SqueakElib, I have my network and session layers working
for encrypted connections, so I just have the presentation layer to go.
Once done, I would be very interested in working in the VM with whomever
is also interested with an eye towards threading (MTVM). I am no expert
here so it will be a challenge I am looking forward to.

Regards,
Robert

On 10/16/2015 06:59 AM, stepharo wrote:

>
> In pharodays presentations we explictly mentioned our strategy:
>      - we keep NB syntax
>      - we change the assembly generation to be able to get Spur.
>
> Stef
>
> I can tell you that if I could get a lua kind of jit now I would sign
> immediately and also for having pharo as a dll.
> Now it takes time to do soemthing.
>
> Le 15/10/15 17:35, Robert Withers a écrit :
>>
>> I am reticent to invest in learning FFI that is changing without an idea
>> of the direction of the change. So
>
>

philippeback
Reply | Threaded
Open this post in threaded view
♦
♦
|

Re: Random forest in Pharo

philippeback
In reply to this post by stepharo


On Fri, Oct 16, 2015 at 12:56 PM, stepharo <[hidden email]> wrote:
Personally I do not want to be forced to deploy R or whatever when I deploy Pharo. Period.
We have enough dependencies to external libraries dll and other.
If for one of your project you want to use a hyper cool super hyper coool external libraries then perfect. Not for Pharo.

Now we should focus on what is important for core pharo and my remark is about the core.

About the FFI, would be good that people stop complaining and help.
    We supported Igor NB (Laurent wrote a tutorial that I spent time to revisit even if I never did a FFI call) so where were you?

Actually reading it and putting it to use in a project.


    Where are you pharoers when it is about to write something for the community?

    For your information we are in discussion with ronie (I do not know the status of his back-end),
    esteban spent 4 months working on a new FFI front-end using NB syntax and back end using FFI. The idea is that we can plug the back-end of ronie.

    Our team on his **own** money will invite ronie to work with us (Now we lost the money of our of our sponsors so times will be difficult).

One more reason to make money with Pharo and leverage what's out there in terms of capabilities.
Going to use Pharo in a hackathon next monday. I'll see if I can get things done or be buried into the ground by the people using other tech. 

Stef


Le 15/10/15 14:18, Esteban Lorenzano a écrit :
yeah but if this is a special case there is no problems on doing FFI bindings and using an external library. 
Precisely for that is FFI.

not that we have to integrate everything into the image :)

but… I would not be so fast in assume pharo performance will not be enough. Unique form to know it is to do it and then see how you can optimise, if needed :)

Esteban

On 15 Oct 2015, at 09:51, stepharo <[hidden email][hidden email]> wrote:

We do not want to be bound to install and maintain connection with fifteen different libs.

Stef

Le 14/10/15 18:01, [hidden email][hidden email] a écrit :

Not sure you would get enough performance on Pharo per se. Xe may be better off leveraging a multicore enabled external lib. Like caret and doMC on R.

Le 14 oct. 2015 17:49, "Serge Stinckwich" <[hidden email]> a écrit :
I don't think so.

I followup your message on SciSmalltalk mailing-list.
This is something that might interested us ;-)



On Wed, Oct 14, 2015 at 4:54 PM, Damien Cassou <[hidden email]> wrote:
> Hi,
>
> did anyone implement a Random Forest algorithm in Pharo?
>
>     https://en.wikipedia.org/wiki/Random_forest
>
> --
> Damien Cassou
> http://damiencassou.seasidehosting.st
>
> "Success is the ability to go from one failure to another without
> losing enthusiasm." --Winston Churchill
>



--
Serge Stinckwich
UCBN & UMI UMMISCO 209 (IRD/UPMC)
Every DSL ends up being Smalltalk
http://www.doesnotunderstand.org/
EstebanLM
Reply | Threaded
Open this post in threaded view
♦
♦
|

Re: Random forest in Pharo

EstebanLM
In reply to this post by stepharo

On 16 Oct 2015, at 12:56, stepharo <[hidden email]> wrote:

Personally I do not want to be forced to deploy R or whatever when I deploy Pharo. Period.
but why would you?
now… if you have to use a special function, you might need to install a package+an external library. 


We have enough dependencies to external libraries dll and other.
If for one of your project you want to use a hyper cool super hyper coool external libraries then perfect. Not for Pharo.
no one said this is going to be in Pharo, AFAIR


Now we should focus on what is important for core pharo and my remark is about the core.

About the FFI, would be good that people stop complaining and help.
    We supported Igor NB (Laurent wrote a tutorial that I spent time to revisit even if I never did a FFI call) so where were you?

    Where are you pharoers when it is about to write something for the community?

    For your information we are in discussion with ronie (I do not know the status of his back-end),
    esteban spent 4 months working on a new FFI front-end using NB syntax and back end using FFI. The idea is that we can plug the back-end of ronie.

    Our team on his **own** money will invite ronie to work with us (Now we lost the money of our of our sponsors so times will be difficult).

Stef


Le 15/10/15 14:18, Esteban Lorenzano a écrit :
yeah but if this is a special case there is no problems on doing FFI bindings and using an external library. 
Precisely for that is FFI.

not that we have to integrate everything into the image :)

but… I would not be so fast in assume pharo performance will not be enough. Unique form to know it is to do it and then see how you can optimise, if needed :)

Esteban

On 15 Oct 2015, at 09:51, stepharo <[hidden email][hidden email]> wrote:

We do not want to be bound to install and maintain connection with fifteen different libs.

Stef

Le 14/10/15 18:01, [hidden email][hidden email] a écrit :

Not sure you would get enough performance on Pharo per se. Xe may be better off leveraging a multicore enabled external lib. Like caret and doMC on R.

Le 14 oct. 2015 17:49, "Serge Stinckwich" <[hidden email]> a écrit :
I don't think so.

I followup your message on SciSmalltalk mailing-list.
This is something that might interested us ;-)



On Wed, Oct 14, 2015 at 4:54 PM, Damien Cassou <[hidden email]> wrote:
> Hi,
>
> did anyone implement a Random Forest algorithm in Pharo?
>
>     https://en.wikipedia.org/wiki/Random_forest
>
> --
> Damien Cassou
> http://damiencassou.seasidehosting.st
>
> "Success is the ability to go from one failure to another without
> losing enthusiasm." --Winston Churchill
>



--
Serge Stinckwich
UCBN & UMI UMMISCO 209 (IRD/UPMC)
Every DSL ends up being Smalltalk
http://www.doesnotunderstand.org/
EstebanLM
Reply | Threaded
Open this post in threaded view
♦
♦
|

Re: Random forest in Pharo

EstebanLM
In reply to this post by Robert Withers

> On 16 Oct 2015, at 13:22, Robert Withers <[hidden email]> wrote:
>
> Bonjour Stef,
>
> I believe the change everyone would be waiting for is a Multi-threaded VM, that supports threaded callouts and callbacks. So I suppose the questions become:

multi thread ffi vm exists as a prototype, and according to its author (Eliot) needs no less than 4 months of someone skilled working on it to finish it.

> - will existing NB syntax require change with the introduction of a MTVM?

nothing will be equal… why? because you will need to provide callbacks. There is no magic here, if you want something to happen while doing something else, you need to provide a way to be called back when that thing finishes.

now we have:

nbCall:module:

to call FFI (will change to a more generic ffiCall:module:, btw… but we’ll keep old notation some versions to provide backward compatibility)

So I can imagine an API like this:

ffiAsyncCall:callback:module:

So yes… you need change. But that’s inevitable… Of course you can do a fwk forking in image and starting a continuation, etc. But well, I will let you guys to think on that (also you still will need the fork) :)

> - to what degree will NB syntax need to be extended to support threaded callouts.

as described, I suppose. No exact idea until we implement.

> - what NB syntax changes are needed for callbacks.

NB used some magic there. Shadow classes and etc. We do not need/want that anymore.

now you have a new FFICallback api, where you can do:

FFICallback
                signature: #(int (int handle, int *pitch, int x, int y, int w, int h))
                block: [ :handle :pitch :x :y :w :h |
                        pitch signedLongAt: 1 put: (self get_stride: handle).
                        self get_data: handle ]

(I extracted that example from my ongoing port of Athens)

> - timing: when  is MTVM expected and can we operate on the leading edge?

we are lacking resources: Is just me (in the Pharo part, of course… Eliot and some others work also in the exclusively VM part, but they have other agendas).

So… my plan is:

- NB to FFI port (should be ready soon)
- spur32 bits (should be ready soon, we are just waiting the NB to FFI)
- spur64 bits (Eliot is working on the JIT, I need to manage the migration of Pharo)
- FFI 64bits (0% done here… just some stubs waiting for effort). But we want to move Pharo to 64bits… we are losing a train here...
- FFI MT

So… not very hight priority. According as how I see things now, I *think* I can have that some point of 2017… yes, as far as that. Also because I have a lot other stuff to do, not just the lowlevel parts.

Of course this is not good and we have talked with some people to speed up this. We talked with Igor about taking the MT stuff (yes, we also believe is VERY important), but he fade in the blur… I didn’t hear from him since 3 months (I’m still waiting for some feedback on OSWindow work he did, he)… yes I’m a bit frustrated.

If *anyone* wants to collaborate in any part of this list (is a MASSIVE effort), I would be very happy and willing to provide as much assistance/guiding/peer programming as I can.

hope this helps

Esteban

>
> Personally, in SqueakElib, I have my network and session layers working for encrypted connections, so I just have the presentation layer to go. Once done, I would be very interested in working in the VM with whomever is also interested with an eye towards threading (MTVM). I am no expert here so it will be a challenge I am looking forward to.
>
> Regards,
> Robert
>
> On 10/16/2015 06:59 AM, stepharo wrote:
>>
>> In pharodays presentations we explictly mentioned our strategy:
>>     - we keep NB syntax
>>     - we change the assembly generation to be able to get Spur.
>>
>> Stef
>>
>> I can tell you that if I could get a lua kind of jit now I would sign
>> immediately and also for having pharo as a dll.
>> Now it takes time to do soemthing.
>>
>> Le 15/10/15 17:35, Robert Withers a écrit :
>>>
>>> I am reticent to invest in learning FFI that is changing without an idea
>>> of the direction of the change. So
>>
>>
>


EstebanLM
Reply | Threaded
Open this post in threaded view
♦
♦
|

Re: Random forest in Pharo

EstebanLM

> On 16 Oct 2015, at 13:53, Esteban Lorenzano <[hidden email]> wrote:
>
>
>> On 16 Oct 2015, at 13:22, Robert Withers <[hidden email]> wrote:
>>
>> Bonjour Stef,
>>
>> I believe the change everyone would be waiting for is a Multi-threaded VM, that supports threaded callouts and callbacks. So I suppose the questions become:
>
> multi thread ffi vm exists as a prototype, and according to its author (Eliot) needs no less than 4 months of someone skilled working on it to finish it.
>
>> - will existing NB syntax require change with the introduction of a MTVM?
>
> nothing will be equal… why? because you will need to provide callbacks. There is no magic here, if you want something to happen while doing something else, you need to provide a way to be called back when that thing finishes.
>
> now we have:
>
> nbCall:module:
>
> to call FFI (will change to a more generic ffiCall:module:, btw… but we’ll keep old notation some versions to provide backward compatibility)
>
> So I can imagine an API like this:
>
> ffiAsyncCall:callback:module:
>
> So yes… you need change. But that’s inevitable… Of course you can do a fwk forking in image and starting a continuation, etc. But well, I will let you guys to think on that (also you still will need the fork) :)

Actually I just remembered that current prototype works attaching external call with an internal Process (with some special id inside).
But still, I do not expect call syntax will change at all.

Esteban

>
>> - to what degree will NB syntax need to be extended to support threaded callouts.
>
> as described, I suppose. No exact idea until we implement.
>
>> - what NB syntax changes are needed for callbacks.
>
> NB used some magic there. Shadow classes and etc. We do not need/want that anymore.
>
> now you have a new FFICallback api, where you can do:
>
> FFICallback
> signature: #(int (int handle, int *pitch, int x, int y, int w, int h))
> block: [ :handle :pitch :x :y :w :h |
> pitch signedLongAt: 1 put: (self get_stride: handle).
> self get_data: handle ]
>
> (I extracted that example from my ongoing port of Athens)
>
>> - timing: when  is MTVM expected and can we operate on the leading edge?
>
> we are lacking resources: Is just me (in the Pharo part, of course… Eliot and some others work also in the exclusively VM part, but they have other agendas).
>
> So… my plan is:
>
> - NB to FFI port (should be ready soon)
> - spur32 bits (should be ready soon, we are just waiting the NB to FFI)
> - spur64 bits (Eliot is working on the JIT, I need to manage the migration of Pharo)
> - FFI 64bits (0% done here… just some stubs waiting for effort). But we want to move Pharo to 64bits… we are losing a train here...
> - FFI MT
>
> So… not very hight priority. According as how I see things now, I *think* I can have that some point of 2017… yes, as far as that. Also because I have a lot other stuff to do, not just the lowlevel parts.
>
> Of course this is not good and we have talked with some people to speed up this. We talked with Igor about taking the MT stuff (yes, we also believe is VERY important), but he fade in the blur… I didn’t hear from him since 3 months (I’m still waiting for some feedback on OSWindow work he did, he)… yes I’m a bit frustrated.
>
> If *anyone* wants to collaborate in any part of this list (is a MASSIVE effort), I would be very happy and willing to provide as much assistance/guiding/peer programming as I can.
>
> hope this helps
>
> Esteban
>
>>
>> Personally, in SqueakElib, I have my network and session layers working for encrypted connections, so I just have the presentation layer to go. Once done, I would be very interested in working in the VM with whomever is also interested with an eye towards threading (MTVM). I am no expert here so it will be a challenge I am looking forward to.
>>
>> Regards,
>> Robert
>>
>> On 10/16/2015 06:59 AM, stepharo wrote:
>>>
>>> In pharodays presentations we explictly mentioned our strategy:
>>>    - we keep NB syntax
>>>    - we change the assembly generation to be able to get Spur.
>>>
>>> Stef
>>>
>>> I can tell you that if I could get a lua kind of jit now I would sign
>>> immediately and also for having pharo as a dll.
>>> Now it takes time to do soemthing.
>>>
>>> Le 15/10/15 17:35, Robert Withers a écrit :
>>>>
>>>> I am reticent to invest in learning FFI that is changing without an idea
>>>> of the direction of the change. So
>>>
>>>
>>
>


Robert Withers
Reply | Threaded
Open this post in threaded view
♦
♦
|

Re: Random forest in Pharo

Robert Withers
In reply to this post by EstebanLM
(+vm-dev)

Esteban, thanks very much for your views. You write:

On 10/16/2015 07:53 AM, Esteban Lorenzano wrote:
 >
 > So… my plan is:
 >
 > - NB to FFI port (should be ready soon)
 > - spur32 bits (should be ready soon, we are just waiting the NB to FFI)
 > - spur64 bits (Eliot is working on the JIT, I need to manage the
migration of Pharo)
 > - FFI 64bits (0% done here… just some stubs waiting for effort). But
we want to move Pharo to 64bits… we are losing a train here...
 > - FFI MT

and of course you are buried in existing tasks, especially the
transition to 64-bits. It is my humble opinion, without really knowing,
that 64-bit would have to be redone after the MTVM completes. Kinda why
I would desire MTVM before 64-bits, then I assume less work would be
needed overall. But that's my uneducated guess.

Perhaps Eliot could shine some light for us on the progress of MTVM and
what's needed.

Because of that assumption I've made and without the responsibilities
you have, Esteban, but recognizing modernizing NB to FFI, my desired
list is:

- NB to FFI port (should be ready soon)
- spur32 bits (should be ready soon, we are just waiting the NB to FFI)
- FFI MT
- spur64 bits (Eliot is working on the JIT, I need to manage the
migration of Pharo)
- FFI 64bits (0% done here… just some stubs waiting for effort). But we
want to move Pharo to 64bits… we are losing a train here...

 > If *anyone* wants to collaborate in any part of this list (is a
MASSIVE effort), I would be very happy and willing to provide as much
assistance/guiding/peer programming as I can.

Yes, please, and I appreciate you willingness to mentor.

Best,
Robert

On 10/16/2015 07:53 AM, Esteban Lorenzano wrote:

>
>> On 16 Oct 2015, at 13:22, Robert Withers <[hidden email]> wrote:
>>
>> Bonjour Stef,
>>
>> I believe the change everyone would be waiting for is a Multi-threaded VM, that supports threaded callouts and callbacks. So I suppose the questions become:
>
> multi thread ffi vm exists as a prototype, and according to its author (Eliot) needs no less than 4 months of someone skilled working on it to finish it.
>
>> - will existing NB syntax require change with the introduction of a MTVM?
>
> nothing will be equal… why? because you will need to provide callbacks. There is no magic here, if you want something to happen while doing something else, you need to provide a way to be called back when that thing finishes.
>
> now we have:
>
> nbCall:module:
>
> to call FFI (will change to a more generic ffiCall:module:, btw… but we’ll keep old notation some versions to provide backward compatibility)
>
> So I can imagine an API like this:
>
> ffiAsyncCall:callback:module:
>
> So yes… you need change. But that’s inevitable… Of course you can do a fwk forking in image and starting a continuation, etc. But well, I will let you guys to think on that (also you still will need the fork) :)
>
>> - to what degree will NB syntax need to be extended to support threaded callouts.
>
> as described, I suppose. No exact idea until we implement.
>
>> - what NB syntax changes are needed for callbacks.
>
> NB used some magic there. Shadow classes and etc. We do not need/want that anymore.
>
> now you have a new FFICallback api, where you can do:
>
> FFICallback
> signature: #(int (int handle, int *pitch, int x, int y, int w, int h))
> block: [ :handle :pitch :x :y :w :h |
> pitch signedLongAt: 1 put: (self get_stride: handle).
> self get_data: handle ]
>
> (I extracted that example from my ongoing port of Athens)
>
>> - timing: when  is MTVM expected and can we operate on the leading edge?
>
> we are lacking resources: Is just me (in the Pharo part, of course… Eliot and some others work also in the exclusively VM part, but they have other agendas).
>
> So… my plan is:
>
> - NB to FFI port (should be ready soon)
> - spur32 bits (should be ready soon, we are just waiting the NB to FFI)
> - spur64 bits (Eliot is working on the JIT, I need to manage the migration of Pharo)
> - FFI 64bits (0% done here… just some stubs waiting for effort). But we want to move Pharo to 64bits… we are losing a train here...
> - FFI MT
>
> So… not very hight priority. According as how I see things now, I *think* I can have that some point of 2017… yes, as far as that. Also because I have a lot other stuff to do, not just the lowlevel parts.
>
> Of course this is not good and we have talked with some people to speed up this. We talked with Igor about taking the MT stuff (yes, we also believe is VERY important), but he fade in the blur… I didn’t hear from him since 3 months (I’m still waiting for some feedback on OSWindow work he did, he)… yes I’m a bit frustrated.
>
> If *anyone* wants to collaborate in any part of this list (is a MASSIVE effort), I would be very happy and willing to provide as much assistance/guiding/peer programming as I can.
>
> hope this helps
>
> Esteban
>
>>
>> Personally, in SqueakElib, I have my network and session layers working for encrypted connections, so I just have the presentation layer to go. Once done, I would be very interested in working in the VM with whomever is also interested with an eye towards threading (MTVM). I am no expert here so it will be a challenge I am looking forward to.
>>
>> Regards,
>> Robert
>>
>> On 10/16/2015 06:59 AM, stepharo wrote:
>>>
>>> In pharodays presentations we explictly mentioned our strategy:
>>>      - we keep NB syntax
>>>      - we change the assembly generation to be able to get Spur.
>>>
>>> Stef
>>>
>>> I can tell you that if I could get a lua kind of jit now I would sign
>>> immediately and also for having pharo as a dll.
>>> Now it takes time to do soemthing.
>>>
>>> Le 15/10/15 17:35, Robert Withers a écrit :
>>>>
>>>> I am reticent to invest in learning FFI that is changing without an idea
>>>> of the direction of the change. So
>>>
>>>
>>
>
>

Robert Withers
Reply | Threaded
Open this post in threaded view
♦
♦
|

Re: Random forest in Pharo

Robert Withers
In reply to this post by EstebanLM


On 10/16/2015 07:58 AM, Esteban Lorenzano wrote:

>
>> On 16 Oct 2015, at 13:53, Esteban Lorenzano <[hidden email]> wrote:
>>
>>
>>> On 16 Oct 2015, at 13:22, Robert Withers <[hidden email]> wrote:
>>>
>>> Bonjour Stef,
>>>
>>> I believe the change everyone would be waiting for is a Multi-threaded VM, that supports threaded callouts and callbacks. So I suppose the questions become:
>>
>> multi thread ffi vm exists as a prototype, and according to its author (Eliot) needs no less than 4 months of someone skilled working on it to finish it.
>>
>>> - will existing NB syntax require change with the introduction of a MTVM?
>>
>> nothing will be equal… why? because you will need to provide callbacks. There is no magic here, if you want something to happen while doing something else, you need to provide a way to be called back when that thing finishes.
>>
>> now we have:
>>
>> nbCall:module:
>>
>> to call FFI (will change to a more generic ffiCall:module:, btw… but we’ll keep old notation some versions to provide backward compatibility)
>>
>> So I can imagine an API like this:
>>
>> ffiAsyncCall:callback:module:
>>
>> So yes… you need change. But that’s inevitable… Of course you can do a fwk forking in image and starting a continuation, etc. But well, I will let you guys to think on that (also you still will need the fork) :)
>
> Actually I just remembered that current prototype works attaching external call with an internal Process (with some special id inside).
> But still, I do not expect call syntax will change at all.

Are you saying all FFI callouts would become threaded or would there be
an unthreaded callout and a threaded callout?  I was assuming the second
scenario.

Robert

>
> Esteban
>
>>
>>> - to what degree will NB syntax need to be extended to support threaded callouts.
>>
>> as described, I suppose. No exact idea until we implement.
>>
>>> - what NB syntax changes are needed for callbacks.
>>
>> NB used some magic there. Shadow classes and etc. We do not need/want that anymore.
>>
>> now you have a new FFICallback api, where you can do:
>>
>> FFICallback
>> signature: #(int (int handle, int *pitch, int x, int y, int w, int h))
>> block: [ :handle :pitch :x :y :w :h |
>> pitch signedLongAt: 1 put: (self get_stride: handle).
>> self get_data: handle ]
>>
>> (I extracted that example from my ongoing port of Athens)
>>
>>> - timing: when  is MTVM expected and can we operate on the leading edge?
>>
>> we are lacking resources: Is just me (in the Pharo part, of course… Eliot and some others work also in the exclusively VM part, but they have other agendas).
>>
>> So… my plan is:
>>
>> - NB to FFI port (should be ready soon)
>> - spur32 bits (should be ready soon, we are just waiting the NB to FFI)
>> - spur64 bits (Eliot is working on the JIT, I need to manage the migration of Pharo)
>> - FFI 64bits (0% done here… just some stubs waiting for effort). But we want to move Pharo to 64bits… we are losing a train here...
>> - FFI MT
>>
>> So… not very hight priority. According as how I see things now, I *think* I can have that some point of 2017… yes, as far as that. Also because I have a lot other stuff to do, not just the lowlevel parts.
>>
>> Of course this is not good and we have talked with some people to speed up this. We talked with Igor about taking the MT stuff (yes, we also believe is VERY important), but he fade in the blur… I didn’t hear from him since 3 months (I’m still waiting for some feedback on OSWindow work he did, he)… yes I’m a bit frustrated.
>>
>> If *anyone* wants to collaborate in any part of this list (is a MASSIVE effort), I would be very happy and willing to provide as much assistance/guiding/peer programming as I can.
>>
>> hope this helps
>>
>> Esteban
>>
>>>
>>> Personally, in SqueakElib, I have my network and session layers working for encrypted connections, so I just have the presentation layer to go. Once done, I would be very interested in working in the VM with whomever is also interested with an eye towards threading (MTVM). I am no expert here so it will be a challenge I am looking forward to.
>>>
>>> Regards,
>>> Robert
>>>
>>> On 10/16/2015 06:59 AM, stepharo wrote:
>>>>
>>>> In pharodays presentations we explictly mentioned our strategy:
>>>>     - we keep NB syntax
>>>>     - we change the assembly generation to be able to get Spur.
>>>>
>>>> Stef
>>>>
>>>> I can tell you that if I could get a lua kind of jit now I would sign
>>>> immediately and also for having pharo as a dll.
>>>> Now it takes time to do soemthing.
>>>>
>>>> Le 15/10/15 17:35, Robert Withers a écrit :
>>>>>
>>>>> I am reticent to invest in learning FFI that is changing without an idea
>>>>> of the direction of the change. So
>>>>
>>>>
>>>
>>
>
>

EstebanLM
Reply | Threaded
Open this post in threaded view
♦
♦
|

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

EstebanLM

On 16 Oct 2015, at 14:06, Robert Withers <[hidden email]> wrote:



On 10/16/2015 07:58 AM, Esteban Lorenzano wrote:

On 16 Oct 2015, at 13:53, Esteban Lorenzano <[hidden email]> wrote:


On 16 Oct 2015, at 13:22, Robert Withers <[hidden email]> wrote:

Bonjour Stef,

I believe the change everyone would be waiting for is a Multi-threaded VM, that supports threaded callouts and callbacks. So I suppose the questions become:

multi thread ffi vm exists as a prototype, and according to its author (Eliot) needs no less than 4 months of someone skilled working on it to finish it.

- will existing NB syntax require change with the introduction of a MTVM?

nothing will be equal… why? because you will need to provide callbacks. There is no magic here, if you want something to happen while doing something else, you need to provide a way to be called back when that thing finishes.

now we have:

nbCall:module:

to call FFI (will change to a more generic ffiCall:module:, btw… but we’ll keep old notation some versions to provide backward compatibility)

So I can imagine an API like this:

ffiAsyncCall:callback:module:

So yes… you need change. But that’s inevitable… Of course you can do a fwk forking in image and starting a continuation, etc. But well, I will let you guys to think on that (also you still will need the fork) :)

Actually I just remembered that current prototype works attaching external call with an internal Process (with some special id inside).
But still, I do not expect call syntax will change at all.

Are you saying all FFI callouts would become threaded or would there be an unthreaded callout and a threaded callout?  I was assuming the second scenario.

I’m saying *the syntax* will not change. That means, if you want to call memcpy, syntax will still be: #(void *memcpy ( void* dest, void *src))

what can (and will) change is the method invoking it…  ffiCall:module: vs. ffiAsyncCall:callback:module: 

Esteban


Robert


Esteban


- to what degree will NB syntax need to be extended to support threaded callouts.

as described, I suppose. No exact idea until we implement.

- what NB syntax changes are needed for callbacks.

NB used some magic there. Shadow classes and etc. We do not need/want that anymore.

now you have a new FFICallback api, where you can do:

FFICallback
signature: #(int (int handle, int *pitch, int x, int y, int w, int h))
block: [ :handle :pitch :x :y :w :h |
pitch signedLongAt: 1 put: (self get_stride: handle).
self get_data: handle ]

(I extracted that example from my ongoing port of Athens)

- timing: when  is MTVM expected and can we operate on the leading edge?

we are lacking resources: Is just me (in the Pharo part, of course… Eliot and some others work also in the exclusively VM part, but they have other agendas).

So… my plan is:

- NB to FFI port (should be ready soon)
- spur32 bits (should be ready soon, we are just waiting the NB to FFI)
- spur64 bits (Eliot is working on the JIT, I need to manage the migration of Pharo)
- FFI 64bits (0% done here… just some stubs waiting for effort). But we want to move Pharo to 64bits… we are losing a train here...
- FFI MT

So… not very hight priority. According as how I see things now, I *think* I can have that some point of 2017… yes, as far as that. Also because I have a lot other stuff to do, not just the lowlevel parts.

Of course this is not good and we have talked with some people to speed up this. We talked with Igor about taking the MT stuff (yes, we also believe is VERY important), but he fade in the blur… I didn’t hear from him since 3 months (I’m still waiting for some feedback on OSWindow work he did, he)… yes I’m a bit frustrated.

If *anyone* wants to collaborate in any part of this list (is a MASSIVE effort), I would be very happy and willing to provide as much assistance/guiding/peer programming as I can.

hope this helps

Esteban


Personally, in SqueakElib, I have my network and session layers working for encrypted connections, so I just have the presentation layer to go. Once done, I would be very interested in working in the VM with whomever is also interested with an eye towards threading (MTVM). I am no expert here so it will be a challenge I am looking forward to.

Regards,
Robert

On 10/16/2015 06:59 AM, stepharo wrote:

In pharodays presentations we explictly mentioned our strategy:
   - we keep NB syntax
   - we change the assembly generation to be able to get Spur.

Stef

I can tell you that if I could get a lua kind of jit now I would sign
immediately and also for having pharo as a dll.
Now it takes time to do soemthing.

Le 15/10/15 17:35, Robert Withers a écrit :

I am reticent to invest in learning FFI that is changing without an idea
of the direction of the change. So
stepharo
Reply | Threaded
Open this post in threaded view
♦
♦
|

Re: Random forest in Pharo

stepharo
In reply to this post by EstebanLM
I'm 100 % in line with esteban roadmap




Le 16/10/15 13:53, Esteban Lorenzano a écrit :

>> On 16 Oct 2015, at 13:22, Robert Withers <[hidden email]> wrote:
>>
>> Bonjour Stef,
>>
>> I believe the change everyone would be waiting for is a Multi-threaded VM, that supports threaded callouts and callbacks. So I suppose the questions become:
> multi thread ffi vm exists as a prototype, and according to its author (Eliot) needs no less than 4 months of someone skilled working on it to finish it.
>
>> - will existing NB syntax require change with the introduction of a MTVM?
> nothing will be equal… why? because you will need to provide callbacks. There is no magic here, if you want something to happen while doing something else, you need to provide a way to be called back when that thing finishes.
>
> now we have:
>
> nbCall:module:
>
> to call FFI (will change to a more generic ffiCall:module:, btw… but we’ll keep old notation some versions to provide backward compatibility)
>
> So I can imagine an API like this:
>
> ffiAsyncCall:callback:module:
>
> So yes… you need change. But that’s inevitable… Of course you can do a fwk forking in image and starting a continuation, etc. But well, I will let you guys to think on that (also you still will need the fork) :)
>
>> - to what degree will NB syntax need to be extended to support threaded callouts.
> as described, I suppose. No exact idea until we implement.
>
>> - what NB syntax changes are needed for callbacks.
> NB used some magic there. Shadow classes and etc. We do not need/want that anymore.
>
> now you have a new FFICallback api, where you can do:
>
> FFICallback
> signature: #(int (int handle, int *pitch, int x, int y, int w, int h))
> block: [ :handle :pitch :x :y :w :h |
> pitch signedLongAt: 1 put: (self get_stride: handle).
> self get_data: handle ]
>
> (I extracted that example from my ongoing port of Athens)
>
>> - timing: when  is MTVM expected and can we operate on the leading edge?
> we are lacking resources: Is just me (in the Pharo part, of course… Eliot and some others work also in the exclusively VM part, but they have other agendas).
>
> So… my plan is:
>
> - NB to FFI port (should be ready soon)
> - spur32 bits (should be ready soon, we are just waiting the NB to FFI)
> - spur64 bits (Eliot is working on the JIT, I need to manage the migration of Pharo)
> - FFI 64bits (0% done here… just some stubs waiting for effort). But we want to move Pharo to 64bits… we are losing a train here...
> - FFI MT
>
> So… not very hight priority. According as how I see things now, I *think* I can have that some point of 2017… yes, as far as that. Also because I have a lot other stuff to do, not just the lowlevel parts.
>
> Of course this is not good and we have talked with some people to speed up this. We talked with Igor about taking the MT stuff (yes, we also believe is VERY important), but he fade in the blur… I didn’t hear from him since 3 months (I’m still waiting for some feedback on OSWindow work he did, he)… yes I’m a bit frustrated.
>
> If *anyone* wants to collaborate in any part of this list (is a MASSIVE effort), I would be very happy and willing to provide as much assistance/guiding/peer programming as I can.
>
> hope this helps
>
> Esteban
>
>> Personally, in SqueakElib, I have my network and session layers working for encrypted connections, so I just have the presentation layer to go. Once done, I would be very interested in working in the VM with whomever is also interested with an eye towards threading (MTVM). I am no expert here so it will be a challenge I am looking forward to.
>>
>> Regards,
>> Robert
>>
>> On 10/16/2015 06:59 AM, stepharo wrote:
>>> In pharodays presentations we explictly mentioned our strategy:
>>>      - we keep NB syntax
>>>      - we change the assembly generation to be able to get Spur.
>>>
>>> Stef
>>>
>>> I can tell you that if I could get a lua kind of jit now I would sign
>>> immediately and also for having pharo as a dll.
>>> Now it takes time to do soemthing.
>>>
>>> Le 15/10/15 17:35, Robert Withers a écrit :
>>>> I am reticent to invest in learning FFI that is changing without an idea
>>>> of the direction of the change. So
>>>
>
>


Robert Withers
Reply | Threaded
Open this post in threaded view
♦
♦
|

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

Robert Withers
In reply to this post by Robert Withers
Yes, exactly. I do realize I was consciously changing that effort
synchronization order. 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. I was barely
familiar with the VM, slang, interpreter, it years ago... I'm totally
unfamiliar with cog. 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
>
>

Ben Coman
Reply | Threaded
Open this post in threaded view
♦
♦
|

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

Ben Coman
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
>>
>>
>

EstebanLM
Reply | Threaded
Open this post in threaded view
♦
♦
|

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

EstebanLM
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.

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.

Esteban

> On 18 Oct 2015, at 17:56, Ben Coman <[hidden email]> 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
>>>
>>>
>>


Robert Withers
Reply | Threaded
Open this post in threaded view
♦
♦
|

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

Robert Withers
In reply to this post by Ben Coman
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
> <[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
>>>
>>>
>>

Robert Withers
Reply | Threaded
Open this post in threaded view
♦
♦
|

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

Robert Withers
In reply to this post by EstebanLM
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 <[hidden email]> 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
>>>>
>>>>
>>>
>

Eliot Miranda-2
Reply | Threaded
Open this post in threaded view
♦
♦
|

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

Eliot Miranda-2
Hi Robert,

_,,,^..^,,,_ (phone)

On Oct 19, 2015, at 5:03 AM, Robert Withers <[hidden email]> wrote:

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?

It's a bit more than that.  It is the sharing of the VM between different threads, but only allowing one thread to own the VM at any one time, changing ownership in call out or Smalltalk process switch time.  This approach provides interleaved concurrency but not parallelism in your Smalltalk code and it means the Smalltalk class library doesn't have to be made thread-safe, which as Esteban said is a huge task.

See

and google "eliot Miranda Simmons own thread" to find more messages.


b) General MTVM means other system services are threaded, like I/O events and scheduling and heartbeat.

No; at least not in my opinion. In the standard single-threaded VM the heartbeat is ideally a thread (it can be an interval timer, but that's problematic; system calls get interrupted), and maybe an incremental global GC could be in its own thread.

So I'm defining the MTVM to be the sharing of the VM between threads, and /not/ just the use of threads to implement non-Smalltalk sub tasks of the VM, and /not/ a full-blown multithreaded Smalltalk VM providing concurrent execution of Smalltalk processes in parallel.

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.

This has been well thought through and discussed.  The definition above is very useful.  It provides a system that can inter operate with concurrent code without having to implement a system that provides parallelism.  It is used in David Simmons' VMs for S# etc and a similar (but less performant) scheme is available in Python VMs.

Please, let's get this scheme working first.  I'm not at all happy (read, extremely unhappy) that there is not much focus on working together to get our current VM to an excellent state and instead lots of work on other VMs that is speculative and a long way away from being production ready. We have a huge amount of work to do on Cog:

- event-driven VM (that hence costs 0% processor time at idle)
- 64-bits (x64 and ARM and...?)
- Sista adaptive optimizer
- FFI via dynamic generation of marshaling code, as required for efficient and correct call outs on x64
- MTVM as defined above
- an incremental global mark-sweep GC for Spur
- running on Xen/Unikernels/containers
- providing a JavaScript plugin to proved rendering and events so we can run an efficient VM in a web browser
- a port of the Interpreter/Context VM to Spur

IMO, things that can /and should/ wait are
- throwing away Slang and providing a true written-in-pure-Smalltalk VM that is self-bootstrapped a la Gerardo Richarte and Xavier Burroni
- a truly parallel multi/threaded VM

and things we shouldn't go anywhere near are
- using libffi
- targeting JavaScript, Java or any other dynamic language de jour that happens to run in a web browser but either provides abysmal performance or doesn't support full Smalltalk semantics
- implementing the VM in other VM frameworks such as PyPy which simply strengthens that community and weakens our own

Right now there are only a handful of people who make commits to the VM and three who are "full time", and we're all overloaded.  But the VM is the base of the pillar and if we want to provide high-quality solutions that people will pay money to use we have to have a high-quality VM.  In Spur we have a VM that is significantly faster that VW, and very reliable.  In Sista we will have a system that is much faster and can be improved upon for years to come and a system that can migrate to future VMs (because it is mostly Smalltalk), and useful support for a high quality FFI.  People like have stepped up and made significant contributions to give us what is a respectable VM that is on an arc to providing a really high-quality production Smalltalk VM written in Smalltalk produced by a very small community.  But it is now 2015 and Cog started 7 years ago. All the work on other VMs, deployment platforms etc, IMO dilutes and delays in delivering to our community a truly world-class VM that we can compete with against Java HotSpot, node.js v8, lua luajit, factor, swift et al.  Please get on board. We'd love the help and we can guarantee you'll have fun and you can guarantee you'll have an impact.


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 <[hidden email]> 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
Ben Coman
Reply | Threaded
Open this post in threaded view
♦
♦
|

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

Ben Coman
In reply to this post by Robert Withers
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

> 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
>> <[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

Robert Withers
Reply | Threaded
Open this post in threaded view
♦
♦
|

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

Robert Withers
In reply to this post by Eliot Miranda-2
Hi Eliot,


... ^^
robert


On 10/19/2015 10:10 AM, Eliot Miranda wrote:

>
> Hi Robert,
>
> _,,,^..^,,,_ (phone)
>
> On Oct 19, 2015, at 5:03 AM, Robert Withers <[hidden email]
> <mailto:[hidden email]>> wrote:
>
>> 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?
>
> It's a bit more than that.  It is the sharing of the VM between
> different threads, but only allowing one thread to own the VM at any one
> time, changing ownership in call out or Smalltalk process switch time.
>   This approach provides interleaved concurrency but not parallelism in
> your Smalltalk code and it means the Smalltalk class library doesn't
> have to be made thread-safe, which as Esteban said is a huge task.
>
> See
> http://lists.gforge.inria.fr/pipermail/pharo-project/2011-January/038943.html
>
> and google "eliot Miranda Simmons own thread" to find more messages.
>
>
>> b) General MTVM means other system services are threaded, like I/O
>> events and scheduling and heartbeat.
>
> No; at least not in my opinion. In the standard single-threaded VM the
> heartbeat is ideally a thread (it can be an interval timer, but that's
> problematic; system calls get interrupted), and maybe an incremental
> global GC could be in its own thread.
>
> So I'm defining the MTVM to be the sharing of the VM between threads,
I apologize if I am off the rails again, Eliot. I must watch that. Let's
see if I can express it right.

I think, not entirely sure mind you, that I am talking about single
threading the image and not sharing the VM between different threads. I
need to read the links you provided and hopefully you'd welcome
discussion about alternatives, long as it doesn't consume your needed
time; that's your discretion, I acknowledge.

Why change owners of the vm process and deal with thread contention edge
cases? If you put a Elib-style vat in the core of the vm and run a
single-osthread instance image, you get hydra, soft virtual semaphores,
threaded FFI and real virtualization, as all external vat communication
must go through the vats' queue. All plugins would have to be changed to
talk through the scheduling queue as pointers to function calls, sort of
thing - continuations queue? Perhaps outbound calls as well so no
thread-safing the plugins...


> and /not/ just the use of threads to implement non-Smalltalk sub tasks

I suppose I'm thinking of it more as this, yet it seems your goal is to
not have to thread safe the plugins, which is safe & reliable. This I
understand.

Perhaps both are possible, by placing a queue in front of every thread,
preparatory or sensory worker threads or main image thread. This is
where I'm at with my thinking. I'd welcome your thoughts.

> of the VM, and /not/ a full-blown multithreaded Smalltalk VM providing

I see this as an escalation of your idea, surely too much and violating
encapsulation of decentralization. I think shared memory is bad and
copyOnWrite sort of thing is much better. Yet perhaps in some cases. Do
all store bytecodes lock the page they access?

> concurrent execution of Smalltalk processes in parallel.

Hydra is with separate threads for separate images, isn't it? A new
Hydra, with an elib vm automatically gets this if we enforce all
inter-vat communications go through each vat's queue.

Does the question come down to complexity, then? May be too much.

>
>> 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.
>
> This has been well thought through and discussed.  The definition above
> is very useful.  It provides a system that can inter operate with
> concurrent code without having to implement a system that provides
> parallelism.  It is used in David Simmons' VMs for S# etc and a similar
> (but less performant) scheme is available in Python VMs.
I would love to learn more about it.

>
> Please, let's get this scheme working first.  I'm not at all happy
> (read, extremely unhappy) that there is not much focus on working
> together to get our current VM to an excellent state and instead lots of
> work on other VMs that is speculative and a long way away from being
> production ready.

Thank you for discussing and defining multi-threading; I welcome it.
Thanks as well for the task specification...

I put this together, with a few details from some of the other emails,
mostly sub-tasks.  However, I did not see ARM or Pharo modernization on
the list, so I added those. You'll find a Word doc and pdf attached,
thank you! This is most beneficial to have a bird's eye view. So I added
the "Current items in play"

...

We have a huge amount of work to do on Cog:

>
> - event-driven VM (that hence costs 0% processor time at idle)
> - 64-bits (x64 and ARM and...?)
> - Sista adaptive optimizer
> - FFI via dynamic generation of marshaling code, as required for
> efficient and correct call outs on x64
> - MTVM as defined above
> - an incremental global mark-sweep GC for Spur
> - running on Xen/Unikernels/containers
> - providing a JavaScript plugin to proved rendering and events so we can
> run an efficient VM in a web browser
> - a port of the Interpreter/Context VM to Spur
>
> IMO, things that can /and should/ wait are
> - throwing away Slang and providing a true written-in-pure-Smalltalk VM
> that is self-bootstrapped a la Gerardo Richarte and Xavier Burroni
> - a truly parallel multi/threaded VM
>
> and things we shouldn't go anywhere near are
> - using libffi
> - targeting JavaScript, Java or any other dynamic language de jour that
> happens to run in a web browser but either provides abysmal performance
> or doesn't support full Smalltalk semantics
> - implementing the VM in other VM frameworks such as PyPy which simply
> strengthens that community and weakens our own
>
> Right now there are only a handful of people who make commits to the VM
> and three who are "full time", and we're all overloaded.  But the VM is
> the base of the pillar and if we want to provide high-quality solutions
> that people will pay money to use we have to have a high-quality VM.  In
> Spur we have a VM that is significantly faster that VW, and very
> reliable.  In Sista we will have a system that is much faster and can be
> improved upon for years to come and a system that can migrate to future
> VMs (because it is mostly Smalltalk), and useful support for a high
> quality FFI.  People like have stepped up and made significant
> contributions to give us what is a respectable VM that is on an arc to
> providing a really high-quality production Smalltalk VM written in
> Smalltalk produced by a very small community.  But it is now 2015 and
> Cog started 7 years ago. All the work on other VMs, deployment platforms
> etc, IMO dilutes and delays in delivering to our community a truly
> world-class VM that we can compete with against Java HotSpot, node.js
> v8, lua luajit, factor, swift et al.  Please get on board. We'd love the
> help and we can guarantee you'll have fun and you can guarantee you'll
> have an impact.
What else can man want in life that the opportunity to take up
challenges when life so graciously lays these obstacles in one's path.
It stuns me what you all have done. Truly amazing the targets and
varieties you offer. A smörgåsbord of multiple generated VMs. Amazing.

Unless you feel otherwise, I think I will focus on 2, 4 & 5 of the
current items:

- 64-bit vm support
- MTVM discussions
- Pharo support and modernization

I love Pharo and what they have done and are doing - it's fantastic and
I want to make an impact there as well. They really need FileDirectory,
though, if only a wrapper, as compatibility code for VMMaker.oscog. :)


>
>>
>> I appreciate you and this MT discussion.

Thank you ,
Robert

>>
>>
>>> 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 <[hidden email]
>>>> <mailto:[hidden email]>> wrote:
>>>>
>>>>
>>>> On Sat, Oct 17, 2015 at 2:25 AM, Robert Withers
>>>> <[hidden email] <mailto:[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
>>>>>>
>>>>>>
>>>>>
>>>

VM Strategy.pdf (54K) Download Attachment
VM Strategy.docx (9K) Download Attachment
123
Free forum by Nabble Edit this page