为什么程序员需要关心Sequential Consistency而不是Cache Coherence？
Guancheng Chen
++或者Java进行多线程编程的程序员。
Sequential Consistency（下文简称SC）是Java内存模型和即将到来的C++0x内存模型的一个关键概念，它确保了你的多线程
程序在执行时的正确性。Cache Coherence（下文简称CC）是多核CPU在硬件中已经实现的一种机制，简单的说，它确保了对一个内存地址的
任何读操作一定会返回那个内存地址最新的（被写入）的值。
那么为什么程序员需要关心SC呢？因为现在的硬件和C++编译器都还未保证SC，也就是说你用C++编写的多线程程序可能会得到不正确的运行结果。
Java从JDK1.5开始加入SC支持，所以Java程序员在进行多线程编程时需要特别注意使用Java提供的相关机制来确保你程序的SC。程序员之
所以不需要关心CC是因为现在的它已经被硬件的实现给保证了。
因为这篇文章有很多表格，而且我不知道group能不能很好的支持它，所以为了保证格式的美观，阅读全文请点击链接：
小弟第一次写这么长的文章，请大家帮忙指正批评！谢谢！
jigsaw
oliver yang
> 我觉得程序员也需要关心cache coherence，因为cache coherence带来的false sharing效果对性能有可能造成成倍的影响。
False sharing本质上不是cache coherence带来的问题，而是cache的多路关联技术带来的问题。
Cache本来就小，内存中总会有不相干的两个虚拟地址可能共享一个cache line.
--
Cheers,
Oliver Yang
Twitter: http://twitter.com/yangoliver
Blog: http://blog.csdn.net/yayong
--------------------------------------------------------------------
An OpenSolaris Developer
Guancheng Chen
心FS。
On 3月6日, 下午4时11分, oliver yang <yangoli...@gmail.com> wrote:
> 在 2010年3月6日 下午11:00，jigsaw <jig...@gmail.com> 写道：
>
> > 我觉得程序员也需要关心cache coherence，因为cache coherence带来的false sharing效果对性能有可能造成成倍的影响。
>
> False sharing本质上不是cache coherence带来的问题，而是cache的多路关联技术带来的问题。
>
> Cache本来就小，内存中总会有不相干的两个虚拟地址可能共享一个cache line.
>
>
>
>
>
>
>
> > 2010/3/6 Guancheng Chen <chenguanch...@gmail.com>
>
> >> 本文所讨论的计算机模型是Shared Memory Multiprocessor，即我们现在常见的共享内存的多核CPU。本文适合的对象是想用C
> >> ++或者Java进行多线程编程的程序员。
>
> >> Sequential Consistency（下文简称SC）是Java内存模型和即将到来的C++0x内存模型的一个关键概念，它确保了你的多线程
> >> 程序在执行时的正确性。Cache Coherence（下文简称CC）是多核CPU在硬件中已经实现的一种机制，简单的说，它确保了对一个内存地址的
> >> 任何读操作一定会返回那个内存地址最新的（被写入）的值。
>
> >> 那么为什么程序员需要关心SC呢？因为现在的硬件和C++编译器都还未保证SC，也就是说你用C++编写的多线程程序可能会得到不正确的运行结果。
> >> Java从JDK1.5开始加入SC支持，所以Java程序员在进行多线程编程时需要特别注意使用Java提供的相关机制来确保你程序的SC。程序员之
> >> 所以不需要关心CC是因为现在的它已经被硬件的实现给保证了。
>
> >> 因为这篇文章有很多表格，而且我不知道group能不能很好的支持它，所以为了保证格式的美观，阅读全文请点击链接：
>
> >>http://www.parallellabs.com/2010/03/06/why-should-programmer-care-abo...
oliver yang
--
oliver yang
> ++或者Java进行多线程编程的程序员。
>
> Sequential Consistency（下文简称SC）是Java内存模型和即将到来的C++0x内存模型的一个关键概念，它确保了你的多线程
> 程序在执行时的正确性。Cache Coherence（下文简称CC）是多核CPU在硬件中已经实现的一种机制，简单的说，它确保了对一个内存地址的
> 任何读操作一定会返回那个内存地址最新的（被写入）的值。
>
> 那么为什么程序员需要关心SC呢？因为现在的硬件和C++编译器都还未保证SC，也就是说你用C++编写的多线程程序可能会得到不正确的运行结果。
使用同步对象可以保证不会有乱序的问题的，SC的问题往往出在一些 lock free的设计里，Peterson算法是一个经典案例：
http://en.wikipedia.org/wiki/Peterson%27s_algorithm
> Java从JDK1.5开始加入SC支持，所以Java程序员在进行多线程编程时需要特别注意使用Java提供的相关机制来确保你程序的SC。程序员之
> 所以不需要关心CC是因为现在的它已经被硬件的实现给保证了。
想深入理解SC就得知道CC。
>
> 因为这篇文章有很多表格，而且我不知道group能不能很好的支持它，所以为了保证格式的美观，阅读全文请点击链接：
>
> http://www.parallellabs.com/2010/03/06/why-should-programmer-care-about-sequential-consistency-rather-than-cache-coherence/
>
> 小弟第一次写这么长的文章，请大家帮忙指正批评！谢谢！
这篇文章大概看了一下，里面提到了SC被编译器错误优化的例子，但实际上，更多的情况是多处理器系统的CC协议只能保证在一个处理器cache里写过的内存，在另一个cache里读时会被更新的情况。
大多数架构为了性能，只保证了写(store)顺序，而读写之间是可以乱序的。因此，即便编译器处理对了顺序，但到了SMP系统，即使有CC也不能阻止读写之间的顺序问题。
所以，才会有处理器支持Memory barrier的指令。
http://en.wikipedia.org/wiki/Memory_barrier
我说的这点在你的参考文献里有说明，但你的博客里没有提到：
http://www.hpl.hp.com/personal/Hans_Boehm/c++mm/threadsintro.html
However, processors typically perform other kinds of optimizations
that have the effect of reordering memory accesses, so that ordinary
memory accesses no longer suffice for implementing synchronization
operations. For example, processors generally don't need to wait for
writes to complete to proceed with later computation and so buffer
incomplete writes and move on. When a subsequent load (from a
different address) completes while the write is still buffered, then
the reordering can become visible. This can result in the wrong
outcome for something like our introductory example, if x and y in the
example are synchronization variables. (For other such optimizations,
see Adve and Gharachorloo, Shared Memory Consistency Models: A
Tutorial, IEEE Computer, 1995.)
In order to address this issue, processors typically also provide
memory fence instructions. These serve as markers to the processor to
inhibit certain optimizations for specific instructions. For our
hypothetical hardware, we will consider a generic fence that ensures
that a memory operation appearing before the fence becomes visible to
all processors before any that appears later.
这篇文档里说的fence指令就是Memory barrier。
如果能正确的使用Memory barrier，有些情况下可以利用它做些lock free的设计了。
Guancheng Chen
On 3月6日, 下午4时33分, oliver yang <yangoli...@gmail.com> wrote:
> Cache Coherence在不同架构的机器上实现是不一样的，MESI是其中一种，Intel x86用的就是这钟实现。
>
> 在 2010年3月6日 下午9:08，Guancheng Chen <chenguanch...@gmail.com> 写道：
>
>
>
>
>
> > 本文所讨论的计算机模型是Shared Memory Multiprocessor，即我们现在常见的共享内存的多核CPU。本文适合的对象是想用C
> > ++或者Java进行多线程编程的程序员。
>
> > Sequential Consistency（下文简称SC）是Java内存模型和即将到来的C++0x内存模型的一个关键概念，它确保了你的多线程
> > 程序在执行时的正确性。Cache Coherence（下文简称CC）是多核CPU在硬件中已经实现的一种机制，简单的说，它确保了对一个内存地址的
> > 任何读操作一定会返回那个内存地址最新的（被写入）的值。
>
> > 那么为什么程序员需要关心SC呢？因为现在的硬件和C++编译器都还未保证SC，也就是说你用C++编写的多线程程序可能会得到不正确的运行结果。
> > Java从JDK1.5开始加入SC支持，所以Java程序员在进行多线程编程时需要特别注意使用Java提供的相关机制来确保你程序的SC。程序员之
> > 所以不需要关心CC是因为现在的它已经被硬件的实现给保证了。
>
> > 因为这篇文章有很多表格，而且我不知道group能不能很好的支持它，所以为了保证格式的美观，阅读全文请点击链接：
>
> >http://www.parallellabs.com/2010/03/06/why-should-programmer-care-abo...
Guancheng Chen
有一个基本的认识，知道"哦！这个问题我需要考虑"，然后他们就会去关注这个问题，进而进一步去看更多的资料。不过我会在文中加入相关论文的介绍，谢谢
指正！
On 3月6日, 下午5时47分, oliver yang <yangoli...@gmail.com> wrote:
> 在 2010年3月6日 下午9:08，Guancheng Chen <chenguanch...@gmail.com> 写道：
>
> > 本文所讨论的计算机模型是Shared Memory Multiprocessor，即我们现在常见的共享内存的多核CPU。本文适合的对象是想用C
> > ++或者Java进行多线程编程的程序员。
>
> > Sequential Consistency（下文简称SC）是Java内存模型和即将到来的C++0x内存模型的一个关键概念，它确保了你的多线程
> > 程序在执行时的正确性。Cache Coherence（下文简称CC）是多核CPU在硬件中已经实现的一种机制，简单的说，它确保了对一个内存地址的
> > 任何读操作一定会返回那个内存地址最新的（被写入）的值。
>
> > 那么为什么程序员需要关心SC呢？因为现在的硬件和C++编译器都还未保证SC，也就是说你用C++编写的多线程程序可能会得到不正确的运行结果。
>
> 使用同步对象可以保证不会有乱序的问题的，SC的问题往往出在一些 lock free的设计里，Peterson算法是一个经典案例：
>
> http://en.wikipedia.org/wiki/Peterson%27s_algorithm
>
> > Java从JDK1.5开始加入SC支持，所以Java程序员在进行多线程编程时需要特别注意使用Java提供的相关机制来确保你程序的SC。程序员之
> > 所以不需要关心CC是因为现在的它已经被硬件的实现给保证了。
>
> 想深入理解SC就得知道CC。
>
>
>
> > 因为这篇文章有很多表格，而且我不知道group能不能很好的支持它，所以为了保证格式的美观，阅读全文请点击链接：
>
> >http://www.parallellabs.com/2010/03/06/why-should-programmer-care-abo...
oliver yang
在高级语言层面的SC的实现大概离不了memory barrier, 但不清楚其实现是否更复杂一些。
如果是内核程序员，能用SC的当然expense比LOCK要小些。
当然所有同步原语的实现里面必然有条指令等价于memory barrier，使用memory barrier和LOCK都会引起CPU
pipeline stall的问题。
Guancheng Chen
以及引入了一些Lock free的实现。针对即将到来的C++0x讨论下SC primitive和Lock的使用真的很有价值，有机会我会写一篇，
谢谢！
On 3月6日, 下午5时59分, oliver yang <yangoli...@gmail.com> wrote:
> 其实，高级语言同时支持SC和LOCK以后，程序员讨论一下什么时候用SC什么使用用LOCK就更有意义了。
>
> 在高级语言层面的SC的实现大概离不了memory barrier, 但不清楚其实现是否更复杂一些。
>
> 如果是内核程序员，能用SC的当然expense比LOCK要小些。
>
> 当然所有同步原语的实现里面必然有条指令等价于memory barrier，使用memory barrier和LOCK都会引起CPU
> pipeline stall的问题。
>
jigsaw
Guancheng Chen
序在cache上面的性能问题。
On 3月6日, 下午9时31分, jigsaw <jig...@gmail.com> wrote:
> 刚好最近就在优化一个shared memory的问题 加入cache line的考量 性能差别在0.5-1倍之间
> 有不止一篇paper说达到了2-4倍的差别。。。不知道他们怎么跑出来的
> 如果是要加入spin lock的话。。。没测试过，不好说。
> 另外刚做了个小测试 intel xeon x5450的mfence/lfence/sfence对性能的影响不太明显--但是可见
> 在我的测试用例里大约在4%以下
> 不知道octeon的syncw有多大....礼拜一去公司跑跑看
>
> 2010/3/6 Guancheng Chen <chenguanch...@gmail.com>
jigsaw
Guancheng Chen
Multiprocessor Cache Model
On 3月7日, 下午2时02分, jigsaw <jig...@gmail.com> wrote:
> 我不是intel的 我们也很少用intel的cpu
> 看了一下介绍，那个acumem的产品是自带编译器的吗？
>
> 2010/3/7 Guancheng Chen <chenguanch...@gmail.com>
jigsaw
Guancheng Chen
告了，典型的情况是几分钟就能出结果，false sharing，memory bandwidth的相关问题也都能检测出来
On 3月7日, 下午2时34分, jigsaw <jig...@gmail.com> wrote:
> 扫了下论文。既然是靠sampling来采集数据的，那岂不是有平台依赖性？他们貌似没有做多平台的版本。
> 而且必须得有binary才行。
> 如果是一般情况下无法运行的binary，比如说内核代码，或者firmware类型的，怎么办？
>
> 2010/3/7 Guancheng Chen <chenguanch...@gmail.com>
Guancheng Chen
http://www.acumem.com/index.php?option=com_content&task=view&id=82&Itemid=134
On 3月7日, 下午2时34分, jigsaw <jig...@gmail.com> wrote:
> 扫了下论文。既然是靠sampling来采集数据的，那岂不是有平台依赖性？他们貌似没有做多平台的版本。
> 而且必须得有binary才行。
> 如果是一般情况下无法运行的binary，比如说内核代码，或者firmware类型的，怎么办？
>
> 2010/3/7 Guancheng Chen <chenguanch...@gmail.com>