0

我有一长串方程，除了大约 113 t 之外，看起来像这样：

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

其中L's 是输入参数。

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

还有其他方法可以加快计算速度吗？谢谢。

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

4

4 回答 4

1

对于依赖于其他值的值，您将很难将工作分配给不同的线程。然后，您也可能会有一个线程在另一个线程上等待。并且启动新线程可能比仅计算 113 个值更昂贵。

您确定计算 t113 需要很长时间吗？还是其他需要很长时间的事情。

于 2013-05-02T18:24:20.543 回答
1

我假设这些任务是时间密集型的，甚至更多L2 + L3。如果不是，那么线程中的开销将大大超过线程的任何最小增益。

如果这是 Java，那么我会使用 aExecutors.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任务的输出在多个地方使用，这将不起作用。

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

于 2013-05-02T18:33:14.163 回答
0

如果所有的分配都像你展示的那样简单，一个合理的编译器会很好地减少它。对于你展示的部分，

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 个添加——如果它们是这样的话——而且现代计算机非常擅长添加，可能不会“更快”。

于 2013-05-02T18:29:30.687 回答
0

您的简单示例将使用 Excel 多线程计算自动多线程（并优化解决方案路径）。
但是您没有提供足够的细节来判断这对于您的实际应用程序是否是一种明智的方法。

于 2013-05-02T18:55:21.633 回答