Легенда:
 новое сообщение
 закрытая нитка
 новое сообщение
 в закрытой нитке
 старое сообщение
|
- Напоминаю, что масса вопросов по функционированию форума снимается после прочтения его описания.
- Новичкам также крайне полезно ознакомиться с данным документом.
| | | | | | | | | | | |
А кстати ещё лучшее замечание... 18.04.04 04:19 Число просмотров: 1834
Автор: void <Grebnev Valery> Статус: Elderman
|
... разумеется Ваше, уважаемый, amirul.
> А мне вообще кажется, что оптимизации в общем случае не
> бывает. Всегда есть граничные случаи (стремление к нулю и
> бесконечности) и срединный (или несколько участков). И надо
> оптимизировать именно под тот случай, который ожидается при
> работе данной и конкретной системы.
Ну, а это кстати вообще блестяще. Серьёзно. Давно (лет 15-20) не встречал верного отношения к решению экстремальных задач (связанны с нахождением экстремума).
ПС. И спасибо за инфу в части мапинга. Думаю, будет полезным.
|
|
<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
На мой взгляд предмет описан гораздо лучше, чем у шрайбера и они вместе взятых.
Ему надо бы предложить статьи для багтрака причесать - думаю рейтинг будет хороший.
|
|
|
подробно о проекте
Анализ криптографических сетевых...
