Буферизованный и небуферизованный ввод-вывод

[qknife]

Получил задачу, на чтение с файлов. Все понятно, но препод включил вот такое требование:

"Позаботьтесь о том, чтобы при проведении эксперимента данные файлов реально считывались с указанного диска, а не из буфера ввода-вывода или из дискового кэша!"

Я так понимаю, что надо просто использовать функции прямого чтения из файла, а не те, которые работают с буфером. Отсюда вопрос:
1. Является ли функция string::getline подходящей при условии открытия файла через поток ifstream
2. Если нет, то какую лучше использовать для работы именно со строками

[McZim]

qknife, к сожалению в венде не силен. Но, любое поточное чтение является чтением из бефера, следовательно ifstream, не подходит.

[RXL]

qknife, препод глупость сморозил или не смог правильно выразить свою мысль. В современных ОС кешированием управляет не приложение, а ядро ОС. Если речь о MSDOS, то можно и напрямую с диска читать.

Под буферизированным вводом-выводом обычно понимают буферизацию уровня приложения или библиотеки.
В этом случае небуферизированный IO - интерфейс с операционной системой и функции-обертки из стандартной библиотеки. Для винды это: ReadFile и read. Прочие библиотечные функции, обычно, буферизированные: fread, методы классов fstream.

[qknife]

Речь идет именно об винде, т.к. задание дал по применению многопоточности на Borland C++ 5. Суть задачи засечь разницу во времени обработки N файлов без многопоточности и с ней. Буферизация по мнению препода заметно повлияет на результат. Может он просто имел ввиду запрет на использование экстрактора.
По-видимому надо будет использовать ReadFile или read.
Тогда еще вопрос, read (который среди методов класса istream), он также использует буфер? или все таки использовать WinApi функции?

[qknife]

По-видимому, проще будет использовать read (fread конечно удобнее, но в документации написано, что буферизуется). Указано, что read используется именно для низкогоуровневого доступа: "При  работе  функции  с устройствами,     байты     данных  считываются непосредственно с устройства".

Боюсь только, чтобы препод не заявил, что функция то не поддерживается ANSI C (

[Вад]

Ага, а также повлияет то, что скорость чтения нескольких файлов с диска будет зависеть от взаимного расположения на диске, и позиционирование головки при вращении диска будет оптимизироваться контроллером. Из-за чего физическая скорость чтения будет совершенно непредсказуемая

[qknife]

в общем решил юзать read (или аналог для ДОСа _read). Файлы будут в тестах одни и те же, так что взаимное расположение одинаково )). Надеюсь прокатит. Спс за советы

[Вад]

qknife, не, я не про то. Взаимное расположение файлов повлияет на то, насколько большими будут задержки при параллельном поочерёдном чтении из них. Чем больше дистанция - тем выше латентность. Но не линейно, а как повезёт - читай, как контроллер очередь запросов на чтение соптимизирует. Читать много файлов сразу и без кэша - значит, резко снизить суммарную физическую скорость чтения с диска. Раза в 2 наверняка, а то и больше.

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

Что-то сомневаюсь я в чистоте такого эксперимента. Вот если бы файлы все на разных дисках находились - тогда ещё может быть...

[qknife]

Да, пожалуй ты прав. О чистоте эксперимента говорить не получится. Но думаю главное показать, что программа работает и думаю все таки многопоточный вариант программы "обскочит" однопоточного брата. В случае же "неудовлетворения" препода результатами смогу сослаться на то, что знающие люди объяснили почему результаты именно таковы. Думаю зачтется такая активность

[Вад]

qknife, он обскачет, если обработка файлов будет медленнее, чем чтение. Если взять, скажем, физическую скорость чтения с диска в 60МБ/с, то при скорости обработки данных по 5-10 МБ/с эффект от многопоточности, думаю, будет в любом случае заметен на >1 процессора.

[McZim]

qknife,

1. Нет не обскочит, ты пойми что даже если у тебя программа многопоточна, то HDD все равно однопоточен.
2. У меня есть друг, очень хороший прогер, так вот он пишет сервера для на линукс системах и он однопоточные сервера делает в разы быстрее чем некоторые программисты делающее многопоточные. Это я к тому что написав программу по учебнику не факт что она быстро будет работать, слишком много нужно учитывать что бы реально добиться производительности.

[Вад]

McZim, там ещё данные обрабатываются. Вдруг там декомпрессия или ещё какой тяжёлый алгоритм?

[McZim]

В задании ничего такого нет, в первом посте ясно написано чтение из файлов.

[Вад]

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

[АлексейК]

В документации по Platform SDK написано, что перед чтением без буферизации, надо использовать функцию CreateFile с установленным

флагом FILE_FLAG_NO_BUFFERING для открытия файла.

[qknife]

в общем выполнил задание, используя read. Многопотоковый вариант выполняется раза в 4 быстрее. Спасибо всем

[McZim]

qknife, ну скорость это спорно, потому как (есть ли промежуточные вычисления или это просто ввод/вывод? читаешь одни и теже данные? чем скорость проверял?)