Comments 12
UFO just landed and posted this here
Ассемблер — это весело до тех пор, пока код не в продакшене. Go не для этого. Что, если у вас специфичный набор команд, а процессор древний? Использование Си еще куда ни шло, но asm это беда.
За перевод спасибо!
За перевод спасибо!
Вы правы.
Но бывают исключения:
Во-первых, много частей Go написано на Ассемблере (см. Гитхаб: math, crypto, hash).
Во-вторых, есть примеры на проде у обычных компаний. Например, homm написал цикл статей, где они переделывали резайз изображений, там были ассемблерные вставки (введение, ..., использование SIMD).
Но бывают исключения:
Во-первых, много частей Go написано на Ассемблере (см. Гитхаб: math, crypto, hash).
Во-вторых, есть примеры на проде у обычных компаний. Например, homm написал цикл статей, где они переделывали резайз изображений, там были ассемблерные вставки (введение, ..., использование SIMD).
Си дёргать тоже проблема — затратно, особенно когда много данных ходит. Если изначально известно что будет хай-лоад, имхо, лучше сразу на Си или Спп писать :)
Вот пишите вы ассемблер, отлаживаете, запускаете… А потом оказывается, что запускать его нужно будет на ARM-е каком-нибудь…
И поэтому, всё исходит из задачи. Если мы знаем что код будет написан строго под скайлейк то и пишем асм заточенный для скайлейк, в случаен если таргет имеет широкий спектр то другое дело. И к тому же define никто не отменял. Если вы собираете под старый проц — одни инструкции, под новый — новые молодёжные.
Да, это наверное неплохая идея — написать сначала на нормальном асме, отладить, и только потом портировать на гошный :). Потому что и синтаксис и стиль у гошного ассемблера очень странный.
UFO just landed and posted this here
Какая реализация может быть быстрее? Эталоном будет копирование памяти, которое занимает около 14 мс.
Почему копирование, если на выходе у вас пишется в 4 раза меньше данных, чем читается? Эталоном будет скорость чтения 4х байт данных и записи х байт.
Лучшая оптимизация может заключаться в том, чтобы запускать такие вещи на графическом процессоре, а не на процессоре, потому что графический процессор действительно хорош в этом.
Если скорость выполнения на одном ядре приближается к скорости копирования в памяти, то графический процессор вам точно никак не поможет, потому что скорость шины PCIe 3.0 16x в 2-3 раза ниже скорости памяти.
Ну да, статья явно не для тех, кто пишет приложения с уймой «кнопочек»… А по поводу — «окажется, что надо запустить на ARM...», расскажите это разработчикам FFMPEG и подобных проектов. Хотя я очень сомневаюсь, что Go подходит для подобного.
Sign up to leave a comment.
Самый медленный способ ускорить программу на Go