Comments 33
сергей куксенко? первый раз слышу. чем знаменит?
Вспомнилось :).
это говорит исключительно о вашем невежестве, и больше ни о чем.
Лихо вы определили невежественность. Это так же может говорить о том, что не все читатетели хабра заядлые джависты и посещают все выступления Сергея. Это конечно маловероятно, но может быть на хабре даже есть люди, которые не пишут на джаве вообще (да, я знаю, что за такие мысли надо сжигать, каюсь).
Автор этого комментария даже не удосужился погуглить. О чем вы вообще говорите? ;)
Часто в подобных статьях вначале вставляют небольшой абзац, кратко поясняющий что за человек, чтобы читателю было понятней. Это также экономит время кучу людей и не заставляет их думать «ага, этот Сергей наверное суперзвезда, раз все о нём знают, а я валенок». Можно под спойлер убрать, чтобы не нарушало общую композицию текста.
Вы абсолютно верно уловили, почему этого абзаца в интервью нет и не будет :) Это что-то вроде системы «свой-чужой», да.
Хабр это отраслевой сайт, общеотраслевая знаменитость Сергея, при всем, уважении, не очевидна.
Ваш снобизм не уместен — в моей области также есть суперзвезды, однако, почему то меня не задевает что они не всем известны.
Ваш снобизм не уместен — в моей области также есть суперзвезды, однако, почему то меня не задевает что они не всем известны.
Косность ваша была бы достойна похвал в былые времена
Таки пост в Хабе Java, а в русскоязычном Java-сообществе Сергей фигура известная. Вон хотя бы на Ютюбе гляньте, сколько у него презентаций. Если вы интересуетесь Java, но ни разу не смотрели презентации Сергея, обязательно обратите на них внимание: наверняка узнаете что-то новое.
Фоторяд — огонь! :)
Замечательное интервью!
Замечательное интервью!
Если вы так каждый доклад предстоящего JPoint'а отрекламируете, мне придётся разорваться на четыре части, чтобы на всех побывать.
ее предлагал Даг Ли: если количество параллелизуемой работы в общем случае превышает 100 миллисекунд
А я вот тут наткнулся на то, что Даг Ли писал про 100 микросекунд.
Хотя оценка, данная Сергеем, мне кажется более реалистичной.
100 микросекунд вообще кажется приветом из прошлого века, если честно :)
бррр. Я фигню написал. Я хочу спросить следующее: тебе не кажется, что одна десятая секунды — это привет из прошлого века? А одна десятитысячная — выглядит адекватно на фоне одной десятой?
Я чисто интуитивно высказываюсь, если что. Никаких бенчей с подтверждением этой мысли у меня нет.
Я чисто интуитивно высказываюсь, если что. Никаких бенчей с подтверждением этой мысли у меня нет.
Когда речь идет о многопоточной работе, начинаются некие поползновения насчет великих и ужасных context switch, которые сами по себе занимают 1..100 тех же самых микросекунд, по разным оценкам. То есть, если ForkJoinPool видимо гарантирует, что там их будет уж точно не больше, чем в самом обычном коде, то остаются только всякие приседания насчет создания(аллокации)/очистки объектов ForkJoinTask, положить/взять что-то из каких-то очередей, некая легковесная синхронизация… все это по отдельности — единицы/десятки наносекунд, взятое вместе, на все сплиты — ну, может, 1000 наносекунд (1 микросекунда) набежит… Так что дробить от 10 микросекунд — кажется адекватным.
(продолжение пред. комментария)
В этой связи даже 100 микросекунд кажется очень консервативным порогом. Я вижу еще как минимум пару моментов, которые влияют на увеличение оценки:
— Параллельный reduce может быть довольно дорогим. Скажем, collect to Set/Map создает промежуточные «локальные» хеш-таблицы, которые затем сливает вместе в новые (или одну, выбранную из локальных, я не помню), таким образом тут уже довольно серьезные расходы, связанные с излишним хешированием, созданием дополнительных структур… Кстати, любопытно, что GS collections в этом случае собирают в одну единственную ConcurrentMap, и говорят что это лучше: www.slideshare.net/InfoQ/parallellazy-performance-java-8-vs-scala-vs-gs-collections/71, хотя в этом случае тоже проявляется дополнительная цена параллельного вычисления над последовательным
— Хотя данные для параллельной/последовательной обработки, скорее всего, надо «читать» в рабочем потоке в первый раз, а значит без разницы, из какого потока, обработка может использовать довольно большой внешний «контекст», сидящий в горячих кешах текущего потока, а не всех тех потоков, на которые будет параллелиться работа. Что то вроде ids.stream().mapTo(id -> cache.getSomValue(id)), если этот cache горячий в текущем потоке. А на его прогрев в параллельных потоках потребуется время. Надеюсь, мысль понятна.
В этой связи даже 100 микросекунд кажется очень консервативным порогом. Я вижу еще как минимум пару моментов, которые влияют на увеличение оценки:
— Параллельный reduce может быть довольно дорогим. Скажем, collect to Set/Map создает промежуточные «локальные» хеш-таблицы, которые затем сливает вместе в новые (или одну, выбранную из локальных, я не помню), таким образом тут уже довольно серьезные расходы, связанные с излишним хешированием, созданием дополнительных структур… Кстати, любопытно, что GS collections в этом случае собирают в одну единственную ConcurrentMap, и говорят что это лучше: www.slideshare.net/InfoQ/parallellazy-performance-java-8-vs-scala-vs-gs-collections/71, хотя в этом случае тоже проявляется дополнительная цена параллельного вычисления над последовательным
— Хотя данные для параллельной/последовательной обработки, скорее всего, надо «читать» в рабочем потоке в первый раз, а значит без разницы, из какого потока, обработка может использовать довольно большой внешний «контекст», сидящий в горячих кешах текущего потока, а не всех тех потоков, на которые будет параллелиться работа. Что то вроде ids.stream().mapTo(id -> cache.getSomValue(id)), если этот cache горячий в текущем потоке. А на его прогрев в параллельных потоках потребуется время. Надеюсь, мысль понятна.
100 мкс — это уже порядок систем реального времени. Вот, только Java таковой не является. Что говорить про оптимизации в микросекунды, если средняя safepoint пауза может составлять 1-10 миллисекунд. Да даже Linux не даёт тебе таких гарантий: поток может запросто проснуться на миллисекунду позже, чем попросишь. Сетевой раундтрип — плюс миллисекунда. Обращение к диску — еще пара миллисекунд.
Я не говорю сейчас про трейдеров, которые насилуют Java похлеще нашего high load. Но в большинстве случаев распараллеливание настолько коротких задач не оправдывает себя. Тем более, что параллельные алгоритмы как правило сложнее и опаснее (всмомни хотя бы пример с дедлоком из-за параллельного стрима).
Я не говорю сейчас про трейдеров, которые насилуют Java похлеще нашего high load. Но в большинстве случаев распараллеливание настолько коротких задач не оправдывает себя. Тем более, что параллельные алгоритмы как правило сложнее и опаснее (всмомни хотя бы пример с дедлоком из-за параллельного стрима).
насколько реальному пользователю нужна векторизация
Делали же project sumatra + graal для генерации hsail. В презентациях и на бумаге идея отличная — Stream API, вся магия под капотом jvm и никакого opencl и cuda. По публикациям и статусу — похоже что проект будет долго дозревать как jigsaw. Сергей, можете поделиться новостями про этот проект?
рандомный генератор настоящий в последних интеловских железках
Так вроде не доверяют этой криптографии
Sumatra — попытка все больше и больше отстающей AMD догнать конкурентов за счет гетерогенных ( APU) вычислений. То есть, еще один уровень абстракции. Как поведут себя GPU на стримах — большой вопрос.
По поводу криптографии — эта тема активно развивается. Так же, как и транзакционная память. Но там еще работать и работать, как в железе, так и потом в джаве.
По поводу криптографии — эта тема активно развивается. Так же, как и транзакционная память. Но там еще работать и работать, как в железе, так и потом в джаве.
Алексей, что-нибудь слышно из Oracle про судьбу Sumatra?
Что такое OpenCL и как жить с ним в java знаю не по наслышке. Собственно эта тема достаточно популярная в узких кругах)
Shared Virtual Memory как раз решает большую часть вопросов. Остается оверхед на генерацию промежуточного кода и его оптимизацию для целевой платформы, а также на переключение контекста между CPU и GPU во время выполнения и поддержку когерентности кешей.
Нет проблем использовать специализированный аппаратный ускоритель для криптографии и интегрировать работу с ним в jvm, вопрос в отсутствии закладок и уязвимостей в реализации. И аппаратное решение сложнее проверить, чем программную реализацию.
Уверен что поддержка аппаратной транзакционной памяти на уровне jvm, даст толчок к упрощению разработки ПО. Пока же STM достаточно медленная, чтобы народ массово начал использовать ее во многих проектах.
Что такое OpenCL и как жить с ним в java знаю не по наслышке. Собственно эта тема достаточно популярная в узких кругах)
Как поведут себя GPU на стримах — большой вопрос.
Shared Virtual Memory как раз решает большую часть вопросов. Остается оверхед на генерацию промежуточного кода и его оптимизацию для целевой платформы, а также на переключение контекста между CPU и GPU во время выполнения и поддержку когерентности кешей.
По поводу криптографии — эта тема активно развивается. Так же, как и транзакционная память. Но там еще работать и работать, как в железе, так и потом в джаве.
Нет проблем использовать специализированный аппаратный ускоритель для криптографии и интегрировать работу с ним в jvm, вопрос в отсутствии закладок и уязвимостей в реализации. И аппаратное решение сложнее проверить, чем программную реализацию.
Уверен что поддержка аппаратной транзакционной памяти на уровне jvm, даст толчок к упрощению разработки ПО. Пока же STM достаточно медленная, чтобы народ массово начал использовать ее во многих проектах.
Остановился на чтениии на половине интервью. Мне почему то показалось что Куксенко отвечает на вопросы грубо и по хамски. Либо был очень сильно не в духе либо у него такая манера либо ему все пофиг
Sign up to leave a comment.
«Работа инженеров – предъявлять претензии» — Интервью с Сергеем Куксенко из Java Performance Team