Вот ссылка на мою беседу с программистом, одним из создателей игры СЯ (Andrey12345):
http://www.sukhoi.ru.sixxs.org/forum/sh ... 98&page=44 (и предыдущая пара страниц)

Мы здесь переходим на 64-разрядные ОС, а программисты (от кот., между прочим, зависит смысл этого перехода) сомневаются в эффективности 64-бит в принципе, особенно для игр.
Т.е. вплоть до того, что, например, те же игры не только не выиграют, а даже проиграют от такого перехода!

В общем, делимся своим мнением по этому вопросу.

П.с. Что касается меня, то я просто в недоумении...
____________________________________________________________________

Ray Adams


Грецкий!


-AG-

Obscury

Давно читал - уже многое забыл Но вот например в википедии пишут, что уже 80386 может адресовать 64 Тб виртуальной памяти: http://ru.wikipedia.org/wiki/Intel_80386



Вот и я о том же. Я когда на асме писал, просто в процедуре сразу писал PUSHA, POPA, RET, что бы потом не загоняться, какие регистры использовать, какие нет. Не исключаю конечно, что умный компилятор может и отследить, какие регистры используются а какие нет, что бы сохранять только нужные. Но это не всегда просто, допустим многие функции возвращаемое значение пишут в регистр (в досе так вообще в порядке вещей - вызываешь 21 прерывание, оно тебе пишет нужную инфу в определенные регистры), так что ИМХО это прокатит только в простейших функциях, а так все равно придется сохранять все.

да, так и есть, в 32 битной архитектуре виртуальное пространство составляет 2 в 46 степени (что составляет 64 Тб), так как память адресуется парой регистров - 16 битным селектором (где для индекса дискриптора используются только 14 бит - остальные биты связаны с привилегиями) и 32 битным смещением. Просто есть определённая путаница с терминами - виртуальный, линейный, эффективный, программно формируемый (программно доступный), физический. Линейный адрес (он же физический, если отключена страничная адресация) не может состоять больше, чем из 36 бит.
Кстати, в 16 битном режиме виртуальное адресное пространство составляет 4 Гб (два 16 битных регистра).
Наверное, в статье про это говорится, сейчас почитаю...
Добавлено спустя 9 минут, 28 секунд

Да уж... Эта фраза без пояснений может ввести в заблуждение (страничная адресация здесь, вообще, не причём). Не читайте люди википедию...

Obscury
Почему нет? Компилятор делает очень просто, в начале функции он сохраняет в стек содержимое регистров, которые могут (в случае ветвления) или будут использоваться в коде функции, а это уж он точно знает (он генерирует этот код ), и в конце функции он их достает из стека. Особого ума от компилятора не требуется. Что происходит в чужом коде так же все равно, главное что бы он восстанавливал все что изменил. Именно так поступает например GCC, про другие говорить не могу, не проверял. Если функция вообще не использует регистры, то для нее и ее вызова не генерируется ни одной пары push pop.
Так же могут поступать и программисты на ассемблере. Тут конечно есть опасность, что чужой код что то испортит, но это должны разруливать либо соглашения между программистами либо соглашения по генерации кода и вызова функций у компиляторов.

Afx Obscury сохранять нужно только те регистры которые не используеются как параметр и не являются возвращаемым значением, а это могут быть далеко не все это раз
и два если мне не изменяет память то как раз вызываЕМАЯ программа должна сохранять индексные и сегментные регистры если она их использует, а роны считаются доступными и изменяемыми. индексными я считаю si и di (16 битный асс, ну и для каждого режима ессно свои расширения, кстати может ещё какие туда же добавились а какие просто забыл) а ронами там ax bx и т.д. конечно давно этим не занимался (уж более 5ти лет точно) но вот такое в памяти осталось, могу и ошибаться

Первый пост дополнен наиболее конкретными высказываниями.
Пожалуйста, для ясности, дополняем сообщения дискуссии, по возможности, коротенькими выводами, что привносит в конечную эффективность продукта та или иная особенность программирования под 32/64-бит.
Также просьба, все-таки, прокомментировать выдержки из диалога и использование 32/64-бит в этом конкретном приложении (СЯ) и, в общем случае, в играх, как одном из основных стимулов перехода на 64-бит в быту.
Заранее спасибо всем участникам дискуссии!

Прокомментирую сообщения с того форума:

Где она расходуется сильнее? На указателях да, но например int как был 32 бита, так и остался. А если все таки нужны 64 битные целые числа, то тут этот расход будет компенсирован тем, что операции над ними будут производится за один такт. Теперь вопрос, большую ли часть данных программы занимают указатели? Как правило нет и больше занимают данные на которые они указывают. Так что расход памяти не на столько сильно увеличен, что бы о нем говорить, как о тормозе

