Max Kirillov (max630) wrote,
Max Kirillov
max630

Category:

C++ vs boehm GC

Тут [info]kouzdra обсирает shared_ptr, мол тормозные они. Довольно интересно. Не то чтобы они мне по работе были слишком тормозными чтобы их не использовать, но меня что-то задело. И пока я был в задетости, внезапно сообразил, что никакой c++ специфики мусоросборщик требовать не должен. Потому что объекту, которого будут коллектить, в идеале совсем никаких действий по своей смерти делать не надо - это во-первых, лишние тормоза, а главное - не несёт практической пользы. То есть деструктор для таких классов вызывать не надо. А я всё думал, как это сделать.

Таким образом, приляпал я к плюсовому коду kouzdra тот самый тупой libgc. Код есть тут: http://www2.max630.info/bench/main.cpp

Он, оказывается, работает быстрее, чем ручные delete. Раза в полтора.


Ещё пример: http://www2.max630.info/bench/tree.cc
Тут динамическая аллокация уже по делу, рекурсивные данные. Вкратце - бинарное дерево. Случайные (псевдослучайные такие псевдо, на самом деле, но зато быстро и предсказуемо, а мне больше и не надо) данные его заполняют, при коллизиях выбрасываются старые поддеревья. Немного напоминает задачу по сбору статистики, но поживее с памятью. Результат - boehm gc чуть-чуть быстрее ручных delete. Надо понимать, что тут количество живых данных, а значит и нагрузка на gc, больше. Тем не менее, он держится хорошо. К сожалению, толком подступиться к статистике GC не удалось, так что анализировать больше нечего. shared_ptr раз в 5 хуже обоих.

Сделал то же самое для ml и haskell (http://www2.max630.info/bench/). Правда, этих шашек я уже очень давно не брал в руки, так что - что есть то есть. В основном я взялся именно потому что у kouzdra всё отлично оптимизируется в статику, и какой-нибудь не в меру умных компилятор мог бы это и сделать. Хотя gc и там и там честно отрапортовал о куче перелопаченных данных. А тут всё честно по определению - дерево не синлайнишь.

Для haskell вытянул императивный вариант как мог, там есть ещё чистый, он раза в 4 медленнее неоптимизированного императивного, и его я не трогал. Ocaml не оптимизировал никак (собственно, с трудом представляю как это можно делать). Пока что получается, что они медленнее раз в 5, примерно на уровне shared_ptr. Если кто-то может предложить варианты быстрее - посмотрю с удовольствием.
Subscribe
  • Post a new comment

    Error

    default userpic

    Your reply will be screened

    Your IP address will be recorded 

    When you submit the form an invisible reCAPTCHA check will be performed.
    You must follow the Privacy Policy and Google Terms of use.
  • 16 comments