You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Especially when prototyping a new protocol, having a accurate field operation counts is very important.
My proposal would be to add this behind a feature flag, adding a globally accessible stats counter that is then updated.
Ideally, by turning on the instrumentation flag, the user would be able to transparently instrument their code with no changes required.
The text was updated successfully, but these errors were encountered:
For my particular use-case, curve operations and FFTs are not too relevant. I really would just want to be able to count the number of field additions, multiplications and divisions.
I assume that, once that is done the common infrastructure could be extended to other functionalities.
Possibly we could decorate methods which should (optionally) be instrumented with some derive_macro which writes to a common (global, thread safe, possibly slow) counter. Then, on the counter itself we can implement some aggregation for better user functionality.
Above, we targeted the expensive operations above, without changing the fields, but..
It's likely easier to just count field operations, either cargo patch in your fork of ark-ff, or else simply fork the curve with one commit that sustitutes your ark-ff.
Especially when prototyping a new protocol, having a accurate field operation counts is very important.
My proposal would be to add this behind a feature flag, adding a globally accessible stats counter that is then updated.
Ideally, by turning on the instrumentation flag, the user would be able to transparently instrument their code with no changes required.
The text was updated successfully, but these errors were encountered: