Почему вы программируете на сборке? [закрыто]

У меня есть вопрос ко всем хардкорным хакерам низкого уровня. Я наткнулся на это предложение в блоге. Я действительно не думаю, что источник имеет значение (это Хаак, если вам действительно интересно), потому что это, кажется, обычное утверждение.

Например, во многих современных трехмерных играх высокопроизводительный основной движок написан на C ++ и ассемблере.

Что касается сборки - это код, написанный на сборке, потому что вы не хотите, чтобы компилятор испускал дополнительные инструкции или использовал чрезмерное количество байтов, или вы используете лучшие алгоритмы, которые вы не можете выразить на C (или не можете выразить без компилятор их смешивает)?

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

Я думаю, вы неправильно истолковываете это заявление:

Например, во многих современных трехмерных играх высокопроизводительный основной движок написан на C ++ и ассемблере.

Игры (и большинство программ в наши дни) не «написаны на ассемблере» так, как они «написаны на C ++». В этом блоге не говорится, что значительная часть игры разрабатывается на ассемблере или что команда программистов сидит и разрабатывает на ассемблере в качестве основного языка.

На самом деле это означает, что разработчики сначала пишут игру и заставляют ее работать на C ++. Затем они профилируют его, выясняют, в чем заключаются узкие места, и, если это имеет смысл, оптимизируют их при сборке. Или, если они уже имеют опыт, они знают, какие части будут узкими местами, и у них есть оптимизированные части из других игр, которые они создали.

Точка программирования в сборе так же , как это всегда было: скорость . Было бы нелепо писать много кода на ассемблере, но есть некоторые оптимизации, о которых компилятор не знает, и для достаточно маленького окна кода человек сделает лучше.

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

Вот еще несколько подходящих примеров:

Примеры из игр

• Статья от Intel об оптимизации игрового движка с помощью встроенных функций SSE. В окончательном коде используются встроенные функции (а не встроенный ассемблер), поэтому объем чистой сборки очень мал. Но они смотрят на вывод ассемблера компилятором, чтобы точно определить, что нужно оптимизировать.

• Быстрый обратный квадратный корень из Quake . Опять же, в подпрограмме нет ассемблера, но вам нужно кое-что знать об архитектуре, чтобы провести такую ​​оптимизацию. Авторы знают, какие операции быстрые (умножение, сдвиг), а какие медленные (деление, sqrt). Таким образом, они придумали очень сложную реализацию квадратного корня, полностью избегающую медленных операций.

Высокопроизводительные вычисления

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

  Прекрасным недавним примером этого является Квантовая Хромодинамика Решетки (Решетка КХД) . В данной статье описывается , как эта проблема в значительной степени сводится к одной очень маленькому вычислительному ядру, который был оптимизирован в большой степени для PowerPC 440 на с IBM Blue Gene / L . Каждый 440 имеет два FPU, и они поддерживают некоторые специальные тернарные операции, которые сложно использовать компиляторам. Без этих оптимизаций Lattice QCD работал бы намного медленнее, что дорого обходится, когда ваша проблема требует миллионов часов процессора на дорогих машинах.

  Если вам интересно, почему это важно, ознакомьтесь со статьей в Science, которая появилась в результате этой работы. Используя решеточную КХД, эти ребята рассчитали массу протона из первых принципов и в прошлом году показали, что 90% массы приходится на энергию сильной связи, а остальное - на кварки. Это E = mc ² в действии. Вот резюме .

Для всего вышеперечисленного приложения не разрабатываются и не пишутся на 100% на ассемблере - даже близко. Но когда людям действительно нужна скорость, они сосредотачиваются на написании ключевых частей своего кода для работы на определенном оборудовании.

Я не занимаюсь программированием на ассемблере много лет, но могу назвать несколько причин, которые часто видел:

