문제

기본적으로 2010년과 2012년의 Visual Studio IDE 및/또는 컴파일러가 멀티 코어 환경을 활용하려면(병렬성을 사용하여 모든 버전에서 멀티 코어 환경을 목표로 삼을 수 있다는 것을 알고 있지만 그건 내 질문이 아닙니다).

저는 어떤 프로세서가 Visual Studio 2010 또는 2012(v11)에서 가능한 최고의 경험을 제공할 수 있는지 알아보고 싶어서 더 높은 클럭의 듀얼 코어를 선택해야 할지, 더 낮은 클럭의 쿼드 코어를 선택해야 할지 결정하려고 합니다( ide 및 백그라운드 컴파일러).

하나의 코어에서 가장 중요한 섹션(백그라운드 컴파일러 및 기타 IDE 작업)을 실행하는 경우 쿼드 코어를 실행하면 코어가 더 빨리 끊어집니다. 특히 백그라운드 컴파일러가 가장 무거운 작업인 경우 이것이 어려울 것이라고 생각합니다. 둘 이상의 프로세스로 분리하기 때문에 멀티 코어를 사용하더라도 대부분의 처리가 여전히 하나의 코어에서 발생해야 한다면 더 높은 클럭 CPU를 사용하는 것이 더 나을 수 있습니다(예:VS 환경의 가장 중요한 부분).

저는 VB 프로그래머입니다. 그들은 2010년과 2012년에 엄청난 성능 향상을 이루었습니다. 축하합니다(끔찍한 회색조 디자인과 모든 곳에 대문자가 있는 것을 제외하고). 그러나 VS를 원활하게 사용할 수 있기를 바랍니다...누구 아이디어 있어?또한 한 번에 하나의 프로젝트만 코딩하므로 솔루션 로드 시간에 대해 크게 걱정하지 않습니다.

감사해요.

도움이 되었습니까?

해결책

아마도 더 높은 클럭의 듀얼 코어를 사용하는 것이 더 나을 것이라고 생각합니다.내 생각에 VS(그리고 오늘날 대부분의 앱)는 아직 멀티스레딩의 큰 이점을 활용하지 못하고 있습니다.VS에는 수십 개의 스레드가 실행될 수 있지만 작업의 하위 집합만이 실제로 스레드를 잘 활용한다고 생각합니다.VS 구현의 전체 부분은 STA 스레드에서 실행되는 C++ COM 구성 요소이므로 UI ​​스레드는 여러 시나리오에서 대부분의 작업을 수행합니다.VS 셸의 많은 부분이 VS2010의 일부로 관리 코드로 다시 작성된다는 사실은 이러한 고대 구성 요소 STA 종속성을 훨씬 더 많이 깨뜨리는 데 도움이 될 것입니다.다른 사람들이 언급했듯이 일부 주요 시나리오(예: 대규모 솔루션 구축)는 이미 다중 코어를 활용하고 있으므로(MSBuild는 병렬로 잘 작동함) 이러한 것이 관심 있는 항목을 지배한다면 더 많은 코어가 더 좋습니다.하지만 IDE UI 사용 및 백그라운드 컴파일과 같은 작업의 경우 대부분이 여전히 단일 스레드인 것 같습니다.저는 직장에 쿼드 코어 상자를 가지고 있는데 VS2008이 내 CPU 리소스의 25% 이상을 사용하는 경우는 거의 없습니다.(저는 VS2010을 본격적으로 사용하여 어떤 시나리오가 더 나은지 알 수는 없지만 적어도 몇 가지 시나리오는 더 낫다는 것을 알고 있습니다.)

다른 팁

MSBuild는 프로젝트 빌드를 병렬로 지원합니다.Visual Studio 2008은 다중 프로세서를 활용하여 프로젝트 컴파일.

다른 사람들이 지적했듯이 MSVS 2010은 실제로 컴파일을 위해 여러 프로세스를 사용합니다.하지만 컴파일 시간이 크게 단축되는 방식으로 자동 변환되지는 않습니다.방금 중간 크기의 C++ 프로젝트(약 200개 파일)로 테스트를 수행했습니다.2.8Ghz의 쿼드 코어보다 3.4Ghz의 듀얼 코어에서 더 빠르게 구축되었습니다.듀얼 코어 프로세서가 더 저렴하지만.(시스템은 각각 4GiB DDR2 Ram과 실질적으로 동일합니다.)또한 컴파일하는 동안 듀얼 코어 프로세서가 최대 70%로 로드되었다는 점에 유의해야 합니다.보시다시피 VS2010이 2개의 코어도 완전히 로드할 수 없다면 4개 이상의 코어를 갖는 것이 무슨 의미가 있습니까?

CPU는 잊어버리세요.컴퓨터에 제공할 수 있는 가장 큰 성능 향상은 솔리드 스테이트 드라이브입니다.Resharper 및 Intellisense와 같은 컴파일 및 백그라운드 프로세스는 IO 집약적이므로 Visual Studio의 주요 병목 현상은 IO입니다.지금처럼 싱글, 듀얼 쿼드, 8코어 등 VS가 CPU 성능을 최대화하는 것을 본 적이 없습니다.

