Без слайдов: Сергей Куксенко
Сегодня у меня для вас сюрприз. Нет, это не реклама очередной нашей конференции и даже не обзор чужой. Сегодня я представлю вам нечто совсем новое.Представьте, что вы пришли на встречу JUG.ru или CodeFreeze, или например на джавовскую конференцию, на которой только что выступил Сергей Куксенко, разработчик из Java Performance Team. И вот, по какой-то причине, все остальные слушатели разбежались, а вы с Сергеем остались один на один. И внезапно, он никуда не торопится, и у него есть свободный час, чтобы ответить на ваши вопросы, коих накопилось великое множество…
Встречайте: сегодня у нас абсолютный эксклюзив — большое интервью с Сергеем Куксенко! Из интервью вы узнаете:
как устроена команда Java Performance в каких направлениях Java сейчас ведется активная performance-работа зачем нужен хардкор на джугах и конференциях что должен знать performance-инженер что такое хайлоад, и где проходит граница что прямо сейчас происходит с джавовыми строками в какую сторону эволюционируют тюнинг рантаймов [embedded content]
— Сергей, ты у нас часто выступаешь с докладами, и твои доклады с каждым разом становятся все сложнее и сложнее с точки зрения материала, который ты рассказываешь, и все глубже и глубже уходят внутрь всяких железячных вещей. Когда ты рассказываешь, ты смотришь в глаза людям — ты видишь там понимание какое-то, или по мере углубления понимание теряется?
Куксенко: Это самый ключевой фидбек, который я вообще пытаюсь поймать на своих докладах. Дело в том, что когда я вижу ответ аудитории, я чувствую некоторое удовольствие от того, что мой доклад прошел не впустую, и в среднем, если я вижу хотя бы с десяток активных слушателей, я считаю, что доклад удался. Такое происходит достаточно часто.
— То есть у тебя есть некий процент, за который ты пытаешься держаться?
Куксенко: Да, я доношу информацию, мне нужно, чтобы она до кого-нибудь дошла, чтобы я делал презентацию не просто для себя.
— А как сделать этот выбор, когда в аудитории у тебя люди с разным бекграундом, у них разный уровень понимания? Ты заранее говоришь, что «Я буду рассказывать фиксированную сложность», или ты сложность подстраиваешь?
Куксенко: Я заранее объявляю, что будет достаточно сложный доклад, и если у меня есть информация об аудитории, и я знаю, что не будет достаточно заинтересованных людей, то я в таком случае не провожу доклад, не участвую в таких слабых конференциях.
— Как ты узнаешь информацию об аудитории?
Куксенко: Как правило, постфактум.
— Как организатор конференции, что я могу тебе про аудиторию рассказать такого, что может повлиять на твой доклад?
Куксенко: Я не знаю ответа на этот вопрос, честно скажу. Возможно, ничего, может быть, что-то можно рассказать. Как правило, я по визитам на конференцию оцениваю уровень аудитории и решаю для себя в голове, поеду ли я сюда еще один раз, или нет.
— На Joker например, последний раз?
Куксенко: По-моему, тут очевидно, что поскольку и на Joker’е, и на JPoint я выступаю каждый год, значит все-таки фидбек есть, и эта подхватывающая обратная связь, она срабатывает, просто по практике.
— Ты в России выступаешь уже года четыре, не меньше. Ты года с 2012 начал?
Куксенко: Где-то с 2011.
— Ты видишь, что аудитория растет? Не по количеству, а по степени понимания того, о чем ты рассказываешь?
Куксенко: Честно говоря, нет. Я вижу немножко обратную связь — я вижу, что аудитория устала, я вижу, что люди устают от сложных докладов, которые мы докладываем из года в год. Ну, по крайней мере, мне так кажется. Я вижу, что достаточно интересные люди, которых я запоминаю на различных конференций, они уходят из этой области. То ли карьерный рост у них начинается, то ли они переключаются в менеджеры, то ли еще что-то. И я пока не вижу серьезной замены этим вещам.
Возможно, срабатывал эффект первых докладов, когда у людей был некоторый голод по техническим вещам, они задавали массу вопросов. Сейчас я вижу снижение такого интереса со стороны аудитории к сложным техническим докладам.
— Это интересно, потому что мне очень нравится, что вы с Лешей (имется в виду Алексей Шипилёв — прим. авт) не занимаетесь самокопированием. В 2011–2012 году была тема перфоманса, а потом она разошлась немного.
Куксенко: Мы все рассказали. Зачем повторяться? С 2012 года ничего не поменялось в этой области.
— Насколько активно развивается перфоманс-наука сейчас, и, может, перфоманс в Java, в частности?
Куксенко: Я ничего не скажу за перфоманс-науку. Я не знаю, что происходит в науке. Наверное, что-то развивается. Перфоманс — это не столько наука, сколько прикладная инженерия, когда у нас есть что-то реальное, и это реальное надо впихнуть в какие-то временные рамки в рамках requirement и т.д. В Java работаем, делаются изменения в различных областях. Нет глобального плана: «К 2020 году наступит вселенское счастье, и мы будем выполнять любую операцию за одну пикосекунду». У нас есть продукт, мы находим какие-то места, мы подкручиваем его там, здесь, изобретаются новые вещи, идет адаптация под новое железо, и т.д., то есть обычный процесс.
— Насколько быстро меняется железо для того чтобы люди, которые занимаются перфомансом, могли использовать новые железные фишки?
Куксенко: Intel каждые два года выкатывает новую микроархитектуру с достаточно интересными фишками, но если начинать смотреть более-менее серьезные исследования, там выясняется, что вышла какая-то супер-пупер новая фича, новая архитектура, и сколько мы получили среднестатистического природа производительности в смысле средней температуры по всей больнице? Ну, плюс 6%. Появляются периодически новые фичи Software. Часть Software за этим не успевает. Она пытается догонять, особенно на уровне Java, где мы должны представлять более-менее архитектурно независимые решения, мы еще должны за этим гнаться.
— Известная проблематика — векторизация и векторные инструкции, которые существуют уже очень много лет в современных процессорах, и часто виртуальную машину 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-архитектуры. Насколько часто ты в повседневной работе имеешь дело с армами какого-либо вида, и что ты можешь сказать, с ними есть какие-то отличия?
Куксенко: В повседневной работе я имел дело с армами ноль раз. Я один раз только сделал свои эксперименты на армах. Когда я делал одну из своих презентаций, мне стало любопытно сделать параллельный замер на армах. Тогда я сделал эти замеры, и просто сравнил это с интеловскими архитектурами. Поэтому, поскольку я реально с армами не работаю, говорить мне пока об этом нечего — нет базиса, хотя платформа достаточно перспективна и достаточно агрессивно вытесняющая Intel из различных ниш.
— По ощущениям она развивается гораздо интереснее, потому что то, о чем ты говорил про 6% роста — такое ощущение, что Intel немножко стагнировал. Ощущение складывается, что перфоманс не растет. Энергоэффективность, возможно, растет, что-то другое типа шифрования появляется, но это, такое ощущение, что рост вширь. Лэптоп пятилетней давности оказывается с точки зрения перфоманса актуальным.
Куксенко: С точки зрения производительности, которая используется конечным пользователем, он оказывается точно таким же. Как у него пять лет назад ты мог смотреть свои киношки на Youtube, так и сейчас ты смотришь свои киношки на Youtube, не видишь никакой разницы. Как пять лет назад ты ходил в Twitter и писал какие-то почты, так и сейчас. Ты не замечаешь разницы. Дело в том, что базовые платформы уже давно достигли требуемой конечным пользователем производительности. Конечно, начинается всякое 3D, Blu-ray, супервысокая четкость изображения, но это уже отдельная область, не в области производительности компьютеров. Но реально, спасибо моему коллеге Леше Шепелеву, он на днях произвел оценки ретроспективы индустрии у себя в Twitter. Он написал, что он померил некий бенчмарк, score которого он хорошо помнит еще по нашей работе в Intel 10-летней давности. И он отмечает, что за эти 10 лет этот бенчмарк стал быстрее в 50 раз на его лэптопе, чем тогда 10 лет назад на серверной машине. Я думаю, прирост производительности в 50 раз за 10 лет — вполне себе нормальный прогресс.
— То есть, на самом деле, развитие есть? Насколько это показательно? Ты помнишь пример что, что это за бенчмарк?
Куксенко: Я хорошо помню его, но думаю, что мы не будем его обсуждать. Я думаю, что когда ты будешь брать интервью у Алексея Шипилёва, ты лучше спросишь у него о релевантности этого бенчмарка, потому что он написал замену для этого бенчмарка.
Стринги
— Давай поговорим про String. Не секрет, что там сейчас происходят разные исследования, связанные с тем, как там можно более компактно записывать. Не секрет, что в последние годы этот класс начинает меняться. Замена substring (), и то, что было в JDK 7u6, и т.д. Насколько стремно, не стремно менять базовый класс платформы? Насколько работа с этим классом отличается от работы с каким-нибудь другим, насколько сложнее какие-то чейнджи туда принимаются? Потому что очень видимая область, и довольно удивительно, что сейчас там происходит активная работа.
Куксенко: Здесь же не вопрос: «А давайте мы придумаем какой-нибудь чейндж, а дальше смотреть», а здесь вопрос выигрышей, которые мы с этого получаем. А поскольку, если у нас есть класс, который, мы знаем, что занимает 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 API, про Bulk Data Operations, которые являются частью всего этого проекта. Ты активно пользуешься этим всем в повседневной разработке? И второе. Те надежды, которые на него возложены были с точки зрения того, что он даст преимущество в частности на многопроцессорных машинах, то, что это еще один уровень абстракции, другой подход к программированию — насколько они оправдались, по твоему ощущению? Дают ли стримы какое-то реальное увеличение производительности?
Куксенко: Если пишу код, не зафиксированный внешними требованиями, то всегда пишут под Java 8, всегда пишу с использованием стримов, хотя уже использую JDK 9 для таких целей. Меня очень радует то, что, присутствуя на различных конференциях, я опрашиваю людей, и я заметил, что достаточно большое количество людей перешло на JDK 8. Стримы мне очень нравятся в том, что код получается гораздо более компактный, и прочее в плане понимания, восприятия. Все-таки программисты чаще читают код, чем пишут.
В плане перфоманса это известный вопрос. Как я говорил, отвечая на этот же вопрос год назад в Киеве, я считаю, что классические пользователи в своей статистической массе ни огромных приростов производительности, ни огромных замедлений от перехода на Stream API не заметят. Люди, которые специально целятся на это дело, они наверняка выжмут из этого достаточно много полезных вещей.
— А части ли случаи, когда Stream API проигрывает по перфомансу классическому (Collections) API?
Куксенко: Как правило, Stream API проигрывает по производительности классическому API просто потому что Stream API подразумевает под собой некоторый оверхед, некоторые действия, которые мы обязаны сделать для того чтобы сконструировать хороший стрим и начать с ним работать. Вопрос: что мы выиграем, сделав эти некоторые затраты? Без параллелизации с точки зрения перфоманса тут нечего выигрывать, за исключением более компактного и лучше читаемого кода. Вопрос параллелизации, об этом тоже много говорилось, и писались различные примеры, шаблоны, графики, когда лучше переходить.
Сейчас самая осторожная оценка, которая выше нашей внутренней оценки, и которая, в принципе, достаточно разумна, и ее предлагал Даг Ли: если количество параллелизуемой работы в общем случае превышает 100 миллисекунд, то, параллелизуя ее, можно получить выигрыш с вероятностью 99%. Если количество работы меньше 100 миллисекунд, лучше не заморачиваться параллелизацией. По нашим замерам это 10 миллисекунд, но там уже… Это безопасная граница.
— 100 — более консервативная оценка?
Куксенко: Да, и более чем достаточная. Я бы переходил на Stream API только по причине того, что код является компактным. Там существуют некоторые проблемы со стороны hotspot и JDK. Не то, что проблемы, а мы знаем, что есть тут и тут не очень хорошо, мы знаем, что это тут и тут надо улучшить, мы сейчас думаем, как нам это сделать.
Даг
— Ты вспомнил Дага Ли. Для меня было некоторым удивление, как построено взаимодействие работы с Дагом, потому что есть мнение, что Oracle даже больше, чем Sun, был совсем консервативной организацией даже с точки зрения OpenJDK, и не очень активно пускал внешних коммиттеров. В принципе, что при Oracle ситуация улучшилась, и все больше и больше появляется внешних коммиттеров, которые что-то контрибьютят в платформу, но с Дагом история совсем особенная, потому что, чуть поработав внутри, мне так посчастливилось, и посмотрев на то, как строится взаимодействие с Дагом, получается, что это вообще какой-то очень специальный человек, который специальным образом стоит по отношению к организации. И в этом смысле это феномен. Просто канкаренси — это одно из главных направлений, по которому развивается современный перфоманс, железо, наука и все это. Расскажи о том, как вы с Дагом взаимодействуете, и почему он на таких привилегированных условиях по отношению к другим?
Куксенко: Если мы возьмем какую-то конкретную область, то можно найти в этой области человека, который является признанным экспертом. Хорошо, если в этой области есть 100 экспертов, и мы можем десяток из них просто нанять, и они будут у нас делать эту область. Это полезно для нашего продукта, и для всей системы. Плохо, когда в этой области есть выдающиеся эксперты, потому что выдающемуся эксперту требуются выдающиеся условия, и в этом случае иногда, может быть, не удастся так корпоративно нанять и приказать сверху, как любят большие корпорации, делать что-то, а в этом случае с таким человеком приходится договариваться, потому что это приносит пользу всем, развитию продукта, если мы можем договориться с человеком снаружи о его контрибуции в эту конкретно область. Даг Ли — это выдающийся человек в той области, это эксперт, равного которому найти сложно, поэтому сложилась, не знаю, исторически или нет, такая схема коллаборации, что он сидит у себя в институте, делает вещи, изобретает, проверяет, делает их, и они попадают к нам в Java, потому что всем от этого польза. Мы развиваем наш продукт, и так далее.
— А кроме Дага существуют другие люди, которые с платформой работают в специальном режиме на специальных условиях?
Куксенко: Может быть, я не знаю.
— То есть, по крайней мере, в перфомансе таких вещей нет?
Куксенко: У нас есть Oracle Labs, и много вещей, связанных с High Performance, High Concurrency вещей приходит от них. Oracle Labs — это более академическая организация, поэтому это более академический мир, у них свои контакты, своя кухня, а к нам приходят готовые решения, которые мы просто воплощаем в жизнь.
— Перфоманс, он везде, по крайней мере в рантайме. Глянешь в GC — перфоманс, глянешь в коллекции — перфоманс, стримы — перфоманс, 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 поделкой. Не знаю почему, но с кем ни пого
