Реализация менеджера памяти с использованием AWE

← →
Rouse_ © (2014-08-27 20:49) [0]

Ребят - а кто занимался вообще работой с AWE?
Сейчас собственно пишу двигло/обертку над этим механизмом, задача вылезти за рамки доступных 3 гигов виртуалки (тесновато).
Хотел-бы посмотреть на сам подход реализации такого менеджера памяти.
Не то чтобы мне не понятно как это делать - меня пока что немного смущает свой подход к реализации.
Идею алгоритма работы с чайнами (поиск/выделение освобождение свободных блоков лимитированноо размера) примерно идентична линуксовому манагеру памяти, но он слишком универсален и не подходит мне по множеству причин, поэтому хотелось бы хотябы глазком подсмотреть на реализации от умных людей :)

← →
Павиа (2014-08-27 21:00) [1]

чайнами - а можно по английски, а то не пойму какой из двух алгоритмов.

← →
Rouse_ © (2014-08-27 21:08) [2]

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

Грубо выделение вот так:

// Смотрим адрес первой свободной ячейки pNextItem := PPointer(FMemoryList[FCurrentMemoryListIndex])^; // Назначаем ее результату Result.FBlockOffset := pNextItem; // Если она не содержит адрес следующей пустой if PPointer(pNextItem)^ = nil then begin // то рассчитываем его самостоятельно pNextItem := PByte(Result.FBlockOffset) + BlockSize; PPointer(FMemoryList[FCurrentMemoryListIndex])^ := pNextItem; end else PPointer(FMemoryList[FCurrentMemoryListIndex])^ := PPointer(pNextItem)^;

а релиз так:

// Смотрим адрес первой свободной ячейки pNextItem := PPointer(FMemoryList[FCurrentMemoryListIndex])^; // пишем его в текущую освобожденную PPointer(Value.FBlockOffset)^ := pNextItem; // а адрес освобожденной пишем как первая свободная ячейка PPointer(FMemoryList[FCurrentMemoryListIndex])^ := Value.FBlockOffset;

← →
Rouse_ © (2014-08-27 21:11) [3]

Но это не суть - тут просто поиск ячеек, а вот сама работа с такими данными - сам подход интересует.

← →
Павиа (2014-08-27 21:28) [4]

> Но это не суть - тут просто поиск ячеек, а вот сама работа
> с такими данными - сам подход интересует.

Подход такой же как с жестким диском.
Доступ надо делать линейным. Собственно как и работают все СУБД перебирая все записи линейна считывая блоки последовательно один за другим и применя к записям последовательно одно и тоже условие.
Для деревьев инверсный индекс.
В AWE блок лучше большой скорее всего 1ГБ или что вам больше подходит.

← →
Rouse_ © (2014-08-27 21:37) [5]

Это уже все предусмотренно, оттестированно и работает.
Вопрос немного в другом, сама архитектура работы с таким манагером.
Тут-же штатный пойнтер уже не подойдет, приходится реализовывать свой аналог. И вот как-бы его так по хитрому реализовать чтобы было удобно работать внешнему программеру.
Щас пока что "class operator inplicit" используется чтобы над таким кастомным пойнтером делать привычные действия в виде присваивания и чтения без изменения исходного кода.
Но, сразу вылезают проблемы в виде динмассивов таких блоков памяти (как бы правильно архитектурно их реализовать чтобы было удобно на внешке) или кастования нескольких блоков к TRecord и т.п.
Грубо хочется все это сделать по возможности с полным использованием "синтаксического сахара" чтобы снаружи было даже не понятно с каким именно блоком банных мы работаем - выделенным моим манагером или штатным.

← →
Rouse_ © (2014-08-27 21:40) [6]

Ну и есесно интересует механика работы переключения окон (у меня пока что все спрятано в самом пойнтере) т.е. как в таких кастомных манагерах ребята обрабатывали необходимость мапа другой памяти в выделенное окно.

← →
Павиа (2014-08-27 21:40) [7]

Немного в сторону от темы. В продолжении про СУБД и не только.
А вот современные изыскания показали что от пейджинга лучше уходить. Слишком тормозит.

Что касается менеджера памяти линукса, то они ещё стараются поддерживать чтобы данные одного типа не расползались по разным окнам. Путем классификации обращений по размеру.

