информационная безопасность
без паники и всерьез
 подробно о проектеRambler's Top100
Сетевые кракеры и правда о деле ЛевинаАтака на InternetВсе любят мед
BugTraq.Ru
Русский BugTraq
 Анализ криптографических сетевых... 
 Модель надежности двухузлового... 
 Специальные марковские модели надежности... 
 Три миллиона электронных замков... 
 Doom на газонокосилках 
 Умер Никлаус Вирт 
главная обзор RSN блог библиотека закон бред форум dnet о проекте
bugtraq.ru / форум / programming
Имя Пароль
ФОРУМ
если вы видите этот текст, отключите в настройках форума использование JavaScript
регистрация





Легенда:
  новое сообщение
  закрытая нитка
  новое сообщение
  в закрытой нитке
  старое сообщение
  • Напоминаю, что масса вопросов по функционированию форума снимается после прочтения его описания.
  • Новичкам также крайне полезно ознакомиться с данным документом.
[C++] Нет. Или mmap или буфер 17.04.04 01:24  Число просмотров: 2152
Автор: amirul <Serge> Статус: The Elderman
<"чистая" ссылка>
mmap все сделает сам. Ну а с буфером может и можно добиться бОльшего контроля над ситуацией (если запретить винде собственную буферизацию), но тут нужно еще и хорошо понимать что и почему происходит
<programming>
[C++] Оптимизации чтения данных з файла... 16.04.04 00:15  
Автор: CrazyPitbull Статус: Незарегистрированный пользователь
<"чистая" ссылка>
Давно хотел проконсультироваться, читаю данные из файла, затем их обрабатываю, так вот, если сделать некоторый буфер и читать большой кусок а потом его обрабатывать это будет быстрее чем если читать посимвольно из файла...
Вообще сделав так получилось, что быстрее, но может это просто обман зрения???
[C++] кроме того, если речь о win32... 16.04.04 10:44  
Автор: dl <Dmitry Leonov>
<"чистая" ссылка>
... то стоит попробовать реализацию с memory map files, очень часто они оказываются быстрее самопальных буферов.
Для большинства задач это будет наиболее оптимальным... 16.04.04 12:25  
Автор: DPP <Dmitry P. Pimenov> Статус: The Elderman
<"чистая" ссылка>
> ... то стоит попробовать реализацию с memory map files,
> очень часто они оказываются быстрее самопальных буферов.
Для большинства задач это будет наиболее оптимальным решением. Однако - не идеал. При последовательной обработке возникнет необходимость подчитывания по кускам. Если в промежутках времени кусочного подчитывания будут запросы другой задачи на чтения из дальней области накопителя, то время обработки файла может упасть раз в десять, чем считывание за раз. А изменения - как часто они будут скидываться в файл (обновление). Плохо как при завершении работы с ним, как и слишком часто. Ну и естественно такой недостаток как непереносимость (зависимость от ОС).
естественно, надо смотреть в каждом конкретном случае 16.04.04 13:01  
Автор: dl <Dmitry Leonov>
<"чистая" ссылка>
> Для большинства задач это будет наиболее оптимальным
> решением. Однако - не идеал. При последовательной обработке
> возникнет необходимость подчитывания по кускам. Если в

Ну так file mapping работает со страницами, а 4к - это достаточно большой кусок по сравнению с побайтовым считыванием. Опять же, при желании действительно можно пройтись по буферу с интервалом в 4к, чтоб гарантированно заставить страницы попасть в физическую память, но лично мне этим никогда не приходилось заниматься.

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

Если нет доверия к тому, как эти моменты выбирает система, всегда можно вызвать FlushViewOfFile.

> Ну и естественно такой
> недостаток как непереносимость (зависимость от ОС).

