мне кажется или участники не в равных условиях?

Э, не понял... За каким гуком здесь стоят seekg и rewind? Постоянно считывать одни и те же 64К?
Дак их система закэширует по ей одной понятному принципу... Данный код ничего реального не отображает.

Ну вот я сделал и свои замеры. Код следующий был у меня (MinGW)



Файл 42-метровый, если что.
"std::cout << buf[77]" для облома компилятору оптимизировать вызов функции, так как без этого он явно пытается это делать.
Собрано в release.

Итак, результаты:


Разницу в 5 раз во времени не вижу.

Реализация замера времени в данном случае - QueryPerformanceFrequency/QueryPerformanceCounter.

Добавлено через 7 минут и 27 секунд

Что ты здесь имел в виду? Отсутствие ios::binary? Или что-то другое?


Это сообщение отредактировал(а) JackYF - 26.4.2007, 17:01

Чтобы не прочитать за конец файла


Через чур интеллектуально для системы



Принимается. Изменил на другой



Режим Release.
Первый цикл пробегает за какую-то долю секунды.
За время второго я успеваю сосчитать до 25-ти


Чего мелочиться? давай уж хотя бы 10^4

Вобщем я бы мог поспорить на счет правильности вывода и точности счетчиков, но дело-то в том что у меня разница заметна "на глаз". 
Я пробую на vs6.0, но и на 8-ке у меня все летало. Хорошо помню как считал построчно и обработал каждую строку в файле 80-метров за 3 секунды. 
Может дело в различной реализации?

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

Это сообщение отредактировал(а) dizzy1984 - 26.4.2007, 20:53

Забавно. Давай подсчитаем количество считанных тобой байт. За одно считывание у нас читается приблизительно 64К.
Считываний у тебя 10000. Итого мы считываем 10000*64К = 10*64М = 640 Мб.
Ты говоришь, что это происходит за долю секунды?

По имеющимся у меня сведениям, скорость 640 Мб/с не имеет ни один жесткий диск.

В данном случае я считаю, что компилятор твой оптимизирует вызов в первом случае, и ничего реально из файла не читает. Добавь вывод нулевого символа буфера на экран либо в другой файл в каждой итерации, приблизительно, как у меня. И скажи, что из этого получится.

ребят, вас чё понесло-то??  

Лично я увидел фразу



И я с этим не согласен. Отсюда все мои посты. Обертка в С-файлов в удобные классы для работы, которые написаны по ООП и в рамках STL - очень хорошая вещь. Во многих случаях облегчает жизнь, особенно сначала. Но от того, что мы обернем что-нибудь в красивую оболочку, скорость не увеличится.

JackYF, вы тут делагогию развели по пустому! я сделал что хотел... за эт пасибо... я не просил самый быстрый способ...  

Нет, не по пустому... Это довольно-таки принципиальный вопрос - вопрос скорости работы С-файлов и С++-потоков.

В данном случае скорость не роляет, это да.

Если оффтопик, то можно выделить в отдельную тему...

Высокая скорость работы первого цикла объяснялась отсутствием процесса чтения. Метод read читал первые 4-ре байта и встречал символ ctrl+z, а посколько файл был открыт как текстовый (  ) воспринимал это как конец файла и ставил статус "все плохо". все последующие 10000-1 итерации работа метода обрывалась где-то в самом начале на проверке статуса.
Я добавил std::ios::binary в конструктор потока. Время срабатывания метода ofstream::read стало больше, чем fread от 1.5ра до где-то 10-ти раз.
Я зря спорил с тобой, ты был прав с самого начала.
Извини.


P.S Мне было интересно и я попробовал также CStdioFile::Read. В большинстве случаев он шел очень близко к fread.

вот-вот. я про это и говорил.

Ага, понятно. Я тогда заметил отсутствие ios::binary, но забыл про такую фишку чтения текстовых файлов...
Тогда многое становится ясным.



Не надо извиняться, главное, что все стало на свои места. Мы провели ряд экспериментов, и теперь не будем голословными в этом вопросе.
В споре рождается истина, как бы банально это не звучало.

Вот теперь тему можно точно закрывать.