Hi Bruno, Bruno Haible <br...@clisp.org> 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 s...@home, then > he will launch the s...@home 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. Regards, Giuseppe
