[Bug libstdc++/14078] New: Manipulators are slow

[Bug libstdc++/14078] New: Manipulators are slow

[peturr02 at ru dot is]

Using manipulators to set ios flags is more than 15x slower than calling
setf directly.

-- 
           Summary: Manipulators are slow
           Product: gcc
           Version: 3.4.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P2
         Component: libstdc++
        AssignedTo: unassigned at gcc dot gnu dot org
        ReportedBy: peturr02 at ru dot is
                CC: gcc-bugs at gcc dot gnu dot org
 GCC build triplet: i686-pc-linux-gnu
  GCC host triplet: i686-pc-linux-gnu
GCC target triplet: i686-pc-linux-gnu


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14078

[Bug libstdc++/14078] Manipulators are slow

[peturr02 at ru dot is]

------- Additional Comments From peturr02 at ru dot is  2004-02-09 09:44 -------
Created an attachment (id=5706)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=5706&action=view)
Test case

Results for 3.4:

time ./manipspeed manip 100000000
14.13user 0.00system 0:14.13elapsed 99%CPU (0avgtext+0avgdata 0maxresident)k
0inputs+0outputs (61major+11minor)pagefaults 0swaps
time ./manipspeed setf 100000000
0.76user 0.00system 0:00.75elapsed 100%CPU (0avgtext+0avgdata 0maxresident)k
0inputs+0outputs (61major+11minor)pagefaults 0swaps
time ./manipspeed direct 100000000
0.75user 0.00system 0:00.74elapsed 100%CPU (0avgtext+0avgdata 0maxresident)k
0inputs+0outputs (61major+11minor)pagefaults 0swaps
time ./manipspeed call 100000000
5.87user 0.00system 0:05.87elapsed 99%CPU (0avgtext+0avgdata 0maxresident)k
0inputs+0outputs (61major+11minor)pagefaults 0swaps

Results for 3.3.2:

time ./manipspeed manip 100000000
43.55user 0.21system 0:44.39elapsed 98%CPU (0avgtext+0avgdata 0maxresident)k
0inputs+0outputs (72major+12minor)pagefaults 0swaps
time ./manipspeed setf 100000000
1.32user 0.03system 0:01.37elapsed 98%CPU (0avgtext+0avgdata 0maxresident)k
0inputs+0outputs (71major+13minor)pagefaults 0swaps
time ./manipspeed direct 100000000
1.24user 0.01system 0:01.28elapsed 97%CPU (0avgtext+0avgdata 0maxresident)k
0inputs+0outputs (71major+13minor)pagefaults 0swaps
time ./manipspeed call 100000000
6.97user 0.01system 0:07.08elapsed 98%CPU (0avgtext+0avgdata 0maxresident)k
0inputs+0outputs (71major+13minor)pagefaults 0swaps

In both cases, the first number is the result of using manipulators:
os << foo;
the second from using setf:
os.setf(ios_base::foo);
the third from a direct call to the manipulator
foo(os);
and the fourth from calling the manipulator indirectly through an inline
function
call(os, foo);
where call is exactly like operator<< for manipulators, except inline:
template<typename C, typename T>
inline std::basic_ostream<C, T>&
call(std::basic_ostream<C, T>& os, std::ios_base&(*pf)(std::ios_base&))
{
	pf(os);
	return os;
}

So it seems manipulators can be made a lot faster just by inlining the
relevant versions of operators << and >>.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14078

[Bug libstdc++/14078] Manipulators are slow

[falk dot hueffner at student dot uni-tuebingen dot de]

------- Additional Comments From falk dot hueffner at student dot uni-tuebingen dot de  2004-02-09 09:55 -------
Subject: Re:  Manipulators are slow

"peturr02 at ru dot is" <gcc-bugzilla@gcc.gnu.org> writes:

 
> So it seems manipulators can be made a lot faster just by inlining
> the relevant versions of operators << and >>.

IMHO, we should only do that if it does not increase code size; these
manipulators are usually not very time critical, especially compared
to real I/O.



-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14078

[Bug libstdc++/14078] Manipulators are slow

[pcarlini at suse dot de]

