运行python用什么处理器_我的Python进程在哪个CPU核上运行？

Q: Is it true that a Python interpreter uses only one CPU core at a time to run all the threads?

不，GIL和CPU关联是不相关的概念。GIL可以在阻塞I/O操作期间释放，也就是在C扩展中进行长时间的CPU密集型计算。

如果一个线程在GIL上被阻塞；它可能不在任何CPU核心上，因此可以公平地说，纯Python多线程代码在CPython实现上一次只能使用一个CPU核心。Q: In other words, will the Python interpreter session 1 (from the figure) run all 3 threads (Main_thread, TCP_thread and UDP_thread) on one CPU core?

我不认为CPython隐式地管理CPU关联。它可能依赖于OS调度器来选择运行线程的位置。Python线程是在真正的OS线程之上实现的。Q: Or is the Python interpreter able to spread them over multiple cores?

要了解可用CPU的数量：>>> import os

>>> len(os.sched_getaffinity(0))

16

同样，线程是否调度在不同的cpu上并不取决于Python解释器。Q: Suppose that the answer to Question 1 is 'multiple cores', do I have a way to track on which core each thread is running, perhaps with some sporadic print statements? If the answer to Question 1 is 'only one core', do I have a way to track which one it is?>>> open("/proc/{pid}/stat".format(pid=os.getpid()), 'rb').read().split()[-14]

'4'

对于当前的可移植解决方案，请查看^{}是否公开此类信息。

您可以将当前进程限制为一组CPU：os.sched_setaffinity(0, {0}) # current process on 0-th coreQ: For this question we forget about threads, but we focus on the subprocess mechanism in Python. Starting a new subprocess implies starting up a new Python interpreter session/shell. Is this correct?

是的。subprocess模块创建新的操作系统进程。如果运行python可执行文件，那么它将启动一个新的Python interpeter。如果运行bash脚本，则不会创建新的Python解释器，即运行bash可执行文件不会启动新的Python解释器/会话/etcQ: Supposing that it is correct, will Python be smart enough to make that separate interpreter session run on a different CPU core? Is there a way to track this, perhaps with some sporadic print statements as well?

见上文（即，OS决定在哪里运行线程，并且可能有OS API公开线程的运行位置）。multiprocessing.Process(target=foo, args=(q,)).start()

multiprocessing.Process还会创建一个新的操作系统进程（运行一个新的Python解释器）。In reality, my subprocess is another file. So this example won't work for me.

Python使用模块来组织代码。如果代码在another_file.py中，那么import another_file在主模块中，并将another_file.foo传递给multiprocessing.Process。Nevertheless, how would you compare it to p = subprocess.Popen(..)? Does it matter if I start the new process (or should I say 'python interpreter instance') with subprocess.Popen(..)versus multiprocessing.Process(..)?

multiprocessing.Process()可能是在subprocess.Popen()之上实现的。multiprocessing提供了类似于threadingAPI的API，它抽象了python进程之间通信的细节（python对象如何序列化以在进程之间发送）。

如果没有CPU密集型任务，那么可以在单个进程中运行GUI和I/O线程。如果您有一系列CPU密集型任务，那么要同时使用多个CPU，可以使用多个带有C扩展名的线程，例如lxml、regex、numpy（或者使用Cython创建的线程），这些线程可以在长时间计算期间释放GIL，或者将它们卸载到单独的进程中（一个简单的方法是使用一个进程池，如提供的通过^{}）。Q: The community discussion raised a new question. There are apparently two approaches when spawning a new process (within a new Python interpreter instance):# Approach 1(a)

p = subprocess.Popen(['python', mySubprocessPath], shell = True)

# Approach 1(b) (J.F. Sebastian)

p = subprocess.Popen([sys.executable, mySubprocessPath])

# Approach 2

p = multiprocessing.Process(target=foo, args=(q,))

“方法1（a）”在POSIX上是错误的（尽管它可能在Windows上工作）。为了便于移植，请使用“方法1（b）”，除非您知道需要cmd.exe（在本例中传递一个字符串，以确保使用正确的命令行转义）。The second approach has the obvious downside that it targets just a function - whereas I need to open up a new Python script. Anyway, are both approaches similar in what they achieve?

subprocess创建新进程，任何进程，例如，您可以运行bash脚本。multprocessing用于在另一个进程中运行Python代码。将Python模块导入并运行其函数比将其作为脚本运行更灵活。见Call python script with input with in a python script using subprocess。