Запись в файл

[Igors]

Что значит не предсказуемый? Кем не предсказуемый? В примере все размеры указаны. Размер окна чуть больше размера страницы на каждый поток (реально будет использоваться две), не много правда?

По поводу страниц. CalcLayers (условное название) разделяет исходное множество (матрица точек) на серию подмножеств, каждое из которых должно обрабатываться отдельно.Более подробный псевдокод

Код

C++ (Qt)
#pragma omp parallel for
for (int i = 0; i < matr.size(); ++i) {
 CLayer * layer = CalcLayers(matr[i]);
 while (layer) {
  DoCalcLayer(layer);
  layer = layer->mNext;
 }
}
 

Число layers может быть очень разным - часто всего 1-2, но иногда и сотни. С числом точек в layers то же самое - от нуля до тысяч.

Отсюда ясно что гранулярность "как получится" и разбить по страницам не удастся, придется хранить начало+размер и.т.д. Не смертельно, но возня. Впрочем "постранично или нет" здесь непринципиально - все равно не годится

Тебе стоит разобраться с работай разделяемой памяти на уровне системы.

Ну вот, опять Вас понесло "учительствовать" - вместо того чтобы просто нормально обсуждать    Тем более разбираться тут особо нечего. Создав shared файл мы тем самым даем ОС рулить, и как он будет это делать - неизвестно. Может просто будет держать весь файл в памяти (пока хватает), может только куски (с каким-то пулом). Во всяком случае не стоит надеяться что мы бесплатно поимеем большое виртуальное пр-во и что "большой и умный кэш" за нас все сделает. Это непредсказуемо - и часто неприемлемо. Получив какие-то данные (напр на основании Вашего примера) мы можем счесть их пригодными, но при др раскладе производительность может быть уже совершенно иной. Очень быстро "затраты только на замеры" превысят время на собственно решение   Поэтому простой вариант предложенный evd куда проще и выгоднее.

[V1KT0P]

Число layers может быть очень разным - часто всего 1-2, но иногда и сотни. С числом точек в layers то же самое - от нуля до тысяч.

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

[Igors]

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

Ну если я (зачем-то) хочу слить просчитанные данные на диск, а затем их (пере)загрузить - то наверное же меня (почему-то) не устроило оставить их в памяти. Лучше исходить из того что все достаточно грамотны - разжевывание очевидных вещей ни к чему.

[BRE]

Отсюда ясно что гранулярность "как получится" и разбить по страницам не удастся, придется хранить начало+размер и.т.д. Не смертельно, но возня. Впрочем "постранично или нет" здесь непринципиально - все равно не годится

Возня, а ты сохраняя их в обычный файл минуешь эту вознь? Что так, что так все равно придется поработать. А по-страницам разбивать действительно не нужно.

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

А что еще остается делать? Если ты пытаешься рассуждать о вещах о которых не имеешь понятия.

Создав shared файл мы тем самым даем ОС рулить, и как он будет это делать - неизвестно. Может просто будет держать весь файл в памяти (пока хватает), может только куски (с каким-то пулом). Во всяком случае не стоит надеяться что мы бесплатно поимеем большое виртуальное пр-во и что "большой и умный кэш" за нас все сделает.

Скажу тебе по секрету, что если ты просто откроешь файл и будешь записывать/читать по одному байтику (что бы сэкономить память), ОС будет буферизировать весь этот файл в памяти. Причем она будет стараться хранить его как можно большую часть. Ну и самое смешное, она будет это делать, занимая реальную (физическую) память. Резюмируя, могу сказать что расходы по памяти: что просто читать/писать файл , что его мапить будут одинаковыми. Все это касается физической памяти.
А и еще маленький момент, ОС пытается использовать для буферов ввода/вывода всю свободную физическую память. Это нормально.

Ты же пытаешься экономить виртуальную память, только не понятно для чего, ты хочешь увеличить число доступных буферов ввода/вывода для ОС. Похвально.  

[V1KT0P]

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

Ну если я (зачем-то) хочу слить просчитанные данные на диск, а затем их (пере)загрузить - то наверное же меня (почему-то) не устроило оставить их в памяти. Лучше исходить из того что все достаточно грамотны - разжевывание очевидных вещей ни к чему.

Ну так как насчет хранить данные в другом компе и получать их по сети? Это ведь прекрасно вписывается в распараллеливание. Сделай сервер который будет управлять клиентами: давать задания и получать результаты. Этот сервер точно будет занимать мало памяти.

[Igors]

Ну так как насчет хранить данные в другом компе и получать их по сети? Это ведь прекрасно вписывается в распараллеливание. Сделай сервер который будет управлять клиентами: давать задания и получать результаты. Этот сервер точно будет занимать мало памяти.

Ой мама!    Получать данные по сети - когда кластер (тело for) исчисляется миллисекундами и меньше? 

Возня, а ты сохраняя их в обычный файл минуешь эту вознь?.

возню 

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

буферизировать весь? Неправда, только (небольшую) часть, в этом легко убедиться в профайлере 

Резюмируя, могу сказать что расходы по памяти: что просто читать/писать файл , что его мапить будут одинаковыми. Все это касается физической памяти.

Хмм.. ну "соразмеримыми". Но дело в том как читать: подряд (быстро) или прыгать seek'ом (медленно). И здесь shared файл не есть решение проблемы

