今天仔细测试了一下Windows线程同步，发现锁的效率真TMD低

wye11083

RT，今天写了个小内存池，但是让我头疼的是，无论如何优化，性能居然连new delete都比不过
换了N种写法，还是不成，最后怒了，去掉锁，速度一下子提升了20倍。曰，Windows的线程锁也太慢了吧。
没办法，只能修改算法了。新算法理论推导基本完成，就是用线程+队列+推送方式设计，推送队列尽可能的长，要不然唤醒推送线程又得花不少时间。这样子，取消了锁，估计性能会更上台阶吧。

dr2001

Win下可以用GetPerformanceCounter Log一下事件的绝对顺序，看看是哪里的问题。
如果非常频繁的获得锁，休眠一下任务的开销还是很大的。

wye11083

dr2001 发表于 2013-5-28 21:28
Win下可以用GetPerformanceCounter Log一下事件的绝对顺序，看看是哪里的问题。
如果非常频繁的获得锁，休 ...

呵呵，就一个线程，而数据结构设计需要频繁获取锁。所以下一步就改进设计理论基础，用队列和推送来实现高效率无锁结构。木办法，要么简单但慢，要么快但复杂。

titer1

dr2001 发表于 2013-5-28 21:28
Win下可以用GetPerformanceCounter Log一下事件的绝对顺序，看看是哪里的问题。
如果非常频繁的获得锁，休 ...

这个performenceCounter ，linux下有没有对应的替代啊？ 3ks

dr2001

titer1 发表于 2013-5-29 08:51
这个performenceCounter ，linux下有没有对应的替代啊？ 3ks

clock_gettime
具体用法Google就行了。

RDTSC用起来过于复杂，不建议使用。

redroof

dr2001 发表于 2013-5-29 08:53
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

redroof 发表于 2013-5-29 09:26
rdtsc最好用了。。。

//该函数可能要加上某些编译器指令来告诉编译器它“没有”返回值（实际rdtsc指令直 ...

1、RDTSC是每个核独立的计数器，只要线程没有始终绑定到唯一确定的核上，结果就肯定是错的，这时候计数都不一定单调增。
2、RDTSC的计数频率是可能变化也可能不变的，不同代的处理器完全不一样。只要Turbo Boost，自动降频等功能开启，RDTSC出来的结果的可信性就有相当的风险。

如果代码严格注意了以上的情况，并且首先在在特定的系统+硬件平台进行测试确认，RDTSC还是很准确的。不过这样的代码要是想通用，且能覆盖实际运行工况，一点戏没有。

现在搞精确一些的时间测量，用HPET，Performance Counter的多一些；一般来说粒度够用了。RDTSC只能在经过验证的受控环境下使用，拿来直接用的RDTSC，跟随机数没太多差异。

titer1

dr2001 发表于 2013-5-29 08:53
clock_gettime
具体用法Google就行了。

谢谢