Увидим ли мы ожидаемое ускорение в часовне, если будут работать "внутри" виртуальных машин?

В следующем семестре я преподаю в Chapel, и мы рассматриваем возможность использования виртуальной машины для студентов вместо физической машины. Как часть класса, я хочу, чтобы студенты могли видеть ускорение при использовании нескольких потоков. Я боюсь, что они не смогут увидеть это, поскольку виртуальная машина будет действовать с неявной гиперпоточностью; один поток будет работать так же быстро, как и многие потоки.

У кого-нибудь есть опыт с этим? Есть ли шанс, что я смогу использовать виртуальную машину вместо физического устройства?

Источник

1 ответ

У нас был успех с виртуальной машиной! ВМ, которую мы использовали для всего класса, имеет:

  • 16 процессоров
  • жесткий диск 60 ГБ
  • 4 ГБ ОЗУ
  • 3 хоста ESXI

Система также имеет неограниченное количество IOP. (Вход / выход в секунду.)

Я рекомендую это решение другим учителям.

Источник

Да, но любое ускорение - это вопрос не просто синтаксического конструктора, а достижимой проблемы. ( [SEQ], [PAR] ) повторное рецептуре:

При всем уважении, профессор, Закон Амдала идет вразрез с большинством наивных, просто украшенных синтаксисом усилий.

Современная критика и переформулировка оригинального аргумента д-ра Джина AMDAHL учли два основных расширения:

  • строгая формулировка (не забывать, что происходит от [SEQ] в [PAR] Выполнение кода происходит за счет затрат, всегда дополнительных расходов, которые в значительной степени идут вразрез с любым ожидаемым (фактическое увеличение расходов на дополнительные расходы).

  • основной предел любого [PAR] - гранулярность выполнения на конечном уровне атомарных транзакций, когда любой доступный ресурс, даже в бесконечной емкости, не приведет к дальнейшему улучшению общего права на скорость из-за дальнейшего неделимого планирования "атомарности"

Обе эти проблемы будут доминировать в ваших образовательных усилиях в большей степени, чем ваши фактические абстракции ВМ, и было бы действительно здорово обсудить более подробно все эти воздействия, связанные с планированием "блокирующих" ресурсов, а не только с ядром (ями) процессора и аппаратными средствами. потоки (на которые расписано O/S), будь то физические или абстрагированные VM-гипервизором.

Как уже много раз отмечали отличные члены команды CRAY Chapel, проблемы с NUMA на реальном оборудовании оказывают большое влияние на конечные издержки надстроек, а сформулированный синтаксис высокого уровня фактически внедрит их в обработку реальных платформ, поэтому еще более дикий

Виртуальные машины:

Лучше проверить созданную VM-гипервизором топологию VM-NUMA (hwloc / lstopo), чтобы лучше декодировать архитектуру VM-CPU-Cache, ваши песочницы VM будут наслаждаться любым аппаратно-ориентированным низким уровнем { C | сборка}-кода, и можно представить себе множество "дурацких" эффектов, если виртуальная машина утверждает, что у vCPU есть 8 независимых vCPU-сокетов, каждое из которых имеет 4 независимых ядра vCPU, каждое из которых имеет полностью отдельную и автономную иерархию неразделенного vCPU-CACHE(s), ни один уровень которых не является общим (несмотря на факты, что физические процессоры (ы) хоста (ов) в основном совместно используют L3_CACHE(s)).

Все это неправильно направляет любые решения, ориентированные на аппаратные ресурсы и оптимизатора (и производительность никогда не повышается, если виртуализация не соответствует физическим свойствам хоста).

(Можно также использовать платформу Live chapel https://tio.run/ создания прототипов)

Источник
Другие вопросы по тегам