From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from lists.gentoo.org (pigeon.gentoo.org [208.92.234.80]) by finch.gentoo.org (Postfix) with ESMTP id D5141138454 for ; Sat, 12 Sep 2015 07:50:08 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id BFDDAE087B; Sat, 12 Sep 2015 07:49:59 +0000 (UTC) Received: from BLU004-OMC1S2.hotmail.com (blu004-omc1s2.hotmail.com [65.55.116.13]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by pigeon.gentoo.org (Postfix) with ESMTPS id A92A5E0869 for ; Sat, 12 Sep 2015 07:49:58 +0000 (UTC) Received: from BLU437-SMTP23 ([65.55.116.8]) by BLU004-OMC1S2.hotmail.com over TLS secured channel with Microsoft SMTPSVC(7.5.7601.23008); Sat, 12 Sep 2015 00:49:57 -0700 X-TMN: [z5bryFV4kz78zqNE4/wLAWptF8PRs7/q] X-Originating-Email: [frodriguez.developer@outlook.com] Message-ID: From: Fernando Rodriguez To: gentoo-user@lists.gentoo.org Subject: [gentoo-user] Re: OT: GCC 5 Offloading Date: Sat, 12 Sep 2015 03:49:02 -0400 User-Agent: KMail/4.14.8 (Linux/3.18.21; KDE/4.14.8; x86_64; ; ) In-Reply-To: References: <20150907195624.GC1081@ca.inter.net> Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-user@lists.gentoo.org Reply-to: gentoo-user@lists.gentoo.org MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-OriginalArrivalTime: 12 Sep 2015 07:49:57.0482 (UTC) FILETIME=[9EA84CA0:01D0ED2F] X-Archives-Salt: 737e2c5d-f26d-4d01-ba86-b64cfc68abe8 X-Archives-Hash: 0dcb0aeb6396e192c8f6a17a3b7f1cdd On Thursday, September 10, 2015 12:20:39 PM james wrote: > You are taking a very conservative view of things. Codes being worked > out now for clusters, will find their way to expand the use of the > video card resources, for general purpose things. Most of this will > occur as compiler enhancements, not rewriting by hand or modifying > algorithmic designs of existing codes. Granted they are going to > mostly apply to multi-threaded application codes. Your being over-optimistic. It seems to me all they're hoping for is to define a standardized and portable high-level interface for programming accelerators. The ones that will benefit the most is the same applications that can benefit from lower level technologies like CUDA. Scientific/number crunching applications, some kinds of clustering, etc. With no synchronization most existing multithreaded designs cannot benefit from it. And obviously code running on the accelerator cannot branch into the CPU, so no system or library calls. That leaves only purely number crunching loops. There's little of that on desktop and few of them can be fully optimized for parallelization. And to be worth the overhead of offloading the CPU needs to be maxed out. That leaves only the few applications I mentioned before. I'm looking at Intel MICs[1] and those look a lot more promising though still of limited use for desktops. It uses OpenMP so it has a lot less restrictions than OpenACC (a few ebuilds in the tree can already benefit from it with minor patches) and you can even offload whole proccesses. You can even ssh to the MIC since it runs Linux. It's not for the average desktop but they're not too expensive either. It may be worth it for high-end gentoo workstation (you can offload compile jobs with distcc) and I got a project on the backburner that can benefit from it. Do you know of any plans to enable offloading on the gentoo toolchain? I was able to build the offloading compiler using crossdev with a few hacks and wrote an ebuild for Intel's simulator[2]. I will work on enabling the host compiler tomorrow and may open a feature request and post patches once I get it working. The changes needed to enable it on the host are pretty trivial. [1] https://software.intel.com/en-us/articles/intel-xeon-phi-coprocessor-codename-knights-corner -- Fernando Rodriguez