Скотт Селлерс, генеральный директор компании Azul, которая предлагает альтернативу Oracle Java Development Kit (JDK) под названием Azul Platform Core для разработки и запуска корпоративных Java-приложений, рассказал порталу ComputerWeekly о влиянии процессорных архитектур на разработку корпоративного ПО и о том, почему первоначальная мантра Java «write once run anywhere» (WORA) важна как никогда.
Тот факт, что процессоры ARM64 отличаются низким энергопотреблением, означает, что в одном и том же объеме пространства дата-центра можно разместить больше серверов, чем на x86-оборудовании.
Если рабочие нагрузки могут выполняться на оборудовании ARM64, то на одну стойку ЦОДа потенциально приходится больше вычислительной мощности. Кроме того, каждая стойка на базе ARM потребляет меньше энергии и требует меньшей инфраструктуры охлаждения, чем стойка для x86-серверов.
Уже не факт, что единственной целевой платформой для корпоративных приложений является сервер x86 на базе процессоров Intel или AMD. Графические процессоры (GPU) от Nvidia и наличие альтернативных серверных чипов от ARM означают, что выбор целевой серверной платформы является важным решением при развертывании корпоративных приложений.
Подъем ARM
«Нет никаких сомнений в том, что инновации в архитектуре ARM64 оказывают глубокое влияние на рынок», — говорит Селлерс. Например, отмечает он, Amazon вложила значительные средства в разработку серверных архитектур на базе ARM64 для Amazon Web Services (AWS), а Microsoft и Google также реализуют инициативы по созданию ARM-серверов.
«Это изначально более экономичная платформа по сравнению с серверами x86, — добавляет Селлерс. — На данный момент производительность ARM64 равна, если не лучше, чем у x86, а общая энергоэффективность значительно выше».
По его словам, рабочие нагрузки ARM64 набирают обороты. Хотя публичные облака обычно поддерживают несколько языков программирования, включая Python, Java, C++ и Rust, использование языков, которые необходимо компилировать для целевой платформы, означает повторное обращение к исходному коду при миграции между серверами на базе x86 и ARM. Интерпретируемые языки, такие как Python и Java, которые компилируются «точно вовремя» («just in time») при запуске приложения, не требуют перекомпиляции приложений.
«Прелесть Java в том, что приложение не нужно модифицировать. Никаких изменений не требуется. Оно действительно просто работает», — говорит Селлерс.
По его словам, переход на другую платформу обычно требует большого объема работы и тестирования, что значительно усложняет процесс переноса облачных рабочих нагрузок с серверов x86 на ARM64. «Если вы основываете свои приложения на Java, вам не придется закладывать под это ресурсы. Вы сможете выделять их динамически, исходя из того, что доступно», — говорит Селлерс.
Это фактически означает, что в инфраструктуре публичного облака как сервисе разработчик Java просто пишет код один раз, а компилятор Java генерирует инструкции машинного кода для целевого процессора при выполнении кода. Лица, принимающие ИТ-решения, могут динамически оценивать стоимость и производительность и выбирать процессорную архитектуру, исходя из стоимости или необходимого уровня производительности.
Селлерс утверждает, что Java работает исключительно хорошо как на x86-, так и на ARM64-платформах. По его словам, заказчики отмечают 30-40%-ный выигрыш в производительности при использовании среды выполнения Java. «Это справедливо как для x86, так и для ARM64», — добавляет он.
По словам Селлерса, ИТ-руководители могут воспользоваться преимуществами производительности и эффективности, доступными на платформе ARM64, без необходимости вносить какие-либо изменения в целевую рабочую нагрузку. В публичном облаке, по его словам, это не только экономит деньги — ведь для достижения того же уровня производительности рабочая нагрузка использует меньше облачных вычислений, — но и ускоряет работу.
Решение о том, на какой платформе развернуть рабочую нагрузку, Селлерс считает необходимым оценивать в рамках расчета окупаемости инвестиций. «При одинаковом объеме памяти и вычислительных мощностей узел ARM64 обычно примерно на 20% дешевле x86-аналога», — говорит он и добавляет, что это хорошо для технологического сектора, поскольку «заставляет Intel и AMD быть честными».
«Некоторые из крупных заказчиков теперь просто используют гибридные развертывания в облаке, а под гибридными я подразумеваю одновременное использование x86 и ARM64, чтобы получить лучшее из всех миров», — отмечает Селлерс, имея в виду тот факт, что, хотя компании действительно могут хотеть запускать рабочие нагрузки на инфраструктуре ARM64, в публичной облачной инфраструктуре развернуто гораздо больше x86-комплектов.
Со временем ситуация изменится, но пока, как отмечает Селлерс, многие из крупных заказчиков не могут приобрести достаточное количество вычислительных узлов ARM64 у провайдеров публичных облаков, поэтому им приходится немного хеджировать свои ставки. Тем не менее, считает он, ARM64 неизбежно станет доминирующей силой в инфраструктуре публичных облачных вычислений.
Почему не всегда дело в графических процессорах
Nvidia отмечает огромный спрос на свои графические процессоры (GPU) для обеспечения рабочих нагрузок искусственного интеллекта в дата-центрах. GPU объединяют в одном устройстве сотни относительно простых процессорных ядер, которые можно запрограммировать на параллельную работу, что позволяет добиться ускорения, необходимого для вычислений ИИ-выводов и рабочих нагрузок машинного обучения.
Селлерс описывает ИИ как «на удивление параллельную» задачу, которую можно решать с помощью большого количества вычислительных ядер GPU, каждое из которых выполняет относительно простой набор инструкций. Именно поэтому GPU стали двигателем ИИ. Однако это не делает их подходящими для всех приложений, требующих высокой степени параллелизма, когда несколько сложных задач программируются для одновременного выполнения.
В качестве примера Селлерс приводит финансовую биржу LMAX Group, которой GPU не подошли бы: «Они были бы слишком медленными, а сценарий использования LMAX ни в коем случае не является таким параллельным по своей сути, как ИИ».
По его словам, GPU полезны для ускорения очень специфических типов приложений, где относительно простая часть обработки может быть распределена между многими процессорными ядрами. Но GPU не подходят для корпоративных приложений, в которых сложный код должен выполняться параллельно на нескольких процессорах.
Помимо споров о том, стоит ли использовать GPU в корпоративных приложениях, по словам Селлерса, важным моментом при написании ИИ-программ, ориентированных на GPU, является выбор языка программирования.
Люди знакомы с программированием ИИ-приложений на Python, но «они не понимают, что код на Python на самом деле ничего не делает. Python — это просто фронтенд, чтобы переложить работу на GPU», — отмечает он.
Селлерс считает, что Java лучше других языков программирования подходит для разработки и запуска традиционных корпоративных приложений, требующих высокой степени параллелизма.
Хотя Nvidia предлагает для GPU язык CUDA, при написании традиционных корпоративных приложений, по его мнению, Java — единственный язык программирования, обладающий настоящими векторными возможностями и масштабными возможностями многопоточности. По словам Селлерса, это делает Java лучшим языком для программирования приложений, требующих возможностей параллельных вычислений. Благодаря виртуальной многопоточности, которая появилась в Java 21, стало проще писать, поддерживать и отлаживать высокопроизводительные параллельные приложения.
«Многопоточность, а также векторизация, позволяющая одновременно выполнять более одной компьютерной операции, стали намного лучше за последние несколько выпусков Java», — добавляет он.
Конечно, критически оценивая, как Селлерс превозносит достоинства Java, надо учитывать ассортимент продуктов Azul. Однако в его словах есть одна общая нить, на которую следует обратить внимание лицам, принимающим ИТ-решения. Если предположить, что будущее корпоративных ИТ-систем за нативно-облачной архитектурой (даже если некоторые рабочие нагрузки будут выполняться локально), необходимо признать новую реальность: x86 — это не единственный игрок на поле.