• Не все компиляторы могут использовать определенные оптимизации ЦП и набор инструкций (например, новые наборы инструкций, которые Intel время от времени добавляет). Ожидание, пока разработчики компилятора наверстают упущенное, означает потерю конкурентного преимущества.

• Легче сопоставить реальный код с известной архитектурой ЦП и оптимизацией. Например, то, что вы знаете о механизме выборки, кешировании и т. Д. Предполагается, что это должно быть прозрачно для разработчика, но на самом деле это не так, поэтому разработчики компилятора могут оптимизировать.

• Доступ к определенному аппаратному уровню возможен / практически возможен только через язык ассемблера (например, при написании драйвера устройства).

• Формальные рассуждения иногда проще для языка ассемблера, чем для языка высокого уровня, поскольку вы уже знаете, какова окончательная или почти окончательная структура кода.

• Программирование некоторых трехмерных графических карт (примерно конец 1990-х годов) в отсутствие API-интерфейсов часто было более практичным и эффективным на языке ассемблера, а иногда невозможно на других языках. Но, опять же, это были игры действительно экспертного уровня, основанные на архитектуре ускорителя, например, ручное перемещение данных в определенном порядке и обратно.

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

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

Обычно сборка непрофессионала выполняется медленнее, чем C (из-за оптимизации C), но многие игры (я отчетливо помню, как Doom ) должны были иметь определенные разделы игры в Assembly, чтобы она могла работать без проблем на обычных машинах.

Вот пример, о котором я говорю.

Я начал профессиональное программирование на ассемблере на самой первой работе (80-е годы). Для встроенных систем требования к памяти - RAM и EPROM - были низкими. Вы можете написать жесткий код, не требующий больших ресурсов.

К концу 80-х я перешел на C. Код было проще писать, отлаживать и поддерживать. На ассемблере были написаны очень маленькие фрагменты кода - для меня это было тогда, когда я писал переключение контекста в RTOS, которую можно использовать самостоятельно. (То, что вам больше не следует делать, если это не «научный проект».)

Вы увидите фрагменты ассемблера в некотором коде ядра Linux. Совсем недавно я просматривал его в спин-блокировках и другом коде синхронизации. Эти фрагменты кода должны получать доступ к атомарным операциям проверки и установки, манипулированию кешами и т. Д.

Я думаю, вам будет сложно оптимизировать современные компиляторы C для большинства общих программ.

Я согласен с @altCognito, что вам, вероятно, лучше потратить время на размышления о проблеме и улучшение работы. По какой-то причине программисты часто сосредотачиваются на микроэффективности и пренебрегают макроэффективностью. Ассемблер для повышения производительности - это микроэффективность. Отступление назад для более широкого обзора системы может выявить макро-проблемы в системе. Решение макро-проблем часто может дать лучший прирост производительности. Как только макропроблемы решены, рушится до микроуровня.

Я полагаю, что микропроблемы находятся под контролем одного программиста и в меньшей области. Изменение поведения на макроуровне требует общения с большим количеством людей, чего избегают некоторые программисты. Ковбой против команды.

"Да". Но поймите, что по большей части преимущества написания кода на ассемблере не стоят затраченных усилий. Возврат, полученный за написание этого на ассемблере, как правило, меньше, чем просто сосредоточение внимания на том, чтобы больше думать о проблеме и тратить свое время на размышления о том, как лучше делать вещи.

Джон Кармак и Майкл Абраш, которые в значительной степени отвечали за написание Quake и всего высокопроизводительного кода, входящего в игровые движки ID, подробно рассказывают об этом в этой книге .

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

В наши дни, по крайней мере, для последовательных кодов, достойный компилятор почти всегда превосходит даже опытного программиста на ассемблере. Но для векторных кодов это отдельная история. Широко распространенные компиляторы не справляются с такой большой задачей, используя, например, векторно-параллельные возможности модуля x86 SSE. Я пишу компилятор, и использование SSE возглавляет мой список причин, по которым я должен работать самостоятельно, вместо того, чтобы доверять компилятору.

