Comments 8
Вкладка висела открытой с того года, только нашёл время дочитать :-)
Про Фи я сказал из зала и не вижу ничего зазорного в этом. Докладчик спросил мнения зрителей, какой будет результат. Я сообщил свою версию и попытался её объяснить, как оказалось, правильно. Если б докладчик не спрашивал, то и я бы не говорил.
Результаты представлены несколько коряво, согласен. Но в принципе их удавалось вполне воспринимать по ходу презентации.
Про Фи я сказал из зала и не вижу ничего зазорного в этом.
Да никаких претензий, конечно. (я, оказывается, и не заметил, что это был ты)
Результаты представлены несколько коряво, согласен. Но в принципе их удавалось вполне воспринимать по ходу презентации.
То есть тебе было неудобно воспринимать результаты в виде цитаты вывода бенчмарка?
То есть тебе было неудобно воспринимать результаты в виде цитаты вывода бенчмарка?
Ну есть ощущение, что можно лучше. Конечно, не таким дурацким графиком без осей, который нарисован в статье. Как минимум стоило выровнять столбики и можно было сделать табличку, хотя бы чисто консольную. Как-то так бы опрятнее смотрелось:
№ bytes/call bytes calls (×10⁶)
0 0.02 5851024 286.1
1 0.00 196464 246.3
...
9 0.00 48 324.1
10 0.00 48 364.3Нет ничего зазорного в том, чтобы не показывать сырой вывод измерительного инструмента, а красиво его переформатировать, не искажая суть.
И красный-зелёный у тебя, конечно, пытка для дальтоников :-)
Роман, спасибо большое за разбор. Я более чем согласен по большей части пунктов, но по парочке сомневаюсь:
Насчет SSA, например — я думал включить более подробное объяснение SSA еще когда планировал доклад. Но в итоге решил, что это слишком далекое отступление от основной темы. Тема single static assignment form вызывает слишком много вопросов — несложно рассказать что такое SSA, сложно ответить на сразу же возникающие вопросы типа "зачем/почему именно так". Отвечать на них нет времени (а то и квалификации — я все же не компиляторщик) — а без этих ответов, как мне кажется, просто непонятно, зачем о ней упоминать. Вводить новую большую сущность, которая лишь очень краем пересекается с основной темой рассказа, и не описать толком, почему эта сущность необходима, и что из себя представляет — это просто отвлекает внимание от основной темы, и не дает ничего взамен.
Поэтому я не стал раскрывать тему и когда термин "SSA" был произнесен — заранее решил, что игра не стоит свеч.
Если эскалировать эту ситуацию: мне кажется, что, в формате доклада на большую аудиторию — сохранить основной фокус и основную линию рассказа важнее, чем уточнять по ходу все детали. Детали можно уточнить и после. Поэтому я предпочитаю просто отрезать те ветки, которые не играют на основную задачу. Хотя я согласен, что "мы об этом сейчас не будем говорить" обычно звучит немного беспомощно :)
Насчет представления данных: тут для меня конфликт между двумя идеями.
Есть идея, что данные должны быть представлены в той форме, в которой они легче всего воспринимаются. Это, безусловно, график.
А есть идея, что, надо давать возможность зрителям побывать как можно ближе к реальности: увидеть реальные команды в терминале, например. Далее я показываю куски из логов компиляции — я бы мог, в пределе, вообще оставить только одну-две ключевых строки. Но мне кажется, что когда я даю больше контекста — я еще и даю зрителям возможность подготовиться к тому, что они сами увидят, когда попытаются сделать такие эксперименты сами. Ради этой возможности я оставляю больше лишнего текста (но выделяю важные элементы другими способами).
С результатами как раз такая история: я счел, что там не настолько сложное поведение, чтобы для него делать график, и лучше показать что-то похожее на реальный вывод бенчмарка. Кроме того, на графике видно количественное изменение, больше-меньше, а важно-то только качественное. Не важно (в контексте моего рассказа), сколько именно байт было аллоцировано — важно >0 (48) или =0(48). Например, на том же самом графике Preconditions (да и на многих других) были бы плавные переходы между разными версиями скомпилированного кода — но такие плавные переходы это артефакт методики измерения, они возникают за счет усреднения по итерации, состоящей из большого количества вызовов.
Что касается вывода результатов, то я во время первого просмотра ориентировался только на цвет, цифры осознал на второй-третий раз, и для этого понадобилось сознательное усилие. Вообще для отображения качественных изменений график в теории должен подходить лучше, чем таблица с цифрами.
Насчёт того, что неважно, сколько байт было аллоцировано, я бы поспорил. Это касается только кейса с вероятностной функцией (он в любом случае самый трудный для отображения). Там, насколько я понимаю, оно не скачком в ноль уходит, а как-то более сложно себя ведёт. Но при этом аллокаций всё меньше и меньше с ходом времени, то есть нагрузка на gc всё равно снижается. Другое дело, что там на каждом запуске или ноль или максимум, видимо, просто случаев максимума всё меньше и меньше, то есть на графике их просто будет не видно. В общем, правда сложно нарисовать.
Что касается вывода результатов, то я во время первого просмотра ориентировался только на цвет, цифры осознал на второй-третий раз, и для этого понадобилось сознательное усилие.
Так я ведь именно это и задумывал: первый слой восприятия просто по цвету, зеленый/красный (насчет цветовой слепоты хороший момент, кстати, спасибо — последнее, о чем я бы стал сам думать), есть аллокация/нет аллокации. А если человеку что-то кажется подозрительным, то он всматривается, и цифры-то — вот они, тут же написаны.
Там, насколько я понимаю, оно не скачком в ноль уходит, а как-то более сложно себя ведёт.
В конкретной версии скомпилированного JIT-ом кода конкретная точка аллокации либо присутствует, либо стерта за счет EA/SR. Промежуточных вариантов нет, нельзя аллоцировать пол-объекта. То, что какие-то промежуточные варианты видны в результатах итераций это артефакт усреднения. Либо внутри итерации код перекомпилировался, либо просто точка аллокации проходится не на каждый вызов метода (т.е находится в какой-то не каждый раз берущейся ветке, как в примере с pair-or-null).
Но, что раз мы это уже столько обсуждаем — значит, не настолько это очевидно, как мне казалось.
Вообще, Роман, если вы будете писать как-нибудь пост про общие принципы — было бы интересно, как вы видите эту дилемму между "реалистичностью" (давать сырые результаты, как они получены — живые логи, цитаты из терминала, куски кода без купюр) и "наглядностью" (давать результаты в максимально удобной для однозначного прочтения форме) в технических презентациях.
И спасибо вам за вашу работу.
Анализ доклада Руслана Черёмина с JPoint 2016