Jeremi Piotrowski <jeremi.piotrowski <at> gmail.com> writes: > No, and yes. Compilation is not affected in any way and runtime > performance can only be improved _if_ this stuff is explicitly used within > the code.
Yes this is all new and a work in progress. I do not think it will be gcc-6 that makes the difference in a few years. But folks should be aware and look for codes that are accelerated via usage of GPU resources. Remember this all started about hardware purchase and future benefits. It's definitely not commodity usage atm. > Meaning you would feel a difference in no less then 5 years when gcc-6 is > widely used and accelerator support is not restricted to intel MIC and > nvidia gpus. James is getting a bit ahead of himself calling this a > "game changer" - yeaaaaah... not really right now. It's not as restricted as you indicate amd, intel, nividia and others like arm (Mali and such) are working to support there hardware under the openacc code extension now in gcc-5. Granted the more powerful your GPU resources are the more they can contribute. This stuff use to only work with vendor supplied compilers and sdks, now it's finally available in gcc, albeit in it's infancy. Naturally it's going to take a while to become mainstream useful; but that more like a year or 2, at most. > Right now this functionality is a toy for the HPC community and will stay > that way. To use it you have to build a separate offloading compiler, need > custom code used by few, and expensive hardware. The tree ebuild doesn't > even provide a way for enabling the accelerator support. I never said it was for the entire portage tree to benefit at this time, but ultimately that is the goal. And yes this is the focus of the cluster folks, including HPC, but it will soon be available to everybody, via clusters and distributed file systems (like Cephfs). My work is on tuning btrfs with cephfs to span the entire network of computers I run[1]. Yes, cephfs' the hammer branch does' use RDMA or RoCE, Rdma over Conformed Ethernet, so infiband interfaces are not needed. Rdma as a concept will eventually provide a mechanism for the DDR memory resources of a video card to be use as system resources, imho. Many are working on this and keeping their details private, for now. > > ... does it use this new stuff anyway, do we need a specific USE-flag > > enabled (I can't spot it, looking for something like "acc" or "rdma" > > ), do we need specific CFLAGS .. ? You have to dig a bit as most projects using this stuff are alpha or testing stages. Here's one, ceph (hammer branche 0.94.x) [2] > I can't speak for RDMA (can't find any mention of it in gcc) because > that's an even more exotic thing than plain old accelerator support > (unless you run infiniband at home...), but the flags are: Rdma is often found in Rdma over Conformed Ethernet as the moniker for language searches. RDMA is a concept, like DMA. RDMA will allow that DDR5 memory on your graphics card to become part of the compiler/computational general pool of resources of your system. Vendors might only do this on new platforms (like arm based servers). It's not guaranteed that a method will be published for legacy hardware. That sort of efforts is up to the FOSS/kernel folks. > -fopenmp > -foffload > -fopenacc > However enabling them is as useful as having CFLAGS=-fopenmp currently. It > changes __nothing__ unless an application has openmp annotations, and the > ones that do should already provide a means of doing so in the build > system. Yes, this is all evolving as we speak, I never stated it was part of stable applications. The advice was for one to consider when purchasing new hardware, so a year or 2 from now they dont say they were not informed of these fundamental changes to gcc and it's implications. In the past special compilers, expensive hardware and lots of vendor trickery kept these sorts of technologies from the masses of FOSS devs and users. Now this has changed but it is going to be some effort and take a while for the greater FOSS communities to learn how to leverages these new resources, which are a 'game changer'. Yes, right now these are the toys of the cluster folks, but soon they'll be commonly used. Plan on replacing NFS with Ceph. Plan on using distcc on a cluster [3]. > tldr: don't buy a dedicated gpu just because you read something on a > mailing list ;) Exactly correct. But if you are going to spend on new resources, be aware that the gpu and ddr memory are now 'targets' for some very aggressive development and all available via gcc-5. Apologies if what I wrote seemed to be 'overly optimistic'. hth, James [1] http://www.networkcomputing.com/storage/fibre-channel-really-is-dead/a/d-id/1320090 [2] https://community.mellanox.com/docs/DOC-2141 [3] https://github.com/mesos/mesos-distcc
