Re: libstdc++/9876: filebuf::sputc more than 10% slower than putc

Re: libstdc++/9876: filebuf::sputc more than 10% slower than putc

[Paolo Carlini]

The following reply was made to PR libstdc++/9876; it has been noted by GNATS.

From: Paolo Carlini <pcarlini@unitus.it>
To: gcc-prs@gcc.gnu.org,  gcc-bugs@gcc.gnu.org,  gcc-gnats@gcc.gnu.org, 
 nobody@gcc.gnu.org
Cc: bkoz <bkoz@redhat.com>
Subject: Re: libstdc++/9876: filebuf::sputc more than 10% slower than putc
Date: Fri, 16 May 2003 19:47:27 +0200

 Just a note for GNATS. We are making progress on this one,
 which, as is, probably could even be closed:
 
    http://gcc.gnu.org/ml/libstdc++/2003-04/msg00245.html
 
 Paolo.
 
 http://gcc.gnu.org/cgi-bin/gnatsweb.pl?cmd=view%20audit-trail&database=gcc&pr=9876
 

Re: libstdc++/9876: filebuf::sputc more than 10% slower than putc

[Benjamin Kosnik]

The following reply was made to PR libstdc++/9876; it has been noted by GNATS.

From: Benjamin Kosnik <bkoz@redhat.com>
To: Paolo Carlini <pcarlini@unitus.it>
Cc: gcc-prs@gcc.gnu.org, gcc-bugs@gcc.gnu.org, gcc-gnats@gcc.gnu.org,
   nobody@gcc.gnu.org
Subject: Re: libstdc++/9876: filebuf::sputc more than 10% slower than putc
Date: Fri, 16 May 2003 12:58:03 -0500

 >Just a note for GNATS. We are making progress on this one,
 >which, as is, probably could even be closed:
 >
 >   http://gcc.gnu.org/ml/libstdc++/2003-04/msg00245.html
 >
 >Paolo.
 
 Yeah, I agree. (I went through this last night, actually as part of
 scoping GNATS for performance issues). The getc_unlocked commentary is
 interesting though. Where to save it? Maybe put this into suspend?
 
 We should probably do a cleanup of GNATS to ease the transition to
 bugzilla. I plan on doing my part this afternoon.
 
 best,
 benjamin

RE: libstdc++/9876: filebuf::sputc more than 10% slower than putc

[Pétur Runólfsson]

The following reply was made to PR libstdc++/9876; it has been noted by GNATS.

From: =?iso-8859-1?Q?P=E9tur_Run=F3lfsson?= <peturr02@ru.is>
To: "Paolo Carlini" <pcarlini@unitus.it>
Cc: <paolo@gcc.gnu.org>,
	<gcc-bugs@gcc.gnu.org>,
	<nobody@gcc.gnu.org>,
	<gcc-gnats@gcc.gnu.org>
Subject: RE: libstdc++/9876: filebuf::sputc more than 10% slower than putc
Date: Sun, 23 Mar 2003 19:38:00 -0000

 > Needless to say, you are right, and Nathan is right, about the need to
 > improve our streambuf::sputc, but we still do _not_ have real numbers
 > to use as a point of reference.
 >=20
 > Are you willing to work on this?
 
 This is stdio vs. unlocked_stdio vs. iostreams:
 
 time ./stdio
 1.11user 0.15system 0:01.27elapsed 99%CPU (0avgtext+0avgdata =
 0maxresident)k
 0inputs+0outputs (22major+8minor)pagefaults 0swaps
 time ./stdio_unlocked
 0.28user 0.15system 0:00.43elapsed 99%CPU (0avgtext+0avgdata =
 0maxresident)k
 0inputs+0outputs (22major+8minor)pagefaults 0swaps
 time ./iostreams
 1.00user 0.19system 0:01.20elapsed 99%CPU (0avgtext+0avgdata =
 0maxresident)k
 0inputs+0outputs (61major+15minor)pagefaults 0swaps
 
 This is on a Intel Pentium III 500 MHz with 384 MB ram, Red Hat Linux =
 8.0
 with kernel 2.5.44.
 
 This is the code:
 
 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
 =3D speed.hh =
 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
 =3D=3D=3D
 
 #ifndef SPEED_HH_INCLUDED
 #define SPEED_HH_INCLUDED
 
 const int iterations =3D 10000000;
 
 #endif
 
 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
 =3D stdio.cc =
 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
 =3D=3D=3D
 
 #include <cstdio>
 #include "speed.hh"
 
 int main()
 {
 	using namespace std;
 
 	FILE* file =3D fopen("tmp", "w+");
 	for (int i =3D 0; i < iterations; ++i)
 	{
 		putc(i % 100, file);
 	}
 	fclose(file);
 	return 0;
 }
 
 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
 =3D stdio_unlocked.cc =
 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
 =3D=3D=3D
 
 #include <cstdio>
 #include "speed.hh"
 
 int main()
 {
 	using namespace std;
 
 	FILE* file =3D fopen("tmp", "w+");
 	for (int i =3D 0; i < iterations; ++i)
 	{
 		putc_unlocked(i % 100, file);
 	}
 	fclose(file);
 	return 0;
 }
 
 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
 =3D iostreams.cc =
 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
 =3D=3D=3D
 
 #include <fstream>
 #include "speed.hh"
 
 int main()
 {
 	using namespace std;
 
 	filebuf buf;
 	buf.open("tmp", ios::out | ios::in | ios::trunc);
 	for (int i =3D 0; i < iterations; ++i)
 	{
 		buf.sputc(i % 100);
 	}
 	buf.close();
 	return 0;
 }
 
 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
 
 There are also major differences in fwrite vs. filebuf::sputn when
 the buffer is bigger than BUFSIZ (fwrite doesn't copy the buffer when
 it is larger than BUFSIZ), as well as in putwc vs. wfilebuf::sputc
 (I think that codecvt is causing this slowdown).
 
 Petur

