Использование scanf () в программах на C ++ быстрее, чем использование cin?

Не знаю, правда ли это, но когда я читал FAQ по одному из проблемных сайтов, я нашел кое-что, что привлекло мое внимание:

Проверьте свои методы ввода / вывода. В C ++ использование cin и cout слишком медленное. Используйте их, и вы гарантированно не сможете решить любую проблему с приличным объемом ввода или вывода. Вместо этого используйте printf и scanf.

Может кто-нибудь прояснить это? Действительно ли использование scanf () в программах на C ++ быстрее, чем использование cin >> something ? Если да, то стоит ли использовать его в программах на 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;
}

Полученные результаты

Используя третью программу, я создал текстовый файл, содержащий 33 280 276 случайных чисел. Сроки исполнения:

iostream version:  24.3 seconds
scanf version:      6.4 seconds

Изменение настроек оптимизации компилятора, похоже, не сильно повлияло на результаты.

Итак: разница в скорости действительно есть.

РЕДАКТИРОВАТЬ: Пользователь clyfish указывает ниже, что разница в скорости в значительной степени связана с функциями ввода-вывода iostream, поддерживающими синхронизацию с функциями 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. Если мы не смешиваем 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 ++, просто используйте строку ниже перед любыми операциями ввода-вывода.

std::ios::sync_with_stdio(false);

Дополнительные сведения об этом см. В соответствующей документации libstdc ++ .

Вероятно, scanf работает несколько быстрее, чем потоки. Хотя потоки обеспечивают большую безопасность типов и не должны анализировать строки формата во время выполнения, обычно они имеют преимущество в том, что они не требуют чрезмерного выделения памяти (это зависит от вашего компилятора и времени выполнения). Тем не менее, если производительность не является вашей единственной конечной целью и вы находитесь на критическом пути, вам действительно следует отдавать предпочтение более безопасным (более медленным) методам.

Здесь есть очень восхитительная статья, написанная Хербом Саттером « Строковые форматтеры усадебной фермы », в которой подробно рассказывается о производительности струнных форматеров, таких как sscanfи, lexical_castи о том, какие вещи заставляли их работать медленно или быстро. Возможно, это аналогично тому, что может повлиять на производительность между вводом-выводом стиля C и стилем 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)» и несколько крошечных «couts» на «printfs», и мой TLE превратился в «Принято»!

Так что да, это может иметь большое значение, особенно когда сроки ограничены.

Если вам важны как производительность, так и форматирование строк, обратите внимание на FastFormat Мэтью Уилсона. библиотеку .

edit - ссылка на публикацию accu в этой библиотеке: http://accu.org/index.php/journals/1539

Существуют реализации stdio ( libio ), которые реализуют FILE * как streambuf C ++ и fprintf как синтаксический анализатор формата времени выполнения. Потоки ввода-вывода не нуждаются в синтаксическом анализе формата времени выполнения, все это делается во время компиляции. Итак, с общими бэкэндами разумно ожидать, что iostreams будет быстрее во время выполнения.

Да, iostream медленнее, чем cstdio.
Да, вам, вероятно, не следует использовать cstdio, если вы разрабатываете на C ++.
Сказав это, есть даже более быстрые способы получить ввод-вывод, чем scanf, если вас не волнует форматирование, безопасность типов, бла, бла, бла ...

Например, это настраиваемая процедура для получения числа из 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и coutв общем использовании , кажется, медленнее , чем scanfи printfв C ++, но на самом деле они являются БЫСТРЕЕ!

Дело в том, что в C ++ всякий раз, когда вы используете cinи cout, по умолчанию выполняется процесс синхронизации, который гарантирует, что если вы используете оба scanfи cinв своей программе, то они оба будут синхронизироваться друг с другом. Этот процесс синхронизации требует времени. Следовательно cinиcout ПОКАЗАТЬСЯ медленнее.

Однако, если для процесса синхронизации установлено значение «Не происходит», cinвыполняется быстрее, чем scanf.

Чтобы пропустить процесс синхронизации, включите в свою программу следующий фрагмент кода прямо в начале main():

std::ios::sync_with_stdio(false);

Посетите этот сайт для получения дополнительной информации.

Проблема в том, что cinэто связано с большими накладными расходами, потому что это дает вам уровень абстракции над scanf()вызовами. Вы не должны использовать scanf()over, cinесли пишете программное обеспечение на C ++, потому что это нужно cinдля. Если вам нужна производительность, вы, вероятно, все равно не будете писать ввод-вывод на C ++.

#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 секунды.

Конечно, смешно использовать cstdio вместо iostream. По крайней мере, когда вы разрабатываете программное обеспечение (если вы уже используете c ++ вместо c, то пройдите весь путь и используйте его преимущества вместо того, чтобы страдать от его недостатков).

Но, по мнению онлайн-судьи, вы не разрабатываете программное обеспечение, вы создаете программу, которая должна уметь делать то, что ПО Microsoft выполняет за 60 секунд за 3 секунды !!!

Итак, в этом случае золотое правило выглядит так (конечно, если у вас не возникнет еще больше проблем с использованием java)

• Используйте c ++ и используйте всю его мощность (и тяжесть / медлительность) для решения проблемы.
• Если вы ограничены во времени, измените cins и couts для printfs и scanfs (если вы запутались, используя строку класса, напечатайте так: printf (% s, mystr.c_str ());
• Если время по-прежнему ограничено, попробуйте внести очевидные оптимизации (например, избегайте слишком большого количества встроенных функций для / while / dowhiles или рекурсивных функций). Также не забудьте передать слишком большие ссылочные объекты ...
• Если время по-прежнему ограничено, попробуйте изменить std :: vectors и наборы для c-массивов.
• Если у вас все еще ограничено время, переходите к следующей задаче ...

Даже если бы они scanfбыли быстрее cin, это не имело бы значения. В большинстве случаев вы будете читать с жесткого диска или клавиатуры. Получение исходных данных в приложение занимает порядки больше времени , чем требуется , scanfили cinобрабатывать его.