Re: [PATCH] core-count: A new program to count the number of cpucores (original) (raw)

[Top][All Lists]

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

From: Gilles Espinasse
Subject: Re: [PATCH] core-count: A new program to count the number of cpucores
Date: Mon, 26 Oct 2009 08:07:42 +0100

----- Original Message ----- From: "Giuseppe Scrivano" <address@hidden> To: "Bruno Haible" <address@hidden> Cc: <address@hidden>; <address@hidden>; "Jim Meyering" <address@hidden> Sent: Monday, October 26, 2009 12:45 AM Subject: Re: [PATCH] core-count: A new program to count the number of cpucores

...

> If it is meant as a tool for helping the parallelization of tasks at the > shell script level, then it needs to take into account > 1) the fact that the current process may be limited to a certain subset > of the available CPUs. See the Linux/NetBSD function > pthreadsetaffinitynp [5][6] and the IRIX notion of a CPU that is > available only to root processes [7].

Probably it is better to add an option, making a difference between the number of "real" and "effective" cores. Where it is not possible to know correctly the latter, they'll coincide.

> 2) the wish of users to not use all processors at once. Users may want to > save 1 CPU for their GUI interactions. This can most comfortably be > done through an environment variable, such as > OMPNUMTHREADS. [8]

What about leave to the user the decisione to use less threads/processes than core-count reports?

For example, assuming that `sort' will soon get the --threads option and an user decides to use all cores except one to sort a file, then it can be done as:

sort --threads="$(($(core-count) - 1))" hugefile

Cheers, Giuseppe

that assume --threads is able to handle negative count or 0 Would not be more efficient to handle the count in core-count? That mean core-count should always report a minimum of 1 and discount from total the number passed as an option.

Probably the first usage of core-count will be to feed make -j

Gilles