Это да, но при изначальной установке на многоплатформенность можно сделать обертку, использующую на каждой платформе наиболее эффективное решение.
При считывании за раз данные сначала попадают в буфер, а... 16.04.04 12:31  
Автор: amirul <Serge> Статус: The Elderman
<"чистая" ссылка>
> возникнет необходимость подчитывания по кускам. Если в
> промежутках времени кусочного подчитывания будут запросы
> другой задачи на чтения из дальней области накопителя, то
> время обработки файла может упасть раз в десять, чем
> считывание за раз. А изменения - как часто они будут
При считывании за раз данные сначала попадают в буфер, а потом копируются в юзерскую память. Меппинг же сразу читает в страницу, а она потом вставляется в юзерский Working Set. Если предполагаются проблемы с последовательным чтением, то можно пройтись по куску файла и сделать по одному обращению через каждые 4 килобайта - время такого чтения будет соизмеримо со считыванием в буфер (скорее всего даже меньше).

> скидываться в файл (обновление). Плохо как при завершении
> работы с ним, как и слишком часто. Ну и естественно такой
> недостаток как непереносимость (зависимость от ОС).
Насколько я помню в виндах (да и в других) используется отложенная запись. "Грязные" страницы скидываются на диск одним пакетом раз в сколько то там секунд (порядка полминуты).
Всё очень сильно зависит от хардверной части. Например, для... 16.04.04 23:25  
Автор: void <Grebnev Valery> Статус: Elderman
<"чистая" ссылка>
> Насколько я помню в виндах (да и в других) используется
> отложенная запись. "Грязные" страницы скидываются на диск
> одним пакетом раз в сколько то там секунд (порядка
> полминуты).

Всё очень сильно зависит от хардверной части. Например, для ряда SCSII - адаптеров винда будет делать ровно то, что отконфигурировано при помощи SCSII. На моём маленьком опыте.
Ну на интел-базед платформах под управлением Микрософт... 16.04.04 12:55  
Автор: DPP <Dmitry P. Pimenov> Статус: The Elderman
<"чистая" ссылка>
> При считывании за раз данные сначала попадают в буфер, а
> потом копируются в юзерскую память. Меппинг же сразу читает

Ну на интел-базед платформах под управлением Микрософт Виндоус может и так, на хороших системах данные перекладываются с диска и пользовательскую память аппаратно.

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

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

> Насколько я помню в виндах (да и в других) используется
> отложенная запись. "Грязные" страницы скидываются на диск
> одним пакетом раз в сколько то там секунд (порядка
> полминуты).

Много ли это или мало?
Не факт. Хотя бы тот факт, что аппаратно можно работать... 16.04.04 13:16  
Автор: amirul <Serge> Статус: The Elderman
Отредактировано 16.04.04 13:18  Количество правок: 1
<"чистая" ссылка>
> Ну на интел-базед платформах под управлением Микрософт
> Виндоус может и так, на хороших системах данные
> перекладываются с диска и пользовательскую память
> аппаратно.
Не факт. Хотя бы тот факт, что аппаратно можно работать только с секторами, а файловые операции производить побайтно говорит о буферизации.

> А при обращении к последним страницам содержимое первых
> точно останется в памяти?
А при полном считывании останется ли все в памяти? Working Set для юзерских процессов точно так же ограничен. Только в данном случае путь данных будет выглядеть так: системный буфер - юзерская память - мэппинг в своп - а далее все точно так же как и с меппингом прямо из файла (подкачка при необходимости). Винда просто не даст процессу иметь больше физических страниц, чем позволено квотами. А будут это просто страницы виртуальной памяти или страницы меппинга - ее уже мало волнует. Меппинг в этой ситуации выигрывает еще и тем, что пока страница чистая никакой записи не требуется (а для сброса страницы в своп - надо)

> А при считывании первого куска и последующих (несколько
> милисекунд) другие задачи не поставят ли в очередь свои
> запросы на чтение/запись из дальних уголков винчестера?
А вот этим уже IO-менеджер занимается. Сериализация запросов к винчестеру не юзерская проблема. Кроме того, слыхал я о винтах которые сериализуют запросы аппаратно. Ну и раз уж на то пошло, то полное чтение ничуть не более застраховано от такого положения, чем меппинг. При этом не имея никаких преимуществ.

