From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Original-To: caml-list@yquem.inria.fr Delivered-To: caml-list@yquem.inria.fr Received: from concorde.inria.fr (concorde.inria.fr [192.93.2.39]) by yquem.inria.fr (Postfix) with ESMTP id C107DBB81 for ; Thu, 9 Mar 2006 11:36:09 +0100 (CET) Received: from rwcrmhc11.comcast.net (rwcrmhc11.comcast.net [216.148.227.151]) by concorde.inria.fr (8.13.0/8.13.0) with ESMTP id k29Aa8DJ018876 for ; Thu, 9 Mar 2006 11:36:09 +0100 Received: from [192.168.1.100] (c-66-30-201-48.hsd1.ma.comcast.net[66.30.201.48]) by comcast.net (rwcrmhc11) with SMTP id <20060309103607m11001kmibe>; Thu, 9 Mar 2006 10:36:07 +0000 Mime-Version: 1.0 (Apple Message framework v623) In-Reply-To: <1141878751.8450.37.camel@budgie.wigram> References: <440DB255.1030701@asfandyar.cjb.net> <1141751708.20944.355.camel@budgie.wigram> <440DD982.8080800@asfandyar.cjb.net> <1141779125.20944.405.camel@budgie.wigram> <20060308193633.GA5460@coruscant.stwing.upenn.edu> <1141855594.23909.63.camel@budgie.wigram> <1141863807.23909.151.camel@budgie.wigram> <1141878751.8450.37.camel@budgie.wigram> Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: John Chu Subject: Re: [Caml-list] STM support in OCaml Date: Thu, 9 Mar 2006 05:38:08 -0500 To: caml-list@yquem.inria.fr X-Mailer: Apple Mail (2.623) X-Miltered: at concorde with ID 44100518.001 by Joe's j-chkmail (http://j-chkmail.ensmp.fr)! X-Spam: no; 0.00; ocaml:01 coherence:01 chu:98 reloads:98 caml-list:01 hierarchy:01 data:02 data:02 snip:02 thread:05 thread:05 remind:06 processor:06 processor:06 acm:06 X-Spam-Checker-Version: SpamAssassin 3.0.3 (2005-04-27) on yquem.inria.fr X-Spam-Level: * X-Spam-Status: No, score=1.0 required=5.0 tests=RCVD_IN_NJABL_PROXY autolearn=disabled version=3.0.3 > I know, so was I -- I've read the AMD64 specs. [snip] > The first thread > has to load stuff from RAM to populate the array, > which slows it down. > > Then it has to write the whole array back to RAM, > and the second thread reloads the whole array from > RAM into the cache. If you've read the AMD64 specs, then you know about the Owned state in the cache coherence protocol AMD chips use. It allows one processor to update another processor without having to update main memory. i.e., one processor goes from M->O, the other goes from I->S. The O state is there to remind the first processor that on an eviction, it can't simply drop the cache line (as it could a line in the S state). It must write back to main memory as if it were in the M state. You're obviously right that two processes on two cores use the same data, the data will obviously need to be copied from the cache hierarchy of one core to the other core. What I'm saying is that it does not need to write into main memory first. john