我有一长串方程,看起来像这样,除了大约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个内核的方式编写代码。对于依赖于其他值的值,您将很难将工作分配给不同的线程。那么很可能会有一个线程在等待另一个线程。启动新线程可能比只计算113个值更昂贵。
你确定计算t113要花很长时间吗?或者是其他需要很长时间的事情
我假设这些任务是时间密集型的,而且不仅仅是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
任务的输出在多个地方使用,这将无法工作。
如果这是另一种语言,也许可以根据可用的线程库使用类似的模式。
如果所有赋值都像您展示的那样简单,那么合理的编译器将会很好地减少它。对于您所显示的部分,
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个加法——如果它们是这样的话——而现代计算机非常擅长加法,可能不会"更快"。
您的简单示例将使用Excel多线程计算自动多线程(并优化解决方案路径)。
但是您没有给出足够的细节来说明这对于您的实际应用程序是否是一种明智的方法。