← →
Rouse_ © (2014-08-27 21:42) [8]

> Что касается менеджера памяти линукса, то они ещё стараются
> поддерживать чтобы данные одного типа не расползались по
> разным окнам. Путем классификации обращений по размеру.

Я на это сразу заложился - если нужны байты - один манагер, а для работы с двордами, будь добр другой создавать. Так проще цепочку чайнов держать.

← →
Павиа (2014-08-27 22:38) [9]

> Rouse_ © (27.08.14 21:37) [5]

Понятно. Ну тут по любому код надо править. Думаю принципиально не решаемо.

← →
Павиа (2014-08-27 22:51) [10]

> Ну и есесно интересует механика работы переключения окон
> (у меня пока что все спрятано в самом пойнтере) т.е. как
> в таких кастомных манагерах ребята обрабатывали необходимость
> мапа другой памяти в выделенное окно.

Архитектурно. Пишешь указ не делать такой бяки и всем под роспись. А так если остро надо прервал основной поток. Поменял окно с копировал к себе в буферную зону или на стек. И восстановил старое окно. Либо делаешь пересылку данных из одного окна в другое.

Я AWE как не рассматривал так и не нашел в нем ничего хорошего. Проблем от него много, а пользы мало.

← →
имя (2014-08-28 09:56) [11]

Удалено модератором

← →
Rouse_ © (2014-08-28 10:09) [12]

Удалено модератором

← →
имя (2014-08-28 10:21) [13]

Удалено модератором

← →
Inovet © (2014-08-28 10:24) [14]

> [12] Rouse_ © (28.08.14 10:09)
> как и 3D Studio 64 битным

3D Studio ещё под ДОС работала в 32 бит режиме. А уж памяти там было сколько..., мегабайта 4.

← →
Rouse_ © (2014-08-28 10:38) [15]

Сейчас он 64 битный :)

← →
имя (2014-08-28 12:12) [16]

Удалено модератором

← →
Eraser © (2014-08-28 14:18) [17]

> Rouse_ © (27.08.14 20:49)

не удивлюсь, если следующая десктопная ОС уже не получит 32 битного варианта, может проще переводить софт на 64 бита?

← →
junglecat (2014-08-28 14:21) [18]

> [17] Eraser © (28.08.14 14:18)

вряд ли. Слишком много 32-бит софта напилено, что вот так прямо фсё ф топку

Удалено модератором

← →
Павиа (2014-08-28 15:33) [20]

Rouse_ Если хочешь быстрое внедрение AWE то используй принцип закрытия. Сделай простой интерфейс к примеру по аналогии с sql запросом. Либо придется весь код проверять и править на соответствие корректности работы. Плюс к тому же конвертация добавиться чего мне не нравиться так как код становиться не разборчивым из- за лишних нагромождений букв.

← →
имя (2014-08-28 16:18) [21]

Удалено модератором

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

> Dimka Maslov © (28.08.14 16:33) [22]
> Когда-то менеджеры памяти писались для задач, сводящихся
> к обращению матриц больших размеров.

Дим, ты похоже первый кто угадал задачу - респект :)

> Павиа (28.08.14 15:33) [20]

Спасибо, но боюсь мы говорим о разных вещах, извини :)
Я попробую еще раз пояснить - как работать с AWE, нюансы синхронизации, сквозной доступ - это все я умею, знаю и не раз применял... но.
Сейчас задача немного в другом - мне нужно это вынести в виде высокоуровневого фреймворка на внешку, чтобы с ним было удобно работать программистам, которые даже понятия не имеют о таких вещах :)
Именно в этом я и прощу помощи чтобы посмотреть как такую задачу решали другие люди :)

> Rouse_ © (28.08.14 21:08) [23]

Это единственная задача, в которой может не хватить памяти.
Что же касается непосредственно задач обращения матриц применительно к МКЭ, то там в последнее время используются т.е. мультифронтальные решатели (sparse equation solvers), которые быстрее и жрут меньше памяти (опять же за счёт работы с диском). Так что смотреть надо туда.

> junglecat (28.08.14 14:21) [18]

на 64 битных ОС можно запускать 32 битный код. серверные ОС от MS уже, к слову, не имеют 32 битных версий.

Реализация менеджера памяти с использованием AWE Найти похожие ветки