RE: libstdc++/9876: filebuf::sputc more than 10% slower than putc

[Pétur Runólfsson]

The following reply was made to PR libstdc++/9876; it has been noted by GNATS.

From: =?iso-8859-1?Q?P=E9tur_Run=F3lfsson?= <peturr02@ru.is>
To: "Paolo Carlini" <pcarlini@unitus.it>
Cc: <paolo@gcc.gnu.org>,
	<gcc-bugs@gcc.gnu.org>,
	<nobody@gcc.gnu.org>,
	<gcc-gnats@gcc.gnu.org>
Subject: RE: libstdc++/9876: filebuf::sputc more than 10% slower than putc
Date: Mon, 3 Mar 2003 11:07:44 -0000

 > Very Interesting issues... Indeed, putc_unlocked is _much_=20
 > faster (3 x ?)
 >=20
 > However...
 >=20
 > The interesting thing is the following: a series of streambuf::sputc,
 > does _not_ call an underlying C-library putc, but instead,=20
 > upon overflow,
 > an underlying _M_file.xsputn, which means an underlying=20
 > _locked_ fwrite,
 > _not_ an underlying fwrite_unlocked!
 >=20
 > So, I would argue that your comparison was not fair before,=20
 > and it's not
 > fair now! ;)
 
 The locking inside fwrite seems to be totally wasted, since
 filebuf isn't threadsafe at all (for that, [io]stream::sentry
 would need to handle the locking), and also _M_really_overflow
 calls fwrite twice (once with BUFSIZ characters, and then with
 1 character).
 
 > Needless to say, you are right, and Nathan is right, about the need to
 > improve our streambuf::sputc, but we still do _not_ have real numbers
 > to use as a point of reference.
 >=20
 > Are you willing to work on this?
 
 Yup.
 
 Petur

Re: libstdc++/9876: filebuf::sputc more than 10% slower than putc

[Paolo Carlini]

The following reply was made to PR libstdc++/9876; it has been noted by GNATS.

From: Paolo Carlini <pcarlini@unitus.it>
To: =?ISO-8859-1?Q?P=E9tur_Run=F3lfsson?= <peturr02@ru.is>
Cc: paolo@gcc.gnu.org,  gcc-bugs@gcc.gnu.org,  nobody@gcc.gnu.org, 
 gcc-gnats@gcc.gnu.org
Subject: Re: libstdc++/9876: filebuf::sputc more than 10% slower than putc
Date: Fri, 28 Feb 2003 17:43:25 +0100

 P=E9tur Run=F3lfsson wrote:
 
 >>    Yes, filebuf::sputc shall be improved: patches welcome,
 >>    or, otherwise, stay tuned!
 >>   =20
 >>    However, the funny thing of your PR is that, as a matter of
 >>    fact, I *cannot* reproduce the trend neither with mainline
 >>    (which produces better code, indeed) nor with 3.2.2!
 >>
 >
 >Whoops, s/putc/putc_unlocked/ :-P
 >
 >putc calls flockfile/funlockfile for each character,
 >streambuf::sputc does not do so and should be compared against
 >putc_unlocked.
 >
 
 Hi Petur.
 
 Very Interesting issues... Indeed, putc_unlocked is _much_ faster (3 x ?)
 
 However...
 
 The interesting thing is the following: a series of streambuf::sputc,
 does _not_ call an underlying C-library putc, but instead, upon overflow,
 an underlying _M_file.xsputn, which means an underlying _locked_ fwrite,
 _not_ an underlying fwrite_unlocked!
 
 So, I would argue that your comparison was not fair before, and it's not
 fair now! ;)
 
 Needless to say, you are right, and Nathan is right, about the need to
 improve our streambuf::sputc, but we still do _not_ have real numbers
 to use as a point of reference.
 
 Are you willing to work on this?
 
 Paolo.
 
 http://gcc.gnu.org/cgi-bin/gnatsweb.pl?cmd=3Dview%20audit-trail&database=3D=
 gcc&pr=3D9876
 
 
 
 
 
 
 
 

