In Python, a common way to retrieve the number of CPUs on a given system is to retrieve the number of CPUs from system configuration values as shown in this entry. Here is the actual function taken from the entry:
def detectCPUs():
"""
Detects the number of CPUs on a system. Cribbed from pp.
"""
# Linux, Unix and MacOS:
if hasattr(os, "sysconf"):
if os.sysconf_names.has_key("SC_NPROCESSORS_ONLN"):
# Linux & Unix:
ncpus = os.sysconf("SC_NPROCESSORS_ONLN")
if isinstance(ncpus, int) and ncpus > 0:
return ncpus
else: # OSX:
return int(os.popen2("sysctl -n hw.ncpu")[1].read())
# Windows:
if os.environ.has_key("NUMBER_OF_PROCESSORS"):
ncpus = int(os.environ["NUMBER_OF_PROCESSORS"]);
if ncpus > 0:
return ncpus
return 1 # Default
There is one very basic problem to using this approach in that it introduces new code at the application level that is already implemented at the Python language level in the multiprocessing module. There is a much simpler and more elegant method of retrieving the number of CPUs available on the system.
import multiprocessing
cpus=multiprocessing.cpu_count()
A use case for using the number of CPUs available on a system within the context of a Python application would be maximizing the concurrency efficiency. The multiprocessing and threading modules share the same interfaces for most abstractions. This means that the application could make a decision at runtime on which module is best suited for the job based on the number of available CPUs. If there is a single CPU on the system in question, the threading module might be better suited. There there are multiple processors available, then multiprocessing might be better suited.
The backport of multiprocessing for 2.5 and earlier is really not all that great - Jesse Noller found some bugs in the core of the interpreter that cause it to crash under certain circumstances while using multiprocessing, and if at all possible you'll be worlds better off using 2.6 instead of trying to play with fire.
ReplyDelete@augie The backport works, but lacks fixes to a deadlock-after-fork issues we found in core. The backport is very similiar to the original pyprocessing code in that respect. If people have been using pyprocessing, then the backport should work for them.
ReplyDeleteI use the backport and it works great. It runs for a few hours a day spawning lots of processes (10s of thousands)
ReplyDeletemonk.e.boy