Re: implementation of std::thread::hardware_concurrency()
I'm testing my suggestion on a netbsd machine, I'd be grateful for darwin testing once I've committed it, which I expect to be later today.
Re: implementation of std::thread::hardware_concurrency()
I am currently working on a patch for OpenBSD.I wrote a some autoconf tests for mingw/*BSD. 2011/11/7 Jonathan Wakely jwakely@gmail.com: I'm testing my suggestion on a netbsd machine, I'd be grateful for darwin testing once I've committed it, which I expect to be later today.
Re: implementation of std::thread::hardware_concurrency()
This provides a working thread::hardware_concurrency on platforms that
support pthread_num_processors_np or the hw.ncpu sysctl, but by
testing for the features in configure rather than hardcoding OS macro
tests in thread.cc
* acinclude.m4 (GLIBCXX_CHECK_SC_NPROC_ONLN): Define.
(GLIBCXX_CHECK_PTHREADS_NUM_PROCESSORS_NP): Define.
(GLIBCXX_CHECK_SYSCTL_HW_NCPU): Define.
* configure.ac: Use new checks.
* configure: Regenerate.
* config.h.in: Regenerate.
* src/thread.cc: Check new config macros.
* testsuite/lib/libstdc++.exp: Likewise.
Tested x86_64-linux and x86_64-netbsd5.1, committed to trunk
Index: acinclude.m4
===
--- acinclude.m4 (revision 181081)
+++ acinclude.m4 (working copy)
@@ -3459,7 +3459,95 @@
AC_LANG_RESTORE
])
+dnl
+dnl Check whether sysconf(_SC_NPROC_ONLN) is available in unistd.h, and define _GLIBCXX_USE_SC_NPROC_ONLN.
+dnl
+AC_DEFUN([GLIBCXX_CHECK_SC_NPROC_ONLN], [
+ AC_LANG_SAVE
+ AC_LANG_CPLUSPLUS
+ ac_save_CXXFLAGS=$CXXFLAGS
+ CXXFLAGS=$CXXFLAGS -fno-exceptions
+
+ AC_MSG_CHECKING([for _SC_NPROC_ONLN])
+ AC_CACHE_VAL(glibcxx_cv_SC_NPROC_ONLN, [
+GCC_TRY_COMPILE_OR_LINK(
+ [#include unistd.h],
+ [int n = sysconf(_SC_NPROC_ONLN);],
+ [glibcxx_cv_SC_NPROC_ONLN=yes],
+ [glibcxx_cv_SC_NPROC_ONLN=no])
+ ])
+ if test $glibcxx_cv_SC_NPROC_ONLN = yes; then
+AC_DEFINE(_GLIBCXX_USE_SC_NPROC_ONLN, 1, [Define if _SC_NPROC_ONLN is available in unistd.h.])
+ fi
+ AC_MSG_RESULT($glibcxx_cv_SC_NPROC_ONLN)
+
+ CXXFLAGS=$ac_save_CXXFLAGS
+ AC_LANG_RESTORE
+])
+
+dnl
+dnl Check whether pthread_num_processors_np is available in pthread.h, and define _GLIBCXX_USE_PTHREADS_NUM_PROCESSORS_NP.
+dnl
+AC_DEFUN([GLIBCXX_CHECK_PTHREADS_NUM_PROCESSORS_NP], [
+
+ AC_LANG_SAVE
+ AC_LANG_CPLUSPLUS
+ ac_save_CXXFLAGS=$CXXFLAGS
+ CXXFLAGS=$CXXFLAGS -fno-exceptions
+
+ AC_MSG_CHECKING([for pthreads_num_processors_np])
+ AC_CACHE_VAL(glibcxx_cv_PTHREADS_NUM_PROCESSORS_NP, [
+GCC_TRY_COMPILE_OR_LINK(
+ [#include pthread.h],
+ [int n = pthread_num_processors_np();],
+ [glibcxx_cv_PTHREADS_NUM_PROCESSORS_NP=yes],
+ [glibcxx_cv_PTHREADS_NUM_PROCESSORS_NP=no])
+ ])
+ if test $glibcxx_cv_PTHREADS_NUM_PROCESSORS_NP = yes; then
+AC_DEFINE(_GLIBCXX_USE_PTHREADS_NUM_PROCESSORS_NP, 1, [Define if pthreads_num_processors_np is available in pthread.h.])
+ fi
+ AC_MSG_RESULT($glibcxx_cv_PTHREADS_NUM_PROCESSORS_NP)
+
+ CXXFLAGS=$ac_save_CXXFLAGS
+ AC_LANG_RESTORE
+])
+
+dnl
+dnl Check whether sysctl is available in pthread.h, and define _GLIBCXX_USE_SYSCTL_HW_NCPU.
+dnl
+AC_DEFUN([GLIBCXX_CHECK_SYSCTL_HW_NCPU], [
+
+ AC_LANG_SAVE
+ AC_LANG_CPLUSPLUS
+ ac_save_CXXFLAGS=$CXXFLAGS
+ CXXFLAGS=$CXXFLAGS -fno-exceptions
+
+ AC_MSG_CHECKING([for hw.ncpu sysctl])
+ AC_CACHE_VAL(glibcxx_cv_SYSCTL_HW_NCPU, [
+GCC_TRY_COMPILE_OR_LINK(
+ [
+ #include stddef.h
+ #include sys/sysctl.h
+ ],
+ [
+ int count;
+ size_t size = sizeof(count);
+ int mib[] = { CTL_HW, HW_NCPU };
+ sysctl(mib, 2, count, size, NULL, 0);
+ ],
+ [glibcxx_cv_SYSCTL_HW_NCPU=yes],
+ [glibcxx_cv_SYSCTL_HW_NCPU=no])
+ ])
+ if test $glibcxx_cv_SYSCTL_HW_NCPU = yes; then
+AC_DEFINE(_GLIBCXX_USE_SYSCTL_HW_NCPU, 1, [Define if sysctl(), CTL_HW and HW_NCPU are available in sys/sysctl.h.])
+ fi
+ AC_MSG_RESULT($glibcxx_cv_SYSCTL_HW_NCPU)
+
+ CXXFLAGS=$ac_save_CXXFLAGS
+ AC_LANG_RESTORE
+])
+
# Macros from the top-level gcc directory.
m4_include([../config/gc++filt.m4])
m4_include([../config/tls.m4])
Index: configure.ac
===
--- configure.ac (revision 181081)
+++ configure.ac (working copy)
@@ -174,6 +174,9 @@
GLIBCXX_CHECK_GET_NPROCS
AC_CHECK_HEADERS(unistd.h)
GLIBCXX_CHECK_SC_NPROCESSORS_ONLN
+GLIBCXX_CHECK_SC_NPROC_ONLN
+GLIBCXX_CHECK_PTHREADS_NUM_PROCESSORS_NP
+GLIBCXX_CHECK_SYSCTL_HW_NCPU
# Check for available headers.
AC_CHECK_HEADERS([endian.h execinfo.h float.h fp.h ieeefp.h inttypes.h \
Index: src/thread.cc
===
--- src/thread.cc (revision 181081)
+++ src/thread.cc (working copy)
@@ -30,9 +30,27 @@
#if defined(_GLIBCXX_USE_GET_NPROCS)
# include sys/sysinfo.h
# define _GLIBCXX_NPROCS get_nprocs()
+#elif defined(_GLIBCXX_USE_PTHREADS_NUM_PROCESSORS_NP)
+# define _GLIBCXX_NPROCS pthread_num_processors_np()
+#elif defined(_GLIBCXX_USE_SYSCTL_HW_NCPU)
+# include stddef.h
+# include sys/sysctl.h
+static inline int get_nprocs()
+{
+ int count;
+ size_t size = sizeof(count);
+ int mib[] = { CTL_HW, HW_NCPU };
+ if (!sysctl(mib, 2, count, size, NULL, 0))
+ return count;
+ return 0;
+}
+# define _GLIBCXX_NPROCS get_nprocs()
#elif defined(_GLIBCXX_USE_SC_NPROCESSORS_ONLN)
# include unistd.h
# define _GLIBCXX_NPROCS sysconf(_SC_NPROCESSORS_ONLN)
+#elif
Re: implementation of std::thread::hardware_concurrency()
On 7 Nov 2011, at 13:45, Jonathan Wakely wrote: This provides a working thread::hardware_concurrency on platforms that support pthread_num_processors_np or the hw.ncpu sysctl, but by testing for the features in configure rather than hardcoding OS macro tests in thread.cc if the system supports run-time User-controllable core-count then this will not account for that. * acinclude.m4 (GLIBCXX_CHECK_SC_NPROC_ONLN): Define. (GLIBCXX_CHECK_PTHREADS_NUM_PROCESSORS_NP): Define. (GLIBCXX_CHECK_SYSCTL_HW_NCPU): Define. * configure.ac: Use new checks. * configure: Regenerate. * config.h.in: Regenerate. * src/thread.cc: Check new config macros. * testsuite/lib/libstdc++.exp: Likewise. Tested x86_64-linux and x86_64-netbsd5.1, committed to trunk nprocs.patch
Re: implementation of std::thread::hardware_concurrency()
On 7 November 2011 14:10, Iain Sandoe wrote: On 7 Nov 2011, at 13:45, Jonathan Wakely wrote: This provides a working thread::hardware_concurrency on platforms that support pthread_num_processors_np or the hw.ncpu sysctl, but by testing for the features in configure rather than hardcoding OS macro tests in thread.cc if the system supports run-time User-controllable core-count then this will not account for that. Yep. Do you know how to detect the right value in that case? If not the alternative is to revert to the previous behaviour of returning zero. (My understanding was that at least some of the options would work for that case, NPROCESSORS_ONLN is distinct from _SC_NPROCESSORS_CONF, for example)
Re: implementation of std::thread::hardware_concurrency()
On 7 November 2011 14:16, Jonathan Wakely wrote: On 7 November 2011 14:10, Iain Sandoe wrote: On 7 Nov 2011, at 13:45, Jonathan Wakely wrote: This provides a working thread::hardware_concurrency on platforms that support pthread_num_processors_np or the hw.ncpu sysctl, but by testing for the features in configure rather than hardcoding OS macro tests in thread.cc if the system supports run-time User-controllable core-count then this will not account for that. Yep. Do you know how to detect the right value in that case? If not the alternative is to revert to the previous behaviour of returning zero. (My understanding was that at least some of the options would work for that case, NPROCESSORS_ONLN is distinct from _SC_NPROCESSORS_CONF, for example) ... which might be a reason to prefer sysconf to sysctl if the latter doesn't handle disabled cores (NetBSD supports both, but I found the sysctl to be slightly faster, so ordered the checks to prefer sysctl) Pretty much the only docs I have to go on for this are glibc's http://www.gnu.org/s/hello/manual/libc/Processor-Resources.html so I know disabled cores are accounted for correctly on GNU systems. If people care about other platforms they need to provide working code, or at least point me at decent documentation.
Re: implementation of std::thread::hardware_concurrency()
On 7 Nov 2011, at 14:16, Jonathan Wakely wrote: On 7 November 2011 14:10, Iain Sandoe wrote: On 7 Nov 2011, at 13:45, Jonathan Wakely wrote: This provides a working thread::hardware_concurrency on platforms that support pthread_num_processors_np or the hw.ncpu sysctl, but by testing for the features in configure rather than hardcoding OS macro tests in thread.cc if the system supports run-time User-controllable core-count then this will not account for that. Yep. Do you know how to detect the right value in that case? If not the alternative is to revert to the previous behaviour of returning zero. (My understanding was that at least some of the options would work for that case, NPROCESSORS_ONLN is distinct from _SC_NPROCESSORS_CONF, for example) Hm. I don't know about the general case - on Darwin it's certainly possible to get at the information at runtime; hw.logicalcpu_max: 4 hw.logicalcpu: 4 hw.physicalcpu_max: 4 hw.physicalcpu: 4 hw.ncpu = 4 and ... switching the control panel to dual CPU .. hw.logicalcpu_max: 4 hw.logicalcpu: 2 hw.physicalcpu_max: 4 hw.physicalcpu: 2 hw.ncpu = 4 but, as you say, that would be the implication of ONLN vs CONF .. cheers Iain
Re: implementation of std::thread::hardware_concurrency()
On 7 November 2011 14:23, Iain Sandoe wrote: On 7 Nov 2011, at 14:16, Jonathan Wakely wrote: On 7 November 2011 14:10, Iain Sandoe wrote: On 7 Nov 2011, at 13:45, Jonathan Wakely wrote: This provides a working thread::hardware_concurrency on platforms that support pthread_num_processors_np or the hw.ncpu sysctl, but by testing for the features in configure rather than hardcoding OS macro tests in thread.cc if the system supports run-time User-controllable core-count then this will not account for that. Yep. Do you know how to detect the right value in that case? If not the alternative is to revert to the previous behaviour of returning zero. (My understanding was that at least some of the options would work for that case, NPROCESSORS_ONLN is distinct from _SC_NPROCESSORS_CONF, for example) Hm. I don't know about the general case - on Darwin it's certainly possible to get at the information at runtime; hw.logicalcpu_max: 4 hw.logicalcpu: 4 hw.physicalcpu_max: 4 hw.physicalcpu: 4 hw.ncpu = 4 and ... switching the control panel to dual CPU .. hw.logicalcpu_max: 4 hw.logicalcpu: 2 hw.physicalcpu_max: 4 hw.physicalcpu: 2 hw.ncpu = 4 but, as you say, that would be the implication of ONLN vs CONF .. Does Darwin support those sysconf values? AFAICT it doesn't. If not, we could find out the equivalent of HW_NCPU for hw.logicalcpu or just use sysctlbyname, but as Apple haven't documented it in the sysctl manpage I don't know if those sysctls are stable or reliable. If someone wants to improve the checks be my guest, as long as it's done via autoconf macros, not by making the macro mess in src/thread.cc any worse.
Re: implementation of std::thread::hardware_concurrency()
On 7 Nov 2011, at 14:23, Iain Sandoe wrote:
On 7 Nov 2011, at 14:16, Jonathan Wakely wrote:
On 7 November 2011 14:10, Iain Sandoe wrote:
On 7 Nov 2011, at 13:45, Jonathan Wakely wrote:
This provides a working thread::hardware_concurrency on platforms
that
support pthread_num_processors_np or the hw.ncpu sysctl, but by
testing for the features in configure rather than hardcoding OS
macro
tests in thread.cc
if the system supports run-time User-controllable core-count then
this will
not account for that.
Yep. Do you know how to detect the right value in that case? If not
the alternative is to revert to the previous behaviour of returning
zero.
(My understanding was that at least some of the options would work
for
that case, NPROCESSORS_ONLN is distinct from _SC_NPROCESSORS_CONF,
for
example)
Hm. I don't know about the general case - on Darwin it's certainly
possible to get at the information at runtime;
hw.logicalcpu_max: 4
hw.logicalcpu: 4
hw.physicalcpu_max: 4
hw.physicalcpu: 4
hw.ncpu = 4
and ... switching the control panel to dual CPU ..
hw.logicalcpu_max: 4
hw.logicalcpu: 2
hw.physicalcpu_max: 4
hw.physicalcpu: 2
hw.ncpu = 4
but, as you say, that would be the implication of ONLN vs CONF ..
however, apparently not - ...
#include unistd.h
#include stdio.h
int main (int ac, char *avv[])
{
printf (n-procs: %d\n, sysconf (_SC_NPROCESSORS_ONLN));
}
$ gcc-4.2 ../tests/nprocs.c -o tt
./tt
n-procs: 4
.. switched to dual cpu ...
$ sysctl hw.logicalcpu
hw.logicalcpu: 2
$ ./tt
n-procs: 4
:-(
so there's a reason to use the systlbyname (and use hw.logicalcpu or
similar, maybe).
[unless that's just a buggy sysconf]
Iain
Re: implementation of std::thread::hardware_concurrency()
On 7 November 2011 14:40, Iain Sandoe wrote:
On 7 Nov 2011, at 14:23, Iain Sandoe wrote:
On 7 Nov 2011, at 14:16, Jonathan Wakely wrote:
On 7 November 2011 14:10, Iain Sandoe wrote:
On 7 Nov 2011, at 13:45, Jonathan Wakely wrote:
This provides a working thread::hardware_concurrency on platforms that
support pthread_num_processors_np or the hw.ncpu sysctl, but by
testing for the features in configure rather than hardcoding OS macro
tests in thread.cc
if the system supports run-time User-controllable core-count then this
will
not account for that.
Yep. Do you know how to detect the right value in that case? If not
the alternative is to revert to the previous behaviour of returning
zero.
(My understanding was that at least some of the options would work for
that case, NPROCESSORS_ONLN is distinct from _SC_NPROCESSORS_CONF, for
example)
Hm. I don't know about the general case - on Darwin it's certainly
possible to get at the information at runtime;
hw.logicalcpu_max: 4
hw.logicalcpu: 4
hw.physicalcpu_max: 4
hw.physicalcpu: 4
hw.ncpu = 4
and ... switching the control panel to dual CPU ..
hw.logicalcpu_max: 4
hw.logicalcpu: 2
hw.physicalcpu_max: 4
hw.physicalcpu: 2
hw.ncpu = 4
but, as you say, that would be the implication of ONLN vs CONF ..
however, apparently not - ...
#include unistd.h
#include stdio.h
int main (int ac, char *avv[])
{
printf (n-procs: %d\n, sysconf (_SC_NPROCESSORS_ONLN));
}
$ gcc-4.2 ../tests/nprocs.c -o tt
./tt
n-procs: 4
.. switched to dual cpu ...
$ sysctl hw.logicalcpu
hw.logicalcpu: 2
$ ./tt
n-procs: 4
:-(
so there's a reason to use the systlbyname (and use hw.logicalcpu or
similar, maybe).
[unless that's just a buggy sysconf]
Well if that's how they want to play it then I'm not even going to
think about changing that code without being able to test it on a real
system!
What does switch to dual cpu actually mean? disable hyperthreading?
disable one core on each die to save power? disable one die to save
power? lie about number of cores so buggy software doesn't get
confused?
I think someone with access to a darwin box and motivation to improve
it will have to make any improvements. I would suggest using
sysctlnametomib and caching the result, then using sysctl, to avoid
the overhead of systlbyname parsing the name on every call. At some
point in the near future (no pun intended) I want to enhance
std::async so it checks the system load and maybe the
hardware_concurrency when deciding whether to run an asynchronous task
in a new thread or not, so I want thread:hardware_concurrency() to be
as fast as possible.
Re: implementation of std::thread::hardware_concurrency()
On 7 Nov 2011, at 14:52, Jonathan Wakely wrote: On 7 November 2011 14:40, Iain Sandoe wrote: so there's a reason to use the systlbyname (and use hw.logicalcpu or similar, maybe). [unless that's just a buggy sysconf] Well if that's how they want to play it then I'm not even going to think about changing that code without being able to test it on a real system! fair ;-) What does switch to dual cpu actually mean? disable hyperthreading? disable one core on each die to save power? disable one die to save power? lie about number of cores so buggy software doesn't get confused? it's done via a control panel which is intended to be a developer's tool to allow testing their code on machines with different capabilities from their development box. I don't think that the average Joe User would need/want to do this I think someone with access to a darwin box and motivation to improve it will have to make any improvements. I would suggest using sysctlnametomib and caching the result, then using sysctl, to avoid the overhead of systlbyname parsing the name on every call. yeah ... if only one could ulimit -hoursinday unlimited ... At some point in the near future (no pun intended) I want to enhance std::async so it checks the system load and maybe the hardware_concurrency when deciding whether to run an asynchronous task in a new thread or not, so I want thread:hardware_concurrency() to be as fast as possible. For the 99.99% case, I suspect that assuming that the number of cpus online == number in the box is safe on Darwin (for normal end users). An interested dev. can do what you suggest .. Iain
Re: implementation of std::thread::hardware_concurrency()
Rechecked.
diff --git a/libstdc++-v3/src/thread.cc b/libstdc++-v3/src/thread.cc
index 09e7fc5..6feda4d 100644
--- a/libstdc++-v3/src/thread.cc
+++ b/libstdc++-v3/src/thread.cc
@@ -112,10 +112,20 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
unsigned int
thread::hardware_concurrency() noexcept
{
-int __n = _GLIBCXX_NPROCS;
-if (__n 0)
- __n = 0;
-return __n;
+int count=0;
+#if defined(PTW32_VERSION) || \
+ (defined(__MINGW64_VERSION_MAJOR) defined(_POSIX_THREADS)) || \
+ defined(__hpux)
+count=pthread_num_processors_np();
+#elif defined(__APPLE__) || defined(__FreeBSD__)
+size_t size=sizeof(count);
+sysctlbyname(hw.ncpu, count, size, NULL, 0);
+#elif defined(_SC_NPROCESSORS_ONLN)
+count=sysconf(_SC_NPROCESSORS_ONLN);
+#elif defined(_GLIBCXX_USE_GET_NPROCS)
+count=_GLIBCXX_NPROCS;
+#endif
+return (count0)?count:0;
}
_GLIBCXX_END_NAMESPACE_VERSION
2011/11/1 Paolo Carlini pcarl...@gmail.com:
Hi,
This is patch is implement the std::thread::hardware_concurrency().
Tested on pthreads-win32/winpthreads on windows OS, and on Linux/FreeBSD.
Please send library patches to the library mailing list too. Also, always
parch mainline first: actually in the latter the function is alread
implemented, maybe something is missing for win32, please check, rediff, and
resend.
Thanks
Paolo
Re: implementation of std::thread::hardware_concurrency()
On 11/01/2011 12:33 PM, niXman wrote: Rechecked. Stylistically, you are missing a lot of spaces around the operators, eg: return (count 0) ? count : 0; also, patches are always submitted with a ChangeLog entry. Do you have already a Copyright assignment in place? I'm asking in general, for your future submissions, this specific patch probably would be small enough to not require it. Paolo.
Re: implementation of std::thread::hardware_concurrency()
On Tue, 1 Nov 2011, niXman wrote:
diff --git a/libstdc++-v3/src/thread.cc b/libstdc++-v3/src/thread.cc
index 09e7fc5..6feda4d 100644
--- a/libstdc++-v3/src/thread.cc
+++ b/libstdc++-v3/src/thread.cc
@@ -112,10 +112,20 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
unsigned int
thread::hardware_concurrency() noexcept
{
-int __n = _GLIBCXX_NPROCS;
-if (__n 0)
- __n = 0;
-return __n;
+int count=0;
+#if defined(PTW32_VERSION) || \
+ (defined(__MINGW64_VERSION_MAJOR) defined(_POSIX_THREADS)) || \
+ defined(__hpux)
+count=pthread_num_processors_np();
+#elif defined(__APPLE__) || defined(__FreeBSD__)
+size_t size=sizeof(count);
+sysctlbyname(hw.ncpu, count, size, NULL, 0);
+#elif defined(_SC_NPROCESSORS_ONLN)
+count=sysconf(_SC_NPROCESSORS_ONLN);
+#elif defined(_GLIBCXX_USE_GET_NPROCS)
+count=_GLIBCXX_NPROCS;
+#endif
+return (count0)?count:0;
Er, the macro _GLIBCXX_NPROCS already handles the case
sysconf(_SC_NPROCESSORS_ONLN). It looks like you actually want to remove
the macro _GLIBCXX_NPROCS completely.
--
Marc Glisse
Re: implementation of std::thread::hardware_concurrency()
On 1 November 2011 11:54, Marc Glisse wrote:
On Tue, 1 Nov 2011, niXman wrote:
diff --git a/libstdc++-v3/src/thread.cc b/libstdc++-v3/src/thread.cc
index 09e7fc5..6feda4d 100644
--- a/libstdc++-v3/src/thread.cc
+++ b/libstdc++-v3/src/thread.cc
@@ -112,10 +112,20 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
unsigned int
thread::hardware_concurrency() noexcept
{
- int __n = _GLIBCXX_NPROCS;
- if (__n 0)
- __n = 0;
- return __n;
+ int count=0;
+#if defined(PTW32_VERSION) || \
+ (defined(__MINGW64_VERSION_MAJOR) defined(_POSIX_THREADS)) || \
+ defined(__hpux)
+ count=pthread_num_processors_np();
+#elif defined(__APPLE__) || defined(__FreeBSD__)
+ size_t size=sizeof(count);
+ sysctlbyname(hw.ncpu, count, size, NULL, 0);
+#elif defined(_SC_NPROCESSORS_ONLN)
+ count=sysconf(_SC_NPROCESSORS_ONLN);
+#elif defined(_GLIBCXX_USE_GET_NPROCS)
+ count=_GLIBCXX_NPROCS;
+#endif
+ return (count0)?count:0;
Er, the macro _GLIBCXX_NPROCS already handles the case
sysconf(_SC_NPROCESSORS_ONLN). It looks like you actually want to remove the
macro _GLIBCXX_NPROCS completely.
Right, I already handled the case of using sysconf. I'm going to veto
this patch in its current form - please check how it works now before
changing this code.
_GLIBCXX_NPROCS should be made to call pthread_num_processors_np() for
mingw or HPUX.
Re: implementation of std::thread::hardware_concurrency()
With what exactly do you don't accept this patch?
2011/11/1 Jonathan Wakely jwakely@gmail.com:
On 1 November 2011 11:54, Marc Glisse wrote:
On Tue, 1 Nov 2011, niXman wrote:
diff --git a/libstdc++-v3/src/thread.cc b/libstdc++-v3/src/thread.cc
index 09e7fc5..6feda4d 100644
--- a/libstdc++-v3/src/thread.cc
+++ b/libstdc++-v3/src/thread.cc
@@ -112,10 +112,20 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
unsigned int
thread::hardware_concurrency() noexcept
{
- int __n = _GLIBCXX_NPROCS;
- if (__n 0)
- __n = 0;
- return __n;
+ int count=0;
+#if defined(PTW32_VERSION) || \
+ (defined(__MINGW64_VERSION_MAJOR) defined(_POSIX_THREADS)) || \
+ defined(__hpux)
+ count=pthread_num_processors_np();
+#elif defined(__APPLE__) || defined(__FreeBSD__)
+ size_t size=sizeof(count);
+ sysctlbyname(hw.ncpu, count, size, NULL, 0);
+#elif defined(_SC_NPROCESSORS_ONLN)
+ count=sysconf(_SC_NPROCESSORS_ONLN);
+#elif defined(_GLIBCXX_USE_GET_NPROCS)
+ count=_GLIBCXX_NPROCS;
+#endif
+ return (count0)?count:0;
Er, the macro _GLIBCXX_NPROCS already handles the case
sysconf(_SC_NPROCESSORS_ONLN). It looks like you actually want to remove the
macro _GLIBCXX_NPROCS completely.
Right, I already handled the case of using sysconf. I'm going to veto
this patch in its current form - please check how it works now before
changing this code.
_GLIBCXX_NPROCS should be made to call pthread_num_processors_np() for
mingw or HPUX.
Re: implementation of std::thread::hardware_concurrency()
I've put gcc-patches@ back in the CC list and removed gcc@ On 1 November 2011 15:35, niXman wrote: Er, the macro _GLIBCXX_NPROCS already handles the case sysconf(_SC_NPROCESSORS_ONLN). It looks like you actually want to remove the macro _GLIBCXX_NPROCS completely. Fixed. No, this still isn't acceptable. I do not want to see preprocessor tests like +#elif defined(__APPLE__) || defined(__FreeBSD__) in the body of get_thread::hardware_concurrency(), the configure script should determine what is available on the platform and set an appropriate macro. Look at the definition of _GLIBCXX_NPROCS and adjust that to do #define _GLIBCXX_NPROCS pthread_num_processors_np() for the relevant platforms. For the platforms using sysctlbyname there could be an inline function that calls it, and _GLIBCXX_NPROCS could be defined to call that, so that thread::hardware_concurrency() can still be defined as it is today. Please read the code you're changing and understand how it works today before making changes.
Re: implementation of std::thread::hardware_concurrency()
What header is required for pthread_num_processors_np? pthread.h Also, you should include sys/sysctl.h before calling sysctlbyname. On the right - yes. sysctlbyname() implicitly included in some header files.
Re: implementation of std::thread::hardware_concurrency()
Ok. I correct it. 2011/11/1 Jonathan Wakely jwakely@gmail.com: I've put gcc-patches@ back in the CC list and removed gcc@ On 1 November 2011 15:35, niXman wrote: Er, the macro _GLIBCXX_NPROCS already handles the case sysconf(_SC_NPROCESSORS_ONLN). It looks like you actually want to remove the macro _GLIBCXX_NPROCS completely. Fixed. No, this still isn't acceptable. I do not want to see preprocessor tests like +#elif defined(__APPLE__) || defined(__FreeBSD__) in the body of get_thread::hardware_concurrency(), the configure script should determine what is available on the platform and set an appropriate macro. Look at the definition of _GLIBCXX_NPROCS and adjust that to do #define _GLIBCXX_NPROCS pthread_num_processors_np() for the relevant platforms. For the platforms using sysctlbyname there could be an inline function that calls it, and _GLIBCXX_NPROCS could be defined to call that, so that thread::hardware_concurrency() can still be defined as it is today. Please read the code you're changing and understand how it works today before making changes.
Re: implementation of std::thread::hardware_concurrency()
On 1 November 2011 15:57, niXman wrote: What header is required for pthread_num_processors_np? pthread.h OK. This assumes that Pthreads is the only abstraction available on __hpux (i.e. that if _GLIBCXX_HAS_GTHREADS is true then we have already included pthread.h): +#if defined(PTW32_VERSION) || \ + (defined(__MINGW64_VERSION_MAJOR) defined(_POSIX_THREADS)) || \ + defined(__hpux) Is that assumption safe? Also, you should include sys/sysctl.h before calling sysctlbyname. On the right - yes. sysctlbyname() implicitly included in some header files. The manual page says it requires sys/sysctl.h so please do that, otherwise a future version of darwin or freebsd might stop implicitly including it and break the code.
Re: implementation of std::thread::hardware_concurrency()
On 1 November 2011 16:01, Jonathan Wakely wrote: On 1 November 2011 15:57, niXman wrote: What header is required for pthread_num_processors_np? pthread.h OK. This assumes that Pthreads is the only abstraction available on __hpux (i.e. that if _GLIBCXX_HAS_GTHREADS is true then we have already included pthread.h): +#if defined(PTW32_VERSION) || \ + (defined(__MINGW64_VERSION_MAJOR) defined(_POSIX_THREADS)) || \ + defined(__hpux) Is that assumption safe? OK, gthr-dec.h includes pthread.h so I think it is safe. Do all supported versions of Pthreads-win32, mingw64 and HPUX define pthread_num_processors_np() in pthread.h? They might not, which is why there should be a configure test checking for the availability of that function, which sets a macro such as _GLIBCXX_USE_PTHREAD_NUM_PROCESSORS_NP, which is then checked in src/thread.cc
Re: implementation of std::thread::hardware_concurrency()
On Nov 1, 2011, at 8:55 AM, Jonathan Wakely wrote: Is there a reason you used hw.ncpu not the constant HW_NCPU ? I suspect on some systems, this would be a runtime value so, no fixed constant could ever work.
Re: implementation of std::thread::hardware_concurrency()
On 1 November 2011 17:06, Mike Stump wrote:
On Nov 1, 2011, at 8:55 AM, Jonathan Wakely wrote:
Is there a reason you used hw.ncpu not the constant HW_NCPU ?
I suspect on some systems, this would be a runtime value so, no fixed
constant could ever work.
It's a constant for identifying the sysctl, not a constant for the
number of processors e.g. (untested)
int mib[] = { CTL_HW, HW_NCPU };
if (!sysctl(mib, 2, count, size, NULL, 0))
The Mac OS X man page says the sysctl() function runs in about a
third the time as the same request made via the sysctlbyname()
function.
My preferred solution (which would be consistent with the existing
code, and additionally support NetBSD, OpenBSD and Irix) would be to
add autoconf tests for the required functionality, then:
#if defined(_GLIBCXX_USE_GET_NPROCS)
# include sys/sysinfo.h
# define _GLIBCXX_NPROCS get_nprocs()
#elif defined(_GLIBCXX_USE_SC_NPROCESSORS_ONLN)
# include unistd.h
# define _GLIBCXX_NPROCS sysconf(_SC_NPROCESSORS_ONLN)
#elif defined(_GLIBCXX_USE_SC_NPROC_ONLN)
# include unistd.h
# define _GLIBCXX_NPROCS sysconf(_SC_NPROC_ONLN)
#elif defined(_GLIBCXX_USE_PTHREADS_NUM_PROCESSORS_NP)
# define _GLIBCXX_NPROCS pthread_num_processors_np()
#elif defined(_GLIBCXX_USE_SYSCTLBYNAME_HW_NCPU)
# include sys/sysctl.h
static inline int get_nprocs()
{
int count;
size_t size = sizeof(count);
int mib[] = { CTL_HW, HW_NCPU };
if (!sysctl(mib, 2, count, size, NULL, 0))
return count;
return 0;
}
# define _GLIBCXX_NPROCS get_nprocs()
#else
# define _GLIBCXX_NPROCS 0
#endif
...
unsigned int
thread::hardware_concurrency() noexcept
{
int __n = _GLIBCXX_NPROCS;
if (__n 0)
__n = 0;
return __n;
}
Re: implementation of std::thread::hardware_concurrency()
On Nov 1, 2011, at 10:13 AM, Jonathan Wakely wrote: I suspect on some systems, this would be a runtime value so, no fixed constant could ever work. It's a constant for identifying the sysctl, not a constant for the number of processors e.g. (untested) Ah, never mind, ignore me.
Re: implementation of std::thread::hardware_concurrency()
Hi, This is patch is implement the std::thread::hardware_concurrency(). Tested on pthreads-win32/winpthreads on windows OS, and on Linux/FreeBSD. Please send library patches to the library mailing list too. Also, always parch mainline first: actually in the latter the function is alread implemented, maybe something is missing for win32, please check, rediff, and resend. Thanks Paolo
Re: implementation of std::thread::hardware_concurrency()
On 10/31/2011 02:10 PM, niXman wrote: +#elif definen(_GLIBCXX_USE_GET_NPROCS) Typo. r~
Re: implementation of std::thread::hardware_concurrency()
On Oct 31, 2011, at 2:10 PM, niXman wrote: This is patch is implement the std::thread::hardware_concurrency(). [ general comment ] Ick, this isn't what I'd call clean. Maybe a porting header inclusion that defines a static inline pthread_num_processors_np when on those system that don't have it. With that then this routine could just use pthread_num_processors_np instead after including that porting header. Having dozens of files with cascades of #if went out of fashion back in the 1990s.
