Да, чаще всего.
Прежде всего, вы исходите из неверного предположения, что язык низкого уровня (в данном случае ассемблер) всегда будет генерировать более быстрый код, чем язык высокого уровня (в данном случае C ++ и C).дело).Это неправда.Всегда ли код C быстрее, чем код Java?Нет, потому что есть другая переменная: программист.То, как вы пишете код и знание деталей архитектуры, сильно влияет на производительность (как вы видели в этом случае).
Вы можете всегда создать пример, где код сборки вручную лучше, чем скомпилированный код, но обычно это вымышленный пример или отдельная подпрограмма, а не истинная программа из 500 000+ строк кода C ++).Я думаю, что компиляторы будут производить лучший ассемблерный код в 95% раз, а иногда, только в редких случаях, вам может понадобиться написать ассемблерный код для небольшой, короткой, высокой производительности , производительностикритические подпрограммы или когда вам нужно получить доступ к функциям, которые ваш любимый язык высокого уровня не раскрывает.Хотите прикосновения этой сложности?Прочитайте этот удивительный ответ здесь, на SO.
Почему это?
Прежде всего потому, что компиляторы могут выполнять оптимизации, которые мы даже не можем себе представить (см. этот короткий список ), и они будут делать их в секунд (когда нам могут потребоваться дни ).
Когда вы кодируете в ассемблере, вы должны создавать четко определенные функции с четко определенным интерфейсом вызовов.Однако они могут принимать во внимание оптимизация всей программы и межпроцедурная оптимизация , например распределение регистров , постоянное распространение , исключение общих подвыражений , планирование команд и другие сложные, неочевидные оптимизации (например, модель многогранника ).На архитектуре RISC парни перестали беспокоиться об этом много лет назад (например, очень трудно настроить расписание команд вручную ), а современные CISC процессоры имеют оченьlong pipelines тоже.
Для некоторых сложных микроконтроллеров даже библиотеки system написаны на C вместо ассемблера, потому что их компиляторы производят лучший (и простой в обслуживании) конечный код.
Компиляторы иногда могут автоматически использовать некоторые инструкции MMX / SIMDx сами по себе, и если вы их не используете, вы просто не можете их сравнивать (другие ответы уже рассмотрели ваш код сборки очень хорошо).Просто для циклов это короткий список оптимизаций цикла из того, что обычно проверено компилятором (как вы думаете, вы могли бы сделать это самостоятельно, когда ваш график был выбран дляПрограмма на C #?) Если вы пишете что-то на ассемблере, я думаю, вам нужно рассмотреть хотя бы некоторые простых оптимизаций .Пример учебника для массивов: развернуть цикл (его размер известен во время компиляции).Сделайте это и запустите тест снова.
В наши дни очень редко нужно использовать язык ассемблера по другой причине: множество различных процессоров .Вы хотите поддержать их всех?Каждый имеет определенную микроархитектуру и несколько определенных наборов инструкций .Они имеют разное количество функциональных блоков, и необходимо подготовить инструкции по сборке, чтобы все они были заняты .Если вы пишете на C, вы можете использовать PGO , но при сборке вам потребуются глубокие знания этой конкретной архитектуры (и переосмыслите и переделайте все для другой архитектуры ).Для небольших задач компилятор обычно делает это лучше, а для сложных задач обычно работа не оплачивается (и компилятор может лучше в любом случае).
Если вы сядете и посмотрите на свой код, вероятно, вы увидите, что вы получите больше, чтобы изменить свой алгоритм, чем переводить в сборку (прочитайте этот отличный пост здесь, на SO ) Существуют высокоуровневые оптимизации (и подсказки для компилятора), которые вы можете эффективно применить, прежде чем прибегнуть к языку ассемблера. Вероятно, стоит упомянуть, что часто используя встроенные функции, вы получите прирост производительности, который ищете, и компилятор по-прежнему сможет выполнять большинство его оптимизаций.
Все это говорит о том, что даже когда вы можете создавать сборочный код в 5-10 раз быстрее, вы должны спросить своих клиентов, предпочитают ли они платить одну неделю вашего времени купите на 50 $ более быстрый процессор . Чрезвычайная оптимизация чаще всего (особенно в LOB-приложениях) от большинства из нас просто не требуется.