Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

<iostream>: std::cout with very low speed compared with printf #4853

Closed
jiannanya opened this issue Jul 22, 2024 · 5 comments
Closed

<iostream>: std::cout with very low speed compared with printf #4853

jiannanya opened this issue Jul 22, 2024 · 5 comments
Labels
duplicate This issue or pull request already exists performance Must go faster

Comments

@jiannanya
Copy link

Describe the bug

The default std::cout does much slower output to default console than printf,even use sync_with_stdio(false) .

Command-line test case

C:\Temp>type testcout.cc
#include <chrono>
#include <iostream>

using std::cin;
using std::cout;
using namespace std::chrono;

constexpr int bench_times{20000};
constexpr float pi{3.1415926f};

int main(int argc, char** argv) {
  cout.sync_with_stdio(false);
  cout.tie(nullptr);
  cin.tie(nullptr);
  auto tm = time(nullptr);

  auto start = high_resolution_clock::now();
  for (int i{}; i != bench_times; ++i) {
    // printf("integer: %d, fraction: %lf, tp:%lld\n", i, pi, tm);
    cout << "integer: " << i << ",fraction: " << pi << " tp: " << tm << '\n';
  }
  auto end = high_resolution_clock::now();
  auto durat = duration_cast<milliseconds>(end - start).count();

  cout << "cost: " << durat << "ms";
  return 0;
}

C:\Temp>cl.exe /O2 /GL /Gy /MD /EHsc /utf-8 /std:c++17 /Fe: .\testcout.exe .\testcout.cc

C:\Temp>.\testcout.exe

Expected behavior

The speed of std::cout is similar to the printf's.

STL version

Microsoft Visual Studio Community 2019
Version 16.11.30

My Local test result

cpu: 12th Gen Intel(R) Core(TM) i5-12600KF   3.70 GHz
system: Windows10 19044.4529
cout: cost: 1012ms   // printf
cost: 7916ms // cout
@frederick-vs-ja
Copy link
Contributor

Perhaps related to #3669.

@fsb4000
Copy link
Contributor

fsb4000 commented Jul 22, 2024

Yeah, I think it's a duplicate.

@jiannanya Consider to use buffering output, setvbuf(stdout, nullptr, _IOLBF, 16384);

@StephanTLavavej StephanTLavavej added the performance Must go faster label Jul 24, 2024
@StephanTLavavej
Copy link
Member

This indeed seems related but we're not quite willing to resolve this as a duplicate yet, as this issue is talking about the absolute performance difference (which could have multiple causes), and sync_with_stdio is just one cause.

@heckerpowered
Copy link
Contributor

I think it might have something to do with operator<<.

operator<< is a user-defined operator here, so it’s actually a function, every operator<< call locks the buffer, but the printf locks the buffer only once (I dunno how it actually works, but I don’t think it has to be locked multi times)

I’ve tested the example above, if we just call operator<< once, the speed of count is similar to printf

@StephanTLavavej StephanTLavavej added the duplicate This issue or pull request already exists label Sep 11, 2024
@StephanTLavavej
Copy link
Member

Thanks, that sounds correct to us. We're going to close this as half by design (repeatedly calling operator<< is of course more expensive) and half duplicate of #3669.

@StephanTLavavej StephanTLavavej closed this as not planned Won't fix, can't repro, duplicate, stale Sep 11, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
duplicate This issue or pull request already exists performance Must go faster
Projects
None yet
Development

No branches or pull requests

5 participants