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

Mon Oct 19 23:17:14 UTC 2015

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 <robert.w.withers at gmail.com
> <mailto:robert.w.withers at gmail.com>> 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 <btc at openInWorld.com
>>>> <mailto:btc at openinworld.com>> wrote:
>>>>
>>>>
>>>> On Sat, Oct 17, 2015 at 2:25 AM, Robert Withers
>>>> <robert.w.withers at gmail.com <mailto:robert.w.withers at gmail.com>> wrote:
>>>>> Yes, exactly. I do realize I was consciously changing that effort
>>>>> synchronization order.
>>>>
>>>> I see 64-bit being higher priority than multi-threaded for the wider
>>>> community.  Dealing with larger in-Image data opens the door to more
>>>> corporate project/funding opportunities. Also simplifying the install
>>>> on modern Linux platforms without requiring additional 386 libraries
>>>> will help acceptance there.
>>>>
>>>>> It is my humble opinion, without really knowing, that 64-bit would
>>>>> have to be redone after the MTVM completes.
>>>>
>>>> I would assume it was the other way around. Presuming that Eliot has
>>>> sponsors influencing his priorities, it seems given that 64-bits will
>>>> happen first.   I would guess any MTVM development on the old vm would
>>>> then need to be reworked.
>>>>
>>>>> I was doing so with the idea in mind that I and others
>>>>> might dig into working on the VM, for threading support, while Eliot
>>>>> maintains focus on 64-bits...a tall order, I know.
>>>>
>>>> The usual downside of splitting resources applies.  There are not that
>>>> many "others" and maybe they would be drawn away from helping with the
>>>> 64-bit vm.  If the 64-bit vm goes slower for lack of resources then
>>>> your footing for MTVM will shifting for a longer time.  You may
>>>> ultimately get where you want to go faster by helping with the 64-bit
>>>> vm.  The rapport built with other vm devs from working on 64-bit might
>>>> could then be applied to MTVM.  (Of course, its your free time, so you
>>>> should pursue what interests you.)
>>>>
>>>>> I was barely familiar with the VM, slang, interpreter, it years ago...
>>>>> I'm totally unfamiliar with cog.
>>>>
>>>> The experience you gain from working beside Esteban and Eliot on
>>>> 64-bit Cog/Spur could then be applied to a MTVM.
>>>>
>>>> btw, you may find these threads interesting...
>>>> *
>>>> http://lists.pharo.org/pipermail/pharo-dev_lists.pharo.org/2015-April/108648.html
>>>> *
>>>> http://forum.world.st/Copy-on-write-for-a-multithreaded-VM-td4837905.html
>>>>
>>>> cheers -ben
>>>>
>>>>> I believe another item on that list ought to be modernizing slang. So
>>>>> many big items!
>>>>>
>>>>> Robert
>>>>>
>>>>>
>>>>>
>>>>> On 10/16/2015 12:48 PM, Stephan Eggermont wrote:
>>>>>>
>>>>>>
>>>>>> On 16-10-15 14:05, Robert Withers wrote:
>>>>>>>
>>>>>>> Because of that assumption I've made and without the responsibilities
>>>>>>> you have, Esteban, but recognizing modernizing NB to FFI, my desired
>>>>>>> list is:
>>>>>>
>>>>>>
>>>>>> I would expect the least total effort to be needed by keeping the work
>>>>>> of Esteban and Eliot as much as possible aligned. That is what
>>>>>> Esteban's
>>>>>> list achieves.
>>>>>>
>>>>>> Stephan
>>>>>>
>>>>>>
>>>>>
>>>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: VM Strategy.pdf
Type: application/pdf
Size: 40515 bytes
Desc: not available
Url : http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20151019/e317c3c8/VMStrategy-0001.pdf
-------------- next part --------------
A non-text attachment was scrubbed...
Name: VM Strategy.docx
Type: application/vnd.openxmlformats-officedocument.wordprocessingml.document
Size: 7030 bytes
Desc: not available
Url : http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20151019/e317c3c8/VMStrategy-0001.bin