FastMM - еще один менеджер кучи

← →
Владимир Кладов (2005-04-03 12:28) [0]

Я тут до кучи сделал еще один менеджер памяти. Если кому интересно: http://bonanzas.rinet.ru/FastMM.zip
Честно говоря, ожидал бОльшего прироста производительности. На узкоспециальной задаче удалось побить стандартный менеджер кучи Delphi примерно вдвое по скорости. Если кто придумает, что исправить, чтобы эффект был больше, я с удовольствием.

← →
thaddy (2005-04-03 22:48) [1]

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!

← →
miek © (2005-04-05 09:56) [2]

А за счет чего происходит прирост производительности, если не секрет?

← →
ECM © (2005-04-05 10:12) [3]

В архиве есть описание алгоритма работы - почитай...

← →
Barloggg (2005-04-05 12:39) [4]

хмм... можно сделать запрос от пользователя, желает ли он часто менять размер строки.

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

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

← →
Владимир Кладов (2005-04-05 15:44) [5]

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

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

← →
thaddy (2005-04-05 21:19) [6]

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:20) [7]

← →
Boguslaw Brandys (2005-04-06 00:25) [8]

Unfortunately FastMM cannot be compiled under Delph 5 :-(

← →
thaddy (2005-04-06 00:46) [9]

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

FastMM - еще один менеджер кучи Найти похожие ветки