Re: gthread: how many cores do I have?

[Mark Mielke <mark mark mielke cc>]

On 04/04/2010 03:34 PM, Pavel Machek wrote:
> > > And then the valid question is... should the api also count virtual
> > > cpus from hyperthreading (aka smt?)?
> > >        
> > BOTH should be available.  If we're spinning up threads to perform some processing, then we need to count those virtual cores.  But if we're starting a child program to perform some processing, then we need to know the count of real cores instead.
> Actually, SMT machine can execute threads from different processes at
> the same time; so you should use number of virtual processors for
> children, too.
>    

Posters you are responding to is pointing out that there is a difference 
between how many threads can execute simultaneously, and how many 
threads can expect to have full access to a machine core while they execute.

The early implementations that assumed one virtual core = one physical 
core, would exhibit very bad performance characteristics  if they tried 
to schedule two tasks to the same physical core on a regular basis. For 
example, if both are trying to do floating point operations, and the 
floating point units in the single physical core, the overall 
performance of both threads executing simultaneously can be even poorer 
than one thread executing tasks serially.

Optimally - both counts should be available. How many tasks can I run 
simultaneously at near 100% CPU vs how many tasks can I run 
simultaneously at any % of the CPU.

A task doing video encoding or anything that would monopolize much of 
the CPU, would probably use the first count, whereas something doing 
heavy I/O and quick transfers of data from one thread to the other might 
choose the latter count.

Cheers,
mark