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

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

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

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

Ray Adams


Грецкий!


-AG-

Afx

Вообще то есть соглашения, что куда класть в каком случае. Или как, мы вызвали функцию, она что-то изменила, а компилятор об этом не знает? Не смешно ли? Зачем она вообще изменила значение регистра если об этом никто не знает? Для того, что бы в вызываемом коде новым значением могли воспользоваться, значит компилятор должен заранее знать куда положит данные вызываемая функция. Соответственно о ЛЮБОЙ функции должно быть известно что она изменила. То, что она не должна изменять, она должна вернуть в положение, которое было до вызова. Да и потом я то тут причем? Берем отладчик и GCC и смотрим на код, который сгенерировал GCC. И что мы видим, при вызове функций никаких лишних сохранений значений регистров не происходит (хотя в 32 битном коде все же есть лишние сохранения, но только одного регистра), а в коде самих функций кидается в стек содержимое регистров, которые используются в нем для промежуточных расчетов. Некоторые регистры используются для передачи параметров в функцию и обратно, так я с этим не спорю

Ну нету этого, не сохраняются все РОНы. Если функция мелкая и в ней вообще не используются РОНы, то вообще ничего не сохраняется в стек при ее вызове (опять же для x86_64, для 32 GCC по умолчанию сохраняет один регистр, но ключик -fomit-frame-pointer позволяет этого избежать).

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

По своему опыту. Писал как то программки, cчитающие фракталы. Так наблюдается проигрыш от простой перекомпиляции с 32 на 64 бита около 10 процентов. Но вот выигрыш от многоядерности хорош: на 2х-ядрах многопоточный вариант программы выигрывал 1.7 раза по сравнению с однопоточной, на 4х- 3.8 раза. Причем первоначальная программа писалась без учета многопоточности, а была сделана многопоточной через 2 года за пол часа. Так, что программисты, которые не используют многопоточность и многоядерность просто чрезвычайно ленивы. Пинать их надо ))