Re: [PATCH] core-count: A new program to count the number of cpu cores

[Bruno Haible]

Hi Giuseppe,

> No, it should not be a hardware inspection tool but a portable
> tool to help shell scripts to have an idea of how many
> processes can be executed at the same time.  If we get too
> much into details then we loose portability

Good. This is important info; IMO it belongs in the
coreutils.texi documentation.

> >   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.

Yes, and for the intended use that you described above
the number of "available" cores should the result without
an option, whereas the "installed" cores would require
an option. (I would not want to use the terms "real" and
"effective" here because that brings up wrong associations
with user ids and group ids.)

> >   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?

This is precisely what can be achieved with the
OMP_NUM_THREADS variable. Say, he has a CPU with 4 cores,
wants to reserve 1 for his GUI and 1 for address@hidden, then
he will launch the address@hidden process with OMP_NUM_THREADS=1
and all other processes with OMP_NUM_THREADS=2.

> 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

Or possibly by:
  env OMP_NUM_THREADS="$(($(core-count) - 1))" sort huge_file
no?

Some programs, like 'msgmerge' from GNU gettext, already pay
attention to the OMP_NUM_THREADS variable - a convention shared
by all programs that rely on OpenMP. Can you make the 'sort'
program use the same convention?

Bruno