Closed jixiege closed 1 year ago
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 https://github.com/facebookresearch/fvcore/pull/77, but unfortunately could not get it approved at the time.
The idea was to count
multiply-add
as one MAC if the op usemultiply-add
, otherwise only countmultiply
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.
Got it, thanks for your reply.
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?