[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: New module nproc
From: |
Bruno Haible |
Subject: |
Re: New module nproc |
Date: |
Thu, 26 Mar 2009 00:42:56 +0100 |
User-agent: |
KMail/1.9.9 |
Hi Paul,
> +/* Return the total number of processors. The result is guaranteed to
> + be at least 1. */
> +unsigned long int
> +num_processors (void)
> +{
> +#ifdef _SC_NPROCESSORS_ONLN
> + long int nprocs = sysconf (_SC_NPROCESSORS_ONLN);
> + if (0 < nprocs)
> + return nprocs;
> +#endif
It appears that this code is right according to POSIX, but does not catch
the entire reality on Linux. (A comment in libgomp/config/linux/proc.c says:
"Count only the CPUs this process can use.")
And on mingw, a different API should be used. See the implementation of the
function omp_get_num_procs() in libgomp, part of GCC:
- for POSIX systems:
http://gcc.gnu.org/viewcvs/trunk/libgomp/config/posix/proc.c?revision=138078&view=markup
- for Linux:
http://gcc.gnu.org/viewcvs/trunk/libgomp/config/linux/proc.c?revision=138078&view=markup
- for mingw:
http://gcc.gnu.org/viewcvs/trunk/libgomp/config/mingw32/proc.c?revision=138078&view=markup
This leads to the question: Why not use the AC_OPENMP macro, and then use the
following?
unsigned long int
num_processors (void)
{
#ifdef _OPENMP
return omp_get_num_procs ();
#else
... existing implementation ...
#endif
}
This would get the count right on Linux, mingw, and on POSIX systems, i.e.
nearly everywhere.
Also, the omp_get_num_procs() function has the advantage that you can
influence it through an environment variable, so that users have the ability
to let multithreaded programs access only, say, 3 out of 4 CPU cores, if
a responsive machine is more important to them than fast execution.
Bruno