-
Notifications
You must be signed in to change notification settings - Fork 131
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
关于性能分析的咨询 #2
Comments
已在文档说明 |
看来从理论和实际上,都能得出结论,这种 batch 替换的方式,比直接写入队列 然后去拿,效果好了不少。 我之前尝试过,依次写入队列,然后获取的时候,修改为 获取多个task 去执行的思路。 感谢您的回复,希望可以添加到你的个人微信,以便今后经常咨询和讨论。 |
具体还有很多影响因素,但目前我认为性能下降的原因最终还是归结到加剧了竞争或者是调用自旋锁时延长了锁的占用时间。只要不触犯这两条,基本上问题就不大。感谢您的认可,向您学习。 |
无锁 性能会比 自旋锁 性能高吗 |
哦,是我理解错了。 如果测试程序锁竞争导致的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 从写入队列,转移到执行队列中,
比直接写入一个线程安全的队列,然后消费的效果会好。
如果好的话,会好多少?
The text was updated successfully, but these errors were encountered: