Насколько быстро RPython GC может выделять память? ( pypy.org )
Причина, по которой их распределитель быстрее, чем у Boehm, заключается не в консервативном сканировании стека.
Вы можете перемещать объекты, используя консервативное сканирование стека. Это распространенный подход. JavaScriptCore использовал его.
Вы можете иметь супербыстрое распределение в неподвижном сборщике, но это подразумевает алгоритм, который сильно отличается от алгоритма Бёма. Я думаю, что самые быстрые неподвижные сборщики имеют похожие быстрые пути распределения с самыми быстрыми подвижными сборщиками. JavaScriptCore имеет быстрый неподвижный распределитель, который называется bump'n'pop. В Fil-C я использую другой подход, который я называю SIMD turbosweep. Есть также подход Immix. И есть много других.
По моим подсчетам, на машине CF Bolz, AMD Ryzen 7 PRO 7840U, предположительно на одном ядре, происходит примерно одно или два выделения памяти в наносекунду, и на одно выделение приходится около 11 инструкций.
Это примерно в 2–4 раза быстрее, чем мой указатель-выталкивающий аренный аллокатор для C, kmregion†, который имеет похожее количество инструкций на (встроенном) быстром пути. Но, возможно, это потому, что я тестировал на более медленном оборудовании. Я также тестировал с 16-байтовыми инициализированными объектами, но без GC. Это примерно в 10 раз быстрее malloc/free.
Не знаю, стоит ли рекомендовать использовать kmregion, поскольку он никогда не использовался для чего-то серьезного, но он должен послужить, по крайней мере, в качестве доказательства концепции.
______
† http://canonical.org/~kragen/sw/dev3/kmregion.h http://canonical.org/~kragen/sw/dev3/kmregion.c http://canonical.org/~kragen/sw/dev3/kmregion_example.c
Source: news.ycombinator.com