Is std::cout slower than std::printf

[Minti]

Is std::cout slower than printf
When we call printf e.g. in

printf(20 format conversion specifications, 20 arguments);

Is it faster than the

std::cout << { 20 redirections to the output stream }
It seems {quite obvious}[1] to me that this @should@ infact be true
this is because in a sense the std::cout method would require 20 calls
to the overloaded operator << on ostream.

[1] I can clearly see you taking your guns out.
--
Imanpreet Singh Arora

[Sam Holden]

On 22 Jun 2004 00:24:10 -0700, Minti <mi************@yahoo.com> wrote:

Is std::cout slower than printf
When we call printf e.g. in

printf(20 format conversion specifications, 20 arguments);

Is it faster than the

std::cout << { 20 redirections to the output stream }
It seems {quite obvious}[1] to me that this @should@ infact be true
this is because in a sense the std::cout method would require 20 calls
to the overloaded operator << on ostream.

The printf call would require a run time examination of the format
string in order to determine the types of the arguments.

All (or most, or some) of those operator<< calls could be in-lined by
the compiler. Certainly for built-in types (which is all that can be
output by printf, as far as I know) the method call overhead should be
in-lined away (of course there are issues with references and
inheritance and the joys of dynamic dispatch).

I would expect a good optimising compiler to produce faster code in the
cout case, while a less optimising compiler might produce faster code in
the printf case (by not optimising away that function call overhead,
assuming that the printf function was implemented reasonably...)

Of course a fancy compiler could notice a constant format string and
know about printf and do something to make debugging hell on earth...

Note: I am not a C++ compiler author, or an optimising compiler of any
flavour author, in fact by the time I've written this someone who is
has probably answered anyway and disagreed with me.

--
Sam Holden

[Alex Vinokur]

"Minti" <mi************@yahoo.com> wrote in message news:e8**************************@posting.google.c om...

Is std::cout slower than printf
When we call printf e.g. in

printf(20 format conversion specifications, 20 arguments);

Is it faster than the

std::cout << { 20 redirections to the output stream }
It seems {quite obvious}[1] to me that this @should@ infact be true
this is because in a sense the std::cout method would require 20 calls
to the overloaded operator << on ostream.

[1] I can clearly see you taking your guns out.
--
Imanpreet Singh Arora

See relevant discussion at
http://groups.google.com/groups?thre...nix2.panix.com
--
Alex Vinokur
http://mathforum.org/library/view/10978.html
http://sourceforge.net/users/alexvn

[John Harrison]

"Minti" <mi************@yahoo.com> wrote in message
news:e8**************************@posting.google.c om...

Is std::cout slower than printf
When we call printf e.g. in

printf(20 format conversion specifications, 20 arguments);

Is it faster than the

std::cout << { 20 redirections to the output stream }
It seems {quite obvious}[1] to me that this @should@ infact be true
this is because in a sense the std::cout method would require 20 calls
to the overloaded operator << on ostream.

[1] I can clearly see you taking your guns out.
--
Imanpreet Singh Arora

My first comment is who cares? std::cout is superior in functionality and
for most people that is more important. My second comment is that if you
really do care then write some code and time them. That is the only way to
answer your question. My expectation would that std::cout is indeed slower,
but that wouldn't stop me using it.

john

[Rolf Magnus]

Minti wrote:

Is std::cout slower than printf
When we call printf e.g. in

printf(20 format conversion specifications, 20 arguments);

Is it faster than the

std::cout << { 20 redirections to the output stream }
It seems {quite obvious}[1] to me that this @should@ infact be true
this is because in a sense the std::cout method would require 20 calls
to the overloaded operator << on ostream.

printf needs to parse the format string at runtime. Further, I doubt
that in a typical implementation _all_ the possible conversions are
implemented withn the printf function itself. So I'd expect printf to
also do the 20 function calls internally.

[Rolf Magnus]

John Harrison wrote:

When we call printf e.g. in

printf(20 format conversion specifications, 20 arguments);

Is it faster than the

std::cout << { 20 redirections to the output stream }
It seems {quite obvious}[1] to me that this @should@ infact be true
this is because in a sense the std::cout method would require 20
calls to the overloaded operator << on ostream.

[1] I can clearly see you taking your guns out.
--
Imanpreet Singh Arora
My first comment is who cares? std::cout is superior in functionality
and for most people that is more important.

In which way is it superior in functionality?
My second comment is that if you really do care then write some code
and time them. That is the only way to answer your question. My
expectation would that std::cout is indeed slower, but that wouldn't
stop me using it.

