Re: picolisp and erlang in distributed/concurrent processing

[andreas]

Really good points Michel, thank you for describing so clearly!

If we're talking solely about multiple picolisp processes, then there is 
built-in picolisp IPC for picolisp processes started by the same common parent 
process.
Check out: (fork) (tell) (kids) (hear) and the functions in @lib/boss.l

There are also coroutines (co) and (task) / *Run

@Lawrence:
Still theorizing over theoretical properties?
I recommend to do a little benchmark project or a little proof of concept of 
what you want to do. 
General discussion/research is good to get a rough overview, but will hardly 
give you an answer for a concrete case, then better do a prototype.
And don't forget there is no golden language being the perfect tool for every 
person and every project, technical features of a language is just one property 
of many to take into account.

-beneroth

- Original Message -
From: Michel Pelletier [mailto:pelletier.mic...@gmail.com]
To: picolisp@software-lab.de
Sent: Tue, 5 Jan 2016 18:56:04 -0800
Subject: Re: picolisp and erlang in distributed/concurrent processing

This is an interesting question that I have a few thoughts on.

First, is that picolisp is so "light" and has such a minimal memory
footprint, that it's easy to use multiprocessing to many picolisp processes
running on a machine, or a in a container.  Multiprocessing has a
reputation of being slow and expensive, but that's not really my experience
on Linux.  One the advantages I believe is that the entire interpreter can
pretty much fit in processor cache, and all processes benefit.

Forks are nice in that they share nothing, so you need some kind of share
nothing IPC.  The awesome aw wrote some nanomsg bindings for picolisp that
do the job very well: https://github.com/aw/picolisp-nanomsg  You can also
use mmap simply enough to share memory between processes. This provides you
with all the parts you need to undertake all kinds of "actor" like patterns.

Erlang, Elixir, and Go all use a concurrency technique called Communicating
Sequential Processes (CSP).  This uses an explicit, synchronous "channel"
abstraction to pass messages between processes and define rendezvous
points.  Processes talk on channels instead of explicitly named actor
endpoints.  As this link points out, there are a lot of overlap in
functionality with actor models, and they can both easily emulate each
other.

https://en.wikipedia.org/wiki/Communicating_sequential_processes#Comparison_with_the_Actor_Model

Nanomsg kind of give you the best of both worlds, with synchronous and
asynchronous passing using either the actor abstraction or "channels" using
various routing policies (pub/sub, many to many, surveying, etc.)

My 2c.

-Michel

On Tue, Jan 5, 2016 at 5:50 PM, Lawrence Bottorff  wrote:

> If Erlang is a perfect 10 (or not!) in the world of distributed,
> concurrent, load-sharing networked interoperable (etc., etc.) software,
> what does picolisp bring to the table? What can I do along these lines in
> picolisp? Erlang allows a node to have thousands of "light' processes. How
> does picolisp do this?
>
> LB
>

LCD screen

[Jake]

I got my LCD screen for the Mizar a few days ago, it came with the wire 
mod done so that the USB can be used to power it instead, I have both 
USB ports plugged into my PC and am using Minicom to communicate with 
the Mizar. Anyhow, none of the LCD commands like (mizar32-lcd-prinl 
'Hello) seem to do anything, the screen is also just completely green. 
Anyone got any ideas? Thanks.

--
UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe

Re: picolisp and erlang in distributed/concurrent processing

[Henrik Sarvell]

Hi Lawrence, note that if you don't change the FD_SET as per my
description here:
http://www.mail-archive.com/picolisp@software-lab.de/msg05890.html and
recompile you won't be able to run more than about 500 child processes
at the same time on the same parent.

If you continue reading the above post you will also see more that
might be of interest to you.

On Wed, Jan 6, 2016 at 4:08 PM,   wrote:
> Really good points Michel, thank you for describing so clearly!If we're
> talking solely about multiple picolisp processes, then there is built-in
> picolisp IPC for picolisp processes started by the same common parent
> process.Check out: (fork) (tell) (kids) (hear) and the functions in
> @lib/boss.lThere are also coroutines (co) and (task) / *Run@Lawrence:Still
> theorizing over theoretical properties?I recommend to do a little benchmark
> project or a little proof of concept of what you want to do. General
> discussion/research is good to get a rough overview, but will hardly give
> you an answer for a concrete case, then better do a prototype.And don't
> forget there is no golden language being the perfect tool for every person
> and every project, technical features of a language is just one property of
> many to take into account.-beneroth- Original Message -From: Michel
> Pelletier [mailto:pelletier.mic...@gmail.com]To:
> picolisp@software-lab.deSent: Tue, 5 Jan 2016 18:56:04 -0800Subject: Re:
> picolisp and erlang in distributed/concurrent processingThis is an
> interesting question that I have a few thoughts on.First, is that picolisp
> is so "light" and has such a minimal memoryfootprint, that it's easy to use
> multiprocessing to many picolisp processesrunning on a machine, or a in a
> container. Multiprocessing has areputation of being slow and expensive, but
> that's not really my experienceon Linux. One the advantages I believe is
> that the entire interpreter canpretty much fit in processor cache, and all
> processes benefit.Forks are nice in that they share nothing, so you need
> some kind of sharenothing IPC. The awesome aw wrote some nanomsg bindings
> for picolisp thatdo the job very well:
> https://github.com/aw/picolisp-nanomsg You can alsouse mmap simply enough to
> share memory between processes. This provides youwith all the parts you need
> to undertake all kinds of "actor" like patterns.Erlang, Elixir, and Go all
> use a concurrency technique called CommunicatingSequential Processes (CSP).
> This uses an explicit, synchronous "channel"abstraction to pass messages
> between processes and define rendezvouspoints. Processes talk on channels
> instead of explicitly named actorendpoints. As this link points out, there
> are a lot of overlap infunctionality with actor models, and they can both
> easily emulate
> eachother.https://en.wikipedia.org/wiki/Communicating_sequential_processes#Comparison_with_the_Actor_ModelNanomsg
> kind of give you the best of both worlds, with synchronous andasynchronous
> passing using either the actor abstraction or "channels" usingvarious
> routing policies (pub/sub, many to many, surveying, etc.)My 2c.-MichelOn
> Tue, Jan 5, 2016 at 5:50 PM, Lawrence Bottorff  wrote:>
> If Erlang is a perfect 10 (or not!) in the world of distributed,>
> concurrent, load-sharing networked interoperable (etc., etc.) software,>
> what does picolisp bring to the table? What can I do along these lines in>
> picolisp? Erlang allows a node to have thousands of "light' processes. How>
> does picolisp do this?>> LB>
-- 
UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe