Анализ доклада Сергея Куксенко с JPoint 2016

    Сегодня открываем новую рубрику: разбор технических выступлений. Если взять в целом удачный доклад с IT-конференции и формализовать в нём те моменты, благодаря которым он хорош, то можно многому научиться в плане выступлений. А если в том же докладе формализовать ещё и моменты, которые можно улучшить, то польза будет двойная. Тем, кто собирается выступать на конференциях, это пригодится. Да и тем, кто давно и успешно там выступает, это тоже не повредит.

    Сегодня вашему вниманию предлагается доклад Сергея Walrus Куксенко на JPoint 2016: «Quantum Performance Effects II: Beyond the Core».


    Слайды тут

    Дисклеймер: про Java только сам доклад, если вы его ещё не видели. Статья под катом — про доклад.

    Сюжет


    От состава и качества сюжетных элементов в докладе зависит очень многое, поэтому с них и начнём.

    Детективный порядок


    Очень быстро (слайды 5-9, время 02:00-05:00) Сергей применяет приём, который можно считать его визитной карточкой (есть ещё один человек, который применяет его столь же виртуозно, это Алексей Шипилёв). Я называю этот приём «детективный порядок изложения» и всем рекомендую к изучению и применению. Хороший, годный порядок выглядит так:

    1. Наблюдаем странные симптомы в программе (совершено убийство).
    2. Пытаемся что-то подкрутить и посмотреть, что изменится (полиция собирает улики).
    3. Вроде бы нашли правдоподобное объяснение (подозреваем герцогиню).
    4. Находится новый тест, разрушающий нашу гипотезу (у герцогини алиби).
    5. Наконец, проясняется истинная причина проблемы (убийца — дворецкий).

    Очевидно, что такое построение сюжета, если сильно не затягивать, захватывает внимание аудитории, слушать интересно, можно пробовать себя в роли детектива, и вообще хочется узнать, чем же всё закончится. “Поиграть в детектива” — очень важный аспект, потому что мы вовлекаем аудиторию и провоцируем её думать, причём думать именно на тему нашего рассказа. Сергей это хорошо понимает и регулярно демонстрирует.

    Обратный порядок, когда мы сначала даём теоретическое обоснование проблемы, а затем приводим пример её манифестации, в большинстве случаев получается скучнее и меньше вовлекает зрителей. Конечно, и в этом жанре есть относительно успешные произведения (кто-нибудь помнит лейтенанта Коломбо?..), но при прочих равных “детективный порядок” лучше удерживает внимание. Только не надо обманываться, лёгкость здесь — кажущаяся. Код, иллюстрирующий пока что нерешённую проблему, нужно писать гораздо тщательнее, чем код, в котором встречается проблема уже известная. Дозировать хинты, не выдавая раньше времени главную тайну, трудно. При подготовке конференций я часто предлагал докладчикам переделать рассказ именно в таком порядке, но с первой попытки с этим мало кто справляется. Так что за простым детективным изложением прячется значительная работа.

    Отметим, что почти все примеры в докладе построены по тому же принципу.

    Проблематизация


    Но пойдём дальше. После пары привлекающих внимание примеров, всё ещё где-то в начале доклада, я ожидал увидеть рассказ о том, что проблемы вокруг кэша процессора в жизни рядового человека встречаются чаще, чем можно подумать (например, ...), и что поэтому знать о них должен каждый, кто не хочет рано или поздно серьёзно от них пострадать. Подозреваю, что такого рассказа не было, потому что среднестатистический программист на Java (это, напомню, JPoint) встречается с проблемами кэша процессора значительно реже одного раза в жизни. Обычно понимание того, что «это с каждым может случиться» даёт ещё немного внимания зрителей. У Сергея практические отсылки впервые встречаются в секции «Demo 6», начиная с 33:20, слайд 43, но к тому времени доклад уже довольно прочно воспринимается как научно-популярная экзотика.

    Есть много (часто противоречащих друг другу) цитат на тему того, на сколько уровней абстракции вниз от текущего должен свободно проникать разум программиста. Возможно, стоило обратиться к авторитету кого-нибудь из великих. В любом случае, хоть какой-то ответ на вопрос гипотетического зрителя «почему это может быть важно лично для меня» стоит иметь близко к началу каждого доклада, а здесь такого ответа нет.

    Выводы


    Концовка вполне ударная. Есть и список конкретных проблем, которые зритель должен знать, и мировоззренческий посыл: изучайте весь ландшафт, не делайте выводов из результатов измерений, пока точно не разобрались, почему они такие. Здесь, как мне кажется, всё хорошо.

    Слайды


    Комментарии по оформлению слайдов в основном касаются расхода батарейки. Представим, что у каждого зрителя в голове есть батарейка, которая садится по мере того, как он думает. Он может быть согласен или не согласен с нашей идеей, он может думать о том, как её опровергнуть, о том, как применить в своей работе, о том, как перескажет её коллегам, о том, какие ещё вопросы, связанные с темой, он хочет задать, поймав докладчика в кулуарах,  — всё это полезные мысли, и на них батарейку не жаль. Но никогда, ни при каких обстоятельствах мы не хотим, чтобы зритель мучительно пытался понять, в чём же наша идея состоит. «Что здесь написано? О какой строке таблицы он сейчас говорит? Что-что он имел в виду?», — непродуктивные траты. Материал у Сергея не самый простой для изображения, поэтому несколько мест, которые можно улучшить, найтись должны были. Ну и нашлись, конечно. А сбережённого заряда зрителям как раз хватит, чтобы лучше понять, как устроены кэш-линии.

    Код


    Но прежде всего хочу похвалить фрагменты кода, которые встречаются в докладе. Код ведь, как известно, только писать просто, а читать — сложно. Поэтому во фрагменты кода, которые мы демонстрируем, надо вкладывать очень много труда: они должны быть просты и минималистичны. В данном случае они именно таковы, и вложенный труд окупается.

    Отдельно хочу отметить, что код правильно демонстрировать именно на белом фоне:



    Конечно, многие программируют в vim другой цветовой гамме, с чёрным фоном. На слайдах её не стоит воспроизводить: серый, красный и тёмно-синий на чёрном запросто может быть совсем не видно на проекторе. Удивительно, как много сопротивления я встречаю, когда говорю об этом докладчикам, с которыми работаю. В ход идут аргументы от «я у нас уже показывал эти слайды, всё было видно» до «организаторы должны просто предоставить нормальное оборудование». На мой взгляд, это то же самое, что писать код, не обрабатывающий никакие ошибки, под предлогами типа «просто пусть они мне в сервис валидные данные передают» или «да оно на тестинге неделю нормально крутилось».

    Указка


    Код у Сергея простой, и навигация по нему не требуется. А вот там, где навигация требуется, в ход идёт лазерная указка. В моей картине мира, если вы воспользовались ею один раз за доклад, это уже на один раз больше, чем надо. Очень заметно при этом страдают те, кто смотрит видеозапись, как мы с вами. Посмотрите отрывок с 50:24 по 50:35. Проблема не в этой записи и в этом чтении, а вот в этой записи и вот в этом чтении. Всё понятно, ага.

    Конечно, работать надо для людей, которые пришли в зал, они важнее, чем те, кто будет смотреть запись. Но многим из тех, кто видел доклад вживую, тоже не повезло. Вот как выглядит зал, в котором всё происходило. Я обвёл людей, у которых вряд ли был шанс увидеть указку (докладчик применял указку только на экране слева от себя):



    При этом конфигурация с двумя дублирующимися экранами — не экзотика, она бывает на конференциях очень часто.

    А вот пример экзотики
    Экзотика — это, например, зал «Сингапур» бизнес-школы Сколково, где в этом году проходили РИТ++ и Highload++. Там вообще никуда бластером не попадёшь, зал круглый, докладчик смотрит в торец спаренных экранов:




    Я сторонник того, чтобы раз и навсегда залепить на кликере лазерную указку пластилином и жить так, как будто её никогда не было, а подсветку делать с помощью рамок, стрелок, последовательного появления элементов на схемах или изменения цвета. На слайде 64, скажем, есть стрелочки, и они нормально выполняют свою функцию:



    Таблицы и диаграммы


    Но на слайде 64, как и на нескольких других, есть таблицы. Так удобнее для аналитики (можно сортировать, делать подвыборки пр.), но хуже для демонстрации. Нужно же, чтобы сразу было видно, что мы хотим показать. Столбики разной длины гораздо проще сравнивать, чем числа, более того, они сразу показывают соотношение (чтобы не надо было делить в голове, во сколько раз 86 больше, чем 35). Полагаю, таблицы во многих случаях можно перерисовать в виде диаграмм, от этого их станет легче расшифровывать. Сравните два варианта слайда 46:

    Оригинальный:



    Переделанный:



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

    Если говорить о диаграммах, то стоит изменить график со слайда 26:



    На видео он возникает на 13:41. Посмотрите примерно минуту с этого места: мне кажется, требуется некоторое усилие, чтобы понять, где на графике хороший случай, а где плохой, так как на слайде много данных и трудная для восприятия легенда. Разобраться, конечно, можно, но гораздо проще было бы это делать, если бы графики появлялись не все сразу, а поочерёдно, и каждый из них докладчик мог бы объяснять и комментировать отдельно в момент показа.

    Линии лучше подписать прямо на графике и избавиться от легенды совсем. О том, что легенды — зло, я уже писал вот тут, но не устану повторять.

    Цвета


    Интересна с точки зрения восприятия точечная диаграмма на слайде 65, которая появляется на видео на 52:53. Вот она:


    Что с этой картинкой не так? Цвета на ней отсортированы в порядке радуги, от красного, который символизирует хороший случай (быстрое копирование), до фиолетового, который соответствует плохому. Однако, сортировка «по радуге» происходит лишь на сознательном уровне, поэтому для того, чтобы разобраться, какой цвет лучше, жёлтый или, например, голубой, приходится либо бегать по легенде глазами, либо вспоминать историю про охотника и фазана. Это всё не очень сложно, но можно сделать проще.

    В голове цвета не отсортированы автоматически, если только это не соотношение светлее-темнее. Решив несложную задачу социальной инженерии, я получил исходник диаграммы и стал перерисовывать её одним цветом. Число оттенков пришлось сократить до пяти (можно и до четырёх, 50+ вряд ли заслуживает отдельного цвета), но в итоге получился вариант, который кажется мне более наглядным (светлое — хорошо, тёмное — плохо):



    Конечно, перед демонстрацией стоит протестировать, будет ли это видно на проекторе.

    Регулярные разборы


    Если вы хотите получить обратную связь по своему выступлению, то я с радостью вам её предоставлю.

    Что для этого нужно сделать?
    1. Видео выступления, доступное на youtube, vimeo и т.п.
    2. Слайды.
    3. Заявка от автора. Без согласия самого выступающего ничего разбирать не будем.

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

    JUG.ru Group

    1 299,33

    Конференции для взрослых. Java, .NET, JS и др. 18+

    Поделиться публикацией
    Комментарии 18
      +6

      Давай меня, меня давай!

        +1
        Обязательно! Помоги доклад выбрать.
          0

          @23derevo, какой будет интересней?

        +1

        Вообще задача «не потерять информацию от лазерной указки» решаема в видеомонтаже (экран с указкой, плюс качественный экран скринкаста), но так мучительна … Я даже в свое время пытался написать хотя бы автоматический детектор моментов, когда докладчик использует лазерную указку, но увы — (не говоря уже о задаче вычисления координат указки, чтобы мапить их на экран). Приходится до сих пор, просматривать глазами, все моменты, когда на экране архитектурная диаграмма или код, а докладчик развернут лицом к экрану, и рука подозрительно поднята… Это ужасно конечно, и результат неидеален — обычно такие моменты требуют всего пространства под код/сложную диаграмму, и ползать и указывать там должен крупный курсор, или рисовалка-экранный аннотатор.


        Я пытался внедрять десятки девайсов докладчикам (чтобы указывали крупным курсором) — гиромыши, носимые микротачпады, ноуты с сенсорными и перьевыми экранами… наиболее оптимальный пока вариант — беспроводной трекбол, но все равно, им надо хотя бы минут пять потренироваться… и это надо сделать ответственностью докладчика — не используй лазерную указку, возьми с собой то устройство, которым ты сможешь удаленно и уверенно рулить курсором, если это потребуется.

          +1
          Вообще, если всерьёз захотеть, в ближайшие несколько лет задача автоматического обнаружения указки и совмещения её со слайдами должна стать довольно простой. На мой обывательский взгляд кажется, что в нейронных сетях всё для этого уже есть.

          А если совмещать в полуручном режиме при монтаже, то на уровне отдельного доклада энтузиаст это может сделать, а на уровне конференции, в которой 50-100 докладов, такая работа, скорее всего, окажется неприемлемо дорогой (монтаж-то там не своими силами делается обычно, а на заказ).
            0

            Да, работа эта тяжелая, профессионалы ее делать не будут, я делаю для тех тысяч смонтированных докладов… получая комментарии в духе «а вот, в такой-то момент пропустил лазерную указку, добавьте». С этим, конечно, надо кончать.


            Насчет указки — несколько лет назад вроде был консенсус, что оптимально выделать отдельную камеру с инфракрасным фильтром — там да, четко будет видно. Но тратить целую камеру на такую фигню жалко конечно. Пропагандируйте беспроводные трекболы, плиз.

              0

              Указку видно не только на видно после, но и как написано в тексте статьи — тем, кто смотри на другой экран в зале.

                0

                Да, конечно. Полно случаев с тремя экранами… да и даже с одним — если это плазма, нифига ее не видно. Непонятно, о чем спор.

            0
            Я даже в свое время пытался написать хотя бы автоматический детектор моментов, когда докладчик использует лазерную указку, но увы — (не говоря уже о задаче вычисления координат указки, чтобы мапить их на экран).

            Пишем видеосигнал, идущий на проектор, параллельно снимаем на камеру экран, на который проектор транслирует изображение, вычитаем из видеосигнала с камеры видеосигнал, идущий на проектор — чем не вариант?

              +2

              Яркость-цвета и вообще все, от экрана, при сьемке на камеру дико плавают (внешняя освещенность, события, перекрывание экрана, мерцания). Анрил вообще.

            +2

            Насчёт Demo 6 — люто не согласен и надеюсь, что Сергей к вам не прислушается. Я существенно легче воспринимаю столбик цифр, чем эти дурацкие спаренные полоски, которые надо взглядом сопоставить с числом снизу и числом слева. Можно было цветом или полужирным выделить, например, 19.3, 19.4, 18.4, чтобы акцент поставить. А так всё хорошо.

              0
              В принципе, тут таблица не очень большая. В ней, конечно, можно и так сориентироваться. Если хочется работать именно с таблицей, то есть варианты её отсортировать, сделать акценты с помощью цвета или жирного шрифта, а также можно элементы таблицы показывать не все сразу, а последовательно, по мере того, как до них доходит речь.
              0
              Ну так а в итоге — куда там указкой показывалось? Потому что я не понял это объяснение про 4k-aliasing.
              Так же я прочитал https://software.intel.com/en-us/node/544395 — и еще больше не понял.
              А потом я посмотрел http://stackoverflow.com/questions/21038965/why-does-the-speed-of-memcpy-drop-dramatically-every-4kb — и мне сейчас вообще кажется, что чувак получил прямо противоположный результат к тому, что рассказано видео.

              Условно, перед проверкой на перекрытие данных, адресам делается & 0xFFF, и потом смотрится, есть ли их перекрытие. Так?
              Мне, логика подсказывает, что при этом объяснении просадка производительности должна быть когда копируешь между адресами кратными 4к, но судя по таблице — это самый лучший случай по производительности. Странно это.
                0
                Насколько я понял, плохой случай — это когда source и destination выровнены относительно 4k примерно одинаково. Поэтому плохой случай находится на диагонали: из-за 4K-алиасинга с точки зрения кэша мы читаем и пишем примерно в те же самые адреса (что на самом деле не так, адреса все разные, просто для таблицы, действительно, взяты остатки от деления адреса на 4096).
                  0
                  > из-за 4K-алиасинга с точки зрения кэша

                  Небольшой коммент: кэш ничего не знает про 4K-aliasing.
                  Это проблема store buffer'а
                  0
                  > Условно, перед проверкой на перекрытие данных, адресам делается & 0xFFF, и потом смотрится, есть ли их перекрытие. Так?

                  Так.

                  > Мне, логика подсказывает, что при этом объяснении просадка производительности должна быть когда копируешь между адресами кратными 4к, но судя по таблице — это самый лучший случай по производительности. Странно это.

                  4k-aliasing, не позволяет делать load пока не завершится store (в случае конфликта). То есть нас интересует load, который идет после store.
                  Если дельта == 4K. то все хорошо ибо:
                  1) load *+4K
                  2) store *+4K
                  3) load *+4K+32
                  4) store *+4K+32

                  Тут нет конфликтов по 4K-aliasing

                  Если дельта == 4K+1(2,15,16). то:
                  1) load *+4K
                  2) store *+4K+1
                  3) load *+4K+32
                  4) store *+4K+1+32

                  то у операций 2 и 3 адреса (в младших 12 битах) перекрываются. И значит load номер 3 ждет пока значение store номер 2 уедет из store buffer.
                    0
                    Ну да, плохой случай находится не на самой диагонали, а чуть выше.
                      0
                      Все, теперь я все понял. Получается, ту ссылку, что я давал выше на stack overflow — это вообщне не про 4к-aliasing. Спасибо.

                      Кстати, чтобы собрать проект с гитхаба, нужно поставить 0.4 версию jol, потому что с 0.5 и выше не собирается (нет класса какого-то).

                  Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

                  Самое читаемое