Как упоминалось в этом вопросе/комментариях существуют определенные недостатки при переходе с 32-разрядного .NET на 64-разрядный .NET.
Наверное, самым большим преимуществом является гораздо более масштабное адресное пространство процесса в 64-битном мире, но какие другие плюсы и минусы стоит отметить?
Я видел, что это заметно быстрее (~ 4 раза в моем опыте) для некоторых вычислительно-тяжелых (число-хруст) приложений. Лучше всего это бесплатно в чистых управляемых случаях. Вам даже не нужно перекомпилировать что-либо, чтобы получить преимущества. Кроме того, я слышал, что x64 JIT имеет более агрессивную оптимизацию.
Самый большой недостаток, вероятно, не в состоянии загрузить 32-разрядные COM-компоненты в процессе.
Ваше приложение может работать или не работать быстрее. Я видел улучшения для некоторых приложений, но не для других. Это зависит от того, насколько ваше приложение использует 64-битные (математические) операции, и если это компенсирует большие данные и код, которые использует x64, и поэтому приходится загружать их в кэш инструкций и данных, прежде чем он сможет быть выполнен.
http://blogs.msdn.com/b/joshwil/archive/2006/07/18/670090.aspx
Это стоит прочитать. Он старый (.NET 2.0), но он все еще применяется; размеры указателей, COM-взаимодействие и т.д.:
Перенос 32-разрядного управляемого кода в 64-разрядный
Также стоит знать, что даже на x64 CLR имеет ограничение на один размер объекта 2Gb. Это не проблема для 99% сценариев, но если вы переходите к x64 предположительно, потому что вы можете работать с большими наборами данных. См. Здесь для дальнейшего обсуждения:
Ограничены ли строки С# (и другие .NET API) размером до 2 ГБ?
Итак. Если ваше приложение не использует данные, которые не вписываются в 32-разрядную память или сильно использует 64-разрядные операции, вы можете не увидеть много, если какие-либо улучшения.
Другим недостатком является то, что приложения Visual Studio для x64 имеют некоторые ограничения:
Изменить и продолжить не доступно для 64-разрядной отладки.
Вы не можете отлаживать в смешанном режиме, звонки от собственного кода до управляемого кода, или наоборот, в 64-битном коде.
Смотрите: http://msdn.microsoft.com/en-us/library/ms184681(VS.80).aspx
Примечание. 64-битные компиляторы С++ по умолчанию не установлены. Вы должны выбрать их во время установки.
Я тоже нашел это (потому что я сам оптимизирую приложение x64).
"Портирование и оптимизация приложений на 64-битной Windows для AMD64..."
http://download.microsoft.com/download/5/b/5/5b5bec17-ea71-4653-9539-204a672f11cf/AMD64_PortApp.doc
Имеет много хороших указателей на коммутаторах компилятора и т.п.
64-битные приложения не всегда будут работать быстрее 32-битных.
Об этом говорится в двух постах ниже:
https://blogs.msdn.microsoft.com/rmbyers/2009/06/09/anycpu-exes-are-usually-more-trouble-than-theyre-worth/
Большие указатели означают больше памяти и потребление кеша и количество байт доступного кеша процессора одинаково для 32-битных и 64-битных процессы.
http://blogs.msdn.com/ricom/archive/2009/06/10/visual-studio-why-is-there-no-64-bit-version.aspx
64-битное адресное пространство для процесса не собирается помочь вам со страницей неисправности, за исключением, возможно, косвенных способов, и это определенно повредит вам в прямые пути, потому что ваши данные больше. В отличие от 64 бит операционная система может вам очень помочь! Если вы работаете как 32-битное приложение на 64-битная ОС, тогда вы получите все 4G адресное пространство и все это может быть опираясь на физическую память (если у вас есть ОЗУ) даже без вас использовать 64 бит указывает на себя.