Ну а больше я там ничего не увидел про производительность и x86_64 Только разговоры, что 4Гб это редкость, для меньшего объема 64 бита не нужны и т.п.
Добавлено спустя 7 минут, 17 секунд
Afx
А вот мне интересно, зачем на ассемблере писать код, который практически заведомо медленнее кода, который могут сгенерировать компиляторы ЯВУ? ИМХО уж если действительно появилась необходимость в оптимизации кода, которую можно сделать только на ассемблере, то надо ее делать как минимум не хуже компилятора. А иначе ассемблер это пустая трата времени, причем как процессорного так и рабочего

Swappp а если в коде попадется функция (в т.ч. системная) которая модифицирует регистры, как компилятор об этом узнает?


А где гарантии, что восстанавливает?

DenisMak SI и DI тоже РОНы. (РОНы - это все регистры к которым применимы арифметико-логические операции, к сегментным они например не пременимы, AX, BX, CX, DX, SI, DI, BP и SP - это все РОНы, у кажого из них есть определенная специализация, но это уже другой разговор)

однако это не значит что их мало и в результате они дают хороший прирост к обьёму использования памяти, а вообще там говорилось о попадании в кеш я это выражал как:
-(где то здесь на форуме прочитал) возрастает нагрузка на пропускную способность того же кеша (... которая в результате может тормозить, но тоже измерить это стандартными средствами не вижу как.) и кеш хранит меньше параметров хоть и при том же обьёме (размерность параметров увеличивается) (противовес большему кол-ву РОНов)

Я говорил о другом - о том, чтобы компилятор не сохранял те регистры, которые портит в функции, зная что они не будут использоваться внешним кодом. Ведь разговор о том, чтобы минимизировать сохранения. Ясно, что компилятор, может сохранить все регистры, на которые есть ссылки в функции. Только это есть плохо в контексте нашего спора об эффективности 64 бит.

Да, конечно, есть соглашения по поводу вызовов, но дело в другом - сохранять при 64 битах нужно больше. Насчёт РОН, тут должно быть соглашение - сохранять их или нет (например, ecx может участвовать во внешнем цикле, в ebx храниться какая-то база, только аккумулятор eax и edx по-настояшему являются регистрами общего назначения).
Swappp, DenisMak, вообщем, речь о том, что регистры (не все, конечно) нужно сохранять при вызовах, а в случае системного вызова их количество (сохраняемых регистров) сильно увеличивается, поэтому встаёт вопрос о том не будут ли 64 битные регистры в 64 битном режиме оказывать большую нагрузку на ПСП памяти нежели 32 битные в 32 битном режиме (я в этом не уверен если честно).

Afx не спорю просто я отделить пытался специализированные от арифм-логич регистров и ты кажется это понял

Swappp

Да не было никакой потребности в оптимизации - на асме писал только по учебе + для эксперементов всяких (читай от нефиг делать). Что касается, надо сохранять РОНы или не надо - еще неизвестно что быстрее выполнится, один PUSHA или 4 PUSH xx если например 4 регистра надо сохранить.

Сразу представил двусвязанный список (например, мне нужна быстрая вставка и относительно быстрый доступ к элементам), в каждом элементе которого храниться по одному байту . А ведь данные программы это как правило различные коллекции (ни один парсер не обойдётся без деревьев или списков - нужна быстрая вставка). Да и не только в указателях дело, есть ещё адреса, просто адреса. Например, любой программист, знающий ассемблер, смотря на сишный код, может представить себе насколько огромным будет количество меток, которые будут в ассемблерном коде, после компиляции сишного. Хотя тут кто-то говорил о том, что они могут быть вовсе не 64 битными, а 32 битными. Может и так.

будут и на псп памяти и на нагрузку на кеш, такова расплата, еслиб в процессорах было для 64х битного режима зашито в 2 раза больше кеша и линий связи с кешем тогда мы бы в меньшей степени ощутили это, хотя если честно дома 2 машины с 2г памяти работают на убунте х64 (раньше было на х86) - разницы не увидел (памяти хватает в обоих случаях), все эти нагрузки могут сказываться на приложениях дотошных до ресурсов, а в повседневно жизни - никакой разницы в производительности, а как показывает оптимизированное под х64 ПО дотошное до ресурсов (типа всяких мерилок, зд редакторов/рендеров....) всёже 64 бита лучше, посмотрите на тот же Paint.Net так что разговор разговором а практика показывает факты

Вот именно? Так как мельком сказано было:



И были менно косвенно высказы опасения о производительности кешей и связи кешей с ОЗУ. Не возрастет ли нагрузка? Может быть значительно именно при многократном случайном доступе (а для тех же игр это не физика, ИИ и т.п. сложные модели как раз?)?

Есть предположение, что скорость программ, работающих с цветом (силами процессора, конечно) может возрасти. Ведь цвет это 32 битные величины, и часто приходится их усреднять. Так как цвет распределён равномерно по всему диапазону значений 32 битного целого, чтобы осуществлять усреднение необходим более мощный тип. 64 битного более чем достаточно. Использовать для этого действительные числа плохо, так как не смотря на то что скорость работы с действительными числами почти не уступает скорости работы с целыми, очень тяжёлой операцией является преобразование типов между целыми и числами с плавающей точкой. Ну это так предположение.
P.S. к играм это не относится, так раскарской там ведает GPU.

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

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

