----- Original Message ----- From: "Giuseppe Scrivano" <gscriv...@gnu.org> To: "Bruno Haible" <br...@clisp.org> Cc: <bug-coreut...@gnu.org>; <bug-gnulib@gnu.org>; "Jim Meyering" <j...@meyering.net> 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 > > pthread_setaffinity_np [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 > > OMP_NUM_THREADS. [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))" huge_file > > > 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
