Как стать автором
Обновить
31
Карма
0
Рейтинг
Григорий Кошелев @gnkoshelev

Team Lead

  • Подписчики 22
  • Подписки

Разбор перформансных задач с JBreak (часть 3)

Акцент во всех трёх частях был на изучении поведения и выявлении его причин.
Возможно, вы правы, и от академического изложения пользы для читателя будет больше. Попробую четвёртую задачу разобрать в другом ключе, благо сам текст написан лишь частично.

Разбор перформансных задач с JBreak (часть 3)

Не заметил, как у меня во время редактирования пропал кусок разметки с самым интересным результатом работы бенчмарка Vector-with-final-fields vs Vector-with-non-final-fields на JRE 1.8.0_161:
Benchmark                                        Mode  Cnt  Score   Error  Units
FinalOrNotFinal...computeWithFinalsBenchmark     avgt   50  2,618 ± 0,075  ns/op
FinalOrNotFinal...computeWithNonFinalsBenchmark  avgt   50  0,929 ± 0,005  ns/op

Кроме самого факта необычности результата, интересно и то, что на JRE 9.0.4 результат не воспроизводится.

Спасибо sheknitrtch за найденную ошибку!

Разбор перформансных задач с JBreak (часть 3)

На моём процессоре Intel Core i7-4710MQ представленный код компилируется в SIMD-инструкции vaddsd, vmulsd и др.

Разбор перформансных задач с JBreak (часть 2)

Опубликовал продолжение — Часть 3.

Вредный Кейворд «Interface»

Класс подразумевает наличие состояния (state).
Интерфейс — нет.

Да, в Java 8 добавили default-методы и статические методы, а в Java 9 — приватные default-методы и приватные статические методы, но с состоянием это не имеет ничего общего.

Если не ошибаюсь, в C# вошло в моду называть интерфейсы с префиксом I, т.к. этот костыль помогает глядя в код понять, что после : находится класс или интерфейс. А использование implements / extends делает код лучше для восприятия (субъективно).

Разбор перформансных задач с JBreak (часть 2)

Ага, я чуть позже про OptimizeStringConcat дописал.

Если же в цепочке попадётся append(long), то оптимизация не отработает — ну, не реализовали почему-то в JDK 8), то есть, будет честный вызов Java кода.
Судя по изменениям в stringopts.cpp в JDK 10/JDK 9 относительно JDK 8, то в новых версиях это по-прежнему не оптимизируется.

Разбор перформансных задач с JBreak (часть 2)

Согласен, в этом месте влияние JIT не настолько существенное — выше Андрей apangin намекнул на различия в определении длины строки под long в StringBuilder и StringConcatFactory. apangin, я же правильно понял, что речь об этом?

[Екатеринбург, анонс] Новые Java-митапы в Екатеринбурге: java.ural.Meetup @1

Прямая отсылка к Уральским горам.

Из нескольких вариантов — этот понравился больше всего (и не только мне).

Разбор перформансных задач с JBreak (часть 2)

Касательно корректности рассуждений о производительности с учётом огромного числа эвристик HotSpot'а: задача объяснить наблюдаемое поведение выглядит значительно привлекательнее задачи оценки или сравнения производительности алгоритмов.
Но выбор в пользу первого варианта объяснялся форматом проведения викторины на конференции, когда по ответам можно было быстро отсортировать решения и уже дальше смотреть пояснения к ответам. В следующий раз стоит выбрать детерминированный вариант задач.

Разбор перформансных задач с JBreak (часть 2)

За задачи и разбор +1, но делать выводы о производительности по байткоду не совсем корректно, как я показывал в презентации.

Спасибо!
За исключением тех случаев, когда javac генерирует идентичный байткод. :) В остальном согласен, и чем дальше (тот же JEP-280), тем поведение JIT-компилятора становится менее предсказуемым.

В этой же презентации про конкатенацию, кстати, тоже есть. Нельзя бенчмаркать StringBuilder и не упомянуть фичу Хотспота под названием OptimizeStringConcat.

О, точно, я уже под утро заканчивал статью и про OptimizeStringConcat совсем забыл, а это важная штука.

