[O-MPI devel] SSIMS meeting
Jeff, I'm currently at the SciDAC2 SSIMS meeting talking about software integration, maintenance, and support funding (on the order of $2 million). I promised Rich I'd keep all informed. We've set up a IRC channel (separate email). Craig
Re: [O-MPI devel] poe PLS component
On Sep 2, 2005, at 4:55 AM, Jeff Squyres wrote: Can you guys convert POE's configure.stub to configure.m4? 4:55 AM, aren't you up kind of early?? Ciao, Craig
[O-MPI devel] Fwd: (j3.2005) Re: Derived types according to MPI2
Begin forwarded message: From: Aleksandar Donev Date: November 21, 2005 9:30:18 AM MST To: J3 Subject: (j3.2005) Re: Derived types according to MPI2 Hello, Malcolm Cohen wrote: Which just goes to show that the authors of MPI2 didn't understand Fortran, since that is completely and utterly false in every sense that matters. Yes, but the interesting thing is neither me nor Van were aware of what the standard actually allows in terms of derived types and the storage for the components, and presumably we know Fortran better. Can storage for the components be separated from the scalar derived type itself? This probably makes no visible difference for scalars, but for arrays it does. Again, I am asking about what STORAGE_SIZE for derived types should mean. Dan Nagle wrote: Please be aware that the "external world" of the MPI standard is really the virtual machine of the C standard. Yes, of course, I am certainly not proposing binding to hardware. When defining a programming language, the "needless abstraction" I should have qualified with "some needless abstractions". Of course abstractions are good, especially when it does not matter to the user how something is done as long as it is done well. But if you want to pass an array of derived types to a parallel IO routine that is not compiled by your super-smart Fortran compiler that chooses to scatter the components across virtual-address space (yes, I mean virtual), then you do NOT want that abstraction. It is about choice. Leave preaching to the preachers. Programming is a profession for a reason---programmers are experienced and educated and understand the issues and don't need lectures on abstractions. Aleks
[O-MPI devel] Fwd: (j3.2005) Re: Derived types according to MPI2
Begin forwarded message: From: Bill Long Date: November 21, 2005 11:03:46 AM MST To: Malcolm Cohen Cc: J3 Subject: (j3.2005) Re: Derived types according to MPI2 Reply-To: lo...@cray.com Malcolm Cohen wrote: Aleksandar Donev said: (like MPI standard). Gak. Just because MPI is a load of dingo's kidneys doesn't mean everyone else should make a horrible mess. MPI is a bad idea that spun out of control. It is mainly useful as an example of what to avoid. It certainly is diametrically opposed to the programmer productivity goals being pushed by DARPA. One hopes that the combination of Fortran 2008 and UPC will finally let users abandon this archaic monstrosity. Cheers, Bill -- Bill Long lo...@cray.com Fortran Technical Support & voice: 651-605-9024 Bioinformatics Software Development fax: 651-605-9142 Cray Inc., 1340 Mendota Heights Rd., Mendota Heights, MN, 55120
[O-MPI devel] Fwd: (j3.2005) Re: Derived types according to MPI2
Begin forwarded message: From: Malcolm Cohen Date: November 21, 2005 11:23:59 AM MST To: Aleksandar Donev Cc: J3 Subject: (j3.2005) Re: Derived types according to MPI2 Aleksandar Donev said: Yes, but the interesting thing is neither me nor Van were aware of what the standard actually allows in terms of derived types and the storage for the components, and presumably we know Fortran better. Can storage One might have hoped so. for the components be separated from the scalar derived type itself? Hey, when *I* am the Fortran processor there's no contiguous storage, or for that matter addressable storage! Don't take too limited a view of current "hard" ware. how something is done as long as it is done well. But if you want to pass an array of derived types to a parallel IO routine that is not compiled by your super-smart Fortran compiler that chooses to scatter the components across virtual-address space (yes, I mean virtual), then you do NOT want that abstraction. You cannot be serious. You do realise that there is no requirement on any array even on intrinsic data types to contain the "actual data". Is that a problem in practice? No of course not. The Fortran standard doesn't mention virtual addressing, physical addressing or any of these things. Is that a problem? No. What the standard should do (and usually does) is to specify the behaviour of the Fortran "virtual machine", i.e. the meaning of the program. How that program gets mapped to hardware is way outside the scope of the standard. It is about choice. Leave preaching to the preachers. Programming is a profession for a reason---programmers are experienced and educated and understand the issues and don't need lectures on abstractions. Apparently not. Cheers, -- ...Malcolm Cohen, NAG Ltd., Oxford, U.K. (malc...@nag.co.uk) __ __ This e-mail has been scanned for all viruses by Star. The service is powered by MessageLabs. For more information on a proactive anti-virus service working around the clock, around the globe, visit: http://www.star.net.uk __ __
Re: [O-MPI devel] Libtool 1.5.22
On Dec 20, 2005, at 7:34 AM, Jeff Squyres wrote: If you are watching the commit logs, you'll notice that Libtool 1.5.22 has been released. It fixes some problems that some of our users have been running into, and starting tonight, will be incorporated into all nightly snapshots. It will also be in Open MPI 1.0.2. Do you know what they've done for Fortran 90? Thanks, Craig
Re: [O-MPI devel] debugging methods
On Jan 3, 2006, at 11:38 AM, Jeff Squyres wrote: In addition to what Brian said, do you have any specific questions about Open MPI's build system, the BTL, etc.? There has been a flurry of traffic on CCA's email list about the lack of updates to autoconf. Will this affect you all in anyway? Cheers, Craig
Re: [O-MPI devel] debugging methods
On Jan 4, 2006, at 8:55 AM, Jeff Squyres wrote: On Jan 4, 2006, at 10:35 AM, Craig Rasmussen wrote: In addition to what Brian said, do you have any specific questions about Open MPI's build system, the BTL, etc.? There has been a flurry of traffic on CCA's email list about the lack of updates to autoconf. Will this affect you all in anyway? Not sure what you're asking. AC is at version 2.59. It's true that it hasn't changed in quite a while, though. AC is certainly not dead; they've had long periods of no releases before (I think they publicly jumped from 2.14 to 2.50 or somesuch). The CCA people seemed to be worried that there was a long dead time between releases and were wondering if they should give up on autoconf and move to something else (cmake). I love (to hate) autoconf and was hoping that it wasn't destined for the bit bucket. But since you all aren't worried, I won't be either. Thanks, Craig
