0

我在一个并行包上进行了一组实验，比如说superlu-dist，使用不同的处理器编号，例如：4, 16, 32, 64

我得到了每个实验的挂钟时间，比如：53.17s, 32.65s, 24.30s, 16.03s

加速公式为：

                  serial time
  Speedup = ----------------------
                parallel time

但是没有关于序列分数的信息。

我可以简单地取挂钟时间的倒数吗？

4

2 回答 2

1

我可以简单地取挂钟时间的倒数吗？

不，
真正的 Speedup 数据需要将 Apples 与 Apples 进行比较：

这意味着，应该将原始的纯[SERIAL]进程调度与任何其他场景进行比较，其中部分可能会被修改，以便使用某种并行性（并行部分可能会重新组织，以便在NCPU上运行/ 计算资源，而序列部分保持原样）。

这显然意味着，原始[SERIAL]代码被扩展（在代码中（#pragma-decorators，OpenCL-modifications，CUDA -tooling 等），并且及时（以执行原始代码-{ host_to_dev | dev_to_host }中不存在的这些附加功能，[SERIAL]进行基准测试），以便添加一些新的部分，其中（可能的[PARALLEL]）处理的其他部分将发生。

这是有代价的——附加开销成本（设置和终止以及从[SERIAL]-part 到[PARALLEL]-part 和返回的数据通信） - 所有这些都增加了额外[SERIAL]的 -part 工作负载（和执行时间 + 延迟）。

有关更多详细信息，请随时阅读关于重新制定的阿姆达尔定律的文章中的批评部分。

在此处输入图像描述

-portion[PARALLEL]看起来很有趣，但 Speedup 主要上限在原始的[SERIAL]-portion 持续时间( s = 1 - p )中，

在此处输入图像描述

但是，如果要进行实际评估，则需要将附加持续时间和增加的延迟成本与工作“组织”一起累积，从原始的纯代码执行过程调度[SERIAL]到希望拥有的[PARALLEL]代码执行过程调度达到

在单个处理器上运行测试并将其设置为串行时间，...，

正如@VictorSong 提出的那样，听起来很简单，但是对一个不连贯的系统（不是纯粹的[SERIAL]原始系统）进行了基准测试，并记录了一个倾斜的标准来进行比较。

这就是为什么应该设计公平方法的原因。纯[SERIAL]原始代码执行可以加时间戳，以显示未更改部分的实际持续时间，但附加开销时间必须合并到现在并行化的串行部分的附加扩展中测试。

重新阐述的阿姆达尔收益递减定律解释了这一点，连同附加开销和处理原子性的影响，这将不允许进一步虚构加速增长，因为添加了更多的计算资源，但是并行 -由于某种形式的内部处理原子性，处理的一部分不允许进一步分割任务工作负载，尽管有可用的空闲处理器，但无法进一步分割。

这两个重新制定的表达式的简化如下所示：

               1
S =  __________________________; where s, ( 1 - s ), N were defined above
                ( 1 - s )            pSO:= [PAR]-Setup-Overhead     add-on
     s  + pSO + _________ + pTO      pTO:= [PAR]-Terminate-Overhead add-on
                    N

一些用于进一步可视化附加开销成本的交互式 GUI 工具可用于此处的交互式参数模拟- 只需将-sliderp移向 ~ 的实际值，即原始( 1 - s )部分的非零部分[SERIAL]代码：

用于交互式模拟的实时 GUI

于 2018-05-20T19:43:38.217 回答
0

当您说“连续分数”时，您是什么意思？根据谷歌搜索显然 superlu-dist 是 C，所以我想你可以使用 ctime 或 chrono 并以通常的方式花时间，它适用于我手动 std::threads 和 omp。

我只是在单个处理器上运行测试并将其设置为串行时间，然后使用更多处理器再次进行测试（就像你说的那样）。

于 2018-05-20T13:23:03.027 回答