JEP 438: Vector API (Fifth Incubator)

Аннотация

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

История

Vector API был впервые предложен в JEP 338 и интегрирован в JDK 16 как API в статусе Incubator. Вторая версия Incubator была предложена в JEP 414 и интегрирована в JDK 17. Третья версия Incubator была предложена в JEP 417 и интегрирована в JDK 18. Четвёртая версия Incubator была предложена в JEP 426 и интегрирована в JDK 19.

Этот JEP предлагает снова выпустить API в статусе Incubator в JDK 20 без изменений API по сравнению с JDK 19. Реализация включает небольшой набор исправлений ошибок и улучшений производительности. Этот JEP также уточняет, что согласование с проектом Valhalla — ключевая часть завершения работы над Vector API.

Цели

• Понятный и лаконичный API — API должен позволять понятно и лаконично выражать широкий спектр векторных вычислений, состоящих из последовательностей векторных операций, скомпонованных внутри циклов и, возможно, с управлением потоком выполнения. Должна быть возможность выразить вычисление, обобщённое относительно размера вектора, то есть числа дорожек в векторе, чтобы такие вычисления были переносимы между аппаратными платформами, поддерживающими разные размеры векторов.

• Независимость от платформы — API должен быть независим от архитектуры процессора, чтобы его можно было реализовать на нескольких архитектурах, поддерживающих векторные инструкции. Как обычно в Java API, если оптимизация под платформу и переносимость вступают в противоречие, мы будем отдавать предпочтение переносимости API, даже если из-за этого некоторые платформенно-зависимые идиомы нельзя будет выразить в переносимом коде.

• Надёжная компиляция во время выполнения и производительность на архитектурах x64 и AArch64 — На подходящих архитектурах x64 среда выполнения Java, а именно компилятор HotSpot C2, должна компилировать векторные операции в соответствующие эффективные и производительные векторные инструкции, например поддерживаемые Streaming SIMD Extensions (SSE) и Advanced Vector Extensions (AVX). Разработчики должны быть уверены, что выраженные ими векторные операции будут надёжно и близко отображаться на соответствующие векторные инструкции. Аналогично, на подходящих архитектурах ARM AArch64 C2 будет компилировать векторные операции в векторные инструкции, поддерживаемые NEON и SVE.

• Плавная деградация — Иногда векторное вычисление невозможно полностью выразить во время выполнения в виде последовательности векторных инструкций, например потому, что архитектура не поддерживает некоторые из нужных инструкций. В таких случаях реализация Vector API должна плавно деградировать и продолжать работать. Это может включать выдачу предупреждений, если векторное вычисление не удаётся эффективно скомпилировать в векторные инструкции. На платформах без векторов плавная деградация даст код, сопоставимый по производительности с циклами, развёрнутыми вручную, где коэффициент развёртки равен числу дорожек в выбранном векторе.

• Согласование с проектом Valhalla — долгосрочная цель Vector API — использовать улучшения объектной модели Java из проекта Valhalla. Прежде всего это будет означать превращение нынешних классов, основанных на значениях (value-based classes), в Vector API в Value Classes (классы-значения), чтобы программы могли работать с Value Objects (объекты-значения), т. е. экземплярами классов, у которых нет Identity (идентичность объекта). Соответственно, Vector API будет оставаться в статусе Incubator на протяжении нескольких выпусков, пока необходимые возможности проекта Valhalla не станут доступны как возможности в статусе Preview (предварительная версия). Как только эти возможности Valhalla станут доступны, мы адаптируем Vector API и его реализацию для их использования, а затем переведём сам Vector API в статус Preview-возможности. Подробнее см. разделы о компиляции во время выполнения и о дальнейшей работе.

Что не является целью

• Улучшение существующего алгоритма автовекторизации в HotSpot не является целью.

• Поддержка векторных инструкций на архитектурах процессоров, отличных от x64 и AArch64, не является целью. Однако важно подчеркнуть, как сказано в целях, что API не должен исключать возможность таких реализаций.

