Comments 16
То чувство, когда хотел прочитать, но устал листать одни и теже фотки…
Закрыл, короче.
Закрыл, короче.
Держи нас в курсе! :-)
поддерживаю. Фотки мешают читать текст перехватывая фокус
Мне помог установеленний раньше image-block (https://addons.mozilla.org/en-US/firefox/addon/image-block/?src=search).
скажите, а есть возможность делать аудиоверсии? в формате подкастов..
Какой сейчас самый мощный ARM сервер, сколько ядер? И если есть аппаратные оптимизации, то почему дефолтный TLS из OpenJDK, такой тормозной на Intel по сравнению с openssl? Или на ARMv8 норм?
Доступен (commodity) Cavium ThunderX2: 32 физических ядра c 4 потоками исполнения на package, коих до 2 на сервер --> 256 cpu на сервере. Прототип суперкомпьютера Fujitsu Post-K: 48+4 ядра на package, 384 ноды в стойке, Tofu interconnect, SVE (512 бит).
Производительность TLS была улучшена в Java 9, отличие от OpenSSL порядка 10% и зависит от бенчмарка. На AArch64 тоже норм.
Производительность TLS была улучшена в Java 9, отличие от OpenSSL порядка 10% и зависит от бенчмарка. На AArch64 тоже норм.
>Например, платформенно-специфичные части, ускорение которых в OpenJDK может помочь ускорить Hadoop. Если интересно, можем поговорить об этом.
Интересно, хотя исходя из практики верится с некоторым трудом. Скажем так — наши типовые задачи для хадупа таковы, что значительная часть ресурсов уходит на дисковый и сетевой обмен. Понятно, что можно и нужно ускорять и вычисления, или скажем экономить память, но и то, и другое довольно редко ограничивает производительность.
Бывают и задачи, которые хотелось бы выгрузить и на GPU, но их сравнительно мало. Иногда хочется ML и допустим NLP, но таких задач тоже мало. Большая часть задач — либо ETL либо SQL.
И да, хадуп на сегодня штатно живет на Java 8. Просто смигрировать его на OpenJDK 9-11 выглядит намного более интересным.
Интересно, хотя исходя из практики верится с некоторым трудом. Скажем так — наши типовые задачи для хадупа таковы, что значительная часть ресурсов уходит на дисковый и сетевой обмен. Понятно, что можно и нужно ускорять и вычисления, или скажем экономить память, но и то, и другое довольно редко ограничивает производительность.
Бывают и задачи, которые хотелось бы выгрузить и на GPU, но их сравнительно мало. Иногда хочется ML и допустим NLP, но таких задач тоже мало. Большая часть задач — либо ETL либо SQL.
И да, хадуп на сегодня штатно живет на Java 8. Просто смигрировать его на OpenJDK 9-11 выглядит намного более интересным.
Да, разница между затратами на ввод-вывод и на вычисления на порядок, но 10% никогда не лишние. Дисковое I/O можно вполне тянуть SSD с распараллеливанием записи, но у всего есть пределы.
Забавно, что вспомнили GPU, ведь там тоже Arm (их дизайн), хотя и не ARM (ISA), в тексте кстати ошибка в этих обозначениях. Никто не мешает сгрузить прямо из джавы (Дима Александров делал недавно хороший обзор по теме) или средствами самого хадупа (начиная с версии 3). У Cavium'а есть опция ставить Tesla от NVidia. Для ML делают специальные армовые железяки. Даже не для быстродейтвия, а чтобы электричество экономить.
Миграция на 9-11, а лучше 10-11 — да, может быть очень полезна. Особенно на арме.
Забавно, что вспомнили GPU, ведь там тоже Arm (их дизайн), хотя и не ARM (ISA), в тексте кстати ошибка в этих обозначениях. Никто не мешает сгрузить прямо из джавы (Дима Александров делал недавно хороший обзор по теме) или средствами самого хадупа (начиная с версии 3). У Cavium'а есть опция ставить Tesla от NVidia. Для ML делают специальные армовые железяки. Даже не для быстродейтвия, а чтобы электричество экономить.
Миграция на 9-11, а лучше 10-11 — да, может быть очень полезна. Особенно на арме.
Я совершенно согласен, что и 10% не лишние, но имеющиеся ресурсы (человеческие) ограничены. Поэтому если заказчик или разработчик видит, что можно скажем ускориться на порядок (и пути в целом достаточно очевидны) — то это и будет делаться.
>Дисковое I/O можно вполне тянуть SSD
Насколько я знаю, у нас на такую роскошь, как весь кластер на SSD, нет денег. Наверное можно было бы выделить часть узлов кластера под SSD, но это отдельная интересная задача. И поддерживается вроде бы уже (кажется даже в 2.3 было реализовано), но насколько я знаю — никто вокруг не пробовал.
>Дисковое I/O можно вполне тянуть SSD
Насколько я знаю, у нас на такую роскошь, как весь кластер на SSD, нет денег. Наверное можно было бы выделить часть узлов кластера под SSD, но это отдельная интересная задача. И поддерживается вроде бы уже (кажется даже в 2.3 было реализовано), но насколько я знаю — никто вокруг не пробовал.
Кто-нибудь может вкратце подытожить. Нет сил и времени эту портянку. Почему прежним то не будет?
summary:
— … Нужно сказать, что Arm-экосистема софта шагнула далеко вперед. Если пять лет назад были проблемы с тем, чтобы поднять железку, то сейчас таких проблем нет. Вы просто приходите, и у вас всё работает out of the box. Работает всё, к чему вы привыкли — Linux, Docker, Kubernetes, Xen, Java, Hadoop, Spark, Kafka, все что угодно.
— Что насчет Java? Расскажите, как она работает, чем отличается от «обычной»?
— Ничем не отличается, в этом и есть ее основное преимущество. Она достаточно производительная для того, чтобы справляться с теми задачами, которые возложены на Java для серверов. Вы переносите свое приложение (надеюсь, что у него нет нативной части, иначе придется его рекомпилировать), на Arm-сервер, проверяете производительность и в большинстве случаев — радуетесь. Недавно вышла статья, где мы сравниваем производительность Arm-сервера с Intel-сервером. Статья вышла в Java Magazine.
Интервью интересное, спасибо! А можно так сделать, чтобы ваша sdk скачивалась через sdkman? Это удобно
Sign up to leave a comment.
«Java-мир больше никогда не будет прежним» — интервью с Александром Белокрыловым и Алексеем Войтыловым из BellSoft