Представьте, что вы пришли на встречу JUG.ru или CodeFreeze, или например на джавовскую конференцию, на которой только что выступил Сергей Walrus Куксенко, разработчик из Java Performance Team. И вот, по какой-то причине, все остальные слушатели разбежались, а вы с Сергеем остались один на один. И внезапно, он никуда не торопится, и у него есть свободный час, чтобы ответить на ваши вопросы, коих накопилось великое множество…
Встречайте: сегодня у нас абсолютный эксклюзив — большое интервью с Сергеем Куксенко! Из интервью вы узнаете:
— Сергей, ты у нас часто выступаешь с докладами, и твои доклады с каждым разом становятся все сложнее и сложнее с точки зрения материала, который ты рассказываешь, и все глубже и глубже уходят внутрь всяких железячных вещей. Когда ты рассказываешь, ты смотришь в глаза людям – ты видишь там понимание какое-то, или по мере углубления понимание теряется?
Куксенко: Это самый ключевой фидбек, который я вообще пытаюсь поймать на своих докладах. Дело в том, что когда я вижу ответ аудитории, я чувствую некоторое удовольствие от того, что мой доклад прошел не впустую, и в среднем, если я вижу хотя бы с десяток активных слушателей, я считаю, что доклад удался. Такое происходит достаточно часто.
— То есть у тебя есть некий процент, за который ты пытаешься держаться?
Куксенко: Да, я доношу информацию, мне нужно, чтобы она до кого-нибудь дошла, чтобы я делал презентацию не просто для себя.
— А как сделать этот выбор, когда в аудитории у тебя люди с разным бекграундом, у них разный уровень понимания? Ты заранее говоришь, что «Я буду рассказывать фиксированную сложность», или ты сложность подстраиваешь?
Куксенко: Я заранее объявляю, что будет достаточно сложный доклад, и если у меня есть информация об аудитории, и я знаю, что не будет достаточно заинтересованных людей, то я в таком случае не провожу доклад, не участвую в таких слабых конференциях.
— Как ты узнаешь информацию об аудитории?
Куксенко: Как правило, постфактум.
— Как организатор конференции, что я могу тебе про аудиторию рассказать такого, что может повлиять на твой доклад?
Куксенко: Я не знаю ответа на этот вопрос. Как правило, я по визитам на конференцию оцениваю уровень аудитории и решаю для себя в голове, поеду ли я сюда еще один раз, или нет.
— Ты в России выступаешь уже года четыре, не меньше. Ты года с 2012 начал?
Куксенко: Где-то с 2011.
— Ты видишь, что аудитория растет? Не по количеству, а по степени понимания того, о чем ты рассказываешь?
Куксенко: Честно говоря, нет. Я вижу немножко обратную связь – я вижу, что аудитория устала, я вижу, что люди устают от сложных докладов, которые мы докладываем из года в год. Ну, по крайней мере, мне так кажется. Я вижу, что достаточно интересные люди, которых я запоминаю на различных конференций, уходят из этой области. То ли карьерный рост у них начинается, то ли они переключаются в менеджеры, то ли еще что-то. И я пока не вижу серьезной замены.
Возможно, срабатывал эффект первых докладов, когда у людей был некоторый голод по техническим вещам, они задавали массу вопросов. Сейчас я вижу снижение такого интереса со стороны аудитории к сложным техническим докладам.
— Это интересно, потому что мне очень нравится, что вы с Лёшей (имеется в виду Алексей Шипилёв — прим. автора) не занимаетесь самокопированием. В 2011-2012 году была тема производительности, а потом она разраслась немного.
Куксенко: Мы все рассказали. Зачем повторяться? С 2012 года ничего не поменялось в этой области.
— Насколько активно развивается performance-наука сейчас, и, может, перфоманс в Java, в частности?
Куксенко: Я ничего не скажу за performance-науку. Я не знаю, что происходит в науке. Наверное, что-то развивается. Performance – это не столько наука, сколько прикладная инженерия, когда у нас есть что-то реальное, и это реальное надо впихнуть в какие-то временные рамки, в требования и т.д.
В Java делаются изменения в различных областях. Нет глобального плана: «К 2020 году наступит вселенское счастье, и мы будем выполнять любую операцию за одну пикосекунду». У нас есть продукт, мы находим какие-то места, мы подкручиваем его там, здесь… Изобретаются новые вещи, идет адаптация под новое железо, и т.д., то есть обычный процесс.
— Насколько быстро меняется железо для того чтобы люди, которые занимаются перфомансом, могли использовать новые железные фишки?
Куксенко: Intel каждые два года выкатывает новую микроархитектуру с достаточно интересными фишками, но если начинать смотреть более-менее серьезные исследования, там выясняется, что то вышла какая-то супер-пупер новая фича, то новая архитектура… И сколько мы получили среднестатистического природа производительности в смысле средней температуры по всей больнице? Ну, плюс 6%.
Появляются периодически новые фичи Software. Часть Software за этим не успевает. Она пытается догонять, особенно на уровне Java, где мы должны представлять более-менее архитектурно независимые решения, мы еще должны за этим гнаться.
— Векторизация и векторные инструкции существуют уже очень много лет в современных процессорах. Часто виртуальную машину Java обвиняют, что она их особо не использует.
Куксенко: Здесь проблема двоякая, заключается в том, что, как правило, все эти инструкции затачиваются под конкретные сценарии и юзкейсы, и вопрос определения этих юзкейсов с абстрактного, не заточенного под данную архитектуру кода, до сих пор остается открытым. Автоматическая векторизация – вопрос, решенный для простых случаев. Но шаг влево, шаг вправо – и алгоритмы векторизации перестают работать.
Понятно, почему это требуется в железе – потому что существуют миллионы разработчиков, которые под конкретную платформу затачивают по-быстрому вплоть до а-ля ассемблерного уровня с помощью каких-нибудь Intrisic’ов и всего прочего нативный код, и получают необходимые вещи. У нас в Java немного другая цель, хотя мы этим не брезгуем, и самые ключевые вещи у нас точно таким же образом затачиваются.
— Можешь привести пример, когда затачиваются вручную?
Куксенко: Во-первых, строковые операции. Большинство из них заточены под конкретное железо, и скоро будут некоторые небольшие обновления в этой области, там будет еще, еще и еще. Это одна область.
Вторая область, которая классически всегда затачивается вручную – это область криптографии, потому что у нас появляются новые инструкции в железе, которые ориентированы на более быструю и на более защищенную криптографию (например, рандомный генератор настоящий в последних интеловских железках), и т.д. И очевидно, что с точки зрения криптографии в области секьюрити игнорировать эти возможности железа было бы не очень хорошо. Но здесь с той же криптографией ключевым стоит вопрос не вопрос производительности приложений, а вопрос защищенности приложений. Используя настоящий рандомный генератор, мы повышаем энтропию и увеличиваем нашу защиту, используя хитрые векторизированные команды для самого кодирования, мы позволяем себе возможность в те же временные рамки впихнуть, например, более сложные алгоритмы кодирования, что повышает защищенность. Здесь производительность опосредована. И здесь возникает большой вопрос, насколько реальному пользователю нужна векторизация.
— То есть вовсе не факт, что нужна? Просто на всех конференциях это любимый вопрос, когда что-то касается Java и перфоманса – как раз вопрос векторизации. Любят всякие сишники тыкать пальчиком, и говорить, что…
Куксенко: И как часто сишники реально добиваются хорошей векторизации их продуктов? За всю историю презентаций на уровне JPoint и Joker, на прошлом Joker'е я получил один единственный фидбек, когда я показывал, что «У меня есть пример. Так мы его разгоняем. А здесь случилась небольшая векторизация». Человек подходил в кулуарах и говорит: «Да, клево, ты показал замечательно. Я хотел разогнать одно место, теперь я буду добиваться того, чтобы оно векторизовалось». За все это время один единственный человек, которому это реально надо, и он знает свои задачи, мне попадался.
О перфомансном хардкоре
— Когда ты рассказываешь перфомансные основы, то понятно, что это надо более-менее всем. А вот когда ты рассказываешь очень продвинутые вещи – например, случай, когда CPU загружен на 100%, как в твоих последних докладах, то какой части людей это реально надо? Ощущение, что каждому сотому.
Куксенко: Если не меньше. На эту аудиторию мы и ориентируемся.
Как ты вообще относишься к образовательному аспекту таких докладов?
Куксенко: Я не рассматриваю их как образовательные, я рассматриваю их как больше ознакомительные, и просто показать, что «Туда, там есть много всего, что можно сделать». И человек, которому это будет нужно, поймет, что может двигаться в эту сторону и не топтаться на месте.
— Я говорил пару дней назад со знакомым тебе Олегом Буниным, человеком, который делал конференцию Highload, я его спросил, что такое Highload по его мнению, и он сказал такую вещь: «Highload начинается тогда, когда тебе становится важным, что у тебя внутри происходит в железе. Пока тебя не волнует, как что у тебя бегает – это не Highload, как только начинает волновать – это Highload». Как ты можешь прокомментировать это утверждение?
Куксенко: По мне, так Highload – это очередной баззворд. Как я всегда говорил у себя в докладах, производительность – это бинарная метрика: клиент или недоволен, или доволен, а дальше начинается всякая наша внутренняя кухня о том, как это померить, сколько денег мы на это потратим, купим мы железа побольше или, наоборот, подкрутим ручки у софта, и т.д. То есть вопрос, где кончается Highload, где начинается Highload – это вопрос, где мы проводим границы цветов. Спектр радуги непрерывный, но мы говорим, что «Этот зеленый, а этот красный», но на самом деле на границе мы не можем провести четко, что «Здесь начинается зеленый, а здесь красный». Здесь зеленый и красный – это очевидно всем кроме дальтоников. Так и с Highload, и со всеми вещами. Но есть небольшое требование, которое мы озвучиваем во всех своих докладах: «Если вы хотите заниматься производительность вашего приложения, если вам это необходимо, вы должны представлять, как работает все сверху донизу, весь стек: как работает ваше предложение, как работает application server, операционная система, железо, Ethernet-провод и т.д. И если вы знаете, как все это работает, тогда вы можете чего-то достичь и получить какие-то выигрыши в этом месте».
— Вы с Лешей начинали знаменитую серию презентаций 2011-2012 года с рассказа, что такое software engineering и что такое performance engineering, и в чем отличие, это был один из ваших первых слайдов. А по тулсет? Я, работая Java-инженером, примерно представляю себе, какой тулсет есть у типичного Java-инженера, может, даже у Java enterprise инженера. А какой тулсет у перфоманс инженера? Какие инструменты перфомттанс-инженер, в частности ты, используешь в повседневной работе?
Куксенко: bash! Все, во-первых, зависит от задач. Классический toolset, если работаешь с внешним бенчмарком – это какой-нибудь профайлер, который к нему цепляется. Профайлер может быть любой, они все одинаковые, по большому счету. И понятно, что есть преимущество в оракловских продуктах, как VisualVM или Mission Control.
Если приходится переходить на более низкий уровень, то начинаешь уже использовать стандартно то, что называется Oracle Solaris Studio Performance Analyzer (длинное название) – достаточно эффективный тул. И второе, для мелких вещей, для овервью, понимания точки зрения – это линуксовый perf. Практика показывает, что в последнее время я, как правило, использую эту связку: perf для овервью, и Oracle Solaris Studio Performance Analyzer для более-менее серьезного копания. Другие утилиты являются ненужными. Может быть, JFR изредка, посмотреть что-либо, что не выходит. JFR, Recorder и Mission Control, но именно посмотреть то, что не выходит за уровень Java.
— А про амплифаер что ты думаешь?
Про Amplifier я ничего сказать не могу, потому что я Amplifier'ом никогда не пользовался. Я пользовался этим продуктом пять-шесть лет назад, когда он еще назывался просто интеловский VTune, и с точки зрения работы по интеловскому железу, платформы Windows это было идеально в то время. Но там были проблемы с работой под не интеловское железо, и с работой с чем-то другим, отличным от Windows в те годы. Сейчас я слышал, что в VTune Amplifier ребята сделали очень серьезную продвижку на автоматический анализ, в том смысле, что он перестает просто показывать тонны различных цифр, чисел и т.п., пытается хайлайтить ключевые проблемы.
— То есть, по сути, дать интерпретацию?
Куксенко: Да, он пытается производить уже некоторый аккаунтинг, классификацию проблем, которые он находит. Я это видел краем глаза на презентации, на практике не использовал.
— То есть непонятно, насколько это правда, насколько это маркетинг?
Куксенко: Если верить презентации, то это правда, и это должно работать, но это привязка под интеловское железо.
— 10 лет назад у нас был AMD, как некий игрок везде – лэптоп, десктоп, серверы, – то сейчас про AMD мы слышим все меньше и меньше, но зато очень серьезно в последние годы появился ARM и ARM-архитектуры. Насколько часто ты в повседневной работе имеешь дело с ARM'ами какого-либо вида, и что ты можешь сказать, с ними есть какие-то отличия?
Куксенко: В повседневной работе я имел дело с ARM'ами ноль раз. Я один раз только сделал свои эксперименты на ARM'ах. Когда я делал одну из своих презентаций, мне стало любопытно сделать параллельный замер на ARM'ах. Тогда я сделал эти замеры, и просто сравнил это с интеловскими архитектурами. Поэтому, поскольку я реально с ARM'ами не работаю, говорить мне пока об этом нечего – нет базиса, хотя платформа достаточно перспективна и достаточно агрессивно вытесняющая Intel из различных ниш.
— По ощущениям она развивается гораздо интереснее, потому что то, о чем ты говорил про 6% роста – такое ощущение, что Intel немножко стагнировал. Ощущение складывается, что перфоманс не растет. Энергоэффективность, возможно, растет, что-то другое типа шифрования появляется, но это, такое ощущение, что рост вширь. Лэптоп пятилетней давности оказывается с точки зрения перфоманса актуальным.
Куксенко: С точки зрения производительности, которая используется конечным пользователем, он оказывается точно таким же. Как у него пять лет назад ты мог смотреть свои киношки на Youtube, так и сейчас ты смотришь свои киношки на Youtube, не видишь никакой разницы. Как пять лет назад ты ходил в Twitter и писал какие-то почты, так и сейчас. Ты не замечаешь разницы. Дело в том, что базовые платформы уже давно достигли требуемой конечным пользователем производительности. Конечно, начинается всякое 3D, Blu-ray, супервысокая четкость изображения, но это уже отдельная область, не в области производительности компьютеров. Но реально, спасибо моему коллеге Леше Шипилёву, он на днях произвел оценки ретроспективы индустрии у себя в Twitter. Он написал, что он померил некий бенчмарк, score которого он хорошо помнит еще по нашей работе в Intel 10-летней давности. И он отмечает, что за эти 10 лет этот бенчмарк стал быстрее в 50 раз на его лэптопе, чем тогда 10 лет назад на серверной машине. Я думаю, прирост производительности в 50 раз за 10 лет – вполне себе нормальный прогресс.
— То есть, на самом деле, развитие есть? Насколько это показательно? Ты помнишь пример что, что это за бенчмарк?
Куксенко: Я хорошо помню его, но думаю, что мы не будем его обсуждать. Я думаю, что когда ты будешь брать интервью у Алексея Шипилёва, ты лучше спросишь у него о релевантности этого бенчмарка, потому что он написал замену для этого бенчмарка.
Стринги
— Давай поговорим про String. Не секрет, что там сейчас происходят разные исследования, связанные с тем, как там можно более компактно записывать. Не секрет, что в последние годы этот класс начинает меняться. Замена substring(), и то, что было в JDK 7u6, и т.д. Насколько стрёмно менять базовый класс платформы? Насколько работа с этим классом отличается от работы с каким-нибудь другим, насколько сложнее какие-то changset'ы туда принимаются? Потому что это очень видимая область, и удивительно, что сейчас там происходит активная работа.
Куксенко: Здесь же не вопрос: «А давайте мы придумаем какой-нибудь чейндж, а дальше смотреть», а здесь вопрос выигрышей, которые мы с этого получаем. А поскольку, если у нас есть класс, который, мы знаем, что занимает 50% в памяти в любом приложении, если не больше, то давайте все-таки что-то с ним сделаем. Давно пора сделать, тем более что у нас были и старые наработки, эксперименты, которые не скрывались.
— Почему раньше работы в этой области стояли, а сейчас активизировались? За годы к стрингам накопилось много вопросов.
Куксенко: Не сказал бы, что работы в этой области стояли. Они делались. Может быть, они не всегда доводились до конца, и оставались экспериментальными, но при этом они были доступны на уровне поиграться. Просто сформировалось видение, как это должно быть сделано. Очень просто делать оптимизации, когда у тебя есть 10 шаблонов использования, и все прыгают в этих 10 шаблонах.
Ты сидишь, разбираешь эти 10 шаблонов, оптимизируешь под них поведение, получаешь выигрыш.
Когда у тебя класс используется тысячей, миллионом различных способов, причем у тебя огромная цена ошибки в этом месте, то очевидно, что ты не будешь сразу бросаться и с кондачка что-то писать. Здесь сначала надо посмотреть, как выигрыш для этих, и для тех, чтобы этим не было хуже, этим стало лучше, и при этом чтобы ничего не сломалось, и т.д. Вот и все действия, вся работа.
Oracle никогда не скрывал, что наибольшие затраты по человеко-часам по развитию Java, и у Sun тоже, они не в области девелопмента, они в области QA.
— На текущий день, по твоим оценкам, не переходя на персоналии, насколько мощный в Java у нас QA, в оракловой Java, в OpenJDK? То есть часто ли там пропускают что-то серьезное, на твой взгляд? Или так сложно сказать?
Куксенко: Мне сложно сказать. Я стараюсь не лезть в эту область, потому что она слишком большая. У нас есть замечательные специалисты, думаю, они гораздо лучше ответят. У нас есть QA-архитекторы, которые знают больше о состоянии дел.
— В JDK 7 update 6 меняли substring(). Интересно: изменение, казалось бы, маленькое, но очень видимое. И последствия этого изменения: долго ли к вам прибегали кастомеры и били вас ногами за этот чейндж, или вы предварительно с ними работали? Очень интересно, как делается анализ для таких изменений. Условно говоря, Условно говоря, это же понятный трейд-офф.
Куксенко: Это даже не сколько трейд-офф, и сколько было понятно, что кастомеры будут прибегать… Во-первых, к нам они лично никогда не прибегают, мы практически не работаем с конкретными кастомерами. Я знаю, существуют некоторые кастомеры, которые бегают и кричат: «Мы не будем переходить на JDK 7 Update 6, потому что не знаем, что это за изменение, не хотим его проверять», и т.д, но здесь не то, что мы просто взяли и сделали это изменение с сабстрингом, с удалением поля Offset и так далее, это один из необходимых шагов, которые двигают нас к финальной цели – легкие стринги, преимущество которых и польза очевидны.
— Что это?
Куксенко: Сейчас строчка – это у нас объект и массив. Если мы их склеим вместе, мы получим такой стринг, который будет иметь все бенефиты локейшена, которые будут занимать меньше памяти, потому что хедеры там не нужны, а особенно это важно для коротких строчек, и прочее. Куча выигрышей, куча пользы, есть огромное количество академических экспериментов в этой области, наш любимый университет Линца что-то делал. То есть есть люди, которые говорят, что «Делать надо так, мы даже сделали пруф оф концепт и получили такие-то выигрыши». И понятно, что мы тоже движемся в эту сторону, просто мы не можем себе позволить делать пруф оф концепт, мы должны делать финальное решение, поэтому мы движемся, может быть, медленно. И было очевидно, что это изменение – важный необходимый шаг по дороге туда, к тому, как мы это видим. Но давайте делать шаги по частям. Этот шаг можно сделать сейчас не откладывая, и тогда потом вываливать на кастомеров и тестировать на кастомерах нам придется меньше чем сейчас.
О производительности Stream API
— Год назад вышла Java 8. Ты много рассказывал про Stream'ы, про Stream API, про Bulk Data Operations, которые являются частью всего этого проекта. Ты активно пользуешься этим всем в повседневной разработке? И второе. Те надежды, которые на него возложены были с точки зрения того, что он даст преимущество в частности на многопроцессорных машинах, то, что это еще один уровень абстракции, другой подход к программированию – насколько они оправдались, по твоему ощущению? Дают ли Stream'ы какое-то реальное увеличение производительности?
Куксенко: Если пишу код, не зафиксированный внешними требованиями, то всегда пишут под Java 8, всегда пишу с использованием Stream'ов, хотя уже использую JDK 9 для таких целей. Меня очень радует то, что, присутствуя на различных конференциях, я опрашиваю людей, и я заметил, что достаточно большое количество людей перешло на JDK 8. Stream'ы мне очень нравятся в том, что код получается гораздо более компактный, и прочее в плане понимания, восприятия. Все-таки программисты чаще читают код, чем пишут.
В плане перфоманса это известный вопрос. Как я говорил, отвечая на этот же вопрос год назад в Киеве, я считаю, что классические пользователи в своей статистической массе ни огромных приростов производительности, ни огромных замедлений от перехода на Stream API не заметят. Люди, которые специально целятся на это дело, они наверняка выжмут из этого достаточно много полезных вещей.
— А части ли случаи, когда Stream API проигрывает по перфомансу классическому (Collections) API?
Куксенко: Как правило, Stream API проигрывает по производительности классическому API просто потому что Stream API подразумевает под собой некоторый оверхед, некоторые действия, которые мы обязаны сделать для того чтобы сконструировать хороший Stream и начать с ним работать. Вопрос: что мы выиграем, сделав эти некоторые затраты? Без параллелизации с точки зрения перфоманса тут нечего выигрывать, за исключением более компактного и лучше читаемого кода. Вопрос параллелизации, об этом тоже много говорилось, и писались различные примеры, шаблоны, графики, когда лучше переходить.
Сейчас самая осторожная оценка, которая выше нашей внутренней оценки, и которая, в принципе, достаточно разумна, и ее предлагал Даг Ли: если количество параллелизуемой работы в общем случае превышает 100 миллисекунд (на самом деле, микросекунд — прим.авт. с подачи apangin), то, параллелизуя ее, можно получить выигрыш с вероятностью 99%. Если количество работы меньше 100 микросекунд, лучше не заморачиваться параллелизацией. По нашим замерам это 10 микросекунд, но там уже… Это безопасная граница.
— 100 – более консервативная оценка?
Куксенко: Да, и более чем достаточная. Я бы переходил на Stream API только по причине того, что код является компактным. Там существуют некоторые проблемы со стороны hotspot и JDK. Не то, что проблемы, а мы знаем, что есть тут и тут не очень хорошо, мы знаем, что это тут и тут надо улучшить, мы сейчас думаем, как нам это сделать.
Даг
— Ты вспомнил Дага Ли. Для меня было некоторым удивление, как построено взаимодействие работы с Дагом, потому что есть мнение, что Oracle даже больше, чем Sun, был совсем консервативной организацией даже с точки зрения OpenJDK, и не очень активно пускал внешних коммиттеров. В принципе, что при Oracle ситуация улучшилась, и все больше и больше появляется внешних коммиттеров, которые что-то контрибьютят в платформу, но с Дагом история совсем особенная, потому что, чуть поработав внутри, мне так посчастливилось, и посмотрев на то, как строится взаимодействие с Дагом, получается, что это вообще какой-то очень специальный человек, который специальным образом стоит по отношению к организации. И в этом смысле это феномен. Просто канкаренси – это одно из главных направлений, по которому развивается современный перфоманс, железо, наука и все это. Расскажи о том, как вы с Дагом взаимодействуете, и почему он на таких привилегированных условиях по отношению к другим?
Куксенко: Если мы возьмем какую-то конкретную область, то можно найти в этой области человека, который является признанным экспертом. Хорошо, если в этой области есть 100 экспертов, и мы можем десяток из них просто нанять, и они будут у нас делать эту область. Это полезно для нашего продукта, и для всей системы. Плохо, когда в этой области есть выдающиеся эксперты, потому что выдающемуся эксперту требуются выдающиеся условия, и в этом случае иногда, может быть, не удастся так корпоративно нанять и приказать сверху, как любят большие корпорации, делать что-то, а в этом случае с таким человеком приходится договариваться, потому что это приносит пользу всем, развитию продукта, если мы можем договориться с человеком снаружи о его контрибуции в эту конкретно область. Даг Ли – это выдающийся человек в той области, это эксперт, равного которому найти сложно, поэтому сложилась, не знаю, исторически или нет, такая схема коллаборации, что он сидит у себя в институте, делает вещи, изобретает, проверяет, делает их, и они попадают к нам в Java, потому что всем от этого польза. Мы развиваем наш продукт, и так далее.
— А кроме Дага существуют другие люди, которые с платформой работают в специальном режиме на специальных условиях?
Куксенко: Может быть, я не знаю.
— То есть, по крайней мере, в перфомансе таких вещей нет?
Куксенко: У нас есть Oracle Labs, и много вещей, связанных с High Performance, High Concurrency вещей приходит от них. Oracle Labs – это более академическая организация, поэтому это более академический мир, у них свои контакты, своя кухня, а к нам приходят готовые решения, которые мы просто воплощаем в жизнь.
— Перфоманс, он везде, по крайней мере в рантайме. Глянешь в GC – перфоманс, глянешь в коллекции – перфоманс, Stream'ы – перфоманс, VM – перфоманс, JIT – перфоманс...
Куксенко: А что значит перфоманс? Перфоманс – скорость исполнения некоего процесса. А время — оно везде. Отсюда и скорость исполнения любых процессов везде. Это мы уже уходим из computer science, приходим к Эйнштейну.
Команда
— У вас есть перфоманс команда в Java, наверное, правильно говорить Oracle Java SE Performance Team. Расскажи про команду, что там за люди, сколько их, и как у вас построена работа.
Куксенко: В команде меньше десятка человек. Чисто технически наша работа сейчас заключается в том, что мы берем различные фичи, различные подпроекты по разработке JDK, и занимаемся их производительностью, на двух уровнях. Первое: убедиться, что там нет серьезных косяков. Второе: если мы убедились, что косяков нет, и мы можем предложить какие-то улучшения, мы их предлагаем. Проект достаточно независимый, как правило, мы редко пересекаемся по работе.
— То есть один инженер – один проект?
Куксенко: Как правило, да.
— Можешь привести примеры таких проектов?
Куксенко: Проект Lambda, проект Jigsaw, Application Data Sharing. В String какие-то конкретные предложены улучшения по синхронизации. Перфоманс-улучшения для G1 Garbage Collector.
— Насколько актуальны внешние performance-контрибьюторы, кроме Дага (Дага, наверное, нельзя считать внешним)? Условно говоря, есть всякие concurrency-interest и прочие источники, где все время идет обсуждение. Насколько активно вы принимаете патчи от community, и что можно сказать о качестве таких патчей?
Куксенко: В этом смысле мы находимся в похожей ситуации: мы не принимаем патчи, мы их предлагаем. Есть владелец кода, например, ребята из Hotspot, и если у нас есть какое-то перфомансное улучшение, мы предлагаем им свою идею патча. Точно также какой-нибудь Вася Пупкин может прийти в OpenJDK mailing list и предложить изменение и улучшение, патч. И вопрос принятия или нет того или иного патча решают владельцы кода, в данном случае команда Hotspot или команда Class Libraries, и мы в этом смысле не принимаем решения, мы предлагаем. Но мы можем проверифицировать стороннее решение, можем обеспечить какие-то данные по замерам, но финальное слово всегда за владельцем кода, как бы мы с ним не спорили, потому что помимо перфоманса существуют требования к качеству кода, его функциональной правильности, в области секьюрити, и прочее.
— Все такие изменения проходят обязательные ревью…
Куксенко: Нам немножко проще, нас знают.
— То есть можно говорить о том, что авторитет важнее в этой области, чем принадлежность к конкретной команде, организации?
Куксенко: И даже больше, потому что, будь я сторонним разработчиком, то мог бы выбрать какую-то интересную вещь в Hotspot, начать ее ковырять, наковырять, получить каких-то приростов, прибежать и начать громко размахивать. Будучи в Oracle, я вынужден заниматься теми вещами, которые, может быть, не приносят мне такой большой славы, но нам их надо сделать, надо дорыть, докопать, тут доделать, тут проверить, и приходится заниматься этим.
— Насколько большой процент возни неприятной и процент интересных исследований по работе, с которыми приходится иметь дело? Часто встречается что-то удивительное? Часто ли тебе приходится натыкаться на такие места в Java, в которых нога перфоманс-инженера не ступала?
Куксенко: Каждый день.
— Как так выходит? У людей снаружи, когда я сам был таким человеком, казалось, что люди, которые делают Java – это некоторые небожители, у которых любая строчка строго обоснована, все оптимизировано по самое не балуй, и соваться туда простым смертным вообще не стоит. Видимо, это не совсем так?
Куксенко: Это не совсем так. Производительность очень часто, если мы не занимаемся каким-нибудь Highload, – это не функциональное требование. Сначала продукт должен работать правильно, а потом он должен работать быстро, и то, если это нужно. Поэтому наличие огромного количества мест, которыми a) никто не занимался, потому что не дошли руки посмотреть, b) потому что туда не надо смотреть, и никого это не волнует, c) потому что раньше это никого не волновало, а сейчас это стало достаточно большой проблемой. Но не будем забывать, что основные усилия должны делаться на правильность. У нас огромное количество кода, где не ступала нога перфоманс инженеров, но все строчки в котором обоснованы с точки зрения корректности. Не будем забывать, что сейчас в команде, которая занимается Java SE перфомансом, меньше 10 человек.
— А насколько, по ощущению, этого достаточно?
Куксенко: При наличии рядом высококвалифицированных команд, которые разрабатывают основной код, этого более чем достаточно. Поскольку наши ключевые инженеры, которые разрабатывают и компилятор, и Garbage Collector и Class Libraries, высоко квалифицированы, мы им помогаем. Не в том смысле, что мы их куда-то двигаем, толкаем, пинаем, а мы выступаем как вспомогательное средство. Если бы у нас по квалификации команда разработчиков была достаточно средняя с точки зрения производительности, тогда мы бы заняли более активную позицию. Сейчас в этом просто нет необходимости, потому что много вещей делается без нашего участия.
— Насколько мы можем говорить о том, что Oracle удалось сейчас в Java собрать экспертов в перфомансе, в VM? Насколько это люди мирового уровня, или люди мирового уровня работают где-то в другом месте, по твоим оценкам?
Куксенко: В этом смысле практика – это критерий истины. Если бы эксперты мирового уровня работали в каком-то другом месте, думаю, мы бы сейчас разговаривали о каком-то продукте.
О других технологиях
— А насколько то, что сейчас происходит, условно говоря, в Java-платформе с точки зрения перфоманса и Rocket Science, с точки зрения того, насколько крутые штуки там делаются, можно ли крутость этих штук сравнить с крутостью вещей, которые делают другие ребята, скажем, Google V8, или аналогичные, .NET, например?
Куксенко: Ничего не могу сказать про .NET. Я его даже никогда не видел. Google V8 видел – вполне себе нормальная штука.
— Не секрет, что многие JVM-инженеры считают Dalvik поделкой. Не знаю почему, но с кем ни поговоришь – все плюются, что как VM она так себе. Как так вышло, что вроде все пользуются Android’ом, а VM-инженеры предъявляют ее машине претензии?
Куксенко: Это работа инженеров – предъявлять претензии. Если бы инженеры не предъявляли претензии к этому продукту, я бы подумал, что либо с инженерами, либо с продуктами что-то не так. У меня есть масса претензий к Java, но я их оставлю при себе.
— Может быть, одну-две для наших зрителей, слушателей, из тех, что можно вынести, из тех, которые ты бы хотел улучшить или что-то сделать.
Куксенко: Обратная совместимость. Я считаю, что надо выкинуть все нафиг и написать все с нуля Но это не подход.
— Он любимый, мне кажется, не только в перфомансе, а везде.
Куксенко: Ошибки дизайна базового API потихоньку накапливаются с годами, и это становится неудобно. Даже не касаясь того, как работает сам язык и все системы, я бы выкинул весь базовый API, и задизайнил новый, более компактный и правильный с учетом ошибок. Но понимаю, что эту работу сделать не то, что нереально, ее невозможно сделать. Никто не в состоянии задизайнить этот API from scratch, и поэтому остается потихонечку добавлять новое, а старое потихонечку депрекейтить. Так и живем.
О разных JVM
— Работа по созданию рантайма, своей виртуальной машины… Есть мнение, что создать виртуальную машину – довольно плевое дело, какую-то самую простую без оптимизацией и так далее.
Куксенко: Да и с оптимизациями это несложно. Берешь и делаешь.
— А что ж там тогда такого годами и тысячами человеколет люди в Oracle делают?
Куксенко: Почему тысячами человеко-лет?
— А сколько? 20 лет уже существует VM в том или ином виде, те или иные. А сколько сейчас вообще VM-ов в Oracle JDK? Там же есть разные варианты.
Куксенко: У нас есть Embedded VM, но я плохо знаю этот мир embedded, поэтому ничего не скажу, что там у нас сейчас происходит.
— Это не Hotspot?
Куксенко: Это Hotspot, но это Embedded Hotspot, это отдельные ребята сидят и его разрабатывают.
— А там упор на footprint или что-то еще?
Куксенко: Там упор на то, чтобы хорошо работать на этих железках.
— Там ARM, скорее всего?
Куксенко: Там ARM и VM под ARM. И все, у нас один Hotspot. У нас есть еще JRockit, есть его поддержка для кастомеров еще осуществляется какое-то время. Его поддерживают совершенно разные люди, потому что команда, которая занимается поддержкой, она достаточно распределенная. Если были или, может, до сих пор есть люди в Санкт-Петербурге, которые над этим работают, но JRockit так и остался на уровне Java 6.
— То есть вы не занимаетесь JRockit?
Куксенко: Не занимаемся.
— История начала 2010 годов – покупка компании Sun компанией Oracle, и разговоры про слияние JRockit и Hotspot, ты что-нибудь знаешь или помнишь, может быть, о том, как это решение принималось, почему оно было принято именно такое? Какие тут критерии могут быть?
Куксенко: Есть компания Oracle, у Oracle есть две виртуальные машины, обе хорошие. Очевидно, надо сливать. Принимаем решение – сливаем.
— Но ведь приняли решение оставить Hotspot, интегрировать туда лучшие фичи и лучшие решения из JRockit.
Куксенко: Да.
— Почему не наоборот? Понятно, что, скорее всего, нужно фичи из одного интегрировать в другую, потому что слияние другого типа, наверное, невозможно с учетом сложности обоих программ.
Куксенко: Просто оно и невозможно, да и это получилось нечто страшное и ужасное.
— Как можно провести анализ, какое из решений выбрать в данном случае? Я даже не представляю себе, как это.
Куксенко: Смотря какие требования. Я не очень хорошо помню и не очень знаю, какие требования ставились, но здесь возникает вопрос, что хотят наши кастомеры. Это самый ключевой вопрос. Если кастомеры скажут, что «Мы привыкли к Hotspot и мы никогда не пойдем на JRockit», и это будет 70-80%, то все, дальнейшая дискуссия остановлена. Если другие кастомеры прибегут и скажут: «А мы хотим JRockit, но мы не хотим на Hotspot», то будет обратная ситуация – обратная ситуация. Дальше возникает вопрос: «А что вам так нравится в том же JRockit или в Hotspot, чтобы вы хотели оставить?». А после этого, когда уже все кастомерные фидбеки собраны, результаты поняты, и дальше смотрим по фичам, сколько будет стоить добавить фич туда, сколько будет добавить фич туда, общий цикл. Думаю, это просто общее решение, что наработки по Hotspot, в том числе по тому же циклу QA (00:48:34), они были гораздо больше, поэтому было решено фичи из JRockit добавлять в Hotspot, а не наоборот.
— На слуху Metaspace, Flight Recorder и Mission Control. А что еще кроме этих вещей было перетащено, перенято из JRockit в Hotspot?
Куксенко: Насколько знаю, идут работы, не знаю их статус, завершились или нет, по тому, что механизмы синхронизации станут похожими на те, к что сделаны на JRockit. Не будет 100% переписывания, но некоторые идеи…
— Основные вещи уже сделаны?
Куксенко: Конечно. Они были сделаны еще тогда, когда эти VM жили в разных компаниях.
— Бытует мнение, что сложность существующих JIT-компиляторов, в особенности C2-комплиятора, она такова, что уже препятствует его дальнейшему развитию? И все проекты, связанные с переписыванием JIT на что-то новое.
Куксенко: Существует такая точка зрения, но существует и более мягкая, которая заключается в том, что не JIT невозможно развивать, а существует достаточно высокий порог входа в JIT-разработку имеющегося того же компилятора C2. То есть человек, желающий сделать что-то в компиляторе, он тратит много времени на начальное вхождение, прежде чем начать выдавать полезные изменения и улучшения. Во-первых, я не сказал бы, что это мешает дальнейшему развитию, компилятор развивается. Вопрос высокого порога входа тоже дискутируем – является ли это плюсом или минусом. Может быть, наоборот, это хороший критерий отсева для людей.
— Чтобы всякие ламеры не лезли?
Куксенко: Есть, может быть, дискуссии. Это политическая или организационная дискуссия – подсчет человеко-часов, потраченных на развитие. Мне бы не хотелось в это углубляться.
— То есть больших инженерных проблем нет?
Куксенко: Есть инженерные вопросы, может быть, сделать так, может быть, сделать сяк. Банальная третьесторонняя зависимость от C и C++ компиляторов начинает раздражать.
— И в каком направлении все это развивается? Писать на Java?
Куксенко: Например, это проект Graal – бери, скачивай, играйся, он работает.
— Наверное, тяжело говорить, то есть в девятке его понятно, что не будет.
Куксенко: Нет. Это третьесторонний проект под одним швейцарским университетом, в том числе с участием Oracle. Он активно используется людьми для прототипирования, для работ в области GPU акселерации, и так далее. То есть он занимает свою достаточно большую нишу в области исследований, и что выйдет – посмотрим дальше. По крайней мере, свою нишу, как хороший академический тул для того чтобы делать исследования в области, именно базируясь на Hotspot, он уже давно занял.
— И аналогичный проект в области GC. Есть Shenandoah, который RedHat в свое время предложил. Ты что-нибудь знаешь по тому, что там сейчас происходит?
Куксенко: К сожалению, не знаю никаких деталей.
— Ты видел? Насколько это интересно?
Куксенко: Я знаю, что RedHat будет адаптировать Shenandoah под Hotspot, и какие-то работы в этом ведутся.
— Еще есть история, что лет пять назад очень большие надежды возлагались на Garbage First Collector, но если поговорить с людьми на конференциях, то в продакшене почти у всех CMS Collector. Так ли это по твоему ощущению, с кем ты общаешься, что тебе говорят, и если это так, то почему это происходит?
Куксенко: Думаю, в первую очередь, от лени. Идеальный продукт должен иметь одну кнопку – «Вкл»
— Удалось ли добиться Garbage First инженерам, людям, которые его разрабатывают, того, чего они хотели?
Куксенко: Мне сложно сказать, я не работаю с Garbage First, не знаю, что сейчас происходит в этой области. У нас на приближающейся осенью Java One заанонсированы доклады людей в том числе людей из нашей перфомансной команды о том, что сейчас происходит реально в области Garbage First. Давайте дождемся Java One, и посмотрим объявленные результаты. Я, конечно, могу сейчас прийти, написать письмо человеку и спросить: «А что ты собираешься рассказывать осенью, что там произошло?», но так прямо сейчас в дискуссии я не знаю этого ответа.
Как любые вещи, Garbage First необходимо было дотюнить, доделать какие-то работы. Эти работы велись, они сделаны, какие-то результаты были достигнуты. Очевидно, что при правильном процессе Garbage First рано или поздно станет нормально себя вести. Думаю, что это будет достаточно рано.
Почему люди не хотят уходить? Во-первых, потому что под CMS-ные тюнинги есть огромное количество готовых рекомендаций, как это надо делать. Тебе не надо думать, ты открываешь, читаешь книжку и по алгоритму побежал: «Так, если так, то сяк, если так – то сяк». Активных и больших описаний по тому, как и где какие ручки подкручивать под Garbage First в природе еще не существует, и они только сейчас создаются. Это первая причина, почему люди не переходят под Garbage First, потому что там я могу покрутить, а тут я еще не знаю – страшно переходить на что-то новое. Вторая причина – многие еще ленятся переходить с Java 7 на Java 8, а Java 7…
— Почти уже end of life… Было анонсировано, что вроде в апреле будет последний публичный апдейт.
Куксенко: Где-то так. И третья причина – лень.
— Да. Может, с нее стоило начать.
Куксенко: Лень у программистов всегда бывает двух видов: это просто нативная лень, которая естественным образом присутствует, и вторая по принципу «Солнце восходит на Востоке. Работает? Работает. Не трогай».
— С точки зрения подхода к разработке существуют, условно говоря, разные императивные вещи, когда мы говорим, как мы хотим что-то сделать, а существуют некие декларативные, когда мы говорим, что хотим сделать. Какие были параметры в старых GC? Размер такого региона, сякого региона, то есть это был ответ на вопрос, как мы хотим сделать. А в Garbage First появились способы задекларировать то, что мы хотим. Например, размер паузы. То есть, мы уже работаем в неких целевых пользовательских показателях. Насколько это интересное направление для развития?
Куксенко: Всем очевидно, мы сами знаем, как должен выглядеть идеальный продукт. Мы даже у себя на слайдовой презентации показывали, что идеальный продукт должен иметь одну кнопку – «Вкл». Ты его включил, и он работает. Он не должен иметь 10 тыс. рычажков, ручек, кнопочек, с помощью которого ты начинаешь его крутить. И здесь даже не вопрос парадигмы функциональной или императивной, это вопрос того, чтобы иметь под конец, рано или поздно, одну большую кнопку «Вкл». Это не то, что цель, мы ее достигнем и уйдем все на пенсию, и так далее, возможно, эта цель недостижима, но к ней полезно было бы стремиться. И чем меньше параметров, чем меньше пространства для игры, тем лучше всем. Потому что если мы сейчас возьмем опции Java виртуальной машины Hotspot, управляют работой Garbage Collector, и захотим просто для своего понимания, не основываясь на знании нашего приложения, а просто давайте переберем их хотя бы в каком-то диапазоне – это займет огромное количество времени, просто поиграться – туда, сюда, туда, сюда, а что меняется в этих сочетаниях.
— Это история про эвристику. Я понял, что ты хочешь сказать, и я тогда чуть в сторону. Есть некий продукт – Hotspot, GC, Runtime, стул, у него есть некие инженерные характеристики – то, что он сделан из дерева, весит столько-то, прибит гвоздями и так далее, а есть некие потребительские – то, что он такого-то цвета, разваливается или не разваливается, занозы у него тебе в задницу цепляются, не цепляются, и так далее. Такое ощущение, что параметры GC в старом виде – это некие инженерные характеристики – все эти килобайты и килобиты, а эти миллисекунды – это воспринимаемые характеристики.
Куксенко: Да. Приведу другую, что едем мы на автомобиле старого производства, тут мы давим кнопку на газ, здесь мы переключаем передачи, здесь мы еще определяем подсос у бензина, потому что плохо там тянется, здесь еще какую-нибудь ручку надо подкрутить, я уж плохо знаю, или мы садимся в другую машину, включаем ключ зажигания, немножко жмем на газ для начала, а потом включаем круиз-контроль и говорим: «Хочу 60 км/час», и едем. Что удобнее?
— И уже как оно справляется – это уже его собственное дело?
Куксенко: Это совершенно не наша забота. Если я выставил свои требования 60 км/час, и оно мне дает 60 км/час, зачем мне выяснять, что там происходит дальше? Очевидно, что для конечного пользователя такой продукт будет быстрее. Да, конечно, может быть, для ряда автомехаников, которые раньше сидели у себя в гаражах и регулировали там упреждение, зажигание или что-нибудь еще, это означает потерю работы, в том числе для CMS-тюнеров это тоже означает потерю работы, но, по-моему, в конечном итоге, для всех это было бы удобнее.
— Если мы двигаемся в сторону уменьшения разных рычажков, и хотим прийти к тому, чтобы пользователь...
Куксенко: Мы не движемся в сторону уменьшения. Мы говорим, что «Эти рычажки остаются на панели, а те под капотом. Открывай капот и крути, пожалуйста».
— То есть возможность крутить все равно остается?
Куксенко: Конечно.
— Просто, с одной стороны, есть движение в сторону уменьшения количества ручек, а с другой стороны, то, чем занимаешься ты с точки зрения своего евангелизма, который ты ведешь на конференциях, «Джугах» и даже сейчас, и с точки зрения того, что мы делаем, как организаторы конференции – мы пытаемся показать какие-то внутренности. И насколько вообще нужно показывать внутренности, учитывая, что у людей все меньше и меньше, даже оставаясь в той же терминологии, рычагов влияния на то, как их Runtime себя ведет?
Куксенко: Я бы, во-первых, не стал утверждать, что людям остается меньше рычагов влияния на то, как Runtime себя ведет, и как это все работает.
Я бы сказал о другом. Дело в том, что если есть требования к производительности Runtime, то мы можем сесть, понять, как он себя ведет, построить перфомансную модель, понять, что можно улучшить, и выдать результат. А текущее состояние, когда у нас есть 100 тыс. ручек, оно приводит к тому, что люди приходят: «У нас нет, мы не хотим разбираться или у нас нет времени разбираться, как это все работает, мы лучше ручки покрутим, посмотрим, что произойдет». Это вполне себе валидный способ действий в определенных случаях, он отнюдь не всегда работает, вплоть до того, что появляется очередная прослойка людей, которые не понимают, как это работает все в деталях, а они умеют поворачивать ручечки. Они знают, что есть ручечки, которые можно крутить, и ходят, их крутят. Это усложняет всю цепочку работы. Да, конечно, перфоманс-инженеров в таком виде, как у нас востребованы – это не очень часто требуемая специальность.
Выступление на JPoint
— Попрошу тебя рассказать немножко о своем докладе, который у тебя будет на JPoint. Он вроде называется так же, как и на Джокере. Будет ли этот тот же доклад, или не тот же, что ты в нем переделаешь? Что за доклад, и чем они будут отличаться?
Куксенко: Доклад будет по-прежнему посвящен аспекту анализа производительности, производительных проблем на этот раз с помощью железа. Анализ, и то, как посмотреть то, что происходит в реальном железе в процессе работы нашей программы, как и что можно улучшить именно для производительности программы.
Ядро и основной доклад будут практически полностью совпадать с тем, что делалось на «Джокере», но я уже давно понял, что доклады нельзя рассказывать один раз, потому что всякий раз, когда ты рассказываешь второй, третий раз, ты исправляешь ошибки, добавляешь что-то более интересное, и т.д. То есть доклад становится более полезным, в нем появляется новая, убирается ненужная информация, и он для тебя становится интересен самому себе наконец-то. То есть, сделав доклад два-три раза, можно довести его до уже более хорошего состояния, когда его можно положить на полочку, и уже не менять. Как правило, доклад, прочитанных один раз, он еще не находится в таком состоянии, и там всегда есть что улучшить.
— Те твои фанаты, которые слушали тебя в Питере, и которые через три недели пойдут тебя слушать в Москву, они для себя что-нибудь новое узнают из него?
Куксенко: Надеюсь, да. По крайней мере, я сделаю меньше воды. У меня доклад, который я читал в Питере, на 40% состоял из воды. Думаю, что надо оставить процентов пять, добавить больше примеров, и немножко более ясное объяснение того, что там происходит, чем это было сделано.
— Дай напоследок какой-нибудь перфомансный совет нашим зрителям.
Куксенко: Перфомансный совет всегда только один может быть, и я всегда говорю его на всех конференциях: если вы хотите заниматься перфомансом, вы должны представлять и знать, как все это работает, все и везде.
P.S.:
Доклады Сергея, о которых идет речь в статье, заботливо собраны нами тут.
Анонс его выступления на JPoint — тут.
Встречайте: сегодня у нас абсолютный эксклюзив — большое интервью с Сергеем Куксенко! Из интервью вы узнаете:
- как устроена команда Java Performance
- в каких направлениях Java сейчас ведется активная performance-работа
- зачем нужен хардкор на джугах и конференциях
- что должен знать performance-инженер
- что такое хайлоад, и где проходит граница
- что прямо сейчас происходит с джавовыми строками
- в какую сторону эволюционируют тюнинг рантаймов
— Сергей, ты у нас часто выступаешь с докладами, и твои доклады с каждым разом становятся все сложнее и сложнее с точки зрения материала, который ты рассказываешь, и все глубже и глубже уходят внутрь всяких железячных вещей. Когда ты рассказываешь, ты смотришь в глаза людям – ты видишь там понимание какое-то, или по мере углубления понимание теряется?
Куксенко: Это самый ключевой фидбек, который я вообще пытаюсь поймать на своих докладах. Дело в том, что когда я вижу ответ аудитории, я чувствую некоторое удовольствие от того, что мой доклад прошел не впустую, и в среднем, если я вижу хотя бы с десяток активных слушателей, я считаю, что доклад удался. Такое происходит достаточно часто.
— То есть у тебя есть некий процент, за который ты пытаешься держаться?
Куксенко: Да, я доношу информацию, мне нужно, чтобы она до кого-нибудь дошла, чтобы я делал презентацию не просто для себя.
— А как сделать этот выбор, когда в аудитории у тебя люди с разным бекграундом, у них разный уровень понимания? Ты заранее говоришь, что «Я буду рассказывать фиксированную сложность», или ты сложность подстраиваешь?
Куксенко: Я заранее объявляю, что будет достаточно сложный доклад, и если у меня есть информация об аудитории, и я знаю, что не будет достаточно заинтересованных людей, то я в таком случае не провожу доклад, не участвую в таких слабых конференциях.
— Как ты узнаешь информацию об аудитории?
Куксенко: Как правило, постфактум.
— Как организатор конференции, что я могу тебе про аудиторию рассказать такого, что может повлиять на твой доклад?
Куксенко: Я не знаю ответа на этот вопрос. Как правило, я по визитам на конференцию оцениваю уровень аудитории и решаю для себя в голове, поеду ли я сюда еще один раз, или нет.
— Ты в России выступаешь уже года четыре, не меньше. Ты года с 2012 начал?
Куксенко: Где-то с 2011.
— Ты видишь, что аудитория растет? Не по количеству, а по степени понимания того, о чем ты рассказываешь?
Куксенко: Честно говоря, нет. Я вижу немножко обратную связь – я вижу, что аудитория устала, я вижу, что люди устают от сложных докладов, которые мы докладываем из года в год. Ну, по крайней мере, мне так кажется. Я вижу, что достаточно интересные люди, которых я запоминаю на различных конференций, уходят из этой области. То ли карьерный рост у них начинается, то ли они переключаются в менеджеры, то ли еще что-то. И я пока не вижу серьезной замены.
Возможно, срабатывал эффект первых докладов, когда у людей был некоторый голод по техническим вещам, они задавали массу вопросов. Сейчас я вижу снижение такого интереса со стороны аудитории к сложным техническим докладам.
— Это интересно, потому что мне очень нравится, что вы с Лёшей (имеется в виду Алексей Шипилёв — прим. автора) не занимаетесь самокопированием. В 2011-2012 году была тема производительности, а потом она разраслась немного.
Куксенко: Мы все рассказали. Зачем повторяться? С 2012 года ничего не поменялось в этой области.
— Насколько активно развивается performance-наука сейчас, и, может, перфоманс в Java, в частности?
Куксенко: Я ничего не скажу за performance-науку. Я не знаю, что происходит в науке. Наверное, что-то развивается. Performance – это не столько наука, сколько прикладная инженерия, когда у нас есть что-то реальное, и это реальное надо впихнуть в какие-то временные рамки, в требования и т.д.
В Java делаются изменения в различных областях. Нет глобального плана: «К 2020 году наступит вселенское счастье, и мы будем выполнять любую операцию за одну пикосекунду». У нас есть продукт, мы находим какие-то места, мы подкручиваем его там, здесь… Изобретаются новые вещи, идет адаптация под новое железо, и т.д., то есть обычный процесс.
— Насколько быстро меняется железо для того чтобы люди, которые занимаются перфомансом, могли использовать новые железные фишки?
Куксенко: Intel каждые два года выкатывает новую микроархитектуру с достаточно интересными фишками, но если начинать смотреть более-менее серьезные исследования, там выясняется, что то вышла какая-то супер-пупер новая фича, то новая архитектура… И сколько мы получили среднестатистического природа производительности в смысле средней температуры по всей больнице? Ну, плюс 6%.
Появляются периодически новые фичи Software. Часть Software за этим не успевает. Она пытается догонять, особенно на уровне Java, где мы должны представлять более-менее архитектурно независимые решения, мы еще должны за этим гнаться.
— Векторизация и векторные инструкции существуют уже очень много лет в современных процессорах. Часто виртуальную машину Java обвиняют, что она их особо не использует.
Куксенко: Здесь проблема двоякая, заключается в том, что, как правило, все эти инструкции затачиваются под конкретные сценарии и юзкейсы, и вопрос определения этих юзкейсов с абстрактного, не заточенного под данную архитектуру кода, до сих пор остается открытым. Автоматическая векторизация – вопрос, решенный для простых случаев. Но шаг влево, шаг вправо – и алгоритмы векторизации перестают работать.
Понятно, почему это требуется в железе – потому что существуют миллионы разработчиков, которые под конкретную платформу затачивают по-быстрому вплоть до а-ля ассемблерного уровня с помощью каких-нибудь Intrisic’ов и всего прочего нативный код, и получают необходимые вещи. У нас в Java немного другая цель, хотя мы этим не брезгуем, и самые ключевые вещи у нас точно таким же образом затачиваются.
— Можешь привести пример, когда затачиваются вручную?
Куксенко: Во-первых, строковые операции. Большинство из них заточены под конкретное железо, и скоро будут некоторые небольшие обновления в этой области, там будет еще, еще и еще. Это одна область.
Вторая область, которая классически всегда затачивается вручную – это область криптографии, потому что у нас появляются новые инструкции в железе, которые ориентированы на более быструю и на более защищенную криптографию (например, рандомный генератор настоящий в последних интеловских железках), и т.д. И очевидно, что с точки зрения криптографии в области секьюрити игнорировать эти возможности железа было бы не очень хорошо. Но здесь с той же криптографией ключевым стоит вопрос не вопрос производительности приложений, а вопрос защищенности приложений. Используя настоящий рандомный генератор, мы повышаем энтропию и увеличиваем нашу защиту, используя хитрые векторизированные команды для самого кодирования, мы позволяем себе возможность в те же временные рамки впихнуть, например, более сложные алгоритмы кодирования, что повышает защищенность. Здесь производительность опосредована. И здесь возникает большой вопрос, насколько реальному пользователю нужна векторизация.
— То есть вовсе не факт, что нужна? Просто на всех конференциях это любимый вопрос, когда что-то касается Java и перфоманса – как раз вопрос векторизации. Любят всякие сишники тыкать пальчиком, и говорить, что…
Куксенко: И как часто сишники реально добиваются хорошей векторизации их продуктов? За всю историю презентаций на уровне JPoint и Joker, на прошлом Joker'е я получил один единственный фидбек, когда я показывал, что «У меня есть пример. Так мы его разгоняем. А здесь случилась небольшая векторизация». Человек подходил в кулуарах и говорит: «Да, клево, ты показал замечательно. Я хотел разогнать одно место, теперь я буду добиваться того, чтобы оно векторизовалось». За все это время один единственный человек, которому это реально надо, и он знает свои задачи, мне попадался.
О перфомансном хардкоре
— Когда ты рассказываешь перфомансные основы, то понятно, что это надо более-менее всем. А вот когда ты рассказываешь очень продвинутые вещи – например, случай, когда CPU загружен на 100%, как в твоих последних докладах, то какой части людей это реально надо? Ощущение, что каждому сотому.
Куксенко: Если не меньше. На эту аудиторию мы и ориентируемся.
Как ты вообще относишься к образовательному аспекту таких докладов?
Куксенко: Я не рассматриваю их как образовательные, я рассматриваю их как больше ознакомительные, и просто показать, что «Туда, там есть много всего, что можно сделать». И человек, которому это будет нужно, поймет, что может двигаться в эту сторону и не топтаться на месте.
— Я говорил пару дней назад со знакомым тебе Олегом Буниным, человеком, который делал конференцию Highload, я его спросил, что такое Highload по его мнению, и он сказал такую вещь: «Highload начинается тогда, когда тебе становится важным, что у тебя внутри происходит в железе. Пока тебя не волнует, как что у тебя бегает – это не Highload, как только начинает волновать – это Highload». Как ты можешь прокомментировать это утверждение?
Куксенко: По мне, так Highload – это очередной баззворд. Как я всегда говорил у себя в докладах, производительность – это бинарная метрика: клиент или недоволен, или доволен, а дальше начинается всякая наша внутренняя кухня о том, как это померить, сколько денег мы на это потратим, купим мы железа побольше или, наоборот, подкрутим ручки у софта, и т.д. То есть вопрос, где кончается Highload, где начинается Highload – это вопрос, где мы проводим границы цветов. Спектр радуги непрерывный, но мы говорим, что «Этот зеленый, а этот красный», но на самом деле на границе мы не можем провести четко, что «Здесь начинается зеленый, а здесь красный». Здесь зеленый и красный – это очевидно всем кроме дальтоников. Так и с Highload, и со всеми вещами. Но есть небольшое требование, которое мы озвучиваем во всех своих докладах: «Если вы хотите заниматься производительность вашего приложения, если вам это необходимо, вы должны представлять, как работает все сверху донизу, весь стек: как работает ваше предложение, как работает application server, операционная система, железо, Ethernet-провод и т.д. И если вы знаете, как все это работает, тогда вы можете чего-то достичь и получить какие-то выигрыши в этом месте».
— Вы с Лешей начинали знаменитую серию презентаций 2011-2012 года с рассказа, что такое software engineering и что такое performance engineering, и в чем отличие, это был один из ваших первых слайдов. А по тулсет? Я, работая Java-инженером, примерно представляю себе, какой тулсет есть у типичного Java-инженера, может, даже у Java enterprise инженера. А какой тулсет у перфоманс инженера? Какие инструменты перфомттанс-инженер, в частности ты, используешь в повседневной работе?
Куксенко: bash! Все, во-первых, зависит от задач. Классический toolset, если работаешь с внешним бенчмарком – это какой-нибудь профайлер, который к нему цепляется. Профайлер может быть любой, они все одинаковые, по большому счету. И понятно, что есть преимущество в оракловских продуктах, как VisualVM или Mission Control.
Если приходится переходить на более низкий уровень, то начинаешь уже использовать стандартно то, что называется Oracle Solaris Studio Performance Analyzer (длинное название) – достаточно эффективный тул. И второе, для мелких вещей, для овервью, понимания точки зрения – это линуксовый perf. Практика показывает, что в последнее время я, как правило, использую эту связку: perf для овервью, и Oracle Solaris Studio Performance Analyzer для более-менее серьезного копания. Другие утилиты являются ненужными. Может быть, JFR изредка, посмотреть что-либо, что не выходит. JFR, Recorder и Mission Control, но именно посмотреть то, что не выходит за уровень Java.
— А про амплифаер что ты думаешь?
Про Amplifier я ничего сказать не могу, потому что я Amplifier'ом никогда не пользовался. Я пользовался этим продуктом пять-шесть лет назад, когда он еще назывался просто интеловский VTune, и с точки зрения работы по интеловскому железу, платформы Windows это было идеально в то время. Но там были проблемы с работой под не интеловское железо, и с работой с чем-то другим, отличным от Windows в те годы. Сейчас я слышал, что в VTune Amplifier ребята сделали очень серьезную продвижку на автоматический анализ, в том смысле, что он перестает просто показывать тонны различных цифр, чисел и т.п., пытается хайлайтить ключевые проблемы.
— То есть, по сути, дать интерпретацию?
Куксенко: Да, он пытается производить уже некоторый аккаунтинг, классификацию проблем, которые он находит. Я это видел краем глаза на презентации, на практике не использовал.
— То есть непонятно, насколько это правда, насколько это маркетинг?
Куксенко: Если верить презентации, то это правда, и это должно работать, но это привязка под интеловское железо.
— 10 лет назад у нас был AMD, как некий игрок везде – лэптоп, десктоп, серверы, – то сейчас про AMD мы слышим все меньше и меньше, но зато очень серьезно в последние годы появился ARM и ARM-архитектуры. Насколько часто ты в повседневной работе имеешь дело с ARM'ами какого-либо вида, и что ты можешь сказать, с ними есть какие-то отличия?
Куксенко: В повседневной работе я имел дело с ARM'ами ноль раз. Я один раз только сделал свои эксперименты на ARM'ах. Когда я делал одну из своих презентаций, мне стало любопытно сделать параллельный замер на ARM'ах. Тогда я сделал эти замеры, и просто сравнил это с интеловскими архитектурами. Поэтому, поскольку я реально с ARM'ами не работаю, говорить мне пока об этом нечего – нет базиса, хотя платформа достаточно перспективна и достаточно агрессивно вытесняющая Intel из различных ниш.
— По ощущениям она развивается гораздо интереснее, потому что то, о чем ты говорил про 6% роста – такое ощущение, что Intel немножко стагнировал. Ощущение складывается, что перфоманс не растет. Энергоэффективность, возможно, растет, что-то другое типа шифрования появляется, но это, такое ощущение, что рост вширь. Лэптоп пятилетней давности оказывается с точки зрения перфоманса актуальным.
Куксенко: С точки зрения производительности, которая используется конечным пользователем, он оказывается точно таким же. Как у него пять лет назад ты мог смотреть свои киношки на Youtube, так и сейчас ты смотришь свои киношки на Youtube, не видишь никакой разницы. Как пять лет назад ты ходил в Twitter и писал какие-то почты, так и сейчас. Ты не замечаешь разницы. Дело в том, что базовые платформы уже давно достигли требуемой конечным пользователем производительности. Конечно, начинается всякое 3D, Blu-ray, супервысокая четкость изображения, но это уже отдельная область, не в области производительности компьютеров. Но реально, спасибо моему коллеге Леше Шипилёву, он на днях произвел оценки ретроспективы индустрии у себя в Twitter. Он написал, что он померил некий бенчмарк, score которого он хорошо помнит еще по нашей работе в Intel 10-летней давности. И он отмечает, что за эти 10 лет этот бенчмарк стал быстрее в 50 раз на его лэптопе, чем тогда 10 лет назад на серверной машине. Я думаю, прирост производительности в 50 раз за 10 лет – вполне себе нормальный прогресс.
— То есть, на самом деле, развитие есть? Насколько это показательно? Ты помнишь пример что, что это за бенчмарк?
Куксенко: Я хорошо помню его, но думаю, что мы не будем его обсуждать. Я думаю, что когда ты будешь брать интервью у Алексея Шипилёва, ты лучше спросишь у него о релевантности этого бенчмарка, потому что он написал замену для этого бенчмарка.
Стринги
— Давай поговорим про String. Не секрет, что там сейчас происходят разные исследования, связанные с тем, как там можно более компактно записывать. Не секрет, что в последние годы этот класс начинает меняться. Замена substring(), и то, что было в JDK 7u6, и т.д. Насколько стрёмно менять базовый класс платформы? Насколько работа с этим классом отличается от работы с каким-нибудь другим, насколько сложнее какие-то changset'ы туда принимаются? Потому что это очень видимая область, и удивительно, что сейчас там происходит активная работа.
Куксенко: Здесь же не вопрос: «А давайте мы придумаем какой-нибудь чейндж, а дальше смотреть», а здесь вопрос выигрышей, которые мы с этого получаем. А поскольку, если у нас есть класс, который, мы знаем, что занимает 50% в памяти в любом приложении, если не больше, то давайте все-таки что-то с ним сделаем. Давно пора сделать, тем более что у нас были и старые наработки, эксперименты, которые не скрывались.
— Почему раньше работы в этой области стояли, а сейчас активизировались? За годы к стрингам накопилось много вопросов.
Куксенко: Не сказал бы, что работы в этой области стояли. Они делались. Может быть, они не всегда доводились до конца, и оставались экспериментальными, но при этом они были доступны на уровне поиграться. Просто сформировалось видение, как это должно быть сделано. Очень просто делать оптимизации, когда у тебя есть 10 шаблонов использования, и все прыгают в этих 10 шаблонах.
Ты сидишь, разбираешь эти 10 шаблонов, оптимизируешь под них поведение, получаешь выигрыш.
Когда у тебя класс используется тысячей, миллионом различных способов, причем у тебя огромная цена ошибки в этом месте, то очевидно, что ты не будешь сразу бросаться и с кондачка что-то писать. Здесь сначала надо посмотреть, как выигрыш для этих, и для тех, чтобы этим не было хуже, этим стало лучше, и при этом чтобы ничего не сломалось, и т.д. Вот и все действия, вся работа.
Oracle никогда не скрывал, что наибольшие затраты по человеко-часам по развитию Java, и у Sun тоже, они не в области девелопмента, они в области QA.
— На текущий день, по твоим оценкам, не переходя на персоналии, насколько мощный в Java у нас QA, в оракловой Java, в OpenJDK? То есть часто ли там пропускают что-то серьезное, на твой взгляд? Или так сложно сказать?
Куксенко: Мне сложно сказать. Я стараюсь не лезть в эту область, потому что она слишком большая. У нас есть замечательные специалисты, думаю, они гораздо лучше ответят. У нас есть QA-архитекторы, которые знают больше о состоянии дел.
— В JDK 7 update 6 меняли substring(). Интересно: изменение, казалось бы, маленькое, но очень видимое. И последствия этого изменения: долго ли к вам прибегали кастомеры и били вас ногами за этот чейндж, или вы предварительно с ними работали? Очень интересно, как делается анализ для таких изменений. Условно говоря, Условно говоря, это же понятный трейд-офф.
Куксенко: Это даже не сколько трейд-офф, и сколько было понятно, что кастомеры будут прибегать… Во-первых, к нам они лично никогда не прибегают, мы практически не работаем с конкретными кастомерами. Я знаю, существуют некоторые кастомеры, которые бегают и кричат: «Мы не будем переходить на JDK 7 Update 6, потому что не знаем, что это за изменение, не хотим его проверять», и т.д, но здесь не то, что мы просто взяли и сделали это изменение с сабстрингом, с удалением поля Offset и так далее, это один из необходимых шагов, которые двигают нас к финальной цели – легкие стринги, преимущество которых и польза очевидны.
— Что это?
Куксенко: Сейчас строчка – это у нас объект и массив. Если мы их склеим вместе, мы получим такой стринг, который будет иметь все бенефиты локейшена, которые будут занимать меньше памяти, потому что хедеры там не нужны, а особенно это важно для коротких строчек, и прочее. Куча выигрышей, куча пользы, есть огромное количество академических экспериментов в этой области, наш любимый университет Линца что-то делал. То есть есть люди, которые говорят, что «Делать надо так, мы даже сделали пруф оф концепт и получили такие-то выигрыши». И понятно, что мы тоже движемся в эту сторону, просто мы не можем себе позволить делать пруф оф концепт, мы должны делать финальное решение, поэтому мы движемся, может быть, медленно. И было очевидно, что это изменение – важный необходимый шаг по дороге туда, к тому, как мы это видим. Но давайте делать шаги по частям. Этот шаг можно сделать сейчас не откладывая, и тогда потом вываливать на кастомеров и тестировать на кастомерах нам придется меньше чем сейчас.
О производительности Stream API
— Год назад вышла Java 8. Ты много рассказывал про Stream'ы, про Stream API, про Bulk Data Operations, которые являются частью всего этого проекта. Ты активно пользуешься этим всем в повседневной разработке? И второе. Те надежды, которые на него возложены были с точки зрения того, что он даст преимущество в частности на многопроцессорных машинах, то, что это еще один уровень абстракции, другой подход к программированию – насколько они оправдались, по твоему ощущению? Дают ли Stream'ы какое-то реальное увеличение производительности?
Куксенко: Если пишу код, не зафиксированный внешними требованиями, то всегда пишут под Java 8, всегда пишу с использованием Stream'ов, хотя уже использую JDK 9 для таких целей. Меня очень радует то, что, присутствуя на различных конференциях, я опрашиваю людей, и я заметил, что достаточно большое количество людей перешло на JDK 8. Stream'ы мне очень нравятся в том, что код получается гораздо более компактный, и прочее в плане понимания, восприятия. Все-таки программисты чаще читают код, чем пишут.
В плане перфоманса это известный вопрос. Как я говорил, отвечая на этот же вопрос год назад в Киеве, я считаю, что классические пользователи в своей статистической массе ни огромных приростов производительности, ни огромных замедлений от перехода на Stream API не заметят. Люди, которые специально целятся на это дело, они наверняка выжмут из этого достаточно много полезных вещей.
— А части ли случаи, когда Stream API проигрывает по перфомансу классическому (Collections) API?
Куксенко: Как правило, Stream API проигрывает по производительности классическому API просто потому что Stream API подразумевает под собой некоторый оверхед, некоторые действия, которые мы обязаны сделать для того чтобы сконструировать хороший Stream и начать с ним работать. Вопрос: что мы выиграем, сделав эти некоторые затраты? Без параллелизации с точки зрения перфоманса тут нечего выигрывать, за исключением более компактного и лучше читаемого кода. Вопрос параллелизации, об этом тоже много говорилось, и писались различные примеры, шаблоны, графики, когда лучше переходить.
Сейчас самая осторожная оценка, которая выше нашей внутренней оценки, и которая, в принципе, достаточно разумна, и ее предлагал Даг Ли: если количество параллелизуемой работы в общем случае превышает 100 миллисекунд (на самом деле, микросекунд — прим.авт. с подачи apangin), то, параллелизуя ее, можно получить выигрыш с вероятностью 99%. Если количество работы меньше 100 микросекунд, лучше не заморачиваться параллелизацией. По нашим замерам это 10 микросекунд, но там уже… Это безопасная граница.
— 100 – более консервативная оценка?
Куксенко: Да, и более чем достаточная. Я бы переходил на Stream API только по причине того, что код является компактным. Там существуют некоторые проблемы со стороны hotspot и JDK. Не то, что проблемы, а мы знаем, что есть тут и тут не очень хорошо, мы знаем, что это тут и тут надо улучшить, мы сейчас думаем, как нам это сделать.
Даг
— Ты вспомнил Дага Ли. Для меня было некоторым удивление, как построено взаимодействие работы с Дагом, потому что есть мнение, что Oracle даже больше, чем Sun, был совсем консервативной организацией даже с точки зрения OpenJDK, и не очень активно пускал внешних коммиттеров. В принципе, что при Oracle ситуация улучшилась, и все больше и больше появляется внешних коммиттеров, которые что-то контрибьютят в платформу, но с Дагом история совсем особенная, потому что, чуть поработав внутри, мне так посчастливилось, и посмотрев на то, как строится взаимодействие с Дагом, получается, что это вообще какой-то очень специальный человек, который специальным образом стоит по отношению к организации. И в этом смысле это феномен. Просто канкаренси – это одно из главных направлений, по которому развивается современный перфоманс, железо, наука и все это. Расскажи о том, как вы с Дагом взаимодействуете, и почему он на таких привилегированных условиях по отношению к другим?
Куксенко: Если мы возьмем какую-то конкретную область, то можно найти в этой области человека, который является признанным экспертом. Хорошо, если в этой области есть 100 экспертов, и мы можем десяток из них просто нанять, и они будут у нас делать эту область. Это полезно для нашего продукта, и для всей системы. Плохо, когда в этой области есть выдающиеся эксперты, потому что выдающемуся эксперту требуются выдающиеся условия, и в этом случае иногда, может быть, не удастся так корпоративно нанять и приказать сверху, как любят большие корпорации, делать что-то, а в этом случае с таким человеком приходится договариваться, потому что это приносит пользу всем, развитию продукта, если мы можем договориться с человеком снаружи о его контрибуции в эту конкретно область. Даг Ли – это выдающийся человек в той области, это эксперт, равного которому найти сложно, поэтому сложилась, не знаю, исторически или нет, такая схема коллаборации, что он сидит у себя в институте, делает вещи, изобретает, проверяет, делает их, и они попадают к нам в Java, потому что всем от этого польза. Мы развиваем наш продукт, и так далее.
— А кроме Дага существуют другие люди, которые с платформой работают в специальном режиме на специальных условиях?
Куксенко: Может быть, я не знаю.
— То есть, по крайней мере, в перфомансе таких вещей нет?
Куксенко: У нас есть Oracle Labs, и много вещей, связанных с High Performance, High Concurrency вещей приходит от них. Oracle Labs – это более академическая организация, поэтому это более академический мир, у них свои контакты, своя кухня, а к нам приходят готовые решения, которые мы просто воплощаем в жизнь.
— Перфоманс, он везде, по крайней мере в рантайме. Глянешь в GC – перфоманс, глянешь в коллекции – перфоманс, Stream'ы – перфоманс, VM – перфоманс, JIT – перфоманс...
Куксенко: А что значит перфоманс? Перфоманс – скорость исполнения некоего процесса. А время — оно везде. Отсюда и скорость исполнения любых процессов везде. Это мы уже уходим из computer science, приходим к Эйнштейну.
Команда
— У вас есть перфоманс команда в Java, наверное, правильно говорить Oracle Java SE Performance Team. Расскажи про команду, что там за люди, сколько их, и как у вас построена работа.
Куксенко: В команде меньше десятка человек. Чисто технически наша работа сейчас заключается в том, что мы берем различные фичи, различные подпроекты по разработке JDK, и занимаемся их производительностью, на двух уровнях. Первое: убедиться, что там нет серьезных косяков. Второе: если мы убедились, что косяков нет, и мы можем предложить какие-то улучшения, мы их предлагаем. Проект достаточно независимый, как правило, мы редко пересекаемся по работе.
— То есть один инженер – один проект?
Куксенко: Как правило, да.
— Можешь привести примеры таких проектов?
Куксенко: Проект Lambda, проект Jigsaw, Application Data Sharing. В String какие-то конкретные предложены улучшения по синхронизации. Перфоманс-улучшения для G1 Garbage Collector.
— Насколько актуальны внешние performance-контрибьюторы, кроме Дага (Дага, наверное, нельзя считать внешним)? Условно говоря, есть всякие concurrency-interest и прочие источники, где все время идет обсуждение. Насколько активно вы принимаете патчи от community, и что можно сказать о качестве таких патчей?
Куксенко: В этом смысле мы находимся в похожей ситуации: мы не принимаем патчи, мы их предлагаем. Есть владелец кода, например, ребята из Hotspot, и если у нас есть какое-то перфомансное улучшение, мы предлагаем им свою идею патча. Точно также какой-нибудь Вася Пупкин может прийти в OpenJDK mailing list и предложить изменение и улучшение, патч. И вопрос принятия или нет того или иного патча решают владельцы кода, в данном случае команда Hotspot или команда Class Libraries, и мы в этом смысле не принимаем решения, мы предлагаем. Но мы можем проверифицировать стороннее решение, можем обеспечить какие-то данные по замерам, но финальное слово всегда за владельцем кода, как бы мы с ним не спорили, потому что помимо перфоманса существуют требования к качеству кода, его функциональной правильности, в области секьюрити, и прочее.
— Все такие изменения проходят обязательные ревью…
Куксенко: Нам немножко проще, нас знают.
— То есть можно говорить о том, что авторитет важнее в этой области, чем принадлежность к конкретной команде, организации?
Куксенко: И даже больше, потому что, будь я сторонним разработчиком, то мог бы выбрать какую-то интересную вещь в Hotspot, начать ее ковырять, наковырять, получить каких-то приростов, прибежать и начать громко размахивать. Будучи в Oracle, я вынужден заниматься теми вещами, которые, может быть, не приносят мне такой большой славы, но нам их надо сделать, надо дорыть, докопать, тут доделать, тут проверить, и приходится заниматься этим.
— Насколько большой процент возни неприятной и процент интересных исследований по работе, с которыми приходится иметь дело? Часто встречается что-то удивительное? Часто ли тебе приходится натыкаться на такие места в Java, в которых нога перфоманс-инженера не ступала?
Куксенко: Каждый день.
— Как так выходит? У людей снаружи, когда я сам был таким человеком, казалось, что люди, которые делают Java – это некоторые небожители, у которых любая строчка строго обоснована, все оптимизировано по самое не балуй, и соваться туда простым смертным вообще не стоит. Видимо, это не совсем так?
Куксенко: Это не совсем так. Производительность очень часто, если мы не занимаемся каким-нибудь Highload, – это не функциональное требование. Сначала продукт должен работать правильно, а потом он должен работать быстро, и то, если это нужно. Поэтому наличие огромного количества мест, которыми a) никто не занимался, потому что не дошли руки посмотреть, b) потому что туда не надо смотреть, и никого это не волнует, c) потому что раньше это никого не волновало, а сейчас это стало достаточно большой проблемой. Но не будем забывать, что основные усилия должны делаться на правильность. У нас огромное количество кода, где не ступала нога перфоманс инженеров, но все строчки в котором обоснованы с точки зрения корректности. Не будем забывать, что сейчас в команде, которая занимается Java SE перфомансом, меньше 10 человек.
— А насколько, по ощущению, этого достаточно?
Куксенко: При наличии рядом высококвалифицированных команд, которые разрабатывают основной код, этого более чем достаточно. Поскольку наши ключевые инженеры, которые разрабатывают и компилятор, и Garbage Collector и Class Libraries, высоко квалифицированы, мы им помогаем. Не в том смысле, что мы их куда-то двигаем, толкаем, пинаем, а мы выступаем как вспомогательное средство. Если бы у нас по квалификации команда разработчиков была достаточно средняя с точки зрения производительности, тогда мы бы заняли более активную позицию. Сейчас в этом просто нет необходимости, потому что много вещей делается без нашего участия.
— Насколько мы можем говорить о том, что Oracle удалось сейчас в Java собрать экспертов в перфомансе, в VM? Насколько это люди мирового уровня, или люди мирового уровня работают где-то в другом месте, по твоим оценкам?
Куксенко: В этом смысле практика – это критерий истины. Если бы эксперты мирового уровня работали в каком-то другом месте, думаю, мы бы сейчас разговаривали о каком-то продукте.
О других технологиях
— А насколько то, что сейчас происходит, условно говоря, в Java-платформе с точки зрения перфоманса и Rocket Science, с точки зрения того, насколько крутые штуки там делаются, можно ли крутость этих штук сравнить с крутостью вещей, которые делают другие ребята, скажем, Google V8, или аналогичные, .NET, например?
Куксенко: Ничего не могу сказать про .NET. Я его даже никогда не видел. Google V8 видел – вполне себе нормальная штука.
— Не секрет, что многие JVM-инженеры считают Dalvik поделкой. Не знаю почему, но с кем ни поговоришь – все плюются, что как VM она так себе. Как так вышло, что вроде все пользуются Android’ом, а VM-инженеры предъявляют ее машине претензии?
Куксенко: Это работа инженеров – предъявлять претензии. Если бы инженеры не предъявляли претензии к этому продукту, я бы подумал, что либо с инженерами, либо с продуктами что-то не так. У меня есть масса претензий к Java, но я их оставлю при себе.
— Может быть, одну-две для наших зрителей, слушателей, из тех, что можно вынести, из тех, которые ты бы хотел улучшить или что-то сделать.
Куксенко: Обратная совместимость. Я считаю, что надо выкинуть все нафиг и написать все с нуля Но это не подход.
— Он любимый, мне кажется, не только в перфомансе, а везде.
Куксенко: Ошибки дизайна базового API потихоньку накапливаются с годами, и это становится неудобно. Даже не касаясь того, как работает сам язык и все системы, я бы выкинул весь базовый API, и задизайнил новый, более компактный и правильный с учетом ошибок. Но понимаю, что эту работу сделать не то, что нереально, ее невозможно сделать. Никто не в состоянии задизайнить этот API from scratch, и поэтому остается потихонечку добавлять новое, а старое потихонечку депрекейтить. Так и живем.
О разных JVM
— Работа по созданию рантайма, своей виртуальной машины… Есть мнение, что создать виртуальную машину – довольно плевое дело, какую-то самую простую без оптимизацией и так далее.
Куксенко: Да и с оптимизациями это несложно. Берешь и делаешь.
— А что ж там тогда такого годами и тысячами человеколет люди в Oracle делают?
Куксенко: Почему тысячами человеко-лет?
— А сколько? 20 лет уже существует VM в том или ином виде, те или иные. А сколько сейчас вообще VM-ов в Oracle JDK? Там же есть разные варианты.
Куксенко: У нас есть Embedded VM, но я плохо знаю этот мир embedded, поэтому ничего не скажу, что там у нас сейчас происходит.
— Это не Hotspot?
Куксенко: Это Hotspot, но это Embedded Hotspot, это отдельные ребята сидят и его разрабатывают.
— А там упор на footprint или что-то еще?
Куксенко: Там упор на то, чтобы хорошо работать на этих железках.
— Там ARM, скорее всего?
Куксенко: Там ARM и VM под ARM. И все, у нас один Hotspot. У нас есть еще JRockit, есть его поддержка для кастомеров еще осуществляется какое-то время. Его поддерживают совершенно разные люди, потому что команда, которая занимается поддержкой, она достаточно распределенная. Если были или, может, до сих пор есть люди в Санкт-Петербурге, которые над этим работают, но JRockit так и остался на уровне Java 6.
— То есть вы не занимаетесь JRockit?
Куксенко: Не занимаемся.
— История начала 2010 годов – покупка компании Sun компанией Oracle, и разговоры про слияние JRockit и Hotspot, ты что-нибудь знаешь или помнишь, может быть, о том, как это решение принималось, почему оно было принято именно такое? Какие тут критерии могут быть?
Куксенко: Есть компания Oracle, у Oracle есть две виртуальные машины, обе хорошие. Очевидно, надо сливать. Принимаем решение – сливаем.
— Но ведь приняли решение оставить Hotspot, интегрировать туда лучшие фичи и лучшие решения из JRockit.
Куксенко: Да.
— Почему не наоборот? Понятно, что, скорее всего, нужно фичи из одного интегрировать в другую, потому что слияние другого типа, наверное, невозможно с учетом сложности обоих программ.
Куксенко: Просто оно и невозможно, да и это получилось нечто страшное и ужасное.
— Как можно провести анализ, какое из решений выбрать в данном случае? Я даже не представляю себе, как это.
Куксенко: Смотря какие требования. Я не очень хорошо помню и не очень знаю, какие требования ставились, но здесь возникает вопрос, что хотят наши кастомеры. Это самый ключевой вопрос. Если кастомеры скажут, что «Мы привыкли к Hotspot и мы никогда не пойдем на JRockit», и это будет 70-80%, то все, дальнейшая дискуссия остановлена. Если другие кастомеры прибегут и скажут: «А мы хотим JRockit, но мы не хотим на Hotspot», то будет обратная ситуация – обратная ситуация. Дальше возникает вопрос: «А что вам так нравится в том же JRockit или в Hotspot, чтобы вы хотели оставить?». А после этого, когда уже все кастомерные фидбеки собраны, результаты поняты, и дальше смотрим по фичам, сколько будет стоить добавить фич туда, сколько будет добавить фич туда, общий цикл. Думаю, это просто общее решение, что наработки по Hotspot, в том числе по тому же циклу QA (00:48:34), они были гораздо больше, поэтому было решено фичи из JRockit добавлять в Hotspot, а не наоборот.
— На слуху Metaspace, Flight Recorder и Mission Control. А что еще кроме этих вещей было перетащено, перенято из JRockit в Hotspot?
Куксенко: Насколько знаю, идут работы, не знаю их статус, завершились или нет, по тому, что механизмы синхронизации станут похожими на те, к что сделаны на JRockit. Не будет 100% переписывания, но некоторые идеи…
— Основные вещи уже сделаны?
Куксенко: Конечно. Они были сделаны еще тогда, когда эти VM жили в разных компаниях.
— Бытует мнение, что сложность существующих JIT-компиляторов, в особенности C2-комплиятора, она такова, что уже препятствует его дальнейшему развитию? И все проекты, связанные с переписыванием JIT на что-то новое.
Куксенко: Существует такая точка зрения, но существует и более мягкая, которая заключается в том, что не JIT невозможно развивать, а существует достаточно высокий порог входа в JIT-разработку имеющегося того же компилятора C2. То есть человек, желающий сделать что-то в компиляторе, он тратит много времени на начальное вхождение, прежде чем начать выдавать полезные изменения и улучшения. Во-первых, я не сказал бы, что это мешает дальнейшему развитию, компилятор развивается. Вопрос высокого порога входа тоже дискутируем – является ли это плюсом или минусом. Может быть, наоборот, это хороший критерий отсева для людей.
— Чтобы всякие ламеры не лезли?
Куксенко: Есть, может быть, дискуссии. Это политическая или организационная дискуссия – подсчет человеко-часов, потраченных на развитие. Мне бы не хотелось в это углубляться.
— То есть больших инженерных проблем нет?
Куксенко: Есть инженерные вопросы, может быть, сделать так, может быть, сделать сяк. Банальная третьесторонняя зависимость от C и C++ компиляторов начинает раздражать.
— И в каком направлении все это развивается? Писать на Java?
Куксенко: Например, это проект Graal – бери, скачивай, играйся, он работает.
— Наверное, тяжело говорить, то есть в девятке его понятно, что не будет.
Куксенко: Нет. Это третьесторонний проект под одним швейцарским университетом, в том числе с участием Oracle. Он активно используется людьми для прототипирования, для работ в области GPU акселерации, и так далее. То есть он занимает свою достаточно большую нишу в области исследований, и что выйдет – посмотрим дальше. По крайней мере, свою нишу, как хороший академический тул для того чтобы делать исследования в области, именно базируясь на Hotspot, он уже давно занял.
— И аналогичный проект в области GC. Есть Shenandoah, который RedHat в свое время предложил. Ты что-нибудь знаешь по тому, что там сейчас происходит?
Куксенко: К сожалению, не знаю никаких деталей.
— Ты видел? Насколько это интересно?
Куксенко: Я знаю, что RedHat будет адаптировать Shenandoah под Hotspot, и какие-то работы в этом ведутся.
— Еще есть история, что лет пять назад очень большие надежды возлагались на Garbage First Collector, но если поговорить с людьми на конференциях, то в продакшене почти у всех CMS Collector. Так ли это по твоему ощущению, с кем ты общаешься, что тебе говорят, и если это так, то почему это происходит?
Куксенко: Думаю, в первую очередь, от лени. Идеальный продукт должен иметь одну кнопку – «Вкл»
— Удалось ли добиться Garbage First инженерам, людям, которые его разрабатывают, того, чего они хотели?
Куксенко: Мне сложно сказать, я не работаю с Garbage First, не знаю, что сейчас происходит в этой области. У нас на приближающейся осенью Java One заанонсированы доклады людей в том числе людей из нашей перфомансной команды о том, что сейчас происходит реально в области Garbage First. Давайте дождемся Java One, и посмотрим объявленные результаты. Я, конечно, могу сейчас прийти, написать письмо человеку и спросить: «А что ты собираешься рассказывать осенью, что там произошло?», но так прямо сейчас в дискуссии я не знаю этого ответа.
Как любые вещи, Garbage First необходимо было дотюнить, доделать какие-то работы. Эти работы велись, они сделаны, какие-то результаты были достигнуты. Очевидно, что при правильном процессе Garbage First рано или поздно станет нормально себя вести. Думаю, что это будет достаточно рано.
Почему люди не хотят уходить? Во-первых, потому что под CMS-ные тюнинги есть огромное количество готовых рекомендаций, как это надо делать. Тебе не надо думать, ты открываешь, читаешь книжку и по алгоритму побежал: «Так, если так, то сяк, если так – то сяк». Активных и больших описаний по тому, как и где какие ручки подкручивать под Garbage First в природе еще не существует, и они только сейчас создаются. Это первая причина, почему люди не переходят под Garbage First, потому что там я могу покрутить, а тут я еще не знаю – страшно переходить на что-то новое. Вторая причина – многие еще ленятся переходить с Java 7 на Java 8, а Java 7…
— Почти уже end of life… Было анонсировано, что вроде в апреле будет последний публичный апдейт.
Куксенко: Где-то так. И третья причина – лень.
— Да. Может, с нее стоило начать.
Куксенко: Лень у программистов всегда бывает двух видов: это просто нативная лень, которая естественным образом присутствует, и вторая по принципу «Солнце восходит на Востоке. Работает? Работает. Не трогай».
— С точки зрения подхода к разработке существуют, условно говоря, разные императивные вещи, когда мы говорим, как мы хотим что-то сделать, а существуют некие декларативные, когда мы говорим, что хотим сделать. Какие были параметры в старых GC? Размер такого региона, сякого региона, то есть это был ответ на вопрос, как мы хотим сделать. А в Garbage First появились способы задекларировать то, что мы хотим. Например, размер паузы. То есть, мы уже работаем в неких целевых пользовательских показателях. Насколько это интересное направление для развития?
Куксенко: Всем очевидно, мы сами знаем, как должен выглядеть идеальный продукт. Мы даже у себя на слайдовой презентации показывали, что идеальный продукт должен иметь одну кнопку – «Вкл». Ты его включил, и он работает. Он не должен иметь 10 тыс. рычажков, ручек, кнопочек, с помощью которого ты начинаешь его крутить. И здесь даже не вопрос парадигмы функциональной или императивной, это вопрос того, чтобы иметь под конец, рано или поздно, одну большую кнопку «Вкл». Это не то, что цель, мы ее достигнем и уйдем все на пенсию, и так далее, возможно, эта цель недостижима, но к ней полезно было бы стремиться. И чем меньше параметров, чем меньше пространства для игры, тем лучше всем. Потому что если мы сейчас возьмем опции Java виртуальной машины Hotspot, управляют работой Garbage Collector, и захотим просто для своего понимания, не основываясь на знании нашего приложения, а просто давайте переберем их хотя бы в каком-то диапазоне – это займет огромное количество времени, просто поиграться – туда, сюда, туда, сюда, а что меняется в этих сочетаниях.
— Это история про эвристику. Я понял, что ты хочешь сказать, и я тогда чуть в сторону. Есть некий продукт – Hotspot, GC, Runtime, стул, у него есть некие инженерные характеристики – то, что он сделан из дерева, весит столько-то, прибит гвоздями и так далее, а есть некие потребительские – то, что он такого-то цвета, разваливается или не разваливается, занозы у него тебе в задницу цепляются, не цепляются, и так далее. Такое ощущение, что параметры GC в старом виде – это некие инженерные характеристики – все эти килобайты и килобиты, а эти миллисекунды – это воспринимаемые характеристики.
Куксенко: Да. Приведу другую, что едем мы на автомобиле старого производства, тут мы давим кнопку на газ, здесь мы переключаем передачи, здесь мы еще определяем подсос у бензина, потому что плохо там тянется, здесь еще какую-нибудь ручку надо подкрутить, я уж плохо знаю, или мы садимся в другую машину, включаем ключ зажигания, немножко жмем на газ для начала, а потом включаем круиз-контроль и говорим: «Хочу 60 км/час», и едем. Что удобнее?
— И уже как оно справляется – это уже его собственное дело?
Куксенко: Это совершенно не наша забота. Если я выставил свои требования 60 км/час, и оно мне дает 60 км/час, зачем мне выяснять, что там происходит дальше? Очевидно, что для конечного пользователя такой продукт будет быстрее. Да, конечно, может быть, для ряда автомехаников, которые раньше сидели у себя в гаражах и регулировали там упреждение, зажигание или что-нибудь еще, это означает потерю работы, в том числе для CMS-тюнеров это тоже означает потерю работы, но, по-моему, в конечном итоге, для всех это было бы удобнее.
— Если мы двигаемся в сторону уменьшения разных рычажков, и хотим прийти к тому, чтобы пользователь...
Куксенко: Мы не движемся в сторону уменьшения. Мы говорим, что «Эти рычажки остаются на панели, а те под капотом. Открывай капот и крути, пожалуйста».
— То есть возможность крутить все равно остается?
Куксенко: Конечно.
— Просто, с одной стороны, есть движение в сторону уменьшения количества ручек, а с другой стороны, то, чем занимаешься ты с точки зрения своего евангелизма, который ты ведешь на конференциях, «Джугах» и даже сейчас, и с точки зрения того, что мы делаем, как организаторы конференции – мы пытаемся показать какие-то внутренности. И насколько вообще нужно показывать внутренности, учитывая, что у людей все меньше и меньше, даже оставаясь в той же терминологии, рычагов влияния на то, как их Runtime себя ведет?
Куксенко: Я бы, во-первых, не стал утверждать, что людям остается меньше рычагов влияния на то, как Runtime себя ведет, и как это все работает.
Я бы сказал о другом. Дело в том, что если есть требования к производительности Runtime, то мы можем сесть, понять, как он себя ведет, построить перфомансную модель, понять, что можно улучшить, и выдать результат. А текущее состояние, когда у нас есть 100 тыс. ручек, оно приводит к тому, что люди приходят: «У нас нет, мы не хотим разбираться или у нас нет времени разбираться, как это все работает, мы лучше ручки покрутим, посмотрим, что произойдет». Это вполне себе валидный способ действий в определенных случаях, он отнюдь не всегда работает, вплоть до того, что появляется очередная прослойка людей, которые не понимают, как это работает все в деталях, а они умеют поворачивать ручечки. Они знают, что есть ручечки, которые можно крутить, и ходят, их крутят. Это усложняет всю цепочку работы. Да, конечно, перфоманс-инженеров в таком виде, как у нас востребованы – это не очень часто требуемая специальность.
Выступление на JPoint
— Попрошу тебя рассказать немножко о своем докладе, который у тебя будет на JPoint. Он вроде называется так же, как и на Джокере. Будет ли этот тот же доклад, или не тот же, что ты в нем переделаешь? Что за доклад, и чем они будут отличаться?
Куксенко: Доклад будет по-прежнему посвящен аспекту анализа производительности, производительных проблем на этот раз с помощью железа. Анализ, и то, как посмотреть то, что происходит в реальном железе в процессе работы нашей программы, как и что можно улучшить именно для производительности программы.
Ядро и основной доклад будут практически полностью совпадать с тем, что делалось на «Джокере», но я уже давно понял, что доклады нельзя рассказывать один раз, потому что всякий раз, когда ты рассказываешь второй, третий раз, ты исправляешь ошибки, добавляешь что-то более интересное, и т.д. То есть доклад становится более полезным, в нем появляется новая, убирается ненужная информация, и он для тебя становится интересен самому себе наконец-то. То есть, сделав доклад два-три раза, можно довести его до уже более хорошего состояния, когда его можно положить на полочку, и уже не менять. Как правило, доклад, прочитанных один раз, он еще не находится в таком состоянии, и там всегда есть что улучшить.
— Те твои фанаты, которые слушали тебя в Питере, и которые через три недели пойдут тебя слушать в Москву, они для себя что-нибудь новое узнают из него?
Куксенко: Надеюсь, да. По крайней мере, я сделаю меньше воды. У меня доклад, который я читал в Питере, на 40% состоял из воды. Думаю, что надо оставить процентов пять, добавить больше примеров, и немножко более ясное объяснение того, что там происходит, чем это было сделано.
— Дай напоследок какой-нибудь перфомансный совет нашим зрителям.
Куксенко: Перфомансный совет всегда только один может быть, и я всегда говорю его на всех конференциях: если вы хотите заниматься перфомансом, вы должны представлять и знать, как все это работает, все и везде.
P.S.:
Доклады Сергея, о которых идет речь в статье, заботливо собраны нами тут.
Анонс его выступления на JPoint — тут.
