anfedorov / psutil

Automatically exported from code.google.com/p/psutil
Other
0 stars 0 forks source link

API to report physical CPU core count #427

Closed GoogleCodeExporter closed 8 years ago

GoogleCodeExporter commented 8 years ago
psutil (and other Python mechanisms such as multiprocessing.cpu_count()) report 
the number of logical cores on a machine. This includes hyperthreaded cores. I 
think it would be rad if psutil could report the count of *physical* CPU cores 
as well.

Here is how you would get this info on OS X, Linux, and Windows:

OS X: 
http://stackoverflow.com/questions/5143839/getting-number-of-cpus-on-mac-os-x-fr
om-c
Linux: http://xmodulo.com/2012/06/how-to-find-number-of-cpu-cores-on.html 
(essentially parsing /proc/cpuinfo)
Windows: GetLogicalProcessorInformation 
http://msdn.microsoft.com/en-us/library/ms683194

If there is interest in this feature, this is something I'd consider 
implementing.

Original issue reported on code.google.com by gregory....@gmail.com on 10 Sep 2013 at 11:21

GoogleCodeExporter commented 8 years ago
Why do you think this would be so important? Do you have a use case?

Original comment by g.rodola on 10 Sep 2013 at 11:51

GoogleCodeExporter commented 8 years ago
Use case: https://bugzilla.mozilla.org/show_bug.cgi?id=914431

Original comment by gregory....@gmail.com on 10 Sep 2013 at 11:57

GoogleCodeExporter commented 8 years ago
I'd like to investigate further into other possible use cases as I don't find 
the one described in there particularly convincing.

According to Google it looks like some demand certainly exists:
https://www.google.com/search?q=python+get+pysical+cpu+count&oq=python+get+pysic
al+cpu+count&aqs=chrome..69i57j0.6003j0&sourceid=chrome&ie=UTF-8#q=python+get+ph
ysical+cpu+count&spell=1

...but for some reason I find myself doubtful.

What's the point of pre-emptively knowing whether a build is gonna finish 15 
minutes later?
I mean, there's nothing you can do about that anyway except buying new hardware.
What about other possible causes for longer processing time such as ram 
temporarily swapping to disk or other processes hogging all CPU resources?
Does it make sense for an app to make such kind of checks on start and warn the 
user as a consequence?
Maybe it does but those are problems which can be fixed by freeing resources, 
and this is not the case.

The only valid use case I can think of is when using multiprocessing module.
In that case it might make sense to spawn as many processes as the number of 
available physical cores, but then again I wonder why this hasn't already 
landed into multiprocessing module.

Original comment by g.rodola on 12 Sep 2013 at 6:35

GoogleCodeExporter commented 8 years ago
I'm not going to spend too much energy convincing you to take this feature: I'm 
going to be implementing it one way or another. I just figured I'd attempt to 
upstream it into psutil so others can benefit from the effort.

Original comment by gregory....@gmail.com on 12 Sep 2013 at 6:37

GoogleCodeExporter commented 8 years ago
...and I'm trying to figure out whether it makes sense to have it from a 
real-world application standpoint, that's all.
There's no need to be harsh.

Original comment by g.rodola on 12 Sep 2013 at 7:08

GoogleCodeExporter commented 8 years ago
I did not mean to be harsh. Just trying to explain where I stand. I appreciate 
psutil and want to give back.

Original comment by gregory....@gmail.com on 12 Sep 2013 at 7:34

GoogleCodeExporter commented 8 years ago
After receiving positive response on python-ideas:
https://mail.python.org/pipermail/python-ideas/2013-September/023138.html
...I'm OK with adding this feature.

Gregory do you think you can come up with a patch?
I would like to expose this as a psutil.NUM_PHYS_CPUS variable calculated at 
import time.

Also, other than the platforms you already mentioned we'll also need Solaris.

Original comment by g.rodola on 25 Sep 2013 at 9:36

GoogleCodeExporter commented 8 years ago
I managed to implement this on all platforms:

Linux: revision 8f1badef10a4
OSX: revision 2f0482f72c8c
BSD: revision e61d0875d976
Windows: revision 6207bf18a3ed
SunOS: revision e26238337e68

Original comment by g.rodola on 14 Dec 2013 at 2:22

GoogleCodeExporter commented 8 years ago
Closing out as fixed as 2.0.0 version is finally out.

Original comment by g.rodola on 10 Mar 2014 at 11:36