今天仔细测试了一下Windows线程同步，发现锁的效率真TMD低
RT，今天写了个小内存池，但是让我头疼的是，无论如何优化，性能居然连new delete都比不过{:sweat:}换了N种写法，还是不成，最后怒了，去掉锁，速度一下子提升了20倍。曰，Windows的线程锁也太慢了吧。
没办法，只能修改算法了。新算法理论推导基本完成，就是用线程+队列+推送方式设计，推送队列尽可能的长，要不然唤醒推送线程又得花不少时间。这样子，取消了锁，估计性能会更上台阶吧。 Win下可以用GetPerformanceCounter Log一下事件的绝对顺序，看看是哪里的问题。
如果非常频繁的获得锁，休眠一下任务的开销还是很大的。 dr2001 发表于 2013-5-28 21:28 static/image/common/back.gif
Win下可以用GetPerformanceCounter Log一下事件的绝对顺序，看看是哪里的问题。
如果非常频繁的获得锁，休 ...
呵呵，就一个线程，而数据结构设计需要频繁获取锁。所以下一步就改进设计理论基础，用队列和推送来实现高效率无锁结构。木办法，要么简单但慢，要么快但复杂。 dr2001 发表于 2013-5-28 21:28 static/image/common/back.gif
Win下可以用GetPerformanceCounter Log一下事件的绝对顺序，看看是哪里的问题。
如果非常频繁的获得锁，休 ...
这个performenceCounter ，linux下有没有对应的替代啊？ 3ks
titer1 发表于 2013-5-29 08:51 static/image/common/back.gif
这个performenceCounter ，linux下有没有对应的替代啊？ 3ks
clock_gettime
具体用法Google就行了。
RDTSC用起来过于复杂，不建议使用。 本帖最后由 redroof 于 2013-5-29 09:29 编辑
dr2001 发表于 2013-5-29 08:53 static/image/common/back.gif
clock_gettime
具体用法Google就行了。
rdtsc最好用了。。。
//该函数可能要加上某些编译器指令来告诉编译器它“没有”返回值（实际rdtsc指令直接把返回值放到了64位返回寄存器（EDX:EAX）里面）
__int64 rdtsc()
{
__asm rdtsc;
}
class CpuTimer
{
public:
__int64 TimerData;
void Start()
{
TimerData = rdtsc();
}
void Stop()
{
TimerData = rdtsc() - TimerData;
//得到的TimerData是按CPU时钟数来计算的，对个人调试足够了（你当然知道你自己的CPU主频）
//如果要得到绝对时间，得按照CPU主频来换算，Windows可读注册表得到CPU主频，Linux好像可以从CPU信息中得到
}
}
本帖最后由 dr2001 于 2013-5-29 09:45 编辑
redroof 发表于 2013-5-29 09:26 static/image/common/back.gif
rdtsc最好用了。。。
//该函数可能要加上某些编译器指令来告诉编译器它“没有”返回值（实际rdtsc指令直 ...
1、RDTSC是每个核独立的计数器，只要线程没有始终绑定到唯一确定的核上，结果就肯定是错的，这时候计数都不一定单调增。
2、RDTSC的计数频率是可能变化也可能不变的，不同代的处理器完全不一样。只要Turbo Boost，自动降频等功能开启，RDTSC出来的结果的可信性就有相当的风险。
如果代码严格注意了以上的情况，并且首先在在特定的系统+硬件平台进行测试确认，RDTSC还是很准确的。不过这样的代码要是想通用，且能覆盖实际运行工况，一点戏没有。
现在搞精确一些的时间测量，用HPET，Performance Counter的多一些；一般来说粒度够用了。RDTSC只能在经过验证的受控环境下使用，拿来直接用的RDTSC，跟随机数没太多差异。 dr2001 发表于 2013-5-29 08:53 static/image/common/back.gif
clock_gettime
具体用法Google就行了。
{:smile:}
谢谢
页:
[1]