C ++プログラムでscanf（）を使用すると、cinを使用するよりも高速ですか？

これが本当かどうかはわかりませんが、問題を提供しているサイトの1つに関するFAQを読んでいたときに、何かに気づきました。

入出力メソッドを確認してください。C ++では、cinおよびcoutの使用は遅すぎます。これらを使用すると、適切な量の入力または出力で問題を解決できないことが保証されます。代わりにprintfとscanfを使用してください。

誰かがこれを明確にしてもらえますか？C ++プログラムで実際にscanf（）を使用するのは、cin >>を使用するよりも速いですか？はいの場合、それをC ++プログラムで使用するのは良い習慣ですか？私はC ++を学習しているだけですが、C固有のものだと思いました...

これは、単純なケースの簡単なテストです。標準入力から数値のリストを読み取り、すべての数値のXORを行うプログラムです。

iostreamバージョン：

#include <iostream>

int main(int argc, char **argv) {

  int parity = 0;
  int x;

  while (std::cin >> x)
    parity ^= x;
  std::cout << parity << std::endl;

  return 0;
}

scanfバージョン：

#include <stdio.h>

int main(int argc, char **argv) {

  int parity = 0;
  int x;

  while (1 == scanf("%d", &x))
    parity ^= x;
  printf("%d\n", parity);

  return 0;
}

結果

3番目のプログラムを使用して、33,280,276個の乱数を含むテキストファイルを生成しました。実行時間は次のとおりです。

iostream version:  24.3 seconds
scanf version:      6.4 seconds

コンパイラーの最適化設定を変更しても、結果はほとんど変わりません。

したがって、実際には速度の違いがあります。

編集：ユーザーclyfish は、速度の違いは主にiostream I / O関数がCI / O関数との同期を維持しているためであると指摘しています。これをオフにするには、次を呼び出しますstd::ios::sync_with_stdio(false);。

#include <iostream>

int main(int argc, char **argv) {

  int parity = 0;
  int x;

  std::ios::sync_with_stdio(false);

  while (std::cin >> x)
    parity ^= x;
  std::cout << parity << std::endl;

  return 0;
}

新しい結果：

iostream version:                       21.9 seconds
scanf version:                           6.8 seconds
iostream with sync_with_stdio(false):    5.5 seconds

C ++ iostreamが勝利しました！ この内部同期/フラッシュは、通常、iostream I / Oの速度を低下させるものであることがわかりました。stdioとiostreamを混在させない場合は、オフにすることができ、iostreamが最も高速になります。

コード：https : //gist.github.com/3845568

http://www.quora.com/Is-cin-cout-slower-than-scanf-printf/answer/Aditya-Vishwakarma

cin/ coutは、基礎となるCライブラリとの同期を保つ必要があるため、パフォーマンスが低下する可能性があります。これは、C IOとC ++ IOの両方を使用する場合に不可欠です。

ただし、C ++ IOのみを使用する場合は、IO操作の前に次の行を使用してください。

std::ios::sync_with_stdio(false);

この詳細については、対応するlibstdc ++ docsを参照してください。

おそらくscanfはストリームを使用するよりもいくらか高速です。ストリームは多くのタイプセーフを提供し、実行時にフォーマット文字列を解析する必要はありませんが、通常、過度のメモリ割り当てを必要としないという利点があります（これはコンパイラとランタイムに依存します）。とは言っても、パフォーマンスが唯一の最終目標であり、クリティカルパスにいる場合を除いて、より安全な（遅い）メソッドを優先する必要があります。

Herb Sutterによる「マナーファームの文字列フォーマッター」による非常に美味しい記事があり、文字列フォーマッターのパフォーマンスの詳細sscanfやlexical_cast、低速または高速で実行されているのはどのようなものでしたか。これは、CスタイルのIOとC ++スタイルの間のパフォーマンスに影響を与えるようなものに似ています。フォーマッタとの主な違いは、タイプセーフとメモリ割り当ての数である傾向がありました。

UVa Onlineの問題に取り組む夜を過ごしました（Factovisors、非常に興味深い問題、チェックしてください）：

http://uva.onlinejudge.org/index.php?option=com_onlinejudge&Itemid=8&category=35&page=show_problem&problem=1080

提出物にTLE（制限時間を超えた）が出ました。これらの問題解決オンライン裁判官サイトでは、ソリューションの評価に使用される数千のテストケースを処理するために、2〜3秒の時間制限があります。このような計算集中型の問題では、マイクロ秒ごとにカウントされます。

私は提案されたアルゴリズム（サイトのディスカッションフォーラムでお読みください）を使用していましたが、まだTLEを取得していました。

"cin >> n >> m"を "scanf（"％d％d "、＆n、＆m）"に変更し、いくつかの小さな "out"を "printfs"に変更すると、TLEは "Accepted"に変わりました！

そう、そうです、特に時間制限が短い場合、それは大きな違いを生む可能性があります。

パフォーマンスと文字列フォーマットの両方に関心がある場合は、Matthew WilsonのFastFormatライブラリをご覧ください。

編集-そのライブラリーのアキュ出版物へのリンク：http : //accu.org/index.php/journals/1539

