Dedicated CPU core for Python?

[Louise Hoffman]

Dear readers,

I was wondering, if Python in the foerseeable future will allocate one
CPU core just for the interpreter, so heavy Python operations does
slow down the OS?

It seams to me like a perfect use for a CPU core =)

Lots of love,
Louise

 

[Michael Hoffman]

I was wondering, if Python in the foerseeable future will allocate one
CPU core just for the interpreter, so heavy Python operations does
slow down the OS?

When running scripts, or loading modules, Python does not really behave
as an interpreter. Instead it compiles the human-readable code to a
bytecode which it then runs on a virtual machine.

 

[Joshua J. Kugler]

Dear readers,

I was wondering, if Python in the foerseeable future will allocate one
CPU core just for the interpreter, so heavy Python operations does
slow down the OS?

It seams to me like a perfect use for a CPU core =)

Are you talking about CPU affinity
(http://en.wikipedia.org/wiki/Processor_affinity) or an actual CPU that can
directory execute Python byte code? If the former, CPython only uses one
CPU core right now because it's threads are all internal, and do not spawn
system threads (IIRC). If the latter, I don't think that would work very
well because then, e.g., C extensions wouldn't work very well as they could
not be executed by a Python Byte-code CPU.

j

 

[John Nagle]

When running scripts, or loading modules, Python does not really behave
as an interpreter. Instead it compiles the human-readable code to a
bytecode which it then runs on a virtual machine.

That's how interpreters have worked since UCSD Pascal, circa 1977.
Very few direct source interpreters, where the source is reprocessed
each time a line is executed, are still used. The original IBM PC
had one of those in ROM. Everbody grinds the code down to some kind
of tree representation, and usually represents the tree as a string
of operations for a stack machine. Then a little intepreter runs
the stack machine. This is typically 10-100x slower than executing
code compiled to the real machine.

I saw a true source interpreter in a Galil industrial
motor controller as recently as 2004, but that's one of the few
remaining uses for that obsolete technology. When the documentation
says that comments take time to execute, you've found one of those
antiques.

John Nagle

 

[Gabriel Genellina]

En Thu, 26 Apr 2007 15:54:38 -0300, Joshua J. Kugler

Are you talking about CPU affinity
(http://en.wikipedia.org/wiki/Processor_affinity) or an actual CPU that
can directory execute Python byte code? If the former, CPython only
uses one
CPU core right now because it's threads are all internal, and do not
spawn system threads (IIRC).

Python threads are OS threads:
http://docs.python.org/lib/module-thread.html
"[The thread module] is supported on Windows, Linux, SGI IRIX, Solaris
2.x, as well as on systems that have a POSIX thread (a.k.a. ``pthread'')
implementation."

 

[Louise Hoffman]

Are you talking about CPU affinity

(http://en.wikipedia.org/wiki/Processor_affinity) or an actual CPU that can
directory execute Python byte code? If the former, CPython only uses one
CPU core right now because it's threads are all internal, and do not spawn
system threads (IIRC). If the latter, I don't think that would work very
well because then, e.g., C extensions wouldn't work very well as they could
not be executed by a Python Byte-code CPU.

Have I understood CPU affinity correct, that it is similar to SMP/
NUMA, only that I can force a process/thread to a cpu core?

In regards to forcing the Python virtual machine (thanks Michael for
the explanation=) ), is the problem that the "OS core" and the "VM
core" would need to copy each others cache/exchange data too often?

Hugs,
Louise

 

[Joshua J. Kugler]

En Thu, 26 Apr 2007 15:54:38 -0300, Joshua J. Kugler

Are you talking about CPU affinity
(http://en.wikipedia.org/wiki/Processor_affinity) or an actual CPU that
can directory execute Python byte code? If the former, CPython only
uses one
CPU core right now because it's threads are all internal, and do not
spawn system threads (IIRC).

Python threads are OS threads:
http://docs.python.org/lib/module-thread.html
"[The thread module] is supported on Windows, Linux, SGI IRIX, Solaris
2.x, as well as on systems that have a POSIX thread (a.k.a. ``pthread'')
implementation."

Yes, that may be, but they are not true system threads, or at least do not
appear to be. Threads on linux each show up as a separate process. I can
have several threads in my Python program, but no additional processes show
up in ps -A. I don't see how Python threads can be system threads with the
GIL. But, I've been wrong before, and threads are something I have very
light knowledge of.

j

 

[John Nagle]

En Thu, 26 Apr 2007 15:54:38 -0300, Joshua J. Kugler

Are you talking about CPU affinity
(http://en.wikipedia.org/wiki/Processor_affinity) or an actual CPU that
can directory execute Python byte code? If the former, CPython only
uses one
CPU core right now because it's threads are all internal, and do not
spawn system threads (IIRC).

Python threads are OS threads:
http://docs.python.org/lib/module-thread.html
"[The thread module] is supported on Windows, Linux, SGI IRIX, Solaris
2.x, as well as on systems that have a POSIX thread (a.k.a. ``pthread'')
implementation."

Yes, that may be, but they are not true system threads, or at least do not
appear to be. Threads on linux each show up as a separate process. I can
have several threads in my Python program, but no additional processes show
up in ps -A. I don't see how Python threads can be system threads with the
GIL. But, I've been wrong before, and threads are something I have very
light knowledge of.

OK. What's going on inside CPython is this:

Each Python thread is an operating system thread, managed through
the POSIX pthreads interface. On a system with more than one CPU,
more than one such thread can run at a time.

But, because the CPython system isn't really reentrant, most of the
data structures have to be protected against simultaneous access by the Global
Interpreter Lock. So, when you have multiple compute-bound threads
on multiple CPUs in Python, at any one time, no more than one of them
is executing the CPython interpreter. The others are blocked on the
Global Interpreter Lock.

The lock is unlocked before I/O requests and such, which allows another
thread to run while threads are blocked waiting for an I/O operation to
complete.

That's why having multiple CPUs ("dual core" in marketing jargon)
won't improve Python performance.

This is an implementation limitation of CPython and its libraries.
Jython and Iron Python don't have this issue.

John Nagle

 

[sjdevnull]

En Thu, 26 Apr 2007 15:54:38 -0300, Joshua J. Kugler
<[email protected]> escribió:

Python threads are OS threads:
http://docs.python.org/lib/module-thread.html
"[The thread module] is supported on Windows, Linux, SGI IRIX, Solaris
2.x, as well as on systems that have a POSIX thread (a.k.a. ``pthread'')
implementation."

Yes, that may be, but they are not true system threads, or at least do not
appear to be. Threads on linux each show up as a separate process.

No they don't, they used to with LinuxThreads but with newer kernels/
thread libraries/ps they no longer show up as processes.

Python threads are OS threads on Linux. If you run strace on a simple
python program that generates a thread, you can see the clone() call.

 

[Tim Roberts]

Have I understood CPU affinity correct, that it is similar to SMP/
NUMA, only that I can force a process/thread to a cpu core?

In regards to forcing the Python virtual machine (thanks Michael for
the explanation=) ), is the problem that the "OS core" and the "VM
core" would need to copy each others cache/exchange data too often?

You do not understand what you are asking. The only possible effect of
your suggestion would be to REDUCE overall system throughput. Your
operating system's scheduler has been carefully tuned to make sure that all
of your CPU cores are kept busy, and are shared evenly amongst all of the
tasks that are ready to run.

By artificially limiting the options as you suggest, you tie the hands of
the scheduler so that it can't make the most effective use of the
resources.

Except for specific needs in some drivers, the use of CPU and thread
affinity is virtually never a good idea.

 

[Gabriel Genellina]

Joshua J. Kugler ha escrito:

En Thu, 26 Apr 2007 15:54:38 -0300, Joshua J. Kugler
<[email protected]> escribió:

CPython only
uses one
CPU core right now because it's threads are all internal, and do not
spawn system threads (IIRC).

Python threads are OS threads:
http://docs.python.org/lib/module-thread.html
"[The thread module] is supported on Windows, Linux, SGI IRIX, Solaris
2.x, as well as on systems that have a POSIX thread (a.k.a. ``pthread'')
implementation."

Yes, that may be, but they are not true system threads, or at least do not
appear to be. Threads on linux each show up as a separate process. I can
have several threads in my Python program, but no additional processes show
up in ps -A. I don't see how Python threads can be system threads with the
GIL. But, I've been wrong before, and threads are something I have very
light knowledge of.

Try with ps -L

gag@4[~]$ ps -L -C python
PID LWP TTY TIME CMD
3952 3952 pts/1 00:00:03 python
3952 3956 pts/1 00:00:00 python
3952 3957 pts/1 00:00:00 python
3952 3958 pts/1 00:00:00 python
3952 3959 pts/1 00:00:00 python
3952 3960 pts/1 00:00:00 python
3952 3961 pts/1 00:00:00 python
3952 3962 pts/1 00:00:00 python

Or ps --help depending on your system.