C vs C++ скорость файлового вывода

Да.

Есть ли где-то тесты сравнения производительности С и С++ в выполнении подобных стандартных операций?

попробуй с оптимизацией собрать

оффтоп: export PS1=«$: », а

ах да. std::endl замени на «\n», чиста ради прикола

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

В четвертых и главных - ЭТО НЕ ВАЖНО, потому что при маленьких объемах вывода вывод малая часть от общего времени выполнения, а при больших объемах вывода упираешься в пропускную способность диска (аппаратную).

> Неужели fstream настолько медленнее fprintf?

Нет, конечно. Сравнивать надо одни и те же вещи, а не совршенно разные. Погугли, что такое std::endl и что с чем ты сравнивал.

> там еще своя буферизация наск мне помнится + накл расходы на вызво вирт ф-й

Нет там ни «своей» буферизации, ни виртуальных функций.

> std::endl замени на «\n», чиста ради прикола

Ну ни хрена себе «прикол»...

Да, для больших объемов данных он тормоз. Вот бустовцы тоже меряли:

http://www.boost.org/doc/libs/1_46_1/libs/spirit/doc/html/spirit/karma/performance_measurements/numeric_performance/format_performance.html

>ах да. std::endl замени на «\n», чиста ради прикола

real = 0.27

Т.е. максимально приблизились к результату Си, но как бы не тру С++ вэй...

видимо endl очистка буфера это весьма медленно.

>В четвертых и главных - ЭТО НЕ ВАЖНО, потому что при маленьких объемах вывода вывод малая часть от общего времени выполнения

там небольшие + там небольшие = здесь итоговые большие.

Всё таки Линус был отчасти прав. Чего оно там делает, без твоего спроса...

> Чего оно там делает, без твоего спроса...

o_O, я хоть тоже не знал этот момент( не нравится iostream, пользуюсь сишными функциями ), но этот момент четко расписан в стандарте и документации

endl включает в себя flush вроде как...

Если так нужна скорость - пишите свои узкозаточенные ф-ии форматированного вывода (printf тоже тормоз еще тот), используйте frite и мапирование.

Но это все надо делать когда действит уперлись в скорость вывода.

Сам юзаю printf и свои обертки над ним.

только не 0.27, а 0.027

>только не 0.27, а 0.027 Да, конечно. Спасибо.

> но как бы не тру С++ вэй..

Щито? Это самый что ни на есть «тру сипэпэп вэй». Не надо слушать идиотов, которые пытаются программировать на плюсах как на .. на ... Короче, как-то через жопу.

видимо endl очистка буфера это весьма медленно.

Естественно. «Очистка буфера» - это принудительное переключение в контекст ядра и запись уже в ядреный буфер.

В сишном случае у тебя таких операций ≈ strlen(«Hello number»)*100000 / (PAGE_SIZE*2), а во втором = 100000

> Чего оно там делает,

Оно делает ровно то, что

1) требуется стандартом
2) описано в документации
3) изложено в исходниках

без твоего спроса...

Что значит «без твоего спроса»? Кто тебя заставлял endl писать? Если ты не знаешь/понимаешь, что оно делает, то это твои и только твои проблемы.

> Щито? Это самый что ни на есть «тру сипэпэп вэй». Не надо слушать идиотов, которые пытаются программировать на плюсах как на ..

сколько не приходилось общаться - iostream мало кому нравиться, STL, strings, locale и т.п. сделаны нормально, а вот насчет iostream - многие считают, что он «пятое колесо», т.к. и не удобен, и не быстр, я считаю также

> iostream мало кому нравиться,

Какое это имеет отношение к «тру/не_тру вэй»?

не удобен

Удобство - понятие субъективное. Как все мы знаем, кому и кобыла - невеста.

и не быстр

А вот это уже 4.2

Плюсовые потоки принцпиально ничем не отличаются от функций работы с файлами стандартной сишной библиотеке и в гнусной реализации работают на одних и тех же буферах.

библиотеки*

> Удобство - понятие субъективное.

форматирование в iostream может быть удобно только кобылам :)

А вот это уже 4.2

тут уже приводили бенчмарки на boost.org, хотите их оспорить?

> но как бы не тру С++ вэй...

Почему это?

> форматирование в iostream может быть удобно только кобылам

Не знаком, так что доверюсь твоему слову.

тут уже приводили бенчмарки на boost.org, хотите их оспорить?

Чё там «оспаривать» ? Там точно так же замерили вызов одной функции против вызова десяти и (ВНЕЗАПНО!!11) обнаружили, что второе - медленней. Там такой же капитанский «бенчмарк» как в стартовом сообщении.

Ждём бенчмарков, которые покажут, что под вендой операции в двоичном режиме быстрее, чем в текстовом.