------- Additional Comments From pcarlini at suse dot de  2004-02-09 10:41 -------
Ok, I'll try to get a feeling of the code size increase... Thanks!

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
         AssignedTo|unassigned at gcc dot gnu   |pcarlini at suse dot de
                   |dot org                     |
             Status|UNCONFIRMED                 |ASSIGNED
     Ever Confirmed|                            |1
   Last reconfirmed|0000-00-00 00:00:00         |2004-02-09 10:41:54
               date|                            |


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14078

[Bug libstdc++/14078] Manipulators are slow

[peturr02 at ru dot is]

------- Additional Comments From peturr02 at ru dot is  2004-02-09 17:09 -------
> IMHO, we should only do that if it does not increase code size;

If the compiler where really smart,
os << uppercase;
should be inlined to
os._M_flags |= ios_base::uppercase;

Which should result in both smaller code and faster execution than what
happens currently.

(Currently, the compiler is unable to inline calls through function pointers,
even if the pointee is known at compile time. There is already a report about
this, it's PR3713.)


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14078

[Bug libstdc++/14078] Manipulators are slow

[pcarlini at suse dot de]

------- Additional Comments From pcarlini at suse dot de  2004-02-10 14:16 -------
I'm looking into this and indeed I agree that the performance problem is real.
However, I'm not sure to understand what you are really advocating on the
_library_ side (vs the _compiler_ side). In particular:
  1- The concerned operator<< and operator>> are _already_ inline!
  2- Nothing changes (at least for plain -O2) if the second argument is const&.

Further comments?

Thanks,
Paolo.

-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14078

[Bug libstdc++/14078] Manipulators are slow

[giovannibajo at libero dot it]

------- Additional Comments From giovannibajo at libero dot it  2004-02-10 14:22 -------
Paolo, does the optimization problem here looks *exactly* like PR3713? 
Otherwise, can you distill a small testcase showing which code construct in v3 
blocks the inlining?

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |giovannibajo at libero dot
                   |                            |it


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14078

[Bug libstdc++/14078] Manipulators are slow

[peturr02 at ru dot is]

------- Additional Comments From peturr02 at ru dot is  2004-02-10 15:22 -------
> The concerned operator<< and operator>> are _already_ inline!

This is one of the operators in question (from include/bits/ostream.tcc):

  template<typename _CharT, typename _Traits>
    basic_ostream<_CharT, _Traits>&
    basic_ostream<_CharT, _Traits>::
    operator<<(__ostream_type& (*__pf)(__ostream_type&))
    {
      // _GLIBCXX_RESOLVE_LIB_DEFECTS
      // DR 60. What is a formatted input function?
      // The inserters for manipulators are *not* formatted output functions.
      return __pf(*this);
    }

I don't see "inline" here. Do you?


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14078

[Bug libstdc++/14078] Manipulators are slow

[pcarlini at suse dot de]

------- Additional Comments From pcarlini at suse dot de  2004-02-10 15:35 -------
Yes, I was about to post something: I had looked at the wrong operator<< and
operator>>, those in std_iomanip.h, sorry ;)

However, I still don't understand your considerations about the const argument:
the signature is fixed in 27.6.1.2.3 and 27.6.2.5.3, isn't it?

-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14078

[Bug libstdc++/14078] Manipulators are slow

[peturr02 at ru dot is]

------- Additional Comments From peturr02 at ru dot is  2004-02-10 15:55 -------
> However, I still don't understand your considerations about the const
> argument: the signature is fixed in 27.6.1.2.3 and 27.6.2.5.3, isn't it?

A top level const isn't part of the signature, so
void f(int n)
is the same as
void f(int const n)

In the same way
void f(ios_base& (*pf)(ios_base&))
is the same as
void f(ios_base& (*const pf)(ios_base&))

The only reason I suggested that the argument should be declared const is
that it seems to make a difference in practice (in fact, about 44%). I
don't know why it does though, the compiler should be able to figure out
on it's own that pf isn't modified in the body of the function.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14078

[Bug libstdc++/14078] Manipulators are slow

[pcarlini at suse dot de]

------- Additional Comments From pcarlini at suse dot de  2004-02-10 16:09 -------
> The only reason I suggested that the argument should be declared const is
> that it seems to make a difference in practice (in fact, about 44%). I
> don't know why it does though, the compiler should be able to figure out
> on it's own that pf isn't modified in the body of the function.

