Pergunta

Basicamente eu quero saber se o Visual Studio IDE e / ou compilador em 2010 e 2012 foi escrita para fazer uso de um ambiente multi core (eu entendo que pode direcionar ambientes multi core em todas as versões usando paralelismo, mas isso não é a minha pergunta).

Eu estou tentando decidir se eu deveria ter um maior relógio dual core ou quad core relógio inferior, como eu quero tentar descobrir qual processador vai me dar a melhor experiência absoluta possível com o Visual Studio 2010 ou 2012 ( v11) (ide e compilador de fundo).

Se eles estão executando a parte mais importante (compilador de fundo e outras tarefas IDE) em um núcleo, em seguida, o núcleo vai ficar cortada mais rápido se a execução de um quad core, especialmente se compilador fundo é a tarefa mais pesada, eu iria imaginar isso seria difícil separar em mais de um processo, por isso mesmo que ele usa múltiplos núcleos você ainda pode ser melhor fora de ir para uma CPU clock maior se a maioria do processamento ainda é obrigado a ocorrer em um núcleo (ou seja, a parte mais significativa do ambiente VS).

Eu sou um programador VB, que fizeram grandes melhorias de desempenho em 2010 e 2012, parabéns (exceto para o projeto em escala de cinza horrível ea maiúscula em todos os lugares), mas eu gostaria de ser capaz de usar VS perfeitamente ... Alguém tem alguma ideia? Além disso, eu não estou muito preocupado com o tempo de carregamento solução, como eu só projeto de um código de cada vez.

Graças.

Foi útil?

Solução

Eu acho que você é provavelmente melhor fora com um de maior relógio dual core. Acho VS (e a maioria dos aplicativos de hoje) ainda não ter grandes vantagens do multi-threading. VS pode ter dezenas de threads em execução, mas apenas um subconjunto de operações realmente aproveitá-las bem, eu acho. Um monte da implementação VS é C ++ componentes COM que são executados no thread STA, de modo que o segmento interface do usuário faz a maior parte do trabalho em muitos cenários. O fato de que muitas peças do shell VS estão sendo reescrito em código gerenciado como parte de VS2010 vai ajudar a quebrar um monte mais dessas antigas dependências STA componentes. Como já foi mencionado, alguns cenários-chave (como a construção de uma solução grande) já fazem tirar proveito dos vários núcleos (MSBuild funciona bem em paralelo), por isso, se aqueles dominar o que você se preocupa, em seguida, mais núcleos é melhor. Mas para coisas como o uso de IDE UI e compilação fundo, acho que a maioria destes ainda são principalmente single-threaded. Eu tenho uma caixa de quad-core no trabalho, e eu raramente vê VS2008 uso mais de 25% dos meus recursos da CPU. (Eu não usei VS2010 o suficiente para valer a saber quais os cenários são melhores, embora eu saiba que pelo menos alguns são melhores.)

Outras dicas

MSBuild suportes construção de projetos em paralelo. Visual Studio 2008 tira proveito de múltiplos processadores para compilação projectos .

Como outras pessoas têm notado, MSVS 2010, de fato, usar vários processos de compilação. Embora, ele não converte automaticamente em tempo de compilação fortemente reduzida. Acabei de fazer um teste com um projeto de tamanho médio C ++ (cerca de 200 arquivos). Construiu mais rápido em dual core de 3,4 Ghz de Quad Core a 2.8GHz. Embora processador Dual Core é mais barato. (Sistemas são praticamente idênticos com 4GiB DDR2 Ram cada). Devo observar também, que o processador durante a compilação Dual Core foi carregado a 70% max. Como você pode ver, se VS2010 não consegue carregar totalmente até 2 núcleos, o que é o ponto de ter 4 ou mais?

Esqueça CPU. O único grande aumento de desempenho que você pode dar a sua máquina é uma unidade de estado sólido. Compilação e fundo processos como ReSharper e Intellisense são tão IO intensivo que o principal gargalo com visual studio é IO. Eu nunca vi VS máximo para fora da CPU, independentemente de eu tinha, dual quad simples ou 8 núcleos como eu faço agora.