Он не знает ничего о внешнем коде. Более того вызов функции может быть из разных мест внешнего кода, а внешний код может быть так же откуда то вызван, где эти регистры используются. Не понимаю, зачем нужна такая минимизация? По моему вполне достаточно того, что бы функция убиралась за собой, это не так уж и затратно. Тем более в 32 битных программах все происходит так же, разница лиш в том, что там кидается 32 бита, а тут 64. Но так же увеличение кол-ва регистров позволяет лишний раз не скидывать промежуточные данные вычислений в стек, что бы освободить регистры для других вычислений. Что частенько дает так же не плохой прирост, особенно в сложных циклах.

В общем что я хочу сказать, одна моя программка получила прирост 15-20% только от того, что я ее скомпилировал под 64 бита. При этом указатели там используются достаточно активно (там фактически рассчитывается двудольный граф, у каждой вершины массив указателей на дуги, у дуг указатели на обе вершины которые они связывают, в алгоритме происходит проход по всем вершинам одной доли с обращение к другой), а необходимости работать с 64 битными числами вообще нет. Так же нет вычислений с плавающей точкой (почти нет, но при тестировании код с ними не выполнялся).

Забудьте про push и передачу таким способом параметров - всё делается через mov в конкретную область памяти заранее отведённую на стеке.
Отвечаю тов. Obscury .
Фреймовый стэк выделяется один раз в самом начале исполнения так, чтобы вместить самое большое количество параметров функций используемых в программе - эту вещь анализирует компилер. Далее этот фрейм относительно постоянен, т.к. количетво и размер параметров функций известен компилятору /прототипирование и проч./ Затем этот единый буфер используется для передачи параметров всем ф-ям в приложении включая API с помощью mov [rsp+20] нужный параметр. Таким образом нет активных перемещений указателя и память под стэком всегда или приблизительно всегда в кэше заранее.
В общем,чтобы не гадать на картах, читайте спецификации. Всё очень толково и продумано -> быстро.

Да не нужна конечно, беседа не о том:

Добавлено спустя 3 минуты, 15 секунд

Так понятнее.
Добавлено спустя 10 минут, 56 секунд
Хотя не очень. Как осуществляется последовательность вызовов (например, рекурсия)? База должна меняться, ведь фрейм уже занят, нужно переместиться на новый. Ладно не утруждайся, объяснять, я вижу, ты не любишь, почитаю как-нибудь (хотя ассемблером уже давно не увлекаюсь).

ИМХО 64бита могут дать огромный прирост если изначально писать с их учётом
(а главное включать смекалку и оптимизировать под них всё и вся)
99% программ просто перекомпилируются и всё, от сюда и маленькая разница
Думаю с двухядерностью примерно такая-же история...

Swappp

Ты не понимаешь. Некоторые функции СПЕЦИАЛЬНО модифицируют регистры. Просто так задумано. Например, почти любая API функция (по крайней мере в 32 бит, про 64 не скажу) возвращаемое значение пишет в EAX. Ну ладно, допустим компилятор в принципе может знать все апи функции, какая какой регистр портит, а если функции пользовательские? В общем, на мой взгляд если в процедуре вызывается внешняя процедура, то сохранять придется все.

А вообще, мне кажется мы все слишком загнались проблемой сохранения регистров в стек. Ведь стек тоже кэшируется, значит сохранение даже всех 16 64-битных ронов будет производится в кэш (как правило 1 уровня), даже в худшем случае это займет пару десятков тактов. Это не так уж и много, если функция более менее сложная, то этим временем можно пренебречь. Поэтому я и сказал что не стоит злоупотреблять многократным вызовом мелких функций, надо их инлайновыми оформлять (но вообщето это и в 32 бит верно, просто в 64 будет еще больше разница). Щас к сожалению и без асма времени не хватает постоянно, может кто протестит, сколько например занимает вызов 1 млрд раз функции (PUSHA POPA RET) и пустой функции (RET) ? аж самому интересно стало, может мы тут только зря копья ломаем?

DenisMak Я просто не понимаю, чем по твоему мнению таким особым отличаются SI и DI, что их нужно сохранять, а другие нет. Вообще есть правило: процедура должна "прибрать" за собой, т.е. все регистры которая изменила, должна восстановить. Т.е. вызывающая программа не должна заморачиваться сохранением контекста - это дело вызываемой процедуры. И тут нет разницы, о чем идет речь, о ронах или сегментных регистрах (просто последние как правило нет нужды изменять в подпрограмме, но раз уж изменил - изволь прибрать за собой). Что касается индексных регистров, - ничем таким особенным они от остальных ронов не отличаются, сохранять все надо. И арифметические, и логические операции нормально с ними работают так же, как и с остальными. Да, по SI и DI работает базово-индексная адресация, с ними работают строковые команды - но и у AX и DX особая роль в операциях умножения и деления, а по CX можно организовывать цикл, но они от этого не перестают быть РОНами.