Are you just guessing that or is there a reason why you think so?

[John Harrison]

"Rolf Magnus" <ra******@t-online.de> wrote in message
news:cb*************@news.t-online.com...

John Harrison wrote:

When we call printf e.g. in

printf(20 format conversion specifications, 20 arguments);

Is it faster than the

std::cout << { 20 redirections to the output stream }
It seems {quite obvious}[1] to me that this @should@ infact be true
this is because in a sense the std::cout method would require 20
calls to the overloaded operator << on ostream.

[1] I can clearly see you taking your guns out.
--
Imanpreet Singh Arora
My first comment is who cares? std::cout is superior in functionality
and for most people that is more important.

In which way is it superior in functionality?

I should have said the iostream library as a whole is superior to the stdio
library. I was thinking of the way that you can

1) Output user defined types with iostream
2) Define new types of stream
3) Write code that is independent of the type of stream you want to input
from or output to

None of those is possible with stdio.

My second comment is that if you really do care then write some code
and time them. That is the only way to answer your question. My
expectation would that std::cout is indeed slower, but that wouldn't
stop me using it.

Are you just guessing that or is there a reason why you think so?

I've never tested it myself, but I seen a few times when posters to this
group have tested it. My recollection is that iostream was slower for those
posters, but of course this is entirely platform dependent. As I said, for
me in the sort of work I do, its never really been an issue, I realise that
is not the case for everyone.

john

[tom_usenet]

On 22 Jun 2004 00:24:10 -0700, mi************@yahoo.com (Minti) wrote:

Is std::cout slower than printf
When we call printf e.g. in

printf(20 format conversion specifications, 20 arguments);

Is it faster than the

std::cout << { 20 redirections to the output stream }
It seems {quite obvious}[1] to me that this @should@ infact be true
this is because in a sense the std::cout method would require 20 calls
to the overloaded operator << on ostream.

[1] I can clearly see you taking your guns out.

In theory, cout could be faster than printf. In practice, it isn't.
Typically operator<< methods follow this pattern:

ostream::sentry cerberos(os); //flushes tied streams
if (cerberos) //checks for good state
{
try
{
//do output, using facet and streambuf
}
catch(...)
{
//set badbit and possibly rethrow;
}
//if there's an error,
//set failbit/eofbit and possibly throw.
}
return os;
//here stream is flushed by ~sentry if unitbuf is set.

As you can see, that's quite a lot to do and is unlikely to be
inlined. If you split the printf into 20 printf's, performance might
be a bit closer.

I think the above can be implemented a lot better, optimizing the
common case (no tied streams, not need to flush). If that is done, and
the formatting facets similarly optimized, then ostreams can be
faster. Apparently cxxrt, Dietmar Kuehl's standard C++ library
implementation, exceeds cstdio performance in many cases.

You should also look at the C++ performance technical report:
http://www.open-std.org/jtc1/sc22/wg.../PDTR18015.pdf
(particularly chapter 3)

Tom
--
C++ FAQ: http://www.parashift.com/c++-faq-lite/
C FAQ: http://www.eskimo.com/~scs/C-faq/top.html

[fabio de francesco]

mi************@yahoo.com (Minti) wrote in message news:<e8**************************@posting.google. com>...

Is std::cout slower than printf
When we call printf e.g. in

printf(20 format conversion specifications, 20 arguments);

Is it faster than the

std::cout << { 20 redirections to the output stream }
It seems {quite obvious}[1] to me that this @should@ infact be true
this is because in a sense the std::cout method would require 20 calls
to the overloaded operator << on ostream.

[1] I can clearly see you taking your guns out.

It is possible to collect cpu time of execution by the use of ANSI C
clock() before and after some operation in order to extract the
duration as a difference.
When using clock() don't forget to divide this difference by the macro
CLOCKS_PER_SEC .

If you have access to a Linux/Unix OS the times() system call can be
used too to get real and cpu time.
The main advantage of the latter is that also child time can be
collected.

Ciao,

Fabio De Francesco.

[Dietmar Kuehl]

sh*****@flexal.cs.usyd.edu.au (Sam Holden) wrote:

