每个人都知道bubblesort是O(n^2)，但这是基于对此进行排序所需的比较次数。我有一个问题，如果我不关心比较次数，但是输出时间，那么你如何分析这个呢？有没有办法分析输出时间而不是比较？
例如，如果您可以对所有对进行冒泡排序并进行并行比较（即使是奇数比较），那么吞吐量时间将类似于2n-1吞吐量时间。比较的数量会很高，但我不在乎最终的吞吐时间很快。
所以从本质上讲，是否对整体并行性能时间有一个共同的分析？如果是这样，请给我一些关键术语，我将从谷歌学习其余部分。
答案 0 :(得分：2)
并行编程在这里有点红鲱鱼。 仅对大O符号做出关于运行时间的假设可能会产生误导。要比较算法的运行时间，您需要完整的等式而不仅仅是大O符号。
问题是大O符号告诉你主导术语n进入无穷大。但运行时间在n的有限范围内。这从连续数学（我的背景）很容易理解。
考虑y=Ax和y=Bx^2 Big O符号会告诉您y=Bx^2速度较慢。但是，在（0，A / B）之间，它小于y=Ax。在这种情况下，使用O（x ^ 2）算法比x<A/B的O（x）算法更快。
事实上，我听说过排序算法，它以O（nlogn）算法开始，然后当n足够小时切换到O（n ^ 2）对数。
最好的例子是矩阵乘法。天真的算法是O（n ^ 3），但有一些算法可以达到O（n ^ 2.3727）。然而，我所看到的每个算法都有如此大的常数，以至于天真的O（n ^ 3）仍然是n的所有粒子值的最快算法，并且看起来不太可能很快改变。
所以你需要的是完整的比较方程式。像An^3（让我们忽略低阶词）和Bn^2.3727之类的东西。在这种情况下，B非常大，以至于O（n ^ 3）方法总能获胜。
并行编程通常只会降低常量。例如，当我使用四个核进行矩阵乘法时，我的时间从An^3变为A/4 n^3。您的并行冒泡排序也会发生同样的事情。你会减少常数。因此，对于n的某些值范围，您的并行冒泡排序可能会超过非并行（或可能甚至是并行）合并排序。虽然，与矩阵乘法不同，我认为范围非常小。
答案 1 :(得分：0)
算法分析并不意味着给出实际的运行时间。这就是基准。分析告诉您程序中相对复杂程度有多大，但该程序的实际运行时间取决于严格分析无法保证实际时间的许多其他因素。例如，如果您的操作系统决定暂停程序以安装更新，会发生什么？你的跑步时间会被拍摄。由于计算机系统的复杂性（内存页面错误，虚拟机垃圾收集，IO中断等），即使反复运行相同的程序也会产生不同的结果。分析不能将这些考虑在内。
这就是为什么在分析过程中通常不会考虑并行处理的原因。 “并行化”程序组件的机制通常在代码外部，通常基于概率算法进行调度。我不知道对此进行静态分析的好方法。再一次，您可以运行一系列基准测试，这将为您提供平均运行时间。
答案 2 :(得分：0)
我们通过并行步骤获得的时间效率可以通过round complexity来衡量。每轮由同时发生的平行步骤组成。通过这样做，我们可以看到吞吐时间的有效性，在我们习惯的类似分析中。