[cpp-threads] Fw: Intel 64 Memory Ordering document

[Alexander Terekhov]

More FYI. (See AMD below.)

< 2 x Forward Quoted>

"comp.arch at patten-glew.net" wrote:
>
> I believe that cross-posting this to newsgroups comp.arch and
> comp.parallel is appropriate.
> [Moderator: it is.]
>
> Longtime readers of comp.arch may know
>    a) that I was involved in defining Intel's implementation of memory
> ordering (the P6 MOB, etc.), and that I am actually a little bit proud
> of that work.
>    b) that I have long been embarassed by Intel's documentation of
> this memory ordering model.
>
> I am happy to report that a much improved document describing Intel's
> memory ordering model has been posted to
> http://developer.intel.com/products/processor/manuals/index.htm:
>
> >Intel(r) 64 Architecture Memory Ordering White Paper
>
> >This document provides information for Intel 64 architecture memory ordering
> >at a level that is architecturally visible to software. The principles and examples
> >provide software writers with a clear understanding of the results that different
> >sequences of memory access instructions may produce.
>
> The guys who got this pushed through Intel deserve much credit. I wish
> that I could congratulate them here by name, but that seems not to be
> allowed.
>
> The document is not perfect (e.g. it is not allowed to use the term
> "atomic"), but it is greatly better than what has been available in
> the past.
>
> I expect that people who need to write parallel programs on Intel
> processors will find this clarifies many heretofore muddy issues.
>
> ---
>
> One particular issue:  every so often somebody talks about a parallel
> algorithm on Intel processors, and I have felt obliged to point out
> that the "official" Intel memory ordering model, as it was documented
> in the SDM (Software Developers' Manual), and as I defined it ever so
> long ago, did not guarantee causality.
>
> I.e.
>
> Initially x = y = 0
>
> P1:  x = 1
>
> P2: if( x ) y = 1
>
> P3:
>       ry = y
>       rx = x
>       if( ry )
>           if( !rx )
>               assert( ! "it should not be possible to have ry==1 and
> rx==0" )
>
> was NOT guaranteed to work, heretofore.
>
> The new white paper says that causality is guaranteed: "In a
> multiprocessor system, memory ordering obeys causality (memory
> ordering respects transitive visibility)."
>
> Indeed, all implementations have provided causality; now it is
> official.
>
> This is good, because many programmers implicitly assume causality.
>
> ===
>
> This is a personal post. It is not approved by (or disapproved by) my
> employer, Intel. I tell you my employer so that you can account for
> any bias I may have.
>
> --


david.christie at amd.com wrote:
>
> On Sep 7, 11:31 am, "comp.a... at patten-glew.net" <AndyG... at gmail.com> wrote:
> > Longtime readers of comp.arch may know
> >    a) that I was involved in defining Intel's implementation of memory
> > ordering (the P6 MOB, etc.), and that I am actually a little bit proud
> > of that work.
> >    b) that I have long been embarassed by Intel's documentation of
> > this memory ordering model.
> >
> > I am happy to report that a much improved document describing Intel's
> > memory ordering model has been posted tohttp://developer.intel.com/products/processor/manuals/index.htm:
> >
> > >Intel(r) 64 Architecture Memory Ordering White Paper
> > >This document provides information for Intel 64 architecture memory ordering
> > >at a level that is architecturally visible to software. The principles and examples
> > >provide software writers with a clear understanding of the results that different
> > >sequences of memory access instructions may produce.
> >
> [snip]
>
> Just so people are aware, AMD's most recent edition of the AMD64
> Architecture Programmer's Manual (rev 3.13, Vol 2, section 7.2,
> available at http://developer.amd.com/devguides.jsp) has similar
> clarifications on memory ordering for Opteron systems.  (We realized
> that our documentation was somewhat lacking as well, and that people
> really do need to know this stuff... :) )
>
> Dave Christie
> not officially speaking on behalf of AMD
>
> --

regards,
alexander.

On 9/7/07, Paul E. McKenney <paulmck at linux.vnet.ibm.com> wrote:
> FYI!
>
>                                        Thanx, Paul
>
> ----- Forwarded message from "Saha, Bratin" <bratin.saha at intel.com> -----
>
> Date: Fri, 7 Sep 2007 13:16:01 -0700
> From: "Saha, Bratin" <bratin.saha at intel.com>
> To: "Boehm, Hans" <hans.boehm at hp.com>, Herb Sutter <hsutter at microsoft.com>,
>        Sarita V Adve <sadve at cs.uiuc.edu>,
>        Jeremy Manson <jeremymanson at google.com>,
>        Bill Pugh <pugh at cs.umd.edu>, Doug Lea <dl at cs.oswego.edu>,
>        vijay at saraswat.org, paulmck at linux.vnet.ibm.com
> Cc: "Hudson, Rick" <rick.hudson at intel.com>,
>        "Glew, Andy" <andy.glew at intel.com>
> Subject: Intel 64 Memory Ordering document
>
> The Intel 64 Memory Ordering document is now at
> http://developer.intel.com/products/processor/manuals/index.htm
> <http://developer.intel.com/products/processor/manuals/index.htm>
>
>
>
> -Bratin
>
>
>
>
> ----- End forwarded message -----
>
> --
> cpp-threads mailing list
> cpp-threads at decadentplace.org.uk
> http://www.decadentplace.org.uk/cgi-bin/mailman/listinfo/cpp-threads
>