Re: How many hardware threads?

[Ludovic Brenta <ludovic@ludovic-brenta.org>]

I can see the value in having your program discover the number of
hardware threads and starting one task on each. This value, however,
is only for quick and dirty solutions. A proper, more long-term and
Ada-like solution, takes into account a lot of factors:

* if a single processor core provides several threads, these threads
share execution units in the core, so assigning compute-intensive
tasks to such threads is counter-productive; in contrast, assigning
tasks that spend a lot of time waiting for external events to occur is
a good idea. So, for your problem, you probably want at most one task
per core, not one task per thread.

* if hardware threads or cores share a common data cache, using too
many tasks may result in cache contention and slow-downs.

* each task will need virtual memory; possibly lots of it; and backed
up by physical memory or you'll cause thrashing. So the number of
tasks you can run is constrained not only by the amount of hardware
threads and cores but also by the amount of physical memory you can
allocate to your program.

* finally, the system administrator must have the last word on how
many tasks your program should use; they might choose to spare one
processor core for the OS or interactive use while your program runs
in the background; or they can run several programs concurrently and
only allocate a fraction of the processors available to your program.

So, having your program discover the number of threads (more usefully,
cores) in the system should only provide a hint as to how many tasks
you can start and you should also provide at least a command-line
option for use by the administrator.

HTH

--
Ludovic Brenta.