RE: libstdc++/9876: filebuf::sputc more than 10% slower than putc

[Pétur Runólfsson]

The following reply was made to PR libstdc++/9876; it has been noted by GNATS.

From: =?iso-8859-1?Q?P=E9tur_Run=F3lfsson?= <peturr02@ru.is>
To: <paolo@gcc.gnu.org>,
	<gcc-bugs@gcc.gnu.org>,
	<nobody@gcc.gnu.org>,
	=?iso-8859-1?Q?P=E9tur_Run=F3lfsson?= <peturr02@ru.is>,
	<gcc-gnats@gcc.gnu.org>
Cc:  
Subject: RE: libstdc++/9876: filebuf::sputc more than 10% slower than putc
Date: Fri, 28 Feb 2003 15:57:06 -0000

 >     Yes, filebuf::sputc shall be improved: patches welcome,
 >     or, otherwise, stay tuned!
 >    =20
 >     However, the funny thing of your PR is that, as a matter of
 >     fact, I *cannot* reproduce the trend neither with mainline
 >     (which produces better code, indeed) nor with 3.2.2!
 
 Whoops, s/putc/putc_unlocked/ :-P
 
 putc calls flockfile/funlockfile for each character,
 streambuf::sputc does not do so and should be compared against
 putc_unlocked.
 
 Petur

Re: libstdc++/9876: filebuf::sputc more than 10% slower than putc

[paolo]

Synopsis: filebuf::sputc more than 10% slower than putc

State-Changed-From-To: open->analyzed
State-Changed-By: paolo
State-Changed-When: Thu Feb 27 20:22:05 2003
State-Changed-Why:
    Yes, filebuf::sputc shall be improved: patches welcome,
    or, otherwise, stay tuned!
    
    However, the funny thing of your PR is that, as a matter of
    fact, I *cannot* reproduce the trend neither with mainline
    (which produces better code, indeed) nor with 3.2.2!
    
    On my P4-2400 (512 MB, linux2.4.20, glibc2.3.1, etc.),
    these are the timings (gcc-3.2.2, -O2):
    iostreams:
     3.500u 0.330s 0:03.92 97.7%     0+0k 0+0io 197pf+0w
    stdio:
     3.570u 0.430s 0:04.03 99.2%     0+0k 0+0io 194pf+0w
    
    Ideas?
    
    Paolo.

http://gcc.gnu.org/cgi-bin/gnatsweb.pl?cmd=view%20audit-trail&database=gcc&pr=9876

libstdc++/9876: filebuf::sputc more than 10% slower than putc

[peturr02]

>Number:         9876
>Category:       libstdc++
>Synopsis:       filebuf::sputc more than 10% slower than putc
>Confidential:   no
>Severity:       serious
>Priority:       medium
>Responsible:    unassigned
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Thu Feb 27 10:36:01 UTC 2003
>Closed-Date:
>Last-Modified:
>Originator:     peturr02@ru.is
>Release:        gcc-3.2.1
>Organization:
>Environment:
Red Hat Linux 8.0
>Description:
filebuf::sputc is more than 10% slower than putc with these tests:

time ./stdio
10.97user 1.60system 0:12.79elapsed 98%CPU (0avgtext+0avgdata 0maxresident)k
0inputs+0outputs (23major+9minor)pagefaults 0swaps
time ./iostreams
12.56user 1.89system 0:14.66elapsed 98%CPU (0avgtext+0avgdata 0maxresident)k
0inputs+0outputs (80major+15minor)pagefaults 0swaps

****** speed.hh ******
#ifndef SPEED_HH_INCLUDED
#define SPEED_HH_INCLUDED

const int iterations = 100000000;

#endif

****** stdio.cc ******
#include <cstdio>
#include "speed.hh"

int main()
{
	using namespace std;

	FILE* file = fopen("tmp", "w+");
	for (int i = 0; i < iterations; ++i)
	{
		putc(i % 100, file);
	}
	fclose(file);
	return 0;
}

****** iostreams.cc ******
#include <fstream>
#include "speed.hh"

int main()
{
	using namespace std;

	filebuf buf;
	buf.open("tmp", ios_base::out | ios_base::in | ios_base::trunc);
	for (int i = 0; i < iterations; ++i)
	{
		buf.sputc(i % 100);
	}
	buf.close();
	return 0;
}

>How-To-Repeat:

>Fix:
This speed difference disappears if streambuf::sputc is inlined and all the cruft deleted so it looks like:

int_type sputc(char_type c)
{
  if (pptr() < epptr())
    {
      *pptr() = c;
      pbump(1);
      return traits_type::to_int_type(c);
    }
  else
    return overflow(traits_type::to_int_type(c));
}
>Release-Note:
>Audit-Trail:
>Unformatted: