[Top][All Lists]

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

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

From: Giuseppe Scrivano
Subject: Re: [PATCH] core-count: A new program to count the number of cpu cores
Date: Tue, 27 Oct 2009 09:42:41 +0100
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/23.1.50 (gnu/linux)

Hi Bruno,

Bruno Haible <address@hidden> writes:

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

Thanks, I will add this note to the documentation.

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

Ok, that makes sense.

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

I am not working on the multi-threaded sort, but if somebody asks I can
make it read OMP_NUM_THREADS.
If is is already used by other GNU programs, then it seems a good idea
to use this value when --threads is not specified on the command line.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]