Mengapa lebih banyak core CPU pada mesin virtual memperlambat waktu kompilasi?


17

[edit # 2] Jika ada orang dari VMWare yang dapat memukul saya dengan salinan VMWare Fusion, saya akan dengan senang hati melakukan hal yang sama dengan perbandingan VirtualBox vs VMWare. Entah bagaimana saya menduga hypervisor VMWare akan lebih baik disetel untuk hyperhreading (lihat jawaban saya juga)

Saya melihat sesuatu yang aneh. Ketika saya meningkatkan jumlah core pada mesin virtual Windows 7 x64 saya, waktu kompilasi keseluruhan meningkat bukannya menurun. Kompilasi biasanya sangat cocok untuk pemrosesan paralel seperti di bagian tengah (post dependency mapping) Anda cukup memanggil instance kompiler pada masing-masing file .c / .cpp / .cs / apa pun yang Anda buat untuk membuat objek parsial yang dapat diambil oleh linker. lebih. Jadi saya akan membayangkan bahwa kompilasi sebenarnya akan berskala sangat baik dengan # core.

Tapi yang saya lihat adalah:

  • 8 core: 1,89 detik
  • 4 core: 1,33 detik
  • 2 core: 1,24 detik
  • 1 inti: 1,15 detik

Apakah ini hanya sebuah artefak desain karena implementasi hypervisor vendor tertentu (type2: virtualbox dalam kasus saya) atau sesuatu yang lebih meresap di lebih banyak VM untuk membuat implementasi hypervisor lebih sederhana? Dengan begitu banyak faktor, saya sepertinya bisa membuat argumen untuk dan menentang perilaku ini - jadi jika seseorang mengetahui lebih banyak tentang ini daripada saya, saya ingin tahu untuk membaca jawaban Anda.

Terima kasih Sid

[ edit: menangani komentar ]

@ MartinBeckett: Kompilasi dingin dibuang.

@MonsterTruck: Tidak dapat menemukan proyek opensource untuk dikompilasi secara langsung. Akan bagus tapi tidak bisa mengacaukan dev dev saya sekarang.

@Mr Lister, @philosodad: Memiliki 8 hw utas, menggunakan VirtualBox, jadi seharusnya pemetaan 1: 1 tanpa emulasi

@ Torbjorn: Saya memiliki 6.5GB untuk VM dan proyek VS2012 yang bertubuh kecil - sangat tidak mungkin saya menukar file halaman.

@All: Jika seseorang dapat menunjuk ke proyek VS2010 / VS2012 open source, itu mungkin referensi komunitas yang lebih baik daripada proyek VS2012 (milik) saya. Orchard dan DNN tampaknya membutuhkan penyesuaian lingkungan untuk dikompilasi dalam VS2012. Saya benar-benar ingin melihat apakah seseorang dengan VMWare Fusion juga melihat ini (untuk kompartementalisasi VMWare vs VirtualBox)

Detail tes:

  • Perangkat keras: Macbook Pro Retina
    • CPU: Core i7 @ 2.3Ghz (quad core, hyper threaded = 8 core di windows task manager)
    • Memori: 16 GB
    • Disk: SSD 256GB
  • Host OS: Mac OS X 10.8
  • Tipe VM: VirtualBox 4.1.18 (tipe 2 hypervisor)
  • OS Tamu: Windows 7 x64 SP1
  • Kompiler: VS2012 mengkompilasi solusi dengan 3 proyek Azure C #
    • Kompilasi pengukuran waktu dengan plugin VS2012 yang disebut 'VSCommands'
    • Semua tes berjalan 5 kali, 2 run pertama dibuang, 3 rata-rata terakhir

9
Mungkin file I / O melambatkannya dengan tugas berlipat ganda dan akses disk ke drive yang divirtualisasi
Martin Beckett

3
Saya ingin mereproduksi ini di komputer saya sendiri. Bisakah Anda mengunggah contoh proyek di suatu tempat? Saya menduga mesin virtual sedang bermain trik di sini. Coba boot ke Windows secara native (Bootcamp) dan lihat apakah Anda mengamati perilaku yang sama - Saya ragu Anda akan melakukannya.
Apoorv Khurasia

1
Apa yang kita kompilasi di sini? Banyak waktu overhead untuk memparalelkan tugas tidak membuahkan hasil sampai Anda mencapai skala tertentu. Lihat bagaimana kompilasi apache atau ravendb tidak.
Wyatt Barnett

2
Anda mungkin kehabisan memori di mesin virtual Anda sehingga mulai bertukar.

1
Hal yang sama terjadi pada saya sebelumnya dengan Java menggunakan Maven 3.x untuk mengkompilasi pada i3. Membiarkannya default ke utas "4" jauh lebih lambat, mendekati 50% lebih lambat, daripada mengatakannya secara eksplisit hanya menggunakan 2 core. Saya pikir itu ada hubungannya dengan konteks hyper-threading switching dan tumpang tindih I / O.

Jawaban:


12

Jawaban: Itu tidak melambat, itu naik dengan # core CPU. Proyek yang digunakan dalam pertanyaan awal adalah 'terlalu kecil' (sebenarnya satu ton pengembangan tetapi kecil / dioptimalkan untuk kompiler) untuk menuai manfaat dari beberapa core. Tampaknya alih-alih merencanakan bagaimana menyebarkan pekerjaan, menelurkan beberapa proses kompiler dll, pada skala kecil ini yang terbaik adalah memalu pada pekerjaan secara seri langsung dari kelelawar.

Ini didasarkan pada percobaan baru yang saya lakukan berdasarkan komentar pada pertanyaan (dan keingintahuan pribadi saya). Saya menggunakan proyek VS yang lebih besar - kode sumber Umbraco CMS karena itu besar, bersumber terbuka dan seseorang dapat langsung memuat file solusi dan membangun kembali (petunjuk: memuat umbraco_675b272bb0a3\src\umbraco.slndalam VS2010 / VS2012).

SEKARANG, apa yang saya lihat adalah apa yang saya harapkan, yaitu kompilasi ditingkatkan !! Nah, ke titik tertentu sejak saya menemukan:

Daftar hasil

Takeaways:

  • Inti VM baru menghasilkan OS X Thread baru dalam proses VirtualBox
  • Waktu kompilasi ditingkatkan seperti yang diharapkan (kompilasi cukup lama)
  • Pada 8 core VM, emulasi inti mungkin muncul di dalam VirtualBox karena hukumannya sangat besar (hit 50%)
  • Hal di atas kemungkinan karena OS X tidak dapat menghadirkan 4 core hyper-threaded (8 h / w thread) sebagai 8 core ke VirtualBox

Poin terakhir itu menyebabkan saya memantau sejarah CPU di semua inti melalui 'Activity Monitor' (sejarah CPU) dan apa yang saya temukan adalah

Grafik riwayat CPU OS X

Takeaways:

  • Pada satu inti VM, aktivitas tersebut tampaknya melompati 4 core HW. Masuk akal, untuk mendistribusikan panas secara merata di tingkat inti.

  • Bahkan pada 4 core Virtual (dan 27 thread VirtualBox OS X atau keseluruhan ~ 800 OS X thread), hanya bahkan thread HW (0,2,4,6) hampir jenuh sedangkan benang HW aneh (1,3,5,7) hampir 0%. Lebih mungkin scheduler berfungsi dalam hal core HW dan BUKAN HW threads jadi saya berspekulasi mungkin OSX 64bit kernel / scheduler tidak dioptimalkan untuk CPU hyper threaded? Atau melihat pengaturan inti 8VM, mungkin mulai menggunakannya pada utilisasi CPU% tinggi? Sesuatu yang lucu sedang terjadi ... well, itu pertanyaan terpisah untuk beberapa pengembang Darwin ...

[Sunting]: Saya ingin mencoba yang sama di VMWare Fusion. Kemungkinannya tidak akan seburuk ini. Saya ingin tahu apakah mereka memamerkan ini sebagai produk komersial ...

Footer:

Jika gambar pernah hilang, kompilasi tabel waktu adalah (teks, jelek!)

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%

Saya menduga penurunan antara 4 dan 8 adalah kombinasi dari VM yang tidak dioptimalkan untuk HT, dan HT tidak sama dengan dua kali lebih banyak inti ( paling baik peningkatan kinerja 30%, biasanya jauh lebih sedikit).
Daniel B

@DanielB: Pada 4 => 8 core, masalahnya bukan hanya peningkatan + 30% saja (vs + 100%) seperti yang Anda sarankan - tetapi kinerja sebenarnya -50%. Jika utas perangkat keras benar-benar 'mati / tidak berguna' dan pekerjaan dialihkan ke core lain, delta kinerja akan menjadi 0. Jadi karena itu saya akan lebih cenderung mengatakan itu adalah desain pada hypervisor tipe 2 VirtualBox. Saya ingin tahu bagaimana VMWare Fusion adalah ...
DeepSpace101

"Pada satu inti VM, aktivitas tersebut tampaknya melompati inti 4 HW. Masuk akal, untuk mendistribusikan panas secara merata pada tingkat inti" - belum tentu, biasanya lebih baik untuk menjadwalkan ulang pada inti yang sama (untuk cache dll) tetapi hypervisor hanya memetik satu di randon, atau inti yang paling sedikit digunakan karena dianggap sebagai pemrosesan tujuan umum di mana proses lain menggunakan inti tersebut. Dalam hal ini, pengoptimalan penjadwal berfungsi melawan Anda (tetapi dengan cara yang sangat kecil)
gbjbaanb

@Sid setuju, saya hanya menunjukkan bahwa dengan HT Anda akan mendapatkan (sangat) pengembalian yang jauh lebih cepat daripada yang Anda kira, jika Anda menganggap itu sebenarnya seperti peningkatan 100%. Dalam hal ini, bisa dengan mudah menjadi pertengkaran untuk HD Anda yang menyebabkan ini, maka saran saya sebelumnya untuk beberapa benchmark CPU buatan.
Daniel B

6

Hanya ada satu alasan yang memungkinkan terjadinya hal ini, yaitu overhead Anda melebihi keuntungan Anda.

Anda mungkin meniru beberapa core, daripada menugaskan core aktual atau bahkan proses atau bahkan utas dari mesin host. Itu tampaknya cukup bagi saya, dan jelas akan memberi Anda percepatan negatif.

Kemungkinan lain adalah bahwa proses itu sendiri tidak dapat diparalelkan dengan baik, dan bahkan mencoba untuk memparalelasinya akan lebih mahal dalam biaya komunikasi daripada yang Anda peroleh.


your overhead is exceeding your gains: Benar tapi itu cukup banyak mencakup semuanya tanpa mengetahui apa yang sebenarnya menyebabkannya :) ... Saya menggunakan VirtualBox dan memiliki inti fisik, jadi diasumsikan pemetaannya harus 1: 1 tanpa emulasi. Saya akan mencari sumber terbuka BESAR VS2012 sehingga orang lain dapat referensi juga ... brb
DeepSpace101

@Sid menurut jawaban ini superuser.com/a/297727 VM virtualbox harus menggunakan core host dengan tepat. Tetapi saya masih memeriksa apa yang terjadi pada tuan rumah, untuk memastikan bahwa perilaku yang diharapkan terjadi.
philosodad

0

Anda tidak sendiri ...

Hal yang sama terjadi pada saya sebelumnya dengan Java menggunakan Maven 3.x untuk mengkompilasi pada i3. Membiarkannya default ke utas "4" jauh lebih lambat, mendekati 50% lebih lambat, daripada mengatakannya secara eksplisit hanya menggunakan 2 core.

Saya pikir itu ada hubungannya dengan konteks hyper-threading switching dan tumpang tindih I / O.

Masuk akal ketika Anda mulai memikirkannya. Anda dapat membuktikan apa yang menyebabkan penurunan hasil dengan alat profil sistem luas yang baik.

Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.