(j3.2006) (SC22WG5.3642) [ukfortran] [Fwd: Preparing for the Tokyo meeting]

[N.M. Maclaren]

On Nov 6 2008, Keith Bierman wrote:
>
>> ...Linux is no different.  The solution is usually the one  
>> mentioned above
>> (i.e. give the gang-scheduled software enough cores that you don't  
>> cause
>> conflicts with other applications).
>
>And keep the jobs that need gang scheduling on a "machine" (virtual  
>perhaps) of their own with a batch scheduler and no interactive jobs.

Agreed.  That's what I did (after my experience of not doing it with
IRIX, when I was new to managing large SMPs).

>I disagree. As far as I can tell, nearly all programming language  
>standards make the implicit assumption that they own the "machine".  
>It's is the OS's job to make that illusion real enough (except where  
>some "volatile" asynch service is taking place that the application  
>wishes to consume ;>

Yes and no.  The problem is when a language assumes an operating system
model that isn't near-universal.  If anyone thinks that Fortran has enough
weight to swing major operating system redesign, they are living in cloud
cuckoo land.

>Coarrays should be a lot easier to deal with (code for, port, etc.)  
>than MPI. MPI has proved useful across a variety of implementations  
>despite having a weak foundation. Coarrays are a step forward. They  
>probably aren't the last step; but it will be years before we get  
>"there" and we probably won't if we don't make stepwise improvements ;>

That is a matter of opinion, but I don't intend to debate it - but please
note that I am not saying that coarrays (except for VOLATILE ones) are a
step backwards.  They have advantages and disadvantages over MPI.


Regards,
Nick Maclaren,
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