Ты же пытаешься экономить виртуальную память, только не понятно для чего, ты хочешь увеличить число доступных буферов ввода/вывода для ОС. Похвально. 

Да я об этом и не помышлял  А дать каждой нитке по файлу - прием известный

А что еще остается делать? Если ты пытаешься рассуждать о вещах о которых не имеешь понятия.

О чем же таком я рассуждаю что не имею понятия? Что неправильного/неграмотного я сказал? И что такого умного сказали Вы что мне следовало бы поучиться? Откуда такое настойчивое желание взять на понт?

[BRE]

О чем же таком я рассуждаю что не имею понятия? Что неправильного/неграмотного я сказал? И что такого умного сказали Вы что мне следовало бы поучиться? Откуда такое настойчивое желание взять на понт?

Вот о чем:

Неправда, только (небольшую) часть, в этом легко убедиться в профайлере 

Ты даже не понял про какие буферы идет речь. Ты не разделяешь физическую и виртуальную память, но пытаешься что-то экономить. Еще раз, ОС использует всю свободную память для хранения буферов ввода/вывода и если у нее была бы возможность (неограниченная RAM) - она бы туда загрузила все все все.

Хмм.. ну "соразмеримыми". Но дело в том как читать: подряд (быстро) или прыгать seek'ом (медленно). И здесь shared файл не есть решение проблемы

У тебя все традиционно, сказать банальную фразу и сделать непонятно откуда следующий вывод, главное пафосно.

[V1KT0P]

Ой мама!    Получать данные по сети - когда кластер (тело for) исчисляется миллисекундами и меньше? 

При чтении с обычного диска задержка вроде как равняется 5-10 мс. Через локальную сеть я думаю можно и быстрее получить.

[Igors]

Ты даже не понял про какие буферы идет речь. Ты не разделяешь физическую и виртуальную память, но пытаешься что-то экономить. Еще раз, ОС использует всю свободную память для хранения буферов ввода/вывода и если у нее была бы возможность (неограниченная RAM) - она бы туда загрузила все все все.

Чего Вы "с больной головы на здоровую"?    Разговор о простой вещи

- вариант 1: читаем файл подряд кусок за куском (напр по 256К)
- вариант 2: перед каждым чтением делаем seek и читаем байт сколько нам надо

Всякому кто имеет хоть небольшой опыт ясно - вариант 2 намного медленнее. Вы предлагаете использовать shared файл - это может отличаться от варианта 2 (причем в обе стороны) но в любом случае до варианта 1 далеко.

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

[BRE]

Всякому кто имеет хоть небольшой опыт ясно - вариант 2 намного медленнее. Вы предлагаете использовать shared файл - это может отличаться от варианта 2 (причем в обе стороны) но в любом случае до варианта 1 далеко.

Всякому то ясно, а не поделишься почему так происходит? Я знаю что ответа у тебя нет, интересно твое мнение. А потом я поделюсь своим.

[Igors]

Всякому то ясно, а не поделишься почему так происходит? Я знаю что ответа у тебя нет, интересно твое мнение. А потом я поделюсь своим.

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

[BRE]

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

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

Вот тут начинается интересное, если ты запустишь программу, которая полностью прочитает файл и размер кеша будет позволять, он весь закешируется и при следующем запуске физически уже не будет читаться с диска! Но seek перед чтением (да еще со своей буферизацией) все равно будет тормозить! Что за фигня спросишь ты, а давай смотреть дальше....

В стандартной библиотеке есть группа функции для работы с файлами с буферизацией (fopen, fread, fwrite, fseek, ...). Пусть весь файл уже находиться в дисковом кеше, т.е. физического чтения с диска не будет. Мы делаем fseek, и пытаемся читать байт, но функция fread прочитает не указанное количество, а с запасом - заполнит весь буфер. Мы прочитали один байт и сделали seek в другое место, нам нужен еще один байт, а прочитается опять буфер значительно большего размера. Т.е. основная задержка вызвана постоянным копированием данных из пространства ядра (не дешевая кстати операция). Поэтому, при таком подходе, отключение буферизации могла увеличить скорость чтения.

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

[Igors]

BRE, спасибо за разъяснения. Избегаю цитат чтобы покороче

С эффектом кэширования всего файла знаком, это конечно здорово, но важно отметить - это все-таки личное дело ОС, зависящее от конкретной обстановки. Управлять этим - у меня не очень получается http://www.prog.org.ru/index.php?topic=20063.msg135896#msg135896.

Да, маппинг работает в рамках обычной подкачки страниц (грубо говоря), что может быть ощутимо быстрее, Но если делать на каждом вызове map/unmap (как Вы написали) то расходы на установку маппинга как бы не были больше. А если мапить один раз, то мапится много страниц - "вынь и положь". И они могут вытеснить  др страницы, которые тоже нужны (мне же). Я немного экспериментировал, могу сказать: пока есть ресурсы - все отлично. Но как только физическая память заканчивается - тормоза ужасны, а Вындоуз вообще уже не встает 

Поэтому с точки зрения регулярного/безопасного решения мне лучше прочитать файл последовательно - такая возможность есть

[BRE]

Но если делать на каждом вызове map/unmap (как Вы написали) то расходы на установку маппинга как бы не были больше.

А ты не планируешь читать/писать файл на каждой итерации?

P.S. Я ни в коем случае не навязывая это решение, более того мне абсолютно все равно как это будет решено/не решено в дальнейшем.