В целом да, можно придраться. Но, как человек, который работает с виртуальными тредами каждый день, могу сказать, что фраза "создать поток" для меня уже давно значит создать именно виртуальный поток. А создать несущий тред (carrier thread) или реальный тред - говорит о том реальном треде.
Пo антипаттерну: ну вот с появлением виртуальных тредов это больше не антиаттерн. Нужен поток - создай виртуальный, сделай в нем что нужно, и выброси. Это отныне очень дешево и производительно. Времена меняются!
Ну и стоит добавить, что пользователи Helidon MP получат троекратный (по нашим бенчмаркам) performance boost, просто поменяв версию на 4. Ведь MicroProfile это стандарт, сам код микросервиса менять не надо.
Во-первых хочу сказать - большое спасибо за статью! Она отличная! Во-вторых.. Прочитав все коментарии, мне показалась, что все описанное слишком “революционно” для многих комментаторов. И мне тоже показалось, что большинство все еще не делают разницы между “обыкновенными” тредами и виртуальными тредами. Я попытаюсь внести немного больше ясности и в терминологию Хелидона, хотя автор в целом все правильно написал. Helidon Nima это внутреннее название веб сервера написанного с нуля в блокирующей парадигме с использованием виртуальных тредов. Ныне официально этот веб сервер называется Helidon Web Server (вот так просто). Старое имя Nima больше не используется. Helidon SE и Helidon MP это уже полноценные фреймворки для написания микросервисов. SE использует максимально “джавовый” стиль программирования, а MP сертифицирована по MicroProfile спецификации, и в ней много всякой магии в стиле спрингов (типа поставил пару аннотаций и все само заработало). В версиях 1-3 низкоуровневым веб сервером служил Netty. В Helidon SE был свой отдельный независимый реактивный движок Helidon Reactive Engine (его, кстати, помогал писать сам Дейвид Карнок). Все API фреймворка Helidon SE были реактивными на базе этого движка и Netty в основе. То есть, если хочешь написать микросервис, то надо написать его в реактивной парадигме используя Single, Multi (хелидоновские аналоги Mono и Flux) и кучей реактивных операторов. С появлением Helidon Web Server (в прошлом Helidon Nima) было принято решение переписать весь Helidon SE под “блокирующую” парадигму и полностью убрать Netty. Тем самым фреймворк Helidon SE 4 обзавелся новым “нереактивным блокирующим” API и новым Helidon Web Server. То есть с версии 4 нет всех этих Single и Multi и реактивных операторов. Просто пишется блокирующий код, как нас учили в 5м классе. И что получилось - команде Helidon мы сравнивали Netty с Helidon Web Server, и этот Helidon Web Server оказался на пару процентов быстрее. Здророво то, что код самого веб сервера стал меньше по объему, понятнее и легким в отладке. Насколько я вижу, автор сравнивает webflux именно с Helidon SE 4 (который работает на основе Helidon Web Server). То есть сравнивает фреймворки. И насколько я вижу из примера, там не только сам Helidon Web Server, но и метрики и всякие observability фичи, и т.д. Поэтому сравнение вполне корректно. Я погонял пример у себя (M1 Max, 64 Gb RAM, Aarch64 JDK21), и результаты схожие. Так что, все вышеописанное верно! Еще раз спасибо за статью! Ознакомиться с результатами бенчмарков можно из ответа m0mus.
Helidon 4, который выйдет в течение месяца, уже полностью перенаписан под виртуальные треды. Нетти просто выкинули за ненадобностью, производительность стала еще лучше (данные есть в прогонах TechEmpower).
На самом деле, это уже вопрос настройки самой Кафки, я в ней не спец. Но, учитывая, что кафка запускается довольно быстро (во всяком случае на моем железе), можно просто для каждого теста давать новый свежий контейнер.
Но, для ускорения и оптимизации тестирования, тут стоит поговорить со спецом по кафке.
Живет на Java 11+, по сему использует все плюшки новых версий (modularity например).
Полная поддержка CDI. Все работает по стандарту! Более того и в native-image.
Наличие SE и всего того, что есть в его спецификациях и реализациях (DB client, реактивщина и т.д.)
Стоит отметить, что полная поддержка стандартов, оптимизация их имплементаций это основной конек Helidon, и для JVM и для native-image.
Сейчас много работы ведется над интеграциями с другими технологиями (Neo4j, Microstreams и т.д)
Общий ответ от Мартина Кръстева:
Тест идет полностью из L1, который всега работает на частоте процессора, так что частота процессора не играет роли в этом тесте.
В оригинале Даниела поищите despace_mask16 — это таблица.
Апропо, идея данного теста быть микро- и макро-архитектурным — т.е. какие инструкции сколько работы успевают сделать — не случайно он не должен зависеть от доступа к памяти (вне L1)
А задуман он именно так, потому что если помните, Даниел жаловался что не хватает одной важной инструкции в ARM (которая на нем заменяется двумя), и поэтому он не мог написать быстрый пруннер.
Я считаю, что скалярный тест и векторный тест показывают довольно ясно, что архитектурно ARM справляется лучше — больше работы за меньше инструкций. И это видно по результатам лучшего соотношения работа/такт в скалярной версии, но в SIMD версии ARM отстает в два раза из-за плохой микроархитекрурной реализации.
(т.е. там инструкций меньше, но они выполняются за больше тактов)
А по теме 'а практически — в шестеро!' — посмотрите следующую статья Даниела, где он сам приходит к выводу, что ARM ~3 раза медленнее (после всех правок и советов его читателей).
Перевод ответа от Мартина Кръстева: Да, хорошо было бы. Но есть одно но: естество теста таково, что компилятору особенно нечего оптимизировать, кроме упорядочивания инструкций оптимальным образом (scheduler). Но хорошо бы действительно посмотреть на g++ по-новее. У меня самого не хватило времени обеспечить наличие g++ 6.x на разных платформах, в то время как 4.х и 5.х уже были там.
Ка ни странно, но все действительно неплохо работает с минимальной конфигурацией. Понятно, что датасорсы пришлось прописывать по-своему на каждом сервере. Больше пришлось повозиться разве что с JAAS, но и тут я лично жду унификации. А а так у нас ни одной вендор специфик аннотации, и этого нам вполне хватает при данных требованиях.
В целом да, можно придраться. Но, как человек, который работает с виртуальными тредами каждый день, могу сказать, что фраза "создать поток" для меня уже давно значит создать именно виртуальный поток. А создать несущий тред (carrier thread) или реальный тред - говорит о том реальном треде.
Пo антипаттерну: ну вот с появлением виртуальных тредов это больше не антиаттерн. Нужен поток - создай виртуальный, сделай в нем что нужно, и выброси. Это отныне очень дешево и производительно. Времена меняются!
Ну и стоит добавить, что пользователи Helidon MP получат троекратный (по нашим бенчмаркам) performance boost, просто поменяв версию на 4. Ведь MicroProfile это стандарт, сам код микросервиса менять не надо.
Во-первых хочу сказать - большое спасибо за статью! Она отличная!
Во-вторых.. Прочитав все коментарии, мне показалась, что все описанное слишком “революционно” для многих комментаторов. И мне тоже показалось, что большинство все еще не делают разницы между “обыкновенными” тредами и виртуальными тредами.
Я попытаюсь внести немного больше ясности и в терминологию Хелидона, хотя автор в целом все правильно написал.
Helidon Nima это внутреннее название веб сервера написанного с нуля в блокирующей парадигме с использованием виртуальных тредов. Ныне официально этот веб сервер называется Helidon Web Server (вот так просто). Старое имя Nima больше не используется.
Helidon SE и Helidon MP это уже полноценные фреймворки для написания микросервисов. SE использует максимально “джавовый” стиль программирования, а MP сертифицирована по MicroProfile спецификации, и в ней много всякой магии в стиле спрингов (типа поставил пару аннотаций и все само заработало).
В версиях 1-3 низкоуровневым веб сервером служил Netty. В Helidon SE был свой отдельный независимый реактивный движок Helidon Reactive Engine (его, кстати, помогал писать сам Дейвид Карнок). Все API фреймворка Helidon SE были реактивными на базе этого движка и Netty в основе. То есть, если хочешь написать микросервис, то надо написать его в реактивной парадигме используя Single, Multi (хелидоновские аналоги Mono и Flux) и кучей реактивных операторов.
С появлением Helidon Web Server (в прошлом Helidon Nima) было принято решение переписать весь Helidon SE под “блокирующую” парадигму и полностью убрать Netty. Тем самым фреймворк Helidon SE 4 обзавелся новым “нереактивным блокирующим” API и новым Helidon Web Server. То есть с версии 4 нет всех этих Single и Multi и реактивных операторов. Просто пишется блокирующий код, как нас учили в 5м классе.
И что получилось - команде Helidon мы сравнивали Netty с Helidon Web Server, и этот Helidon Web Server оказался на пару процентов быстрее. Здророво то, что код самого веб сервера стал меньше по объему, понятнее и легким в отладке.
Насколько я вижу, автор сравнивает webflux именно с Helidon SE 4 (который работает на основе Helidon Web Server). То есть сравнивает фреймворки. И насколько я вижу из примера, там не только сам Helidon Web Server, но и метрики и всякие observability фичи, и т.д.
Поэтому сравнение вполне корректно.
Я погонял пример у себя (M1 Max, 64 Gb RAM, Aarch64 JDK21), и результаты схожие.
Так что, все вышеописанное верно! Еще раз спасибо за статью!
Ознакомиться с результатами бенчмарков можно из ответа m0mus.
Helidon 4, который выйдет в течение месяца, уже полностью перенаписан под виртуальные треды. Нетти просто выкинули за ненадобностью, производительность стала еще лучше (данные есть в прогонах TechEmpower).
Он быстрее и меньше)
На самом деле, это уже вопрос настройки самой Кафки, я в ней не спец. Но, учитывая, что кафка запускается довольно быстро (во всяком случае на моем железе), можно просто для каждого теста давать новый свежий контейнер.
Но, для ускорения и оптимизации тестирования, тут стоит поговорить со спецом по кафке.
Да, это перевод, я это указал только что :)
Но далеко не машинный, возможно я уже так коряво думаю (чаще живу не в России). Иногда даже выдумываю новые слова..
О да, это уже in progress. PetClinic это святое!
Но пока CLI позволяет сгенерировать отличные очень компактные quickstarter-ы :)
Очевидные плюсы:
Стоит отметить, что полная поддержка стандартов, оптимизация их имплементаций это основной конек Helidon, и для JVM и для native-image.
Сейчас много работы ведется над интеграциями с другими технологиями (Neo4j, Microstreams и т.д)
github.com/blu/ascii_pruner/blob/master/README.md
Тест идет полностью из L1, который всега работает на частоте процессора, так что частота процессора не играет роли в этом тесте.
В оригинале Даниела поищите despace_mask16 — это таблица.
Апропо, идея данного теста быть микро- и макро-архитектурным — т.е. какие инструкции сколько работы успевают сделать — не случайно он не должен зависеть от доступа к памяти (вне L1)
А задуман он именно так, потому что если помните, Даниел жаловался что не хватает одной важной инструкции в ARM (которая на нем заменяется двумя), и поэтому он не мог написать быстрый пруннер.
Я считаю, что скалярный тест и векторный тест показывают довольно ясно, что архитектурно ARM справляется лучше — больше работы за меньше инструкций. И это видно по результатам лучшего соотношения работа/такт в скалярной версии, но в SIMD версии ARM отстает в два раза из-за плохой микроархитекрурной реализации.
(т.е. там инструкций меньше, но они выполняются за больше тактов)
А по теме 'а практически — в шестеро!' — посмотрите следующую статья Даниела, где он сам приходит к выводу, что ARM ~3 раза медленнее (после всех правок и советов его читателей).
Спасибо)
https://habrahabr.ru/post/334142/