Ejecutando la aplicación .NET de 32 bits en sistema operativo de 64 bits, ¿es realmente malo?

Question

Entiendo que podemos compilar una aplicación .NET apuntando a AnyCPU lo que hará que se ejecute 32 bits en un sistema operativo de 32 bits y 64 bits en un sistema operativo de 64 bits.

Sin embargo, se informó de un error * en un sistema operativo de 64 bits en el que mi aplicación estaba dando un error y las soluciones para eso, tengo que apuntar a x86.

Ahora mi pregunta: ¿es realmente malo apuntar a x86 aunque su código se ejecute en x64? ¿De qué tipo de actuación estamos hablando? (mi aplicación es bastante intensiva en la CPU pero es realmente difícil de conseguir)

Después de todo .NET Framework se ejecutará en 32 bits, lo cual me suena mal en lugar de tomar la capacidad de direccionamiento total de x64 CPU **.

* No puedo recordar el error, pero la solución estaba dirigida específicamente a x86, y resolvió el problema.

** No estoy seguro de si es importante pero mi aplicación no utiliza ninguna variable Int64.

Answer 1

No, no está mal; De hecho, para una aplicación en la que estoy trabajando, I tiene para apuntar a x86 (ya que trae objetos COM, para los cuales el proveedor no es compatible con x64)

Answer 2

He tenido una aplicación de procesamiento de números que usaba mucho CPU (fuerza bruta para dar solución). Ejecutarlo en .NET Framework de 64 bits (8 segundos) fue aproximadamente 4 veces más rápido que 32 bits (30 segundos). Sin embargo, es solo un caso.

Answer 3

Lo que debe recordar es que para obtener un proceso de 32 bits para ejecutar en un entorno de 64 bits, el sistema tiene que hacer una traducción de direcciones de memoria para todo lo que hace. ¿Es mala? Depende del escenario Definitivamente no es tan eficiente como podría ser. Ejecutar una versión de 32 bits de IIS en un servidor x-64 es dolorosamente lento en comparación con lo que podría ser. Todo depende de cuáles sean sus necesidades de la aplicación.

Answer 4

No. Se ejecutará sin problemas. De hecho, a menudo encontramos que nuestras aplicaciones de 32 bits se ejecutan en Vista de 64 bits mejor que en Vista de 32 bits, debido al administrador de memoria del sistema operativo más reciente. Dirigirse a x86 directamente debería funcionar bien. Sin embargo, ser capaz de ejecutar de forma nativa en 64 bits tendrá otras ventajas, como la capacidad de acceder a más memoria, más registros para la CPU, etc., por lo que vale la pena poner el esfuerzo en ponerse en marcha si es posible.

Answer 5

No, no es tan malo tener que apuntar a x86 en sistemas x64. Se perderá los beneficios adicionales de x64 y terminará funcionando en la capa de emulación de 32 bits. Pero eso es mejor que estar completamente roto, y la mayoría de las aplicaciones todavía son de 32 bits.

Con .Net, la razón normal para tener que hacer esto es una dependencia en una dll nativa de 32 bits solamente. Si deja su .Net apuntado desde cualquier CPU, intentará cargar su dll de 32 bits en modo de 64 bits, lo que provocará un bloqueo. En última instancia, desea alejarse de esa dependencia para que pueda usar el modo de 64 bits. Pero para un lanzamiento, no te matará.

Answer 6

Iba a decir la mejor manera de decir con certeza si medir, pero obviamente si no se ejecuta correctamente, entonces es un poco difícil de medir.

Antes que nada, vea si hay un problema de rendimiento. Si parece que es un problema, mire si puede identificar exactamente qué hay en la aplicación que no cumple con x64. La mayoría del código .NET debe ser independiente de la plataforma, por lo que el culpable más probable es cualquier biblioteca nativa interoperacional o de terceros.

Answer 7

La respuesta es "depende."Depende de lo que haga su aplicación, si accede a la memoria mucho o no. Kevin tiene razón: el procesador tiene que hacer mucho la traducción de direcciones, pero esto probablemente no perjudicará demasiado el rendimiento de su aplicación. las instrucciones de hardware son básicamente las mismas entre x86 y amd64 y no hay mucha ineficacia suponiendo que los autores de CLR supieran lo que estaban haciendo (y estoy seguro de que lo hicieron). Es posible que vea una gran diferencia de rendimiento si está haciendo gráficos. manipulación, pero dado que esto es solo una aplicación .NET, no creo que lo estés. Para algunas tareas de cálculo numérico, puedes notar una diferencia como mencionó Mehrdad, aunque me sorprendería que lo hicieras.

All- en general, yo diría que no me preocupo por los problemas de rendimiento a menos que tenga una aplicación sensible al rendimiento. Luego, solo debe preocuparse por los problemas de rendimiento una vez que comprenda la n ature de su aplicación.

Answer 8

Si usa las estructuras asignadas, y tiene cálculos de lote de 64 bits (dobles, largos), entonces verá una disminución en el rendimiento debido a que el motor de Jit de 32 bits está menos avanzado que el de 64 bits.

De lo contrario, la versión de 32 bit y 64 bit de .Net tiene un rendimiento un tanto similar.

Y también si usted no necesita exceder límite de 2 GB para su proceso que no hace necesitan 64 bits para capacidades de direccionamiento, el sistema operativo se encarga de eso para usted usando un modo especial llamado CPU Long Mode - Compatibilidad de modo secundario. (La CPU se está ejecutando en modo de 64 bits, pero usando 32 bits para el direccionamiento, para compatibilidad)

Answer 9

¿Su "error" ha sido que su código .NET utiliza un objeto COM de 32 bits?

Este caso podría ser un problema al ejecutar un proceso .NET en una arquitectura de 64 bits que se ha compilado con la configuración AnyCPU.

La razón es que el proceso se ejecutará como un proceso de 64 bits y cualquier COM componetne que se ejecute en el proceso también debe ser una versión de 64 bits. Si este no es el caso, su proceso se cerrará.

Una posible solución es establecer su plataforma de destino en x86.