From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 82240 invoked by alias); 18 Oct 2016 11:03:47 -0000 Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org Received: (qmail 82133 invoked by uid 89); 18 Oct 2016 11:03:46 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.2 required=5.0 tests=BAYES_00,RP_MATCHES_RCVD,SPF_HELO_PASS autolearn=ham version=3.3.2 spammy=Performance, fromscratch, patchset, fine-tuning X-HELO: mx1.redhat.com Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Tue, 18 Oct 2016 11:03:45 +0000 Received: from int-mx13.intmail.prod.int.phx2.redhat.com (int-mx13.intmail.prod.int.phx2.redhat.com [10.5.11.26]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 2C144624AA; Tue, 18 Oct 2016 11:03:44 +0000 (UTC) Received: from localhost.localdomain (vpn1-6-161.ams2.redhat.com [10.36.6.161]) by int-mx13.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id u9IB3gS1011233; Tue, 18 Oct 2016 07:03:43 -0400 Subject: Re: [PATCH 0/8] NVPTX offloading to NVPTX: backend patches To: Alexander Monakov References: <1476463189-22540-1-git-send-email-amonakov@ispras.ru> <6e6106d4-3ae9-54e2-c1d3-99a2580297dc@redhat.com> Cc: gcc-patches@gcc.gnu.org, Nathan Sidwell From: Bernd Schmidt Message-ID: Date: Tue, 18 Oct 2016 11:03:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.3.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-IsSubscribed: yes X-SW-Source: 2016-10/txt/msg01416.txt.bz2 On 10/17/2016 07:06 PM, Alexander Monakov wrote: > I've just pushed two commits to the branch to fix this issue. Before those, the > last commit left the branch in a state where an incremental build seemed ok > (because libgcc/libgomp weren't rebuilt with the new cc1), but a from-scratch > build was broken like you've shown. LULESH is known to work. I also intend to > perform a trunk merge soon. Ok that did work, however... >> I think before merging this work we'll need to have some idea of how well it >> works on real-world code. > > This patchset and the branch lay the foundation, there's more work to be > done, in particular on the performance improvements side. There should be > an agreement on these fundamental bits first, before moving on to fine-tuning. The performance I saw was lower by a factor of 80 or so compared to their CUDA version, and even lower than OpenMP on the host. Does this match what you are seeing? Do you have a clear plan how this can be improved? To me this kind of performance doesn't look like something that will be fixed by fine-tuning; it leaves me undecided whether the chosen approach (what you call the fundamentals) is viable at all. Performance is still better than the OpenACC version of the benchmark, but then I think we shouldn't repeat the mistakes we made with OpenACC and avoid merging something until we're sure it's ready and of benefit to users. Bernd