Скорость Google Go
2011-09-06 08:02 pm![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
waqurВ июне исследователи из Гугла опубликовали статью [1], где они сравнивнивают производительность индустриальных языков программирования C++ и Java/Scala с Go. Программа на Гоу была в 7 раз медленнее, чем программа на C++, после применения экстремальных мер по оптимизации к последней.
Если C++ный код не подвергается экстремальной оптимизации, разница не так велика - порядка 2x-4x раз [2].
Статью [1] писала не та команда, которая разрабатывает компилятор для Гоу. У Роба Пайка и компании возникли возражения по этим цифрам, и путём некоторой оптимизации Go-исходников теста с использованием профилировщика, они смогли сравниться с C++ [3]
Также, Russ Cox отмечает:
"We used gopprof to study an inefficient Go program and then to improve its performance by an order of magnitude and to reduce its memory usage by a factor of six. A subsequent comparison with an equivalently optimized C++ program shows that Go can be competitive with C++ when programmers are careful about how much garbage is generated by inner loops."
Таким образом, бенчмарки показывают, что язык Go упёрся в принципиальный дефект своего дизайна - в сборку мусора по принципу stop-the-world. Обычная программа на Go (без экстремальных мер по оптимизации) больше тратит времени на сборку мусора, чем собственно на вычисления.
[1] https://days2011.scala-lang.org/sites/days2011/files/ws3-1-Hundt.pdf
[2] http://shootout.alioth.debian.org/u64q/which-programming-languages-are-fastest.php
http://shootout.alioth.debian.org/u32/which-programming-languages-are-fastest.php
[3] http://www.theregister.co.uk/2011/07/01/go_v_cpluplus_redux/
Ссылка [2] также интересна тем, что она показывает, как отстали Python, Ruby и PHP. Статически типизированные языки безусловно рвут динамически типизированные, они быстрее в десятки раз.
Если C++ный код не подвергается экстремальной оптимизации, разница не так велика - порядка 2x-4x раз [2].
Статью [1] писала не та команда, которая разрабатывает компилятор для Гоу. У Роба Пайка и компании возникли возражения по этим цифрам, и путём некоторой оптимизации Go-исходников теста с использованием профилировщика, они смогли сравниться с C++ [3]
Также, Russ Cox отмечает:
"We used gopprof to study an inefficient Go program and then to improve its performance by an order of magnitude and to reduce its memory usage by a factor of six. A subsequent comparison with an equivalently optimized C++ program shows that Go can be competitive with C++ when programmers are careful about how much garbage is generated by inner loops."
Таким образом, бенчмарки показывают, что язык Go упёрся в принципиальный дефект своего дизайна - в сборку мусора по принципу stop-the-world. Обычная программа на Go (без экстремальных мер по оптимизации) больше тратит времени на сборку мусора, чем собственно на вычисления.
[1] https://days2011.scala-lang.org/sites/days2011/files/ws3-1-Hundt.pdf
[2] http://shootout.alioth.debian.org/u64q/which-programming-languages-are-fastest.php
http://shootout.alioth.debian.org/u32/which-programming-languages-are-fastest.php
[3] http://www.theregister.co.uk/2011/07/01/go_v_cpluplus_redux/
Ссылка [2] также интересна тем, что она показывает, как отстали Python, Ruby и PHP. Статически типизированные языки безусловно рвут динамически типизированные, они быстрее в десятки раз.
![[identity profile]](https://www.dreamwidth.org/img/silk/identity/openid.png){kind=small}
no subject
Date: 2011-09-07 04:02 am (UTC)no subject
Date: 2011-09-07 07:25 am (UTC)Далее, в гоу нет стека как такового, ведь концепция линейного стека несовместима с сопроцедурами/гопроцедурами/гринлетами/ивэнтлетами/лёгкими_потоками/зелёными_потоками/как-они-там-ещё-называются. Зелёные потоки требуют древовидного стека (a la Cactus Stack), который всегда реализуется на куче; а стековые кадры вызывающей-вызываемой функции не находятся физически рядом (как в традиционной модели стека), а связаны указателями (как в классических структурах данных linked list / tree).
Поэтому, в конечном итоге, вся аллокация, в том числе и стековая, выполняется на куче.
no subject
Date: 2011-09-07 07:29 am (UTC)фишка в том, что выделение памяти в системах с GC это O(1) операция, практически как получение памяти на стеке.
ну а сборку мусора всякими ловкими ходами, вроде поколений объектов, тоже довольно сильно ускоряют.
итого -- получается сильно быстрее в некоторых случаях обычной сишной кучи (понятно, что где надо, ты себе пулы сделаешь).
no subject
Date: 2011-09-07 07:42 am (UTC)кто делает запросы к этой куче, кроме сгенерированного компилятором кода + вручную написанной библиотеки-аналога STL? они могли немного допилить все эти вещи, чтобы те радостно работали с объектами фиксированного размера, например 128 байт
и далее куча превращается в простой пул со всеми его преимуществами:
* нефрагментируемость
* быстрая аллокация на битовой карте свободных блоков + счётчиках единичных битов в иерархически организованных группах разного размера
* быстрое удаление
* можно в кольцевом буфере помнить с десяток последних освобожденных блоков и распределять их в приоритетном порядке для лучших показателей по кэш-попаданию
а для сишного кода, библиотек третьих фирм и т.д. можно было оставить традиционную сишную кучу со всеми её недостатками в смысле производительности