Код SSE лучше работает в сборке, чем встроенные функции компилятора, по крайней мере, в MSVC. (т.е. не создает лишних копий данных)

У меня в исходных кодах на работе три или четыре ассемблерных подпрограммы (примерно в 20 МБ исходного кода). Все они являются SSE (2) и связаны с операциями с изображениями (довольно большими - подумайте, 2400x2048 и больше).

Для хобби работаю над компилятором, а там еще ассемблер. Библиотеки времени выполнения довольно часто полны ими, большинство из них связано с вещами, которые бросают вызов нормальному процедурному режиму (например, помощники для исключений и т. Д.)

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

Если вы действительно не поставите 100000 устройств, а программный ассемблер позволит действительно значительно сэкономить, просто поместив во флэш-чип меньшую категорию. Но я не из этой категории.

Многие люди думают, что встраивание - это оправдание для ассемблера, но их контроллеры имеют большую мощность процессора, чем машины, на которых была разработана Unix . (Microchip поставляется с микроконтроллерами на 40 и 60 MIPS по цене менее 10 долларов США ).

Однако многие люди застряли с наследием, поскольку изменить архитектуру микрочипа непросто. Также код HLL очень зависит от архитектуры (потому что он использует аппаратную периферию, регистры для управления вводом-выводом и т. Д.). Так что иногда есть веские причины продолжать поддерживать проект на ассемблере (мне повезло, что я смог настроить дела на новой архитектуре с нуля). Но часто люди обманывают себя тем, что им действительно нужен ассемблер.

Мне все еще нравится ответ, который дал профессор, когда мы спросили, можем ли мы использовать GOTO (но вы также можете прочитать это как ASSEMBLER): «если вы считаете, что стоит написать трехстраничное эссе о том, зачем вам эта функция, вы можете ее использовать . Пожалуйста, отправьте эссе со своими результатами ".

Я использовал это как руководящий принцип для низкоуровневых функций. Не стесняйтесь его использовать, но убедитесь, что вы правильно его мотивируете. Даже поставьте пару искусственных барьеров (например, в эссе), чтобы избежать запутанных рассуждений в качестве оправдания.

Некоторые инструкции / флаги / элементы управления просто отсутствуют на уровне C.

Например, проверка переполнения на x86 - это простой флаг переполнения. Эта опция недоступна в C.

Дефекты, как правило, выполняются построчно (оператор, код и т. Д.); Хотя верно то, что для большинства проблем сборка будет использовать гораздо больше строк, чем языки более высокого уровня, иногда бывают случаи, когда это лучшее (наиболее краткое, наименьшее количество строк) соответствует рассматриваемой проблеме. Большинство из этих случаев связаны с обычными подозреваемыми, такими как драйверы и бит-бэнг во встроенных системах.

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

Помимо прочего, все высшие языки имеют определенные ограничения. Вот почему некоторые люди предпочитают программировать в ASM, чтобы иметь полный контроль над своим кодом.

Другим нравятся очень маленькие исполняемые файлы, в диапазоне 20-60 КБ, например, проверьте HiEditor , который реализован автором элемента управления HiEdit, превосходный мощный элемент управления редактированием для Windows с подсветкой синтаксиса и вкладками всего лишь ~ 50 КБ). В моей коллекции более 20 таких золотых элементов управления от Excell, таких как ssheets на html-рендеры.

Я думаю, что многие разработчики игр были бы удивлены этой информацией.

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

Эта цитата является чрезмерно обобщенной и далеко не такой верной, как десять лет назад.

Но эй, простые факты не должны препятствовать настоящему крестовому походу хакеров в пользу сборки. ;)

