|
|
1
2
我不太介意并行化,但我想指出,并行化膨胀/侵蚀并不是我在这里选择的第一选择。 通过膨胀/侵蚀,可以对像素周围的结构元素执行最大/最小操作。例如,如果您有一个5x5窗口,那么每个像素看25个像素,因此本质上每个像素看25次。因此,使用这种天真的方法,每个像素的计算复杂度与像素中结构元素的大小成正比。 使用更高效的形态学算子计算算法,您可以降低这种复杂性,甚至可以降低到恒定的复杂性(每像素),而不管结构元素的大小。关于这方面有很多文献,我最后包括了一些参考文献,他们也引用了其他论文并进行了比较。 我不知道你所处的环境,以及绩效的重要性。但并行化将是我正在做的最后一步。首先,无论性能如何,我都会让算法运行。一旦我对此感到满意(或者对运行时感到恼火,我愿意对此做些什么),我就会提高到一个更高效的解决者。如果最后,我仍然需要稍微推动运行时,我会并行化(或者考虑使用GPU是否有意义)。 如果现在进行并行化,可能会得到一些加速,但在提高性能的算法改进方面,您会有所损失。 现在,正如所承诺的,两篇关于高效形态滤波器的论文: Petr Dokládal, Eva Dokladalova. Computationally efficient, one-pass algorithm for morphological filters. Journal of Visual Communication and Image Representation, Elsevier, 2011 提出了一种基于结构元素的O(1)算法,并对经典的高效算法进行了比较/引用。 Joseph Gil, Ron Kimmel. Efficient Dilation, Erosion, Opening and Closing Algorithms 看起来也不错。我没有详细阅读,但我在我的研究领域认识罗恩·金梅尔,这可能是一本不错的书。 |
|
|
2
2
OpenMP是一种共享内存范例。如果可以保证所有不同的进程都将向相同的位置写入相同的值,那么让它们这样做就可以了。有比赛条件,但不会影响结果。 这为您提供了以下代码:
如果不能做出这样的保证,可以使用关键部分来限制写访问:
但是,如果你不能做出这样的保证,这是 令人不快的 并行性候选,因为每次运行代码时,不同的进程将在不同的时间到达位图的不同部分。也就是说,执行顺序是不确定的,因此您无法预测结果。假设只有一个正确的结果 必须 产生相同的输出。
同样,请确保您正在使用
另一种策略是收集所有需要修改的地方,然后在以后连续编写它们。如果你的支票很贵,但你的书写很便宜,这可能是有道理的;比方说,如果您使用正则表达式进行检查并写出零。
如果书写成本很高,您可以对
|
|
|
a a · 为什么在这个可重入锁示例中需要引用计数? 3 年前 |
|
|
Grant · goroutines有高空闲唤醒电话 3 年前 |
|
|
hoaz · 如何安全地清理并发映射 7 年前 |
|
|
Alanpatchi · int基元类型的volatile声明 7 年前 |