Benchmarking performance of the protocol is one of the essential steps of development cycle. Until now, we don't have any "generic" tool for profiling performance of MPC protocols. Instead, MPC implementations have their own profiling utilities, e.g. cggmp24::progress::Tracer.
Latest v0.5.0-alpha.1 release restructures round_based::Mpc trait. One could implement a PerfProfiler that wraps and implements round_based::Mpc. By intercepting calls to MpcExecution::{send, complete}, PerfProfiler could measure exactly how long takes each round (pure computations) and how much time we spend on sending/receiving messages (i.e. on I/O).
At the end of the protocol execution, profiler would provide stats. Similarly to cggmp24::progress::PerfReport, stats should implement Display, so we can print them to the terminal. It would be beneficial to have some sort of statistical analysis: provided reports from several executions, find the means per each round, deviation, p50/p75/p90.
Benchmarking performance of the protocol is one of the essential steps of development cycle. Until now, we don't have any "generic" tool for profiling performance of MPC protocols. Instead, MPC implementations have their own profiling utilities, e.g.
cggmp24::progress::Tracer.Latest
v0.5.0-alpha.1release restructuresround_based::Mpctrait. One could implement aPerfProfilerthat wraps and implementsround_based::Mpc. By intercepting calls toMpcExecution::{send, complete},PerfProfilercould measure exactly how long takes each round (pure computations) and how much time we spend on sending/receiving messages (i.e. on I/O).At the end of the protocol execution, profiler would provide stats. Similarly to
cggmp24::progress::PerfReport, stats should implementDisplay, so we can print them to the terminal. It would be beneficial to have some sort of statistical analysis: provided reports from several executions, find the means per each round, deviation,p50/p75/p90.