> Там точно так же замерили вызов одной функции против вызова десяти и (ВНЕЗАПНО!!11) обнаружили, что второе - медленней.

сможете показать, как сделать на iostream без вызова десяти функций?

Что сделать-то? Ты хоть понимаешь, что

char buffer[256];
for (int i = 0; i < NUMITERATIONS; ++i) {
    sprintf(buffer, "[%-14.3f%-14.3f]", 12345.12345, 12345.12345);
}

и

std::stringstream strm;
for (int i = 0; i < NUMITERATIONS; ++i) {
    strm.str("");
    strm << '[' 
      << std::setiosflags(std::ios::fixed)
      << std::left
      << std::setprecision(3)
      << std::setw(14)
      << 12345.12345
      << std::setw(14)
      << 12345.12345
      << ']';
}

это не эквивалентный код?

Давай, ты сначала проследуешь по ссылке, поймешь о чём идет речь, а потом уже будешь задавать дурацкие вопросы.

> Что сделать-то?

кажется я переоценил ваши умственные способности...

sprintf(buffer, «[%-14.3f%-14.3f]», 12345.12345, 12345.12345);

это не эквивалентный код

ну так напишите эквивалентный и быстрый - только это я вас и просил

> ну так напишите эквивалентный

Пожалуйста:

sprintf(buffer, «[%-14.3f%-14.3f]», 12345.12345, 12345.12345);


:3

Тру было бы наверное

ostream& el( ostream& S ){ return S<<«\n»; }

и потом ее юзать

cout<<«Hello LOR!»<<el;

;-)

в принципе да, сравнение не честное, т.к. в Си сброс буфера не происходит, а есть ли в Си аналог flush из С++, чтобы в каждой итерации за него подёргать?

> а есть ли в Си аналог flush

man fflush

Хуже то, что если не хелло ворлд выводить или еще хуже, читать откуда-то, то тут все говно и вылезет.

да вообще бессмыслица потому что машинный код генируется одинаковый что для си что для сипипи совершенно одинаковый что сравниваете ? если их и сравнивать то по другим критериям нежели по скорости ну или напишите вручную вызовы виртуальный функций на чистом си потом пусть компилятор сгенерит для спипи и сравнивайте наверняка вы проиграете если не спец по ассемблеру

Ну что же. добавление fflush() в цикл программы на Си, кардинально меняет ситуацию и С++ с Си, меняются местами.

real 0m0.441s

user 0m0.060s

sys 0m0.370s

#include <stdio.h>

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

FILE *file = fopen(«hello.txt», «w»);

if(file == NULL){

   fprintf(stderr, «Файл данных не открыт\n»);      

   return -1;

   }

for (int i =0; i< 100000; i++) {

   fprintf(file, «Hello number: %d\n», i);

   fflush(file);

}

fclose(file);

return 0;

}

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

выбирать лучший результат

LOL!

в третьих да, медленней

В четвертых и главных - ЭТО НЕ ВАЖНО

С++ фанбои такие С++ фанбои :)

с -O3 возможны регрессии и глюки, лучше -02 (и -march=native ессно)

с -O3 возможны регрессии и глюки

ЕМНИП при O3 может что-то заглючить только если код изначально кривой и опирается на отсутствие некоторых корректных с точки зрения языка оптимизаций.

> С++ фанбои такие С++ фанбои :)

Но до ЛОРовских анонимусов нам ах как далекоооо...

> Но до ЛОРовских анонимусов нам ах как далекоооо...

Нет, что-ты! Говорить, что не нужно и скорость не главное - ты уже научился.

Ещё подтянуть знания по статистике чтоб не «не выбирать лучший результать» - нужно ведь получить реальную достижимую скорость, а не мифическую пиковую возможную при хитрых стечениях обстоятельств, вроде шедулинга и тд

А так - ты всё ещё С++ фанбой и у тебя С++ головного мозга.

Ты дислектик? Ели нет - потрудись перечитать еще раз то что я в этой ветке писал (в частности про скорость). Если смог прочитать - попытайся ПОНЯТЬ. Хотя я не уверен, что человек не асиливший регистрацию на ЛОРе и делающий далеко идущие выводы о головном мозге незнакомого человека умеет думать...

Ещё подтянуть знания по статистике чтоб не «не выбирать лучший результать» - нужно ведь получить реальную достижимую скорость, а не мифическую пиковую возможную при хитрых стечениях обстоятельств, вроде шедулинга и тд

Ты хочешь поучить меня статистике? Забавное такое существо... На будущее - если хочешь сравнить производительность на рафинированных тестах типа теста ТС бери именно ЛУЧШИЙ результат. Если хочешь оценить РЕАЛЬНУЮ производительность - бери СВОЕ РЕАЛЬНОЕ приложение и оценивай.

Школота блин, я б тебе зачет не поставил.