On Apr 28, 2013, at 6:10 AM, David A Case wrote:
> On Sat, Apr 27, 2013, M. L. Dodson wrote:
>>
>>
>> I don't know how widespread openmp support is among operating systems likely
>> to be used for AmberTools installs, but if it is near universal, my opinion
>> is that -openmp installs should be the default, not serial installs. This is
>> because almost all modern CPUs are multicore, hence fit well with openmp.
>
> Our main concern in making this the default is/was that users might be using
> multiple cores when they weren't expecting to, potentially violating local
> queue requirements, etc. But I'm cc-ing this to amber-developers, to get
> other opinions. You are correct that certain types of workstation jobs would
> indeed be faster if users routinely made us of the openmp capabilties.
>
> ...thanks…dac
>
Seems an easy implementation would be to read the environment variable that sets
the number of cores. If the user has not set the variable, a simple if-then can
set the number of cores=1; if the variable is set, then the user knows about and
wants to use openmp and, therefore, control the number of cores. I would actually
be surprised if this is not the way the openmp support libraries handle things
anyway.
You are right, though, if openmp AND MPI were both active, things might need
special case treatment. I seem to remember this being a problem several years
ago (MKL using openmp?). I can't see how openmp, on its own, would impact queue
handling. It just implements multiple threads on the same CPU within the same
process. Or have I somehow missed the point?
A real potential problem might be another library, say a math library, using
openmp behind our back, running afoul of a default openmp situation in, say,
nab. That might not be a peaceful coexistence. Corner case pile up might well
tip the scales against default openmp.
Bud Dodson
--
M. L. Dodson
Business email: activesitedynamics-at-gmail-dot-com
Personal email: mldodson-at-comcast-dot-net
Gmail: mlesterdodson-at-gmail-dot-com
Phone: eight_three_two-five_63-386_one
_______________________________________________
AMBER mailing list
AMBER.ambermd.org
http://lists.ambermd.org/mailman/listinfo/amber
Received on Sun Apr 28 2013 - 06:00:05 PDT