> Много ли это или мало?
Как уже сказано, можно сделать ручной flush.
У RSX-11 не было системных вызовов на чтение одного байта из... 16.04.04 14:01  
Автор: DPP <Dmitry P. Pimenov> Статус: The Elderman
<"чистая" ссылка>
> Не факт. Хотя бы тот факт, что аппаратно можно работать
> только с секторами, а файловые операции производить
> побайтно говорит о буферизации.

У RSX-11 не было системных вызовов на чтение одного байта из файла, минимум - сектор.

> А при полном считывании останется ли все в памяти? Working
> Set для юзерских процессов точно так же ограничен. Только в
Опять Виндовс...
> данном случае путь данных будет выглядеть так: системный
> буфер - юзерская память - мэппинг в своп - а далее все
Ну, хорошо, выделили в файловом кеши буфер, закачали инфой, потом мовнуть в область памяти пользовательской задачи - это же смешное время по сравнению с чтением с носителя.
> точно так же как и с меппингом прямо из файла (подкачка при
> необходимости). Винда просто не даст процессу иметь больше
> физических страниц, чем позволено квотами. А будут это
Игрался я с Экселем, когда он отжирал всю свободную память - ничего не своповалось.
> просто страницы виртуальной памяти или страницы меппинга -
> ее уже мало волнует. Меппинг в этой ситуации выигрывает еще
> и тем, что пока страница чистая никакой записи не требуется
> (а для сброса страницы в своп - надо)
Ну есть у него преимущества при определенных условиях.
> А вот этим уже IO-менеджер занимается. Сериализация
> запросов к винчестеру не юзерская проблема. Кроме того,
Откуда система знает - возжелает ли пользовательская задача в следующую милисекунду читать из смежного вектора или нет.
> слыхал я о винтах которые сериализуют запросы аппаратно. Ну
Вроде как все скайзевые, ИДЕшники пока не умеют.
> и раз уж на то пошло, то полное чтение ничуть не более
> застраховано от такого положения, чем меппинг. При этом не
> имея никаких преимуществ.
Более естественно удовлетворить запрос целиком, все равно передавать обратно в задачу управление следует после полного окончания отработки запроса.
И что в этом хорошего? 16.04.04 15:23  
Автор: amirul <Serge> Статус: The Elderman
<"чистая" ссылка>
> У RSX-11 не было системных вызовов на чтение одного байта
> из файла, минимум - сектор.
Сабж

> > А при полном считывании останется ли все в памяти?
> Working
> > Set для юзерских процессов точно так же ограничен.
> Только в
> Опять Виндовс...
Просто его я знаю лучше всего. Ну квотирование количества физической памяти, доступной пользовательскому процессу насколько я помню есть и в *NIX-ах

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

> Игрался я с Экселем, когда он отжирал всю свободную память
> - ничего не своповалось.
Не помню уж точных критериев винды (а у других я и не знал никогда), но насколько я помню все зависит как от количества этой самой физической памяти, так и от количества процессов. Но лимиты ТОЧНО есть - если интересно могу поискать документацию

> Откуда система знает - возжелает ли пользовательская задача
> в следующую милисекунду читать из смежного вектора или нет.
Ну это пока ничего не читается можно сразу же кидаться исполнять а пока все равно делать не фиг (позиционирование идет или чтение) - можно и пособирать запросы

