[gentoo-user] Re: new computer : any advice ?

[james <wireless@tampabay.rr.com>]

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