Question

我目前正在使用pointclouds，我已经实现了一种分段算法，将具有特定最大距离的点聚类成段。

为了优化它，我给每个线段一个轴对齐的边界框，以检查给定的点是否可能是一个线段的匹配，然后再仔细观察并迭代点并计算距离（我实际使用这是一个八叉树，用于修剪掉大部分点。）

我通过gnuprof运行我的程序，这就是结果：

Each sample counts as 0.01 seconds.
  %   cumulative   self              self     total           
 time   seconds   seconds    calls   s/call   s/call  name    
 52.42      5.14     5.14 208995661     0.00     0.00  otree_node_out_of_bounds
 19.60      7.06     1.92 189594292     0.00     0.00  otree_has_point_in_range
 11.33      8.17     1.11   405834     0.00     0.00  otree_node_has_point_in_range
  9.29      9.08     0.91   352273     0.00     0.00  find_matching_segments
 [...]

如您所见，大部分计算时间都花在otree_node_out_of_bounds上，其实现如下：

int otree_node_out_of_bounds(struct otree_node *t, void *p)
{
    vec3 *_p = p;
    return (_p->x < t->_llf[0] - SEGMENTATION_DIST 
        || _p->x > t->_urb[0] + SEGMENTATION_DIST
        || _p->y < t->_llf[1] - SEGMENTATION_DIST 
        || _p->y > t->_urb[1] + SEGMENTATION_DIST
        || _p->z < t->_llf[2] - SEGMENTATION_DIST 
        || _p->z > t->_urb[2] + SEGMENTATION_DIST);
}

其中SEGMENTATION DIST是编译时常量，允许gcc进行一些常量折叠。 _llf和_urb的类型为float[3]，代表八叉树的边界框。

所以，我的问题基本上是，是否有可能对此函数进行一些偷偷摸摸的优化，或者更为一般的是，是否有更有效的方法来对AABB进行边界检查，或者甚至以不同的方式对其进行说明，我通过使用一些C / gcc魔法以某种方式加快比较？

如果您需要更多信息来回答这个问题，请告诉我们：）

谢谢，安迪。

Answer 1

这是一个很小的叶子函数，被称为很多次。分析结果总是过度代表这些功能的成本，因为测量呼叫的开销相对于功能本身的成本而言是很大的。通过正常优化，整个操作的成本（在最终调用此测试的外部循环级别）将占整个运行时的较低百分比。您可以通过使该函数与启用的分析内联（例如，使用__attribute__((__always_inline__))）来观察此情况。

你的功能看起来很好。我怀疑你可以比你更好地优化个人测试（或者如果可以的话，它不会是戏剧性的）。如果您想优化整个操作，则需要在更高级别执行：

你可以尝试另一种结构（例如kd-tree而不是octree）或一种利用数据中某种模式的全新算法。
您可以将循环从“对于每个点检查otrees”反转为“对于每个otree检查点”，这样可以反复使用边界数据。
您可以确保以最有效的方式访问数据（可能是点数）（即按顺序而不是随机跳转）。
使用重构的循环，您可以使用SSE在单个指令中执行多个边界测试（没有分支！）。

Answer 2

对我来说很好看。我能想到的唯一微优化是将* _p声明为静态

优化轴对齐边界框检查

2 个答案: