4

For some reason I'm unable to get my output stream to run any faster with the line

std::ios_base::sync_with_stdio(false);

included at the beginning of my program. I'm testing this with these two programs:

#include <iostream>

int main() {
    for (int i = 0; i < 500000; i++)
        std::cout << "Hello World\n";
}

and

#include <iostream>

int main() {
    std::ios_base::sync_with_stdio(false);
    for (int i = 0; i < 500000; i++)
        std::cout << "Hello World\n";       
}

The run time for each program is as follows

first_test (synced)

real    0m1.095s
user    0m0.472s
sys     0m0.299s

second_test (with synced turned off)

real    0m1.091s
user    0m0.471s
sys     0m0.299s

I'm compiling with g++ -O3 main.cpp. I'm on a mac running 10.11.1.

Is there any way to get the output stream to perform faster by turning sync_with_stdio off?

3
  • 1
    did you redirect the output ? or did you let it print to the terminal ? Commented Dec 1, 2015 at 15:32
  • That seems very slow, are you sure you're measuring the right thing? How much time is taken by your OS to spawn the process? Where is the output going? Is that buffered? Is it printing to the terminal, which will add far more overhead than syncing with stdio does? You should be sure you're measuring the right thing before you bother trying to speed it up. Commented Dec 1, 2015 at 16:09
  • I've remeasured it redirecting it to a file not the terminal. I also tested the cstdio printf (instead of cout). With sync_with_stdio(false) it takes 0m0.348s and with printf it takes only 0m0.046s
    – coder21
    Commented Dec 1, 2015 at 16:36

1 Answer 1

3

Is there any way to get the output stream to perform faster by turning sync_with_stdio off?

No, it's not mandatory that code will run any faster. That option allows you to mix I/O to/from std::cout/std::cin (and friends) with I/O to/from stdout/stdin (and friends):

std::cout << "test";
printf("another test";

It is implementation defined whether I/O is buffered (and how) and it is implementation defined how to achieve this result. Consequence of this is that it is implementation defined whether this mechanism will slow down your code or not (and then if you will have any benefit turning it off).

You tried and in your case your compiler has a good standard library implementation without any visible price to keep this synchronization.


That said also note that measurement of this type are hard to implement correctly. How did you get those values? Moreover same test should be repeated multiple times to calculate an average. Also note that buffering itself may bias this results. Please note that outputting to console will also flat your results. Final note: I'd also try with a higher value than 500000, timing around 1 ms may be not as accurate as you may wish.

4
  • 2
    IIRC on file streams it's more evident.
    – edmz
    Commented Dec 1, 2015 at 16:08
  • I measured it simply using the time command. I retimed it redirecting the output to a fileand measured against cstdio's printf. with sync_with_stdio(false) it took 0m0.348s but fprint took only 0m0.045s. It seems to me that the difference shouldnt be quite that drastic
    – coder21
    Commented Dec 1, 2015 at 16:40
  • Why not? C++ streams do much much more than a plain printf(), in such trivial case (in the sense that there is nothing else but outputting) then you can see that difference (note you're measuring a 300 msec difference for a single shot, it also measure program loading and for C++ streams there is much more to load and initialize than C style I/O). A better test should avoid to measure such time (and then should be performed inside your program). I explain: if you change from 500000 to 5 you may see same overhead (340 ms vs 40 ms). What you're measuring is overhead plus I/O time... Commented Dec 1, 2015 at 16:48
  • You should expect C++ I/O to be slower as you should expect program loading and initialization to be slower too. You should also expect that this difference won't change much if you enable/disable synchronization (because it's somehow unrelated to I/O itself). All this said...in real world (non fictional programs) you should have less difference and it'll greatly vary according to compiler (also its version), optimizations and environment. Commented Dec 1, 2015 at 16:51

Not the answer you're looking for? Browse other questions tagged or ask your own question.