* [Bug libstdc++/59177] steady_clock::now() and system_clock::now do not use the vdso (and are therefore very slow)
2013-11-18 18:23 [Bug libstdc++/59177] New: steady_clock::now() and system_clock::now do not use the vdso (and are therefore very slow) luto at mit dot edu
@ 2013-11-18 18:38 ` paolo.carlini at oracle dot com
2013-11-18 18:46 ` jakub at gcc dot gnu.org
` (10 subsequent siblings)
11 siblings, 0 replies; 13+ messages in thread
From: paolo.carlini at oracle dot com @ 2013-11-18 18:38 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59177
Paolo Carlini <paolo.carlini at oracle dot com> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |jakub at gcc dot gnu.org
--- Comment #1 from Paolo Carlini <paolo.carlini at oracle dot com> ---
CC-ing Jakub, then.
^ permalink raw reply [flat|nested] 13+ messages in thread
* [Bug libstdc++/59177] steady_clock::now() and system_clock::now do not use the vdso (and are therefore very slow)
2013-11-18 18:23 [Bug libstdc++/59177] New: steady_clock::now() and system_clock::now do not use the vdso (and are therefore very slow) luto at mit dot edu
2013-11-18 18:38 ` [Bug libstdc++/59177] " paolo.carlini at oracle dot com
@ 2013-11-18 18:46 ` jakub at gcc dot gnu.org
2013-11-18 19:15 ` luto at mit dot edu
` (9 subsequent siblings)
11 siblings, 0 replies; 13+ messages in thread
From: jakub at gcc dot gnu.org @ 2013-11-18 18:46 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59177
--- Comment #2 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Just install glibc 2.17 or later if you care about the speed, otherwise it is
fixing much more important problem that the clocks had ABI incompatible
settings depending on common libstdc++ configure options. If you do have glibc
2.17 or later, clock_gettime(CLOCK_MONOTONIC, &tp); should be used (if not,
that would be a bug somewhere), but earlier glibcs have clock_gettime defined
only in librt, which is undesirable to require.
^ permalink raw reply [flat|nested] 13+ messages in thread
* [Bug libstdc++/59177] steady_clock::now() and system_clock::now do not use the vdso (and are therefore very slow)
2013-11-18 18:23 [Bug libstdc++/59177] New: steady_clock::now() and system_clock::now do not use the vdso (and are therefore very slow) luto at mit dot edu
2013-11-18 18:38 ` [Bug libstdc++/59177] " paolo.carlini at oracle dot com
2013-11-18 18:46 ` jakub at gcc dot gnu.org
@ 2013-11-18 19:15 ` luto at mit dot edu
2013-11-18 19:25 ` jakub at gcc dot gnu.org
` (8 subsequent siblings)
11 siblings, 0 replies; 13+ messages in thread
From: luto at mit dot edu @ 2013-11-18 19:15 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59177
--- Comment #3 from Andy Lutomirski <luto at mit dot edu> ---
I can't get gcc trunk to build right now, but I just distcleaned and rebuilt
the 4.8 branch truck on Fedora 19, which has glibc-2.17-19.fc19.x86_64. It
defines _GLIBCXX_USE_CLOCK_GETTIME_SYSCALL. This happens because:
configure:19349: checking for clock_gettime, nanosleep and sched_yield
configure:19378: result: no
I think that the underlying problem is that --enable-libstdcxx-time defaults to
"no". Shouldn't it default to "yes" (and hence run the fancy configure
checks)? Configuring with ./configure --enable-libstdcxx-time does the right
thing.
^ permalink raw reply [flat|nested] 13+ messages in thread
* [Bug libstdc++/59177] steady_clock::now() and system_clock::now do not use the vdso (and are therefore very slow)
2013-11-18 18:23 [Bug libstdc++/59177] New: steady_clock::now() and system_clock::now do not use the vdso (and are therefore very slow) luto at mit dot edu
` (2 preceding siblings ...)
2013-11-18 19:15 ` luto at mit dot edu
@ 2013-11-18 19:25 ` jakub at gcc dot gnu.org
2013-11-18 19:46 ` luto at mit dot edu
` (7 subsequent siblings)
11 siblings, 0 replies; 13+ messages in thread
From: jakub at gcc dot gnu.org @ 2013-11-18 19:25 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59177
--- Comment #4 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
The default for --enable-libstdcxx-time is =auto, which should be the right
thing:
gnu* | linux* | kfreebsd*-gnu | knetbsd*-gnu)
AC_MSG_CHECKING([for at least GNU libc 2.17])
AC_TRY_COMPILE(
[#include <features.h>],
[
#if ! __GLIBC_PREREQ(2, 17)
#error
#endif
],
[glibcxx_glibc217=yes], [glibcxx_glibc217=no])
AC_MSG_RESULT($glibcxx_glibc217)
if test x"$glibcxx_glibc217" = x"yes"; then
ac_has_clock_monotonic=yes
ac_has_clock_realtime=yes
fi
ac_has_nanosleep=yes
ac_has_sched_yield=yes
My trunk build on Fedora 19 today has:
/* Defined if clock_gettime syscall has monotonic and realtime clock support.
*/
/* #undef _GLIBCXX_USE_CLOCK_GETTIME_SYSCALL */
/* Defined if clock_gettime has monotonic clock support. */
#define _GLIBCXX_USE_CLOCK_MONOTONIC 1
/* Defined if clock_gettime has realtime clock support. */
#define _GLIBCXX_USE_CLOCK_REALTIME 1
and there are two clock_gettime calls in libstdc++.so.6 as they should be.
^ permalink raw reply [flat|nested] 13+ messages in thread
* [Bug libstdc++/59177] steady_clock::now() and system_clock::now do not use the vdso (and are therefore very slow)
2013-11-18 18:23 [Bug libstdc++/59177] New: steady_clock::now() and system_clock::now do not use the vdso (and are therefore very slow) luto at mit dot edu
` (3 preceding siblings ...)
2013-11-18 19:25 ` jakub at gcc dot gnu.org
@ 2013-11-18 19:46 ` luto at mit dot edu
2013-11-18 19:50 ` jakub at gcc dot gnu.org
` (6 subsequent siblings)
11 siblings, 0 replies; 13+ messages in thread
From: luto at mit dot edu @ 2013-11-18 19:46 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59177
Andy Lutomirski <luto at mit dot edu> changed:
What |Removed |Added
----------------------------------------------------------------------------
Version|4.9.0 |4.8.3
--- Comment #5 from Andy Lutomirski <luto at mit dot edu> ---
Aha. I think the issue is only in 4.8. libstdc++-v3/configure.ac says:
# For clock_gettime, nanosleep and sched_yield support.
# NB: The default is [no], because otherwise it requires linking.
GLIBCXX_ENABLE_LIBSTDCXX_TIME([no])
Aside from the typo in the comment (the end of the sentence seems to have
disappeared), I'm still confused. Even in the 4.8 branch,
enable_libstdcxx_time=yes doesn't appear to link in librt; only
enable_libstdcxx_time=rt seems to have that effect.
(Please accept my apologies if I'm just completely confused about how autoconf
works here.)
^ permalink raw reply [flat|nested] 13+ messages in thread
* [Bug libstdc++/59177] steady_clock::now() and system_clock::now do not use the vdso (and are therefore very slow)
2013-11-18 18:23 [Bug libstdc++/59177] New: steady_clock::now() and system_clock::now do not use the vdso (and are therefore very slow) luto at mit dot edu
` (4 preceding siblings ...)
2013-11-18 19:46 ` luto at mit dot edu
@ 2013-11-18 19:50 ` jakub at gcc dot gnu.org
2013-11-18 19:53 ` luto at mit dot edu
` (5 subsequent siblings)
11 siblings, 0 replies; 13+ messages in thread
From: jakub at gcc dot gnu.org @ 2013-11-18 19:50 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59177
--- Comment #6 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Sure, for GCC 4.8.1 we've only changed minimum things that were required for
correct operation and ABI compatibility, it didn't receive the extra changes
for =auto.
^ permalink raw reply [flat|nested] 13+ messages in thread
* [Bug libstdc++/59177] steady_clock::now() and system_clock::now do not use the vdso (and are therefore very slow)
2013-11-18 18:23 [Bug libstdc++/59177] New: steady_clock::now() and system_clock::now do not use the vdso (and are therefore very slow) luto at mit dot edu
` (5 preceding siblings ...)
2013-11-18 19:50 ` jakub at gcc dot gnu.org
@ 2013-11-18 19:53 ` luto at mit dot edu
2013-11-18 19:58 ` jakub at gcc dot gnu.org
` (4 subsequent siblings)
11 siblings, 0 replies; 13+ messages in thread
From: luto at mit dot edu @ 2013-11-18 19:53 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59177
--- Comment #7 from Andy Lutomirski <luto at mit dot edu> ---
I guess what I'm saying is: what's wrong with "yes" in 4.8? From looking at
the code, it still seems like it does the right thing (i.e. not using
clock_gettime if it's not in [posix4]).
^ permalink raw reply [flat|nested] 13+ messages in thread
* [Bug libstdc++/59177] steady_clock::now() and system_clock::now do not use the vdso (and are therefore very slow)
2013-11-18 18:23 [Bug libstdc++/59177] New: steady_clock::now() and system_clock::now do not use the vdso (and are therefore very slow) luto at mit dot edu
` (6 preceding siblings ...)
2013-11-18 19:53 ` luto at mit dot edu
@ 2013-11-18 19:58 ` jakub at gcc dot gnu.org
2013-11-18 20:03 ` luto at mit dot edu
` (3 subsequent siblings)
11 siblings, 0 replies; 13+ messages in thread
From: jakub at gcc dot gnu.org @ 2013-11-18 19:58 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59177
--- Comment #8 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
For hosted linux --enable-libstdcxx-time can work just fine, just use it.
But, such a change isn't desirable for the branch, e.g. because the fancy
checks require link tests which aren't usable for some bare metal
configurations, might not be the right thing for Solaris or whatever else, etc.
=auto has been introduced exactly to get some reasonably safe defaults
automatically by default. So, if you want to change anything on the branch,
supposedly it would be partial backport of the =auto stuff, but only limit it
to the most commonly tested targets or something. Still, I'd say it is better
to just tell people who want it to --enable-libstdcxx-time themselves if they
want.
In the past it has been ABI incompatible option, now hopefully is not.
^ permalink raw reply [flat|nested] 13+ messages in thread
* [Bug libstdc++/59177] steady_clock::now() and system_clock::now do not use the vdso (and are therefore very slow)
2013-11-18 18:23 [Bug libstdc++/59177] New: steady_clock::now() and system_clock::now do not use the vdso (and are therefore very slow) luto at mit dot edu
` (7 preceding siblings ...)
2013-11-18 19:58 ` jakub at gcc dot gnu.org
@ 2013-11-18 20:03 ` luto at mit dot edu
2013-11-18 20:17 ` paolo.carlini at oracle dot com
` (2 subsequent siblings)
11 siblings, 0 replies; 13+ messages in thread
From: luto at mit dot edu @ 2013-11-18 20:03 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59177
--- Comment #9 from Andy Lutomirski <luto at mit dot edu> ---
Given that this is C++11-only, it's already fixed on trunk, it's only a
performance issue (as opposed to correctness), and it's more complicated than
just changing the default, I won't argue for a backport.
>From my perspective, feel free to close this.
^ permalink raw reply [flat|nested] 13+ messages in thread
* [Bug libstdc++/59177] steady_clock::now() and system_clock::now do not use the vdso (and are therefore very slow)
2013-11-18 18:23 [Bug libstdc++/59177] New: steady_clock::now() and system_clock::now do not use the vdso (and are therefore very slow) luto at mit dot edu
` (8 preceding siblings ...)
2013-11-18 20:03 ` luto at mit dot edu
@ 2013-11-18 20:17 ` paolo.carlini at oracle dot com
2013-11-19 0:15 ` redi at gcc dot gnu.org
2013-11-19 0:45 ` luto at mit dot edu
11 siblings, 0 replies; 13+ messages in thread
From: paolo.carlini at oracle dot com @ 2013-11-18 20:17 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59177
Paolo Carlini <paolo.carlini at oracle dot com> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|UNCONFIRMED |RESOLVED
Resolution|--- |WORKSFORME
--- Comment #10 from Paolo Carlini <paolo.carlini at oracle dot com> ---
Ok, thanks.
^ permalink raw reply [flat|nested] 13+ messages in thread
* [Bug libstdc++/59177] steady_clock::now() and system_clock::now do not use the vdso (and are therefore very slow)
2013-11-18 18:23 [Bug libstdc++/59177] New: steady_clock::now() and system_clock::now do not use the vdso (and are therefore very slow) luto at mit dot edu
` (9 preceding siblings ...)
2013-11-18 20:17 ` paolo.carlini at oracle dot com
@ 2013-11-19 0:15 ` redi at gcc dot gnu.org
2013-11-19 0:45 ` luto at mit dot edu
11 siblings, 0 replies; 13+ messages in thread
From: redi at gcc dot gnu.org @ 2013-11-19 0:15 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59177
--- Comment #11 from Jonathan Wakely <redi at gcc dot gnu.org> ---
(In reply to Andy Lutomirski from comment #5)
> # For clock_gettime, nanosleep and sched_yield support.
> # NB: The default is [no], because otherwise it requires linking.
> GLIBCXX_ENABLE_LIBSTDCXX_TIME([no])
>
> Aside from the typo in the comment (the end of the sentence seems to have
> disappeared),
No, the sentence is complete. Comment 8 explains that we don't want to do tests
that require running the linker for the default configuration, because that's
not possible for bare metal targets.
^ permalink raw reply [flat|nested] 13+ messages in thread
* [Bug libstdc++/59177] steady_clock::now() and system_clock::now do not use the vdso (and are therefore very slow)
2013-11-18 18:23 [Bug libstdc++/59177] New: steady_clock::now() and system_clock::now do not use the vdso (and are therefore very slow) luto at mit dot edu
` (10 preceding siblings ...)
2013-11-19 0:15 ` redi at gcc dot gnu.org
@ 2013-11-19 0:45 ` luto at mit dot edu
11 siblings, 0 replies; 13+ messages in thread
From: luto at mit dot edu @ 2013-11-19 0:45 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59177
--- Comment #12 from Andy Lutomirski <luto at mit dot edu> ---
D'oh! I assumed that "it" was the resulting library (and thus that it would
require linking *against librt*), not that "it" was the configure test.
^ permalink raw reply [flat|nested] 13+ messages in thread