Самый медленный способ ускорить программу на Go

[@akamajoris]

Ассемблер — это весело до тех пор, пока код не в продакшене. Go не для этого. Что, если у вас специфичный набор команд, а процессор древний? Использование Си еще куда ни шло, но asm это беда.
За перевод спасибо!

[@win0err]

Вы правы.

Но бывают исключения:
Во-первых, много частей Go написано на Ассемблере (см. Гитхаб: math, crypto, hash).
Во-вторых, есть примеры на проде у обычных компаний. Например, homm написал цикл статей, где они переделывали резайз изображений, там были ассемблерные вставки (введение, ..., использование SIMD).

[@homm]

Справедливости ради, не ассемблерные вставки а интринсики — специальные архитеркутрно-зависимые функции в Си, почти всегда 1-в-1 транслируемые в конкретные инструкции процессора.

[@kozyabka]

Си дёргать тоже проблема — затратно, особенно когда много данных ходит. Если изначально известно что будет хай-лоад, имхо, лучше сразу на Си или Спп писать :)

[@win0err]

Да, я потестил. Получается медленней, чем писать на Гошном асме. Но это логично, поэтому не стал даже упоминать об этом в статье

[@a-tk]

Вот пишите вы ассемблер, отлаживаете, запускаете… А потом оказывается, что запускать его нужно будет на ARM-е каком-нибудь…

[@kozyabka]

И поэтому, всё исходит из задачи. Если мы знаем что код будет написан строго под скайлейк то и пишем асм заточенный для скайлейк, в случаен если таргет имеет широкий спектр то другое дело. И к тому же define никто не отменял. Если вы собираете под старый проц — одни инструкции, под новый — новые молодёжные.

[@youROCK]

Да, это наверное неплохая идея — написать сначала на нормальном асме, отладить, и только потом портировать на гошный :). Потому что и синтаксис и стиль у гошного ассемблера очень странный.

[@homm]

Какая реализация может быть быстрее? Эталоном будет копирование памяти, которое занимает около 14 мс.

Почему копирование, если на выходе у вас пишется в 4 раза меньше данных, чем читается? Эталоном будет скорость чтения 4х байт данных и записи х байт.

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

Если скорость выполнения на одном ядре приближается к скорости копирования в памяти, то графический процессор вам точно никак не поможет, потому что скорость шины PCIe 3.0 16x в 2-3 раза ниже скорости памяти.

[@iga2iga]

Ну да, статья явно не для тех, кто пишет приложения с уймой «кнопочек»… А по поводу — «окажется, что надо запустить на ARM...», расскажите это разработчикам FFMPEG и подобных проектов. Хотя я очень сомневаюсь, что Go подходит для подобного.