• Поддержка компилятора C1 не является целью.

• Гарантия поддержки строгих вычислений с плавающей точкой, которых платформа Java требует для скалярных операций, не является целью. Результаты операций с плавающей точкой над скалярами с плавающей точкой могут отличаться от результатов эквивалентных операций с плавающей точкой над векторами скаляров с плавающей точкой. Все отклонения будут чётко задокументированы. Этот пункт не исключает возможности выражать или контролировать требуемую точность или воспроизводимость векторных вычислений с плавающей точкой.

Мотивация

Векторное вычисление состоит из последовательности операций над векторами. Вектор представляет собой (как правило) фиксированную последовательность скалярных значений, где скалярные значения соответствуют числу векторных дорожек, определённому аппаратурой. Бинарная операция, применённая к двум векторам с одинаковым числом дорожек, для каждой дорожки применяет эквивалентную скалярную операцию к соответствующим двум скалярным значениям из каждого вектора. Обычно это называют Single Instruction Multiple Data (SIMD).

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

HotSpot уже поддерживает автовекторизацию, которая преобразует скалярные операции в операции superword, а те затем отображаются на векторные инструкции. Набор преобразуемых скалярных операций ограничен и, кроме того, неустойчив к изменениям структуры кода. Более того, может использоваться лишь часть доступных векторных инструкций, что ограничивает производительность сгенерированного кода.

Сегодня разработчику, который хочет писать скалярные операции, надёжно преобразуемые в операции superword, нужно понимать алгоритм автовекторизации HotSpot и его ограничения, чтобы добиться надёжной и стабильной производительности. В некоторых случаях написать преобразуемые скалярные операции может оказаться невозможно. Например, HotSpot не преобразует простые скалярные операции вычисления хэш-кода массива (методы Arrays::hashCode), а также не может автоматически векторизовать код лексикографического сравнения двух массивов (поэтому мы добавили интринсик для лексикографического сравнения).

Vector API призван улучшить ситуацию, предоставив способ писать сложные векторные алгоритмы на Java с использованием существующего автовекторизатора HotSpot, но с пользовательской моделью, которая делает векторизацию гораздо более предсказуемой и надёжной. Векторные циклы, написанные вручную, позволяют выразить высокопроизводительные алгоритмы, например векторизованный hashCode или специализированные сравнения массивов, которые автовекторизатор, возможно, никогда не оптимизирует. Этот явный векторный API может принести пользу во многих областях, включая машинное обучение, линейную алгебру, криптографию, финансы и код внутри самого JDK.

Описание

Вектор представлен абстрактным классом Vector<E>. Переменная типа E конкретизируется упакованным типом скалярного примитивного целочисленного или вещественного типа элементов, которые содержит вектор. У вектора также есть форма, определяющая размер вектора в битах. Форма вектора определяет, как экземпляр Vector<E> отображается на аппаратный векторный регистр, когда векторные вычисления компилирует компилятор HotSpot C2. Длина вектора, т. е. число дорожек или элементов, равна размеру вектора, делённому на размер элемента.

Поддерживаемый набор типов элементов (E): Byte, Short, Integer, Long, Float и Double, что соответствует скалярным примитивным типам byte, short, int, long, float и double.

Поддерживаемые формы соответствуют размерам векторов 64, 128, 256 и 512 бит, а также max бит. Форма размером 512 бит может упаковать byte в 64 дорожки или int в 16 дорожек, и вектор такой формы может обрабатывать 64 значения byte или 16 значений int за раз. Форма размером max бит поддерживает максимальный размер вектора текущей архитектуры. Это обеспечивает поддержку платформы ARM SVE, реализации которой могут поддерживать любой фиксированный размер от 128 до 2048 бит с шагом 128 бит.

