Вот я присоединюсь: ваш текст для меня как раз хуже, чем чеклист. Потому что а) по объему гораздо больше чеклиста б) ценности дополнительной этот объем не несет
Ценностью может быть не только информация — это может быть развлечение, эмоциональное вовлечение, или своеобразная эмоциональная поддержка читателю. Но в вашем тексте этого нет.
Я согласен, что полезно уметь писать текст без воды. Это полезная практика: регулярно спрашивать себя, что пострадает если я вычеркну из предложения вот это слово?
Но многие люди путают текст без воды с текстом с замаскированной водой. Например, безличные обороты часто увеличивают объем, не увеличивая смысла: "Я нажал кнопку ОК"/"Необходимо произвести нажатие кнопки ОК". Безличные обороты сложнее воспринимаются: там глагола либо вообще нет, либо он стоит где-то далеко от существительного, и мозгу труднее связать все части воедино, чтобы воссоздать картинку.
Есть еще стилистический аспект: безличные обороты тесно связаны с канцеляритом. Тексты с безличными оборотами — это чаще всего бюрократические/юридические документы. И когда человек начинает писать безличными оборотами — он часто сваливается в канцелярит, ведь это самый распространенный шаблон такого рода текстов. А это ужасно читается.
Поэтому — нет, не надо использовать безличные обороты. Вместо этого надо научиться ясно использовать "личные" обороты. Не надо писать от имени непонятного третьего лица — пишите от своего имени, но пишите ясно. Это тоже навык, но мне кажется — это более полезный навык, чем навык писать от имени "того парня"
Потому что научить компилятор разбирать комбинированные (сырые+параметризованные) выражения — это требует ресурсов, и усложняет и так непростую тему параметризованных типов. Какой профит будет от этой траты ресурсов?
Ответ: профит очень мал. Гораздо проще привести сырой тип руками к нужному параметризованному. Если у вас в проекте легаси код с сырыми типами — сделайте вокруг него обертку-адаптер.
Т.е. моя идея в том, что никто никогда не обещал сохранять сырые типы как "first class citizen". Их время ушло, давай, до свидания. Компилятор поддерживает их для обратной совместимости, но не более.
Мне кажется, здесь очень простая логика: любой сырой тип в выражении эквивалентен заявлению "я хочу работать в рамках java <1.5". Просто, понятно, легко запомнить.
Сырые типы оставлены для обратной совместимости. В современном коде их быть не должно — ну либо программист сам за себя в ответе. Спрашивается: зачем тратить ресурсы пытаясь научить компилятор расплетать выражения, комбинирующие сырые и параметризованные типы? Какой реальный профит это даст?
Даже если вам в код пришел сырой тип из какой-нибудь легаси библиотеки — гораздо проще его руками привести к "нужному" параметризованному, и дальше не знать горя (тут должна быть саркастическая усмешка).
Смотря для чего "помогает". Вынесение редких кусков кода в отдельный метод — это и в джаве стандартный прием. Он помогает и с логической точки зрения — основная задача отделена от вспомогательных, и часто помогает JIT-у, потому что часто выполняющийся метод становится короче, и с большей вероятностью вклеивается. Но не в этом случае
Тогда checkexpression устроится, а хелпер, бросающий exception, нет (что нам и нужно).
Нет, это не то, что нам нужно, ровно наоборот: с точки зрения escape-анализа если ссылка уходит в невклеенный метод — это значит, что она "убегает" за границы анализа, т.е. доступна неопределенному кругу лиц. И значит никакой скаляризации, точка.
… Кроме случая, когда холодная ветка кода прямо совсем уж холодная — вообще ни разу не вызывалась за время сбора профиля. Тогда JIT может спекулятивно предположить, что этот кусок никогда и не будет вызываться, и скомпилировать метод вообще без этого куска, вставив охранную проверку, uncommon trap, со ссылкой на полную версию метода в интерпретируемом режиме, и рекомпиляцию. Именно это здесь и происходит, когда вероятность попадания на исключение пренебрежимо мала.
Если же вероятность попадания в редкую ветку все-таки не нулевая — то выносить ее в отдельный метод с точки зрения скаляризации как раз-таки хуже, потому что редкий метод скорее всего не будет вклеен. Здесь я разбирал такое на примере HashMap
Что касается вывода результатов, то я во время первого просмотра ориентировался только на цвет, цифры осознал на второй-третий раз, и для этого понадобилось сознательное усилие.
Так я ведь именно это и задумывал: первый слой восприятия просто по цвету, зеленый/красный (насчет цветовой слепоты хороший момент, кстати, спасибо — последнее, о чем я бы стал сам думать), есть аллокация/нет аллокации. А если человеку что-то кажется подозрительным, то он всматривается, и цифры-то — вот они, тут же написаны.
Там, насколько я понимаю, оно не скачком в ноль уходит, а как-то более сложно себя ведёт.
В конкретной версии скомпилированного JIT-ом кода конкретная точка аллокации либо присутствует, либо стерта за счет EA/SR. Промежуточных вариантов нет, нельзя аллоцировать пол-объекта. То, что какие-то промежуточные варианты видны в результатах итераций это артефакт усреднения. Либо внутри итерации код перекомпилировался, либо просто точка аллокации проходится не на каждый вызов метода (т.е находится в какой-то не каждый раз берущейся ветке, как в примере с pair-or-null).
Но, что раз мы это уже столько обсуждаем — значит, не настолько это очевидно, как мне казалось.
Вообще, Роман, если вы будете писать как-нибудь пост про общие принципы — было бы интересно, как вы видите эту дилемму между "реалистичностью" (давать сырые результаты, как они получены — живые логи, цитаты из терминала, куски кода без купюр) и "наглядностью" (давать результаты в максимально удобной для однозначного прочтения форме) в технических презентациях.
Роман, спасибо большое за разбор. Я более чем согласен по большей части пунктов, но по парочке сомневаюсь:
Насчет SSA, например — я думал включить более подробное объяснение SSA еще когда планировал доклад. Но в итоге решил, что это слишком далекое отступление от основной темы. Тема single static assignment form вызывает слишком много вопросов — несложно рассказать что такое SSA, сложно ответить на сразу же возникающие вопросы типа "зачем/почему именно так". Отвечать на них нет времени (а то и квалификации — я все же не компиляторщик) — а без этих ответов, как мне кажется, просто непонятно, зачем о ней упоминать. Вводить новую большую сущность, которая лишь очень краем пересекается с основной темой рассказа, и не описать толком, почему эта сущность необходима, и что из себя представляет — это просто отвлекает внимание от основной темы, и не дает ничего взамен.
Поэтому я не стал раскрывать тему и когда термин "SSA" был произнесен — заранее решил, что игра не стоит свеч.
Если эскалировать эту ситуацию: мне кажется, что, в формате доклада на большую аудиторию — сохранить основной фокус и основную линию рассказа важнее, чем уточнять по ходу все детали. Детали можно уточнить и после. Поэтому я предпочитаю просто отрезать те ветки, которые не играют на основную задачу. Хотя я согласен, что "мы об этом сейчас не будем говорить" обычно звучит немного беспомощно :)
Насчет представления данных: тут для меня конфликт между двумя идеями.
Есть идея, что данные должны быть представлены в той форме, в которой они легче всего воспринимаются. Это, безусловно, график.
А есть идея, что, надо давать возможность зрителям побывать как можно ближе к реальности: увидеть реальные команды в терминале, например. Далее я показываю куски из логов компиляции — я бы мог, в пределе, вообще оставить только одну-две ключевых строки. Но мне кажется, что когда я даю больше контекста — я еще и даю зрителям возможность подготовиться к тому, что они сами увидят, когда попытаются сделать такие эксперименты сами. Ради этой возможности я оставляю больше лишнего текста (но выделяю важные элементы другими способами).
С результатами как раз такая история: я счел, что там не настолько сложное поведение, чтобы для него делать график, и лучше показать что-то похожее на реальный вывод бенчмарка. Кроме того, на графике видно количественное изменение, больше-меньше, а важно-то только качественное. Не важно (в контексте моего рассказа), сколько именно байт было аллоцировано — важно >0 (48) или =0(48). Например, на том же самом графике Preconditions (да и на многих других) были бы плавные переходы между разными версиями скомпилированного кода — но такие плавные переходы это артефакт методики измерения, они возникают за счет усреднения по итерации, состоящей из большого количества вызовов.
Вы что-то путаете. Никто из тех, кто занимается спортом, не жалуется на то, что он тратит время и ресурсы нервной системы. Люди приходят туда, чтобы научиться новому, прокачать скилы. И кстати, там никого ничего не заставляют.
Да нет, это вы просто мысль потеряли. Если вам сказали делать какое-то упражнение, чтобы потом лучше выполнять бросок, и вы месяц его делали — а потом осознали, что ничего нового вы не узнали, потому что, на самом-то деле вы и так уже этот бросок умели делать. Потому что вы его еще на дзюдо выучили. И вся разница в том, что там тот же самый бросок другими словами объясняли, и подводящие упражнения другие были — вот вы сразу и не уловили, что речь про то же самое. А тренеру и тем более пофигу было, ему проще всю группу заставить одно и то же делать, а не разбираться, кто там что уже знает.
… Так вот, в этой ситуации я считаю, что вы зря потратили месяц, и ресурсы нервной системы, ушедшие на то, чтобы понять, в чем же разница между тем, что вы и так умеете, и тем, чему вас пытаются научить. Но вы, конечно, можете считать, что просто здорово развлеклись.
На случай, если вы и здесь не улавливаете связи с TDD: я считаю, что принцип test first — это прежде всего педагогика. Он должен выстроить у человека определенный способ мышления. Если такой способ уже выстроен — то уже неважно, когда именно писать тесты. Если человек его выстроил у себя другим способом — нет необходимости месяц выполнять прописанные TDD ката, чтобы в итоге понять, что потратил месяц зря.
А я вам вернул ваш же пример: айкидо может быть эффективным, вот только далеко не все, что вас заставят заучивать — действительно важно для этой эффективности. Часть правил — просто порожняк, или лично вам не подходит — а вы тратите своё время и ресурсы нервной системы. Иначе айкидо было бы самым лучшим видом единоборств — а это, очевидно, не так.
Вам учителя прямо биомеханику объясняли? Точки приложения сил, действующие мышцы, рефлекторные паттерны активации мышц?.. или просто на пальцах что-то такое показали, что выглядело более-менее, а задавать каверзные вопросы никто не решился, потому что авторитет тренера, да и мы ж сюда пришли фигачить, а не разбираться?
Проблема с подходом "200 раз попробовать" в том, что человек ко всему привыкает. И через 200 раз уже не понятно: стало удобнее, или ты просто привык к неудобству? Как говорит старая поговорка — да, медведя можно научить ездить на велосипеде. Но будет ли от того медведю польза и удовольствие?
Это хорошо, что вы привели айкидо в пример: у меня много ассоциаций с телесными навыками возникает, но я их не приводил, потому что полагал, что программисты не поймут.
Так вот: движения в айкидо — как и любом другом виде единоборств — вовсе не какие-то особо естественные. В них есть определенные принципы, которые естественны. Но сами движения естественны только для Морихайи Уэсибы. В них полным-полно культурной и контекстуальной специфики создателя, времени и места их создания. Вам они просто со временем начинают казаться естественными — "стерпится-слюбится"
И проблема не только в этом, а ещё и в том, что учителя айкидо очень редко способны вменяемо обьяснить биомеханические принципы, лежащие в основе — чтобы ученик сам уже принимал решение, как ему эти принципы использовать. Чаще всего учителя айкидо вообще слова такого — биомеханика — не знают. Вместо этого основной принцип у них "делай как сказано".
Ну в том-то и дело, что если лошадь не эффективнее автомобиля — то это автомобиль лишний. И уж точно нет оснований всех агитировать пересаживаться на автомобиль. TDD как вы сами сказали — неестественно, и требует усилий. Если без неё даже и не лучше — это аргумент против, а не за
По-моему, инженерам очень свойственно переоценивать свои способности понимать психологию :) Например: одинаковые действия могут иметь для разных людей совсем разный (вплоть до противоположного) внутренний смысл, и приводить их мозги в совсем разные состояния. Это, вроде бы, очевидная вещь. Но почему-то мы забываем про это, когда начинаем отстаивать необходимость для всех программистов выполнять одни и те же действия при разработке.
Ведь очевидно, что с "материальной" точки зрения момент написания теста не имеет значения — конечные материальные артефакты одинаковы. Значит, момент написания должен как-то влиять именно на мозг разработчика, на его ход мышления. Но почему мы считаем, что для всех разработчиков предлагаемые действия будут оказывать одинаковый эффект на ход мышления? Мы что, правда считаем, что все разработчики так же одинаковы, как процессоры?
Это как-то еще можно считать оправданным, когда речь идет об обучении новичков. Ну, потому что у новичка с высокой вероятностью еще нет никакого способа думать о разработке — так почему бы не попробовать привить ему сразу удобный и общепринятый. (Я вот думаю, что было бы круто, если бы меня учили разрабатывать по TDD еще с молодости) Но когда речь идет об уже состоявшемся разработчике, с уже сформировавшимся способом думать — то большой вопрос, стоит ли ему себя переучивать на другой способ мышления. Будет ли от этого должный профит. Особенно когда мы пляшем не вокруг вопроса "нужны ли тесты вообще", а вокруг вопроса "написать ли мне тест сейчас, или когда я пойму, что он мне, наконец, понадобился".
Я вижу немало разработчиков, ставших адвокатами TDD уже в зрелости. Ну так, возможно, просто у них изначально "способ думать" был более совместим с этим подходом — отсюда и энтузиазм?
Для меня, например, сам процесс написания кода часто служит "способом думать". Я легко могу проследить, откуда это: я же физик-теоретик, и думать, пока руки, на автомате, выписывают уравнения, для меня очень естественно. Точно так же я думаю, пока руки пишут код. Тесты же я субъективно воспринимаю как аналог математического доказательства. Мало кто начинает доказывать теоремы строчка за строчкой кванторов, как они финально изложены в учебнике — обычно сначала на ощупь ищешь идею, а потом уже ее строго оформляешь. Вот и получается, что в моем способе мышления test first контринтуитивен, подходит разве что для очень простых сценариев, где "доказательство" сразу очевидно, и не надо думать.
… В общем, я воспринимаю TDD как фреймворк/набор библиотек — есть несколько компонентов, связанных общей идеей, и ты можешь составлять из них удобную тебе для работы конфигурацию. А не как боевой устав, который ты должен исполнять под страхом смерти независимо от реальной осмысленности его требований в данный момент.
Знаете в чем различие между действительно заинтересованным человеком — и фанатиком? Действительно заинтересованный человек сам себя спрашивает «а вдруг это не работает?», «а вдруг — работает вовсе не это?», «а вдруг — работает не во всех условиях?», «а вдруг — работает не все, а часть просто булшит?», «а вдруг — это просто привычка?». А фанатику такие вопросы задают со стороны — а он от них отмахивается, и продолжает цитировать святое писание.
У вас перед глазами сидел пример человека, который успешно разрабатывает отказываясь от одного из ваших принципов. И что, вы изменили свой принцип? Может, вы уточнили формулировку? Насколько я читаю — нет. Получается, что реальность не важна, святое писание важнее.
А насчет опытов: лично мне в жизни повезло. Я обучался ставить эксперименты в таком контексте, где не было заранее известных «правильных» ответов. Так что я знаю разницу между мотивацией «сдать физпрактикум на 5 за отведенное время», и искренним любопытством.
Отсутствие доказательной базы для большинства практик проектирования/разработки — не является извиняющим фактором. Да, никто не может объективно подтвердить, что его метод лучше других. Так что теперь, мы будем соревноваться в субъективной убедительности? Мы инженеры, или теологией занимаемся? Если уверенности нет — мне кажется, надо с этого и начинать: «уверенности нет». А не «в идеале практически все так должны работать, чтобы быть эффективными» — хотя на самом деле про эффективность есть только одно исследование.
Не, я не заметил диалога. Я заметил «я думаю, что действий больше» — «я думаю, что меньше». Мой фаворит «Это неправда». Для меня это не диалог, а попытка навязать свои догмы, в ситуации, когда объективных доказательств нет, а хочется быть правым.
«Есть лишь единичные сколько-либо достоверные исследования, доказывающие реальную эффективность TDD. В основном, вера в эффективность и необходимость TDD базируется на личном опыте и рекомендациях экспертов» — вот с этой фразы, кмк, апологетам TDD стоило бы начинать каждый свой пассаж. Во-первых, чтобы не вводить аудиторию в заблуждение давлением авторитета, а во-вторых, чтобы самому помнить, на каком зыбком основании стоят высказываемые утверждения.
Нет, правда: мне кажется очень странным непробиваемая уверенность в абсолютной необходимости TDD, при том, что эта уверенность основывается только на экспертном мнении, и одном-единственном исследовании. При всем уважении к экспертам, экспертное мнение — это самый низкий уровень доверия из тех, что вообще стоит рассматривать (ниже только агенство ОБС). Одно-единственное исследование это, конечно, лучше, чем ничего, но это совершенно точно не дает основания для такой убежденности. Мне кажется очень странным (если говорить мягко) что люди с инженерным/естественнонаучным образованием сами не замечают — -- и не говорят — на каком зыбком основании они стоят, делая столь уверенные заявления.
Что касается самой практики TDD: мне кажется, вся путаница возникает из-за того, что, по-сути, в TDD есть несколько компонент. Часть из них — инженерные, и их необходимость может быть достаточно строго обоснована при наличии достаточного количества исследований. Например, сама необходимость плотного покрытия кода тестами — для меня является именно инженерным компонентом. Можно провести измерения количества ошибок в коде с тестами и без тестов, можно выработать набор эвристик, позволяющих оценить вероятность пропустить ошибку в отсутствии тестов, можно оценить стоимость тестового покрытия — и, в итоге, пересчитать все на деньги. Сейчас это вряд ли кто-то делает, но лет через 10-15 это вполне вероятно, потому что сама задача выработки таких критериев не выглядит чем-то особо сложным.
А вот порядок действий — сначала тесты, или сначала код — это совершенно очевидно психологический компонент. Обсуждать его с позиций количества нажатий — по-моему, это почти бессмысленно, это как сравнивать языки программирования по количеству нажатий, требуемых для реализаций одинаковой функциональности. Можно подумать, скорость разработки определяется скоростью нажатия кнопок!
Порядок действий связан с тем, как человек думает, а не с тем, как он кнопки нажимает. И количество действий влияет на юзабилити не само по себе, а через тот эффект, который оно оказывает на поток мышления. Например, бОльшее количество действий может быть удобнее, если сами действия лучше соответствуют тому, как человек думает. И наоборот: меньшее количество действий, но идущих в разрез с моим потоком мышления могут очень сильно сбивать, обходясь тем самым очень дорого с когнитивной точки зрения
А думают все люди по-разному (ваш КО). Особенно по-разному думают люди, когда они, как специалисты, выросли в разных традициях, на разных практиках. Например, по тексту интервью я могу предположить, что когда Тагир думает о «формулировке задачи» (==что надо сделать) — для него эта формулировка выглядит как интерфейс будущего кода. А для Андрея та же «формулировка задачи» выглядит как тест для еще несуществующего кода. Важна ли эта разница? Мне кажется, нет. Мне кажется, важно, чтобы в мозгу инженера вообще была эта мысль «а что за задачу я сейчас решаю». Каким способом эта мысль в мозге разработчика поселилась — дело десятое. TDD предлагает один из методов вдолбить эту мысль в голову разработчика — но это явно не единственный метод. И уж если разработчик уже как-то сам себя приучил думать о формулировке задачи — то зачем ему теперь test first?
… Я даже скажу ещё более еретическую мысль: сформулировать заранее что хочешь получить — иногда может быть вредно, потому что зашоривает.
Тогда я не догадался записать, что за код смотрел, так что теперь уже точно не скажешь. Но было бы забавно, если я смотрел код, который автор просто забил/не успел соптимизировать — а я решил, что там умнейшая закладка на скаляризацию, и сел копать эту тему :)
Нет, это не лямбды Питера, это был очень простой метод, который возвращал пару объектов, заворачивая их в что-то вроде Pair. Что-то вроде метода lookup, который возвращает найденный объект + индекс позиции для вставки, если объекта нет. Пост Питера про лямбды я увидел уже позже.
И, кстати, у Питера странные вещи написаны: XX:MaxBCEAEstimateSize (как и все остальные ключи с BCEA) — это параметр _меж_процедурного EA, который используется не для скаляризации, а для lock elision. Почему это флаг у него как-то повлиял на скаляризацию (и действительно повлияло ли) — это большой вопрос.
Неплохое описание такого рода есть у Скота Ааронсона в его курсе по квантовым вычислениям (Квантовые вычисления от Демокрита...). Не вдаваясь в детали — он говорит очень простую вещь: вот у нас есть набор событий, и ассоциированные с ними вероятности. Как мы комбинируем эти вероятности, когда хотим посчитать вероятность сложного события? В "классическом" тервере для этого есть определенные правила комбинации. Но тервер — это всего лишь математическая абстракция, игра ума. Откуда следует, что реальные вероятности событий в реальном мире будут подчиняться именно этим правилам? Ниоткуда не следует, это просто экспериментальный факт. Мы сделали 100500 (классических) экспериментов, и выяснили, что такие правила комбинации вероятностей действительно приводят к совпадению с экспериментом.
… приводят, пока эксперимент классический. Когда мы начинаем комбинировать состояния квантовых систем, мы обнаруживаем, что нам нужны какие-то другие правила комбинации, потому что классические — не работают. Эти новые правила комбинации вероятностей — это, собственно, и есть все отличие квантовой теории от классической. Все наблюдаемые и операторы оттуда вытекают.
P.S. Искушенному математику, возможно, будет немного непривычно осознать, что природа не создана по математическим лекалам. Наоборот: математика создана из наблюдения за природой. В этом смысле любая физическая теория в конце-концов упирается в некоторые утверждения, которые "нипочему" — мир просто устроен вот так, и мы наблюдаем это в ощущениях (пусть даже опосредованно, обработав пентабайты данных с LHC)
Вот я присоединюсь: ваш текст для меня как раз хуже, чем чеклист. Потому что а) по объему гораздо больше чеклиста б) ценности дополнительной этот объем не несет
Ценностью может быть не только информация — это может быть развлечение, эмоциональное вовлечение, или своеобразная эмоциональная поддержка читателю. Но в вашем тексте этого нет.
Я согласен, что полезно уметь писать текст без воды. Это полезная практика: регулярно спрашивать себя, что пострадает если я вычеркну из предложения вот это слово?
Но многие люди путают текст без воды с текстом с замаскированной водой. Например, безличные обороты часто увеличивают объем, не увеличивая смысла: "Я нажал кнопку ОК"/"Необходимо произвести нажатие кнопки ОК". Безличные обороты сложнее воспринимаются: там глагола либо вообще нет, либо он стоит где-то далеко от существительного, и мозгу труднее связать все части воедино, чтобы воссоздать картинку.
Есть еще стилистический аспект: безличные обороты тесно связаны с канцеляритом. Тексты с безличными оборотами — это чаще всего бюрократические/юридические документы. И когда человек начинает писать безличными оборотами — он часто сваливается в канцелярит, ведь это самый распространенный шаблон такого рода текстов. А это ужасно читается.
Поэтому — нет, не надо использовать безличные обороты. Вместо этого надо научиться ясно использовать "личные" обороты. Не надо писать от имени непонятного третьего лица — пишите от своего имени, но пишите ясно. Это тоже навык, но мне кажется — это более полезный навык, чем навык писать от имени "того парня"
Занимаюсь. Но не так плотно, как aragozin.
Потому что научить компилятор разбирать комбинированные (сырые+параметризованные) выражения — это требует ресурсов, и усложняет и так непростую тему параметризованных типов. Какой профит будет от этой траты ресурсов?
Ответ: профит очень мал. Гораздо проще привести сырой тип руками к нужному параметризованному. Если у вас в проекте легаси код с сырыми типами — сделайте вокруг него обертку-адаптер.
Т.е. моя идея в том, что никто никогда не обещал сохранять сырые типы как "first class citizen". Их время ушло, давай, до свидания. Компилятор поддерживает их для обратной совместимости, но не более.
Мне кажется, здесь очень простая логика: любой сырой тип в выражении эквивалентен заявлению "я хочу работать в рамках java <1.5". Просто, понятно, легко запомнить.
Сырые типы оставлены для обратной совместимости. В современном коде их быть не должно — ну либо программист сам за себя в ответе. Спрашивается: зачем тратить ресурсы пытаясь научить компилятор расплетать выражения, комбинирующие сырые и параметризованные типы? Какой реальный профит это даст?
Даже если вам в код пришел сырой тип из какой-нибудь легаси библиотеки — гораздо проще его руками привести к "нужному" параметризованному, и дальше не знать горя (тут должна быть саркастическая усмешка).
Смотря для чего "помогает". Вынесение редких кусков кода в отдельный метод — это и в джаве стандартный прием. Он помогает и с логической точки зрения — основная задача отделена от вспомогательных, и часто помогает JIT-у, потому что часто выполняющийся метод становится короче, и с большей вероятностью вклеивается. Но не в этом случае
Нет, это не то, что нам нужно, ровно наоборот: с точки зрения escape-анализа если ссылка уходит в невклеенный метод — это значит, что она "убегает" за границы анализа, т.е. доступна неопределенному кругу лиц. И значит никакой скаляризации, точка.
… Кроме случая, когда холодная ветка кода прямо совсем уж холодная — вообще ни разу не вызывалась за время сбора профиля. Тогда JIT может спекулятивно предположить, что этот кусок никогда и не будет вызываться, и скомпилировать метод вообще без этого куска, вставив охранную проверку, uncommon trap, со ссылкой на полную версию метода в интерпретируемом режиме, и рекомпиляцию. Именно это здесь и происходит, когда вероятность попадания на исключение пренебрежимо мала.
Если же вероятность попадания в редкую ветку все-таки не нулевая — то выносить ее в отдельный метод с точки зрения скаляризации как раз-таки хуже, потому что редкий метод скорее всего не будет вклеен. Здесь я разбирал такое на примере HashMap
Так я ведь именно это и задумывал: первый слой восприятия просто по цвету, зеленый/красный (насчет цветовой слепоты хороший момент, кстати, спасибо — последнее, о чем я бы стал сам думать), есть аллокация/нет аллокации. А если человеку что-то кажется подозрительным, то он всматривается, и цифры-то — вот они, тут же написаны.
В конкретной версии скомпилированного JIT-ом кода конкретная точка аллокации либо присутствует, либо стерта за счет EA/SR. Промежуточных вариантов нет, нельзя аллоцировать пол-объекта. То, что какие-то промежуточные варианты видны в результатах итераций это артефакт усреднения. Либо внутри итерации код перекомпилировался, либо просто точка аллокации проходится не на каждый вызов метода (т.е находится в какой-то не каждый раз берущейся ветке, как в примере с pair-or-null).
Но, что раз мы это уже столько обсуждаем — значит, не настолько это очевидно, как мне казалось.
Вообще, Роман, если вы будете писать как-нибудь пост про общие принципы — было бы интересно, как вы видите эту дилемму между "реалистичностью" (давать сырые результаты, как они получены — живые логи, цитаты из терминала, куски кода без купюр) и "наглядностью" (давать результаты в максимально удобной для однозначного прочтения форме) в технических презентациях.
И спасибо вам за вашу работу.
Да никаких претензий, конечно. (я, оказывается, и не заметил, что это был ты)
То есть тебе было неудобно воспринимать результаты в виде цитаты вывода бенчмарка?
Роман, спасибо большое за разбор. Я более чем согласен по большей части пунктов, но по парочке сомневаюсь:
Насчет SSA, например — я думал включить более подробное объяснение SSA еще когда планировал доклад. Но в итоге решил, что это слишком далекое отступление от основной темы. Тема single static assignment form вызывает слишком много вопросов — несложно рассказать что такое SSA, сложно ответить на сразу же возникающие вопросы типа "зачем/почему именно так". Отвечать на них нет времени (а то и квалификации — я все же не компиляторщик) — а без этих ответов, как мне кажется, просто непонятно, зачем о ней упоминать. Вводить новую большую сущность, которая лишь очень краем пересекается с основной темой рассказа, и не описать толком, почему эта сущность необходима, и что из себя представляет — это просто отвлекает внимание от основной темы, и не дает ничего взамен.
Поэтому я не стал раскрывать тему и когда термин "SSA" был произнесен — заранее решил, что игра не стоит свеч.
Если эскалировать эту ситуацию: мне кажется, что, в формате доклада на большую аудиторию — сохранить основной фокус и основную линию рассказа важнее, чем уточнять по ходу все детали. Детали можно уточнить и после. Поэтому я предпочитаю просто отрезать те ветки, которые не играют на основную задачу. Хотя я согласен, что "мы об этом сейчас не будем говорить" обычно звучит немного беспомощно :)
Насчет представления данных: тут для меня конфликт между двумя идеями.
Есть идея, что данные должны быть представлены в той форме, в которой они легче всего воспринимаются. Это, безусловно, график.
А есть идея, что, надо давать возможность зрителям побывать как можно ближе к реальности: увидеть реальные команды в терминале, например. Далее я показываю куски из логов компиляции — я бы мог, в пределе, вообще оставить только одну-две ключевых строки. Но мне кажется, что когда я даю больше контекста — я еще и даю зрителям возможность подготовиться к тому, что они сами увидят, когда попытаются сделать такие эксперименты сами. Ради этой возможности я оставляю больше лишнего текста (но выделяю важные элементы другими способами).
С результатами как раз такая история: я счел, что там не настолько сложное поведение, чтобы для него делать график, и лучше показать что-то похожее на реальный вывод бенчмарка. Кроме того, на графике видно количественное изменение, больше-меньше, а важно-то только качественное. Не важно (в контексте моего рассказа), сколько именно байт было аллоцировано — важно >0 (48) или =0(48). Например, на том же самом графике Preconditions (да и на многих других) были бы плавные переходы между разными версиями скомпилированного кода — но такие плавные переходы это артефакт методики измерения, они возникают за счет усреднения по итерации, состоящей из большого количества вызовов.
Да нет, это вы просто мысль потеряли. Если вам сказали делать какое-то упражнение, чтобы потом лучше выполнять бросок, и вы месяц его делали — а потом осознали, что ничего нового вы не узнали, потому что, на самом-то деле вы и так уже этот бросок умели делать. Потому что вы его еще на дзюдо выучили. И вся разница в том, что там тот же самый бросок другими словами объясняли, и подводящие упражнения другие были — вот вы сразу и не уловили, что речь про то же самое. А тренеру и тем более пофигу было, ему проще всю группу заставить одно и то же делать, а не разбираться, кто там что уже знает.
… Так вот, в этой ситуации я считаю, что вы зря потратили месяц, и ресурсы нервной системы, ушедшие на то, чтобы понять, в чем же разница между тем, что вы и так умеете, и тем, чему вас пытаются научить. Но вы, конечно, можете считать, что просто здорово развлеклись.
На случай, если вы и здесь не улавливаете связи с TDD: я считаю, что принцип test first — это прежде всего педагогика. Он должен выстроить у человека определенный способ мышления. Если такой способ уже выстроен — то уже неважно, когда именно писать тесты. Если человек его выстроил у себя другим способом — нет необходимости месяц выполнять прописанные TDD ката, чтобы в итоге понять, что потратил месяц зря.
А я вам вернул ваш же пример: айкидо может быть эффективным, вот только далеко не все, что вас заставят заучивать — действительно важно для этой эффективности. Часть правил — просто порожняк, или лично вам не подходит — а вы тратите своё время и ресурсы нервной системы. Иначе айкидо было бы самым лучшим видом единоборств — а это, очевидно, не так.
Вам учителя прямо биомеханику объясняли? Точки приложения сил, действующие мышцы, рефлекторные паттерны активации мышц?.. или просто на пальцах что-то такое показали, что выглядело более-менее, а задавать каверзные вопросы никто не решился, потому что авторитет тренера, да и мы ж сюда пришли фигачить, а не разбираться?
Проблема с подходом "200 раз попробовать" в том, что человек ко всему привыкает. И через 200 раз уже не понятно: стало удобнее, или ты просто привык к неудобству? Как говорит старая поговорка — да, медведя можно научить ездить на велосипеде. Но будет ли от того медведю польза и удовольствие?
Это хорошо, что вы привели айкидо в пример: у меня много ассоциаций с телесными навыками возникает, но я их не приводил, потому что полагал, что программисты не поймут.
Так вот: движения в айкидо — как и любом другом виде единоборств — вовсе не какие-то особо естественные. В них есть определенные принципы, которые естественны. Но сами движения естественны только для Морихайи Уэсибы. В них полным-полно культурной и контекстуальной специфики создателя, времени и места их создания. Вам они просто со временем начинают казаться естественными — "стерпится-слюбится"
И проблема не только в этом, а ещё и в том, что учителя айкидо очень редко способны вменяемо обьяснить биомеханические принципы, лежащие в основе — чтобы ученик сам уже принимал решение, как ему эти принципы использовать. Чаще всего учителя айкидо вообще слова такого — биомеханика — не знают. Вместо этого основной принцип у них "делай как сказано".
И это мне очень напоминает изложение TDD.
Ну в том-то и дело, что если лошадь не эффективнее автомобиля — то это автомобиль лишний. И уж точно нет оснований всех агитировать пересаживаться на автомобиль. TDD как вы сами сказали — неестественно, и требует усилий. Если без неё даже и не лучше — это аргумент против, а не за
Да, я тоже примерно так пишу.
По-моему, инженерам очень свойственно переоценивать свои способности понимать психологию :) Например: одинаковые действия могут иметь для разных людей совсем разный (вплоть до противоположного) внутренний смысл, и приводить их мозги в совсем разные состояния. Это, вроде бы, очевидная вещь. Но почему-то мы забываем про это, когда начинаем отстаивать необходимость для всех программистов выполнять одни и те же действия при разработке.
Ведь очевидно, что с "материальной" точки зрения момент написания теста не имеет значения — конечные материальные артефакты одинаковы. Значит, момент написания должен как-то влиять именно на мозг разработчика, на его ход мышления. Но почему мы считаем, что для всех разработчиков предлагаемые действия будут оказывать одинаковый эффект на ход мышления? Мы что, правда считаем, что все разработчики так же одинаковы, как процессоры?
Это как-то еще можно считать оправданным, когда речь идет об обучении новичков. Ну, потому что у новичка с высокой вероятностью еще нет никакого способа думать о разработке — так почему бы не попробовать привить ему сразу удобный и общепринятый. (Я вот думаю, что было бы круто, если бы меня учили разрабатывать по TDD еще с молодости) Но когда речь идет об уже состоявшемся разработчике, с уже сформировавшимся способом думать — то большой вопрос, стоит ли ему себя переучивать на другой способ мышления. Будет ли от этого должный профит. Особенно когда мы пляшем не вокруг вопроса "нужны ли тесты вообще", а вокруг вопроса "написать ли мне тест сейчас, или когда я пойму, что он мне, наконец, понадобился".
Я вижу немало разработчиков, ставших адвокатами TDD уже в зрелости. Ну так, возможно, просто у них изначально "способ думать" был более совместим с этим подходом — отсюда и энтузиазм?
Для меня, например, сам процесс написания кода часто служит "способом думать". Я легко могу проследить, откуда это: я же физик-теоретик, и думать, пока руки, на автомате, выписывают уравнения, для меня очень естественно. Точно так же я думаю, пока руки пишут код. Тесты же я субъективно воспринимаю как аналог математического доказательства. Мало кто начинает доказывать теоремы строчка за строчкой кванторов, как они финально изложены в учебнике — обычно сначала на ощупь ищешь идею, а потом уже ее строго оформляешь. Вот и получается, что в моем способе мышления test first контринтуитивен, подходит разве что для очень простых сценариев, где "доказательство" сразу очевидно, и не надо думать.
… В общем, я воспринимаю TDD как фреймворк/набор библиотек — есть несколько компонентов, связанных общей идеей, и ты можешь составлять из них удобную тебе для работы конфигурацию. А не как боевой устав, который ты должен исполнять под страхом смерти независимо от реальной осмысленности его требований в данный момент.
У вас перед глазами сидел пример человека, который успешно разрабатывает отказываясь от одного из ваших принципов. И что, вы изменили свой принцип? Может, вы уточнили формулировку? Насколько я читаю — нет. Получается, что реальность не важна, святое писание важнее.
А насчет опытов: лично мне в жизни повезло. Я обучался ставить эксперименты в таком контексте, где не было заранее известных «правильных» ответов. Так что я знаю разницу между мотивацией «сдать физпрактикум на 5 за отведенное время», и искренним любопытством.
Не, я не заметил диалога. Я заметил «я думаю, что действий больше» — «я думаю, что меньше». Мой фаворит «Это неправда». Для меня это не диалог, а попытка навязать свои догмы, в ситуации, когда объективных доказательств нет, а хочется быть правым.
Нет, правда: мне кажется очень странным непробиваемая уверенность в абсолютной необходимости TDD, при том, что эта уверенность основывается только на экспертном мнении, и одном-единственном исследовании. При всем уважении к экспертам, экспертное мнение — это самый низкий уровень доверия из тех, что вообще стоит рассматривать (ниже только агенство ОБС). Одно-единственное исследование это, конечно, лучше, чем ничего, но это совершенно точно не дает основания для такой убежденности. Мне кажется очень странным (если говорить мягко) что люди с инженерным/естественнонаучным образованием сами не замечают — -- и не говорят — на каком зыбком основании они стоят, делая столь уверенные заявления.
Что касается самой практики TDD: мне кажется, вся путаница возникает из-за того, что, по-сути, в TDD есть несколько компонент. Часть из них — инженерные, и их необходимость может быть достаточно строго обоснована при наличии достаточного количества исследований. Например, сама необходимость плотного покрытия кода тестами — для меня является именно инженерным компонентом. Можно провести измерения количества ошибок в коде с тестами и без тестов, можно выработать набор эвристик, позволяющих оценить вероятность пропустить ошибку в отсутствии тестов, можно оценить стоимость тестового покрытия — и, в итоге, пересчитать все на деньги. Сейчас это вряд ли кто-то делает, но лет через 10-15 это вполне вероятно, потому что сама задача выработки таких критериев не выглядит чем-то особо сложным.
А вот порядок действий — сначала тесты, или сначала код — это совершенно очевидно психологический компонент. Обсуждать его с позиций количества нажатий — по-моему, это почти бессмысленно, это как сравнивать языки программирования по количеству нажатий, требуемых для реализаций одинаковой функциональности. Можно подумать, скорость разработки определяется скоростью нажатия кнопок!
Порядок действий связан с тем, как человек думает, а не с тем, как он кнопки нажимает. И количество действий влияет на юзабилити не само по себе, а через тот эффект, который оно оказывает на поток мышления. Например, бОльшее количество действий может быть удобнее, если сами действия лучше соответствуют тому, как человек думает. И наоборот: меньшее количество действий, но идущих в разрез с моим потоком мышления могут очень сильно сбивать, обходясь тем самым очень дорого с когнитивной точки зрения
А думают все люди по-разному (ваш КО). Особенно по-разному думают люди, когда они, как специалисты, выросли в разных традициях, на разных практиках. Например, по тексту интервью я могу предположить, что когда Тагир думает о «формулировке задачи» (==что надо сделать) — для него эта формулировка выглядит как интерфейс будущего кода. А для Андрея та же «формулировка задачи» выглядит как тест для еще несуществующего кода. Важна ли эта разница? Мне кажется, нет. Мне кажется, важно, чтобы в мозгу инженера вообще была эта мысль «а что за задачу я сейчас решаю». Каким способом эта мысль в мозге разработчика поселилась — дело десятое. TDD предлагает один из методов вдолбить эту мысль в голову разработчика — но это явно не единственный метод. И уж если разработчик уже как-то сам себя приучил думать о формулировке задачи — то зачем ему теперь test first?
… Я даже скажу ещё более еретическую мысль: сформулировать заранее что хочешь получить — иногда может быть вредно, потому что зашоривает.
И, кстати, у Питера странные вещи написаны: XX:MaxBCEAEstimateSize (как и все остальные ключи с BCEA) — это параметр _меж_процедурного EA, который используется не для скаляризации, а для lock elision. Почему это флаг у него как-то повлиял на скаляризацию (и действительно повлияло ли) — это большой вопрос.
… приводят, пока эксперимент классический. Когда мы начинаем комбинировать состояния квантовых систем, мы обнаруживаем, что нам нужны какие-то другие правила комбинации, потому что классические — не работают. Эти новые правила комбинации вероятностей — это, собственно, и есть все отличие квантовой теории от классической. Все наблюдаемые и операторы оттуда вытекают.
P.S. Искушенному математику, возможно, будет немного непривычно осознать, что природа не создана по математическим лекалам. Наоборот: математика создана из наблюдения за природой. В этом смысле любая физическая теория в конце-концов упирается в некоторые утверждения, которые "нипочему" — мир просто устроен вот так, и мы наблюдаем это в ощущениях (пусть даже опосредованно, обработав пентабайты данных с LHC)