Форум программистов «Весельчак У»
  *
Добро пожаловать, Гость. Пожалуйста, войдите или зарегистрируйтесь.
Вам не пришло письмо с кодом активации?

  • Рекомендуем проверить настройки временной зоны в вашем профиле (страница "Внешний вид форума", пункт "Часовой пояс:").
  • У нас больше нет рассылок. Если вам приходят письма от наших бывших рассылок mail.ru и subscribe.ru, то знайте, что это не мы рассылаем.
   Начало  
Наши сайты
Помощь Поиск Календарь Почта Войти Регистрация  
 
Страниц: [1]   Вниз
  Печать  
Автор Тема: Буферизованный и небуферизованный ввод-вывод  (Прочитано 23794 раз)
0 Пользователей и 1 Гость смотрят эту тему.
qknife
Гость
« : 17-12-2008 15:18 » 

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

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

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

ru
Offline Offline
Пол: Мужской
Я странный


WWW
« Ответ #1 : 17-12-2008 16:57 » 

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

The CBO without stats is like a morning without coffee. (c) T.Kyte.
RXL
Технический
Администратор

ru
Offline Offline
Пол: Мужской

WWW
« Ответ #2 : 17-12-2008 17:09 » 

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

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

... мы преодолеваем эту трудность без синтеза распределенных прототипов. (с) Жуков М.С.
qknife
Гость
« Ответ #3 : 17-12-2008 17:29 » 

Речь идет именно об винде, т.к. задание дал по применению многопоточности на Borland C++ 5. Суть задачи засечь разницу во времени обработки N файлов без многопоточности и с ней. Буферизация по мнению препода заметно повлияет на результат. Может он просто имел ввиду запрет на использование экстрактора.
По-видимому надо будет использовать ReadFile или read.
Тогда еще вопрос, read (который среди методов класса istream), он также использует буфер? или все таки использовать WinApi функции?
Записан
qknife
Гость
« Ответ #4 : 17-12-2008 17:44 » 

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

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

ru
Offline Offline
Пол: Мужской

« Ответ #5 : 17-12-2008 17:45 » 

Ага, а также повлияет то, что скорость чтения нескольких файлов с диска будет зависеть от взаимного расположения на диске, и позиционирование головки при вращении диска будет оптимизироваться контроллером. Из-за чего физическая скорость чтения будет совершенно непредсказуемая Улыбаюсь
« Последнее редактирование: 17-12-2008 17:49 от Вад » Записан
qknife
Гость
« Ответ #6 : 17-12-2008 17:50 » 

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

ru
Offline Offline
Пол: Мужской

« Ответ #7 : 17-12-2008 17:55 » 

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

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

Что-то сомневаюсь я в чистоте такого эксперимента. Вот если бы файлы все на разных дисках находились - тогда ещё может быть...
« Последнее редактирование: 17-12-2008 17:58 от Вад » Записан
qknife
Гость
« Ответ #8 : 17-12-2008 18:09 » 

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

ru
Offline Offline
Пол: Мужской

« Ответ #9 : 17-12-2008 18:13 » 

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

ru
Offline Offline
Пол: Мужской
Я странный


WWW
« Ответ #10 : 17-12-2008 19:04 » 

qknife,

1. Нет не обскочит, ты пойми что даже если у тебя программа многопоточна, то HDD все равно однопоточен.
2. У меня есть друг, очень хороший прогер, так вот он пишет сервера для на линукс системах и он однопоточные сервера делает в разы быстрее чем некоторые программисты делающее многопоточные. Это я к тому что написав программу по учебнику не факт что она быстро будет работать, слишком много нужно учитывать что бы реально добиться производительности.
« Последнее редактирование: 17-12-2008 19:05 от McZim » Записан

The CBO without stats is like a morning without coffee. (c) T.Kyte.
Вад
Модератор

ru
Offline Offline
Пол: Мужской

« Ответ #11 : 17-12-2008 19:12 » 

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

ru
Offline Offline
Пол: Мужской
Я странный


WWW
« Ответ #12 : 17-12-2008 20:29 » 

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

The CBO without stats is like a morning without coffee. (c) T.Kyte.
Вад
Модератор

ru
Offline Offline
Пол: Мужской

« Ответ #13 : 17-12-2008 20:33 » 

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

ru
Offline Offline
Пол: Мужской

« Ответ #14 : 17-12-2008 22:41 » 

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

флагом FILE_FLAG_NO_BUFFERING для открытия файла.
« Последнее редактирование: 18-12-2008 08:30 от АлексейК » Записан
qknife
Гость
« Ответ #15 : 19-12-2008 16:59 » 

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

ru
Offline Offline
Пол: Мужской
Я странный


WWW
« Ответ #16 : 20-12-2008 11:09 » new

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

The CBO without stats is like a morning without coffee. (c) T.Kyte.
Страниц: [1]   Вверх
  Печать  
 

Powered by SMF 1.1.21 | SMF © 2015, Simple Machines