Чому більше ядер процесора на віртуальній машині повільно збирає час?

[редагувати №2] Якщо хтось із VMWare може змусити мене скопіювати копію VMWare Fusion, я був би більш ніж радий зробити те саме, що і порівняння VirtualBox з VMWare. Я якось підозрюю, що гіпервізор VMWare буде краще налаштований на гіпертокування (див. Мою відповідь також)

Я бачу щось цікаве. Коли я збільшую кількість ядер на моїй віртуальній машині Windows 7 x64, загальний час компіляції збільшується, а не зменшується. Компіляція, як правило, дуже добре підходить для паралельної обробки, оскільки в середній частині (розміщення відображення залежностей) ви можете просто викликати екземпляр компілятора на кожному вашому .c / .cpp / .cs / будь-якому файлі, щоб створити часткові об'єкти для того, щоб лінкер взяв над. Тож я б міг уявити, що компіляція насправді дуже добре поєднується з # ядрами.

Але я бачу:

• 8 ядер: 1,89 сек
• 4 ядра: 1,33 сек
• 2 ядра: 1,24 сек
• 1 ядро: 1,15 сек

Це просто артефакт дизайну через реалізацію гіпервізора конкретного постачальника (тип 2: у моєму випадку віртуальна скринька) чи щось більш розповсюджене для більшої кількості віртуальних машин, щоб спростити реалізацію гіпервізора? Маючи так багато факторів, я, здається, зможу навести аргументи і за, і проти такої поведінки - тому, якщо хтось знає про це більше, ніж я, мені буде цікаво прочитати вашу відповідь.

Спасибі Сиде

[ редагувати: звернення до коментарів ]

@MartinBeckett: Холодні компіляції були відкинуті.

@MonsterTruck: Не вдалося знайти проект з відкритим джерелом для компіляції безпосередньо. Було б чудово, але зараз не можу накрутити мою розвідку.

@Mr Lister, @philosodad: Майте 8 hw-потоків, використовуючи VirtualBox, тому має бути відображення 1: 1 без емуляції

@Thorbjorn: У мене є 6,5 ГБ для VM та невеликого проекту VS2012 - навряд чи я замінюю / вимикаю файл сторінки.

@All: Якщо хтось може вказати на проект VS2010 / VS2012 з відкритим кодом, це може бути кращою орієнтацією для спільноти, ніж мій (власний) проект VS2012. Orchard та DNN, здається, потребують налаштування середовища, щоб скласти у VS2012. Я дуже хотів би побачити, чи хтось із VMWare Fusion також бачить це (для VMWare vs VirtualBox)

Деталі тесту:

• Обладнання: Macbook Pro Retina
  • ЦП: Core i7 @ 2.3Ghz (чотирьохядерний, гіперпотокова = 8 ядер у менеджері завдань Windows)
  • Пам'ять: 16 ГБ
  • Диск: 256 Гб SSD
• Хост ОС: Mac OS X 10.8
• Тип VM: VirtualBox 4.1.18 (гіпервізор типу 2)
• Гостьова ОС: Windows 7 x64 SP1
• Компілятор: VS2012 збирає рішення з проектами 3 C # Azure
  • Перемірка часу компіляції плагіном VS2012 під назвою "VSCommands"
  • Усі тести виконуються 5 разів, перші 2 викинуті, останні 3 - усереднені

Відповідь: Це не сповільнюється, але збільшується з кількістю ядер CPU. Проект, використаний в оригінальному запитанні, був "занадто малим" (це фактично тонни розробок, але малий / оптимізований для компілятора), щоб отримати користь від декількох ядер. Здається, замість того, щоб планувати, як розповсюдити роботу, нерестуючи кілька процесів компілятора тощо, у цьому невеликому масштабі найкраще забивати роботу серійно прямо з місця.

Це ґрунтується на новому експерименті, який я зробив на основі коментарів до питання (і моєї особистої цікавості). Я використав більш великий проект VS - вихідний код Umbraco CMS, оскільки він великий, відкритий, і можна безпосередньо завантажити файл рішення та відновити (підказка: завантажуйте umbraco_675b272bb0a3\src\umbraco.slnу VS2010 / VS2012).

ЗАРАЗ, те, що я бачу, - це те, чого я очікую, тобто компілює масштаб !! Ну, до певного моменту, оскільки я знаходжу:

Винос:

• Нове ядро ​​VM призводить до появи нової теми OS X в процесі VirtualBox
• Збільшити масштаб часу, як очікувалося (компіляції досить довгі)
• При ядрах 8 ВМ ядра емуляції можуть запускатись у VirtualBox, оскільки штраф є масовим (50% потрапляння)
• Сказане вище, ймовірно, тому що OS X не в змозі представити VirtualBox 4 ядра з гіперпотоком (8 г / ш потоку) як 8 ядер.

Цей останній момент змусив мене стежити за історією процесора у всіх ядрах через "Монітор активності" (історія процесора), і те, що я знайшов, було

Винос:

• На одному ядрі ВМ активність, схоже, перескакує через 4 ядра HW. Має сенс рівномірно розподіляти тепло на основних рівнях.

• Навіть у 4 віртуальних ядрах (і 27 потоках VirtualBox OS X або в загальній кількості ~ 800 потоків OS X), тільки навіть нитки HW (0,2,4,6) майже насичені, а непарні потоки HW (1,3,5,7) майже на 0%. Більш ймовірно, що планувальник працює в плані ядер HW, а не в потоках HW, тому я гадаю, що, можливо, ядро ​​/ планувальник OSX 64bit не оптимізовано для гіперпотокового процесора? Або дивлячись на налаштування 8ВМ ядра, можливо, він починає використовувати їх при високому відсотку використання процесора? Щось смішне виходить одне ... ну, це окреме питання для деяких розробників Дарвіна ...

[ред.]: Я хотів би спробувати те саме в VMWare Fusion. Швидше за все, це буде не так вже й погано. Цікаво, чи вони демонструють це як комерційний продукт ...

Нижній колонтитул:

Якщо зображення коли-небудь зникають, таблиця часу компіляції є (текст, некрасиво!)

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" потоків було набагато повільніше, майже на 50% повільніше, ніж явно казати йому використовувати лише 2 ядра.

Я думаю, що це має щось спільне з переключенням контексту гіпер-ниток та перекриттям вводу-виводу.

Це має сенс, коли ти починаєш думати про це. Ви можете довести, що спричиняє дегенерацію результатів, за допомогою хорошого інструменту для широкого системного профілювання.