alfanerd

I think you only need one queue per actor? And then one worker per CPU core? I believe that how Erlang does it, and do millions of actors without any issues...

Sending a message between Actors can be just moving a pointer to a piece of shared memory.

I think sending messages is more about the way you think about concurrency, more than the implementation.

I have always found the "one thread doing "while True receive message, handle message" much easier to reason about than "remember to lock this chunk of data in case more than one thread should access it"

Yes, yes, yes and I hope the alternate timeline will start now.

IMO the reason that we have so many ways of doing concurrency in Python (fra asyncio, curio, trio to gevent, multiprocessing etc.) is that it was never properly dealt with.

It has to be built into the language, a feature of the language, like fx. garbage collection. The model of Pony or Erland, where are execution thread is started per core could also have been used in python, instead we got the async/await mess, which almost created a whole new language, where every library has to be rewritten.

It saddens me to think that the ugly cludge that async/await is got added to Python almost without any discussion, whereas the insignificant walrus operator got so much heat that GVR quit.

+1

Of interest might also be Erjang, Kresten Krab's port of BEAM to JVM. https://github.com/trifork/erjang

As I understand it, it is feature complete and actually runs Erlang pretty well. Could be interesting to see some benchmark testing.

In my 30+ years experience of concurrency, the shared-nothing message model makes it relative easy to reason about concurrency (since every actor is single threaded).

I have worked with Java, C# and Python, and for each I have developed a concurrent object framework, making it quite easy to work with multible channels of incoming events, for example for process control systems with barcode-scanners, scales, I/O-busses etc. connected to the system

I think ponylang does a pretty good implementation of the Actor model.

Feel free to have a look at the Python impl. of the framework (www.github.com/pylots/pyworks)

It is in the Gilectomy branch of Larry Hastings github project. (https://github.com/larryhastings/gilectomy)

I also pasted the fib test to pastebin: https://pastebin.com/Ryyb2K7V

I just made a quick test: CPython-3.6.1 vs. Jython-2.7.0 (May 2015)

I ran Larry Hastings' Gilectomy testprogram x.py: fib(40) on 8 threads HW: MacBook Pro, 2015, 8 (4+4) cores, 1Gb RAM

Jython ran the program 8 times faster, utilising all 8 cores >95%. Python ran on 1-2 cores less than 60% utilisation. (Pretty sure Jython will run 16 times faster on 16 cores)

It's 2017, why this is acceptable to GvR and the Python community is beyond me.

Jython: real 1m4.959s user 7m38.521s sys 0m2.396s

Python: real 8m19.035s user 8m16.508s sys 0m11.424s

You loose access to all the C-libraries that comes with Python. On the other hand you get beautiful integration with all Java libraries very nicely integrated.

Both Jython (Java impl) and IronPython (C# impl) works fine without the GIL. The big issue is compatibility with C-based libraries, as I hear Larry Hastings, there are three levels of compatibility:

1) Fully compatible, nothing needs to be done 2) Fully compatible, but a recompile of C-libs is needed 3) Almost compatible, but some updates to C-libs are needed

Larry is aiming for 2)

Some years ago I wrote pyworks (www.github.com/pylots/pyworks), a proposal for async objects (inspired by ABCL and cooC (Concurrent Object Oriented-C, https://www.researchgate.net/publication/220178380_Concurren...)

The testcase is 100 threads sending 1000 messages in to each other in a ring. On a 8-core Mac Jython and IronPython performs better than on 1-core, but Python 2.7 performs so badly that it never finishes.

The ideal scenario is probably that the CPython interpreter starts one thread per core running as many coroutines in parallel as possible, but that looks like a long way away for Python

I mean the developer (using a highlevel language as Python) ideally should get more performance on an 8-core than on a 1-core CPU.

Erlang, which btw. is older than Python, will perform better the more cores you have due to its message oriented nature. Python (2.7) on the other hand performed worse with multithreading on multicore.

I was hoping that Python would take the same direction in the future, but unfortunately we are getting the async/await mess, instead of a simple async object model (sorry, my pet peeve)