Легенда:
 новое сообщение
 закрытая нитка
 новое сообщение
 в закрытой нитке
 старое сообщение
|
- Напоминаю, что масса вопросов по функционированию форума снимается после прочтения его описания.
- Новичкам также крайне полезно ознакомиться с данным документом.
Господа, будьте снисходительны, не бросайтесь сразу штрафовать за, как вам кажется, глупые вопросы - beginners на то и beginners.
| | | | | |
Можно, хотя чуть геморно. Но я сторонник стиля вообще не использовать массивы в программах, что и предложил бы Сергею Косину. 03.08.05 12:50 Число просмотров: 1941
Автор: DPP <Dmitry P. Pimenov> Статус: The Elderman
|
|
|
|
<beginners>
|
Как получить массив другого приложения. 28.07.05 15:12
Автор: Kosin Статус: Незарегистрированный пользователь
|
Здравствуйте.
Я занимаюсь численным моделированием, для расчетов мне не обходимы данные по оптическим свойствам вещества, которые хранятся в файле определенного формата, который я считываю и заполняю массив. Проблема заключается в том, что этот массив имеет размер около 0,5 ГБайта (для полного расчета будет порядка нескольких ГБайт) и загрузка его занимает значительное время, что очень не удобно при отладке программы, необходимо постоянно ждать по несколько минут. Решение этой проблемы я вижу в том, что бы постоянно хранить этот массив в памяти (приложения, потока или чего ни будь еще), а программа расчета просто получала бы этот массив при каждой загрузке.
Вопрос мой такой, посредством чего можно получить этот массив (что почитать). При чем желательно не копировать массив, поскольку это не дает значительного ускорения (а возможно наоборот) так как значительная часть этого массив хранится в свопе, так же этот метод приведет к удвоению занимаемой памяти, что, наверное, не совсем хорошо скажется на производительности. Хорошо бы получать ссылку на этот массив (но у каждой приложениия свое адресное пространство).
Я пишу на Fortran-е, знаю Си.
Возможно, здесь поможет много потоковое приложение. Я немного знаком с MPI может от туда чего ни будь.
|
|
handle = ::globalalloc( gmem_share , size); 05.08.05 07:51
Автор: kstati <Евгений Борисов> Статус: Elderman
|
|
|
|
Реализовал. 04.08.05 15:16
Автор: Kosin Статус: Незарегистрированный пользователь
|
Сделал я проецирование моего файла в память. Проецирование происходит при каждом запуске программы (т.е. без использования второго процесса), инициализация задачи происходит очень быстро (при прямом чтении файла использовалась бесформатная запись). По ощущениям скорость счета не изменилась. В процессе счета появились небольшие притормаживанния (связанные, наверное, с подгрузкой данных) но совершенно не значительные по сравнению со временем счета. Я доволен, отлаживать программу стало значительно приятней и быстрее и еще в придачу счет не тормозит.
Надо будет сравнить скорости счета этих двух вариантов. Пока идет процесс отлавливания ошибок и совершенствования мат. модели, далеко счисть, не удается или ошибка или неустойчивости или вечные двигатели :-). На начальной стадии движение не очень развито, по этому используется только малая часть данных, и свопа нет. При развитом движении программа может за какие-нибудь несколько секунд облазить пол таблицы, тогда, возможно, проявятся какие-нибудь недостатки.
Пока дело до предела адресации не дошло, пока стоит задача показать, что этот метод (уйти от интегрирования по спектру, и избежать повторный расчет, по сути, предварительно все рассчитать) может значительно ускорить расчет при приемлемой точности результатов на модельных задачах.
Вот книга где я нашел о проецировании файлов (на русском), может кому-нибудь будет полезна http://rosigma.chat.ru/richter/ .
Поработал с WIN32 API на Фортране. Кстати есть мнение, что, при всех достоинствах С, для задач численного моделирования Фортран дает более быстрый код чем С.
DPP, а как это без массивов?
Еще раз спасибо за ответы.
|
| |
Просто фортран предназначен для физико-математических... 04.08.05 19:19
Автор: DPP <Dmitry P. Pimenov> Статус: The Elderman
|
> Поработал с WIN32 API на Фортране. Кстати есть мнение, что,
> при всех достоинствах С, для задач численного моделирования
> Фортран дает более быстрый код чем С.
Просто фортран предназначен для физико-математических расчетов. Эффектифность кода у этих языков почти равна и сильно зависит от компилятора, а кодить формулы лучше на фортране :).
> DPP, а как это без массивов?
Возмем, к примеру, задачу: "Файл представляет собой последовательность байт. Требуется подсчитать сколько раз в нем встречается заданный байт". Однозначно проще и быстрее всего будет считать файл в массив и циклично перебрав все байты посчитать количество заданных, чем читать файл побайтно. В последнем случае слишком много накладных расходов - один запрос на прочтение байта может занимать времени столько же, сколько и прочтение сотен или тысяч байт.
Есть задачи, которые на первый взгляд элементарно решаются с использованием массивов и не решаются без них. Возмем, например, такую задачу: "Последовательно вводятся числа. Как только будет введено заданное число (например ноль), нужно вывести второе максимальное число (не самое максимальное, а то, что меньше него, но больше всех остальных)". Сразу хочется написать ввод чисел в массив (со счетчиком количества введеных чисел), упорядочение их по возрастанию (как только будет введен ноль) и выдачу второго элемента массива. Однако непонятно какого объема нужно заводить массив? Вводится может и миллион и милиард и более чисел. Получается, что ее нельзя решить используя массив, даже динамически увеличивающийся, поскольку объем памяти ограничен. Зато легко можно решить не используя массив вообще.
Получаем интересный вывод: "Какой бы большой массив использовался в программе, его может не хватить. Какой бы небольшой массив не использовался в программе, он может быть не использоваться и на один процент за все время эксплуатации программы. Динамическое выделение памяти лишь позволяет эффективнее пользоваться памятью. А задача должна быть универсальна и обрабатывать столько данных, сколько ей подсунули, а не на сколько она расчитана". Иногда лучше последовательно считывать и обрабатывать данные, особенно там, где их можно обработать за один проход, пусть даже в ущерб скорости, если потеря скорости будет не велика.
Причем следует учесть возможности современных ОС. При превом считывании данных из файла весь файл может осесть в кеши и оставаться в нем до выключении компьютера, а передача данных из ОЗУ (файловый кеш) в ОЗУ (переменные программы) достаточно быстра, по сравнению с чтением с накопителя, хотя и больше будет накладных расходов на обращения к ОС при чтении данных.
> Еще раз спасибо за ответы.
|
|
Можно сделать как раз то что ты хочешь. Загрузить свои... 03.08.05 11:20
Автор: Proteus Статус: Незарегистрированный пользователь
|
|
Можно сделать как раз то что ты хочешь. Загрузить свои данные в DLL и сделать в ней расшаренную секцию. У меня такое раньше получалось
|
| |
И будет длл размером гиг 03.08.05 13:10
Автор: Killer{R} <Dmitry> Статус: Elderman
|
Ибо данные в shared секции должны быть инициализированы.
Как уже сказали - файлмэппинг решит все проблемы. Да и шаренная секция это частный случай файлмапы.
|
|
Спасибо за ответы 28.07.05 16:33
Автор: Kosin Статус: Незарегистрированный пользователь
|
Работаю я в Win2k, но, по всей видимости, будет создана модификация этой программы для Linux (с параллельными вычислениями), но пока такая задача не стоит.
Я думаю «File mapping» будет хорошим решением (я уже немного посмотрел), буду разбираться и пробовать реализовать.
Спасибо за ответы! Очень оперативно.
|
| |
Но "скорости" это не добавит. Полюбому файл будет... 02.08.05 12:40
Автор: DPP <Dmitry P. Pimenov> Статус: The Elderman
|
> Я думаю «File mapping» будет хорошим решением (я уже
> немного посмотрел), буду разбираться и пробовать
> реализовать.
Но "скорости" это не добавит. Полюбому файл будет последовательно считан в оперативку. Мало того, по мере нехватки оперативки будет происходить своп, если памяти не слишком много.
А программы самописные или "закрытые"? Может просто их объединить так, чтоб после кода первой выполнялся код второй.
В нормальных операционках должны быть возможности организовать и обмен данными между программами через память, и общие области памяти. С такими штучками баловался еще лет пятнадцать назад, когда Микрософтового Виндовса еще в помине не было. Но у вас я так понял все под Виндовс, а я увы с ним такими вещами не занимался.
> Спасибо за ответы! Очень оперативно.
|
| | |
Еще как добавит. 02.08.05 14:20
Автор: amirul <Serge> Статус: The Elderman
|
> Но "скорости" это не добавит. Полюбому файл будет
> последовательно считан в оперативку. Мало того, по мере
Будет считан один раз и закешированы (если хотя бы один процесс не закроет свой меппинг) самые нужные области этого файла. Повторный запуск произойдет значительно быстрее
> нехватки оперативки будет происходить своп, если памяти не
> слишком много.
Никакого свопа в случае с отмепленными файлами не будет. Если страница чистая - она просто освободится, если грязная - сбросится прямо в тот файл, для которого отмеплена.
> В нормальных операционках должны быть возможности
> организовать и обмен данными между программами через
> память, и общие области памяти. С такими штучками баловался
Ну так меппинг одной и той же области одного и того же файла это и есть расшаривание памяти. Во всех процессах, отмепивших файл будут присутствовать одни и те же страницы.
|
| | | |
Для этого нужен второй процесс для того, чтоб "удерживать"... 02.08.05 17:51
Автор: DPP <Dmitry P. Pimenov> Статус: The Elderman
|
> Будет считан один раз и закешированы (если хотя бы один
> процесс не закроет свой меппинг) самые нужные области этого
> файла. Повторный запуск произойдет значительно быстрее
Для этого нужен второй процесс для того, чтоб "удерживать" мэпинг на момент редактирования основной проги.
Причем, не смортя на внушительный размер, я глубоко сомневаюсь, что тормозит чтение. Предполагаю, что немаловажную роль играет конвертация данных при считывании из этого формата в бинарный массив.
Еще бы посоветовал отлаживать прогу на маленьких объемах данных.
Еще меня шокирует переспективные размеры данных - смогут ли обычные писюки это "прожевать и переварить". Не придется ли переходить на полностью 64 разрядную платформу с огромной памятью.
> Никакого свопа в случае с отмепленными файлами не будет.
> Если страница чистая - она просто освободится, если грязная
> - сбросится прямо в тот файл, для которого отмеплена.
Если обрабатываем полгиговыйе данные на полгига памяти так, что они обрабатываются последовательно. Потом при редактировании и перекомпилировании придется освободится от самых "старых" данных - начала файла. При обработке, если все обрабатывается с начала и последовательно при загрузке начала, "забудем" вторую часть, потом третью и так далее... Такая ситуация возможна.
|
| | | | |
при грамотном подходе аппаратные 64 бита необязательны 02.08.05 18:15
Автор: Killer{R} <Dmitry> Статус: Elderman
|
Секцию можно открывать и на большие файлы а мапить по-очередно разные регионы.
А для доступа к данным огранизовать класс - обертку реазлизующие нечто типа здорового массива с индексами __int64, и примерно такими методами:
class BigFileAccessor
{
...
public:
unsigned char operator [](__int64 offset) const;
unsigned char &operator [](__int64 offset);
MappedRegionPtr OpenBuffer(__int64 offset, size_t size);
}
где MappedRegionPtr - шаред поинтер с подсчетом ссылок и оповещением BigFileAccessor о том что регион освободился
И уже внутри него организовывать всякие мэппинги. Потом при возможности перекинуть все это на 64хбитную платформу будет проще простого.
|
| | | | | |
Клиент-Сервер 04.08.05 08:58
Автор: Iwan Статус: Незарегистрированный пользователь
|
|
Загружаешь данные в оперативку сервером, который постоянно резидентен. Отлаживаешь свой код и всё остальное на клиенте.
|
| | | | | |
Можно, хотя чуть геморно. Но я сторонник стиля вообще не использовать массивы в программах, что и предложил бы Сергею Косину. 03.08.05 12:50
Автор: DPP <Dmitry P. Pimenov> Статус: The Elderman
|
|
|
|
Вы не написали в какой ОС работаете, предполагаю что в... 28.07.05 16:01
Автор: leo <Леонид Юрьев> Статус: Elderman
|
Вы не написали в какой ОС работаете, предполагаю что в Windows.
Оптимальное решение будет примерно такое:
1) Записать в файл линейное бинарное представление (образ памяти) массива данных;
2) Ознакомиться с системными функциями управления виртуальной памяти, например CreateFileMapping(), MapViewOfFile(), OpenFileMapping() и т.д.;
3) Написать вспомогательную программу, которая создаст разделяемое отображение (Named Shared Memory) и отобразит полученный файл в память. Также программа может зафиксировать отображение в RAM;
4) Из отлаживаемой расчетной программы открывать разделяемое отображение (см. OpenFileMapping()). При этом вы сразу получите доступ ко всему, уже загруженному в память, массиву;
|
|
Memory mapping 28.07.05 15:45
Автор: amirul <Serge> Статус: The Elderman
|
> Здравствуйте.
На POSIX-ах это mmap, на Win32 - CreateFileMapping/MapViewOfFile
> этот массив имеет размер около 0,5 ГБайта (для полного
> расчета будет порядка нескольких ГБайт) и загрузка его
Будет одна проблема. Адресного пространства процесса может не хватить для размещения твоего меппинга. Тут уж 64-битная адресация с 64-битными же процессорами (PAE - это очередная глупая заплатка на нерасширяемую архитектуру)
> занимает значительное время, что очень не удобно при
> отладке программы, необходимо постоянно ждать по несколько
> минут. Решение этой проблемы я вижу в том, что бы постоянно
> хранить этот массив в памяти (приложения, потока или чего
> ни будь еще), а программа расчета просто получала бы этот
> массив при каждой загрузке.
При меппинге резервируется область памяти, а чтение из файла производится непосредственно в момент обращения к странице.
> Вопрос мой такой, посредством чего можно получить этот
> массив (что почитать). При чем желательно не копировать
> массив, поскольку это не дает значительного ускорения (а
> возможно наоборот) так как значительная часть этого массив
> хранится в свопе, так же этот метод приведет к удвоению
Никакого удвоения не будет. Можешь считать отмепленный файл дополнительным свопом, куда будут свопиться изменения той области памяти, в которую ты отмепил этот файл
> занимаемой памяти, что, наверное, не совсем хорошо скажется
> на производительности. Хорошо бы получать ссылку на этот
> массив (но у каждой приложениия свое адресное
> пространство).
Один из побочных эффектов - ЭТОТ ЖЕ файл может отмепить в свое адресное пространство произвольное количество процессов. При этом они будут ФИЗИЧЕСКИ иметь общую память (то есть в адресное пространство каждого процесса будут впечатаны одни и те же физические страницы памяти)
|
|
Если удвоение памяти тебя не страшит, то создай RAM-диск и закинь файл туда 28.07.05 15:32
Автор: Yurii <Юрий> Статус: Elderman
|
|
|
|
|
подробно о проекте
Анализ криптографических сетевых...
