Когда я должен использовать вызовы ASM?

Question

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

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

---

Стоит ли учиться работать с ASM, чтобы я мог делать вызовы ASM в C ++, может ли он дать мне значительный / заметныйпреимущество в производительности?

В каких ситуациях я должен его использовать?

Answer 1

Почти никогда:

• Вы хотите использовать его только после того, как профилировали свой код C ++ и определили определенный раздел как узкое место.
• И даже тогда,Вы хотите сделать это только после того, как исчерпали все опции оптимизации C ++.
• И даже тогда вы хотите использовать ASM только для узких внутренних циклов.
• И даже тогда, чтобы побить компилятор C ++ на современной платформе, требуется немало усилий и навыков.

Answer 2

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

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

Answer 3

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

Однако вам не нужно писать реальную сборку, вместо этого вы можете просто использовать встроенные функции.Смотрите, например, это .

Answer 4

Краткий ответ: это зависит, скорее всего, вам это не понадобится.

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

Выполните профилирование.

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

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

Профиль профиль профиль ....

Answer 5

Не забегай вперед.

Я опубликовал проект sourceforge , показывающий, как значительно ускорилась программа моделирования (более 700x).

Это не было сделано заранее, предполагая, что нужно сделать быстро.

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

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

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

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

P.S. Если вам интересно, разница между использованием профилировщика и случайной паузой заключается в том, что профилировщики ищут «узкие места», предполагая, что это локализованные вещи. Они ищут подпрограммы или строки кода, которые отвечают за большой процент общего времени. Чего они пропускают, так это проблем, которые распространены . Например, у вас может быть 100 подпрограмм, каждая из которых занимает 1% времени. То есть никаких узких мест. Однако во многих или во всех этих подпрограммах может быть выполнено действие, составляющее 1/3 времени, которое может быть выполнено лучше или не выполнено вообще. Случайная пауза будет видеть эту активность с небольшим количеством выборок, потому что вы не суммируете, вы исследуете образцы. Другими словами, если вы взяли 9 проб, в среднем вы заметили активность по 3 из них. Это говорит о том, что он большой. Так что вы можете это исправить и получить коэффициент ускорения 3/2.

Answer 6

Если вам нужно спросить, чем вам это не нужно.

Answer 7

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