Если вы программируете 8-битный микроконтроллер низкого уровня со 128 байтами ОЗУ и 4 КБ программной памяти, у вас нет особого выбора при использовании сборки. Однако иногда при использовании более мощного микроконтроллера вам нужно, чтобы определенное действие произошло в точное время. Тогда пригодится язык ассемблера, поскольку вы можете подсчитывать инструкции и таким образом измерять тактовые циклы, используемые вашим кодом.

Если бы вы были рядом со всеми усилиями по исправлению проблемы 2000 года, вы могли бы заработать много денег, если бы знали Assembly. В нем по-прежнему написано много унаследованного кода, и этот код иногда требует обслуживания.

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

В некоторых случаях все, что действительно требуется, - это заменить какую-либо языковую конструкцию инструкцией, которую оптимизатор не может понять, как использовать. Типичный пример - в приложениях DSP, где векторные операции и операции умножения-накопления трудно обнаружить оптимизатору, но легко обработать код.

Например, некоторые модели SH4 содержат матрицу 4x4 и 4 векторные инструкции. Я увидел огромное улучшение производительности в алгоритме коррекции цвета, заменив эквивалентные операции C на матрице 3x3 соответствующими инструкциями, с небольшими затратами на увеличение матрицы коррекции до 4x4, чтобы соответствовать предположению оборудования. Это было достигнуто путем написания не более дюжины строк сборки и внесения соответствующих корректировок в соответствующие типы данных и хранилище в горстку мест окружающего кода C.

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

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

Почти каждый средний и крупный игровой движок или библиотека, которые я видел до сих пор, имеет несколько оптимизированных вручную версий сборки, доступных для матричных операций, таких как конкатенация матриц 4x4. Кажется, что компиляторы неизбежно упускают из виду некоторые умные оптимизации (повторное использование регистров, развертывание циклов максимально эффективным способом, использование машинно-зависимых инструкций и т. Д.) При работе с большими матрицами. Эти функции управления матрицей также почти всегда являются «горячими точками» профиля.

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

Наконец, если у вас есть подпрограммы обслуживания прерываний, asm может иметь решающее значение в мире - есть определенные операции, которые вы просто не хотите выполнять при прерывании, и вы хотите, чтобы ваши обработчики прерываний «входили и выходили быстро». ... вы почти точно знаете , что произойдет в вашем ISR, если он в asm, и это побуждает вас не допускать никаких черт (что в любом случае является хорошей практикой).

Игры довольно жадны по производительности, и хотя в то же время оптимизаторы довольно хороши, «мастер-программист» все же может добиться большей производительности, вручную кодируя нужные части в сборке.

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

Я лично поговорил только с одним разработчиком о том, как он использует сборку. Он работал над прошивкой, которая касалась управления портативным mp3-плеером. Работа по сборке преследовала 2 цели:

1. Скорость: задержки должны быть минимальными.
2. Стоимость: при минимальном коде оборудование, необходимое для его запуска, может быть немного менее мощным. При массовом производстве миллионов единиц это может накапливаться.

Единственное, что я продолжаю писать на ассемблере, - это встроенное оборудование с ограниченными ресурсами. Как отмечает Леандер, сборка по-прежнему хорошо подходит для ISR, где код должен быть быстрым и хорошо понятным.

Вторая причина для меня - сохранить функциональные знания сборки. Возможность изучить и понять шаги, предпринимаемые ЦП для выполнения моих приказов, просто приятно.

В последний раз, когда я писал на ассемблере, мне не удавалось убедить компилятор сгенерировать свободный от libc, позиционно-независимый код.

В следующий раз, вероятно, будет по той же причине.

Конечно, раньше были и другие причины .

