(j3.2006) (SC22WG5.5388) [ukfortran] Straw vote on draft DTS

[Bill Long]

On Dec 7, 2014, at 2:45 PM, Malcolm Cohen <malcolm at nag-j.co.jp> wrote:

> Bill Long writes:
> <<<
> it is equivalent to implementing the infrastructure to handle an exception 
> handling mechanism. [...] Given that exception handlers already exist in other 
> languages, and certainly at the system level, the argument that implementors do 
> not know how to do this seems weak at best.  I understand grumbling about hard 
> work, not claims of inability.
>>>> 
> 
> So we've got to do all the work to implement exception handling (and more), but 
> the user does not get the benefit of actually having exception handling in the 
> language?
> 
> We've knocked back Exception Handling in the past several times, mostly because 
> we considered the cost-benefit ratio to be unsatisfactory.  To have to do a 
> great deal of that work now, as a mere by-the-by from this TS, with even fewer 
> benefits than before, is unbelievable.

The previous debates on exception handling were before I joined the committee.  If the TS capability were implemented in enough compilers, perhaps a future proposal for exception handling would face a lower hurdle. 

However, the TS provides an escape clause for vendors who do not want to do this work.  They can set STAT_STALLED_IMAGE to a negative value ( -666 might be available), telling the programmer that that the ability to detect a stalled image is not supported.  But, for the vendors whose customers need this capability, the semantics need to be specified in the standard.  


> 
> And the claims of inability (from me at least) are to do with implementing it 
> *efficiently* without impacting programs that do not use the feature.  The fact 
> that the huge clanking machinery of C++ exceptions exists, and slows down C++ 
> programs, is not a counterexample!

I appreciate concerns about performance.   However, I don?t think the actual effects will be that severe overall.  For a serial code,  a parallel code that does not use coarrays, a code that does not scale to a large number of images, at code with no CHANGE TEAM statements, or a code that runs in a short time, the ability to recover from a stalled image is not that important.   I would expect vendors to offer something like a -h noft flag to turn off the fault tolerance features.  This would cover a pretty large swath of codes.  Even Cray has a -h nocaf switch to prevent linking in the coarray runtime library for codes that have no coarray content.  For codes that do need the fault tolerance capabilities, there are still strategies to minimize the performance hit.  Subprograms that do not have any need for return-site deallocations or finalizations (which covers a significant fraction of all subprograms) don?t need any significant processing.  Small functions can be inlined, eliminating any return-site processing.    The overall performance effect of handling stalled images is likely to be minimal for codes that use it, and not an issue for codes that don?t.  We?ve been there before.  Finalization is a drag on performance, but it affects only codes that use types with final subroutines. Those who want the capability appear willing to pay the price. 


Cheers,
Bill


> 
> Cheers,
> -- 
> ................................Malcolm Cohen, Nihon NAG, Tokyo. 
> 
> _______________________________________________
> J3 mailing list
> J3 at mailman.j3-fortran.org
> http://mailman.j3-fortran.org/mailman/listinfo/j3

Bill Long                                                                       longb at cray.com
Fortran Technical Suport  &                                  voice:  651-605-9024
Bioinformatics Software Development                     fax:  651-605-9142
Cray Inc./ Cray Plaza, Suite 210/ 380 Jackson St./ St. Paul, MN 55101