On Thu, Sep 12, 2013 at 9:32 PM, Antoine Pitrou <solipsis@pitrou.net> wrote:
On Thu, 12 Sep 2013 21:26:07 +0200
"Giampaolo Rodola'" <g.rodola@gmail.com>
wrote:
> On Thu, Sep 12, 2013 at 9:10 PM, Antoine Pitrou <solipsis@pitrou.net> wrote:
>
> > On Thu, 12 Sep 2013 20:59:46 +0200
> > "Giampaolo Rodola'" <g.rodola@gmail.com>
> > wrote:
> > > This is a follow up of a feature request which recently appeared on
> > psutil
> > > bug tracker:
> > > https://code.google.com/p/psutil/issues/detail?id=427
> > >
> > > I don't know whether the proposal makes sense for psutil per-se but it
> > > certainly made me think about multiprocessing.cpu_count() and the fact
> > that
> > > it currently returns the number of virtual CPUs (physical + logical).
> > >
> > > Given that multiple processes cannot take any advantage of hyper
> > threading
> > > technology
> >
> > Of course they can.  The CPU doesn't distinguish between different
> > kinds of "threads", they can either belong to the same process or to
> > different ones.
>
>
> Of course you're right, I'm sorry. I should have phrased my statement more
> carefully before sending the email.
> Then the question is whether having physical CPU cores count can be useful.

I suppose it doesn't hurt :-) I don't think it belongs specifically in
multiprocessing, though. Perhaps in the platform module?

I'd be +0.5 for multiprocessing because:

- cpu_count() is already there
- physical_cpu_count() will likely be used by multiprocessing users only

...but my main concern was first figuring out whether it might actually make sense to distinguish between virtual and physical CPUs in a real world app.
 
(unless you want to contribute psutil to the stdlib?)

That's something I'd be happy to do if there's general approval but I guess that's for another thread. 

--- Giampaolo
https://code.google.com/p/pyftpdlib/
https://code.google.com/p/psutil/
https://code.google.com/p/pysendfile/