This is the mail archive of the
libstdc++@gcc.gnu.org
mailing list for the libstdc++ project.
Re: Killing two birds with a one-line configuration change
In article <20020411190259.B11527@redhat.com>,
Richard Henderson <rth@redhat.com> writes:
>> If someone on a Linux platform could *please* just try my suggested fix ...
> With your suggested fix, runtime is 13.74 seconds instead of 14.03.
I am prepared to be further humbled by the evidence, but I suspect
that you may have measured a case that is completely unaffected by my
patch. I base this on the speedup you measured and your comment that
you didn't expect my patch to help.
> The lseeks are still present in the strace output.
OK, at least you were the first to bother even testing it and
reporting about it in that environment. Thank you. However, I think
I was assuming something about the way you were testing the PR. The
PR explicitly says "piping in the log file". This is important. When
the test case is run in that manner without the sync_with_stdio(false)
calls and without _GLIBCPP_AVOID_FSEEK defined, there are 2 seek
system calls *per* *character* *read* at the C++ application level on
Linux! I can agree with you that it would be optimal to remove all
useless seek system calls in all configurations but I don't think you
even saw the really horrible hot spot produced by the PR as reported
and the intention of my patch.
Just to humor me, can you trace/time both:
a.out <log # fseek avoidance path of my patch only helps this case
a.out log
(Look at both cases with and without the sync_with_stdio(false) calls
you added; compare like cases with and without my configuration patch.)
Compiled with g++ mainline on my machine (times are similar with and
without the sync_with_stdio(false) calls on this OS):
; time a.out log
67444 Pageviews, 14041 Visits, 91521 Hits.
65r 64.2u 0.1s a.out log
; time a.out <log
67444 Pageviews, 14041 Visits, 91521 Hits.
97r 95.4u 0.1s a.out
Compiled with g++ 2.95.2:
; time a.out log
67444 Pageviews, 14041 Visits, 91521 Hits.
51r 50.4u 0.1s a.out log
; time a.out <log
67444 Pageviews, 14041 Visits, 91521 Hits.
51r 50.4u 0.1s a.out
> I really didn't expect your patch to help, because _GLIBCPP_AVOID_FSEEK
> merely emulates lseek with displacement 1 with getc/ungetc. However,
> my main point is that we shouln't have any lseeks whatsoever!
FYI, during the run of the test case as published, here is the steady
state truss output on my machine:
[...]
read(0x0,0x8056000,0x4000) = 16384 (0x4000)
read(0x0,0x8056000,0x4000) = 16384 (0x4000)
read(0x0,0x8056000,0x4000) = 16384 (0x4000)
read(0x0,0x8056000,0x4000) = 16384 (0x4000)
read(0x0,0x8056000,0x4000) = 16384 (0x4000)
read(0x0,0x8056000,0x4000) = 16384 (0x4000)
read(0x0,0x8056000,0x4000) = 16384 (0x4000)
read(0x0,0x8056000,0x4000) = 16384 (0x4000)
read(0x0,0x8056000,0x4000) = 16384 (0x4000)
break(0x8069000) = 0 (0x0)
[...]
Zero seeks on stdin/cin.
>> [1] libstdc++-v3 adheres to the standard in ways that affect
>> performance that libstdc++-v2, as shipped with gcc 2.95.2, did not.
> What ways are these?
C++ IO calls must be interleaveable on a per-character basis with C IO
calls. When libstdc++-v2 was compiled for systems that did not use
libio for C IO, the standard was not met. AKAIK, libstdc++-v3 would
still have used libio (at least as an option) had libio been ported to
V3 G++ ABI. That was never done.
I think you raise a great issue with the sync_with_stdio(false) case
still seeking. I have both raised it and worked on fixing it before.
I concluded that it will take some rearchitecture to fix right.
> I should add that if not affecting the read cursor is for some
> unexplained reason absolutely required by the standard, then we
> should be using pread instead of lseek+read+lseek.
I could agreed except you must make cursor movement calls to ensure
that C IO calls interleaved will work correctly. pread() is not part
of the standard and there are issues with how it works with
interactive streams but it could be used as an option, if it helped
some systems.
Regards,
Loren