Golang: специфические вопросы производительности / Даниил Подольский, Кирилл Даншин
ฝัง
- เผยแพร่เมื่อ 23 ก.ย. 2024
- Приглашаем на конференцию HighLoad++ 2024, которая пройдет 2 и 3 декабря в Москве!
Программа, подробности и билеты по ссылке: clck.ru/3DD4yb
--------
HighLoad++ Moscow 2018
Тезисы и презентация:
www.highload.ru...
Язык Go уверенно набирает популярность. Настолько уверенно, что сегодня уже имеет смысл разговаривать о его специфических проблемах. Например, о проблемах производительности.
…
Нашли ошибку в видео? Пишите нам на support@ontico.ru
Даниил Подольский: "... это - черная магия", программисты на C: "да я колдун!"
Легенда чатика по Golang
последние слова никогда так не смешили "хорошо калеки, спасибо" ))
инвалиды, огузки)))
"Мы что-то померили на конкретных случаях и сделали какие-то бинарные выводы". Но, кажется, так и не поняли почему это работает именно так. Особенно улыбнуло, что "интерфейс не стоит ничего". Как это ничего? Это, как минимум, отсутствие инлайнинга и косвенный вызов(если компилятор не раздуплится в девиртуализацию для конкретного случая). Это МОЖЕТ стоить ничего, но это не значит что это ВСЕГДА так.
4:50 на этом этапе вместо записи структуры как значения записываем ее как ссылка и внезапно интерфейсы оказываются в 2-3 раза дороже. Мало того, если добавить тут еще один тест с приведением не к интерфейсу, а к ссылке на структуру, то оказывается, что приведение типов не стоит ничего от слова совсем(хотя разница колеблется в промежутке 10-50%, но при скорости работы 0.48-0.5 и 0.7-0.75 нс это будет ощутимо только в том случае, если вы только и делаете, что приводите типы), а интерфейсы - не такое уж дешевое удовольствие
Хотел много чего написать, но почитал комментарии и смотрю, я не один такой. Исследовать программу как черный ящик, когда можно просто посмотреть ассемблер и увидеть, что генерирует компилятор, это странно. Еще более странно не учитывать работу кэшей, которые при "хорошем стечении обстоятельств" повысят скорость на порядок, а при плохом наоборот. Если синтетический тест с минимальным кодом (увеличением на единичку) попадает в кэш, то что будет с реальной программой, никто не скажет.
Про defer. Вопрос не только в том, сколько времени работает сама функция и сколько занимает реализация defer, а еще и в том, что происходит внутри самого defer. Если там закрываются сетевые соединения, удаляются временные файлы или еще что, то время работы самого механизма defer пренебрежимо мало.
P.S.
Те, кому значимы наносекунды пишут на C/C++.
P.P.S.
Хотел бы я увидеть хоть один пример из реального кода на go, где defer что-то замедлил...
@@paxpax1707 Он вроде говорит что ждал что канал будет как мьютекс, но канал значительно дороже мьютекса оказался
Поверхностно, но наверное, именно поэтому докладчик предупредил что «откровений не будет»
это все ниочем. нужно объяснять почему так происходит.
Да там ни чего интересного, дерьмовый фронтенд который не умеет в оптимизации, можно просто на godbolt глянуть количество инструкций которые генерирует компилятор gcc.godbolt.org/z/MZ1ylU
"Если ваша функция выполняется меньше 100нс, то вам не нужен дефер". А когда вообще возникает такая необходимость оптимизировать 100нс-функции?
Если функция ооочень часто вызывается и половину времени занимает только defer, то можно от него избавиться. Например, какой-нибудь сеттер с мьютексом. Как правило люди не парятся на счет анлока и просто используют паттерн mu.Lock(); defer mu.Unlock().
Это какая-то астрология.
Сейчас компиляторы на столько умные, что всю ахинею разработчика умеют линеаризовывать.
А здесь не раскрыто главного, какой ассемблерный код генерится и какие бывают граничные условия.
Говоря о наносах, не стоит забывать про промах кеша и branch mispredict
компиляторы не настолько крутые как хотелось бы да и часто чтобы соптимизировало надо код немного всё таки облагородить особым образом
Они ещё не знают как популярны Арм сервера
Где таких берёте? Ходит, воду пьёт, вздыхает... никак напиться не может. Жесть! 🤷♂️
ну, человек немаленькой комплекции.. можно сделать скидку