On Mon, Aug 5, 2013 at 6:09 PM, Sean Farley <s...@macports.org> wrote: > > ebori...@macports.org writes: >> I personally swap back and forth between variants of mpich >> when I'm testing my own MPI code (why, oh why, doesn't clang have >> OpenMP support yet?) > > Because there is almost no benefit for parallel applications? ;-) > Really, though, if you're in the domain where OpenMP can help > (computation bound, dense linear algebra) then your time is better spent > on using CUDA.
Hrmm, not on the Intel PHI we're using. :) (Obviously not MacPorts related, but I often develop on my mac, so it's nice to be able to compile & check the OpenMP code.) > To help get things moving along, I'd suggest we concentrate on the > +gfortran variant (and therefore having mpich / openmpi use 'PortGroup > multiplecompilers 1.0'). What would be holding back using the > multiplecompilers group with active_variants? I have no qualms moving to the portgroup; any concerns on the list with adding the portgroup [1] to trunk? Would you consider modifying it (perhaps it does and I missed it) to support something like "multiplecompilers.dragonegg = 0" to disable a family (or particular version) rather than making the variants explicitly and having them error out in the Portfile? Thanks, Eric [1] https://bitbucket.org/seanfarley/scienceports/src/2832e9d9716e178f20b5ab0eb563f40d7fcce730/_resources/port1.0/group/multiplecompilers-1.0.tcl?at=default _______________________________________________ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
