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

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

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

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

Ray Adams


Грецкий!


-AG-

DenisMak Да кстати, про лишние регистры я и забыл. Это на самом деле важнее, чем возможность работы с 64 битными целыми числами. Но кстати тоже есть минус - при вызове функции все эти регистры (к тому же вдвое большего размера) надо сохранять в стеке - расход памяти и нагрузка на ее ПСП увеличится, а так же скорее всего функции будут вызываться медленнее. (отсюда вывод - не злоупотреблять многократным вызовом мелких функций, пользоваться инлайновыми, это же относится и к глубоким рекурсиям)

Afx нужно не злоупотреблять разрядностью параметров в первую очередь, и тут есть припон для использования 32х битных команд в 64битном режиме используется префикс (эт уже ассемблер) - увеличение длины команды, но реально на производительность думаю почти не влияет

Они кодируются RIP'ом в 4 байта как и абсолютные указатели в 32битах. Нет недостатков.

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

+Скорость набирается за счёт конвенции вызовов в 64 битах - стек приложения приблизительно постоянен всегда, как неплавающий буфер, т.е. не приходится перемещать указатель стека и выделять новую память. Очень удобно и быстро.

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

обьясни или ссылочку дай, что сказать то хотел?


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


тоже не особо понятно


эх давнооо я изучал ассемблер и чота такое припоминаю ))) тем более тогда

если где ошибся не пинать))) просто указать ошибку, т.к. давно этим не занимался, так сказать остаточные знания

Причем тут параметры, я про другое. При вызове любой функции, даже если она вообще без параметров и состоит из одной команды RET, в стек сохраняются все РОНы и адрес возврата, а в 64 бит РОНов в 2 раза больше, и размер уних в 2 раза больше - отсюда больший расход стека.

asmfan

Насколько я знаю, это зависит исключительно от компилятора (или от программиста, если на чистом асме писать).

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

Это когда используешь вызов сделанных в коде функций, а когда функции у тебя заменяемые напр. "PFNGLRENDERBUFFERSTORAGEMULTISAMPLEEXTPROC glRenderbufferStorageMultisampleEXT" то тут уж ничего не поделаешь придется использовать 64-битные, кроме того 64-битные придется использовать при доступе к указателям членам класса, напр. "struct Some { char *str; int *nums; };"
Короче есть и преимущеста у 64 бит, а есть и недостатки и в случе если программе хватает 3гб памяти лучше делать ее 32-битной чем возиться с 64-битностью. Кроме того сам мелкософт ставит палки в колеса разработчикам, желающим перейти на 64 бита, т.к. бесплатный Visual Studio 2008 Express edition компилит код только в 32-битные ехе-шники.

DenisMak Да, я немного напутал. Автоматически это все сохраняется в прерывниях, а для функций есть команда PUSHA (и соответственно POPA), которая сохраняет РОНЫ. Адрес возврата сохраняется/восстанавливается автоматически командами CALL/RET. Но это в асме, вручную, можно не сохранять регистры если не надо, а компилятор все равно воткнет эти команды в любую функцию.

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

Насчет передачи параметров: через регистры действительно самый быстрый способ, быстрее чем через стек, но он не уневерсальный, поэтому (во всяком случае нас так учили) большинство компиляторов данные передают через стек. API функции например все так работают (т.е.вызов ф-и MyFunc(X,Y) будет выглядеть так:
PUSH Y
PUSH X
CALL MYFUNC
)

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

Как только играм понадобится больше 4 гигабайтов - так сразу ПО начнут оптимизировать под 64-х битные вычисления.
А сейчас рассуждения по теме не имеют ни какого смысла.
Мое мнение поставил 4 гига - ставь 64-ю версию.

P.S. Эту тему надо поднять года через два.

вы про смещение чтоли?
asmfan а указатель на структуру например тоже будет смещением? получается где то должен быть base и при каждом доступе проц должен складывать base+offset - возрастает длина команды (на счёт скорости выполнения тоже мне кажется не останется той же) + base - где то хранить надо а это либо рон или индексный регистр либо (что ещё хуже) память - дешвле сразу 64 битные указатели хранить, хотя чего то мож и не знаю. да и потом если будет такой base - значит heap 32битный -> своя модель памяти под которую должен быть заточен (как минимум знать) компилятор чтобы правильно обращаться к тем или иным данным, хотя в принципе очень даже ничего (только при поддержке компилятора) если хипа достаточно для промежуточных а остальное пространство используется допустим для мапинга/проецирования файлов в память для доступа к текстурам например.

такое используется в компиляторах? мне кажется это сильно могло бы сократить перерасход памяти в структурах данных

