[Python-Dev] Re: PoC: Subinterpreters 4x faster than sequential execution or threads on CPU-bound workaround

[Joseph Jenne via Python-Dev]

I'm seeing a drop in performance of both multiprocess and subinterpreter 
based runs in the 8-CPU case, where performance drops by about half 
despite having enough logical CPUs, while the other cases scale quite 
well. Is there some issue with python multiprocessing/subinterpreters on 
the same logical core?


On 5/5/20 2:46 PM, Victor Stinner wrote:

Hi,

I wrote a "per-interpreter GIL" proof-of-concept: each interpreter
gets its own GIL. I chose to benchmark a factorial function in pure
Python to simulate a CPU-bound workload. I wrote the simplest possible
function just to be able to run a benchmark, to check if the PEP 554
would be relevant.

The proof-of-concept proves that subinterpreters can make a CPU-bound
workload faster than sequential execution or threads and that they
have the same speed than multiprocessing. The performance scales well
with the number of CPUs.


Performance
===

Factorial:

 n = 50_000
 fact = 1
 for i in range(1, n + 1):
 fact = fact * i

2 CPUs:

 Sequential: 1.00 sec +- 0.01 sec
 Threads: 1.08 sec +- 0.01 sec
 Multiprocessing: 529 ms +- 6 ms
 Subinterpreters: 553 ms +- 6 ms

4 CPUs:

 Sequential: 1.99 sec +- 0.01 sec
 Threads: 3.15 sec +- 0.97 sec
 Multiprocessing: 560 ms +- 12 ms
 Subinterpreters: 583 ms +- 7 ms

8 CPUs:

 Sequential: 4.01 sec +- 0.02 sec
 Threads: 9.91 sec +- 0.54 sec
 Multiprocessing: 1.02 sec +- 0.01 sec
 Subinterpreters: 1.10 sec +- 0.00 sec

Benchmarks run on my laptop which has 8 logical CPUs (4 physical CPU
cores with Hyper Threading).

Threads are between 1.1x (2 CPUs) and 2.5x (8 CPUs) SLOWER than
sequential execution.

Subinterpreters are between 1.8x (2 CPUs) and 3.6x (8 CPUs) FASTER
than sequential execution.

Subinterpreters and multiprocessing have basically the same speed on
this benchmark.

See demo-pyperf.py attached to https://bugs.python.org/issue40512 for
the code of the benchmark.


Implementation
==

See https://bugs.python.org/issue40512 and related issues for the
implementation. I already merged changes, but most code is disabled by
default: a new special undocumented
--with-experimental-isolated-subinterpreters build mode is required to
test it.

To reproduce the benchmark, use::

 # up to date checkout of Python master branch
 ./configure \
 --with-experimental-isolated-subinterpreters \
 --enable-optimizations \
 --with-lto
 make
 ./python demo-pyperf.py


Limits of subinterpreters design


Subinterpreters have a few design limits:

* A Python object must not be shared between two interpreters.
* Each interpreter has a minimum memory footprint, since Python
internal states and modules are duplicated.
* Others that I forgot :-)


Incomplete implementation
=

My proof-of-concept is just good enough to compute factorial with the
code that I wrote above :-) Any other code is very likely to crash in
various funny ways.

I added a few "#ifdef EXPERIMENTAL_ISOLATED_SUBINTERPRETERS" for the
proof-of-concept. Most are temporary workarounds until some parts of
the code are modified to become compatible with subinterpreters, like
tuple free lists or Unicode interned strings.

Right now, there are still some states which are shared between
subinterpreters: like None and True singletons, but also statically
allocated types. Avoid shared states should enhance performances.

See https://bugs.python.org/issue40512 for the current status and a
list of tasks.

Most of these tasks are already tracked in Eric Snow's "Multi Core
Python" project:
https://github.com/ericsnowcurrently/multi-core-python/issues

Victor
--
Night gathers, and now my watch begins. It shall not end until my death.
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/S5GZZCEREZLA2PEMTVFBCDM52H4JSENR/
Code of Conduct: http://python.org/psf/codeofconduct/

___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/DAF6PTIY5A55TW3PHQLL347FID2UVT73/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: PEP 618: Add Optional Length-Checking To zip

[Joseph Jenne via Python-Dev]

I'd like to suggest "len_eq" as a short but (rather) self-explanatory 
option.


On 5/20/20 3:16 PM, Gregory P. Smith wrote:



On Wed, May 20, 2020 at 11:09 AM Jim J. Jewett > wrote:


David Mertz wrote:

> Fwiw, I don't think it changes my order, but 'strict' is a
better word than
> 'equal' in all those places. I'd subtract 0.1 from each of those
votes if
> they used "equal".

I would say that 'equal' is worse than 'strict'. but 'strict' is
also wrong.

Zipping to a potentially infinite sequence -- like a manual
enumerate --
isn't wrong.  It may be the less common case, but it isn't wrong. 
Using
'strict' implies that there is something sloppy about the data in,
for
example, cases like Stephen J. Turnbull's lagged time series.

