가상 머신에서 더 많은 CPU 코어가 컴파일 시간을 느리게하는 이유는 무엇입니까?

[edit # 2] VMWare의 누군가가 VMWare Fusion의 사본으로 저를 때릴 수 있다면 VirtualBox와 VMWare의 비교와 같은 일을하는 것이 더 행복 할 것입니다. 어떻게 든 VMWare 하이퍼 바이저가 하이퍼 스레딩에 더 잘 맞춰질 것이라고 생각합니다 (내 답변도 참조하십시오)

궁금한 점이 있습니다. Windows 7 x64 가상 시스템에서 코어 수를 늘리면 전체 컴파일 시간 이 줄어들지 않고 늘어납니다 . 컴파일은 일반적으로 중간 부분 (포스트 종속성 매핑)에서와 같이 병렬 처리에 매우 적합합니다. 링커가 취할 부분 객체를 만들기 위해 각 .c / .cpp / .cs / whatever 파일에서 컴파일러 인스턴스를 호출 할 수 있습니다 위에. 그래서 컴파일은 실제로 # 개의 코어로 확장 될 것이라고 상상했을 것입니다.

그러나 내가보고있는 것은 :

• 8 코어 : 1.89 초
• 4 코어 : 1.33 초
• 2 코어 : 1.24 초
• 1 코어 : 1.15 초

특정 벤더의 하이퍼 바이저 구현 (필자의 경우 type2 : virtualbox) 또는 하이퍼 바이저 구현을 더 단순하게 만들기 위해 더 많은 VM에 더 널리 퍼져있는 설계 아티팩트입니까? 너무 많은 요인으로, 나는이 행동과 반대되는 주장을 할 수있는 것 같습니다. 그래서 누군가가 나보다 이것에 대해 더 많이 알고 있다면, 나는 당신의 대답을 읽고 싶어합니다.

감사합니다 시드

[ 편집 : 주소록 주석 ]

@MartinBeckett : 콜드 컴파일이 삭제되었습니다.

@MonsterTruck : 직접 컴파일 할 오픈 소스 프로젝트를 찾을 수 없습니다. 좋을 것이지만 지금 내 개발 환경을 망칠 수는 없습니다.

@Mr Lister, @philosodad : VirtualBox를 사용하여 8 개의 hw 스레드가 있으므로 에뮬레이션없이 1 : 1 매핑이어야합니다.

@Thorbjorn : VM에 6.5GB가 있고 작은 VS2012 프로젝트가 있습니다. 페이지 파일을 휴지통에 넣거나 버릴 가능성이 거의 없습니다.

@All : 누군가 오픈 소스 VS2010 / VS2012 프로젝트를 가리킬 수 있다면 내 (독점) VS2012 프로젝트보다 커뮤니티 참조가 더 좋습니다. 오차드와 DNN은 VS2012에서 컴파일하기 위해 환경 조정이 필요한 것 같습니다. VMWare Fusion을 사용하는 사람이 이것을 볼 수 있는지 정말로 알고 싶습니다 (VMWare 대 VirtualBox 구획화).

테스트 세부 사항 :

• 하드웨어 : Macbook Pro Retina
  • CPU : Core i7 @ 2.3Ghz (쿼드 코어, 하이퍼 스레드 = Windows 작업 관리자의 8 코어)
  • 메모리 : 16GB
  • 디스크 : 256GB SSD
• 호스트 OS : Mac OS X 10.8
• VM 유형 : VirtualBox 4.1.18 (유형 2 하이퍼 바이저)
• 게스트 OS : Windows 7 x64 SP1
• 컴파일러 : 3 개의 C # Azure 프로젝트로 솔루션을 컴파일하는 VS2012
  • 'VSCommands'라는 VS2012 플러그인으로 컴파일 시간 측정
  • 모든 테스트는 5 번 실행되며 처음 2 번은 삭제되고 마지막 3 번은 평균

답변 : 속도가 느려지지 않으며 CPU 코어 수에 따라 확장됩니다. 원래의 질문에 사용 된 프로젝트는 (실제로 A의 '너무 작은'이었다 톤 멀티 코어의 이점을 얻을 수있는 개발하지만, 컴파일러 최적화 된 소 / 중). 작업을 퍼 뜨리고 여러 컴파일러 프로세스를 생성하는 방법을 계획하는 대신이 소규모로 작업을 직렬로 진행하는 것이 가장 좋습니다.

이것은 질문에 대한 의견과 개인적 호기심을 바탕으로 한 새로운 실험을 기반으로합니다. Umbraco CMS의 소스 코드 는 규모가 크고 오픈 소스이므로 솔루션 파일을 직접로드하고 다시 빌드 할 수 있기 때문에 더 큰 VS 프로젝트를 사용했습니다 (힌트 : umbraco_675b272bb0a3\src\umbraco.slnVS2010 / VS2012에서 로드 ).

지금, 내가 보는 것은 내가 기대하는 것, 즉 컴파일 스케일 업 !! 글쎄, 내가 찾은 이후 특정 지점으로 :

테이크 아웃 :

• 새로운 VM 코어는 VirtualBox 프로세스 내에서 새로운 OS X 스레드를 만듭니다
• 컴파일 시간이 예상대로 확장됩니다 (컴파일이 충분히 길다)
• 8 개의 VM 코어에서 패널티가 엄청 나기 때문에 VirtualBox 내에서 코어 에뮬레이션이 시작될 수 있습니다 (50 % 적중)
• OS X이 4 개의 하이퍼 스레드 코어 (8 h / w 스레드)를 VirtualBox에 8 코어로 제공 할 수 없기 때문에 위의 가능성이 있습니다.

그 마지막 시점으로 인해 'Activity Monitor'(CPU 기록)를 통해 모든 코어에서 CPU 기록을 모니터링하고 내가 찾은 것은

테이크 아웃 :

• 하나의 VM 코어에서 활동은 4 개의 HW 코어에서 도약하는 것 같습니다. 코어 수준에서 균일하게 열을 분산시키는 것이 합리적입니다.

• 4 개의 가상 코어 (및 27 개의 VirtualBox OS X 스레드 또는 전체 ~ 800 OS X 스레드)에서도 HW 스레드 (0,2,4,6) 만 채도가 높은 반면 홀수 HW 스레드 (1,3,5,7) 거의 0 %에 있습니다. 스케줄러가 HW 코어 및 NOT HW 스레드 측면에서 작동하므로 OSX 64 비트 커널 / 스케줄러가 하이퍼 스레드 CPU에 최적화되어 있지 않을 것이라고 생각합니까? 아니면 8VM 코어 설정을 살펴보면 CPU 사용률이 높은 %에서 사용하기 시작합니까? 재미있는 일이 하나 있습니다 ... 글쎄, 그것은 일부 다윈 개발자에게는 별도의 질문입니다 ...

[편집] : VMWare Fusion에서 동일하게 시도하고 싶습니다. 그다지 나쁘지 않을 것입니다. 그들이 이것을 상용 제품으로 선보일 지 궁금합니다 ...

보행인:

이미지가 사라지면 컴파일 타임 테이블은 (text, ugly!)입니다.

Cores in    Avg compile      Host/OSX    Host/OSX CPU
   VM         times (sec)   Threads      consumption
    1           11.83            24        105-115%
    2           10.04            25        140-190%
    4            9.59            27        180-270%
    8           14.18            31        240-430%

이 일이 발생하는 이유는 단 하나뿐입니다. 즉 오버 헤드가 이익을 초과하기 때문입니다.

호스트 시스템에서 실제 코어 나 프로세스 또는 스레드를 할당하지 않고 여러 코어를 에뮬레이션 할 수 있습니다. 그것은 나에게 가능성이있는 것 같고, 분명히 당신에게 부정적인 속도 향상을 줄 것입니다.

또 다른 가능성은 프로세스 자체가 제대로 병렬화되지 않고 병렬화를 시도하더라도 얻는 것보다 통신 오버 헤드가 더 많이 든다는 것입니다.

당신은 혼자가 아닙니다 ...

Java에서 Maven 3.x를 사용하여 i3에서 컴파일하는 것과 동일한 일이 발생했습니다. 스레드를 기본값으로 "4"로 설정 하면 명시 적으로 2 개의 코어 만 사용하도록 지시하는 것보다 훨씬 느리고 50 % 정도 느립니다.

하이퍼 스레딩 컨텍스트 전환 및 겹치는 I / O와 관련이 있다고 생각합니다.

당신이 그것에 대해 생각하기 시작하면 의미가 있습니다. 우수한 시스템 전체 프로파일 링 도구를 사용하여 결과의 ​​성능 저하 원인을 증명할 수 있습니다.