Дмитрий Вьюков. Интервью - часть первая

Собственно, сам выпуск вы можете послушать на сайте или в itunes

В слак чате Дима так же ответил на некоторые вопросы, интересующие сообщество (орфография и стили вопросов сохранены).

Сейчас в связи появлением в atomic SetValue началась мода на атомарность. Когда в Го это действительно оправдано? Просто это регулярная тема для споров, в том числе и тут т.к. изначально язык предлагает каналы и мьютексы для синхронизации. Но Го атомик достаточно высокоуровневый и с ходу сложно об него порезаться. Или таки просто?

Каналы скорее всего станут несколько быстрее в будущем, но все равно далеки от атомарного инкременты счетчика. Не стоит надеяться, что канал+отдельная горутина будет так же быстро, как и счетчик. Когда использовать атомарные типы - сложный вопрос. Ну во-первых, прежде чем применять какие-либо деструктивные оптимизации надо получить проблему производительности. Если проблемы производительности в данном месте нет, то очевидно атомики применять не надо. Дальше вопрос - насколько существующие оптимизированные примитивы синхронизации делают то, что вам нужно. Например, если вы можете просто заменить мьютекс или канал+горутина на sync.Once или atomic.Value, то это делает выбор проще, чем если вам нужно писать с нуля сложный lock-free алгоритм на атомиках. Дальше вопрос - сколько вы и ваша команда готовы вынести дополнительной сложности в проекте. Дальше - насколько атомики получаются быстрее. Дальше все это взвесить и решить - стоит оно того или нет.

Будет ли максимальный stop the world для GC в будущем снижаться ниже 10 ms?

По поводу сборщика мусора - я последнее время отошел от дел, сейчас другие люди его делают и не знаю, что именно они собираются делать. За них отвечать я не могу. Но вообще можно сделать сборщик вообще без пауз, и вроде все соглашались, что это хорошая идея. Стоит заметить, что 10 ms - цифра достаточно с потолка, и никто в данный момент не пытается придерживаться этой границы. Сборщик просто тормозит программу на некоторое время. Обычно так получается, что это время маленькое и меньше 10 мс. Так же стоит заметить, что если программа аллоцирует память как угарелая, то у сборщика не будет выбора как остановить её. Даже если он полностью конкаррент.

Дим, в этом свете тогда вопрос, есть ли возможность жёстко задавать размер хипа, чтобы влезать в мобильные приложения и в ограничения на контейнеры. Так как GOGC выглядит совсем soft. Планируется ли?

Нету. Пока ты не зафайлишь баг с описание того, как сильно это мешает тебе разрабатывать реальные мобильные приложения, - нет.

Ещё у меня такой вопрос. Я видел обсуждения про асинхронную работу с файловой системой на разных ОС. Вообще ведутся какие-то работы в этом направлении?

Насколько я знаю, никакие работы не ведутся. Есть открытый баг на эту тему.

Я понимаю что каналы никогда не будут близки к атомикам т. к. концептуально разное. Но вопрос - насколько ещё можно ускорить каналы и самое главное насколько разработчики компилятора Го в этом заинтересованы интересен. До 1.5 был основная мысль “все оптимизации после переноса на Го”. Перенесли - как теперь вектор развития утверждается? (прим. имеется ввиду переписывание рантайма c C на Go)

Насколько я понимаю, команда Го не сильно заинтересованы в каналах, по-крайней мере они сами вроде ничего не делают. Мало реальных приложений, где много времени тратиться в каналах. На гугловых кластерах первая функция связанная с каналами - chansend занимает 0.03%

Дмитрий, у нас есть слухи про то, что Intel делает дебагер на базе gdb, ты не в курсе?

Про Intel я не могу распространяться. поживем-увидим =)

В каких оптимизациях заинтересована команда? Что бы примерно знать вектор развития.

В целом в каждый момент времени они занимаются тем, что больше всего замедляет реальные Го программы. Сейчас там есть несколько людей, которые занимаются сборщиком мусора, есть человек, который занимается эскейп анализом, есть несколько людей, которые занимаются генерацией кода.

comments powered by Disqus