From owner-sc22wg5+sc22wg5-dom8=www.open-std.org@open-std.org Wed Jul 5 22:01:36 2017 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 BD04E3587E4; Wed, 5 Jul 2017 22:01:36 +0200 (CEST) Delivered-To: sc22wg5@open-std.org Received: from mail-oi0-f48.google.com (mail-oi0-f48.google.com [209.85.218.48]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by www.open-std.org (Postfix) with ESMTP id 42B8935695B for ; Wed, 5 Jul 2017 22:01:36 +0200 (CEST) Received: by mail-oi0-f48.google.com with SMTP id x187so77323932oig.3 for ; Wed, 05 Jul 2017 13:01:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=stevelionel.com; s=google; h=mime-version:in-reply-to:references:from:date:message-id:subject:to; bh=PTSCCKze5RU/TTp3bnPuEiAv77oTsnq75Z14tGSiJvM=; b=mkOwQOKvN0T3Uuk44A0KuUxn2QYLyQt1oSyD80MJzqdp2OyytEqCw09af5nkQyT67J bE7UTQ1/BhuUSZFKs+vBgD56UHB3bKzAaqUw4ipYsXbj1DuCWDNQYOnL/NjbZt5py+z1 NZH51AABhOLgQaagn0MDdp53eXCJ/+imzKFpM= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to; bh=PTSCCKze5RU/TTp3bnPuEiAv77oTsnq75Z14tGSiJvM=; b=YpqWTKiTH9LKkm+c9MI6PmFdMhbfFfHa0ajLPmFnrlCBh/x+y9nNqUHkN1usQl9h43 UoCVnkTbNqj/0iCcHDr2c1qeVcpp1qkZcrkSCxcJ0UsHBCvc0K4ptsmRprQcaZ11eoXk IUKnwdsTI8ENFbWijB6SURG7EFJpV7Y5Bsp3OrQdXaHDi8iNrUu6P0DxQNISVOom/XpL +Y+gD5ztL/6rVPjC5xjPVquDCUbihMr8ANyNEaP+mB/OziNg1hvLGRk7/nBcBT3Q4dW0 LhVu9T02nKnCTOrhGG3zyzW7QcHlOU5DPeHQ7FbEEFSM6JjDDKKAw6Gx95P/a4CY73Ox DedQ== X-Gm-Message-State: AKS2vOwUHMP2A0/vrj/BjLxaMGhtEQ1bDtAOsEmogwVvpbT4TL+dwbiK w5saFemqYTdOqEnVID0TiOyGMVU5Vosq7eo= X-Received: by 10.202.83.200 with SMTP id h191mr24013710oib.171.1499284894515; Wed, 05 Jul 2017 13:01:34 -0700 (PDT) MIME-Version: 1.0 Received: by 10.182.113.137 with HTTP; Wed, 5 Jul 2017 13:01:34 -0700 (PDT) X-Originating-IP: [71.168.105.188] In-Reply-To: <9A2D2BF6-EEEB-418B-A7B8-A27F54B1EFF1@cray.com> References: <20170705131003.C2A753587D1@www.open-std.org> <677196EB-62B3-448D-8AD9-6D0E36BAFD32@cray.com> <888EAD5C-B10E-4E55-9F63-35F1BBE2F342@nasa.gov> <9A2D2BF6-EEEB-418B-A7B8-A27F54B1EFF1@cray.com> From: Steve Lionel Date: Wed, 5 Jul 2017 16:01:34 -0400 Message-ID: Subject: Re: (j3.2006) (SC22WG5.5889) 3 levels of parallelism? To: WG5 Content-Type: multipart/alternative; boundary="001a113dd62a8e21d80553977735" Sender: owner-sc22wg5@open-std.org Precedence: bulk --001a113dd62a8e21d80553977735 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Wed, Jul 5, 2017 at 3:46 PM, Bill Long wrote: > > > Right. If GPU=E2=80=99s became as pervasive as multiple cores on a proce= ssor > chip, I suspect compiler vendors would take advantage of DO CONCURRENT to > target GPU=E2=80=99s. Ultimately, this is a customer demand issue, since > generating code for GPU=E2=80=99s is a non-trivial task. > This aspect of the industry goes in cycles - accelerators/coprocessors are a big thing for a while, and then the "general purpose" processor catches up and makes the accessory processor no longer of benefit, especially considering the additional demands it makes on the programmer. I expect that to happen again, and at least Intel has shown it is heading in that direction with bootable KNL and merged instruction sets. Lacking any inside knowledge, history tells me that in five years or so we'll be looking at unified architectures that "do it all". DO CONCURRENT and array operations already provide a compiler with enough information to intelligently apportion work across instruction-level parallelism (vectors) and thread-level parallelism, and to combine the two when it thinks it is efficient. Maybe today's compilers aren't quite there yet, but I don't see the need for any additional constructs in the language to "help" here. Steve . --001a113dd62a8e21d80553977735 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On W= ed, Jul 5, 2017 at 3:46 PM, Bill Long <longb@cray.com> wrote:


Right.=C2=A0 If GPU=E2=80=99s became as pervasive as multiple cores on a pr= ocessor chip, I suspect compiler vendors would take advantage of DO CONCURR= ENT to target GPU=E2=80=99s.=C2=A0 Ultimately, this is a customer demand is= sue, since generating code for GPU=E2=80=99s is a non-trivial task.

This aspect of the industry goes in cycles - a= ccelerators/coprocessors are a big thing for a while, and then the "ge= neral purpose" processor catches up and makes the accessory processor = no longer of benefit, especially considering the additional demands it make= s on the programmer. I expect that to happen again, and at least Intel has = shown it is heading in that direction with bootable KNL and merged instruct= ion sets. Lacking any inside knowledge, history tells me that in five years= or so we'll be looking at unified architectures that "do it all&q= uot;.

DO CONCURRENT and array operations already p= rovide a compiler with enough information to intelligently apportion work a= cross instruction-level parallelism (vectors) and thread-level parallelism,= and to combine the two when it thinks it is efficient. Maybe today's c= ompilers aren't quite there yet, but I don't see the need for any a= dditional constructs in the language to "help" here.=C2=A0
<= div>
Steve
--001a113dd62a8e21d80553977735--