Многие люди любят очернять ассемблер, потому что они никогда не учились кодировать на нем, лишь смутно сталкивались с ним, и это их либо ошеломило, либо несколько запугало. Настоящие талантливые программисты поймут, что бессмысленно критиковать C или Assembly, потому что они дополняют друг друга. на самом деле преимущество одного - недостаток другого. Организованные синтаксические правила C улучшают ясность, но в то же время отказываются от всей мощи сборки, которая не содержит каких-либо структурных правил! Инструкции кода C созданы для создания неблокирующего кода, который, как можно утверждать, усиливает ясность замысла программирования, но это потеря мощности. В C компилятор не допускает перехода внутри if / elseif / else / end. Или вам не разрешено писать два цикла for / end для разных переменных, которые перекрывают друг друга, вы не можете писать самомодифицирующийся код (или не можете легко и просто) и т. д. Обычные программисты напуганы вышесказанным и не имеют ни малейшего представления о том, как даже использовать силу этих подходов, поскольку они были воспитаны для следования общепринятым правилам . Вот правда: сегодня у нас есть машина с вычислительной мощностью, чтобы делать гораздо больше, чем приложение, для которого мы их используем, но человеческий мозг слишком неспособен кодировать их в среде кодирования без правил (= сборка) и нуждается в ограничительных правилах, которые в значительной степени уменьшить спектр и упростить кодирование. Я сам написал код, который не может быть написан на C, не становясь чрезвычайно неэффективным из-за вышеупомянутых ограничений. И я еще не говорил о скорости, которая, по мнению большинства, является основной причиной написания на ассемблере, ну, если ваш ум ограничен мышлением на C, тогда вы навсегда раб своего компилятора. Я всегда думал, что мастера шахмат будут идеальными программистами на ассемблере, в то время как программисты на C просто играют в "дам".

Уже не скорость, а контроль . Скорость иногда зависит от контроля, но это единственная причина, по которой нужно писать код на ассемблере. Все остальные причины сводятся к контролю (например, SSE и оптимизация других сторон, драйверы устройств и код, зависящий от устройства, и т. Д.).

Если я смогу превзойти GCC и Visual C ++ 2008 (также известный как Visual C ++ 9.0), людям будет интересно взять у меня интервью о том, как это возможно.

Вот почему на данный момент я просто читаю что-то на ассемблере и просто пишу __asm ​​int 3, когда это необходимо.

Надеюсь, это поможет ...

Я не писал на ассемблере несколько лет, но раньше я приводил две причины:

• Вызов дела! Я прошел несколько месяцев назад, когда я писал все на ассемблере x86 (времена DOS и Windows 3.1). По сути, он научил меня части низкоуровневых операций, аппаратного ввода-вывода и т. Д.
• Для некоторых вещей он оставался маленьким (снова DOS и Windows 3.1 при написании TSR )

Я снова смотрю на сборку кода, и это не более, чем вызов и радость. У меня нет других причин для этого :-)

Однажды я взял на себя проект DSP, который предыдущий программист написал в основном на ассемблерном коде, за исключением логики обнаружения тона, которая была написана на C с использованием чисел с плавающей точкой (на DSP с фиксированной точкой!). Логика обнаружения тона выполнялась примерно на 1/20 реального времени.

В итоге я переписал практически все с нуля. Почти все было на C, за исключением некоторых небольших обработчиков прерываний и нескольких десятков строк кода, связанных с обработкой прерываний и обнаружением частоты низкого уровня, которое выполняется более чем в 100 раз быстрее, чем старый код.

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

Виртуальная машина Dalvik, которая интерпретирует байт-код для приложений Java на телефонах Android, использует ассемблер для диспетчера. Этот фильм (примерно 31 минута, но его стоит посмотреть полностью!) Объясняет, как

«все еще есть случаи, когда человек может работать лучше, чем компилятор».

Я не знаю, но я поставил себе цель хотя бы попробовать и сильно постараться в какой-то момент в будущем (скоро, надеюсь). Когда я программирую на языке высокого уровня, не может быть ничего плохого в том, чтобы узнать больше о материалах низкого уровня и о том, как все работает за кулисами. К сожалению, трудно найти время, когда вы работаете на полную ставку разработчиком / консультантом и родителем. Но в свое время я уступлю, это точно.