For chips with branch prediction circuitry, the cost of a conditional that
resolves the same way every time is nothing (or real close) each time you
hit the branch - the chip looks at the branch prediction cache and
speculatively executes along the most likely path. I think if you do the
same thing something like 95% of the time, you are pretty much okay. I
still tend to at least try to minimize conditionals in loops, but if you are
using a conditional on a fixed input param, it really should have very low
cost. I don't know the depth of the branch prediction caching mechanism -
ie., if you hit enough different conditionals, somebody has got to end up
uncached. The intel ia32-vintage chips have been doing this for a number of
years; I have not read the manual(s), but I think most other chips seem to
do it as well these days. I don't know what the story with the itanium and
branch predicition is, but with VLIW chips, a misprediction has to be pretty
expensive (really long pipeline). I am not a fan of itanium and my
impression is that it is sliding into oblivion anyway.
Regards - Bob
----- Original Message -----
From: "Jason Swails" <jason.swails.gmail.com>
To: "AMBER Mailing List" <amber.ambermd.org>
Sent: Wednesday, May 12, 2010 12:21 AM
Subject: Re: [AMBER] NTT=3 or NTT=1
> On Wed, May 12, 2010 at 12:09 AM, Ross Walker <ross.rosswalker.co.uk>
> wrote:
>
>> Hi Jason,
>>
>> > Does this exist, and/or is it of any use in pmemd? It would seem as
>> > though
>> > pmemd would be worth speeding up in this regard more (since it's the
>> > 'performance' end of amber). However, since the load balancer is far
>> > more
>> > sophisticated in pmemd, I see the possibility that it may not help
>> > nearly as
>> > much.
>> >
>> > A quick grep shows that there's an ifdef NO_NTT3_SYNC and an ifndef
>> > NO_NTT3_SYNC in the pmemd source directory. What's the verdict on
>> > this?
>>
>> Yes, it exists in both sander and pmemd in AMBER 11. I added it to the
>> CVS
>> tree about a year ago. It works great for both sander and pmemd improving
>> scaling significantly for ntt=3 simulations in both codes. Essentially it
>> brings ntt=3 scaling for pmemd inline with the ntt=1 numbers. I recommend
>> using it if you want to run large core count long ntt=3 runs. Just
>> 'caveat
>> emptor'!!!
>>
>> Probably this should be a cntrl namelist option and properly documented.
>>
>
> Documented, most likely (especially for pmemd if the explanation I gave
> seconds before I got your email was accurate). Namelist option....
>
>
>> Although this then means an if statement inside the inner loop which
>> would
>> be bad, or two loops with the if statement factored out.
>>
>
> For this reason, pre-processor option sounds best. I don't think the
> repeated if statements are particularly desirable for pmemd. (I'm also a
> big fan of not duplicating code where it can be avoided, so do-looping
> twice
> to factor out an if statement would not appeal to me. It would still need
> an if statement, though, yes? It would just be hit once each timestep
> rather
> than once each non-owned atom per time step). I don't know the exact
> computational cost of a conditional evaluation, but it's certainly more
> expensive than no conditional evaluation :).
>
> That said, I'm going to recompile with NO_NTT3_SYNC right away. Do we
> have
> comparisons/timings/scaling data for this? If so, where is it? If not,
> is
> it worth doing?
>
> Thanks!
> Jason
>
>
>> All the best
>> Ross
>>
>>
>> /\
>> \/
>> |\oss Walker
>>
>> | Assistant Research Professor |
>> | San Diego Supercomputer Center |
>> | Tel: +1 858 822 0854 | EMail:- ross.rosswalker.co.uk |
>> | http://www.rosswalker.co.uk | http://www.wmd-lab.org/ |
>>
>> Note: Electronic Mail is not secure, has no guarantee of delivery, may
>> not
>> be read every day, and should not be used for urgent or sensitive issues.
>>
>>
>>
>>
>>
>>
>> _______________________________________________
>> AMBER mailing list
>> AMBER.ambermd.org
>> http://lists.ambermd.org/mailman/listinfo/amber
>>
>
>
>
> --
> Jason M. Swails
> Quantum Theory Project,
> University of Florida
> Ph.D. Graduate Student
> 352-392-4032
> _______________________________________________
> AMBER mailing list
> AMBER.ambermd.org
> http://lists.ambermd.org/mailman/listinfo/amber
>
>
_______________________________________________
AMBER-Developers mailing list
AMBER-Developers.ambermd.org
http://lists.ambermd.org/mailman/listinfo/amber-developers
Received on Wed May 12 2010 - 08:30:06 PDT
