Partly to help out the KNL processor, which gets easily
perplexed when having to deal with branchy code, refine
the GNIX macros to have less impact on the critical path
for messages (send/recv).
Add a new GNIX_DBG_TRACE macro to be used for tracing
functions in the critical path. This macro is only activated
when the --enable-debug configury option is enabled.
Remove use of GNIX_INFO from the data flow path for
send/recv. Subsequent PRs will remove its usage from
the data flow path for RMA and ATOMIC operations.
With these changes we now have for 8-byte streaming send/recv
message pattern:
before:
219997.79 messages/sec
after:
232988.82
This is with default compiler optimizations (gcc 6.3.0)
Signed-off-by: Howard Pritchard hppritcha@gmail.com
(cherry picked from commit a4b39515b9f1ba734777cb67ca1ec9ad7abea7d5)
Partly to help out the KNL processor, which gets easily perplexed when having to deal with branchy code, refine the GNIX macros to have less impact on the critical path for messages (send/recv).
Add a new GNIX_DBG_TRACE macro to be used for tracing functions in the critical path. This macro is only activated when the --enable-debug configury option is enabled.
Remove use of GNIX_INFO from the data flow path for send/recv. Subsequent PRs will remove its usage from the data flow path for RMA and ATOMIC operations.
With these changes we now have for 8-byte streaming send/recv message pattern:
before: 219997.79 messages/sec after: 232988.82
This is with default compiler optimizations (gcc 6.3.0)
Signed-off-by: Howard Pritchard hppritcha@gmail.com (cherry picked from commit a4b39515b9f1ba734777cb67ca1ec9ad7abea7d5)
Conflicts: prov/gni/src/gnix_msg.c