avatar-decorate
获赞
1107
粉丝
763
关注
1
看过 TA
1.2W
上海交通大学
2023
搜索算法
IP属地:北京
前Shopee逐风计划信息检索算法工程师实习生
私信
关注
只是把图1的328行的两数比较[取需要处理的桶的个数较少的一端]​改成了图2的1140行的两数比较[取需要处理的桶里的元素个数的和较少的一端]​其他没变,时间却慢了许多,如图3,5.69ms变成了6.28ms,3.75ms变成了3.82ms,7.03ms变成了6.87ms,6.26ms变成了6.57ms。​​取数组上的两个数来比较,这个开销应该很小,难道不应该以桶大小和作为负载评估量?以桶个数作为负载大小更科学?导致对两端的选择不准确?​找到了一种低维下比HEM更快的算法,匹配概率很小,只有不到10个匹配订阅,图4,C-BOMP优化后的fRein 0.57ms,比HEM 1.01ms快不少(不过可能是因为在debug模式下HEM测了每种任务的时间多了很多开销,去掉后还是HEM快,而REIN不怎么受这个计算开销的影响)。可惜的是这个桶大小和负载选择优化[谓词粒度负载优化PGWO]和hRein都没什么用。这是低维下的真实事件实验,如果是随机生成的事件,效果还会差不少,可见与值有关,以前做的值倾斜分布生成得不好,以后做值分布实验应该直接测只落入每段区间内的匹配时间!​​9次实验,谓词宽度从0.1到0.9,到0.7时fRein-cbomp报段错误了,到0.3时hRein-cbomp报段错误了。​不知什么原因,比较少见的随机错误。跑完后再单独运行了0.7和0.3的情况,没错了。​BG-Tree上也有类似情况,好像也是C-BOMP优化的锅。非DEBUG模式(debug下某些算法会测量各种细分操作上的时间)下重新跑了遍,fRein cbomp在w0.2,0.4,0.5下都报了段错误,导致最后许多算法只跑了6次实验,图5。​​ #C++# #研究生日常[话题]# #硕士# #奇怪# #灵异# #程序员的一天#
0 点赞 评论 收藏
转发
牛客网
牛客企业服务