Question

我有一系列的方程看起来像这样，除了大约113 t：

t1 = L1;
t2 = L2 + 5;
t3 = t2 + t1;
t4 = L3
...
t113 = t3 + t4
return t113;

L是输入参数。

计算t113需要很长时间。所以我试图把它分成几个不同的线程，试图让这个更快。问题是我不知道该怎么做。我尝试用手在纸上画出树的形状，这样我就可以更好地分析它，但它在中途变得太大而且笨重。

还有其他方法可以让计算更快吗？感谢。

编辑：我正在使用带有SYS / BIOS的8核DSP。根据我的前任，这些反向和正向运动方程将花费最多的时间来处理。我的前任也故意选择这款8核DSP作为实现硬件。所以我假设我应该以一种利用所有8个内核的方式编写代码。

Answer 1

使用依赖于其他值的值，您将很难将工作分配给不同的线程。那么你也可能有一个线程在另一个线程上等待。启动新线程可能比仅计算113个值更加昂贵。

你确定要花很长时间来计算t113吗？或者是其他需要很长时间的事情。

Answer 2

我假设这些任务是时间密集的，而且只是L2 + L3或更多。如果没有，则线程中的开销将大大超过线程的任何最小增益。

如果这是Java，那么我将使用Executors.newCachedThreadPool();在需要时启动新线程，然后允许作业本身将作业提交到线程池并等待响应。这有点奇怪，但它会起作用。

例如：

private final ExecutorService threadPool = Executors.newCachedThreadPool();
...
public class T3 implements Callable<Double> {
    public Double call() throws Exception {
        Future<Double> t2 = threadPool.submit(new T2());
        Future<Double> t1 = threadPool.submit(new T1());
        return t2.get() + t1.get();
    }
}

然后最后的任务是：

Future<Double> t3 = threadPool.submit(new T3());
// this throws some exceptions that need to be caught
double result = t3.get();
threadPool.shutdown();

然后线程池只会处理结果。它会做尽可能多的并行化。现在，如果T1任务的输出在多个地方使用，则无效。

如果这是另一种语言，可能会使用类似的模式，具体取决于可用的线程库。

Answer 3

如果所有分配都与您显示的分配一样简单，那么合理的编译器会将其减少。对于您显示的部分，

return L1 + L2 + L3 + 5, should be all the work it's doing.

也许这可以在两个线程（在两个CPU上）完成，如：

T1:  L1 + L2
T2:  L3 + 5
Parent thread: Add the two results.

但只增加了113个 - 如果它们就是这样 - 现代计算机非常擅长添加，可能不会“更快”。

Answer 4

您的简单示例将使用Excel多线程计算自动多线程（并优化解决方案路径）但是你没有给出足够的细节来判断这对你的真实应用是否是一种合理的方法。

多线程一系列方程

4 个答案: