Особенности производительности x64 и x86 .Net - PullRequest
19 голосов
/ 29 июня 2011

Я пытаюсь понять, какие различия в производительности существуют при запуске собственного приложения C # / .Net 4.0 в x64 против x86. Я понимаю соображения, касающиеся памяти (x64 обращается ко всей памяти, x86 ограничено 2/4 ГБ), а также тот факт, что приложение x64 будет использовать больше памяти (все указатели - 8 байтов вместо 4 байтов). Насколько я могу судить, ни один из них не должен влиять ни на один из тактовых импульсов для команд тактирования, поскольку конвейер x64 достаточно широк, чтобы обрабатывать более широкие инструкции.

Есть ли снижение производительности при переключении контекста из-за большего размера стека для каждого потока? Какие показатели производительности я упускаю при оценке двух?

Ответы [ 2 ]

18 голосов
/ 29 июня 2011

Джо Уайт дал вам несколько веских причин, по которым ваше приложение может работать медленнее. Большие указатели (и, следовательно, более крупные ссылки в .NET) будут занимать больше места в памяти, а это означает, что меньше вашего кода и данных уместится в кэш.

Однако существует множество полезных причин, по которым вы можете использовать x64:

  • Соглашение о вызовах AMD64 используется по умолчанию в x64 и может быть немного быстрее, чем стандартные cdecl или stdcall, при этом многие аргументы передаются в регистрах и используют регистры XMM для плавающей запятой.

  • CLR будет выдавать скалярные инструкции SSE для работы с операциями с плавающей запятой в 64-битной среде. В x86 он использует стандартный стек FP x87, который немного медленнее, особенно для таких вещей, как преобразование между int и float.

  • Наличие большего количества регистров означает, что гораздо меньше шансов, что JIT придется разлить их из-за давления регистра. Регистры разлива могут быть довольно дорогими для быстрых внутренних циклов, особенно если функция встроена и вводит туда дополнительное давление регистра.

  • Любые операции с 64-битными целыми числами могут принести огромную пользу, если их можно уместить в один регистр, а не разбивать на две отдельные половины.

  • Это может быть очевидным, но дополнительная память, к которой может обращаться ваш процесс, может оказаться весьма полезной, если ваше приложение требует много памяти, даже если оно не выходит за пределы теоретического ограничения. Фрагментация может привести к тому, что вы попадете в состояние «недостаточно памяти» задолго до того, как достигнете этой отметки.

  • RIP-относительная адресация в x64 может, в некоторых случаях, уменьшить размер исполняемого образа . Хотя это не относится непосредственно к приложениям .NET, оно может влиять на совместное использование библиотек DLL, которые в противном случае, возможно, придется переместить. Мне было бы интересно узнать, есть ли у кого-либо какая-либо конкретная информация по этому поводу в отношении .NET и управляемых приложений.

Помимо этого, x64-версия среды выполнения .NET, по-видимому, по крайней мере в текущих версиях выполняет больше оптимизаций, чем эквивалент x86. Такие вещи, как встраивание и выравнивание памяти, кажется, происходят гораздо чаще. Фактически, недавно была ошибка, которая препятствовала встраиванию любого метода, который принимал или возвращал тип значения; Я помню, как это было исправлено в x64, а не в версии x86.

Действительно, единственный способ определить, что лучше для вашего приложения, - это выполнить профилирование и тестирование на обеих архитектурах и сравнить реальные результаты. Тем не менее, я лично использую любой процессор везде, где это возможно, и избегаю чего-либо изначально зависимого от архитектуры. Это облегчает сборку и развертывание и, как мы надеемся, станет более надежным в будущем, когда большинство пользователей начнут переходить исключительно на x64.

5 голосов
/ 29 июня 2011

С 64-разрядным приложением тесно связано то, что «приложение x64 будет использовать больше памяти», поскольку у вас 64-разрядное приложение меньше, потому что все размеры указателя удвоены, поэтому вы получаете меньше пробега из Встроенный (сверхбыстрый) кэш процессора. Вы должны получать данные из системной памяти чаще, что намного медленнее, чем L2 и даже встроенный кэш L1.

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...