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
The idea was to count multiply-add as one MAC if the op use multiply-add, otherwise only count multiply so we don't ignore some possibly expensive ops. The flop counter provides APIs to overwrite these decisions.
This may not be ideal for a number of reasons, but that's mainly because MAC is a poorly defined concept (flop as well, but better).
I had attempted to change everything to flops instead of MAC in #77, but unfortunately could not get it approved at the time.
The idea was to count multiply-add as one MAC if the op use multiply-add, otherwise only count multiply so we don't ignore some possibly expensive ops. The flop counter provides APIs to overwrite these decisions.
This may not be ideal for a number of reasons, but that's mainly because MAC is a poorly defined concept (flop as well, but better).
I had attempted to change everything to flops instead of MAC in #77, but unfortunately could not get it approved at the time.
flopcounter supports
aten::upsample_nearest2d
, but seems that this op does not involvingmultiply-add
operations.I am confused whether to strictly conform to the definition of
MACs
since "We count one fused multiply-add as one flop." is mentioned in docstring.Does a single
multiply
count one flop?The text was updated successfully, but these errors were encountered: