bug-gnulib
[Top][All Lists]
Advanced

[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




reply via email to

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