[amd64]Вопрос к практикам

> что количество архитектурных регистров особой роли не играет.

(... кто о чём, а вшивый о бане - это я про себя...) Как же не играет? В отсутствии достаточного кол-ва регистров для организации рантайма в SBCL архитектура оного рантайма мало того, что перекроена в совершенно непохожей манере по сравнению с классическими RISC'ами с 32-64 регистрами, так ещё и нещадно эксплуатирует стек там, где вышеозвученные RISC'и обходятся без него. Линуксовое ядро, кстати, тоже страдает от малого числа регистров, например, current на x86 каждый раз вычисляется, а на x86-64 хранится в выделенном регистре.

Потом, в 32-битный регистр tagged fixnum нормального размера с хотя бы с 32-я значащими битами не помещается, поэтому в 32-битном SBCL от fixnum толку при числодробилках мало.

Если брать более приземлённые задачи, то существует ещё класс задач, которые до сих пор кодируются руками на ассемблере: критические блоки кодеров, декодеров, конвертеры цветовых пространств. Мой ручной конвертер rgb16->32 на sse2 работает в 64-битном режиме почти в два раза быстрее, чем в 32-х. Как раз за счёт 16 simd-регистров вместо 8. Обычная целочисленная длинная арифметика, кстати, тоже быстрее в 64-битном режиме работает, как ни крути.

Помимо этого, в 64-битном режиме есть и другие приятные плюшки типа релативной адресации (RIP-relative).

-O3

-O3 turns on all -O2 optimizations and also some optimizations that increase binary size and make debugging harder or even impossible. Using -O3 as your default optimization level might be a bad idea, see below.

© Gentoo wiki. Могу я узнать причины, по которым сударь выбрал -О3? Так длиннее?

Если ты собираешь дженту ради оптимизации - лучше разбери её обратно.

> в SBCL архитектура оного рантайма мало того, что перекроена в совершенно непохожей манере по сравнению с классическими RISC'ами с 32-64 регистрами

Не понял, что вы имеете ввиду? Лисп-машины вообще интересная штука, но с SBCL и его кодогенерацией к сожалению не знаком.

> так ещё и нещадно эксплуатирует стек там, где вышеозвученные RISC'и обходятся без него

Это не страшно, потому что внутри функции изменения rSP обычно не зависят ни от чего, поэтому процессор всегда может подгрузить данные заранее. На входе в функцию из rSP вычитается константа, на выходе -- прибавляется. В зависимости от опций оптимизации посреди функции могут быть еще push/pop аргументов, но и это не проблема, потому что они безусловные.

> Потом, в 32-битный регистр tagged fixnum нормального размера с хотя бы с 32-я значащими битами не помещается, поэтому в 32-битном SBCL от fixnum толку при числодробилках мало.

Ну так это проблема не количества регистров, а их ширины.

> Мой ручной конвертер rgb16->32 на sse2 работает в 64-битном режиме почти в два раза быстрее, чем в 32-х. Как раз за счёт 16 simd-регистров вместо 8.

Не глядя в код сложно что-то сказать.

> Обычная целочисленная длинная арифметика, кстати, тоже быстрее в 64-битном режиме работает, как ни крути.

64-битная арифметика -- да, конечно.

> Помимо этого, в 64-битном режиме есть и другие приятные плюшки типа релативной адресации (RIP-relative).

Да вроде никто и не спорит, что AMD64 -- какой-никакой, но все-таки шаг вперед по сравнению с i386. :)

> Могу я узнать причины, по которым сударь выбрал -О3? Так длиннее?
Да я и не помню точно уже. Кто-то советовал.

> Если ты собираешь дженту ради оптимизации - лучше разбери её обратно.
Ни в коем случае. USE-флаги же. И bleeding edge.

> Не понял, что вы имеете ввиду? Лисп-машины вообще интересная штука, но с SBCL и его кодогенерацией к сожалению не знаком.

Рантайм у SBCL (и программ им собранных) имеет несколько бОльшую сложность, чем у обычной сишной программы. Из-за малого числа регистров бэкенд под ia32 раза в два с лишним жирнее, чем у того же mips. А самое печальное - написан, практически, с нуля, и по логике с рисковыми бэкендами почти не пересекается. Остальные многорегистровые бэкенды очень сильно похожи друг на друга, только кодогенераторы отличаются.

