From owner-sc22wg5+sc22wg5-dom8=www.open-std.org@open-std.org Thu Dec 11 20:26:18 2014 Return-Path: X-Original-To: sc22wg5-dom8 Delivered-To: sc22wg5-dom8@www.open-std.org Received: by www.open-std.org (Postfix, from userid 521) id 4BB78358295; Thu, 11 Dec 2014 20:26:18 +0100 (CET) Delivered-To: sc22wg5@open-std.org Received: from mail-pd0-f175.google.com (mail-pd0-f175.google.com [209.85.192.175]) by www.open-std.org (Postfix) with ESMTP id 94E36356DCC for ; Thu, 11 Dec 2014 20:26:17 +0100 (CET) Received: by mail-pd0-f175.google.com with SMTP id g10so3602163pdj.20 for ; Thu, 11 Dec 2014 11:26:16 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to; bh=qU14HJOYcdQuGheuUfObjdAuexo6jMj7nwilKYeXYqM=; b=TMtz7/N2yK4ybFrAU8NP7d7pVYAE2S2S1cbrDZ150YWgkyEuKunx4O1OMy5a0moqzT YXCFko6c/y79BxS1a5MPKwi9Is4l3aeDl20Nj6Uqmi/hFWy4N0eLVPzwdj45uRJ+uS8o UE+98sV+FhTNpSxChuDShV2+Mja8tBmKiGbUwikQyuLeBOy6QGEc9Mz4zAtsOEWcU1Kb g9j0/vqZbezt59V7W6NmQbx2twM/T+SwMF2+L/Uij9jfjwCtu1vH2YTARBUMX3KKXz7t 18mjB1Q7PbNybqA6Z3PnnLjNQg8ngln/7Sy0bxS9arBS18p/JEOCzzPwPXOfDqj+ePvj YxBw== X-Gm-Message-State: ALoCoQngap6mDOmnNrPlMNkGsrEPZs4rnQhh3Ikj8/VGrYy9AT9w08B6WgpxjLxrmSJ1J9xVn6hv X-Received: by 10.70.90.10 with SMTP id bs10mr8276705pdb.165.1418325976247; Thu, 11 Dec 2014 11:26:16 -0800 (PST) Received: from ?IPv6:2601:9:a80:179f:74ce:2948:3810:306b? ([2601:9:a80:179f:74ce:2948:3810:306b]) by mx.google.com with ESMTPSA id gm11sm2042724pbd.63.2014.12.11.11.26.15 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 11 Dec 2014 11:26:15 -0800 (PST) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) Subject: Re: (j3.2006) (SC22WG5.5385) Straw vote on draft DTS From: Damian Rouson In-Reply-To: <20141207195158.20EE0358488@www.open-std.org> Date: Thu, 11 Dec 2014 11:26:14 -0800 Cc: WG5 List Content-Transfer-Encoding: quoted-printable Message-Id: <0EF5DA3D-6652-44A7-8859-70A05437D64B@rouson.net> References: <20141108182113.6EC5E3581CE@www.open-std.org> <20141207195158.20EE0358488@www.open-std.org> To: fortran standards email list for J3 X-Mailer: Apple Mail (2.1878.6) Sender: owner-sc22wg5@open-std.org Precedence: bulk On Dec 7, 2014, at 11:46 AM, Bill Long wrote: I have not attempted to fully digest the issues involved in the vote on = the draft TS, but I have one query and a few comments supportive of = Bill=92s response below. >=20 >=20 > There is substantial opinion that implementing stalled image recovery = is not easy. I do not disagree. In simplest terms, it is equivalent to = implementing the infrastructure to handle an exception handling = mechanism. It is a bit simpler - the handler is basically internal to = the runtime rather than user-specified, and if the relevant END TEAM = statement lacks a STAT=3D specifier, the code would end up aborting = anyway, so there is no need to do much before then. However, the basic = process of unwinding the call stack (if there is one) that grew after = the CHANGE TEAM statement execution is more or less the same as for an = exception handler. 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.=20 I will probably suffer for asking this, but just out of curiosity, would = building such an infrastructure make it more likely that a future = standard would support user-specified exception-handling? If so, then = from a user perspective, this would be a nice stepping stone. >=20 > The more general question of whether Fortran should include fault = tolerance on a timely schedule at all is really a question Fortran=92s = future relevance in the HPC market place. And that is the only market = where Fortran has a significant fraction of programming language = mindshare. The need for this capability is in the 2018-2020 =93exascale=94= time frame. If we miss that window, we=92re seriously disadvantaged. = The Fortran 2015 standard (with compilers available ~2018) is our last = opportunity to meet the schedule. Alternatives like MPI and SHMEM are = actively making progress in this area, realizing the same target dates = are looming.=20 I find this reasoning very compelling. I=92ve been for some time = touting the failed-image feature set as an example of Fortran leading = the way in an area that everyone recognizes as important at the = exascale. Letting this feature set slip beyond Fortran 2015 would = likely push Fortran to the back of the pack just as more and more users = are getting access to coarrays. We need for their early experiences = with corrays to be positive and for the path forward to appear = promising. =20 In my experiences teaching modern Fortran courses, it appears coarrays = have breathed new life into a language whose demise had long been = rumored. Earlier this year, students started asking me to move coarray = parallel programming to the beginning of my classes and I now use = coarrays throughout each class. (My new motto is =93serial code is = legacy code.=94) Furthermore, considering the installed base of the = Cray Compiler Environment, the Intel compiler, and the upcoming GFortran = 5.0 release, I can=92t help but wonder if Fortran might soon (or = already) be the most widely available PGAS language o the planet. = Finding ways to capitalize on this momentum by anticipating trends and = responding early with relevant features might go a long way toward = ensuring the language=92s future. Will there be any possibility for implementors to leverage the MPI or = SHMEM progress Bill is citing? GFortran/OpenCoarrys is already doing = this in other areas: using MPI=92s one-sided communication and = collective communication to support the same in coarray Fortran. >=20 > The idea that vendors need to implement a facility like fault = tolerance before including it in the standard is out of touch with the = realities of modern-day compiler development. It might have been viable = in the past, but today=92s compiler vendors will implement a feature = AFTER is it in the standard, not before. Not only is this an economic = reality, but also a positive for program portability. In many cases = from the past where vendors implement new facilities outside the = standard, the features end up being =93extensions=94 that don=92t go = away but perpetually lead to non-portable code for programmers who use = them. On platforms with multiple Fortran compilers, this is a recurring = frustration.=20 Moreover, it can be hard to get vendors to implement features even long = after they are in the standard and GFortran appears to be the only = implementor that is actively pushing beyond the standard by already = supporting the collective communication features proposed in this draft = TS. I don=92t think it would be good for the viability of the language = to wait for vendor implementations to precede standardization, = especially in this timely area. The elephants in this room are the = funding agencies that are putting massive financial, technological, and = human resources behind the push to reach the exascale in a timely = manner. Of necessity, other parallel programming models will tackle = this problem and, as suggested above, I would hope that implementors can = leverage their work if implementing their own solution proves = cost-prohibitive. That ability to build on top of a range of = communication libraries is to me one of the best features of coarray = Fortran. Damian=