DNM+ Online
dotnetmania 2.0
Programando para 64 bits con .NET Framework 2.0
Por primera vez, y con la reciente salida de la versión 2005 de Visual Studio, Microsoft tiene una bonita historia que contar en torno a los 64 bits. Los compiladores para el .NET Framework 2.0 son los primeros capaces de generar código MSIL optimizado para plataformas de 64 bits, tanto para procesadores Itanium como los basados en tecnología extendida x64.

La arquitectura de los 64 bits
La transición de 32 a 64 bits es tan inminente e inevitable como fue en su momento la de 16 a 32 bits, aunque afortunadamente ya podemos anticipar que no será tan compleja, sobre todo para aplicaciones desarrolladas con código manejado. Las ventajas de los 64 bits son varias: desde poder direccionar hasta 8 TB (sí, ¡TeraBytes!) frente a los clásicos 3 GB de los procesadores de 32 bits, incluso permitir escalar verticalmente nuestro servidor hasta nuevos límites. Un ejemplo: este incremento de memoria permite al sistema operativo pasar de un máximo de 115.000 conexiones TCP/IP simultáneas a más de 1.000.000 en Windows Server 2003. En un escenario de un servidor Web con ASP.NET, el cambio a 64 bits no supondría sólo ventajas para nuestra aplicación en cuanto al uso de memoria, sino sobre todo en el rendimiento y escalabilidad de nuestra Web. Dentro de los sistemas de 64 bits podemos diferenciar dos arquitecturas completamente diferentes, cada una con sus ventajas e inconvenientes, pero sobre todo destinadas a dos escenarios claramente diferenciados. Es fundamental conocer cuáles son nuestros objetivos y prioridades antes de decantarnos por una u otra arquitectura. Por un lado nos podemos encontrar con los sistemas basados en procesadores extendidos, los conocidos como x64, basados en la tecnología EM64T (Extended Memory 64 Technology). Ejemplos de éstos son los sistemas basados en Intel Xeon, Pentium 4 x64 o AMD Athlon 64 entre otros. Son procesadores que mantienen su núcleo de 32 bits pero incorporan un conjunto de instrucciones extendidas que le permiten ejecutar código de 64 bits. Estos sistemas nos permiten acceder a las ventajas de los 64 bits pero manteniendo la habilidad de ejecutar código 32 bits de forma nativa con el rendimiento habitual. Por otro lado podremos encontrar procesadores nativos de 64 bits, los conocidos como IPF (Itanium Pentium Family) o IA64 y basados en la tecnología EPIC (Explicit Parallel Instruction Computing). Son procesadores con arquitectura completamente diferente a los x86 o x64, mucho más potentes y capaces de ejecutar hasta 6 instrucciones en paralelo. El inconveniente de estos procesadores es que no pueden ejecutar código de 32 bits de forma nativa, así que esta ejecución de código de 32 bits se realiza a nivel del sistema operativo mediante un subsistema de emulación conocido como WoW64 (Windows 32 on Windows 64). Por desgracia, el impacto de este subsistema de emulación en el rendimiento es bastante elevado. Los procesadores con tecnología extendida x64 están destinados principalmente a estaciones de trabajo con grandes necesidades de rendimiento, direccionamiento de memoria, o precisión en operaciones de coma flotante, como por ejemplo aplicaciones de diseño gráfico CAD, de cálculos de ingeniería, o simplemente para entusiastas de videojuegos o sistemas multimedia. En el caso de los procesadores IA64 o Itanium, su uso está principalmente destinado a servidores de backend como bases de datos (existe una versión de SQL Server 2000 y 2005 para IA64), servidores de componentes de 64 bits, o servidores de aplicaciones Web para 64 bits. Como vemos, el mensaje es claro. Los procesadores Itanium están diseñados principalmente para ejecutar código nativo en 64 bits, no de 32 bits. Generación de código para 64 bits con Visual Studio 2005 El IDE de Visual Studio 2005 sigue siendo una aplicación de 32 bits, aunque por primera vez soportada en WoW64. Esto quiere decir que ya podemos instalarlo directamente en máquinas Itanium, aunque mi recomendación personal es no hacerlo y seguir desarrollando sobre estaciones de trabajo de 32 bits. En este caso, el modelo de desarrollo recomendado es mediante despliegues y depuración remota sobre la máquina Itanium. De todas formas, aunque despleguemos el IDE en la misma máquina, si intentamos depurar código nativo de 64 bits, nos encontraremos con el IDE ejecutando bajo 32 bits y la aplicación a depurar en 64 bits, con lo cual internamente se utilizará depuración remota aún dentro de una misma máquina, ya que código de 32 y 64 bits no pueden convivir en un mismo proceso. Lo que sí cambian son los compiladores. Tanto en C# como en Visual Basic 2005 podemos generar código manejado para 64 bits. ¿Pero no habíamos quedado en que el código MSIL era código intermedio independiente de la plataforma? ¿por qué tenemos entonces que volver a recompilar para 64 bits? Efectivamente el código MSIL que generamos con la configuración por defecto (anyCPU) es agnóstico a la plataforma. Este código puede ser ejecutado en cualquier tipo de procesador, ya que el JITter generará código nativo sobre la marcha. En el caso de máquinas de 64 bits, se ejecutará sobre el Framework 2.0 para 64 bits, con lo cual el rendimiento será mayor. Sin embargo, esto ya era posible con el código generado mediante Visual Studio 2003, aunque era ejecutado sobre una versión del Framework 1.0 o 1.1 corriendo en 32 bits bajo WoW64, con lo cual el rendimiento era incluso inferior que en máquinas nativas de 32 bits. La gran novedad es la posibilidad que tenemos ahora con Visual Studio 2005 de especificar como target en la configuración de compilación tanto procesadores Itanium (IA64) como Extendidos (x64). En este caso, el código MSIL generado estará optimizado para que el JITter de dichas plataformas sea capaz de generar código nativo optimizado para ese procesador, por ejemplo haciendo así uso de las nuevas capacidades de Itanium para ejecutar instrucciones simultáneamente. El incremento del rendimiento de nuestra aplicación en estos casos es notable. Así pues y con todo lo visto, podemos decir que en la mayoría de los casos, portar nuestras aplicaciones .NET a 64 bits consiste simplemente en cambiar el target de la configuración de compilación y recompilar. Obviamente el escenario se complica si tenemos dependencias de código de 32 bits, tanto en componentes COM accedidos mediante COM Interop, como en DLL nativas referenciadas mediante Platform Invoke. En el caso de que tengamos acceso al código de estos componentes, la recomendación es recompilarlos también en 64 bits. En el caso de que no tengamos acceso al código fuente o podamos recompilar los componentes en 64 bits, tendremos que exponerlos a nuestro proceso manejado de 64 bits mediante un proceso wrapper de 32 bits y realizar la comunicación mediante mecanismo IPC (InterProcess Communication). Si nuestro componente es COM, bastará con registrarlo en COM+ como servidor, así será la propia plataforma de COM+ quien nos lo exponga a nuestro código manejado mediante un proceso de 32 bits. Si el componente es una DLL nativa, por ejemplo en C o C++, tendremos que hacer un wrapper nosotros mismos, por ejemplo mediante un Server ATL que lo encapsule y exponga el mismo contrato mapeado. ¡Animaos! Sólo tenéis que cambiar una opción de la configuración de Visual Studio y recompilar para 64 bits. Ahora ya sólo nos falta una máquina de 64 bits para poder ejecutarlo :-).

blog comments powered by Disqus
autor
referencias