Мастера DELPHI (документация, исходники, скачать)

Основная («Начинающим»)/ Базы / WinAPI / Компоненты / Сети / Media / Игры / Corba и COM / KOL / FreePascal / .Net / Прочее / RSDN.ORG

« предыдущая ветвь | форум | следующая ветвь »

FastMM - еще один менеджер кучи [Delphi, Windows]

Владимир Кладов © (2005-04-03 12:28:00)
Я тут до кучи сделал еще один менеджер памяти. Если кому интересно: http://bonanzas.rinet.ru/FastMM.zip
Честно говоря, ожидал бОльшего прироста производительности. На узкоспециальной задаче удалось побить стандартный менеджер кучи Delphi примерно вдвое по скорости. Если кто придумает, что исправить, чтобы эффект был больше, я с удовольствием.

thaddy (2005-04-06 00:46:00) [1]
It can! but it needs a rewrite using a tool to translate the mmx code to db statements. Look at Vladimir's mmx unit for an example

Boguslaw Brandys (2005-04-06 00:25:00) [2]
Unfortunately FastMM cannot be compiled under Delph 5 :-(

thaddy (2005-04-05 21:20:00) [3]
Another optimization might be to implement the allocation not as a tree, but like a circular buffer with two read/write pointers.
Bufferpointers should be in an offset 16 bit register like ax. This would automatically overflow to zero when a page boundary is reached! Then you can use virtualalloc etc, when more memory is needed. With your schema you can compare the pointers ( within an allocation schema) to see if there's enough space. This is highly efficient since only three compares are necessary.

thaddy (2005-04-05 21:19:00) [4]
Another optimization might be to implement the allocation not as a tree, but like a circular buffer with two read/write pointers.
Bufferpointers should be in an offset 16 bit register like ax. This would automatically overflow to zero when a page boundary is reached! Then you can use virtualalloc etc, when more memory is needed. With your schema you can compare the pointers ( within an allocation schema) to see if there's enough space. This is highly efficient since only three compares are necessary.

Владимир Кладов (2005-04-05 15:44:00) [5]
да результаты и не могут показывать одно и то же - в многозадачной среде. А еще при повторном прогоне может получиться просто другая раскрадка загруженности физических страниц, чем при первом. Так что чтобы сделать чистый тест, надо запретить использование файла подкачки, включить realtime приоритет, и не давать системе шансов получить тайм-слайсы до завершения теста. Но это не практично, все равно в жизни все не так.

Я обратил внимание, что FastMM (не мой который а в пакете, на который указал Thaddy), скорость существенно вырастает прежде всего засчет выравнивания на границу 16-байтного блока. И для пересылки куска памяти на reallocate используется mmx, очень впечатляюще. Я хочу попробовать еще 1 вариант. Гранулярность + все тот же метод выделения памяти с максимальным резервированием на хвосте. Главное, за счет чего надо пытаться обогнать прочие менеджеры - это минимизация числа машинных операций для выполнения выделения и освобождения памяти. Realloc, как обнаружилось вносит не более четверти вклада в самоыз специальных случаях.

Barloggg (2005-04-05 12:39:00) [6]
хмм... можно сделать запрос от пользователя, желает ли он часто менять размер строки.

насчет эффективности... она нестабильна.
При вызове менеджера задач Вин2000 скорость упала и последовательные запуски приложенного ехе-файла в тестовой задаче показывают чуть ли не двухкратный прирост скорости против стандартного.

До этого эффективность была около 30% против стандартного и 10% против замененного sysdcu

ECM (2005-04-05 10:12:00) [7]
В архиве есть описание алгоритма работы - почитай...

miek (2005-04-05 09:56:00) [8]
А за счет чего происходит прирост производительности, если не секрет?

thaddy (2005-04-03 22:48:00) [9]
Try http://newsgroups.borland.com/cgi-bin/dnewsweb?cmd=article&group=borland.public.attachments&item=8648&utag=

Fastcode project Memory Manager Challenge in Brland.public.delphi.basm newsgroup!

Наверх

	« предыдущая ветвь \| форум \| следующая ветвь »