--- Comment #9 from tstarling at wikimedia dot org 2010-09-08 02:36 ---
Created an attachment (id=21732)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21732&action=view)
10 lines, 500 bytes per line
Test file attached as requested, compressed with gzip. Test code follows.
get
--- Comment #8 from tstarling at wikimedia dot org 2010-09-08 01:34 ---
(In reply to comment #5)
> For sure we cannot add virtual functions to basic_streambuf without breaking
> the ABI.
I'm mostly looking for a long-term fix, to improve the speed of libstdc++
applications generally, e
--- Comment #7 from redi at gcc dot gnu dot org 2010-09-07 19:50 ---
(In reply to comment #0)
> Calling ios::sync_with_stdio(false) before the loop start reduces the time per
> line to around 0.3us, on par with fgets(). This suggests that the problem is
> with the stdio synchronisation c
--- Comment #6 from paolo dot carlini at oracle dot com 2010-09-07 17:55
---
By the way, I don't know anything about your testcase (it would be a good idea
attaching something here, just in case), but on my machines, i7 mostly, I don't
see anything similar to your performance gap, I see
--- Comment #5 from paolo dot carlini at oracle dot com 2010-09-07 17:49
---
For sure we cannot add virtual functions to basic_streambuf without breaking
the ABI. Also, getline certainly isn't just fgets, takes a delim char, uses
traits, etc. Sure, anyway, in principle you can often spe
--- Comment #4 from tstarling at wikimedia dot org 2010-09-07 17:18 ---
Benchmarking on Solaris indicates that cin.getline() takes only 1us per
iteration there, but I don't think the source code is available, so it's hard
to provide details.
However, I think that a huge speedup could b
--- Comment #3 from paolo dot carlini at oracle dot com 2010-09-07 11:15
---
There is nothing we can do to speed up further the v3 side of the synced code,
thus, unless you have evidence that other implementations perform much better
than v3, and provide details, this is closed.
--
--- Comment #2 from tstarling at wikimedia dot org 2010-09-07 10:46 ---
(In reply to comment #1)
> If the problem is in the stdio sync code, then file a glibc PR.
>
I mean the "stdio sync code" as in the code in libstdc++ which synchronises
with glibc, not actual code within glibc. If
--- Comment #1 from paolo dot carlini at oracle dot com 2010-09-07 09:42
---
If the problem is in the stdio sync code, then file a glibc PR.
--
paolo dot carlini at oracle dot com changed:
What|Removed |Added
--