Разбор перформансных задач с JBreak (часть 1)

Дополнил статью ссылкой на эксплойт Тагира lany.

Разбор перформансных задач с JBreak (часть 1)

Какое это имеет отношение к озвученной задаче?

Всегда есть место некоторому допущению. Как, например, при вступлении в брак предполагается, что супруги будут верны друг другу.

Вы просите оценить производительность трёх методов, вот только получается, что их производительность зависит не от того, что написано в них самих, а от подробностей внешних условий, которые вы никак не задаёте, а значит они могут быть произвольными.

Строго говоря, на пути вашего кода на Java к производительности есть по меньшей мере javac, JIT-компилятор, GC, side-эффекты от остальной части JVM, OS, hardware и ещё много чего, о чём я даже не подозреваю. При этом, если вы можете легко рассуждать о влиянии всех этих вещей на итоговую производительность — вы круты.
в чём смысл такой задачи — лично мне неясно

В том же, в чём, например, смысл логических задач — разминка для ума.

Java 9 — Вы уже перешли? Нет? И не надо ...!?

Я Java бы выучил только за то,
Что раз написав — используй легко.
Релизы не часто, но верность хранит
И качеству кода, и стилю.
Как часто бывает, когда любой наш коммит
Останется с нами на годы?
Совместимости ради полюбишь и ты,
Друг мой, Java исходные коды.

Разбор перформансных задач с JBreak (часть 1)

Вот ваши задачи жду. Сам сходу смог только половину осилить (и то ещё проверить надо!)

Java 9 — Вы уже перешли? Нет? И не надо ...!?

Из того, что может (лично меня) побудить перейти на Java 9 — это стандартный годный HTTP-клиент и jshell, но с этим и подождать можно.

Java 9 — Вы уже перешли? Нет? И не надо ...!?

В продакшене были версии Java 6, 7 и 8. И всегда прекрасно себя чувствовал.
Непривычно было только один раз года 4 назад, когда с проекта на Java 7 перешёл на проект с Java 6: но к отсутствию dimond operator, try-with-resources, multi-catch exception привык быстро (только некоторые наработки пришлось портировать).

Разбор перформансных задач с JBreak (часть 1)

Чтобы правильно ответить на задачи нужно было либо знать, либо разобраться (посмотреть исходники, закодить за пять минут наколеночный бенчмарк или спросить у гугла). Никто этого не отрицает.
На одном из стендов вообще был ассемблерный код, эквивалент которого генерит JIT — было б время, поразбирался из интереса. Хотя первая реакция была такой же, как ваша.

Разбор перформансных задач с JBreak (часть 1)

Часто вы используете реализации List или наследников PrintStream, отличных от JDK'шных?
К самой викторине нужно относиться как к развлечению, хотя и здесь JIT оставляет нам пространство на подумать.

Экспресс-оценка сложности алгоритма (+разбор задачи c Joker 2017 и DotNext 2017 Moscow)

Да, мы можем заменить x на n и получить некоторую оценку, но мы не можем тривиальным образом утверждать из-за огрубления, что она будет точнее прочих предложенных:
Наиболее точный ответ на последний вопрос предлагалось выбрать из внушительного списка вариантов.

Экспресс-оценка сложности алгоритма (+разбор задачи c Joker 2017 и DotNext 2017 Moscow)

Справедливости ради, остаётся недоказанной равносильность перехода от сложности алгоритма for-for-toBinaryString к произведению сложности вложенных циклов for-for и сложности метода toBinaryString, поскольку x в оценке O(log²(x)) метода зависит от состояния цикла.

Выше предлагается эмпирически способ подсчёта вычислительной сложности с засеканием времени. Ещё один альтернативный способ (без необходимости засекать время):
  1. Заменяем все операции на увеличение счётчика.
  2. Если количество операций может быть посчитано явно (без необходимости крутить цикл или рекурсию, то прибавляем сразу необходимое количество.
  3. Делаем для n разного порядка и подбираем подходящую асимптотику.
  4. Profit!

Информация

В рейтинге
Не участвует
Откуда
Екатеринбург, Свердловская обл., Россия
Работает в
Зарегистрирован
Активность