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

[Keith Bierman]

On Nov 6, 2008, at 1:42 AM, N.M. Maclaren wrote:

>
> Firstly, most systems have no way to prevent one job from hogging  
> resources
> like memory, cache, TLB entries, and so on.  There are rarely any  
> facilities
> to say "give this process N cores or don't run it" or "restrict  
> this program
> to x% of the cache or TLB entries".

Most mainframes had very mature facilities. Some Unix operating  
environments have reasonably good ones (google solaris resource  
management containers).


>
> Secondly, the thread schedulers are almost always optimised for  
> interactive
> (GUI) work,

Tunable on the better systems.

>> .....
>
> You are assuming that the world is like Cray.  It isn't.  I am  
> referring
> to the multi-core systems that are used for mixed workloads, of the  
> sort
> I describe above.  And, yes, I managed Cray-like systems for a  
> decade, so
> I can talk both languages

No doubt many institutions don't segregate jobstreams in a sensible  
fashion. And doubtless there are reasons for their behaviors (good,  
bad, non-technical, etc.) but precisely how does that translate into  
what should be part of a Standard?
> ...
> 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.

It should be possible to configure the runtime so that only N images  
can run ... and N could be 1. While that might not provide the  
clearest programming style, what's the issue for a Standard?

> ....    b) Because of that, SSE optimisations are handled by all  
> compilers in
> simi

No doubt more to come in the not so distant future. Indeed, some  
people have noticed that today's graphic processors are attached  
processors in the rough style of the FPS array processors of  
yesteryear. Where there are compute engines there will eventually be  
people trying to exploit them ;> But that also seems to be a bit of a  
digression from the question of the advisability of adding coarrays.

If they aren't "everywhere" (for some reasonable value of everwhere)  
and committed to be in future products, most people won't be able to  
make the investment in coding for them. So make them part of the  
standard, or throw them off the train entirely. The middle ground is  
largely an empty wasteland.

>

-- 
Keith H. Bierman   khbkhb at gmail.com      | AIM kbiermank
5430 Nassau Circle East                  |
Cherry Hills Village, CO 80113           | 303-997-2749
<speaking for myself*> Copyright 2008