标准里唯一规定确定是无锁的是atomic_flag，其他都是impl dependent，具体是不是有锁，要用is_lock_free() 来看

【 在 libgcc 的大作中提到: 】
: 大部分atomic是有锁的？
--
FROM 122.234.63.*

测试程序本身问题更多

1. 线程没绑核独占，线程数超过核数
2. 10线程太多，瓶颈肯定在FSB带宽上
3. global variable，肯定是在L3了，各个线程又都是读+写，cache line很费，cpu内部带宽多半也有问题，baidu cache MESI protocol
4. 加锁以后编译器知道循环独占，做了cache优化，降低了撞锁，增加了cache利用


【 在 confinement 的大作中提到: 】
: 测试程序非常简单，每次就是主程序里push_back十个线程，线程执行的函数就是上面的累加函数。我测试过 -O3 编译，单纯从执行时间看，跟不带O编译看不出什么区别
: 无锁的普通 long long 类型为什么也慢。。
:
--
FROM 122.234.63.*

我的理解是：

如果不是性能敏感部分，用哪个都无所谓

性能敏感部分

容易撞锁，就用atomic，因为内部是类似spin lock，不造成context switch，但是对cache不友好，代码出现优化边界，优化效率下降。

不容易撞锁，考虑换设计吧，能单线程就尽量单线程，能共享只读就不要共享写，现在的prefetch实在太强大了。




【 在 confinement 的大作中提到: 】
另外问一下，原子变量可以以任何类型作为模板参数，那在自定义类型情形下，这东西到底有什么作用，怎么个用法？不太理解
--
FROM 122.234.63.*

hyper-thread并不能和独立的核相提并论。

hyper-thread只指如果两个指令不冲突，一个核可以同时执行这两个指令，其他所有的东西，寄存器，cache这些都是共享的。

所以你如果运行的两个指令不能同时执行，反而会造成更大的问题。

一般来说，hyper-thread会用来做一个显式的软预读，提高cache hit rate，其他并没有什么太大用处

【 在 confinement 的大作中提到: 】
: 是测试有点问题，误导了，主贴已经修改。 测试机器是8核16线程，这种，理论上是能够16线程并行运算的吧，一核2线程这种东西，对于我这样不是很懂cpu底层的，始终不是很清楚
:
--
FROM 115.193.179.*

实测没啥用，性能按核计算即可
【 在 ziqin 的大作中提到: 】
: hyper-thread并不能和独立的核相提并论。
: hyper-thread只指如果两个指令不冲突，一个核可以同时执行这两个指令，其他所有的东西，寄存器，cache这些都是共享的。
: 所以你如果运行的两个指令不能同时执行，反而会造成更大的问题。
: ...................
--
FROM 221.221.49.*