Почему скомпилированный и связанный язык высокого уровня выполняется медленнее, чем ассемблер / машинный код?

Question

Скажем, я компилирую и связываю C в плоский двоичный файл или какой-нибудь исполняемый формат вывода для запуска на пустом компьютере. Если я оптимизировал и передал прямой двоичный файл в ЦП при загрузке, почему полученный формат потребовал бы больше тактов от скомпилированного и связанного источника C, чем от сборки в сборе? Я имею в виду, что если одни и те же инструкции подаются и извлекаются из некоторого двоичного формата, независимо от источника, если получающийся двоичный код выдает одинаковые коды операций, независимо от того, являются ли они C, D, Assembly или даже непосредственно написанными кодами операций (если это возможно), почему программисты часто говорят, что сборка всегда будет быстрее?

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

Answer 1

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

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

Например, компилятор может развернуть цикл, чтобы сделать его быстрее. В ассемблере вы можете сделать то же самое с макросом; но пойдет ли программист на ассемблер на эту проблему?

Answer 2

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

Answer 3

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

Answer 4

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

Ну нет ничего лучше, чем тестирование на конкретную ситуацию и хорошие библиотеки)).