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

Я думаю, что вы неправильно читаете это утверждение:

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

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

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

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

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

Вот некоторые более важные Примеры:

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

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

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

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

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

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

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

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

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

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

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

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

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

Конечно, у меня были другие причины .

Almost every medium-to-large game engine or library I've seen to date has some hand-optimized assembly versions available for matrix operations like 4x4 matrix concatenation. It seems that compilers inevitably miss some of the clever optimizations (reusing registers, unrolling loops in a maximally efficient way, taking advantage of machine-specific instructions, etc) when working with large matrices. These matrix manipulation functions are almost always "hotspots" on the profile, too.

I've also seen hand-coded assembly used a lot for custom dispatch -- things like FastDelegate, but compiler and machine specific.

Finally, if you have Interrupt Service Routines, asm can make all the difference in the world -- there are certain operations you just don't want occurring under interrupt, and you want your interrupt handlers to "get in and get out fast"... you know almost exactly what's going to happen in your ISR if it's in asm, and it encourages you to keep the bloody things short (which is good practice anyway).

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

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

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

Aside from very small projects on very small CPUs, I would not set out to ever program an entire project in assembly. However, it is common to find that a performance bottleneck can be relieved with the strategic hand coding of some inner loops.

In some cases, all that is really required is to replace some language construct with an instruction that the optimizer cannot be expected to figure out how to use. A typical example is in DSP applications where vector operations and multiply-accumulate operations are difficult for an optimizer to discover, but easy to hand code.

For example certain models of the SH4 contain 4x4 matrix and 4 vector instructions. I saw a huge performance improvement in a color correction algorithm by replacing equivalent C operations on a 3x3 matrix with the appropriate instructions, at the tiny cost of enlarging the correction matrix to 4x4 to match the hardware assumption. That was achieved by writing no more than a dozen lines of assembly, and carrying matching adjustments to the related data types and storage into a handful of places in the surrounding C code.

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

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

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

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

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

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

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

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

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

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

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

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

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

"Yes". But, understand that for the most part the benefits of writing code in assembler are not worth the effort. The return received for writing it in assembly tends to be smaller than the simply focusing on thinking harder about the problem and spending your time thinking of a better way of doing thigns.

John Carmack and Michael Abrash who were largely responsible for writing Quake and all of the high performance code that went into IDs gaming engines go into this in length detail in this book.

I would also agree with Ólafur Waage that today, compilers are pretty smart and often employ many techniques which take advantage of hidden architectural boosts.

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

К концу 80-х я перешел на C. Код стал легче писать, отлаживать и поддерживать. Очень маленькие фрагменты кода были написаны на ассемблере - для меня это было, когда я писал переключение контекста в ОСРВ по-отдельности. (Что-то, что вы больше не должны делать, если это не «научный проект».)

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

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

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

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

Usually, a layman's assembly is slower than C (due to C's optimization) but many games (I distinctly remember Doom) had to have specific sections of the game in Assembly so it would run smoothly on normal machines.

Here's the example to which I am referring.

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

I have not coded in assembly language for many years, but I can give several reasons that I frequently saw:

• Not all compilers can make use of certain CPU optimizations and instruction set (e.g., the new instruction sets that Intel adds once in a while). Waiting for compiler writers to catch up means losing a competitive advantage.

• Easier to match actual code to known CPU architecture and optimization. For example, things you know about the fetching mechanism, caching, etc. This is supposed to be transparent to the developer, but the fact is that it is not, that's why compiler writers can optimize.

• Certain hardware level accesses are only possible/practical via assembly language (e.g., when writing device driver).

• Formal reasoning is sometimes actually easier for the assembly language than for the high-level language since you already know what the final or almost final layout of the code is.

• Programming certain 3D graphic cards (circa late 1990s) in the absence of APIs was often more practical and efficient in assembly language, and sometimes not possible in other languages. But again, this involved really expert-level games based on the accelerator architecture like manually moving data in and out in certain order.

I doubt many people use assembly language when a higher-level language would do, especially when that language is C. Hand-optimizing large amounts of general-purpose code is impractical.

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

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

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

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

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

Многие люди думают, что встраивание - это оправдание ассемблеру, но их контроллеры имеют больше ресурсов процессора, чем машины Unix . (Микрочип идет

Многие думают, что встраивание - это оправдание ассемблеру, но их контроллеры имеют большую мощность процессора, чем машины Unix был разработан. (Микрочип идет

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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