I would expect a good optimising compiler to produce faster code in the
cout case, while a less optimising compiler might produce faster code in
the printf case (by not optimising away that function call overhead,
assuming that the printf function was implemented reasonably...)
Actually, that was my assumption way back before I started to implement my
own standard C++ library. As it turns out, it is pretty tough to arrive at
the same speed as the stdio-family with standard IOStreams: you need to go
through a whole bunch of tricks to avoid overheads. This concerns things
like caching result of the ctype and numpunct facets, short-circuiting
sentry construction, folding flags and conditions, etc. Effectively, this
results in roughly the same performance as stdio (if anybody has results
about current implementations, I would be quite interested, especially if
the IOStreams library shows far better performance than stdio). I'm not
sure whether such enhancements are applied to other library implementations
(maybe the other library implementers can say something on this issue...).
Note: I am not a C++ compiler author, or an optimising compiler of any
flavour author, in fact by the time I've written this someone who is
has probably answered anyway and disagreed with me.

I don't think that the optimising compiler can do much here although there
will be a *huge* performance difference between optimized and unoptimized
IOStreams. With IOStreams and locales being templates often located in
header files, optimized compilation will take quite a while at least with
the compilers I tested it (mostly gcc and Sun CC). However, many of the
needed performance gains are in the library implementation.

BTW, you can download my implementation form
<http://www.dietmar-kuehl.de/cxxrt/> if you want to look at it.
--
<mailto:di***********@yahoo.com> <http://www.dietmar-kuehl.de/>
<http://www.contendix.com> - Software Development & Consulting

[Dietmar Kuehl]

sh*****@flexal.cs.usyd.edu.au (Sam Holden) wrote:

I would expect a good optimising compiler to produce faster code in the
cout case, while a less optimising compiler might produce faster code in
the printf case (by not optimising away that function call overhead,
assuming that the printf function was implemented reasonably...)
Actually, that was my assumption way back before I started to implement my
own standard C++ library. As it turns out, it is pretty tough to arrive at
the same speed as the stdio-family with standard IOStreams: you need to go
through a whole bunch of tricks to avoid overheads. This concerns things
like caching result of the ctype and numpunct facets, short-circuiting
sentry construction, folding flags and conditions, etc. Effectively, this
results in roughly the same performance as stdio (if anybody has results
about current implementations, I would be quite interested, especially if
the IOStreams library shows far better performance than stdio). I'm not
sure whether such enhancements are applied to other library implementations
(maybe the other library implementers can say something on this issue...).
Note: I am not a C++ compiler author, or an optimising compiler of any
flavour author, in fact by the time I've written this someone who is
has probably answered anyway and disagreed with me.

I don't think that the optimising compiler can do much here although there
will be a *huge* performance difference between optimized and unoptimized
IOStreams. With IOStreams and locales being templates often located in
header files, optimized compilation will take quite a while at least with
the compilers I tested it (mostly gcc and Sun CC). However, many of the
needed performance gains are in the library implementation.

BTW, you can download my implementation form
<http://www.dietmar-kuehl.de/cxxrt/> if you want to look at it.
--
<mailto:di***********@yahoo.com> <http://www.dietmar-kuehl.de/>
<http://www.contendix.com> - Software Development & Consulting

[Jerry Coffin]

mi************@yahoo.com (Minti) wrote in message news:<e8**************************@posting.google. com>...

Is std::cout slower than printf
When we call printf e.g. in

printf(20 format conversion specifications, 20 arguments);

Is it faster than the

std::cout << { 20 redirections to the output stream }

They'll typically both run as fast as the I/O subsystem supports,
though iostreams will typically require more CPU usage to do it.

--
Later,
Jerry.

The universe is a figment of its own imagination.

[Jack Klein]

On 22 Jun 2004 00:24:10 -0700, mi************@yahoo.com (Minti) wrote
in comp.lang.c++:

Is std::cout slower than printf
When we call printf e.g. in

printf(20 format conversion specifications, 20 arguments);

Is it faster than the

std::cout << { 20 redirections to the output stream }
It seems {quite obvious}[1] to me that this @should@ infact be true
this is because in a sense the std::cout method would require 20 calls
to the overloaded operator << on ostream.

[1] I can clearly see you taking your guns out.

Yes, in fact the ISO C++ standard requires that std::cout be at least
27.2% slower than printf() in all cases.

--
Jack Klein
Home: http://JK-Technology.Com
FAQs for
comp.lang.c http://www.eskimo.com/~scs/C-faq/top.html
comp.lang.c++ http://www.parashift.com/c++-faq-lite/
alt.comp.lang.learn.c-c++
http://www.contrib.andrew.cmu.edu/~a...FAQ-acllc.html