Мы считаем, что эти простые формы достаточно универсальны, чтобы быть полезными на всех актуальных платформах. Однако по мере экспериментов с будущими платформами, пока этот API находится в статусе Incubator, мы можем дополнительно изменить устройство параметра формы. Такая работа не входит в начальные рамки этого проекта, но эти возможности отчасти определяют нынешнюю роль форм в Vector API. (Подробнее см. раздел о дальнейшей работе ниже.)

Сочетание типа элементов и формы определяет вид (species) вектора, представленный классом VectorSpecies<E>.

Операции над векторами делятся на поэлементные (lane-wise) и междорожечные (cross-lane).

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

• Операция между дорожками применяет операцию ко всему вектору целиком. Операция между дорожками выдаёт либо скаляр, либо вектор, возможно, другой формы. Операции между дорожками далее делятся на операции перестановки и операции свёртки.

Чтобы сократить поверхность API, мы определяем коллективные методы для каждого класса операций. Эти методы принимают на вход константы-операторы; эти константы являются экземплярами класса VectorOperator.Operator и определены в полях static final класса VectorOperators. Для удобства мы определяем специальные методы, которые можно использовать вместо обобщённых, для некоторых распространённых полнофункциональных операций, таких как сложение и умножение.

Некоторые операции над векторами, например преобразование и переинтерпретация, по своей природе меняют форму, т. е. выдают векторы, формы которых отличаются от форм входных данных. Операции, меняющие форму, в векторном вычислении могут негативно сказаться на переносимости и производительности. Поэтому API определяет для каждой операции, меняющей форму, вариант, не зависящий от формы, если это применимо. Для наилучшей производительности разработчикам следует по возможности писать код, не зависящий от формы, с использованием операций, не зависящих от формы. Операции, меняющие форму, помечены как таковые в спецификации API.

Класс Vector<E> объявляет набор методов для распространённых векторных операций, поддерживаемых всеми типами элементов. Для операций, специфичных для типа элементов, существует шесть абстрактных подклассов Vector<E>, по одному для каждого поддерживаемого типа элементов: ByteVector, ShortVector, IntVector, LongVector, FloatVector и DoubleVector. Эти типоспецифичные подклассы определяют дополнительные операции, привязанные к типу элементов, поскольку сигнатура метода ссылается либо на тип элементов, либо на соответствующий тип массива. Примеры таких операций — свёртка (например, суммирование всех дорожек в скалярное значение) и копирование элементов вектора в массив. Эти подклассы также определяют дополнительные полнофункциональные операции, специфичные для целочисленных подтипов (например, побитовые операции, такие как логическое «или»), а также операции, специфичные для типов с плавающей точкой (например, трансцендентные математические функции, такие как возведение в степень).

С точки зрения реализации эти типоспецифичные подклассы Vector<E> дополнительно расширяются конкретными подклассами для разных форм векторов. Эти конкретные подклассы не являются публичными, поскольку нет необходимости предоставлять операции, специфичные для сочетаний типов и форм. Благодаря этому поверхность API сводится к сумме аспектов, а не к их произведению. Экземпляры конкретных классов Vector получаются через фабричные методы, определённые в базовом классе Vector<E> и его типоспецифичных подклассах. Эти фабрики принимают на вход вид нужного экземпляра вектора и создают различные экземпляры, например экземпляр вектора, элементы которого имеют значения по умолчанию (т. е. нулевой вектор), или экземпляр вектора, инициализированный из заданного массива.

Для поддержки управления потоком выполнения некоторые векторные операции могут принимать маски, представленные публичным абстрактным классом VectorMask<E>. Каждый элемент маски — это логическое значение, соответствующее дорожке вектора. Маска выбирает дорожки, к которым применяется операция: операция применяется, если элемент маски для дорожки равен true, а если он равен false, выполняется некоторое альтернативное действие.

