visual studio programacion microsoft español descargar community c++ windows 64bit

c++ - programacion - visual studio community



¿Hay algún punto real compilando una aplicación de Windows como de 64 bits? (12)

Crearlos como de 64 bits ahora, incluso si nunca libera la compilación, puede ayudarlo a encontrar y reparar los problemas que encontrará más adelante cuando se vea obligado a compilar y lanzar como de 64 bits.

Yo diría con confianza que el 99% de las aplicaciones que escribimos no necesitan ocuparse de más de 2 Gb de memoria. Por supuesto, hay muchos beneficios obvios para el sistema operativo que ejecuta 64 bits para abordar más RAM, pero ¿existe alguna razón en particular para compilar una aplicación típica de 64 bits?


Cuando dice que el 99% de las aplicaciones no se beneficiarán de 64 bits, eso puede ser cierto para usted personalmente, pero durante el día utilizo Visual Studio y Xcode para compilar C ++ con una base de código grande, busque en los repositorios de varios Gb con Google Desktop y Spotlight. Luego llego a casa para escribir música usando un secuenciador que usa varias bibliotecas de sonido de Gb, y hago una sesión de fotos en mis 20Gb de fotos, y tal vez hago un poco de edición de video con mis clips de vacaciones.

Así que para mí (y me atrevo a decir que muchos otros usuarios), tener una versión de 64 bits de muchas de estas aplicaciones será una gran ventaja. Procesador de textos, navegador web, cliente de correo electrónico: tal vez no. Pero cualquier cosa relacionada con los grandes medios realmente se beneficiará.


Hay mejoras de rendimiento que se pueden ver con 64 bits. Un buen ejemplo es que algunos parámetros en las llamadas de función se pasan a través de registros (menos cosas para empujar en la pila).

Editar Revisé algunas de mis notas anteriores de cuando estaba estudiando algunas de las diferencias de ejecución de nuestro producto con una compilación de 64 bits en comparación con una compilación de 32 bits. Corrí las pruebas en una máquina de 64 bits de cuatro núcleos. Así que está la cuestión de comparar manzanas con naranjas, ya que los 32 bits se ejecutaban bajo el modo de emulación, obviamente. Sin embargo, parece que muchas cosas que leo de esta forma, por ejemplo, dicen constantemente que la velocidad alcanzada para WOW64 no es significativa. Pero incluso si esa afirmación no es cierta, es casi seguro que su aplicación se ejecute en un sistema operativo de 64 bits. Por lo tanto, tiene valor una comparación de una construcción de 32 bits frente a 64 bits en una máquina de 64 bits.

En las pruebas que realicé (ciertamente no completas), no encontré ningún caso en el que la compilación de 32 bits fuera más rápida. Sin embargo, muchas de las operaciones intensivas de SQL que ejecuté (alta CPU y alta E / S) fueron de un 20% a un 50% más rápidas cuando se ejecutaron con la compilación de 64 bits. Estas pruebas involucraron algunas sentencias de SQL bastante “feas” y también algunas pruebas de TPCC con alta concurrencia. Por supuesto, mucho depende bastante de los conmutadores del compilador, por lo que necesita hacer sus propias pruebas.


No subestime el valor de marketing de ofrecer una versión nativa de 64 bits de su producto.

Además, es posible que se sorprenda de cuánta gente trabaja en aplicaciones que requieren la mayor cantidad de memoria posible.


Podrías considerarlo como una prueba de futuro. Puede estar muy lejos, pero considere algunos años en el futuro, donde los sistemas operativos y las CPU de 64 bits son ubicuos (considere cómo se desvanecieron los 16 bits cuando se hizo cargo de los 32 bits). Si su aplicación es de 32 bits y todos sus competidores han pasado a 64 bits para entonces, su aplicación podría ser vista (o acusada por sus competidores como) obsoleta, más lenta o incapaz de cambiar. Tal vez incluso un día el soporte para aplicaciones de 32 bits se eliminará o será incompleto (¿Windows 7 puede ejecutar aplicaciones de 16 bits de manera adecuada?). Si ya está compilando una versión de 64 bits de su aplicación, evitará estos problemas. Si lo pospones hasta más tarde, podrías escribir mucho más código entre ahora y cuando lo transfieras, entonces tu puerto será aún más difícil.

Para muchas aplicaciones, no hay muchas razones técnicas convincentes, pero si es fácil, la conversión ahora puede ahorrarle esfuerzo en el futuro.


Se pueden procesar más datos por ciclo de reloj, lo que puede ofrecer mejoras de rendimiento a, por ejemplo, aplicaciones criptográficas, de codificación de video, etc.


Si no necesita el espacio de direcciones extendido, la entrega en modo de 64 bits no ofrece nada y tiene algunas desventajas como aumentar el consumo de memoria y la presión del caché.

Si bien ofrecemos versiones de 64 bits, nuestros clientes que están en el límite nos están presionando para reducir el consumo de memoria para que obtengan estas ventajas.


Todas las aplicaciones que pueden necesitar mucha memoria: servidores de base de datos que desean almacenar muchos datos en la memoria, aplicaciones científicas que manejan muchos datos, ...


Yo diría que solo hazlo si necesitas más de 2GB.

Una cosa es la compilación de 64 bits significa (obviamente) punteros de 64 bits. Eso significa que el código y las estructuras de datos se vuelven un poco más grandes, lo que significa que la aplicación. se beneficiará un poco menos del caché y llegará a la memoria virtual un poco más a menudo, etc.

Por lo tanto, si no lo necesita, el efecto básico es hacer que su aplicación sea un poco más lenta y más hinchada sin ninguna razón.

Dicho esto, a medida que pase el tiempo, le importarán más los 64 bits de todos modos, simplemente porque para eso se escribirán todas las herramientas y bibliotecas, etc. Incluso si su aplicación puede vivir felizmente en 64K, es poco probable que use un código de 16 bits; las ganancias no importan (es una aplicación pequeña y rápida de todos modos) y ciertamente están superadas por la molestia involucrada. Con el tiempo, veremos 32 bits de la misma manera.


x64 tiene ocho registros de propósito general más que no están disponibles cuando se ejecuta código de 32 bits. Eso es tres veces más (el doble si contamos ESI, EDI, EBP y ESP como propósito general; no lo hago). Eso puede ahorrar una gran cantidad de cargas y tiendas en funciones que usan más de cuatro variables.


Fastcall hace que las subrutinas de llamada sean más rápidas al mantener los primeros cuatro parámetros en los registros.


Recientemente he leído este artículo, Optimización de software en C ++ . En el capítulo 2.3 Choice of operating system hay una comparación entre ventajas y desventajas del sistema de 64 y 32 bits, con algunas observaciones específicas con respecto a Windows.

Mark Wilkins ya notó en este hilo sobre más registros para llamadas de función. Otra propiedad interesante del sistema de 64 bits es esta:

The SSE2 instruction set is supported on all 64-bit CPUs and operating systems.

Las instrucciones de SSE2 pueden proporcionar optimizaciones excelentes y se están utilizando cada vez más, por lo que, en mi opinión, esta es una característica notable.