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
_______________________________________________
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list