Как и в случае векторов, экземпляры VectorMask<E> являются экземплярами непубличных конкретных подклассов, определённых для каждого сочетания типа элементов и длины. Экземпляр VectorMask<E>, используемый в операции, должен иметь тот же тип и ту же длину, что и экземпляры векторов, участвующие в операции. Операции сравнения векторов дают маски, которые затем можно передавать на вход другим операциям, чтобы выборочно работать с определёнными дорожками и тем самым эмулировать поток управления. Маски также можно создавать с помощью статических фабричных методов класса VectorMask<E>.

Мы ожидаем, что маски будут играть важную роль в разработке векторных вычислений, обобщённых по форме. Это ожидание основано на ключевом значении предикатных регистров, эквивалента масок, в ARM Scalable Vector Extensions и в Intel AVX-512.

На таких платформах экземпляр VectorMask<E> отображается на предикатный регистр, а операция, принимающая маску, компилируется в векторную инструкцию, принимающую предикатный регистр. На платформах, которые не поддерживают предикатные регистры, применяется менее эффективный подход: экземпляр VectorMask<E> по возможности отображается на совместимый векторный регистр, а операция, принимающая маску, в общем случае составляется из эквивалентной операции без маски и операции смешивания (blend).

Для поддержки операций перестановки между дорожками некоторые векторные операции принимают перестановки (shuffles), представленные публичным абстрактным классом VectorShuffle<E>. Каждый элемент перестановки — это значение int, соответствующее индексу дорожки. Перестановка — это отображение индексов дорожек, описывающее перемещение элементов дорожек из данного вектора в результирующий вектор.

Как и в случае векторов и масок, экземпляры VectorShuffle<E> являются экземплярами непубличных конкретных подклассов, определённых для каждого сочетания типа элементов и длины. Экземпляр VectorShuffle<E>, используемый в операции, должен иметь тот же тип и ту же длину, что и экземпляры векторов, участвующие в операции.

Пример

Вот простое скалярное вычисление над элементами массивов:

void scalarComputation(float[] a, float[] b, float[] c) {
   for (int i = 0; i < a.length; i++) {
        c[i] = (a[i] * a[i] + b[i] * b[i]) * -1.0f;
   }
}

(Мы предполагаем, что массивы-аргументы имеют одинаковую длину.)

Вот эквивалентное векторное вычисление с использованием Vector API:

static final VectorSpecies<Float> SPECIES = FloatVector.SPECIES_PREFERRED;

void vectorComputation(float[] a, float[] b, float[] c) {
    int i = 0;
    int upperBound = SPECIES.loopBound(a.length);
    for (; i < upperBound; i += SPECIES.length()) {
        // FloatVector va, vb, vc;
        var va = FloatVector.fromArray(SPECIES, a, i);
        var vb = FloatVector.fromArray(SPECIES, b, i);
        var vc = va.mul(va)
                   .add(vb.mul(vb))
                   .neg();
        vc.intoArray(c, i);
    }
    for (; i < a.length; i++) {
        c[i] = (a[i] * a[i] + b[i] * b[i]) * -1.0f;
    }
}

Сначала мы получаем из FloatVector предпочтительный вид (species), форма которого оптимальна для текущей архитектуры. Мы сохраняем его в поле static final, чтобы компилятор времени выполнения рассматривал значение как константу и поэтому мог лучше оптимизировать векторное вычисление. Затем основной цикл проходит по входным массивам с шагом, равным длине вектора, то есть длине вида. Он загружает векторы float заданного вида из массивов a и b по соответствующему индексу, последовательно выполняет арифметические операции, а затем сохраняет результат в массив c. Если после последней итерации остаются элементы массива, результаты для этих хвостовых элементов вычисляются обычным скалярным циклом.

Эта реализация обеспечивает оптимальную производительность на больших массивах. Компилятор HotSpot C2 на процессоре Intel x64 с поддержкой AVX генерирует машинный код, похожий на следующий:

