Re: gthread: how many cores do I have?

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.


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]