下学期我将在 Chapel 教书,我们正在考虑使用 VM 代替物理机器让学生进行编程。作为课堂的一部分,我希望学生能够在使用多个线程时看到加速。我担心他们将无法看到这一点,因为 VM 将使用隐式超线程进行操作;一个线程的运行速度与多个线程一样快。
有人对这个有经验么?我有机会使用虚拟机而不是物理设备吗?
下学期我将在 Chapel 教书,我们正在考虑使用 VM 代替物理机器让学生进行编程。作为课堂的一部分,我希望学生能够在使用多个线程时看到加速。我担心他们将无法看到这一点,因为 VM 将使用隐式超线程进行操作;一个线程的运行速度与多个线程一样快。
有人对这个有经验么?我有机会使用虚拟机而不是物理设备吗?
我们在虚拟机上取得了成功!我们全班使用的虚拟机有:
该系统还具有无限的 IOP。(每秒输入/输出。)
我向其他老师推荐这个解决方案。
是的,但是任何加速都不仅仅是语法构造函数的问题,而是问题的可实现的( [SEQ], [PAR] )
重新表述:
恕我直言,教授,阿姆达尔定律违背了大多数天真的、只是句法修饰的努力。
对原始 Gene AMDAHL 博士论点的当代批评和重新表述考虑了两个主要扩展:
开销严格的公式(不要忘记,从[SEQ]
代码[PAR]
执行开始是有代价的,总是附加成本,这与任何预期的(实际附加开销成本不可知)加速不符)
任何[PAR]
执行粒度的主要限制,在有限的原子事务级别,其中任何进一步的可用资源,即使在无限容量中,由于进一步不可分割的调度“原子性”,也不会进一步提高整体速度
这两个问题将比您实际的 VM 抽象更多地主导您的教育工作,并且确实非常适合更详细地讨论调度-“阻塞”-资源的所有这些影响,而不仅仅是 CPU 核心和硬件-线程(O/S 调度到的线程),无论是物理的还是由 VM 管理程序抽象的。
正如伟大的 CRAY Chapel 团队成员已经多次指出的那样,真实硬件 NUMA 问题对最终附加开销有很大影响,高级制定的语法实际上会注入到真实平台处理中,所以情况是甚至更狂野。
更好地检查 VM-hypervisor 生成的 VM-NUMA 拓扑 ( hwloc
/ lstopo
) 以更好地解码 VM-CPU-Cache 架构,您的 VM-sand-boxes 将享受任何硬件导向的低级 { C | 汇编}-code,并且可以想象许多“愚蠢”的效果,如果VM声称vCPU有8个独立的vCPU-socket,每个有4个独立的vCPU-core,每个都有一个完全独立的非共享vCPU的自治层次结构-CACHE(s),没有共享的级别(尽管事实上,主机的物理 CPU 操作主要共享 L3_CACHE(s))。
所有这些都误导了任何以硬件为中心的资源优化器的决策(如果虚拟化错过了主机的物理属性,性能永远不会上升)。
(也可以使用 https://tio.run 上的Live chapel 平台进行调整和原型设计)