Как сборка быстрее, чем у HLL? - PullRequest
0 голосов
/ 11 февраля 2012

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

Ответы [ 6 ]

2 голосов
/ 11 февраля 2012

Дни, когда ядра процессора фактически выполняют инструкцию машинного кода напрямую, давно прошли. Они переведены в микрооперации, рископодобные инструкции, которые были разработаны, чтобы поддерживать современное суперскалярное ядро, способное к выполнению не по порядку, с поддержкой нескольких исполнительных блоков. Фактическая реализация которого является производственным секретом и меняется для каждого нового поколения архитектуры процессора. Одним из первых отличительных процессоров с таким поведением был Intel 486, доступный в 1989 году.

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

2 голосов
/ 11 февраля 2012

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

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

1 голос
/ 11 февраля 2012

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

Языки высокого уровня призваны упростить и ускорить программирование , а не программ быстрее.

0 голосов
/ 11 февраля 2012

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

Вплоть до начала этого столетия архитектура X86 была ближе к CISC (думаю, Vax), чем к RISC (думаю, Sparc), и, таким образом, эксперты могли превзойти хорошие оптимизирующие компиляторы.Но AMD серьезно отреагировала на показатели производительности Intel, потому что их чипы были гораздо более рискованными под прикрытием.Результатом является то, что рукописная сборка для мира X86 разделена по производительности.

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

0 голосов
/ 11 февраля 2012

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

Так как же сборка быстрее? Ты знаешь все. Компилятор слепо следует правилам.

Конечно, все это предполагает, что вы действительно действительно знаете, как оптимизировать свою целевую платформу. Если вы собираетесь писать ассемблер «очевидным путем», вы, вероятно, не сможете победить правильный компилятор. То, сможете ли вы победить их, также во многом зависит от компилятора - ICC и LLVM довольно трудно победить, но на другом конце спектра вы можете победить .NET JIT-компилятор во сне (да, это JIT-компилятор , но так же и LLVM, если вы хотите, чтобы это было).


В случае, если вы хотите знать, как побить компиляторы ..

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

0 голосов
/ 11 февраля 2012

Программы, написанные на ассемблере раньше были быстрее, когда ПК был медленным и простым, а компиляторы не слишком яркими.

Раньше я писал множество сборок в 1980-х, потому что вам пришлось , чтобы использовать ПК, которые у нас были тогда. Это был МГц вместо ГГц.

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

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

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