These are well known deficiencies of the inliner

  http://gcc.gnu.org/ml/libstdc++/2003-02/msg00302.html

which, I'm told, should be already fixed "automatically" in the tree-ssa
branch. For this reason, I'd rather prefer not adding the "redundant" const
in the signature, even if (thanks for pointing that out!) technically it would
still be conforming. Anyway, I'm going to add to the performance testsuite a
snippet distilled from your manipspeed, so we'll be able to track the issue in
the future. Thanks again for your report.

-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14078

[Bug libstdc++/14078] Manipulators are slow

[gdr at integrable-solutions dot net]

------- Additional Comments From gdr at integrable-solutions dot net  2004-02-10 17:03 -------
Subject: Re:  Manipulators are slow

"pcarlini at suse dot de" <gcc-bugzilla@gcc.gnu.org> writes:

| ------- Additional Comments From pcarlini at suse dot de  2004-02-10 16:09 -------
| > The only reason I suggested that the argument should be declared const is
| > that it seems to make a difference in practice (in fact, about 44%). I
| > don't know why it does though, the compiler should be able to figure out
| > on it's own that pf isn't modified in the body of the function.
| 
| These are well known deficiencies of the inliner
| 
|   http://gcc.gnu.org/ml/libstdc++/2003-02/msg00302.html
| 
| which, I'm told, should be already fixed "automatically" in the tree-ssa
| branch. For this reason, I'd rather prefer not adding the "redundant" const
| in the signature, even if (thanks for pointing that out!) technically it would
| still be conforming. Anyway, I'm going to add to the performance testsuite a
| snippet distilled from your manipspeed, so we'll be able to track the issue in
| the future. Thanks again for your report.

The operator should however be declared inline.

-- Gaby


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14078

[Bug libstdc++/14078] Manipulators are slow

[pcarlini at suse dot de]

------- Additional Comments From pcarlini at suse dot de  2004-02-10 17:08 -------
> The operator should however be declared inline.

Ca va sans dire! ;)

Will post a patch in a few minutes...

Paolo.

-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14078

[Bug libstdc++/14078] Manipulators are slow

[cvs-commit at gcc dot gnu dot org]

------- Additional Comments From cvs-commit at gcc dot gnu dot org  2004-02-11 12:08 -------
Subject: Bug 14078

CVSROOT:	/cvs/gcc
Module name:	gcc
Changes by:	paolo@gcc.gnu.org	2004-02-11 12:08:24

Modified files:
	libstdc++-v3   : ChangeLog 
	libstdc++-v3/include/std: std_istream.h std_ostream.h 
Added files:
	libstdc++-v3/testsuite/performance/27_io: 
	                                          fmtflags_manipulators.cc 

Log message:
	2004-02-10  Paolo Carlini  <pcarlini@suse.de>
	Petur Runolfsson  <peturr02@ru.is>
	
	PR libstdc++/14078
	* include/std/std_istream.h (operator>>(__istream_type& (*)
	(__istream_type&)), operator>>(__ios_type& (*)(__ios_type&)),
	operator>>(ios_base& (*)(ios_base&))): Declare inline.
	* include/std/std_ostream.h (operator<<(__ostream_type& (*)
	(__ostream_type&)), operator<<(__ios_type& (*)(__ios_type&)),
	operator<<(ios_base& (*) (ios_base&))): Likewise.
	* testsuite/performance/27_io/fmtflags_manipulators.cc: New.

Patches:
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libstdc++-v3/ChangeLog.diff?cvsroot=gcc&r1=1.2325&r2=1.2326
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libstdc++-v3/include/std/std_istream.h.diff?cvsroot=gcc&r1=1.15&r2=1.16
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libstdc++-v3/include/std/std_ostream.h.diff?cvsroot=gcc&r1=1.14&r2=1.15
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libstdc++-v3/testsuite/performance/27_io/fmtflags_manipulators.cc.diff?cvsroot=gcc&r1=NONE&r2=1.1



-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14078

[Bug libstdc++/14078] Manipulators are slow

[cvs-commit at gcc dot gnu dot org]