0.43%  / │  0x0000000113d43890: vmovdqu 0x10(%r8,%rbx,4),%ymm0
  7.38%  │ │  0x0000000113d43897: vmovdqu 0x10(%r10,%rbx,4),%ymm1
  8.70%  │ │  0x0000000113d4389e: vmulps %ymm0,%ymm0,%ymm0
  5.60%  │ │  0x0000000113d438a2: vmulps %ymm1,%ymm1,%ymm1
 13.16%  │ │  0x0000000113d438a6: vaddps %ymm0,%ymm1,%ymm0
 21.86%  │ │  0x0000000113d438aa: vxorps -0x7ad76b2(%rip),%ymm0,%ymm0
  7.66%  │ │  0x0000000113d438b2: vmovdqu %ymm0,0x10(%r9,%rbx,4)
 26.20%  │ │  0x0000000113d438b9: add    $0x8,%ebx
  6.44%  │ │  0x0000000113d438bc: cmp    %r11d,%ebx
         \ │  0x0000000113d438bf: jl     0x0000000113d43890

Это вывод микробенчмарка JMH для приведённого выше кода, полученный с прототипом Vector API и реализацией из ветки vectorIntrinsics репозитория разработки проекта Panama. Эти горячие участки сгенерированного машинного кода наглядно показывают трансляцию в векторные регистры и векторные инструкции. Мы отключили развёртывание циклов (опцией HotSpot -XX:LoopUnrollLimit=0), чтобы трансляция была нагляднее; иначе HotSpot развернул бы этот код с помощью существующих оптимизаций циклов C2. Все выделения памяти под объекты Java устранены.

(HotSpot способен автоматически векторизовать скалярное вычисление в этом конкретном примере и сгенерирует похожую последовательность векторных инструкций. Главное отличие в том, что автовекторизатор генерирует для умножения на -1.0f векторную инструкцию умножения, тогда как реализация Vector API генерирует векторную инструкцию XOR, которая инвертирует знаковый бит. Однако главная цель этого примера — представить Vector API и показать, как его реализация генерирует векторные инструкции, а не сравнить его с автовекторизатором.)

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

void vectorComputation(float[] a, float[] b, float[] c) {
    for (int i = 0; i < a.length; i += SPECIES.length()) {
        // VectorMask<Float>  m;
        var m = SPECIES.indexInRange(i, a.length);
        // FloatVector va, vb, vc;
        var va = FloatVector.fromArray(SPECIES, a, i, m);
        var vb = FloatVector.fromArray(SPECIES, b, i, m);
        var vc = va.mul(va)
                   .add(vb.mul(vb))
                   .neg();
        vc.intoArray(c, i, m);
    }
}

В теле цикла мы получаем зависящую от цикла маску, которая передаётся операциям загрузки и сохранения. Когда i < SPECIES.loopBound(a.length), маска m объявляет все дорожки установленными. На последней итерации цикла, когда SPECIES.loopBound(a.length) <= i < a.length и (a.length - i) <= SPECIES.length(), маска может объявлять суффикс неустановленных дорожек. Операции загрузки и сохранения не выбросят исключений выхода за границы, поскольку маска не допускает доступа к массиву за пределами его длины.

Мы бы предпочли, чтобы разработчики писали в таком стиле для всех поддерживаемых платформ и получали оптимальную производительность, но сегодня на платформах без предикатных регистров такой подход не оптимален. Теоретически компилятор C2 можно было бы улучшить так, чтобы он преобразовывал цикл, отделяя последнюю итерацию и удаляя маску из тела цикла. Это остаётся областью для дальнейших исследований.

Компиляция во время выполнения

У Vector API две реализации. Первая реализует операции на Java, поэтому она функциональна, но не оптимальна. Вторая определяет внутренние (intrinsic) векторные операции для компилятора времени выполнения HotSpot C2, чтобы он мог компилировать векторные вычисления в соответствующие аппаратные регистры и векторные инструкции, когда они доступны.

