¿Visual Studio 2008, 2010 o 2012 (v11) fue escrito para usar múltiples núcleos?
https://stackoverflow.com/questions/1814015
-
06-07-2019 - |
italiano
english
français
española
中国
日本の
العربية
Deutsch
한국어
Português
RussianPregunta
Básicamente quiero saber si el IDE y / o el compilador de Visual Studio en 2010 y 2012 fue escrito para hacer uso de un entorno multinúcleo (entiendo que podemos apuntar a entornos multinúcleo en todas las versiones usando paralelismo, pero esa no es mi pregunta).
Estoy tratando de decidir si debo obtener un doble núcleo de reloj más alto o un núcleo cuádruple de reloj más bajo, ya que quiero tratar de averiguar qué procesador me dará la mejor experiencia absoluta posible con Visual Studio 2010 o 2012 ( v11) (ide y compilador de fondo).
Si están ejecutando la sección más importante (compilador de fondo y otras tareas ide) en un núcleo, entonces el núcleo se cortará más rápido si ejecuta un núcleo cuádruple, especialmente si el compilador de fondo es la tarea más pesada, me imagino que esto sería difícil separar en más de un proceso, por lo que incluso si usa múltiples núcleos, es mejor que opte por una CPU de mayor reloj si la mayor parte del procesamiento todavía tiene lugar en un núcleo (es decir, la parte más importante del entorno VS).
Soy un programador de VB, han realizado grandes mejoras de rendimiento en 2010 y 2012, felicidades (excepto por el horrible diseño de escala de grises y mayúsculas en todas partes), pero me encantaría poder usar VS sin problemas ... ¿Alguien tiene alguna idea? Además, no me preocupa demasiado el tiempo de carga de la solución, ya que solo codifico un proyecto a la vez.
Gracias.
Solución
Creo que probablemente estés mejor con un doble núcleo de reloj más alto. Creo que VS (y la mayoría de las aplicaciones de hoy) todavía no tienen grandes ventajas de subprocesamiento múltiple. VS puede tener docenas de subprocesos en ejecución, pero solo un subconjunto de operaciones realmente los aprovecha bien, creo. Gran parte de la implementación de VS son componentes COM de C ++ que se ejecutan en el subproceso STA, por lo que el subproceso de la interfaz de usuario realiza la mayor parte del trabajo en muchos escenarios. El hecho de que muchas partes del shell VS se reescriban en código administrado como parte de VS2010 ayudará a romper muchas más de estas antiguas dependencias de componentes de STA. Como otros han mencionado, algunos escenarios clave (como construir una solución grande) ya aprovechan los múltiples núcleos (MSBuild funciona bien en paralelo), por lo que si esos dominan lo que le interesa, más núcleos son mejores. Pero para cosas como el uso de IDE UI y la compilación en segundo plano, creo que la mayoría de estos todavía son en su mayoría de un solo subproceso. Tengo una caja de cuatro núcleos en el trabajo, y rara vez veo que VS2008 use más del 25% de mis recursos de CPU. (No he usado VS2010 lo suficiente como para saber qué escenarios son mejores, aunque sé que al menos algunos son mejores).
Otros consejos
MSBuild soporta proyectos de construcción en paralelo. Visual Studio 2008 aprovecha múltiples procesadores para compilar proyectos .
Como han señalado otras personas, MSVS 2010 sí utiliza múltiples procesos para la compilación. Sin embargo, no se convierte automáticamente en un tiempo de compilación muy reducido. Acabo de hacer una prueba con un proyecto C ++ de tamaño medio (alrededor de 200 archivos). Se construyó más rápido en Dual Core a 3.4 Ghz que en Quad Core a 2.8Ghz. Aunque el procesador Dual Core es más barato. (Los sistemas son prácticamente idénticos con 4GiB DDR2 Ram cada uno). Debo señalar también que durante la compilación, el procesador Dual Core se cargó al 70% máximo. Como puede ver, si VS2010 no puede cargar completamente incluso 2 núcleos, ¿cuál es el punto de tener 4 o más?
Olvídate de la CPU. El mayor aumento de rendimiento que puede darle a su máquina es una unidad de estado sólido. Los procesos de compilación y de fondo como Resharper e Intellisense son tan intensivos en IO que el principal cuello de botella con Visual Studio es IO. Nunca he visto VS max fuera de la CPU, independientemente de si tenía un solo, doble quad u 8 núcleos como lo hago ahora.
Actualizar Gracias por tu comentario @Erx ... No soy experto en los procesos exactos que están sucediendo. Sin embargo, si piensa en cuántas lecturas hace el compilador solo para compilar un proyecto, no le sorprenderá el éxito de IO. Visual Studio puede contener archivos en la memoria, pero ¿ha notado que cuando crea un proyecto y tiene cambios sin guardar, los archivos se guardan primero antes de que comience la compilación? Esto me dice que el compilador msbuild está accediendo a los archivos guardados y que no usa los archivos en memoria. Si ha cerrado un archivo en VS, no hay garantía de que el archivo todavía esté en la memoria, ya que la administración de memoria de VS podría haberlo limpiado. Por lo tanto, tiene sentido que el compilador obtenga una copia limpia. Esto puede ser muchos cientos o miles de archivos. Luego está la escritura de la salida compilada, las lecturas del paquete NuGet, los scripts de ConfigGen ( http://configgen.codeplex.com/). Obtienes la imagen.
Además, he leído en alguna parte que Intellisense lee y escribe mucho en el sistema de archivos, por lo que será un éxito adicional en el rendimiento si tiene un HDD lento.
Los complementos como Resharper también afectan al sistema de archivos, particularmente con la compilación en segundo plano. Nunca recomendaría eliminar Resharper, ya que es la mejor herramienta de productividad disponible. Por lo tanto, reiteraré que si ha utilizado un nuevo sistema elegante con la última cantidad de núcleos disponibles y enormes cantidades de RAM, gaste un par de cientos de dólares / £ 100 en un nuevo SSD. No te arrepentirás.
Además, vea el problema de Scott Guthrie sobre el asunto http://weblogs.asp.net/scottgu/archive/2007/11/01/tip-trick-hard-drive-speed-and-visual-studio- performance.aspx Específicamente, cito: " ... donde sea necesario, intercambie la compra de velocidad de procesador de CPU adicional en lugar de invertir en un disco más rápido " Si alguien lo supiera, esperaría que el jefe del equipo de desarrollo de Visual Studio lo supiera.
Una cosa a considerar sería su uso de la virtualización en su entorno de desarrollo. La virtualización definitivamente utiliza múltiples núcleos, ya sea que Visual Studio lo haga o no. Tengo múltiples entornos de desarrollo, cada uno con su propia VM.
La pregunta se ha editado para mencionar VS2012, pero la mayoría de las respuestas datan de antes de que se publicara. VS2012 introdujo compilaciones paralelas como una característica estándar . Por lo tanto, hay una mejor oportunidad de utilizar fácilmente más núcleos en una CPU capaz. Sin embargo, como se mencionó anteriormente, si desea tiempos de compilación cortos, es esencial un disco duro rápido, preferiblemente un SSD de alta gama.
Existe cierto debate sobre si el disco duro o la CPU son la mejor inversión, pero mejorarlos debería tener un gran impacto. En la mayoría de los mercados, el costo del tiempo de desarrollo supera con creces los costos de hardware, por lo que generalmente es mejor comprar la mejor CPU y disco duro que pueda. Lo único a tener en cuenta es la ley de rendimientos decrecientes en su extremo superior.
Cita del artículo sobre compilaciones paralelas en VS2012:
Visual Studio 2010 incluyó una opción para " número máximo de paralelo construcciones de proyectos. " Aunque no hubo indicios de ninguna restricción, esta opción IDE solo funcionó para proyectos C ++. Afortunadamente, esto la restricción ya no se aplica a Visual Studio 11. Más bien, ahora hay soporte completo para compilaciones paralelas en otros idiomas también. Para ver esto, ejecute una copia de Process Explorer al mismo tiempo que una solución con Se están construyendo numerosos proyectos. Verás que múltiples MSBuild se crean instancias, tantas como se especifica en el número máximo de compilaciones de proyectos paralelos. "
