Domanda

Fondamentalmente voglio sapere se l'IDE e / o il compilatore di Visual Studio nel 2010 e 2012 sono stati scritti per utilizzare un ambiente multi-core (capisco che possiamo scegliere come target ambienti multi-core in tutte le versioni usando il parallelismo, ma non è questa la mia domanda).

Sto cercando di decidere se dovrei ottenere un dual core con clock superiore o un quad core con clock inferiore, in quanto voglio provare a capire quale processore mi offrirà la migliore esperienza possibile con Visual Studio 2010 o 2012 ( v11) (compilatore ide e background).

Se stanno eseguendo la sezione più importante (compilatore in background e altre attività ide) in un core, il core verrà tagliato più rapidamente se esegue un quad core, specialmente se il compilatore in background è il compito più pesante, immagino questo sarebbe difficile separare in più di un processo, quindi anche se utilizza multi core potrebbe essere meglio andare per una CPU di clock superiore se la maggior parte dell'elaborazione è ancora destinata a verificarsi in un core (cioè la parte più significativa dell'ambiente VS).

Sono un programmatore VB, hanno apportato grandi miglioramenti alle prestazioni nel 2010 e 2012, complimenti (tranne per il design orribile della scala dei grigi e la maiuscola ovunque), ma mi piacerebbe poter usare VS senza problemi ... qualcuno ha qualche idea? Inoltre, non sono troppo preoccupato per il tempo di caricamento della soluzione, poiché codifico solo un progetto alla volta.

Grazie.

È stato utile?

Soluzione

Penso che probabilmente stai meglio con un dual core con clock superiore. Penso che VS (e la maggior parte delle app di oggi) non traggano ancora grandi vantaggi dal multi-threading. VS può avere decine di thread in esecuzione, ma solo un sottoinsieme di operazioni ne sfrutta davvero bene, penso. Gran parte dell'implementazione VS sono componenti COM C ++ eseguiti sul thread STA, quindi il thread dell'interfaccia utente svolge gran parte del lavoro in molti scenari. Il fatto che molti pezzi della shell VS vengano riscritti in codice gestito come parte di VS2010 contribuirà a rompere molte più di queste antiche dipendenze STA componenti. Come altri hanno già detto, alcuni scenari chiave (come la creazione di una soluzione di grandi dimensioni) sfruttano già più core (MSBuild funziona bene in parallelo), quindi se quelli dominano ciò che ti interessa, allora più core è meglio. Ma per cose come l'utilizzo dell'interfaccia utente IDE e la compilazione in background, penso che la maggior parte di questi siano ancora prevalentemente a thread singolo. Ho una scatola quad-core al lavoro e raramente vedo che VS2008 utilizza più del 25% delle risorse della mia CPU. (Non ho usato VS2010 abbastanza sul serio per sapere quali scenari sono migliori, anche se so che almeno alcuni sono migliori.)

Altri suggerimenti

MSBuild supporta la costruzione di progetti in parallelo. Visual Studio 2008 sfrutta più processori per compilare progetti .

Come altri hanno notato, MSVS 2010 utilizza effettivamente più processi per la compilazione. Tuttavia, non si converte automaticamente in tempo di compilazione fortemente ridotto. Ho appena fatto un test con un progetto C ++ di medie dimensioni (circa 200 file). Costruito più velocemente su Dual Core a 3,4 Ghz rispetto a Quad Core a 2,8 Ghz. Sebbene il processore Dual Core sia più economico. (I sistemi sono praticamente identici a 4GiB DDR2 Ram ciascuno). Devo anche notare che durante la compilazione il processore Dual Core è stato caricato al 70% max. Come puoi vedere, se VS2010 non è in grado di caricare completamente anche 2 core, qual è il punto di avere 4 o più?

Dimentica la CPU. Il più grande aumento delle prestazioni che puoi dare alla tua macchina è un'unità a stato solido. I processi di compilazione e background come Resharper e Intellisense sono così intensi in termini di IO che il principale collo di bottiglia con Visual Studio è IO. Non ho mai visto VS max fuori dalla CPU, indipendentemente dal fatto che avessi core singoli, doppi o 8 core come faccio ora.