------- Additional Comments From cvs-commit at gcc dot gnu dot org  2004-02-11 15:02 -------
Subject: Bug 14078

CVSROOT:	/cvs/gcc
Module name:	gcc
Branch: 	gcc-3_4-branch
Changes by:	paolo@gcc.gnu.org	2004-02-11 15:02:04

Modified files:
	libstdc++-v3   : ChangeLog 
	libstdc++-v3/include/std: std_istream.h std_ostream.h 
Added files:
	libstdc++-v3/testsuite/performance: fmtflags_manipulators.cc 

Log message:
	2004-02-11  Paolo Carlini  <pcarlini@suse.de>
	Petur Runolfsson  <peturr02@ru.is>
	
	PR libstdc++/14078
	* include/std/std_istream.h (operator>>(__istream_type& (*)
	(__istream_type&)), operator>>(__ios_type& (*)(__ios_type&)),
	operator>>(ios_base& (*)(ios_base&))): Declare inline.
	* include/std/std_ostream.h (operator<<(__ostream_type& (*)
	(__ostream_type&)), operator<<(__ios_type& (*)(__ios_type&)),
	operator<<(ios_base& (*) (ios_base&))): Likewise.
	* testsuite/performance/fmtflags_manipulators.cc: New.

Patches:
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libstdc++-v3/ChangeLog.diff?cvsroot=gcc&only_with_tag=gcc-3_4-branch&r1=1.2224.2.33&r2=1.2224.2.34
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libstdc++-v3/include/std/std_istream.h.diff?cvsroot=gcc&only_with_tag=gcc-3_4-branch&r1=1.15&r2=1.15.10.1
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libstdc++-v3/include/std/std_ostream.h.diff?cvsroot=gcc&only_with_tag=gcc-3_4-branch&r1=1.14&r2=1.14.10.1
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libstdc++-v3/testsuite/performance/fmtflags_manipulators.cc.diff?cvsroot=gcc&only_with_tag=gcc-3_4-branch&r1=NONE&r2=1.1.2.1



-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14078

[Bug libstdc++/14078] Manipulators are slow

[pcarlini at suse dot de]

------- Additional Comments From pcarlini at suse dot de  2004-02-11 15:05 -------
(Partial, clean) fix committed to mainline and 3_4.

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|ASSIGNED                    |RESOLVED
         Resolution|                            |FIXED
   Target Milestone|---                         |3.4.0


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14078

[Bug libstdc++/14078] Manipulators are slow

[cvs-commit at gcc dot gnu dot org]

------- Additional Comments From cvs-commit at gcc dot gnu dot org  2004-07-30 19:21 -------
Subject: Bug 14078

CVSROOT:	/cvs/gcc
Module name:	gcc
Branch: 	hammer-3_3-branch
Changes by:	paolo@gcc.gnu.org	2004-07-30 19:21:29

Modified files:
	libstdc++-v3   : ChangeLog.hammer 
	libstdc++-v3/include/std: std_istream.h std_ostream.h 

Log message:
	2004-07-30  Paolo Carlini  <pcarlini@suse.de>
	Petur Runolfsson  <peturr02@ru.is>
	
	PR libstdc++/14078
	* include/std/std_istream.h (operator>>(__istream_type& (*)
	(__istream_type&)), operator>>(__ios_type& (*)(__ios_type&)),
	operator>>(ios_base& (*)(ios_base&))): Declare inline.
	* include/std/std_ostream.h (operator<<(__ostream_type& (*)
	(__ostream_type&)), operator<<(__ios_type& (*)(__ios_type&)),
	operator<<(ios_base& (*) (ios_base&))): Likewise.

Patches:
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libstdc++-v3/ChangeLog.hammer.diff?cvsroot=gcc&only_with_tag=hammer-3_3-branch&r1=1.1.2.27&r2=1.1.2.28
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libstdc++-v3/include/std/std_istream.h.diff?cvsroot=gcc&only_with_tag=hammer-3_3-branch&r1=1.4.12.3&r2=1.4.12.4
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libstdc++-v3/include/std/std_ostream.h.diff?cvsroot=gcc&only_with_tag=hammer-3_3-branch&r1=1.4.32.2&r2=1.4.32.3



-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14078