Чтобы избежать взрывного роста числа интринсиков C2, мы определяем обобщённые интринсики, соответствующие различным типам операций, например унарным, бинарным, преобразованиям и так далее, которые принимают параметр, описывающий конкретную выполняемую операцию. Интринсификацию всего API поддерживают около двадцати новых интринсиков.

Мы ожидаем, что в итоге объявим векторные классы как Value Classes, как предлагает проект Valhalla (см. Value Objects и JEP 401 (Primitive Classes)). Пока же Vector<E> и его подклассы считаются value-based classes, поэтому следует избегать операций над их экземплярами, зависящих от Identity. Хотя экземпляры векторов абстрактно состоят из элементов в дорожках, C2 не скаляризует эти элементы — значение вектора рассматривается как единое целое, подобно int или long, которое отображается на векторный регистр соответствующего размера. C2 обрабатывает экземпляры векторов особым образом, чтобы обойти ограничения escape-анализа и избежать упаковки (boxing). В будущем мы согласуем эту особую обработку с Value Objects проекта Valhalla.

Интринсики Intel SVML для трансцендентных операций

Vector API поддерживает трансцендентные и тригонометрические поэлементные (lanewise) операции над векторами с плавающей точкой. На x64 мы используем Intel Short Vector Math Library (SVML), чтобы предоставить оптимизированные внутренние реализации таких операций. Внутренние операции обладают теми же численными свойствами, что и соответствующие скалярные операции, определённые в java.lang.Math.

Исходные файлы на ассемблере для операций SVML находятся в исходном коде модуля jdk.incubator.vector, в каталогах для конкретных ОС. Процесс сборки JDK компилирует эти исходные файлы для целевой операционной системы в разделяемую библиотеку, специфичную для SVML. Эта библиотека довольно большая: её размер чуть меньше мегабайта. Если образ JDK, собранный с помощью jlink, не включает модуль jdk.incubator.vector, библиотека SVML в образ не копируется.

Пока реализация поддерживает только Linux и Windows. Поддержку macOS мы рассмотрим позже, поскольку подготовка исходных файлов на ассемблере с нужными директивами требует немалой работы.

Среда выполнения HotSpot попытается загрузить библиотеку SVML и, если она есть, привязать операции из библиотеки SVML к именованным подпрограммам-заглушкам (stub routines). Компилятор C2 генерирует код, вызывающий соответствующую подпрограмму-заглушку в зависимости от операции и вида вектора (то есть типа элементов и формы).

В будущем, если проект Panama расширит поддержку нативных соглашений о вызовах на векторные значения, реализация Vector API, возможно, сможет загружать библиотеку SVML из внешнего источника. Если такой подход не повлияет на производительность, включать SVML в виде исходного кода и встраивать её в сборку JDK больше не понадобится. До тех пор мы считаем описанный выше подход приемлемым, учитывая возможный выигрыш в производительности.

Дальнейшая работа

• Как упоминалось выше, мы ожидаем, что в итоге объявим векторные классы как Value Classes. О текущей работе по согласованию Vector API с Valhalla см. ветку lworld+vector репозитория кода проекта Valhalla. Кроме того, мы ожидаем использовать обобщённую специализацию (generic specialization) Value Classes из проекта Valhalla, чтобы экземпляры Vector<E> были Value Objects, где E — примитивный класс, например int, а не его класс-обёртка Integer. Подтипы Vector<E> для конкретных типов, например IntVector, могут оказаться ненужными, когда появится обобщённая специализация по примитивным классам.

• Мы можем добавить поддержку векторов значений IEEE с плавающей точкой формата binary16 (значений float16). Это тоже зависит от проекта Valhalla: потребуется представлять значения float16 как Value Objects и улучшить реализацию Vector API, чтобы она использовала аппаратные векторные инструкции для векторов значений float16. Исследовательскую работу см. в ветке vectorIntrinsics+fp16 репозитория кода Vector API проекта Panama.