Unfortunately, the best I can come up with is 'same_length', or
possibly
'equal_len' or 'equal_length'.  While those are better
semantically, they
are also slightly too long or awkward.  I would personally still
consider
'same_length' the least bad option.

-jJ


As we've come down to naming things... if you want it to read more 
like English,


`zip(vorpal_rabbits, holy_hand_grenades, lengths_must_match=True)`

or another chosen variation of that such as `len_must_match=` or 
`length_must_match=` reads nicely and is pretty self explanatory that 
an error can be expected if the condition implied by the "must" is 
found untrue without really feeling a need to look it up in documentation.


It is also harder to type or fit on a line.  Which is one advantage to 
a short thing like `strict=`.


I don't care so much about the particular spelling here to argue among 
any of those, I primarily want the feature to exist.


I expect we're entering steering council territory for a decision soon...

-gps

___
Python-Dev mailing list -- python-dev@python.org

To unsubscribe send an email to python-dev-le...@python.org

https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at

https://mail.python.org/archives/list/python-dev@python.org/message/G5JTZI6SARFG5AA3H2XJUIUNXR2TBNQ4/
Code of Conduct: http://python.org/psf/codeofconduct/


___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/TGLTTQ7PKYSWYBYVKE6PHUH5RLJSDUH5/
Code of Conduct: http://python.org/psf/codeofconduct/
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/YEKKT3YIXMNJPFIMAGSCVMJSBDBPSZLM/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: REPL output bug

[Joseph Jenne via Python-Dev]

On 2020-06-15 15:26, Ivan Pozdeev via Python-Dev wrote:


On 12.06.2020 11:01, Rob Cliffe via Python-Dev wrote:
If I run the following program (using Python 3.8.3 on a Windows 10 
laptop):


import sys, time
for i in range(1,11):
    sys.stdout.write('\r%d' % i)
    time.sleep(1)

As intended, it displays '1', replacing it at 1-second intervals with 
'2', '3' ... '10'.


Now run the same code inside the REPL:

Python 3.8.3 (tags/v3.8.3:6f8c832, May 13 2020, 22:20:19) [MSC v.1925 
32 bit (Intel)] on win32

Type "help", "copyright", "credits" or "license" for more information.
>>> import sys, time
>>> for i in range(1,11):
... sys.stdout.write('\r%d' % i)
... time.sleep(1)
...
12
22
32
42
52
62
72
82
92
103
>>>

It appears that the requested characters are output, *followed by* 
the number of characters output

(which is the value returned by sys.stdout.write) and a newline.
Surely this is not the intended behaviour.
sys.stderr behaves the same as sys.stdout.



3.7.4 win64 works as expected (i.e. prints and overwrites only the 
numbers) and I see nothing relevant in 
https://docs.python.org/3/whatsnew/3.8.html


So I'd say this is a bug.



Python 2 does NOT exhibit this behaviour:

Python 2.7.18 (v2.7.18:8d21aa21f2, Apr 20 2020, 13:19:08) [MSC v.1500 
32 bit (Intel)] on win32

Type "help", "copyright", "credits" or "license" for more information.
>>> import sys, time
>>> for i in range(1,11):
... sys.stdout.write('\r%d' % i)
... time.sleep(1)
...
10>>>
# displays '1', '2' ... '10' as intended.

Best wishes
Rob Cliffe
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/T3BVZMBLWK3PMLRL2XCQFMLATGRTUPYE/

Code of Conduct: http://python.org/psf/codeofconduct/
--
Regards,
Ivan

___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/6BS3GXCS63PTXZMOMZSC6M5DHNAJO5FX/

Code of Conduct: http://python.org/psf/codeofconduct/


I just tested with 3.7.3 and got the same results as originally 
described. Is there something different about 3.7.4 on win7?


Python 3.7.3 (default, Dec 20 2019, 18:57:59)
[GCC 8.3.0] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import sys
>>> import time
>>> for i in range(1,11):
... sys.stdout.write('\r%d' % i)
... time.sleep(1)
...
12
22
32
42
52
62
72
82
92
103
(I also tested with 3.8.3 with the same results)

Joseph J
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/TOSIE4NBT3LVO2ZNUM7FDLTWIIYNJWSP/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: PEP 622: Structural Pattern Matching

[Joseph Jenne via Python-Dev]

On 2020-06-25 03:00, Greg Ewing wrote:

On 25/06/20 7:50 pm, Anders Munch wrote:

Pascal is a precedent for this placement of 'case',


Yes, but it doesn't use it with "match". In fact it doesn't have
any keyword in front of the values to be matched; it goes like

   case n of
  1: ...;
  2: ...;
  3: ...;
   end

If we did that in Python it would look like this:

   case shape:
  Point(x, y):
 ...
  Line(x1, y1, x2, y2):
 ...
  Circle(cx, cy, r):
 ...

What think folks of this?

IMHO it looks a lot like shell scripting, which isn't really a bad thing 
in general, but the second form seems to lose some readability to me


--

Joseph

___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/CYB2FCKAM5W5ZWP5LFBJYYGDA5ZWOTPJ/
Code of Conduct: http://python.org/psf/codeofconduct/