Jeff,
I addressed your comments and it is in the trunk for 2 weeks already. I
thought that you are in rush with hosting migration, so I didn't show up.
Current solution is not complete. I plan to return to it to implement
continuous synchronisation as I will have the timeframe. However it should
be
Got that. Thank you!
четверг, 18 сентября 2014 г. пользователь Ralph Castain написал:
> I believe compile-time is preferable as there is a non-zero time impact of
> enabling this code. It's really more for developers to improve scalability
> - if a user is actually interested, I think it isn't th
I believe compile-time is preferable as there is a non-zero time impact of
enabling this code. It's really more for developers to improve scalability - if
a user is actually interested, I think it isn't that hard for them to configure
it.
On Sep 18, 2014, at 7:16 AM, Artem Polyakov wrote:
>
Jeff, thank you for the feedback! All of mentioned issues are clear and I
will fix them shortly.
One important thing that needs additional discussion is compile-time vs
runtime selection. Ralph, what do you think about that? Several of issues
depends on that decision.
2014-09-18 20:09 GMT+07:00 J
I have a few comments:
- This looks nice. Thanks for the contribution.
- I notice that the ORTE timing stuff is now a compile-time decision, not a
run-time decision. Do we care that we've now taken away the ability for users
to do timings in a production build?
- "clksync" -- can we use "clo
Hello,
I would like to introduce OMPI timing framework that was included into the
trunk yesterday (r32738). The code is new so if you'll hit some bugs - just
let me know.
The framework consists of the set of macro's and routines for internal OMPI
usage + standalone tool mpisync and few additional
