Комментарии 8
Есть проект (не особо живой, правда, на вид) по использованию SIMD инструкций для ARM Neon через cgo.
Как оцените такой подход? По сравнению с изложенным в статье.
Поправьте если я не так понял:
Существует язык Go, в нём по сути ничего кроме span нет, но при этом функции span очень неоптимизированные, потому что разработчики решили написать именно свой компилятор, а в нём не осилили поддержку множества архитектур и поэтому сделали некий go-байткод, который позже видимо компилируется в какой-то С код и только потом в ассемблер и бинарь или типа того
В этом go байт коде они впринципе проигнорировали наличие регистров и тд, ведь это сложно реализовать
При этом они переписали свой компилятор с С++ не на C++ с поддержкой llvm, а на Go и потратили на это немало сил и времени
Какой-то несвязный поток сознания у вас вышел, но давайте разберемся. Го-байткод он же IR это нормальная практика для большинства современных языков. Разделение на фронтенд(Лексер языка, генерация IR) и бекенд(генерация машинного кода и в том числе работа с регистрами) позволяет относительно быстро добавлять новые архитектуры и платформы. От LLVM отказались мне кажется намеренно, т.к. один из краеугольных камней Го - быстрая компиляция по сравнению с Си и переезд на LLVM кратно, а может быть и в десятки раз увеличил бы время сборки.
Байт код и ir это разные вещи, на ir проводятся оптимизации и дальше бекенд преобразует его в ассемблер, а байт-код потом исполняется на интерпретаторе или транслируется в С который позже преобразуется в бинарь ( лично я считаю единственным верным способом компилировать Go это перевести его в С и запустить clang)
C невероятно быстро компилируется, нет никаких доказательств, что Go компилируется за сравнимое время
Было бы интересно сравнить с cgo + intrinsic, рукам такой код писать будет долго
Часть 1. Почему Go-ассемблер и векторизация могут быть полезны: идея для ускорения