work took seconds the first four lines are the process id that was printed inside each muchcpu instance the last line shows that the million iterations can run in about seconds on my machine during that secondsmy process monitor indicated that all four of my cores were running at percent if we subclass threading thread instead of multiprocessing process in muchcputhe output looks like this work took seconds this timethe four threads are running inside the same process and take close to three times as long to run this is the cost of the global interpreter lockin other languages or implementations of pythonthe threaded version would run at least as fast as the multiprocessing versionwe might expect it to be four times as longbut remember that many other programs are running on my laptop in the multiprocessing versionthese programs also need share of the four cpus in the threading versionthose programs can use the other three cpus instead multiprocessing pools in generalthere is no reason to have more processes than there are processors on the computer there are few reasons for thisonly cpu_count(processes can run simultaneously each process consumes resources with full copy of the python interpreter communication between processes is expensive creating processes takes nonzero amount of time given these constraintsit makes sense to create at most cpu_count(processes when the program starts and then have them execute tasks as needed it is not difficult to implement basic series of communicating processes that does thisbut it can be tricky to debugtestand get right of coursepython being pythonwe don' have to do all this work because the python developers have already done it for us in the form of multiprocessing pools