测量相互依赖的线程的并行计算时间

时间:2012-04-20 08:27:03

标签: c++ pthreads runtime parallel-processing time-measurement

我有一个关于并行程序中运行时测量的问题(我使用的是C ++,但我认为这个问题更为通用)。

一些简短的解释:3个线程并行运行(pthread),以不同的方式解决同样的问题。每个线程可以将信息传递给另一个线程(例如,由一个线程而不是另一个线程获得的部分解决方案),以便根据他自己的计算中的他自己的状态/可用信息来加速其他线程。第一个线程准备就绪后,整个过程就会停止。 现在,我希望有一个独特的时间测量,用于从开始到问题解决时评估运行时。 (最后,我想确定通过并行计算使用协同效应是否比在单个线程上计算更快。)

在我看来,问题在于(由于操作系统暂停/取消暂停单个线程),在进程中传递信息的点在每个进程的状态中都不是确定的。这意味着,在线程1上的xxx单位的cpu时间之后获取某个信息,但是它无法被控制,线程2是否在yyy之后接收该信息或者在其计算中花费的cpu时间的zzz单位。假设此信息在任何情况下都已完成线程2的计算,则线程2的运行时间为yyy或zzz,具体取决于操作系统的操作。

如何获得运行时比较的确定性行为?我可以命令操作系统运行每个线程“不受干扰”(在多核机器上)吗?有什么我可以做的实现(c ++) - 基础?

还有其他概念来评估此类实现的运行时间(时间增益)吗?

祝你好运 马丁

2 个答案:

答案 0 :(得分:1)

任何时候有人在同一句话中使用“确定性”和“多核”这两个术语,它就会响起警钟: - )

您的程序中有两个非确定性的主要来源:1)操作系统,它通过操作系统抖动和调度决策为线程时序增加噪声; 2)算法,因为程序遵循不同的路径,取决于(部分解决方案)通信的顺序。

作为一名程序员,你无法对操作系统噪音做些什么。即使对于在专用(静止)节点上运行的程序,标准OS也会增加很多噪声。用于计算节点的专用操作系统可以在某种程度上降低噪声,例如Blue Gene systems exhibit significantly less OS noise and therefore less variation in timings

关于算法,您可以通过添加同步来为程序引入确定性。如果两个线程同步,例如交换部分解,则同步之前和之后的计算顺序是确定性的。您当前的代码是异步的,因为一个线程“发送”部分解决方案,但不等待它“收到”。您可以通过将计算分为步骤并在每个步骤之后在线程之间进行同步,将其转换为确定性代码。例如,对于每个线程:

  1. 计算一步
  2. 记录部分解决方案(如果有)
  3. 屏障 - 等待所有其他线程
  4. 从其他线程中读取部分解决方案
  5. 重复1-4
  6. 当然,我们不希望这个代码也能执行,因为现在每个线程都必须等待所有其他线程完成计算才能继续下一步。

    最好的方法可能就是接受非决定论,并使用统计方法来比较你的时间。对于给定数量的线程运行程序多次,并记录时间的范围,平均值和标准偏差。您可能已经足够了解例如对于给定数量的线程,所有运行的最大计算时间,或者您可能需要统计测试(例如Student's t-test)来回答更复杂的问题,例如“从4个线程增加到8个线程会减少运行时间有多确定? ”。正如DanielKO所说,时间的波动是用户实际会经历的,所以测量这些并在统计上量化它们是有意义的,而不是旨在完全消除它们。

答案 1 :(得分:0)

这种测量的用途是什么?

假设您可以通过一些人为的方法,以线程运行不受干扰的方式设置OS调度程序(即使通过间接事件,如使用缓存,MMU等的其他进程),这对于实际使用是否切合实际并行程序?

现代操作系统很少让应用程序控制一般中断处理,内存管理,线程调度等。除非您直接与金属交谈,否则您的确定性测量不仅不切实际,而且用户您的程序永远不会遇到它们(除非它们与您进行测量时的金属接近。)

所以我的问题是,为什么你需要这么严格的条件来测量你的程序?在一般情况下,只接受波动,因为这是用户最有可能看到的。如果某个算法/实现的加速是如此微不足道以至于无法与背景噪声区分开来,那对我来说比知道实际的加速分数更有用。