我有一长串方程式,看起来像这样,除了大约有113个t:
t1 = L1;
t2 = L2 + 5;
t3 = t2 + t1;
t4 = L3
...
t113 = t3 + t4
return t113;其中L是输入参数。
计算t113需要很长的时间。所以我试着把它分成几个不同的线程,试图让它变得更快。问题是我不知道该怎么做。我试着用手在纸上画出树的形式的t,这样我就可以更好地分析它,但它在中途变得太大和笨拙。
有没有其他方法可以让计算速度更快?谢谢。
编辑:我使用的是带有SYS/BIOS的8核DSP。根据我的前任,这些反向和正向运动学方程将花费最多的时间来处理。我的前辈也有意选择了这款8核DSP作为硬件实现。因此,我假设我应该以一种利用所有8个内核的方式来编写代码。
发布于 2013-05-03 02:24:21
对于依赖于其他值的值,您将很难将工作分配给不同的线程。那么你也有可能让一个线程在另一个线程上等待。而且,启动新的线程可能比只计算113个值更昂贵。
您确定计算t113需要很长时间吗?或者是其他需要很长时间的事情。
发布于 2013-05-03 02:33:14
我假设这些任务是时间密集型的,而不仅仅是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任务的输出,这将不起作用。
如果这是另一种语言,根据可用的线程库,也许可以使用类似的模式。
发布于 2013-05-03 02:29:31
如果所有的赋值都像你展示的一样简单,一个合理的编译器将会很好地减少它。对于你展示的部分,
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个加法器--如果是这样的话--而且现代计算机非常擅长加法,可能不会“更快”。
https://stackoverflow.com/questions/16345049
复制相似问题