Closed ChunelFeng closed 1 year ago
已在文档说明
看来从理论和实际上,都能得出结论,这种 batch 替换的方式,比直接写入队列 然后去拿,效果好了不少。
我之前尝试过,依次写入队列,然后获取的时候,修改为 获取多个task 去执行的思路。 尝试下来,在空跑的测试环境中,性能是下降的。 预计是在任务有random耗时的情况下, 性能会略有提升。 但是由于纯调度的性能diff,本来就非常小,在有耗时的task的情况下,会被稀释的很厉害。 测试结果就不是那么准确了。
感谢您的回复,希望可以添加到你的个人微信,以便今后经常咨询和讨论。 我的微信是 ChunelFeng
具体还有很多影响因素,但目前我认为性能下降的原因最终还是归结到加剧了竞争或者是调用自旋锁时延长了锁的占用时间。只要不触犯这两条,基本上问题就不大。感谢您的认可,向您学习。
无锁 性能会比 自旋锁 性能高吗
哦,是我理解错了。 如果测试程序锁竞争导致的cache coherency traffic中比较大,可以试试ttas锁。https://rigtorp.se/spinlock/。 不知道性能提升怎么样了。
我可以试着提个Pr
我试了下 https://probablydance.com/2019/12/30/measuring-mutexes-spinlocks-and-how-bad-the-linux-scheduler-really-is/ 这篇文章提到的改进,没什么效果。
struct spinlock {
void lock() {
for (int spin_count = 0; !try_lock(); ++spin_count) {
if (spin_count < 16)
_mm_pause();
else {
std::this_thread::yield();
spin_count = 0;
}
}
}
bool try_lock() {
return !locked.load(std::memory_order_relaxed) &&
!locked.exchange(true, std::memory_order_acquire);
}
void unlock() { locked.store(false, std::memory_order_release); }
private:
std::atomic_bool locked{false};
};
如果用极少的异步线程,且每次推任务时采用批量提交大量的任务(延长锁的占用时间),那么采用这种自旋锁才有可能能提高整体性能,否则可能会因为多做一些无用的yeild导致线程切换从而降低整体性能。
您好,追随您在b站的视频找到这里。
想咨询一下,是否有测试结果,来对比使用 a batch of 的方式,将 task 从写入队列,转移到执行队列中, 比直接写入一个线程安全的队列,然后消费的效果会好。
如果好的话,会好多少?