Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 11
А зачем языку go ассемблер от x86, тем более такой экзотический? Неужели так много программистов желают колупаться с ассемблером в вебе?
Помимо инструкций есть не тривиальная задача их расположения и организации вычислений и данных. Вот один из вариантов решения подобных проблем halide-lang.org
Помимо инструкций есть не тривиальная задача их расположения и организации вычислений и данных. Вот один из вариантов решения подобных проблем halide-lang.org
go не одним вебом ограничивается, люди вон софт для видео регистратора писали, да мало ли чего еще…
Неужели так много программистов желают колупаться с ассемблером в вебе?
Нет, их мало и они не совсем веб-разработчики. То, что они делают, потом используют в том числе веб-разработчики.
Ещё одним «пользователем» ассемблера является сам тулчейн.
Можете пробежаться по статье Архитектура ассемблера Go. Разница лишь в том, что нет этапа парсинга.
Ассемблер в Go — одно из промежуточных представлений компилятора (низкоуровневый IR).
Если через 10 лет везде будет AVX-512, то, возможно, вместо 16 векторных регистров он будет использовать 32 (в них float'ы хранятся). Либо у нас будет что-то типа вот этого: GOAMD64 architecture flag и получить преимущества EVEX префикса можно будет значительно раньше.
Может еще cuda префикс добавить? Векторизация это конечно здорово, но не всегда уместно.
Не всегда != никогда.
У Go тулчейна есть задача быть максимально независимым от других утилит, в частности внешних ассемблеров.
Тем более если кому-то векторизация не нужна, он о ней не задумывается.
А в рантайме Go, может быть, даже применение найдётся.
Я сейчас не обязательно про новые «модные» инструкции и 512-битные регистры, к которым у многих есть своё отношение, а про приятные дополнения к предыдущим AVX. Насколько мне известно, положительные эксперименты как минимум в пакетах крипты уже были.
Я не пытаюсь вас переубедить. Просто предоставляю контекст, который может быть полезен и, возможно, ускользнул от вас.
У Go тулчейна есть задача быть максимально независимым от других утилит, в частности внешних ассемблеров.
Тем более если кому-то векторизация не нужна, он о ней не задумывается.
А в рантайме Go, может быть, даже применение найдётся.
Я сейчас не обязательно про новые «модные» инструкции и 512-битные регистры, к которым у многих есть своё отношение, а про приятные дополнения к предыдущим AVX. Насколько мне известно, положительные эксперименты как минимум в пакетах крипты уже были.
Я не пытаюсь вас переубедить. Просто предоставляю контекст, который может быть полезен и, возможно, ускользнул от вас.
У go задача быть языком для ремесленников с низким порогом входа, а не увеличивать скорость вращения сферических коней в вакууме.
Go в том числе в датацентрах используется, а там есть понятие tail latency.
Издержки на него можно сократить, если Go работает быстрее.
Сделать Go быстрее для всех, без надобности учить людей писать более быстрый код можно с помощью ускорения рантайма и улучшения компилятора (например, научить его использовать дополнительные регистры для уменьшения количества spill'ов, правда это немного надуманный пример).
Хуже от того, что Go будет становиться более быстрым и/или потреблять меньше памяти, никому не будет.
Издержки на него можно сократить, если Go работает быстрее.
Сделать Go быстрее для всех, без надобности учить людей писать более быстрый код можно с помощью ускорения рантайма и улучшения компилятора (например, научить его использовать дополнительные регистры для уменьшения количества spill'ов, правда это немного надуманный пример).
Хуже от того, что Go будет становиться более быстрым и/или потреблять меньше памяти, никому не будет.
Быстрый и потребление памяти совершенно не связанные вещи. Современное ПО для решения тех же задач требует на порядки больше ресурсов чем, ПО решавшее эти задачи ранее. Напомню что векторные инструкции предполагают жесткое выравнивание данных, что ведёт к увеличению требуемой памяти.
Если у нас больше регистров, нужно меньше spill'ов в память, если в функции можно обойтись без «локальных слотов» внутри фрейма, фрейм у функции будет меньше или вообще нулевой, тогда при вызовах функции стек будет расти медленнее. Меньше стеки — меньше потребление памяти. Вот это имел в виду выше.
Мне не известны ваши познания в этой теме, но в своих я не настолько уверен, чтобы про все векторные инструкции тут говорить обобщая. Есть специальные инструкции, которые не требуют выравнивания, причём в случае, если данные выровнены, они работают не хуже, чем формы, требующие выравнивания. В Go даже стек, насколько помню, не выровнен…
Можем закрыть эту тему?
Я не понимаю ваших мотивов и того, чего вы хотите.
Очевидно, мои ответы вам не помогают/не нравятся.
Мне не известны ваши познания в этой теме, но в своих я не настолько уверен, чтобы про все векторные инструкции тут говорить обобщая. Есть специальные инструкции, которые не требуют выравнивания, причём в случае, если данные выровнены, они работают не хуже, чем формы, требующие выравнивания. В Go даже стек, насколько помню, не выровнен…
Можем закрыть эту тему?
Я не понимаю ваших мотивов и того, чего вы хотите.
Очевидно, мои ответы вам не помогают/не нравятся.
Оба ассемблера при сборке инструкций, где возможно применить и VEX, и EVEX схемы, используют VEX. Иными словами, VADDPD X1, X2, X3 будет иметь VEX префикс.
А разве смешение VEX и EVEX инструкций не приводит к падению скорости исполнения кода? Что-то там связанное с отделённостью EVEX-конвейера и частотами…
Конкретно пример с
AVX-512 и EVEX может появляться только в новом коде, когда программист сознательно запросил данное поведение (использовал новые регистры или суффиксы опкода).
Способа «переопределить» поведение нет. То есть нельзя попросить тот
VADDPD привёл для подчёркивания того, что старый код будет собираться по-старому, с VEX префиксом. В редких ситуациях EVEX префикс мог бы дать небольшой выигрыш в размере машинного кода за счёт compressed displacement, но для более детерменированного поведения и в том числе для обратной совместимости, выбрана цитируемая вами схема. Плюс тем, кто «без словаря» не помнит всех нюансов, спокойнее (например мне).AVX-512 и EVEX может появляться только в новом коде, когда программист сознательно запросил данное поведение (использовал новые регистры или суффиксы опкода).
Способа «переопределить» поведение нет. То есть нельзя попросить тот
VADDPD кодировать по схеме AVX-512.Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Go 1.11: AVX-512 со вкусом Go