From: Maciej Golebiewski Newsgroups: comp.parallel.mpi Subject: Re: MPICH on single CPU Linux workstation Date: Tue, 11 May 1999 12:58:54 +0200 Organization: Organization? Me??? Message-Id: <37380D6E.F2439B2D@hotbot.com> References: <3732261D.3064F078@caltech.edu> <7h7c2j$bri$1@milo.mcs.anl.gov> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Xref: ukc comp.parallel.mpi:5069 Hi, We've been using ch_lfshmem under Linux for some time and everything is working OK. Of course, this doesn't mean a thing :) so after reading Rusty's post I felt a little bit nervous. As a result I have just looked through the code for the device to make sure that there are no strange things. The result of my code "audit" and talks with Hubert (the guy behind ch_lfshmem) is that the situation is not that bad, but not perfect either. Basically, it all depends on the memory interface of your machine. If you have a normal PC, eventually a dual-CPU machine with the memory interface behaving nicely (i.e. the data that goes out of CPU gets written into memory chips in the same order) and cache-coherent, then everything will work well. The problem is with how the chipsets of high-end PC servers (those boxes with 4 or 8 Xeon processors) work: it might be that for performance reasons the chipset re-orders memory writes, so that the final ordering is different that what goes out of CPU. In that case, well, you should not use lfshmem, or you should port it to your chipset. But for a normal single or dual Intel CPU box, ch_lfshmem should be safe to use. Maciej Golebiewski Rusty Lusk wrote: > communication through shared memory, which will be faster. You should > not use the ch_lfshmem device on Linux. Although it may work in > several environments, it has only been fully tested on the NEC SX-4, > and relies on Japanese assembler language :-).