Atualizar Obrigado pelo seu comentário @Erx ... Não sou especialista sobre os processos exatos que estão acontecendo. No entanto, se você pensar em quantas lê o compilador faz apenas para compilar um projeto, você não vai ser surpreendido pela IO atingido. Visual Studio pode armazenar arquivos na memória, mas você já reparou que quando você cria um projeto e você tem alterações não salvas, os arquivos são salvos antes de os pontapés construir fora? Isso me diz que o compilador msbuild está acessando os arquivos salvos e que ele não usa os arquivos na memória. Se você tiver fechado um arquivo no VS, não há garantia de que o arquivo ainda está na memória como poderia ter sido limpo por gerenciamento de memória do VS. Portanto, faz sentido que o compilador recebe uma cópia limpa. Isso pode ser muitas centenas ou milhares de arquivos. Depois, há a escrita de saída compilada, pacote NuGet lê, roteiros ConfigGen ( http://configgen.codeplex.com/). Você começa a foto.

em algum lugar Além disso, eu li que Intellisense faz um monte de leitura e escrita para o sistema de arquivos, de modo que vai ser um sucesso adicionado no desempenho se você tiver um disco rígido lento.

Plugins como ReSharper também atingiu o sistema de arquivos, particularmente com a compilação de fundo. Eu nunca iria defender a remoção ReSharper, pois é a melhor ferramenta de produtividade disponível. Então eu vou reiterar, se você tiver com toques em um novo sistema de fantasia com a mais recente número de núcleos disponíveis e enormes ammounts de RAM, passar um par de cem dólares / £ 100 em um novo SSD. Você não vai se arrepender.

Além disso, confira pântano de Scott Guthrie sobre o assunto http://weblogs.asp.net/scottgu/archive/2007/11/01/tip-trick-hard-drive-speed-and-visual-studio- performance.aspx Especificamente, cito: "... onde o comércio necessário fora de comprar mais velocidade do processador CPU em favor de investir em um disco mais rápido em vez". Se alguém deveria saber que você esperaria que o chefe da equipe de desenvolvimento do Visual Studio para saber.

No coisa a considerar seria o uso da virtualização em seu ambiente de desenvolvimento. virtualização definitivamente faz uso de múltiplos núcleos ou não Visual Studio faz. Eu tenho vários ambientes de desenvolvimento, cada um com seu próprio VM.

A questão foi editado mencionar VS2012, mas a maioria das respostas datam de antes, que foi lançado. VS2012 introduzido paralelo cria como um recurso padrão. Assim, não há melhor oportunidade de utilizar facilmente mais núcleos em uma CPU capaz. No entanto, como mencionado anteriormente, se você quiser curtos tempos de compilação um disco rígido rápido é essencial, de preferência um alto SSD final.

Há algum debate sobre se o disco rígido ou a CPU é o investimento melhor, mas melhorando tanto deve ter um grande impacto. Na maioria dos mercados o custo do tempo desenvolvedor supera em muito os custos de hardware de modo geral você é melhor fora de comprar a melhor CPU e disco rígido você pode. A única coisa de levar em consideração é a lei dos rendimentos decrescentes no que final muito superior.

citar o artigo sobre paralelo baseia-se em VS2012:

Visual Studio 2010 inclui uma opção para "número máximo de paralelo projecto baseia-se." Embora não houve indicação de qualquer restrição, esta opção IDE só trabalhou para projetos C ++. Felizmente, este restrição não se aplica a Visual Studio 11. Em vez disso, há agora suporte completo para paralelo cria em outros idiomas também. Ver isso, execute uma cópia do Process Explorer ao mesmo tempo uma solução com inúmeros projetos está construindo. Você verá que MSBuild múltipla instâncias são criadas - como muitos como especificado no "número máximo de projeto paralelo cria. "

Licenciado em: CC-BY-SA com atribuição
Não afiliado a StackOverflow
scroll top