Russian Qt Forum

Добрый вечер

Есть вспомогательные расчеты которые выполняются одинаково неск раз. Естественно желание слить результаты на диск и потом грузить вместо того чтобы считать повторно. Но как это сделать для 2 или более ниток?

Порядок такой: есть массив матриц 9x9 пикселей, на них натравливается заданное число ниток N. Ок, посчитали начали след фазу (опять те же матрицы N нитками), опять требуется вспомогательный расчет что уже был на предыдущем шаге. Хммм.. и как загрузить?

Спасибо

Что-то как-то не очень понятно расписано. Сделай класс для хранения результатов, и сделай его синглтоном. При запуске проги пусть загружает все данные из файла, при закрытии сохраняет в файл.

Речь идет о выполнении серии расчетов на 1 запуске. Псевдокод

C++ (Qt)
// первый шаг
#pragma omp parallel for
for (int i = 0; i < matr.size(); ++i) {
 CalcLayers(matr[i]);
 CalcBounds(matr[i]);
}
 
//... какой-то не параллельный код
 
// второй шаг
#pragma omp parallel for
for (int i = 0; i < matr.size(); ++i) {
 CalcLayers(matr[i]);   // опять нужен CalcLayers и он даст те же результаты что и на шаге 1
 CalcInterior(matr[i]);
}
 

C++ (Qt)
// первый шаг
#pragma omp parallel for
for (int i = 0; i < matr.size(); ++i) {
 data = CalcLayers(matr[i]);
 SaveLayers( i, data );    // сохранили во внешнем хранилище данные, ключом является индекс
 CalcBounds(matr[i]);
}
 
//... какой-то не параллельный код
 
// второй шаг
#pragma omp parallel for
for (int i = 0; i < matr.size(); ++i) {
 data = ReadLayers( i );   // читаем из внешнего хранилища данные для нужного индекса
 CalcInterior(matr[i]);
}
 

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

Вот так я и хочу. Правда фиксированной длины не получится, но не суть. Проблема в том что это работает только для 1 нитки  - тогда порядок чтения совпадает с записью. Но что делать если ниток 2 или более и они пишут/читают как/когда хотят ???

Ты можешь свободно перемещаться по файлу с помощью seek. Одной нитке нужна запись с индексом 12 - переместились в то место файла и прочитали, второй с индексом 47 - переместились, прочитали.

Это очевидно, но даже по самым примерным прикидкам - мрачно. seek сбросит кэш файла, имеем некэшированный I/O который к тому же надо лочить. Обойдется дороже чем пересчитать. Думаю как бы соорудить свой файл для каждой нитки...

А ты его размапь в память.

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

Можно мапить нужными в данный момент области файла, окнами не большого размера.

Порядок расчета важен?

Написав parallel мы соглашаемся что вычисления могут выполняться в любом порядке

Ну ReadIndex/Layers придется защитить, но не вижу никакой ошибки. Спасибо

Это для linux (думаю также будет работать и под маком), под венду переделывается за пару минут.

C++ (Qt)
#include <QCoreApplication>
#include <QtConcurrentMap>
#include <QFutureWatcher>
#include <QFile>
#include <QThread>
#include <QDebug>
#include <sys/mman.h>
#include <unistd.h>
#include <errno.h>
 
static const int count = 10000;
static const int bufSize = sizeof( int );
 
static int pageSize;
 
struct Data
{
	int			handle;
	int			index;
};
 
bool writeData( const Data &data )
{
	qDebug() << "Process index = " << data.index << "( thread id =" << QThread::currentThreadId() << ")";
 
	off_t offsetHi = (data.index * bufSize) / pageSize;
	off_t offsetLo = (data.index * bufSize) % pageSize;
 
	void *address = mmap( 0, pageSize + bufSize, PROT_WRITE, MAP_SHARED, data.handle, offsetHi * pageSize );
	if( address == MAP_FAILED )
	{
		qDebug() << "mmap error" << errno;
		return false;
	}
 
	int *dst = static_cast<int *>( address + offsetLo );
	*dst = data.index;
 
	munmap( address, pageSize + bufSize );
 
	return true;
}
 
bool readData( const Data &data )
{
	off_t offsetHi = (data.index * bufSize) / pageSize;
	off_t offsetLo = (data.index * bufSize) % pageSize;
 
	void *address = mmap( 0, pageSize + bufSize, PROT_READ, MAP_SHARED, data.handle, offsetHi * pageSize );
	if( address == MAP_FAILED )
	{
		qDebug() << "mmap error" << errno;
		return false;
	}
 
	int *src = static_cast<int *>( address + offsetLo );
	qDebug() << "Check index = " << data.index << (( *src == data.index )? "Ok" : "Error");
 
	munmap( address, pageSize + bufSize );
 
	return true;
}
 
int main( int argc, char *argv[] )
{
	QCoreApplication app( argc, argv );
 
	pageSize = sysconf( _SC_PAGESIZE );
 
	QFile file( "data.bin" );
	if( !file.open( QIODevice::ReadWrite ) )
	{
		qWarning() << "File open error";
		return 1;
	}
	file.resize( bufSize * count );
 
	QList<Data> data;
	for( int i = 0; i < count; ++i )
	{
		Data d;
		d.handle = file.handle();
		d.index = i;
		data.append( d );
	}
 
	qDebug() << "Write";
	QFutureWatcher<bool> writer;
	writer.setFuture( QtConcurrent::mapped( data, writeData ) );
	writer.waitForFinished();
 
	qDebug() << "Read";
	QFutureWatcher<bool> reader;
	reader.setFuture( QtConcurrent::mapped( data, readData ) );
	reader.waitForFinished();
 
	return 0;
}
 

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

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

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

Два системный вызова это конечно перебор, посмотрим на твое решение.
Судя по этому:
оно будет заметно проще.

По поводу страниц. 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 куда проще и выгоднее.

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

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

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

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

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

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

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

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

возню  :)

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

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

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

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

Вот о чем:


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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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