(j3.2006) (SC22WG5.3631) [ukfortran] N1751

[N.M. Maclaren]

On Nov 6 2008, Michael Ingrassia wrote:

>There's a premiss in N1751.txt that I'm not sure I believe, although
>I may be reading it wrong.
>
>>Segments Pi and Qj are unordered, and it is therefore permitted for a
>>processor to execute segment Qj to completion before starting segment
>Pi.
>
> I accept that in theory, there is no argument based solely on segment 
> ordering to disallow a processor to execute segment Qj to completion 
> before starting segment Pi.
>
>But do we actually say that a processor is permitted to predicate
>the start of segment Pi on the completion of a different segment? 

You're reading something into N1751 that I didn't say, imply or mean.
The issue is not about a processor adding new ordering constraints, but
about whether it is conforming to ALLOW that ordering to happen.

>And if not, then doesn't the principle of Get On With It
>(or whatever you might call it) say that the processor has to 
>eventually start Pi?

Can you point me at anything in the standard that states that principle?

More seriously, why do you think that the processor can (let alone should)
decide that the best strategy is to stop doing what it thinks is useful
work in order to achieve fairness between images?  Knowing when to do that
and when not to is equivalent to solving the Halting Problem ....

>After all, we don't worry that the PRINT will
>never happen in
>
>	R = SIN(3.04789232)
>	PRINT *, R
>
>because the processor might never get around to advancing the program
>counter.

That isn't comparable.  That isn't reasonable processor behaviour, and the
industry consensus has always been that such gratuitously perverse behaviour
is a bug.

The issue I raise IS reasonable behaviour.  One standard scheduling strategy
is to run threads while they are consuming CPU, and to look for another to
run only when they enter a wait state.  The same principle is used in most
HPC job schedulers, where a node is dedicated to a job until that job
finishes, and is only then reallocated.

Furthermore, as I said, it really does happen in existing systems. Please 
ask me in Tokyo why even configuring the system to use round-robin 
scheduling doesn't always work. The executive summary is that, sometimes, 
both threads can be assigned affinity to the same core and the looping 
thread can end up with a higher priority. Whereupon, my scenario happens.

>Maybe the principle is that an implementation risks being incorrect if it
>introduces extra segment orderings  (Qj must precede Pi)
>not implied by the standard.   In other words, this is a processor problem
>not a user problem.
>
>What am I missing?

Any wording in the standard that I, as the local expert, could use to beat
the vendor over the head with :-(

Many (most?) vendors point-blank refuse to accept bug reports that are not
clear breaches of the standard or their documentation - and sometimes even
if they are! - security failures, or serious performance issues.

No names - no pack drill :-)


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