Hi Riccardo,
On 10/06/2020 5:51 pm, Riccardo Ghetta wrote:
Hi,
as an user, the "lua use case" is right what I need at work.
I realize that for python this is a niche case, and most users don't
need any of this, but I hope it will useful to understand why having
multiple independent interpreters in a single process can be an
essential feature.
The company I work for develop and sells a big C++ financial system with
python embedded, providing critical flexibility to our customers.
Python is used as a scripting language, with most cases having C++
calling a python script itself calling other C++ functions.
Most of the times those scripts are in workloads I/O bound or where the
time spent in python is negligible. > But some workloads are really cpu bound and those tend to become
GIL-bound, even with massive use of C++ helpers; some to the point that
GIL-contention makes up over 80% of running time, instead of 1-5%.
And every time our customers upgrade their server, they buy machines
with more cores and the contention problem worsens.
Different interpreters need to operate in their own isolated address
space, or there will be horrible race conditions.
Regardless of whether that separation is done in software or hardware,
it has to be done.
Whenever data contained in a Python object is passed to C/C++ code,
there are two ways to do it. Either pass the whole object, or a
reference to the underlying data.
By passing the underlying data, you can release the GIL, and your
problem is solved, or at least alleviated.
If you can't do that, and must pass the object, then all accesses to
that object must be protected by a per-interpreter lock.
That's because interpreters need to operate serially, or you'll get
horrible race conditions.
If you need to share objects across threads, then there will be
contention, regardless of how many interpreters there are, or which
processes they are in.
Obviously, our use case calls for per-thread separate interpreters:
server processes run continuously and already consume gigabytes of RAM,
so startup time or increased memory consumption are not issues. Shared
state also is not needed, actually we try to avoid it as much as possible.
In the end, removing process-global state is extremely interesting for us.
If the additional resource consumption is irrelevant, what's the
objection to spinning up a new processes?
Cheers,
Mark.
P.S.
Do try passing the underlying data, not the whole object, and dropping
the GIL when calling back into C++. It can be effective.
CPython already drops the GIL for some computational workloads
implemented in C, like compression.
_______________________________________________
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/6KYRUABTLNYNGNRBS5KRKPHKLKS2AI7U/
Code of Conduct: http://python.org/psf/codeofconduct/