FILE *をC ++ streambufと​​して実装するstdio実装（libio）、およびランタイムフォーマットパーサーとしてfprintfがあります。IOstreamはランタイム形式の解析を必要としません。それはすべてコンパイル時に行われます。したがって、バックエンドが共有されている場合、実行時のiostreamの方が高速であることを期待するのは妥当です。

はい、iostreamはcstdioより遅いです。
はい、C ++で開発している場合は、おそらくcstdioを使用すべきではありません。
そうは言っても、書式設定、タイプセーフ、何とか何とか何とか何も気にしないのであれば、scanfよりもI / Oを取得するためのより高速な方法があります...

たとえば、これはSTDINから数値を取得するカスタムルーチンです。

inline int get_number()
{
    int c;        
    int n = 0;

    while ((c = getchar_unlocked()) >= '0' && c <= '9')
    {
        // n = 10 * n + (c - '0');
        n = (n << 3) + ( n << 1 ) + c - '0';
    }
    return n;
}

問題は、呼び出しcinより上の抽象化レイヤーを提供するため、多くのオーバーヘッドが発生することですscanf()。C ++ソフトウェアを作成scanf()してcinいる場合は、それが必要でcinあるため、overを使用しないでください。パフォーマンスが必要な場合は、おそらくC ++でI / Oを作成することはおそらくないでしょう。

文cinとcout一般的な使用には、より遅いように見えるscanfとprintfC ++で、実際に彼らは高速です！

重要なのは、C ++では、cinandとを使用するたびにcout、デフォルトで同期プロセスが実行され、プログラムscanfと両方で使用した場合cin、両方が互いに同期して動作することを確認します。この同期プロセスには時間がかかります。したがってcin、coutAPPEARは遅くなります。

ただし、同期プロセスが発生しないように設定されている場合は、cinよりも高速ですscanf。

同期プロセスをスキップするには、次のコードスニペットをの最初のプログラムに含めますmain()。

std::ios::sync_with_stdio(false);

詳細については、このサイトにアクセスしてください。

#include <stdio.h>
#include <unistd.h>

#define likely(x)       __builtin_expect(!!(x), 1)
#define unlikely(x)     __builtin_expect(!!(x), 0)

static int scanuint(unsigned int* x)
{
  char c;
  *x = 0;

  do
  {
      c = getchar_unlocked();
      if (unlikely(c==EOF)) return 1;
  } while(c<'0' || c>'9');

  do
  {
      //*x = (*x<<3)+(*x<<1) + c - '0';
      *x = 10 * (*x) + c - '0';
      c = getchar_unlocked();
      if (unlikely(c==EOF)) return 1;
  } while ((c>='0' && c<='9'));

  return 0;
}

int main(int argc, char **argv) {

  int parity = 0;
  unsigned int x;

  while (1 != (scanuint(&x))) {
    parity ^= x;
  }
  parity ^=x;
  printf("%d\n", parity);

  return 0;
}

ファイルの最後にバグがありますが、このCコードは高速のC ++バージョンよりも劇的に高速です。

paradox@scorpion 3845568-78602a3f95902f3f3ac63b6beecaa9719e28a6d6 ▶ make test        
time ./xor-c < rand.txt
360589110

real    0m11,336s
user    0m11,157s
sys 0m0,179s
time ./xor2-c < rand.txt
360589110

real    0m2,104s
user    0m1,959s
sys 0m0,144s
time ./xor-cpp < rand.txt
360589110

real    0m29,948s
user    0m29,809s
sys 0m0,140s
time ./xor-cpp-noflush < rand.txt
360589110

real    0m7,604s
user    0m7,480s
sys 0m0,123s

元のC ++は30秒かかり、Cコードは2秒かかりました。

もちろん、iostreamではなくcstdioを使用するのはばかげています。少なくともソフトウェアを開発するときは（すでにc ++ over cを使用している場合は、すべての方法を試して、デメリットに悩まされるのではなく、メリットを利用してください）。

しかし、ソフトウェアを開発していないオンライン裁判官では、Microsoftソフトウェアが3秒で60秒かかることを実行できるプログラムを作成しています!!!

したがって、この場合、ゴールデンルールは次のようになります（もちろん、javaを使用してさらに問題が発生しない場合）

• 問題を解決するためにc ++を使用し、その能力（および重さ/遅さ）のすべてを使用する
• 時間制限がある場合は、printfsとscanfsのcinsとcoutsを変更します（クラス文字列を使用して失敗した場合は、次のように印刷します：printf（％s、mystr.c_str（））;
• それでも時間が制限されている場合は、明らかな最適化を試みてください（組み込みのfor / while / dowhilesまたは再帰関数が多すぎるのを避けるなど）。また、大きすぎる参照オブジェクトを渡すようにしてください...
• それでも時間制限がある場合は、std :: vectorsとc-arrayのセットを変更してみてください。
• それでも時間制限がある場合は、次の問題に進んでください...

場合でも、scanfより速くだったcin、それは問題ではないでしょう。ほとんどの場合、ハードドライブまたはキーボードから読み取ります。生データをアプリケーションに取り込むには、scanfそれcinを処理するよりも桁違いに長い時間がかかります。