Prom++, в отличие от VictoriaMetriсs, полностью совместим с Prometheus и является его полной заменой (достаточно просто заменить исполняемый файл и вы получите снижение потребления ОЗУ в несколько раз).
Вопрос не в языке, а в объеме работ) Кодовая база Prometheus очень большая, чтобы вот просто так взять и переписать ее на C++ (не говоря уже об отладке)
Тогда бы нам пришлось переписать целиком Prometheus (https://github.com/prometheus/prometheus) на C++, что потребовало бы большого количества времени (исчисляемого годами) и сил. А так мы переписали только проблемные части Prometheus, сохранив полную совместимость с исходным продуктом.
Да и нет смысла переписывать то, что итак хорошо работает)
Дело в том, что при CGo вызове происходит перевод горутины в режим системного вызова и переключение стека со стека горутины на системный. В рамках этих 2 задач выполняется множество небольших операций (например изменение полей в структуре g, где происходят atomic-операции), которые как раз в сумме и дают эти 78ns
1) Создание потока ОС занимает десятки микросекунд (!!!) и в исходном коде функции runtime.entersyscall я на нашел кода по созданию потока ОС (поэтому вы этого в статье и не увидели)
2) Да, вы совершенно правы, что наше решение пока не позволяет вызывать Go callback'и и я об этом в статье сказал
Prom++, в отличие от VictoriaMetriсs, полностью совместим с Prometheus и является его полной заменой (достаточно просто заменить исполняемый файл и вы получите снижение потребления ОЗУ в несколько раз).
А еще Prom++ потребляет ОЗУ в несколько раз меньше, чем VictoriaMetrics. Подробнее об этом вы можете прочитать в статье моих коллег https://habr.com/ru/companies/flant/articles/878282/
Вопрос не в языке, а в объеме работ) Кодовая база Prometheus очень большая, чтобы вот просто так взять и переписать ее на C++ (не говоря уже об отладке)
Тогда бы нам пришлось переписать целиком Prometheus (https://github.com/prometheus/prometheus) на C++, что потребовало бы большого количества времени (исчисляемого годами) и сил. А так мы переписали только проблемные части Prometheus, сохранив полную совместимость с исходным продуктом.
Да и нет смысла переписывать то, что итак хорошо работает)
Дело в том, что при CGo вызове происходит перевод горутины в режим системного вызова и переключение стека со стека горутины на системный. В рамках этих 2 задач выполняется множество небольших операций (например изменение полей в структуре g, где происходят atomic-операции), которые как раз в сумме и дают эти 78ns
1) Создание потока ОС занимает десятки микросекунд (!!!) и в исходном коде функции runtime.entersyscall я на нашел кода по созданию потока ОС (поэтому вы этого в статье и не увидели)
2) Да, вы совершенно правы, что наше решение пока не позволяет вызывать Go callback'и и я об этом в статье сказал
Зачем и почему мы переписали ядро хранения данных на C++ подробно описано здесь: https://habr.com/ru/companies/flant/articles/878282/