История изменений

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

Это абсолютная ложь.

уже компилятор гораздо лучше человека

Это тоже.

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

А вообще вопрос ASM vs. C смысла не имеет. Если вы его задаёте, вы гарантированно неопытны и рано вам ещё писать на ассемблере.

• На первом месте всегда переносимость и поддерживаемость кода
• Куда большего выигрыша по производительности почти гарантированно можно достичь не прибегая к ассемблеру
  • Выбором более подходящего вычислителя. Курим GPU.
  • Алгоритмически. Курим асимптотику алгоритмов.
  • Распараллеливанием кода.
  • Нет, ГРАМОТНЫМ распараллеливанием кода. Вспоминаем закон Амдала, курим contention, lockfree и вообще независимость по данным
  • Хочется ниже уровнем? Вспоминаем что самая медленная деталь компьютера - память. Курим cache locality и смежные темы
  • Хочется ещё ниже? Курим simd интринсики

    Напомню, это всё оставаясь в рамках высокоуровнего, переносимого и поддерживаемого кода.

• Есть шанс что вы не перегоните компилятор, а время потратите
• А, вообще говоря, боттлнек-то который подлежит оптимизации вы найти способны?
• А в производительности ли вообще проблема вашего продукта?

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

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

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

Это абсолютная ложь.

уже компилятор гораздо лучше человека

Это тоже.

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

А вообще вопрос ASM vs. C смысла не имеет. Если вы его задаёте, вы гарантированно неопытны и рано вам ещё писать на ассемблере.

• На первом месте всегда переносимость и поддерживаемость кода
• Куда большего выигрыша по производительности почти гарантированно можно достичь не прибегая к ассемблеру
  • Выбором более подходящего вычислителя. Курим GPU.
  • Алгоритмически. Курим оценку сложности алгоритмов. O(N)? А сможешь за O(log N)?
  • Распараллеливанием кода.
  • Нет, ГРАМОТНЫМ распараллеливанием кода. Вспоминаем закон Амдала, курим contention, lockfree и вообще независимость по данным
  • Хочется ниже уровнем? Вспоминаем что самая медленная деталь компьютера - память. Курим cache locality и смежные темы
  • Хочется ещё ниже? Курим simd интринсики

    Напомню, это всё оставаясь в рамках высокоуровнего, переносимого и поддерживаемого кода.

• Есть шанс что вы не перегоните компилятор, а время потратите
• А, вообще говоря, боттлнек-то который подлежит оптимизации вы найти способны?
• А в производительности ли вообще проблема вашего продукта?

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

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