Ненужные манипуляции со стеком усложняют код и замедляют работу.

> Не глядя в код сложно что-то сказать.

Да что там смотреть... 128-битным регистром читается 8 пикселов формата rgb-16, в 64-битном режиме регистров хватает их все обработать за раз, а в 32-битном - нет.

> Да вроде никто и не спорит, что AMD64 -- какой-никакой, но все-таки шаг вперед по сравнению с i386. :)

Так о том и речь.

Да я и не помню точно уже. Кто-то советовал.

Вспомни и начисти этому кому-то вывеску. Развелось таких горе-советчиков…

Ни в коем случае.

Ну хоть это хорошо…

> Ненужные манипуляции со стеком усложняют код и замедляют работу.

Если сравнивать производительность версий под разные архитектуры, то она определяется кучей факторов. Что касается непохожести бекендов, то увы, такая уж архитектура IA-32. У меня есть подозрения, что в интеле не думали, что х86 может стать доминирующей архитектурой на рынке десктопов, серверов и рабочих станций. Для чего она хорошо подходит, так это для программирования на ассемблере задач, где не нужна высокая производительность.

> Да что там смотреть... 128-битным регистром читается 8 пикселов формата rgb-16, в 64-битном режиме регистров хватает их все обработать за раз, а в 32-битном - нет.

А, ну так XMM регистры -- не РОН. Поэтому и получился прирост.

а ты больше слушай лорных "спецов"

Смысл есть. У тебя все часто используемые файлы будут постоянно в памяти.

> это субъективное ощущение, но мне кажется, что система на amd64 работает в целом стабильнее

Может потому, что наиболее кривые программы под 64 бита просто не собираются? :)

> Слышал только, что O3 может вызывать баги. А вот замедление - хз.

Была недавно ссылка на тест на форониксе — Генту с разными флагами против Убунту. В паре тестов -O3 проигрывал -O2 в третьем знаке.

Спасибо, интересно. Но:

1) анализ на лету - вряд ли быстрое дело

2) по ссылке нет ничего о дополнительных регистрах в процессорах, ни о 128, ни даже об одном, оттуда можно сделать вывод про распараллеливание операций по РОНам для ускорения, если их хватает

>Но во многих до сих пор живет миф о нехватке регистров. :)

Ещё бы. Для начала покажите ссылки, что у хоть одного процессора x86(_64) дополнительный массив регистров есть.

> Для начала покажите ссылки, что у хоть одного процессора x86(_64) дополнительный массив регистров есть.

давно читал, уже не помню где именно. Но вроде есть здесь: http://www.amd.com/us-en/assets/content_type/white_papers_and_tech_docs/22007...

Если вы думаете, что я это сам придумал, то вы мне льстите. :)

> Для начала покажите ссылки, что у хоть одного процессора x86(_64) дополнительный массив регистров есть.

Ну вот вам например ссылка на описание микроархитектуры Pentium 4: http://download.intel.com/technology/itj/q12001/pdf/art_2.pdf (см. стр. 6). Цитата оттуда:

The register renaming logic renames the logical IA-32 registers such as EAX onto the processors 128-entry physical register file. This allows the small, 8-entry, architecturally defined IA-32 register file to be dynamically expanded to use the 128 physical registers in the Pentium 4 processor.

Надеюсь, Intel -- достаточно авторитетный для вас источник. :)

>Ну вот вам например ссылка на описание микроархитектуры Pentium 4: http://download.intel.com/technology/itj/q12001/pdf/art_2.pdf (см. стр. 6). Цитата оттуда:

>The register renaming logic renames the logical IA-32 registers such as EAX onto the processors 128-entry physical register file. This allows the small, 8-entry, architecturally defined IA-32 register file to be dynamically expanded to use the 128 physical registers in the Pentium 4 processor.

Спасибо. Кое-что в этом для меня осталось загадкой - как можно, обладая 128+8=136-ю регистрами, давать пользоваться только 8-ю? Ведь какие возможности для компилятора - столько регистров и все наши. Не надо делать в процессоре динамическую подстройку с RAT и прочим - компилятора сам разбросает тонким слоем по регистрам операции. Может, кто-либо из x86-кунов и здесь имеет хороший ответ? :)

Скорее это как некий регистровый кеш и глобально на модель архитектуры СPU это не влияет.