• Мы рассчитываем улучшить реализацию, чтобы лучше оптимизировать циклы, содержащие векторизованный код, и в целом постепенно повышать производительность со временем.

• Мы также рассчитываем улучшить комбинаторные модульные тесты, чтобы они проверяли, что C2 генерирует аппаратные векторные инструкции. Сейчас модульные тесты без проверки предполагают, что многократного выполнения достаточно, чтобы C2 сгенерировал аппаратные векторные инструкции. Мы изучим возможность использовать IR Test Framework компилятора C2, чтобы кросс-платформенно проверять наличие векторных узлов в IR-графе (например, с помощью сопоставления с регулярными выражениями). Если этот подход окажется проблематичным, мы можем рассмотреть простейший подход, использующий флаг -XX:+TraceNewVectors, доступный только в непродуктовых сборках, для вывода векторных узлов.

• Мы оценим возможность определения синтетических форм векторов, чтобы лучше управлять развёртыванием циклов и матричными операциями, и рассмотрим подходящую поддержку алгоритмов сортировки и синтаксического разбора. (Подробнее см. эту презентацию.)

Альтернативы

Альтернативный подход — автовекторизация в HotSpot, но она потребовала бы значительной работы. Более того, она всё равно оставалась бы хрупкой и ограниченной по сравнению с Vector API, поскольку автовекторизацию при сложном потоке управления выполнить очень трудно.

В целом, даже после десятилетий исследований — особенно для циклов по массивам в FORTRAN и C — похоже, что автовекторизация скалярного кода не является надёжной тактикой оптимизации произвольных циклов, написанных пользователем, если только пользователь не уделяет необычайно пристального внимания неписаным контрактам о том, какие именно циклы компилятор готов автовекторизовать. Слишком легко написать цикл, который не автовекторизуется по причине, которую не сможет обнаружить ни один человек, читающий код. Годы работы над автовекторизацией, даже в HotSpot, оставили нам много механизмов оптимизации, которые работают лишь в особых случаях. Мы хотим пользоваться этими механизмами чаще!

Тестирование

Мы разработаем комбинаторные модульные тесты, чтобы обеспечить покрытие всех операций для всех поддерживаемых типов и форм на различных наборах данных.

Мы также разработаем тесты производительности, чтобы убедиться, что цели по производительности достигнуты, а векторные вычисления эффективно отображаются на векторные инструкции. Скорее всего, это будут микробенчмарки JMH, но потребуются и более реалистичные примеры полезных алгоритмов. Поначалу такие тесты могут находиться в отдельном репозитории проекта. Учитывая количество тестов и способ их генерации, перед интеграцией в основной репозиторий их, вероятно, потребуется отобрать и привести в порядок.

Риски и допущения

• Есть риск, что API будет смещён в сторону функциональности SIMD, поддерживаемой на архитектурах x64, но этот риск снижается благодаря поддержке AArch64. Это касается в основном явно фиксированного набора поддерживаемых форм, который мешает писать алгоритмы в обобщённом по форме стиле. Мы считаем, что большинство остальных операций Vector API ориентированы на переносимые алгоритмы. Чтобы снизить этот риск, мы учтём и другие архитектуры, в частности архитектуру ARM Scalar Vector Extension, модель программирования которой динамически подстраивается под единственную фиксированную форму, поддерживаемую оборудованием. Мы приветствуем и поощряем участие в этой работе участников OpenJDK, которые работают над специфичными для ARM частями HotSpot.

• Vector API использует типы-обёртки (например, Integer) как заместители примитивных типов (например, int). Это решение вынужденное: его диктуют текущие ограничения обобщённых типов (generics) Java, плохо совместимых с примитивными типами. Когда проект Valhalla в итоге добавит более мощные generics, текущее решение будет выглядеть неудобным и, скорее всего, его придётся изменить. Мы предполагаем, что такие изменения будут возможны без чрезмерной обратной несовместимости.