Aggiorna Grazie per il tuo commento @Erx ... Non sono un esperto degli esatti processi in corso. Tuttavia, se pensi a quante letture compila il compilatore solo per compilare un progetto, non sarai sorpreso dall'hit hit. Visual Studio può contenere file in memoria, ma hai notato che quando si crea un progetto e si hanno modifiche non salvate, i file vengono salvati prima che inizi la compilazione? Questo mi dice che il compilatore msbuild sta accedendo ai file salvati e che non usa i file in memoria. Se hai chiuso un file in VS, non vi è alcuna garanzia che il file sia ancora in memoria poiché potrebbe essere stato ripulito dalla gestione della memoria di VS. Quindi ha senso che il compilatore ottenga una copia pulita. Possono essere molte centinaia o migliaia di file. Poi c'è la scrittura dell'output compilato, le letture del pacchetto NuGet, gli script ConfigGen ( http://configgen.codeplex.com/). Ottieni l'immagine.

Inoltre, ho letto da qualche parte che Intellisense esegue molte operazioni di lettura e scrittura sul file system, quindi sarà un successo aggiuntivo se si dispone di un HDD lento.

Plugin come Resharper colpiscono anche il file system, in particolare con la compilazione in background. Non consiglierei mai di rimuovere Resharper in quanto è il miglior strumento di produttività disponibile. Quindi lo ripeterò, se sei schizzato su un nuovo sistema di fantasia con l'ultimo numero di core disponibili e enormi quantità di RAM, spendi un paio di centinaia di dollari / £ 100 su un nuovo SSD. Non te ne pentirai.

Inoltre, controlla la palude di Scott Guthrie sull'argomento http://weblogs.asp.net/scottgu/archive/2007/11/01/tip-trick-hard-drive-speed-and-visual-studio- performance.aspx In particolare, cito: " ... ove necessario, comprometti l'acquisto di ulteriore velocità del processore CPU a favore di investimenti in un disco più veloce invece " ;. Se qualcuno dovesse sapere che ti aspetteresti che il capo del team di sviluppo di Visual Studio lo sappia.

Una cosa da considerare sarebbe l'uso della virtualizzazione nel tuo ambiente di sviluppo. la virtualizzazione fa sicuramente uso di più core indipendentemente dal fatto che Visual Studio lo faccia. Ho più ambienti di sviluppo ognuno con la propria VM.

La domanda è stata modificata per menzionare VS2012, ma la maggior parte delle risposte risale a prima che fosse rilasciato. VS2012 ha introdotto le build parallele come una funzionalità standard . Quindi, ci sono migliori opportunità di utilizzare facilmente più core su una CPU capace. Tuttavia, come accennato in precedenza, se vuoi brevi tempi di compilazione è essenziale un disco rigido veloce, preferibilmente un SSD di fascia alta.

C'è qualche dibattito sul fatto che il disco rigido o la CPU sia l'investimento migliore, ma il miglioramento di entrambi dovrebbe avere un grande impatto. Nella maggior parte dei mercati il ??costo del tempo degli sviluppatori supera di gran lunga i costi dell'hardware, quindi di solito è meglio acquistare la CPU e il disco rigido migliori che è possibile. L'unica cosa da considerare è la legge dei rendimenti decrescenti ai massimi livelli.

Citazione dell'articolo riguardante build parallele su VS2012:

  

Visual Studio 2010 includeva un'opzione per il "numero massimo di parallelo"   build del progetto. " Sebbene non vi fosse alcuna indicazione di alcuna restrizione,   questa opzione IDE ha funzionato solo per progetti C ++. Fortunatamente questo   la restrizione non si applica più a Visual Studio 11. Piuttosto, ora c'è   pieno supporto per build parallele anche in altre lingue. Vedere   questo, esegue una copia di Process Explorer allo stesso tempo una soluzione con   numerosi progetti stanno costruendo. Vedrai più MSBuild   vengono create istanze - quante ne sono state specificate nel numero massimo "   di build di progetti parallele. "

Autorizzato sotto: CC-BY-SA insieme a attribuzione
Non affiliato a StackOverflow
scroll top