Чем отличается выполнение программы на x86 процессорах 2003 и 2024 года выпуска?

Question

[Евгений]

Кроме более быстрого выполнения команд и набором доп инструкций(которые программой не используются)

1.Есть ли принципиальная разница для работы программы на процессоре х86 разных годов?

2.Нужны ли разные компиляторы для разных процессоров архитектуры х86?

Comments

[res2001]

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

[Adamos]

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

Answer 1

[pfg21]

1. нет, если в коде отсутствуют команды из расширений архитектуры.
да, если в коде присутствуют команды расширений, то на процессоре без них код просто не заработает.
2. да. для использования расширений архитектуры компилятор+библиотеки должен их поддерживать.

Answer 2

[Дмитрий]

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

1. Существует конвеер исполнения инструкций. Который состоит из портов выполнения. С каждым новым поколением процессора этот конвеер допиливают. Улучшают синхронизации кешей, меняют в целом принцип работы кешей и порядок выполнения инструкций. Добавляют новые порты. Перепиливают микрокод для инструкций, используя эти изменения.
2. Переупорядочивание выполнения инструкций. Каждый новый проц что-то да делает с этим. Улучшают сам алгоритм переупорядочивания, избавления потоков выполнения от лишних зависимостей данных, увеличивают внутренние буферы, используемые для этих целей. В итоге растёт retired instruction per clock.
3. Предсказатели переходов постоянно совершенствуются, меньше тупняков конвеера дают, меньше сбросов кеша.
4. Декодер инструкций. Fetch-буфер растёт, буфер декодинга растёт, буфер переупорядочивания растёт.
5. Интерфейсы взаимодействия с памятью тоже совершенствуются. Одноканальный DDR из 2003-го, который требует отдельного контроллера памяти на северном мосту, и мноканальный DDR6 из 2025-го -- мягко говоря, вещи из разных миров. Не только память должна быть быстрой, но и процессор должен уметь общаться с этой памятью. В конце нулевых контроллер памяти начали встраивать в сам процессор, это позволило снизить задержки доступа к памяти в разы.

А ещё много-много тонкостей, которые не афишируются публично и держатся в коммерческой тайне.

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

Comments

[pfg21]

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

[Дмитрий]

pfg21, эта скорость же не с потолка берётся, как раз таки от изменения реализации внутренних механизмов.

Если ничего не меняется, почему тогда появляются уязвимости типа Meltdown, Spectre, Foreshadow, ZombieLoad, и т.п., когда изменяется внутренняя кухня модели исполнения в процессоре, её исследуют и находят косяки? Если бы ничего не менялось, уязвимости бы не появлялись.

Явно это всё не видно для пользователя, но это не значит что ничего не происходит.
Если раньше в процессоре без спекулятивного исполнения, без бранчпредиктора и без переупорядочивания команд, происходила операция, которая требует результата предыдущей команды или результата чтения из памяти, процессор банально останавливался и стоял ждал, пока придёт ответ, не выполняя никакой полезной работы. Современный процессор же начнёт спокойно выполнять код дальше, который не завязан на результат предыдущей операции.
Да, это не "видно глазом" из-за низких задержек для человеческого восприятия, но ждущий чего-то процессор, и не останавливающийся и делающий другую полезную работу -- это разве не кардинальное изменение процесса исполнения кода?

Если вы пишете hello, world, то разницы не увидите совершенно, за вас уже сделали колоссальную работу разработчики компилятора, ОС, драйверов. А если это какой-то неблокирующий IPC, который утилизирует знания о модели памяти, синхронизации кешей, работы блока переупорядочивания команд, NUMA не дай бог, то будет очень больно не учитывать все современные особенности модели исполнения.

Посмотрите какой-нибудь низкоуровневый проект, типа DPDK. Где для предотвращения cache false sharing в примитивах синхронизации выравнивали данные по границе одной кеш-линии (64 байта), а потом появился Sandy Bridge со своим парным префетчером (две линии по 64 байта за раз), и код сломался пока не пофиксили 128-байтным выравниванием. Архитектура та же, всё то же самое, никаких новых расширений не задействовали, а код сломался в новом процессоре. Почему же?

[pfg21]

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

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