Understanding GFLOPS vs number of parameters

username: mfoglio
cooked: <p>I am working on real-time scenario where inference time is extremely important. I am running the model on a Nvidia GPU and the models will be converted to TensorRT.</p>
<p>I am comparing:</p>
<p>Squeezenet 1.1</p>
<ul>
<li>num_params 1235496</li>
<li>GFLOPS 0.35</li>
<li>File size 4.7 MB</li>
<li><a href="https://pytorch.org/vision/master/models/generated/torchvision.models.squeezenet1_1.html#torchvision.models.squeezenet1_1" class="inline-onebox" rel="noopener nofollow ugc">squeezenet1_1 — Torchvision main documentation</a></li>
</ul>
<p>Mobilenet v3 small</p>
<ul>
<li>num_params 2542856</li>
<li>GFLOPS 0.06</li>
<li>File size 9.8 MB</li>
<li><a href="https://pytorch.org/vision/master/models/generated/torchvision.models.mobilenet_v3_small.html#torchvision.models.mobilenet_v3_small" class="inline-onebox" rel="noopener nofollow ugc">mobilenet_v3_small — Torchvision main documentation</a></li>
</ul>
<p>It seems that squeezenet size is approximately 48% of mobilenet. However, I am sure how to interpret the GFLOPS. I know that GFLOPS represent the number of floating point operations per second.<br>
Since squeezenet has a greater GFLOPS, would this mean that it’s architecture can be executed faster? In other words, if the models were to have the same number of parameters, would the one with greater GFLOPS be the faster?</p>

username: JuanFMontesinos
cooked: <p>Hi,<br>
Indeed. The number of parameters is something aligned to the expressiveness of the model. Comparing two networks with the same underlaying technology, the more parameters, the larger distributions it can learn. While there is a correlation between number of parameters and GFLOPs it’s not strictly related.</p>
<p>A typical example are dense residual conections:<br>
<div class="lightbox-wrapper"><a class="lightbox" href="https://discuss.pytorch.org/uploads/default/original/3X/1/b/1b34148e012c994cfe613fe5a68403f941ccbd8d.jpeg" data-download-href="https://discuss.pytorch.org/uploads/default/1b34148e012c994cfe613fe5a68403f941ccbd8d" title="image"><img src="https://discuss.pytorch.org/uploads/default/optimized/3X/1/b/1b34148e012c994cfe613fe5a68403f941ccbd8d_2_658x500.jpeg" alt="image" data-base62-sha1="3SEtl1Qo7sKOXhyEBtd27Q697xr" width="658" height="500" srcset="https://discuss.pytorch.org/uploads/default/optimized/3X/1/b/1b34148e012c994cfe613fe5a68403f941ccbd8d_2_658x500.jpeg, https://discuss.pytorch.org/uploads/default/optimized/3X/1/b/1b34148e012c994cfe613fe5a68403f941ccbd8d_2_987x750.jpeg 1.5x, https://discuss.pytorch.org/uploads/default/optimized/3X/1/b/1b34148e012c994cfe613fe5a68403f941ccbd8d_2_1316x1000.jpeg 2x" data-dominant-color="E1E0DF"><div class="meta"><svg class="fa d-icon d-icon-far-image svg-icon" aria-hidden="true"><use href="#far-image"></use></svg><span class="filename">image</span><span class="informations">1706×1295 238 KB</span><svg class="fa d-icon d-icon-discourse-expand svg-icon" aria-hidden="true"><use href="#discourse-expand"></use></svg></div></a></div><br>
Here, densenet and resnet have the same number of parameters but densenet requires more computations.</p>
<p>Or imagine you run the same ResNet twice, but in one case you add pooling (which would reduce the size thus the GFLOPs).</p>
<p>In summary, there is a correlation between size and computational cost, but a fine design can effectively reduce the computations.</p>

username: mfoglio
cooked: <p>Thank you for your reply, <a class="mention" href="/u/juanfmontesinos">@JuanFMontesinos</a> .<br>
Your example helped me a lot.<br>
I still have a doubt. When speaking about GFLOPS on PyTorch website, what are the exactly measuring? Are these the number of floating point operations to do inference on a single image?<br>
Or do they count the number of floating point operations per second when running the model on a specific hardware?<br>
Are GFLOPS and GFLOPs the same thing?<br>
Thank you</p>

username: JuanFMontesinos
cooked: <p>Hi,<br>
I don’t look at pytorch’s examples so I cannot respond to that.</p>
<p>FLOPs are Floating-point operations but that’s a bit ambiguous as described</p>
<pre><code class="lang-auto">When dealing about computing effort and computing speed (hardware performance), terminology
is usually confusing. For instance, the term ‘compute’ is used ambiguously, sometimes applied to
the number of operations or the number of operations per second. However, it is important to clarify
what kind of operations and the acronyms for them. In this regard, we will use the acronym FLOPS
to measure hardware performance, by referring to the number of floating point operations per second, as standardised in the industry, while FLOPs will be applied to the amount of computation for
a given task (e.g., a prediction or inference pass), by referring to the number of operations, counting
a multiply-add operation pair as two operations. An extended discussion about this can be found in
the appendix.
</code></pre>
<aside class="onebox pdf" data-onebox-src="https://arxiv.org/pdf/2109.05472.pdf">
  <header class="source">

      <a href="https://arxiv.org/pdf/2109.05472.pdf" target="_blank" rel="noopener nofollow ugc">arxiv.org</a>
  </header>

  <article class="onebox-body">
    <a href="https://arxiv.org/pdf/2109.05472.pdf" target="_blank" rel="noopener nofollow ugc"><span class="pdf-onebox-logo"></span></a>

<h3><a href="https://arxiv.org/pdf/2109.05472.pdf" target="_blank" rel="noopener nofollow ugc">2109.05472.pdf</a></h3>

  <p class="filesize">794.51 KB</p>

  </article>

  <div class="onebox-metadata">
    
    
  </div>

  <div style="clear: both"></div>
</aside>

<p>In deep learning these floating point ops are usually just multiply-add ops. As you can read, it requires certain clarification but the general idea is to provide hardware-agnostic ways of showing computational cost.</p>
<p>For example,  some papers show inference time, but this number obviously depends on the hardware and the batch size (so that the gpu is working at its maximum/optimal workload). Similarly, you can say how many imgs (in computer visioon) per unit of time you can process. Yet again, this depends on image size, batch size, hardware…</p>
<p>So in the end the most agnostic way (although the hardest) of showing this info is with the required amount of operations. If I my algorithm can sum 2 numbers in 5 steps and yours in 7, mine is better.</p>
<p>In your case, the simplest case would be doing your own tests. Also note that compiled models can benefit from improvements (there is torch.compile now). For example transformers now have flask attention in pytorch and so on…</p>
<p>My advice is:<br>
Just take the metric that fits better your problem (inference time, imgs/second) and read a bit how to make a fair comparison.</p>