> Более естественно удовлетворить запрос целиком, все равно
> передавать обратно в задачу управление следует после
> полного окончания отработки запроса.
Ну тут да, какие то незаметные преимущества могут быть, но опять таки в крайне редких случаях: если я запускаю две задачи, требующие активной работы с большими объемами данных на разных концах винчестера, то виноват все таки я, а не система или программист, писавший запускаемые программы. Ибо даже если программу или систему можно заточить под такие вот частные случаи, то все равно толк от них будет крайне редко, а на штатное исполнение влиять будет
Не говорю, что это метод лишен недостатков. Просто как... 16.04.04 16:18  
Автор: DPP <Dmitry P. Pimenov> Статус: The Elderman
Отредактировано 16.04.04 16:20  Количество правок: 1
<"чистая" ссылка>
Не говорю, что это метод лишен недостатков. Просто как вариант...
> Сабж
Отсутствие принудительной буферизации на уровне системы может положительно повлиять на производительность ввода/вывода.
> Просто его я знаю лучше всего. Ну квотирование количества
> физической памяти, доступной пользовательскому процессу
> насколько я помню есть и в *NIX-ах
Почти везде, кроме ДОСа.
> Ну да. Только почему бы не кинуть сразу в юзерскую память?
> Кроме того, как я уже сказал, большие файлы даже если их
> считать прямо в память будут мепиться в своп.
Мепиться - не значит сразу своповаться. И очень маленькие туда тоже отмепяться.
> Не помню уж точных критериев винды (а у других я и не знал
> никогда), но насколько я помню все зависит как от
> количества этой самой физической памяти, так и от
> количества процессов. Но лимиты ТОЧНО есть - если интересно
> могу поискать документацию
Главное, чтоб эти лимиты не мешали работать...
> Ну это пока ничего не читается можно сразу же кидаться
> исполнять а пока все равно делать не фиг (позиционирование
> идет или чтение) - можно и пособирать запросы
Я имел в виду, что в процессе чтения первых 4к (семь милисекунд), в первую милисекунду другая пользовательская задача выдаст запрос на чтение другого файла, подумав, может быть, еще две-три милисекунды, Винды все-таки решаться удовлетворить ее запрос. Хотя тормознутость Винды как раз и говорит о том, что после получения запроса на чтение файла, она может еще несколько секунд ждать, собирая другие запросы.
> Ну тут да, какие то незаметные преимущества могут быть, но
> опять таки в крайне редких случаях: если я запускаю две
> задачи, требующие активной работы с большими объемами
> данных на разных концах винчестера, то виноват все таки я,
> а не система или программист, писавший запускаемые
> программы. Ибо даже если программу или систему можно
> заточить под такие вот частные случаи, то все равно толк от
> них будет крайне редко, а на штатное исполнение влиять
> будет
Естественно лучше писать под более типичные случаи, если програмка не одноразовая.
угу, т.е. при работе с большими буферами можно фактически нарваться на тот же mapping, но уже своп-файла, получив двойной объем работы :) 16.04.04 13:44  
Автор: dl <Dmitry Leonov>
<"чистая" ссылка>
Да, да, если такое ПО стало заметно тормозить из-за увеличившегося объема данных стОит втыкнуть еще один модуль памяти и все будет опять летать. 16.04.04 14:15  
Автор: DPP <Dmitry P. Pimenov> Статус: The Elderman
<"чистая" ссылка>
[C++] ====================================================================== 17.04.04 01:14  
Автор: CrazyPitbull Статус: Незарегистрированный пользователь
<"чистая" ссылка>
Таким образом работая в винде типа 2000 или ХР нужно читать в буфер кратностью в кластер, используя memory map files... Это самые конструктивные предложения! Если я упустил какие-то моменты прошу поправить!
P.S:спасибо за активное участие
Читать ничено не надо, просто область памяти будет... 19.04.04 10:21  
Автор: DPP <Dmitry P. Pimenov> Статус: The Elderman
<"чистая" ссылка>
> Таким образом работая в винде типа 2000 или ХР нужно читать
> в буфер кратностью в кластер, используя memory map
Читать ничено не надо, просто область памяти будет отображена в файл. Получается работа с содержимым файла как с памятью. Причем сразу ничего читаться не будет, а по мере обращения - обратились к какому-то байтику, если этот фрагмент еще не подчитан из файла, то ОС сама его подчитает. Записываться обратно в файл будут только те фрагменты, которые были изменены в памяти.
> files... Это самые конструктивные предложения! Если я
> упустил какие-то моменты прошу поправить!
В любом случае, подведя черту, можно утверждать, что побайтовое чтение файла средствами ОС будет довольно медленным. Значительно быстрее это можно сделать, организовав свою буфферизацию. Наиболее эффективны два метода - чтение всего файла целиком (не лишен недостатков) и отображение файла в память (почти идеален для Виндовс). Чтобы принять окончательное решение каким методом пользоваться следует проанализировать как этот файл будет обрабатываться (последовательно-однопроходно, последовательно-многопроходно, случайный-произвольный доступ...)
Вариант: изваять несколько реализаций и при завершении проекта попробовать собрать с каждым модулем и потестировать.
> P.S:спасибо за активное участие
[C++] Нет. Или mmap или буфер 17.04.04 01:24  
Автор: amirul <Serge> Статус: The Elderman
<"чистая" ссылка>
mmap все сделает сам. Ну а с буфером может и можно добиться бОльшего контроля над ситуацией (если запретить винде собственную буферизацию), но тут нужно еще и хорошо понимать что и почему происходит
А вообще вопрос имеется. 17.04.04 05:31  
Автор: void <Grebnev Valery> Статус: Elderman
<"чистая" ссылка>
> mmap все сделает сам. Ну а с буфером может и можно добиться
> бОльшего контроля над ситуацией (если запретить винде
> собственную буферизацию), но тут нужно еще и хорошо
> понимать что и почему происходит

