(j3.2006) (SC22WG5.3640) [ukfortran] [Fwd: Preparing for the Tokyo meeting]
Thu Nov 6 15:39:57 EST 2008
On Nov 6 2008, Bill Long wrote:
>> Firstly, most systems have no way to prevent one job from hogging
>> resources like memory, cache, TLB entries, and so on.
>That's a management / policy decision, not a software constraint.
>Certainly not an issue relevant to whether coarrays should be in the
It's actually a hardware constraint. I agree that it is not directly
relevant, unlike the scheduler issue, because it doesn't stop programs
completing. I shouldn't have responded - sorry.
>> There are rarely any facilities
>> to say "give this process N cores or don't run it"
>The providers of things like PBS, moab, lsf, ... will be very
>disappointed to learn that their products don't work
No, they won't. They document precisely that. They rely on the underlying
operating system providing such control and, if it doesn't, they don't
provide it. And that, in turn, can cause the scheduler problems.
>> It's not specifiable. Some coarray programs can survive that
>> environment; others can't; and it isn't possible to write a clear
>> specification of which can and which can't.
>What is not specifiable? We have a compiler flag, -Xn where n is the
>number of images that will fix the number at compile time. That looks
>specifiable to me. Sure, if a program explicitly references image 2 and
>is run with only 1 image, it will get an error. But that is clearly
>specified in the standard as non-conforming.
The set of programs that will work with such a constraint is not
>I can't speak for IBM, Hitachi, or Fujitsu, but at least I know now you
>are not aware of what happens in Cray's compiler.
I accept the correction. I have never used any Cray system, neither old
Cray nor new Cray.
University of Cambridge Computing Service,
New Museums Site, Pembroke Street, Cambridge CB2 3QH, England.
Email: nmm1 at cam.ac.uk
Tel.: +44 1223 334761 Fax: +44 1223 334679
More information about the J3