pusha/popa нет в 64 битах. API и конвенции вызова для 64 бит предусматривают передачу первых 4х парамтров как через РОН так и ХММ, либо через те и те одновременно в определённых ситуациях.
Под 64 бит ОС 64 выигрывают у 32 из-за отсутствия WOW переходников, посему никакие рекомендации мол если меньше 3х гигов и проч. не должны смущать. Если писать универсальный код, то перекомпиляции ис-под С/С++ компилера будет достаточно.
size_t, *_PTR, прочие макро- и просто фичи для компилера.

+есть гугл и что такое RIP можно посмотреть там. База - это instruction pointer, если в ближаих +-2х Гигабайтах находится то, что нужно адресовать, то будет использовано именно смещение, а не абсолютная адресация.
Естественно это всё для заранее известного адреса ибо смещение до данных можно посчитать только статически иначе же полные указатели, которые хранятся в РОН и работают по косвенной адресации, тоже дёшево по скорости и кол-ву кода. Единственная команда работающая непосредственно с 64 битн числами - mov! Все остальные через неё, если надо.

ты сказал об одном частном случае поэтому

крайне не верно для общего случая

asmfan

Интересно, а как тогда регистры сохранять? по одному?

Да.
Добавлено спустя 3 минуты, 52 секунды
Простите, вопрос лично для себя: вы какого уровня программисты - Ява и проч. или С/С++ или ниже?
Просто если последнее, то думаю знание английского и чтение мануалов интела и амд обязательно, ещё ссылочка интересная http://en.wikipedia.org/wiki/X86-64

asmfan С++. Одно время увлекался асмом (давно было, еще под дос, под винду совсем чуть чуть) но профессионально на асме писать не приходилось.

Вообще тема заинтересовала. Нагуглил вот статейку http://www.xakep.ru/magazine/xa/083/118/1.asp
Действительно, есть новые фишки, раньше API через стек вызывались, теперь через регистры, однако как я понял это относитьтся именно к API функциям, свои функции можно писать как угодно. А рекурсивную функцию например вообще невозможно написать без сохранения регистров в стек, так что PUSHA/POPA пригодились бы

Ещё: на рсдн есть хорошая статья про программирование под 64бит. А вообще можно писать переносимый код на С/С++ зная некоторые особеннсти прогр-я не заморачиваясь на внутреннем представлении кода и конвенциях вызовов. Просто компилеры умные однако пошли )
А неоднозначности как в теме данной ветки нет, 64 бит для 64 бит ОС.

Вот уж поскорей бы - может хоть висту 64 нормально поддерживать начнет Майкрософт, чтоб дрова для всего были и все под нее работало) Здесь мы опять имеем дело с перекосом прогресса - 64битность уже есть - но нужды в ней ПОКА нет! Когда будет - все заработает, дело времени)

Вот здесь есть и обзоры и много другой полезной информации: http://tanksim.org.ru.sixxs.org/

Дискуссия становится крайне интересной и противоречивой.
Давайте, для наглядности, разберем следующий конретный пример из моего диалога:

-AG-

Andrey12345

-AG-

Andrey12345



-AG-
.
Andrey12345

-AG-

Andrey12345


-AG-

Andrey12345

Нет, сегментная адресация по факту в Windows не используется - все сегменты наложены друг на друга. Хотя, конечно, операции, скажем, с адресами cs:epi и ds:esi, даже если им соответствует один и тот же линейный адрес, могут закончится не одинаково (например, нельзя писать в сегмент кода). Использовать больше 4Гб памяти позволяют 36 разрядная адресация, для этого необходимо включить режим PAE. В Windows это можно сделать через AWE API. Одновременно нельзя пользоваться всей памятью - в каждый момент доступно только 4Гб памяти (в режиме ядра есстественно). При проецировании окна на другую область памяти, составляются новый каталог страниц и новые таблицы страниц (что приводит к сбросы TLB кэша, кстати). Ну и не терабайты, конечно, а всего-то навсего 64 ГБ.

Правильно для прерываний, но не забываем, что есть такое системный вызов. Программа для Windows это ОГРОМНОЕ количество системных вызовов и при каждом необходимо много чего сохранять. Вообще, не сохранять РОН можно только если ты один пишешь программу (и то не стоило бы), а если один программист пишет функцию, а другой её вызывает, то как тут можно не сохранять? Не изучать же прогаммистам полностью код друг друга. То же самое и при использовании языков высокого уровня. Скажем если код подгружается динамически из DLL-ки, как тут можно узнать, нужно сохранять регистры или нет? Да даже если всё статически скомпилировано, сомнительно что у компилятора хватит мозгов проанализировать вызывающий код и код функции и сделать оптимизацию - это уже фантастика...
Добавлено спустя 19 минут, 38 секунд

Не очень понятен сей момент. При каждом вызове в стеке должен создаваться новый фрейм (хотя бы с точкой возврата), как же указатель стека может не перемещаться? Сама область отведённая под стек постоянна, но вершина стека не может оставаться постоянной иначе это не стек. Вообщем, не понял о чём вы...