Архив недели @dbg_nsk
Понедельник
Всем привет!
На этой неделе с вами буду я - Ваня Углянский (@dbg_nsk) - простой сибирский JVM инженер из команды Excelsior@Huawei.
Найдется ли у вас минутка поговорить о священной книге нашей - JVM спецификации?
Шучу! Про спеку будет, но совсем немного. В конце концов, это ведь не столько технический аккаунт, а скорее зарисовки и персональные истории из разных частей IT?
Вот этим и займемся: расскажу свою историю системного программиста и не только.
Коротко, кто я:
- с 2011 участвую в разработке JVM-ов
- до 2019 работал над Excelsior JET - независимой JVM с AOT компилятором
- с 2019 в Huawei
- специализируюсь на рантайме: GC, профилировка, etc
- преподаю в универе (C, С++)
- делаю митапы в Новосибе
- бесстыдно щитпощу в тви
О чем хочу поговорить:
Что это вообще значит - разрабатывать JVM? (она ведь вроде как уже есть)
Будни JVM инженера
О чем молчит спека? Бывает ли в Java UB?
Бенчировать или не бенчировать?
Хардкорные доклады и статьи
А не из технического:
10 лет в одной команде - как ощущения?
Есть ли жизнь в российской провинции?
Как сделать местное комьюнити от первого митапа до своей конфы
Преподавание: как и зачем?
Сюрприз тема
Буду миксовать технические и нетехнические темы, чтобы было разнообразие.
Если у вас есть какие-нибудь еще вопросы или темы для обсуждения, то напишите в реплаях, постараюсь сориентироваться.
Пункт "почему интеловский ассемблерный синтаксис гораздо лучше AT&T" я все-таки вычеркнул, чтобы не быть сильно токсичным.
Скоро начнем, а пока пара дисклеймеров.
Я не буду говорить, что именно делаю сейчас в Huawei, это под очень жестким NDA. Максимум про какие-то свои ощущения, но это и все.
Ну и то, что я буду говорить - это исключительно мое личное мнение, и никак не отражает взгляды моего работодателя.
В общем, у меня лапки!
Я буду рассказывать именно свою историю и абсолютно не буду претендовать на вселенскую истину, ваш опыт может сильно отличаться от моего, и это же отлично.
Узнаете что-нибудь новое, поделитесь своим опытом в реплаях - win-win.
Все, теперь можем начинать.
@itunderhood Расскажи ещё чо там эксцельсиор? Законсервировали? Подох? Его съел Хуавей? Ещё что-то случилось? Что же будет с родиной и с нами^W тем вашим AOT-ом?
Ребята, не стоит вскрывать эту тему. Вы молодые, шутливые, вам все легко. Это не то. Это не Чикатило и даже не архивы спецслужб. Сюда лучше не лезть. Серьезно, любой из вас будет жалеть. Лучше закройте тему и забудьте. Я вполне понимаю, что данным сообщением вызову... twitter.com/skv_nskv/statu…
@itunderhood @dbg_nsk Верит ли ваша конфессия в священный грааль?
Это очень сложный теологический вопрос!
Удивительным образом наш разговор на этой неделе раз за разом будет возвращаться к священном Граалю twitter.com/tagir_valeev/s…
Что еще за род деятельности такой - JVM-инженер?
Небольшой вводный тред 🧵
Вы, наверное, слышали, про такой язык - Java. 25 лет на рынке, второе (ух, вот это удар, долгое время было первое!) место в рейтинге TIOBE, шутки про нелаконичный синтаксис.
Так вот, Java - это managed язык, который работает на Java Virtual Machine (JVM).
JVM реализует все те приятные особенности managed языков, к которым мы так привыкли: автоматическое управление памятью (в т.ч. GC), безопасные операции, универсальность кода при разработке по разные целевые архитектуры.
Но на самом деле JVM (сюрприз) - это ведь тоже программа, которую нужно разрабатывать, отлаживать, разгонять. Клиенты этой программы - другие программисты, использующие Java, Kotlin, Scala
Вот собственно разработкой этих программ JVM-инженеры и занимаются
Вот так все просто!
Тут стоит сказать, что люди, реализующие языки программирования (компиляторщики и рантаймщики), часто (?) называют себя общим термином "системные программисты", туда же относят писателей операционных систем или драйверов.
Всех их объединяет крепкая связь с низким уровнем.
Возвращаемся к JVM
Люди часто путают понятия JVM, Hotspot и OpenJDK, после чего говорят мне: "а, т.е. ты работаешь в Oracle?"
На самом деле, все не так просто, и JVM-ов есть огромное множество.
Как именно должна работать виртуальная машина зафиксировано в нашем священном писании - JVM спецификации (не путать с Java спецификацией, это разные документы)
При этом книга эта оставляет огромное пространство для маневра в реализации
Этой свободой люди активно пользуются, чтобы создавать различные, специализированные под конкретные сценарии, виртуальные машины.
Hotspot - лишь одна из реализаций, от которой, правда отпочковалось много других после того, как ее код открыли.
Но существуют и абсолютно независимые реализации JVM, например, OpenJ9 от компании IBM.
Довольно долго существовала такая реализация и у нас: называлась Excelsior JET, отличалась ставкой на AOT компиляцию Java. В ее разработке я успел активно поучаствовать.
В общем, JVM-ов в мире есть огромное множество, кто-то из них дальше ушел от Hotspot-а, кто-то ближе.
Такое разнообразие создает эффект гонки вооружений: кто круче реализует тот или иной компонент виртуальной машины, чтобы приложения пользователей работали быстрее и лучше.
А кто-то даже отходит от спеки и создает что-то совсем свое (привет, GraalVM)
В любом случае, работы здесь хватает: поддержка новых фич языка, разработка и реализация новых алгоритмов, разгон JVM, портирование на новое железо. Всем этим занимаются JVM инженеры из разных команд
Лайфхак: в следующий раз, когда кто-то начнет рассказывать вам: "а вот в Java/JVM под капотом сделано так-то", резко прервите его фразой: "а в какой конкретно реализации Java?"
Собеседник потеряется (либо наоборот, просияет), а вы будете выглядеть очень шарящим
так, нам нужен пакет с пакетами.
здесь будет тред всех тредов, в конце его перепощу 🧵
Шучу! Про спеку будет, но совсем немного. В конце концов, это ведь не столько технический аккаунт, а скорее зарисовки и персональные истории из разных частей IT? Вот этим и займемся: расскажу свою историю системного программиста и не только.
тред с представлениями: twitter.com/itunderhood/st…
Что еще за род деятельности такой - JVM-инженер? Небольшой вводный тред 🧵
кто такие JVM-инженеры?twitter.com/itunderhood/st…
Что-то я все о себе, да о себе.
Давайте поговорим о вас!
К какой части IT вы себя относите? 1/2
или же
кстати, в компиляторах тоже есть понятия frontend и backend, но значит это совсем другое!
под frontend-ом обычно понимают часть компилятора, отвечающую за первичную обработку исходного кода программы,
а под backend-ом - финальную часть, генерирующую уже собственно машинный код
@itunderhood Обидеть десктоп-программиста может каждый.
ничего подобного, я хорошо отношусь ко всем гендерам! twitter.com/tagir_valeev/s…
так, ну все, в реплаях набралось профессий еще на один опрос, почему бы его и не добавить?
А может вы:
Вторник
Доброго утра всем, кроме внезапных туманных морозов!
Как у вас с погодой?
Продолжаем! Теперь давайте немного расскажу про особенности нашей работы, "будни JVM-инженера" и немного про стереотипы о нас, с которыми я сталкивался.
Опять все чисто со своей колокольни, так что это конечно будет истина в последней инстанции.
При разработке JVM часто встают задачи, которые раньше вообще не решались, либо решались редко. Из-за постоянной гонки JVM вооружений мы находимся на переднем крае науки/инженерии
Чтение научных статей по работе - частая ситуация. Написание, увы, чуть более редкая, но бывает
С другой стороны, между изложением идеи в статье (и даже созданием прототипа) и реализацией этой идеи в боевой JVM присутствует огромная пропасть.
Да и вообще, кажущаяся простота многих алгоритмов разбивается о детали реализации. Гладко было на бумаге, да забыли про овраги.
И вот сам процесс реализации научной идеи на практике, переход от академии к инженерии, он очень интересный и вдохновляющий что ли.
Не так давно это было идеей в твоей голове, а спустя сколько-то месяцев бац! и оно реально работает (а бенчи показывают хорошие цифры)
С пропастью между идеей и реализацией в боевой JVM связан первый стереотип. От людей далеких от JVM несколько раз слышал: "а чего это так долго делают GC? Этож просто DFS, обошел граф в глубину и ура".
Действительно, и чего это люди всё новые алгоритмы GC изобретают
При разработке JVM ты вынужденно сталкиваешься с более низким уровнем абстракции: ассемблерные инструкции, регистры, стек и т.д.
Это не значит, что мы много прям пишем на ассемблере, но генерация кода, отладка и профилировка - все это уже про асм.
В какой-то момент мне стало удобнее при возникновении проблемы в методе сначала смотреть породившийся асм, а уж потом исходник на Java.
Я уже даже не вижу там mov, push, lea. Я вижу девиртуализованый вызов, gc-point или стек-чек.
на всякий случай: я не считаю, что программисты, взаимодействующие с низким уровнем чем-то лучше тех, кто работает на более высоком (мне почему-то часто это предъявляют).
конечно нет, у нас всех свой уровень абстракции, общих принципов и сути то это не меняет.
Собственно про низкий уровень очередной стереотип.
Про нас иногда говорят что-то в духе "битики туда сюда перегоняют", подразумевая, что мы и основную разработку ведем именно на асме.
Это, конечно, не так.
Попробуйте реализовать большую и сложную систему (типа GC) на асме, вы просто умрете. Чем удобнее язык для разработки таких систем, тем лучше.
asm для нас - результат работы компилятора. В очень редких случаях - инструмент написания performance critical кода
А вот битики - да, гоняем.
Свободный бит в заголовке объекта - безумно редкий и дорогой ресурс, выбить его под свои задачи - большая удача.
Далее, люди думают, что раз уж не асм, то обязательно нужно использовать для разработки JVM языки C или C++. Укрепляет этот стереотип и то, что Hotspot, например, написан именно на плюсах.
Но и это тоже всего лишь один из вариантов.
Опять таки: вряд ли кому-то нравится писать сложные системы на C/C++ (из-за их низкой надежности). А JVM - это сложная система, даже очень.
Оказывается, что некоторые модули виртуальной машины можно отлично написать на managed языках. Например, на Java или Scala.
Отличным примером может являться проект GraalVM. Одна из его составных частей - компилятор Graal, написанный на Java.
Более того, в другой его составной части Substrate VM даже и рантайм написан на особом диалекте Java, с некоторыми ухищрениями.
Понятно дело, что тут возникают интересные вопросы бутстрапа и самоприменимости, но все они разрешимы (спасибо уже существующим reference реализациям)
Так что бывают команды вполне себе разрабатывающие JVM-ы в Intellij IDEA
...и я искренне надеюсь, что за этим будущее. Ну или может за растом, но точно не за написанием JVM на плюсах, это уж слишком error prone
--
Заметили, что мы опять упомянули GraalVM? Второй раз за два дня. Только и разговоров, что о священном Граале
При разработке JVM я лично очень часто сталкиваюсь с эффектом бабочки. Меняешь что-то в одной компоненте, и это совершенно причудливым (на самом деле нет) образом влияет на абсолютно, казалось бы, несвязанную компоненту.
Отследить такие связи заранее бывает очень сложно.
Я говорю о том, как слишком агрессивная оптимизация генерации кода может нарушить работу GC, как изменение в профилировке кода может отломать отгрузку классов, как изменение в GC ломает вызов нативных методов.
Представляете, как весело выбирать assignee в jira?
Вообще, баги в JVM - бесконечная тема.
Моя любимая категория багов в JVM - спорадичные! Если JVM крешается при каждом запуске, то это не такой уж и сложный баг.
Гораздо веселее баги проявляющиеся только иногда, скажем, раз в 10000 запусков (это все еще неплохой вариант)
Спорадичность багов объясняется тем, что каждый запуск JVM непохож на другие
Отличаются моменты прихода GC и работа, которую он делает; отличается порядок перекомпиляции методов; отличаются пути исполнения в зависимости от входных данных, наконец
Не стоит забывать и о фазе луны
В общем, некоторые баги проявляются при очень редком стечении обстоятельств
Мой рекорд - баг, проявлявшийся раз в год (это при еженочном тестировании на огромном тестсьюте). Отладил со второй попытки.
Но это исключение, конечно. Креш раз в две недели - куда более реальная штука
Вот и как такое отлаживать? Допустим, у вас развал, проявляющийся раз в 10000 запусков при нагрузочном тестировании. Что будете делать?
Конечно, первое, что хочется сделать - поймать развал в отладчике.
Увы, спорадичные баги не любят отладчики. Скорее всего, запуская в gdb, вы разрушите те самые специфические условия и тайминги, которые проявляют проблему.
Следующая идея после отладчика - вставить отладочную печать. Неплохо и иногда даже помогает.
Но если место довольно часто исполняется, то вместо ответа вы получите гигабайты логов.. и снова спугнете баг (тайминги, помните, логи все испорят).
Остается только делать подробнейшие крешдампы, которые расскажут максимум информации о состоянии системы в момент развала. В идеале, конечно, получить еще и coredump
Именно поэтому в крешдампы у того же хотспота такие большие. Со сложными багами это все, что у вас есть
@itunderhood А что такое развал? Как инженеру по нагрузочному тестированию мне интересно
а вот это отличный вопрос!
обычно я сталкиваюсь с неожиданным SIGSEGV во внутренностях JVM.
но это уже довольно хороший сценарий! куда хуже, если все продолжает работать, но исходная Java программа начинает исполняться неправильно. Бывает и такое.
twitter.com/think_not_thin…
Еще один (древнейший) способ отладки: метод пристального вглядывания в код. Помогает гораздо чаще, чем вы могли бы подумать.
А еще: специальные режимы сборки JVM, проверяющие внутренние инварианты на каждом шагу.
В этом плане мы, конечно, немного параноики
Вдогонку про креши: к сожалению развалы из-за багов JVM часто трудно отличить от развалов из-за испорченного железа, на котором она работает.
Часто раскопки таких развалов заканчиваются советом пользователю проверить, не битые ли у них диск/память.
Поэтому, увидев, что ваша JVM спорадично крешнулась, вы можете сами отсечь довольно вероятную причину проблемы, проверив память на вашей машине
Про это отлично писал @shipilev вот здесь: shipilev.net/jvm/test-your-…
Если так сделаете, то сразу получите плюс вам в карму лично от меня
@itunderhood etolstoy.com/frontend-syndr…
отличный пост от Егора!
не нужно комплексовать из-за уровня абстракции, на котором вы программируете, у каждого из нас есть более низкий уровень, до которого мы не опускаемся.
но я, конечно, за то, чтобы интересоваться другими уровнями абстракции (как вниз, так и вверх!) twitter.com/igrekde/status…
Бенчи, ну куда уж без них.
С учетом эффекта бабочки и постоянного желания исполнять Java программы пользователей быстрее, необходимо все время контролировать: а не просадила ли очередная правка производительность.
Если да, то готовы ли мы на этой пойти? (бывает и такое)
Для этого используются как принятые в индустрии стандартные бенчи типа SpecJBB, так и что-то более кастомное, полученное, например, из реальных приложений.
Варьируются они и по размеру: от микробенчмарков до настоящих толстяков. Но подробнее про бенчирование поговорим отдельно.
При разработке JVM появляется привычка задавать вопрос "а как это работает?" на любую фичу языка (ведь собственном мы этим и занимаемся - реализуем фичи managed языков, которые для пользователя работают из коробки).
С этой стороны очень интересно изучать новые языки, а потом сравнивать их реализации. Я люблю смотреть, а как та или иная фича сделана в Go, в .NET, да даже в плюсах
Особенно интересно смотреть на все это в исторической перспективе, как реализация менялась и эволюционировала
Как-то я приходил на подкаст @generictalks, где мы с ребятами в таком вот ключе посравнивали GC в Java и в Go
Мне кажется, получилось довольно интересно и познавательно, как для джавистов, так и для гошников
Запись: youtu.be/RbMcJdHOCjc
(вообще, подкаст топовый, рекомендую)
Завершая тред на мажорной ноте, скажу, что разработка JVM - это потрясающе интересно
Это такой уникальной сплав науки и инженерии, настоящее путешествие при переходе от высокого уровня к низкому и захватывающий детектив при отладке вылезающих проблем
Короче, люблю это дело!
Продолжаем! Теперь давайте немного расскажу про особенности нашей работы, "будни JVM-инженера" и немного про стереотипы о нас, с которыми я сталкивался. Опять все чисто со своей колокольни, так что это конечно будет истина в последней инстанции.
зарисовки из жизни JVM-инженеров
twitter.com/itunderhood/st…
@itunderhood Так. А как определяется, что Java программа стала работать неправильно?
еще один отличный вопрос
что такое правильно работающая Java программа написано в спеках. Если программа работает не по спеке - значит, что-то не так!
а как понять, что JVM правильно реализует спеку? Для этого есть специальные сертифицированные наборы тестов: JCK (~117к тестов) twitter.com/Bloodalan/stat…
не могу определиться, про что рассказывать следующим, поэтому спрошу у вас!
что хотите сначала: рассказ про личное (как я стал системным программистом и остался в одной команде на 10 лет) или техническое (про undefined behaviour в Java)?
@itunderhood Расскажи про какие-нибудь кейсы намеренного нарушения спеки ради оптимизаций
хе-хе, ктож в таком признается :)
несоответствие спеке - повод наехать на создателей JVM, создав соответствующий ишуй у них в багтрекере.
если, конечно, эта JVM хочет носить гордое имя "Java compatible" (а пользоваться другими - дело довольно рискованное). twitter.com/lightdelay/sta…
Среда
не могу определиться, про что рассказывать следующим, поэтому спрошу у вас! что хотите сначала: рассказ про личное (как я стал системным программистом и остался в одной команде на 10 лет) или техническое (про undefined behaviour в Java)?
доброе утро!
тогда начнем с личной истории.
но не беспокойтесь, про UB тоже расскажу (во второй половине дня) twitter.com/itunderhood/st…
Итак, за предыдущие два дня у вас должно было появиться какое-то представление о том, чем я вообще занимаюсь.
Сейчас расскажу, как я вообще попал в JVM разработку, какой у меня был "карьерный путь", и как я разок сходил в enterprise разработку на год.
Началось все, когда я был на третьем курсе МехМата НГУ
Довольно банально: нужно было выбирать научрука, мне очень нравилась программировать, я стал думать, куда пойти, чтобы этим заниматься… ну, вы знаете, как это бывает, потерянные студенты, которым нужно что-то срочно решать
За несколько лет до этого меня (тогда еще школьника) обучал потрясающий @mraleph.
Он впервые показал мне плюсы (тогда еще старые, до 11-ых), рассказал про основы трансляции и курировал проект простенького транслятора выдуманного языка (жутко похожего на Lua, как я потом понял)
Черт, похоже, что все началось не на третьем курсе! Ну ладно, не суть.
Смысл в том, что @mraleph работал в Excelsior, где собственно был JVM-инженером. От него то я и узнал про компанию, и что вообще можно такими делами заниматься
И вот на своем третьем курсе я про все это вспомнил и решил попробовать пройти на стажировку в этот Excelsior
Мы с одногруппником порешали задачки (отдельно), прошли собеседование.. и в результате прошли на стажировку тоже!
Кстати, на данный момент это последнее собеседование, на котором я присутствовал.
Чтобы вы понимали: стажировка на JVM-инженера - это очень долгий процесс, он длится месяцы и даже годы. В нашем случае, он заканчивался защитой диплома бакалавра, что произошло через 1.5 года.
А что вы хотели? Контекст, который нужно вписать, просто гигантский
Я уже много где рассказывал про то, как у нас проходила стажировка, т.к. считаю это очень крутым и уникально поставленным процессом
Например, про это можно почитать вот здесь:
habr.com/ru/company/jug… (только учтите, что остальная информация кроме стажировок сильно устарела)
Добавлю только, что ощущения от стажировки у меня были следующие:
Во-первых, я осознал, насколько же я не шарю. Я пришел на стажировку в полной уверенности, что я уже много чего знаю (я ведь транслятор делал!!). На самом деле контекста у меня было чуть меньше, чем ноль.
Во-вторых, я понял, насколько крутые люди в Excelsior работают! Как много они знают, как могут предсказывать влияние той или иной правки на всю JVM, как божественно они отлаживают.
Черт, да как же они хороши. Были и есть.
Ну и в-третьих, я потихоньку стал въезжать в то, что происходит в JVM. Как маленькие кирпичики стали появляться вспышки понимания, которые со временем складывались в цельную картину.
Это очень-очень необычное ощущение, как будто у тебя появляется новый орган чувств.
Тем не менее, процесс шел слишком медленно, и под конец четвертого курса я был скорее разочарован в себе, чем воодушевлен. Защитил довольно слабенький (по меркам Excelsior, конечно) диплом, и думал, что делать дальше.
Мягко говоря, я не был уверен, что системщина - это мое.
И тут случилось очень неожиданное, но важное событие.
Нас с @pjBooms временно перекинули на другой проект, никак не связанный с JVM.
Это был такой классический enterprise, где надо было делать что-то типа dropbox-а. На Java, со спрингом, liquibase и вот этим всем.
Мне сначала очень понравилось! Все такое новое, я хватался за все таски, во все старался вникнуть, никогда в жизни так много не писал на Java и действительно кайфовал.
К тому же результат был куда более наглядный, чем при копании в JVM, и это был приятный контраст.
Мое участие в проекте продлилось чуть меньше года.
И за это время от начального возбуждения я дошел до настоящей тоски по всему тому, что я рассказывал вам в предыдущие дни.
С каждый следующим днем в enterprise разработке меня тянуло обратно в системщину.
И вот где-то в этот момент я и понял, что enterprise - это просто не совсем мое.
В тоже самое время у меня дико попер магистерский диплом, который на радость мне, как водоворот засасывал меня обратно в мир компиляторов и рантаймов.
За оставшееся время я написал магистерский диплом, которым до сих пор горжусь, который потом был продуктизирован и вошел в JET, и который потом вполне мог бы стать диссером, если бы я захотел.
А сам я понял, что системщина - это для меня то самое, и продолжил в этом развиваться
Такие дела!
Иногда нужно свернуть с пути и пробовать что-то другое, чтобы понять, что твой изначальный путь - правильный. (с) Джейсон Стетхем-Конфуций
Развиваться в системщине я все эти годы продолжал в одной и той же команде
В нашем деле есть бесконечное количество R&D задач, которые обеспечивают (мне) нескончаемый драйв, челендж и простор для обучения
Так что из-за скуки или "предела роста" уйти не получится
Кроме того, очевидно, что наше занятие - оно не для всех, чисто по техническим причинам. Кому-то захочется быстрее видеть результат своей работы, кому-то не нравится прикасаться к низкому уровню.
Поэтому, естественным образом остаются только единомышленники.
И вот представьте: люди, с которыми вы на одной волне, каждый из которых - крутой спец в нашей области, с которыми вы, наконец, росли вместе эти 10 лет.
Для меня эти люди стали гораздо больше, чем просто коллегами.
Поэтому отвечая на вопрос из самого начала треда "как это - работать в одной команде 10 лет?", скажу, что это в моем случае это просто огромная удача, вот и все.
И люди - это одна из причин, почему мне нравится приходить на работу каждый день.
И это не я такой консервативный: очень многие в команде здесь уже по многу лет. Кто 5, кто 7, а кто и 20.
Для внешнего мира, где принято менять работу раз в пару лет, это может показаться диким, но надеюсь, я объяснил, почему для нас это вполне естественно.
В качестве заключения: оставаться в одной команде долгие годы - это необязательно значит засиживаться, деградировать и отставать в развитии.
Если у вас есть возможность продолжать расти вглубь, а вас окружают ваши люди, то это отличный и гармоничный вариант.
Итак, за предыдущие два дня у вас должно было появиться какое-то представление о том, чем я вообще занимаюсь. Сейчас расскажу, как я вообще попал в JVM разработку, какой у меня был "карьерный путь", и как я разок сходил в enterprise разработку на год.
как я стал JVM-инженером, и как это - 10 лет проработать в одной команде
twitter.com/itunderhood/st…
интересно, дойдет ли сегодня дело до плюсовых температур?
Ну что, передохнули, поговорив за жизнь?
Давайте чуть-чуть хардкорчика: начнем с обещанного минитреда про Undefined Behaviour в Java
...да нет в Java никакого UB, этож вам не плюсы. Здесь всегда все определенно, конец треда.
простите, не сдержался! все бы мы хотели жить в таком мире, конечно.
на самом деле все немного сложнее, так что давайте начнем с самого начала.
Если вас спросят, в чем проблема C/C++, как языков программирования, что вы скажете?
Уверен, что среди ответов не раз прозвучит тот самый Undefined Behaviour или UB.
Дело в том, что прям в спеках этих языков написано, что в том или ином случае гарантируется неопределенное поведение.
Т.е. единственное, что в этих случаях гарантируется - что ничего не гарантируется.
Это довольно красивый ход при создании языка: он снимает с создателей ответственность в краевых ситуациях, а также развязывает руки компилятору, позволяя делать очень агрессивные оптимизации.
Вот только программистам это приносит в основном боль и страдания.
Ну ладно, давайте откроем неиссякаемый источник безумия: (Я в процессе такие восхитительные вещи понаходил) Один лайк — один пример UB на C++!
Не буду сейчас приводить какие-то свои примеры таких ситуаций, а лучше просто оставлю здесь ссылку на бессмертную классику: тред @Nekrolm про UB в плюсах: twitter.com/Nekrolm/status…
А есть ли UB в Java?
На первый взгляд кажется, что этого быть не может. Спека написана так, что никакого UB быть не должно, любое действие имеет вполне себе понятное последствие.
Даже вхождения слов undefined вы в спеке найдете всего ничего и (почти) все они не о том.
Хотя одно из вхождений - очень интересное.
JVM Specification, Глава 6, параграф 1:
"If some constraint (a "must" or "must not") in an instruction description is not satisfied at run time, the behavior of the Java Virtual Machine is undefined."
О чем здесь идет речь:
JVM на вход приходит уже не исходный код на языке Java, а байткод (полученный, например, трансляцией из исходного кода). Это такой более удобный для JVM абстрактный язык.
Этот байткод обязан удовлетворять неким условиям, описанным в спеке.
Если он получен трансляцией из Java кода javac-ом из JDK, то все так и будет. Но зачастую байткод генерят просто из воздуха, чтобы получить тело для какого-нибудь wrapper-а или proxy класса.
Этим часто занимаются различные Java библиотеки и фреймворки. Тот же Spring.
Правильность байткода проверяет специальный компонент JVM - верификатор. Это такой последний рубеж обороны, подтверждающий, что входные данные корректные.
Вот только его очень любят отключать, из-за стереотипа о том, что он работает долго (на самом деле это неправда)
Поэтому на практике на вход JVM вполне может прийти паленный байткод, в котором описанные в спеке ограничения нарушаются. Что тогда произойдет при отключенном верификаторе?
Правильно, UB. Мы не знаем! Может произойти все, что угодно. И это явно сказано в спеке.
Если вы думаете, что это надуманный пример, то нет: ответственно заявляю, что одни люди часто ошибаются при генерации байткода, а вторые - упорно выставляют -noverify в погоне за мифическим ускорением
Кто так делает, помните: по надежности вы опускаете Java до уровня C++
Про верификатор есть отличный доклад моего коллеги @pjBooms: youtube.com/watch?v=-OocG7…
Там он наглядно показывает, зачем верификатор нужен, как работает и объясняет, что он, если что и тормозит, то только старт вашего приложения (да и то не оч. сильно)
Есть, конечно, и более простой способ: из Java можно позвать метод, написанный на C, а там уже хоть обмазаться UB, благо примеров огромное множество.
Но это нечестно: UB тогда случится именно в сишном коде, а не в Java, так что я бы это не засчитал.
Ну что, передохнули, поговорив за жизнь? Давайте чуть-чуть хардкорчика: начнем с обещанного минитреда про Undefined Behaviour в Java
Undefined Behaviour в Java twitter.com/itunderhood/st…
Но кроме UB в JVM есть и другой интересный (и чем-то похожий) момент: умалчивание спекой о тех или иных механизмах
Вот мы все привыкли, что в Java есть сборка мусора. Более того, мы даже привыкли думать, что знаем, как эти самые GC работают.
А знаете, что про это говорит спека?
2.5.3: Heap storage for objects is reclaimed by an automatic storage management system (known as a GC) ... JVM assumes no particular type of automatic storage management system, and the storage management technique may be chosen according to the implementor's system requirements.
И это фактически единственное упоминание GC на всю спеку.
Что это для нас значит? А то, что в спеке не зафиксировано, как сборщик мусора должен работать.
Это уж нам, JVM инженерам, решать, как именно мертвые объекты будем собирать.
Из этого есть забавные следствия.
GC может не собирать мертвые объекты вообще. Да и в принципе на запускаться, имеет право.
Конечно же, приложения при этом очень быстро будут исчерпывать память, но кому-то это вполне и норм. Важно, что спеку мы тут не нарушаем.
@itunderhood Но есть же реализации JVM без сборщика мусора. Они просто раз в сутки перезапускаются и все ок. Это все ещё Java Compatible?
про это уже спрашивали вот тут, ответ именно такой: все корректно, это нормальные JVM. twitter.com/vit_ius/status…
Когда конкретно GC придет за помершим объектом - исключительно его дело. Он может подержать его в памяти до удобного момента (и на самом деле это буквально всегда происходит на практике).
Если вы затачиваетесь на то, что объект скоро умрет, эт вы зря.
2.5. В сознании многих людей есть такая интересная мысль, что объекты не могут жить дольше, чем область видимости единственной ссылки на них.
Типа:
if (...) {
var o = new Object();
...
} ← мучительная смерть o
такая мысль в головах - это тяжкое наследие C++, где в похожем коде бы вызвался деструктор (если объект на стеке).
В Java с одной стороны GC не обязан тут же прибегать за объектом, а с другой стороны, мог прибить его и раньше (после последнего использования o).
Обратите внимание, что такой недетерминизм, это не UB. Спека вам ничего не обещала, вообще ничего не говорила на тему смерти объектов.
Если вы пытаетесь какие-то предсказания о времени жизни объекта делать, то простите, но
В каком порядке объекты (ставшие одновременно ненужными) будут помирать - тоже непонятно. В Java есть возможность проследить за смертью объекта с помощью финализаторов, но опять таки: заточитесь на то, что один объект умирает перед другим - погибните сами.
Кто-то может сказать, что это безобразие, что нужно было все четко специфицировать, чтобы во всех разных JVM все GC работали бы "правильно"
На самом деле такая молчаливость спеки позволяет реализовывать все новые и более специализированные сборщики мусора, а это хорошо для всех
Что еще не описано в спеке?
А вот например способ, как именно код то исполнять.
Обязательно ли его интерпретировать, компилировать на лету или может можно скомпилировать все* заранее?
Спека не говорит.
Поэтому нельзя сказать "Java интерпретируется", например. Все зависит от реализации. В Hotspot сейчас гибридная модель tiered компиляции: сначала код интерпретируется, а горячие методы потом компилируются по ходу
А у нас в JET интерпретатора не было вообще, зато был AOT.
Вы бы знали, как долго мы убеждали людей, что это вообще возможно: скомпилировать Java приложение заранее, AOT компилятором.
Слишком многие были уверены, что так просто нельзя, хотя спека то про это ничего не говорит.
Еще из неопределенного:
В спеке никак не зафиксирована раскладка полей в объектах и вообще их внутреннее устройство.
Если пытаетесь хачить и писать что-то низкоуровнево в поля объекта: у вас потенциальные проблемы, поля могут быть совсем в другом месте.
Порядок методов в классах - тоже не определен на самом деле! Более конкретно: когда вы через рефлексию получаете все методы класса (через getDeclaredMethods()) вам вернется массив, в котором методы будут в произвольном порядке, возможно разным для разных JVM!
Казалось бы, ну кто может заточиться на порядок методов в этом массиве? А вот могут, например, есть заточка в стандартной библиотеке языка Scala (нашли случайно, одна и та же программа работала очень по-разному от запуска к запуску).
В принципе можно продолжать еще долго, но закончу вот каким пунктом. Спека ничего не говорит о существовании в Java (и ее стандартной библиотеке) такой штуки, как Unsafe.
Кто не знает, это скрытый пакет, дающий доступ к низкоуровневым операциям.
Это значит, что любой вызов метода из Unsafe может просто не работать вообще. В теории.
На практике чуть мягче: в абсолютном большинстве JVM unsafe поддержан, т.к. через него сделана стандартная библиотека.
Но вот насколько корректно он работает - никто не знает!
Ну т.е. обычно он поддержан настолько, чтобы проблем в стандартной библиотеке не было. Но поведение методов из unsafe в деталях может сильно отличаться.
Вообще, очень печально, конечно, что этот приватный API получил такое распространение в пользовательских приложениях.
Завершая тред, оставлю предостережение. Если вы затачиваетесь на внутренность какой-то JVM, а спека вам при этом ничего не обещает, то вы в очень шатком положении
Следующий апдейт может все сломать, не говоря уж о переходе на другую JVM
Подумайте два раза, надо оно вам или нет
- Дорогой, давай ты не будешь углубляться в тонкости Java/JVM спецификаций в коллективном твиттере, там ведь даже не все на Java пишут
- Конечно, дорогая.
Три рюмки спустя:
Но кроме UB в JVM есть и другой интересный (и чем-то похожий) момент: умалчивание спекой о тех или иных механизмах Вот мы все привыкли, что в Java есть сборка мусора. Более того, мы даже привыкли думать, что знаем, как эти самые GC работают. А знаете, что про это говорит спека?
О чем молчит спека, и почему не стоит затачиваться на конкретные реализации JVM
twitter.com/itunderhood/st…
Четверг
@miha_x64 @itunderhood В Golang, где порядок итерации по hashmap не определен, его сделали случайным, чтобы вылавливать когда на него закладываются. Сейчас люди закладываются, что порядок итерации случайный. golang.org/doc/go1#iterat…
мне кажется, что это очень смешно)
доброе утро! twitter.com/asatarin/statu…
Сегодня я немного в огне (скоро объясню почему), поэтому на техническую тему времени не хватит, да и, думаю, после вчерашнего лучше сделать перерыв.
Поэтому сейчас предлагаю поговорить про Новосибирск, нашу провинцию и IT в ней.
Итак, как вы уже поняли, я кайфую от своей работы и от своей команды.
Но есть один нюанс. Мы в Новосибирске😱
Насколько это плохо или хорошо?
Давайте быстренько перечислим объективно плохое, что в Новосибе есть, а потом перейдем к хорошему (и к моему отношению вообще).
Из плохого: климат
Обычно люди представляют себе совсем уж постапокалиптическую картинку, что у нас всегда -40. Это не так, конечно.
На самом деле, климат здесь резко-континентальный, в течение года температуры прыгают от -40 до +35, где-то так.
Т.е. здесь можно замерзнуть зимой, и спариться летом. Но главное, что все очень быстро меняется (ну, вы видели мой скриншот: с -38 до -2 за сутки)
на случай, если сейчас придут питерцы и скажут, что наш -40 - это никакой не -40, т.к. влажность не та: все в порядке у нас с влажностью, -40 - это реальный капец!
На практике у нас обычно есть пара совсем неприятных (холодных или жарких) недель, остальное время температуры вполне себе терпимые, жить можно.
Главный практический вывод: тебе в гардеробе нужна буквально вся одежда по температуре. С одними штанами не прожить ¯_(ツ)_/¯
Второе плохое: удаленность от остального мира. Мы буквально в середине России, до (зарубежной) Европы и до Азии почти одинаково далеко. Разве что в Тай близко.
Сейчас, понятно, это пофиг, но вот раньше летать куда угодно через Москву - такое себе было.
Третье плохое: Новосиб - это российская провинция, со всеми вытекающими. Да, мы третий по размеру город. Да, население растет. Да, столица Сибири (вообще то каждый город в Сибири считает себя столицей, это такой местный прикол).
Но на самом деле - это провинция.
Из этого простое следствие, что у города мало денег на улучшение инфраструктуры. Метро строится жутко медленно, улицы чистят хуже, архитектуры особо никакой нет.
Еще и работы меньше и зарплаты в целом ниже, чем в столицах (хотя и жить, конечно, значительно дешевле).
И не смотря на все минусы выше, в Новосибирске очень годный IT сектор.
Я часто слышу такую мысль: "очень много крутых программистов именно из Новосиба, это потому, что они хотят вырваться из этого ада и для этого тренируются!".
И вот с этим очень трудно согласиться.
Крутость местных программистов объясняется:
хорошими вузами (по крайней мере двумя), которые могут дать качественную образовательную базу,
большим количеством компаний, как местных, так и филиалов: JB, Yandex, Сбер, ЦФТ, Huawei, 2GIS, etc
сильной связью этой самой IT отрасли с наукой, которая здесь представлена очень хорошо из-за местного научного центра - Академгородка (всемирно известного).
Поэтому здесь очень много компаний, занимающихся наукоемким ПО.
В результате, программисты здесь вырастают со студенческой скамьи, идут после этого работать либо в большие компании, либо в наукоемкое ПО.
И таким образом формируют действительно крутое, высококачественное сообщество IT спецов.
Конечно, многие потом уезжают, дойдя до потолка в какой-нибудь из местных компаний или филиалов. Но часть людей остается, например по причинам, которые я описывал вчера: интересная, наукоемкая работа и крутая команда.
Если говорить конкретно про системное программирование, то приведу простой факт: в Новосибирске есть как минимум 3 независимые команды JVM разработчиков.
А в вашем городе сколько?
Объясняется это, кстати, тоже просто: в Новосибирском Академгородке жил и занимался своими исследованиями Андрей Петрович Ершов, один из пионеров системного программирования и в т.ч. компиляторостроения. Это великий человек, его работы, например, повлияли на Дональда Кнута
Так вот он основал здесь целую научную школу компиляторщиков, которая жива и по сей день.
Так что ничего удивительного в том, что в Новосибирске много компиляторщиков и рантаймщиков, абсолютно нет.
Поэтому не надо говорить, что в Новосибе все в IT только и делают, что стараются уехать.
У нас крепкий академический фундамент и годные местные компании. А каждый человек уж сам решает, воспользоваться ему этим всем, как трамплином, или остаться и развиваться здесь дальше.
Кстати, никого не осуждаю, оба варианта абсолютно отличные. Хотите уезжать - почему нет, распространите частичку Сибири чуть дальше по миру.
Решаете остаться - тоже хорошо, т.к. это усилит местное комьюнити.
К сожалению, часто слышу упорное порицание второго варианта - остаться здесь. Уверен, что и сейчас придут люди, которые начнут говорить, как же я не прав, что остался, как же я не понимаю, в Новосибирске просто ад!
Штош, их право.
Ну и в конце треда накидаю более общих пунктов, за что Новосиб можно любить:
тут есть снег зимой! слышал, в столицах с этим проблемы
тут красивая природа - до Алтая всего 400км на машине
тут дешевое жилье, на порядок дешевле Московского
При этом это не деревня, инфраструктура есть и вполне достойная (ну, не Московский уровень, но все-таки)
тут развитая культура: театры, консерватории, балет. Многое досталось нам от Питера во времена эвакуации
кстати, мы говорим поребрик! но подъезд.
ну и, если слышите, слово "мультифора", то перед вами точно сибиряк.
Но самое главное, конечно, тут офигительные люди. Что в IT, что не в IT.
Огромное количество творческих людей тоже из Новосиба.
Я уж не говорю про ученных, никак с IT не связанных.
Ну и в результате конкретно я Новосибирск люблю со всеми его недостатками и преимуществами. При этом хочется, чтобы он развивался и происходили качественные улучшения, чтобы людям меньше хотелось отсюда уехать
Впрочем, наверное так рассуждает любой житель провинции в РФ
ну и небольшое продолжение треда про провинцию.
как-то я подумал: раз я не собираюсь уезжать, а остаюсь здесь, а у нас здесь есть проблемы, то что лично я могу сделать, чтобы помочь? чего нам не хватает?
Я не депутат какой-нибудь, не могу сделать так, чтобы дороги начали лучше чистить.
Не господь бог, с погодой тоже ничего не исправлю.
Зато я понял, чего в Новосибе не хватает лично мне: живого общения на тему Java и JVM. Ну и решил это исправить.
(еще я могу делиться знаниями в универе и делают это, но про это завтра)
Это как раз было в момент моей первой поездки на JPoint, где я увидел, что в Москве то с Java IT тусовкой все в порядке. Митапы, конференции, все как надо.
А у нас в Новосибе по Java в тот момент была конференция JBreak (потом закрылась), но и все, сообщества никакого не было.
В результате я понял, что надо попробовать собрать митапчик: просто чтобы проверить гипотезу, что это хоть кому-то кроме меня надо.
В тот же момент такая же мысль пришла в голову @honig_den. Мы собрались, позвали @tagir_valeev и @ZhekaKozlov в качестве докладчиков и...
...и спустя пару недель к нам на первый митап пришло сразу больше 100 человек посетителей и это на маленький, местный, первый в своем роде Java митап!
да не любая площадка выдержит 100 человек, мы были в полном шоке.
--
так появился Новосибирский Java User Group: @jugnsk.
зацените, какой у нас классный Дюк в шарфике в качестве маскота, я им очень горжусь
Сообщество сформировалось очень быстро, буквально за пару митапов.
С тех пор мы провели уже 16 митапов, помогли в организации 2-ух конференций и провели свою собственную Java конференцию в Новосибирске, которую назвали SnowOne (@snowone_conf).
оказалось, что людям очень нужно было место, где можно пообщаться, выступить с докладом, послушать доклад про Java, спросить что-то по работе, да просто потусоваться со своими людьми.
и мы им это дали, и продолжаем давать.
Всегда есть то, в чем мы можем быть полезны окружающему миру.
Если не только жаловаться, но еще и что-то делать, то реальность может начать преображаться. Пусть не сразу, шаг за шагом, но улучшения будут.
По крайней мере, если вообще не пробовать, то точно ничего и не выйдет.
Кстати, почему я сегодня в огне: у нас сегодня 17-ый митап @jugnsk!
Ковид не пощадил никого, так что это уже 4й митап, который проводим онлайн. Но в этом есть плюс, я могу позвать всех вас на него
Трансляция будет здесь (начало в 7 по Нск, в 3 по Мск): youtu.be/RdndZ9Ruv50
Пользуясь случаем, сразу позову вас и на нашу конфу, которая будет проходить в конце февраля, тоже онлайн: snowone.ru
Много докладов про Java/JVM, хардкорчик, JVM спека, вот это все будет. Приходите, мы с @tagir_valeev, @pjBooms и @toparvion будем вас очень ждать!
Вообще, организация митапов и конференций для меня - очень непривычное дело. Ну, знаете, чаще я копаюсь в gdb, отлаживая очередной развал JVM.
А тут нужна какая-то совершенно другая часть мозга, чтобы все грамотно организовать, да еще и переобщаться с кучей людей.
Но для меня это окупается многократно: когда видишь, как людям заходит, как они общаются и учатся, как они моментально забивают свободные места на очередной митап, то испытываешь такую детскую радость.
Ну и я правда думаю, что Новосибирск от этого становиться чуть-чуть лучше.
Сегодня я немного в огне (скоро объясню почему), поэтому на техническую тему времени не хватит, да и, думаю, после вчерашнего лучше сделать перерыв. Поэтому сейчас предлагаю поговорить про Новосибирск, нашу провинцию и IT в ней.
о Новосибирске и провинциальном IT twitter.com/itunderhood/st…
ну и небольшое продолжение треда про провинцию. как-то я подумал: раз я не собираюсь уезжать, а остаюсь здесь, а у нас здесь есть проблемы, то что лично я могу сделать, чтобы помочь? чего нам не хватает?
о нашем местном Java комьюнити twitter.com/itunderhood/st…
@itunderhood У меня есть несколько вопросов к тебе, буду рад если ответишь. AOT компилированная программа может работать без JVM? AOT компилированная программа детерминированная? Можем ли мы утверждать, что поведение будет одинаковым при разных запусках? ->
хорошие вопросы, на которые стоит ответить небольшим тредом 🧵 twitter.com/vit_ius/status…
для начала давайте договоримся, что честный AOT (всегда компилировать >все< классы заранее) в Java невозможен.
Спека явно говорит, что могут появиться новые классы, которые нужно будет на лету скомпилировать. Например, если вы их сгенерируете.
поэтому будем думать про AOT компиляцию Java, как "скомпилировать все известные классы заранее, а если появятся новые, ну что-нибудь придумаем, поджитуем, например"
>>AOT компилированная программа может работать без JVM?
формальный ответ - нет, вам все еще нужна JVM, чтобы собирать мусор, аллоцировать объекты и так далее, т.е. вам нужен рантайм.
наверное вы здесь хотели спросить другое: а можно ли получить с AOT один бинарь, без jar-файлов
(и установленной на машине пользователя JVM)
Так можно, да. Заранее скомпилировать все классы Java приложения и слинковать их в один бинарь вместе с частями рантайма, получится такой же .exe-шник, как для программы на C++
>>AOT компилированная программа детерминированная? Можем ли мы утверждать, что поведение будет одинаковым при разных запусках?
Нет и нет.
Да, недетерминизма будет меньше, т.к. деоптимизаций и перекомпиляций нет, но GC то остается. А он приходит по своим эвристикам.
>>Почему AOT такой непопулярный?
Два ответа.
Тот, который чаще всего можно слышать от разработчиков JIT компиляторов - "из-за динамических свойств Java, как языка"
Тот, который скажу я: "по историческим причинам".
Когда-то в Sun решили идти по пути интерпретации, потом джит-компиляции. 20 лет по этому пути шли, довольно трудно теперь с него свернуть, совсем другие технологии теперь нужно придумывать, чтобы AOT работал так же хорошо.
Ну а мы то видели другой путь, так что знаем, что можно и AOT компилятор для Java хороший сделать.
Да и посмотрите, какой сейчас бум AOT компиляции Java, GraalVM Native Image тот же. Вот вам и динамические свойства Java.
>>AOT компилированная программа будет производительнее?
Зависит от характера приложения. Если профиль исполнения плоский - то да, будет быстрее с AOT. Если есть ярко выраженные спайки - JIT проявит себя лучше.
Что можно гарантировать уверенно, так это быстрый старт AOT-скомпилированного приложения.
Вообще не нужно тратить время на компиляцию на лету => в начале работы AOT вырвется вперед (вне зависимости от профиля)
хорошие вопросы, на которые стоит ответить небольшим тредом 🧵 twitter.com/vit_ius/status…
внезапный тред с ответами на вопросы про AOT компиляцию Java
twitter.com/itunderhood/st…
Пятница
Доброе утро! Пятница - отличное время, чтобы поговорить про образование
Начнем с пары опросов.
Высшее (профильное, всякие IT специальности) образование программистам:
И конечно, первородный спор.
С какого языка начнем учить программировать? 1/2
или может:
свои варианты тоже приветствуются!
Лого проходит вне конкурса
Этой ночью я хочу сообщить всем будущим айтишникам, что если вас учат программированию, но не учат языкам программирования, то вас обкрадывают. Программирование — это технология, но языки программирования — это объекты искусства, творения человеческого гения.
Вот с Виталием никогда непонятно, серьезно он говорит или нет (да и вообще, его это твит или нет)
Но мысль интересная! Стоило псевдокод добавить в опрос. twitter.com/_bravit/status…
почему никто не голосует за SML отличный язык((
По заказам трудящихся еще один опрос.
А нужно ли студенту IT факультета после 4 лет обучение идти еще и в магистратуру?
про диссер даже спрашивать не буду, это слишком больная тема
@itunderhood Отмените обязательный призыв, купите попкорн и наблюдайте пустеют вузы
да скорей бы уже!
без шуток, угроза армии наносит огромный вред высшему образованию twitter.com/xd720p/status/…
@itunderhood Как было у меня: совсем основы учатся в школе на простом и человеческом языке вроде паскаля, js, python или шарпов, а в универе с первого курса хардкор в виде плюсов, ручного управления памятью и т.д.
пожалуйста, хватит учить перваков плюсам 😥😥😥
мало кто знает, но увидев плюсы до сишечки перваки начинают путать ссылки и операцию взятия адреса, перестают есть и пить и умирают 😞 задумайтесь!! twitter.com/Volodya262/sta…
@itunderhood После бакалавриата нужно идти к психотерапевту
есть и такое мнение
главное, чтобы это был не бакалавриат по психотерапии! twitter.com/brumeregan/sta…
вот вы думаете, я у вас про первый язык программирования по приколу спрашиваю, а это не так!
меня тут позвали обсудить учебную программу на одном из направлений, надо быть подготовленным.
так и скажу потому: по результатам независимых соц. исследований люди предпочитают python
@skv_nskv @tagir_valeev @itunderhood Теперь у студентов выбор есть: плюсы или питон.
как говорится, есть два стула twitter.com/cypok/status/1…
Про мои отношения с университетом.
Преподаю уже восьмой год, Сишечку и Плюсы.
При этом делают это не на профильном факультете, а на МехМате. Хотя, огромное число выпускников ММФ потом идет в IT, так что тут как посмотреть.
Если сишечка для обучения (системному) программированию подходит неплохо, то плюсы - это, конечно, совсем не про обучение язык.
Я бы его показывал только уже в конце обучения, типа как медикам интернам показывают всяких больных редкими болезнями
Но с программой не поспоришь 🤷♂️
Да в целом и с сишечки начинать - тоже странный выбор, конечно. Не всем же быть системными программистами.
Спасает только то, что из школы обычно уже приходят люди, пробовавшие на чем-то программировать.
Начал преподавать я где-то из тех же соображений, что и митапы делать.
Мне не очень нравилось, как преподавали прогу мне, решил, что могу лучше. Ну а вакантные места то для преподов всегда найдутся
Хе-хе, я тогда был не сильно то старше своих студентов
Меня постоянно с ними путали все: от других студентов, спрашивающих, жесткий ли препод в группе, до людей из деканата, ругающих за слишком резкие ответы
Впрочем, сейчас меня от этого спасает только борода
Зачем вообще идти в универ преподавать?
Кроме вот этой моей детской наивности про улучшение мира вокруг
(а еще интересных таких разговоров про отдачу долга своей альма-матер, прям как с армией)
Во-первых, когда объясняете что-то, то сами в этом гораздо лучше начинаете разбираться. Банальщина страшная, все про это говорят, но это реально так.
Даже удивительно насколько упорядочивание базовых знаний хорошо укрепляет понимание всего остального.
Во-вторых, это отличная возможность прокачать навыки публичных выступлений. Попробуйте рассказать про шаблоны в плюсах так, чтобы заинтересовать в том числе людей, которые хотели просто делать игры) Нужно быть довольно убедительным.
И в-третьих, это возможность пообщаться с интересными людьми. Я про студентов с горящими глазами и потрясающе крутой головой. Они готовы завоевать весь мир и решить любую задачу.
Конечно же не все студенты такие, но даже ради небольшого процента стоит идти преподавать.
ах да, еще преподам выдают бесплатные лицензии на продукты JetBrains, Microsoft и еще много чего.
Пара лайфхаков для начинающих преподов:
Если кто-то говорит вам, что преподавать легко и просто, то гоните его ссаными тапками.
Скорее всего это перегоревший препод, который пытается резко найти себе замену и убежать в закат.
Преподавать сложно и на это уходит очень много времени. Это, конечно, при условии, что вы хотите делать это нормально, а не тяп-ляп, сами разберутся.
Подготовка к парам, ревью задач, проведение лекций и семинаров, ответы на вопросы студентов. Это все огромная работа.
Если вам прям противно от процесса преподавания и совсем это не в кайф, то лучше отступиться, это просто не ваше.
Все ведь мы видели этих бедных аспирантов, которых из под палки отправили преподавать? Кому от этого было хорошо?
Не нужно бояться, что вы чего-то не знаете. Или тем более, что есть студент, который шарит лучше вас. Крутые студенты - это то, ради чего стоит преподавать, помните?
Порадуйтесь, что встретили такого, может еще и диплом с ним отличный получится написать (или поработать).
Студенты, которым не интересен ваш предмет - это нормально, люди все очень разные.
Так уж получилось, что у нас система образования редко подразумевает выбор конкретных курсов, так что они могут быть заложниками ситуации.
Не вижу смысла как-то обижаться и начинать их топить.
Конечно, если уж совсем всей группе неинтересно, то что-то пошло сильно не так. Может стоит поработать над курсом, а может сменить направление, попреподавать в другом месте.
А может это был просто аномальный год, после такого хорошо бы отдохнуть с семестр (а то перегорите)
Очень банально, но все же: не стоит обесценивать работу студента. Даже если вам что-то кажется простым и очевидным, то для студента это могло потребовать огромных усилий.
И вообще, не стремайтесь хвалить студентов, когда они этого заслуживают.
Но и свою работу тоже цените: пришедший в последний момент студент, пытающийся сдать на шару (списанные) задачи за весь семестр с чистой совестью может быть отправлен нафиг.
Вы этот семестр работали, его одногруппники работали, а он решил проскочить.
В целом, конечно, если бы студенты и преподы побольше бы откровенно говорили друг с другом без всяких этих игр “я списал со шпоры, а я тебя поймал и поставил неуд”, было бы гораздо проще всем жить.
И вообще, терпеть не могу экзамены, самая скучная и неприятная часть преподавания
О, важный совет! Делайте слайды!
Я понимаю, что это вкусовщина, но в слайдах можно выдать куда больший объем информации, чем мелом (маркером) по доске
К тому же, у студента сразу остаются материалы, которые можно потом разобрать
Я именно про преподавание проги, не матана
Про главный вопрос жизни, вселенной и всего такого (нужна ли программисту вышка), я бы ответил: что да, кайфовая вышка была бы очень полезна.
В плане дисциплины, обучения навыку учиться, формирования общей картины устройства мира, разнообразия подходов к программированию
Но я не понимаю людей, которые требуют от ВУЗа обучению последним Java (JS?) фреймворкам. Конечно же он этому не научит: за 4 года все эти фреймворки банально устареют.
Универ не про то, он про общий кругозор, про культуру программистскую что ли
@itunderhood Конечно До этого все школьные попытки в программирование заканчивались на первой сложности, потому что "а зачем" А тут стало прям интересно решать эти сложности
ну вот, не зря в тот год преподавал! twitter.com/s_esipenko/sta…
@itunderhood Мемы в презентации - топ!
да, добавляйте мемы в слайды, это всем нравится!
(главное потом не спрашивать у студентов, а чего они не смеялись над мемасом, смешно же, ну?)
twitter.com/s_esipenko/sta…
я думаю, что моя преподавательская карьера закончится тем, что я перейду черту и начну вставлять мемасы с гитлером там или что-то такое.
все жду, сейчас я где-то вот на таком уровне:
Буквально на следующей неделе ко мне придет новая группа студентов (у них номер группы будет начинаться с 20-ки, представляете??).
Это всегда немного волнительно и очень интересно! Надеюсь, что не смотря на ковид (и, возможно, опять дистант), у нас с ними все получится.
В конце треда скажу, что преподавание - это сложно, сжирает кучу времени и все такое, но эмоционально лично для меня это все окупается.
Если думаете, преподавать или нет - попробуйте, эта штука может вас очень сильно затянуть (а в результате вы еще и пользу окружающим принесете)
Про мои отношения с университетом. Преподаю уже восьмой год, Сишечку и Плюсы. При этом делают это не на профильном факультете, а на МехМате. Хотя, огромное число выпускников ММФ потом идет в IT, так что тут как посмотреть.
про преподавание в универе
twitter.com/itunderhood/st…
Суббота
Надеюсь, ваши выходные проходят хорошо!
Сегодня вечером хочу поговорить про еще одну свою любимую тему: хардкорные доклады на IT конференциях
Сначала небольшая вводная часть, а потом сделаю подборку из годных (на мой взгляд) хардкорных докладов про JVM
Несколько недель назад на этом аккаунте прозвучало мнение, что IT конференции просто не могут выполнять образовательную функцию и нужны совсем для другого.
Дескать, чему ты там за час научишь то, это не так работает
Это было на неделе про нейрофизиологию, в конце декабря
Я уже тогда хотел за это повоевать, но был конец года, дедлайны, завалы, все в огне, вы понимаете.
Но отвечу сейчас, это важно для последующего треда.
Мой поинт в том, что конечно же доклады (как и посты, например) отлично могут исполнять образовательную функцию
Но для этого есть предусловия.
У слушателя доклада уже должен быть подходящий контекст на старте.
Это не значит, что он должен заранее все знать. Но нет никакого смысла человеку никогда не слышавшему про сборку мусора приходить на доклад про устройство Shenandoah GC
GC здесь выбран просто в качестве примера, можно привести аналогию с любой темой: нет никакого смысла слушать про новый фреймворк, решающий какую-то проблему, если вы еще на совсем начинающем уровне.
В этом плане я вообще слабо верю в полезность докладов для новичков
Соответственно хороший технический доклад именно в опытную аудиторию и метит: в нем нет повторения всем известных истин, а вместо этого рассказывается об уникальном опыте, на получение которого самостоятельно потребуется куча времени.
Грубо говоря, такие доклады - это квинтэссенция опыта, зачастую многолетнего, собранные и хорошо структурированные знания, которые докладчик получал кровью и потом.
А прошаренный слушатель за счет наличия контекста этот опыт может быстро воспринять, не тратя на это десятки часов
Короче: доклады - это не школьная программа и не семестровый курс в универе, да. Это про другое - краткая выжимка материала для профессионалов.
Говорить, что такой доклад - это просто повод поболтать со спикером на афтепати - это дикое обесценивание его работы, не надо так.
Есть, конечно, и лайтовые доклады, нацеленные чисто на создание настроения, они тоже имеют право на существование.
Но я сегодня не про них, а про то, что можно использовать в качестве источника знаний.
У нас в Java мире (по крайней мере в русскоязычной его части) как-то повелось, что есть доклады не только про повседневные задачи Java разработчиков, но и про устройство JVM. Их в числе прочих обычно называют "хардкорными" докладами.
Внимательный читатель сейчас скажет: эй, чувак, а кто их слушает то эти доклады? По твоей же логике они могут быть полезны только другим JVM инженерам! Ну и еще performance-инженерам, которые по работе разбираются в устройстве JVM.
Остальным просто не хватит контекста.
Да, но нет
Пришедшим впервые на хардкорный доклад контекста и правда может не хватить
Но практика показывает, что для многих внутреннее устройство JVM кажется штукой любопытной, поэтому они читают хардкорные посты, смотрят доклады, интересуются и расспрашивают JVM разрабов
Кроме того, часто хардкорные докладчики специально немного занижают порог вхождения, объясняя в докладе некоторые понятные им самим вещи, чтобы подготовить аудиторию.
Это все дает интересный эффект
Посмотрев какое-то количество хардкорных докладов и прочитав сколько-то постов, можно составить вполне себе целостное понимание того, как JVM устроена
Да, не очень глубокое (доклады это все-таки науч. поп), но целостное
Вот вам и образовательная функция, даже в нашей узкой теме
Кстати, да: мне и самому очень удобно бывает пересмотреть какой-нибудь хардкорный доклад, чтобы прояснить непонятный/забытый момент из чужой технологии.
Не так часто, но сам факт: это полезно даже человеку, каждый день работающему с внутренностями JVM.
А теперь я накидаю вам набор хардкорных докладов и постов, которые помогут сформировать картину происходящего под капотом JVM
Начал бы я с обзорного доклада @pjBooms и @cypok про устройство JVM: youtube.com/watch?v=JbLClS…
Это такой смузи хардкорный доклад, идеально для старта
Туда же доклад @JohnWings про JIT компиляцию: отличная точка входа для знакомства с динамическими компиляторами. youtu.be/9valLOxgDbI
Ну, раз сказал про JIT, то грех не упомянуть похожий доклад от @pjBooms, но уже про AOT компиляцию Java. Если вам интересно узнать про это дело подробнее, чем то, что я писал на этой неделе, то welcome: youtu.be/KbbSGg-PK70
И еще один отличный доклад именно про компиляторы: от Chris Seaton про разработку Graal компилятора (как раз на Java, как я рассказывал в начале недели).
Показывает, как легко начать что-то в таком компиляторе делать: youtu.be/sFf15TvSXZ0
Давайте немного поднимем градус хардкорности в теме компиляторов: доклад @iwan0www про векторизацию кода в Hotspot: youtu.be/kIteya13bts
Еще есть очень интересный доклад Артура Пилипенко про LLVM-based JIT компилятор Falcon. Это вообще уникальный рассказ про компиляцию Java в LLVM: youtu.be/Xub_epLoNs8
Ну и закончим подтему компиляторов на докладе Клиффа Клика (одного из отцов компилятора C2 в Hotspot) про Sea Of Nodes представление в C2: youtu.be/9epgZ-e6DUU
Переходим к рантайму.
Первое, что приходит в голову про рантайм - это, конечно, GC.
Мне трудно здесь привести какой-нибудь прям лайтовый доклад для совсем начинающих, но зато есть отличная база знаний у Plumbr: plumbr.io/java-garbage-c…
Там начало GC прям по полочкам
Если продолжать именно про тексты и GC, то нельзя не упомянуть знаменитую The Garbage Collection Handbook - манускрипт про разные стратегии управления памятью
Но я бы не советовал это новичкам и не понимаю, зачем многие так делают
Вот если собрались делать свой GC, то да
После понимания основных принципов сборки мусора можно послушать про что-нибудь более продвинутое, например про G1 от Monica Beckwith:
infoq.com/presentations/…
Или про Shenandoah GC от @shipilev:
раз youtube.com/watch?v=c1jVn5…
и
два youtube.com/watch?v=jaiRW1…
Ну и мимоходом оставлю здесь свой доклад про то, что GC часто может вести себя совсем не так, как вы думаете. В результате чего появляются ходячие объекты мертвецы: youtu.be/XtijbFcQxyw
простите за саморекламу, но перекликается с темой недели!
Но рантайм - это совсем не только GC!
Очень часто нам приходится профилировать код, а это целая отдельная тема для обсуждения, т.к. в Java с профилировкой все сложно.
Здесь, конечно, упомяну отличный доклад от @AndreiPangin: youtu.be/QiGrTvsCZmA
Вообще, у Андрея очень много классных хардкорных докладов про рантайм Хотспота:
про JVM TI: youtu.be/aiuKiE5-0g4
про память: youtu.be/kKigibHrV5I
про VM Structs: youtu.be/Es1MR1m29V8
Возвращаемся к профайлерам: лучшее, что я про профайлеры читал - это посты Нитсана Вакарта в его потрясающем блоге: psy-lob-saw.blogspot.com
Что-то давно не было новых постов, но и старые очень достойны внимания. Например: psy-lob-saw.blogspot.com/2016/02/why-mo…
Более хардкорно про профайлеры: Сергей Мельников - Профилируем с точностью до микросекунд и инструкций процессора: youtube.com/watch?v=hw2uxG…
И совсем свежак (вчера выложили). Доклад @Kirill_Tim_ про портирование async-profiler на Windows: youtu.be/DL2JxMLQuJ4
(кажется, в этом докладе нет ни строчки кода на Java, хех)
Нельзя говорить про рантайм JVM и не упомянуть Java Memory Model. Это одна из самых сложных частей спеки, и уже даже на этой неделе мы с вами вспоминали ее в теме про UB.
Лучшие доклады про JMM - доклады @shipilev.
Раз: youtube.com/watch?v=noDnSV…
Два: youtube.com/watch?v=Ky1_5m…
И продолжение: youtube.com/watch?v=C6b_dF…
Знаю людей, которые пересматривали эти доклады какое-то безумное количество раз, но где вы найдете более структурированный источник информации про JMM? (спека не в счет). То-то же.
Ну и раз мы говорим про доклады @shipilev, то нельзя не вспомнить его великие доклады про бенчирование (тема, на которую у меня не хватило времени на рабочей неделе, сорян):
раз: youtu.be/p2b4JHESEOc
два: youtu.be/8pMfUopQ9Es
А еще Алексея можно читать, его цикл постов JVM Anatomy Quarks отлично раскрывает небольшие детали реализации JVM, что помогает набрать контекст.
Всячески рекомендую:
shipilev.net/jvm/anatomy-qu…
Отдельная категория хардкорных докладов: доклады про мега-проекты в JDK. По ним очень круто понимать, куда конкретно реализация языка идет прям сейчас и чего ждать в будущем.
Из них приведу, во-первых, доклады @kuksenk0.
про Valhalla (добавление inline типов в Java):
раз: youtu.be/snrbobBVjyc
два: youtu.be/ri5i3mnSNk8
про Loom (добавление легковесных тредов в Java):
youtu.be/oBMZc2VMujw
Во-вторых, доклады @iwan0www про проект Panama (новый механизм взаимодействия с нативным кодом из Java):
раз: youtube.com/watch?v=4vHMmL…
два: youtu.be/0y6_RDga-fk?li…
Ну и раз мы тут пробегаем мимо темы нативов и Panama, то и свой последний доклад про нативы здесь тоже оставлю, он получился неплохим: youtu.be/DVTeZdtuHS0
В целом, если есть желание именно следить за прогрессом языка и его реализации, то очень полезно смотреть доклады с JVMLS: ежегодной конференции JVM-инженеров.
Вот плейлист с последнего: youtube.com/playlist?list=…
Ну и отдельно еще несколько просто крутых хардкорных докладов:
Доклады @godin про Java байткод, javac/kotlinc компиляторы и code coverage: youtu.be/89dSBMxaX_
Доклад @volker_simonis про анализ крешей HotSpot-а: youtu.be/buPX_nj40Tg
Помните я рассказывал про отладку по креш-дампам, как единственный способ отладки. Так вот, после доклада вы тоже сможете их читать.
Отличный доклад @kuksenk0 про ускорение CompletableFuture с прошлогоднего @snowone_conference: youtu.be/W7iK74YA5NM
Ну и еще разок отличный доклад @pjBooms про верификатор и полурешетки: youtube.com/watch?v=-OocG7…
С кого начали тред, тем и заканчиваем :)
На этом остановлюсь, хотя хардкорных докладов еще очень много.
Станете ли вы экспертом в JVM сразу после просмотра всех этих докладов?
Это вряд ли. Зато вы получите контекст и более полную картину мира, будете лучше понимать, что происходит у JVM под капотом.
Впрочем, знаю нескольких людей, которых после просмотра этих докладов резко начинало тянуть на низкий уровень, и в результате они становились системными программистами или JVM-разработчиками :)
В любом случае, приятного просмотра и чтения!
Еще обратите внимание, с каких конференций почти все приведенные доклады, по крайней мере русскоязычные
Это конференции и митапы @jugrugroup, ну и еще наши - от @jugnsk
Мало где еще есть такие темы, так что пользуйтесь этим и приходите на конфы. Эти пацаны умеют в хардкор🤘
Надеюсь, ваши выходные проходят хорошо! Сегодня вечером хочу поговорить про еще одну свою любимую тему: хардкорные доклады на IT конференциях Сначала небольшая вводная часть, а потом сделаю подборку из годных (на мой взгляд) хардкорных докладов про JVM
про полезность докладов на конференциях
twitter.com/itunderhood/st…
А теперь я накидаю вам набор хардкорных докладов и постов, которые помогут сформировать картину происходящего под капотом JVM Начал бы я с обзорного доклада @pjBooms и @cypok про устройство JVM: youtube.com/watch?v=JbLClS… Это такой смузи хардкорный доклад, идеально для старта
отдельно список моих рекомендаций по хардкорным докладам (часть предыдущего треда) twitter.com/itunderhood/st…
Воскресенье
ох, ну и жесть сегодня по всей стране, конечно.
надеюсь, что с вами все в порядке вне зависимости от того, какие у вас политические предпочтения.
у меня на сегодня был запланирован развлекательный тред, но я что-то даже не знаю, как его постить, когда весь тви заполнен видео жестких задержаний :(
в Новосибе вроде все прошло относительно спокойно
Хорошо, развлекательный тред тогда перенесем до лучших времен (запощу потом у себя), а сейчас все-таки поговорим о пропущенной технической теме: бенчирование.
Я буду говорить про бенчирование на JVM, но мысли в целом довольно универсальные.
Вот представьте: выбираете вы между двух технологий, которые по остальным характеристикам кроме производительности (удобство использования, применимость) вполне сопоставимы.
Или просто вам интересно, насколько быстро работает вот такая штука в вашем коде.
Что будете делать?
Померите производительность так, словно общаетесь с черным ящиком,
Будете разбираться в том, как цель вашего бенчирования работает, что у нее внутри (потратите кучу времени), а уж потом начнете замеры
опрос еще идет, но уже видно, что мнения разделились, это очень хорошо!
пока начну писать свое мнение про это
Кажется, что первый вариант наиболее честный.
Потому, что при таком подходе вы максимально непредвзяты, у вас пока нет какого-то своего мнения и представления, какая технология должна быть быстрее, а значит человеческий фактор на бенчирование не повлияет точно. Это очень важно.
Все просто: вот две цифры, у кого попугаев больше, ту технологию и выберем, будет нам счастье и перфоманс.
Понятно дело, что замеры вы делаете при этом по науке: на свободной машине, прогрев перед этим JVM, в качестве результата получаете среднее и отклонение
Уточню здесь: при замерах на JVM с tiered компиляцией (например Hotspot) нужно "прогревать" виртуальную машину, делать несколько итераций замеров, которые не пойдут в финальный результат.
Это необходимо, чтобы JVM успела найти горячие методы и их оптимизировать.
Вообще, даже это знание уже разрушает концепцию черного ящика, т.к. вы уже знаете про JIT и учитываете его. Но опустим этот нюанс, будем думать, что даже черный ящик все мерят с прогревом.
И знаете что? Да, подход с черным ящиком даст вам абсолютно правильный и непредвзятый результат.
Но проблема в том, что без знания устройства того, что вы бенчируете, велика вероятность, что вы интерпретируете результат совершенно неправильно.
Приведу пару примеров.
Вот буквально недавно я готовил доклад про нативы, где нужно было сделать довольно много замеров для сравнения разных технологий вызова сишного метода из Java.
И результаты, которые я получал раз за разом - это просто праздник какой-то.
Вот есть встроенная технология вызовов нативов - JNI, а есть библиотека, которая позволяет это делать более удобно - JNR.
Мерим простейший бенч: вызов пустого сишного метода из Java. Получаем - вызов через JNR на 5% быстрее, чем через JNI.
Если идти по пути черного ящика, то у нас на руках просто сенсация! Кто-то сделал библиотеку, которая работает быстрее, чем встроенный в Java механизм. Срочно в печать!
Но это противоречит здравому смыслу. Я знаю, что JNR сделан через JNI, т.е. должен работать строго медленнее
Начинаем копать глубже и оказывается, что мерится не совсем то: обычный вызов через JNI - это вызов instance native метода, а библиотека JNR в своих недрах порождает вызов static native метода.
Разные вещи мерили, хотя без заглядывания под капот это было максимально неочевидно!
Заменяем вызов на static - получаем прирост производительности на 7 процентов и обгоняем результат библиотеки JNR.
Черный ящик сфейлил по полной программе.
Еще пример: мерил я насколько быстро работает вызов натива в новой классной технологии из проекта Panama, над которым уже очень долго работают в Oracle, по сравнению со старой технологией - JNI
Опять простейший тест и черный ящик: вызов натива через JNI и Panama
И угадайте что?
Новая технология, которая должна заменить JNI, показывает цифры ровно в два раза уступающие результату старинной технологии.
Что случилось? Не успели оптимизировать? Плохо задизайнили технологию? В любом случае - это прям сенсация, скорей в печать! (нет)
На самом деле при этом эксперименте происходила интересная штука: менялась версия Java на которой происходит замер.
Для Panama брался кастомный билд со самой свежей не выпущенной еще даже версии Java на тот момент (16-ая), а для JNI - старая добрая стабильная 8-ка.
И цифры, как и всегда, не соврали, а просто были неправильно интерпретированы.
Дело не в том, что в Panama вызовы сделали медленнее.
Дело в том, в районе Java 9 сделали изменение, которое увеличило накладный расходы на вызов ЛЮБОГО натива ровно в два раза.
Это не ошибка и не глупость, а вполне мотивированное действие, другие сценарии от этого сильно выиграли.
Подробное объяснение вот здесь: bugs.openjdk.java.net/browse/JDK-818…
Но чтобы в этом разобраться пришлось посравнивать асмы и заняться археологией.
Берем Java 11 -> сравниваем с Panama -> новая технология сходу обгоняет JNI на 5%.
Опять фейл черного ящика, хотя здесь то уж, что могло бы быть проще.
И последний пример из той же оперы: теперь сравниваем вызов скомпилированного (!) сишного метода через JNI с интерпретацией (!!) LLVM биткода этого метода. Это можно сделать с помощью проекта Sulong - часть GraalVM.
Ха, очередное упоминание священного Грааля!
Тут уже даже с методом черного ящика есть некая предвзятость: ну понятно же, что скомпилированное быстрее интерпретатора, что тут мерить то?
Но все-таки мерим: и да, интерпретация медленнее на порядок. Окей, репортуем.. или подумаем еще раз?
Уточню, что вызываемый сишный метод на этот раз не пустой, иначе совсем неинтересно. Я добавил туда немного мяса: в том числе и вызовов других сишных методов из библиотек
И важный момент здесь вот в чем: эти библиотечные методы не интерпретируются, они заранее скомпилированы.
И что же мы получаем: в случае JNI мы вызываем Си метод, который вызывает другие Си методы. Накладные расходы на переключение контекста (Java to Native) посчитались 1 раз.
В случае интерпретатора из Java в Native нам приходится переходить при вызове КАЖДОГО внешнего метода.
Т.е. мы опять сравниваем теплое с мягким! И цифры опять не соврали, в таком сценарии, конечно же вызов скомпилированного метода будет быстрее.
Что нужно сделать: вызывать из него только другие интерпретируемые методы, вот тогда будет честно.
И действительно, в таком сценарии интерпретация начинает побеждать вызов скомпилированного сишного кода.
Это вообще очень интересный и важный результат, а мы его чуть не потеряли из-за неправильного эксперимента!
И это только три маленьких примера сравнения, прямо скажем, довольно тривиальной операции - вызова нативного метода.
Представьте теперь, что вы хотите сравнить два здоровенных фреймворка, сколько тонкостей будет там?
Что же тогда делать? Неужели всегда прошаривать детали реализации, а уж потом делать замер?
Я бы ответил, что это тоже не совсем правильно.
Черный ящик - хорошая точка входа, хороший первый замер. Но останавливаться на получении таким методом двух сухих цифр не стоит.
После этого стоит спросить себя: а почему технология A оказалась медленнее технологии B?
И еще: а что конкретно в технологии A заняло больше времени, чем в B?
Чтобы ответить на два этих вопроса, вам придется копнуть глубже, но необязательно при этом досконально изучать всю-всю технологию.
Сам этот результат подскажет вам, куда стоит посмотреть.
Самое сложное в этом подходе - вовремя остановиться.
Задавать вопросы "а почему?" можно очень долго. Например увидеть диф в асме и продолжить думать: а почему вот эта инструкция оказалась дольше вон той?
Но тут уже каждый сам решает, в какой момент ему становится это неважно.
Бенчи - это еще причина представлять, а что именно происходит под капотом JVM (или другой вашей виртуальной машины).
Без этого может быть сложно трактовать результаты замеров: слишком уж много оптимизаций произойдет под капотом, слишком много компонентов вмешается в работу бенча
Краткое резюме: цифры, которые вы получите на бенчах - это просто цифры, они никогда не врут. Ваша интерпретация этих цифр - вот, что важно.
А без ответа на вопрос "почему?" эта интерпретация может быть максимально ошибочна.
Хорошо, развлекательный тред тогда перенесем до лучших времен (запощу потом у себя), а сейчас все-таки поговорим о пропущенной технической теме: бенчирование. Я буду говорить про бенчирование на JVM, но мысли в целом довольно универсальные.
про бенчирование и черные ящики
twitter.com/itunderhood/st…
так, нам нужен пакет с пакетами. здесь будет тред всех тредов, в конце его перепощу 🧵
тред - пакет с пакетами (нужно четко следовать определению треда всех тредов!)
twitter.com/itunderhood/st…
так, нам нужен пакет с пакетами. здесь будет тред всех тредов, в конце его перепощу 🧵
Ну что, пора прощаться!
Надеюсь, что на этой неделе вы узнали что-нибудь новое и интересное. Мне с вами понравилось!
Если хотите больше, подписывайтесь на мой личный твиттер: @dbg_nsk
А все темы за прошедшую неделю здесь: twitter.com/itunderhood/st…