업데이트@Erx님 의견 감사드립니다...나는 현재 진행되고 있는 정확한 프로세스에 대해 전문가가 아닙니다.그러나 프로젝트를 컴파일하기 위해 컴파일러가 수행하는 읽기 횟수를 생각하면 IO 적중이 놀라지 않을 것입니다.Visual Studio는 파일을 메모리에 보관할 수 있지만 프로젝트를 빌드할 때 저장되지 않은 변경 내용이 있으면 빌드가 시작되기 전에 파일이 먼저 저장된다는 사실을 알고 계셨나요?이는 msbuild 컴파일러가 저장된 파일에 액세스하고 있으며 메모리 내 파일을 사용하지 않는다는 것을 알려줍니다.VS에서 파일을 닫은 경우 VS의 메모리 관리에 의해 파일이 정리되었을 수 있으므로 파일이 여전히 메모리에 있다는 보장이 없습니다.따라서 컴파일러가 깨끗한 복사본을 얻는 것이 합리적입니다.이는 수백 또는 수천 개의 파일일 수 있습니다.그런 다음 컴파일된 출력 쓰기, NuGet 패키지 읽기, ConfigGen 스크립트(http://configgen.codeplex.com/).당신은 그림을 얻습니다.

또한 Intellisense가 파일 시스템에 대해 많은 읽기 및 쓰기를 수행하므로 HDD 속도가 느린 경우 성능에 추가 타격이 될 것이라는 내용을 어딘가에서 읽었습니다.

Resharper와 같은 플러그인도 특히 백그라운드 컴파일의 경우 파일 시스템에 영향을 미칩니다.저는 Resharper가 최고의 생산성 도구이기 때문에 제거하는 것을 결코 옹호하지 않습니다.따라서 사용 가능한 최신 코어 수와 대용량 RAM을 갖춘 멋진 새 시스템을 구입했다면 새 SSD에 몇 백 달러/100파운드를 지출하십시오.당신은 그것을 후회하지 않을 것입니다.

또한 이 문제에 대한 Scott Guthrie의 습지를 확인하세요. http://weblogs.asp.net/scottgu/archive/2007/11/01/tip-trick-hard-drive-speed-and-visual-studio-performance.aspx 구체적으로 다음과 같이 인용합니다."...필요한 경우 더 빠른 디스크에 투자하기 위해 추가 CPU 프로세서 속도를 구입하는 것을 절충합니다."누군가가 알아야 한다면 Visual Studio 개발 팀의 책임자가 알 것이라고 기대할 것입니다.

고려해야 할 사항은 개발 환경에서 가상화를 사용하는 것입니다.가상화는 Visual Studio의 사용 여부에 관계없이 확실히 여러 코어를 사용합니다.각각 자체 VM이 있는 여러 개발 환경이 있습니다.

VS2012를 언급하도록 질문이 편집되었지만 대부분의 답변은 VS2012가 출시되기 전으로 거슬러 올라갑니다.VS2012는 병렬 빌드를 다음과 같이 도입했습니다. 표준 기능.따라서 유능한 CPU에서 더 많은 코어를 쉽게 활용할 수 있는 더 나은 기회가 있습니다.그러나 앞서 언급한 것처럼 짧은 컴파일 시간을 원한다면 빠른 하드 드라이브가 필수이며, 고급 SSD를 사용하는 것이 좋습니다.

하드 드라이브와 CPU 중 어느 것이 더 나은 투자인지에 대해서는 논쟁이 있지만 둘 중 하나를 개선하면 큰 영향을 미칠 것입니다.대부분의 시장에서 개발자 시간 비용은 하드웨어 비용보다 훨씬 크기 때문에 일반적으로 가능한 최고의 CPU와 하드 드라이브를 구입하는 것이 가장 좋습니다.고려해야 할 유일한 것은 최고 수준의 수익 감소 법칙입니다.

VS2012의 병렬 빌드에 관한 기사에서 인용:

Visual Studio 2010에는 "최대 병렬 프로젝트 빌드 수"옵션이 포함되어 있습니다. 제한 사항에 대한 표시는 없지만이 IDE 옵션은 C ++ 프로젝트에만 효과가있었습니다.다행히도이 제한은 더 이상 Visual Studio 11에 적용되지 않습니다.오히려 이제 다른 언어로 된 병렬 빌드에 대한 완전한 지원이 있습니다.이를 보려면 수많은 프로젝트가있는 솔루션이 구축되는 프로세스 탐색기 사본을 동시에 실행하십시오."최대 병렬 프로젝트 빌드 수"에 지정된대로 여러 MSBuild 인스턴스가 생성된다는 것을 알 수 있습니다.

라이센스 : CC-BY-SA ~와 함께 속성
제휴하지 않습니다 StackOverflow
scroll top