Comments 8
FloatVector.SPECIES_128 - странное название. Почему не FloatVector.128_bit?
Далее, почему final SPECIES_FLOAT - большими буквами, а другие final - нет?
Унылое наследие пишущих на си. Сначала все эти фокусы с видеокартами проделывают именно на си, потому что проще, а потом, когда выгода темы становится очевидной, все остальные бросаются внедрять у себя копию. Именно копию. Потому что с нуля считается некомильфо (и в большинстве случаев это верно). Ну а с копией приходит и унылый стиль из языка, где нет энумов (или зубры ими никогда не пользуются), где есть традиции всё писать большими буквfми через подчёркивание, ну и где много чего вообще странного с точки зрения Java.
FloatVector.SPECIES_128 — странное название. Почему не FloatVector.128_bit?
Далее, почему final SPECIES_FLOAT — большими буквами, а другие final — нет?
А почему бы и нет? У вас какие-то принципиальные возражения?
Ладно, может, там много всяких вариантов для 128 бит и термин species уже устоялся.
А почему бы и нет? У вас какие-то принципиальные возражения?
Только одно - единообразие в именовании.
Исторически сложилось так, что в Java нет такого понятия как константа (а я подозреваю что именно это вы имеете в виду, говоря про использование uppercase).
Общепринято (еще раз, это не требование) использовать модификаторы static final для обозначения "константы".
Как вы можете заметить, в данном случае есть только final.
И использовал uppercase для SPECIES_FLOAT я умышленно.
Почему не FloatVector.128_bit
Как минимум потому, что спецификация языка прямо запрещает использовать идентификаторы, начинающиеся не с Java-символа.
Именно поэтому разница не такая впечатляющая.
разница скорее из-за того, что пока там ещё не всё готово. переписал https://github.com/Mark-Kovalyov/CardRaytracerBenchmark на это апи и вместо 10 сек код выполняется 40. что под 17 что 19-ой java, хотя в последней обещали какие-то улучшения. в принципе надо учитывать, что процессор супер скалаярный, он и без simd умеет умножать/складывать параллельно, по 3-4 инструкции минимум, а тут ещё какая-то обвязка в виде объектов, которые надо чистить. хотя конечно gc в моём случаи работал наверно только 1 сек из 40. но всё равно, не на такие результаты я расчитывал, переделывая код, причём он на 100% использует новое api.
и вместо 10 сек код выполняется 40
У меня было похожее замедление при бенчмарке совсем небольших массивов (в районе 1-2 сотен).
Подозреваю, что оверхед на загрузку модуля и вызов апи таким вот способом довольно дорогой.
По поводу улучшений в 19:
Improvements to the API proposed for JDK 19 include enhancements to load and store vectors to and from MemorySegments, as defined by the Foreign Function and Memory API preview. JDK 19 would also add two cross-lane vector operations, compress and expand, together with a complementary vector mask compress operation.
In another addition to the vector API, bitwise integral lanewise operations would be expanded, including operations such counting the number of one bits, reversing the order of bits, and compressing and expanding bits.
Т.е. ничего что могло бы повлиять на скорость в сабжевом случае.
Vector API в Java: краткий обзор и тестирование