А вообще вопрос имеется.
По незнанию своему предполагаю, что мапить-то полезно, когда пишут и читают, ну, в оооооооооочень большие файлы (ну, метров 50 -100), да и в случаях когда необходим доступ к данным аля-доступ "в оперативной памяти", ну, как бы, как если бы мы работали с огромными массивами.

Я это к тому, что не слишком ли стало всё запущено в процессе обсуждения, когда ставятся задачи оптимизации в общем случае, как в начале топика.
Хорошее замечание, кстати 17.04.04 13:45  
Автор: amirul <Serge> Статус: The Elderman
<"чистая" ссылка>
> А вообще вопрос имеется.
> По незнанию своему предполагаю, что мапить-то полезно,
> когда пишут и читают, ну, в оооооооооочень большие файлы
> (ну, метров 50 -100), да и в случаях когда необходим доступ
Подозреваю, что в таких случаях даже альтернативы нет. Но вот для 100 килобайтного, к примеру, файлика меппинг тоже не помешает. Хотя если исключить ситуацию с очень жестким режимом использования винта (куча запросов в разных концах), отключить буферизацию винды и слить файл полностью в память, то не думаю, что производительность будет отличаться.
Кстати, в пользу меппинга коротких файлов говорит и то, что винда (да и линух) работает с файлами (в основном исполняемыми образами) исключительно при помощи меппинга.

> к данным аля-доступ "в оперативной памяти", ну, как бы, как
> если бы мы работали с огромными массивами.
Вот тут, наверное, и есть ключевой момент: пока есть альтернатива, лучше делать так, как удобнее.

> Я это к тому, что не слишком ли стало всё запущено в
> процессе обсуждения, когда ставятся задачи оптимизации в
> общем случае, как в начале топика.
А мне вообще кажется, что оптимизации в общем случае не бывает. Всегда есть граничные случаи (стремление к нулю и бесконечности) и срединный (или несколько участков). И надо оптимизировать именно под тот случай, который ожидается при работе данной и конкретной системы.
А кстати ещё лучшее замечание... 18.04.04 04:19  
Автор: void <Grebnev Valery> Статус: Elderman
<"чистая" ссылка>
... разумеется Ваше, уважаемый, amirul.

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

Ну, а это кстати вообще блестяще. Серьёзно. Давно (лет 15-20) не встречал верного отношения к решению экстремальных задач (связанны с нахождением экстремума).

ПС. И спасибо за инфу в части мапинга. Думаю, будет полезным.
Немного о менеджере памяти 18.04.04 15:11  
Автор: amirul <Serge> Статус: The Elderman
<"чистая" ссылка>
> ПС. И спасибо за инфу в части мапинга. Думаю, будет
> полезным.
В свое время совершенно случайно наткнулся на статью о виндовом MM.
http://gl00my.chat.ru/nt/mem.txt

На мой взгляд предмет описан гораздо лучше, чем у шрайбера и они вместе взятых.
Ему надо бы предложить статьи для багтрака причесать - думаю рейтинг будет хороший.
1  |  2 >>  »  




Rambler's Top100
Рейтинг@Mail.ru


  Copyright © 2001-2024 Dmitry Leonov   Page build time: 0 s   Design: Vadim Derkach