> Ну "спец" же =) Вроде одни преумущества, но на практике 32-х битный
> (generic) код довольно часто почему-то быстрее 64х-битного: то ли лишний уровень
> в TLB даёт о себе знать, то ли префиксы кодманд и адресность становятся
> бутылочным горлышком для декодера - неизвестно, Не думаю. Декодер успевает распихивать команды на кучи блоков, изображая "как-бы 8-ядерный" х86 и прочие гипертрединги, так что в результате роялит именно распределение нагрузки на блоки, которые находятся за ним. Поэтому врядли он является узким местом. Например, недавний тест фороникса очень недвусмысленно демонстрирует поведение бульдозера, при том это поведение формируется распределением нагрузки на блоки. Ну то-есть скорость целочисленных операций перестает существенно расти после того как закончатся неозадаченные целочисленные блоки, что ожидаемо, ну и так далее ;). Гипертрединг тоже похоже преследует цель догрузить блоки за декодером. На изображение полноценного честного ядра конечно остатков возможностей блоков не хватает, но свои 15-20% на сильно многопоточных случаях получить все-таки удается. С чего бы быть хоть какому-то приросту, если в декодер все уткнулось?
> т.к. "спец" решил об этом умолчать =)
Не, плюсов совсем без минусов не бывает. Еще и код и данные жирнее, значит реже будут в кеш попадать целиком. С другой стороны, кеши нынче у х64 процов весьма жирные и наврядли это сильная проблема в большинстве случаев. И в целом по шинам надо передавать несколько больше данных, и это может упереться и в оперативку и в размер кеша. Ну и оперативку нынче понапихали многоканальную, с нехилым бандвизом. Наверное не для красоты.
Понятно что в целом есть возможности проиграть 32-битному коду в некоторых случаях. С другой стороны, годный алгоритм критичный к скорости - должен быть не сильно жирным и целиком влезать в кеш, а когда это случилось, наличие 64-битной арифметики, кучи регистров и гарантированное наличие SSE2 вполне могут обеспечить победу.
