lmbxmu / HRank

Pytorch implementation of our paper accepted by CVPR 2020 (Oral) -- HRank: Filter Pruning using High-Rank Feature Map
https://128.84.21.199/abs/2002.10179
250 stars 49 forks source link

关于compute_rate、秩的计算顺序的问题 #15

Open Menace-Dragon opened 3 years ago

Menace-Dragon commented 3 years ago

您好!我有两个问题:

  1. compress_rate是指每层的保留率吗,还是指的是每层要删掉的比例呢?
  2. 是在开始剪枝前仅计算一次各卷积层的平均秩,还是每层剪枝完后计算下一个卷积层的平均秩呢(比如第1层剪完了,然后我才计算第2层的平均秩;然后再剪第2层,再计算第3层的平均秩......)?
Menace-Dragon commented 3 years ago

不好意思标题打错了,是compress_rate

lmbxmu commented 3 years ago

您好!我有两个问题:

  1. compress_rate是指每层的保留率吗,还是指的是每层要删掉的比例呢?
  2. 是在开始剪枝前仅计算一次各卷积层的平均秩,还是每层剪枝完后计算下一个卷积层的平均秩呢(比如第1层剪完了,然后我才计算第2层的平均秩;然后再剪第2层,再计算第3层的平均秩......)?
  1. 删掉比例
  2. 剪枝前仅计算一次各卷积层的平均秩
Menace-Dragon commented 3 years ago

感谢!再次叨扰您,我又有了新的问题:

  1. vgg16的压缩率和flops以及参数量和readme种给的不对应?(vgg16的compress_rate [0.95]+[0.5]6+[0.9]4+[0.8]*2,readme给的是Flops=105.61M和Params=2.64M,但是好像不对应,和我算出来的不对应)

  2. 是每剪一层就微调一次,还是将所有层剪完之后只微调一次?如果是前者,那么在剪枝前仅计算一次各卷积层的平均秩会不会有偏差呢?

lmbxmu commented 3 years ago
  1. 没有吧。计算代码我们都提供的好好的,自己详细阅读我们的说明
  2. 一层一微调。 都剪完再调参考 https://github.com/lmbxmu/HRankPlus
NCHU-zhoucheng commented 3 years ago

老师,您好!我想请问下,HRank在对不同的网络模型进行剪枝时,每层的剪枝比例是如何确定的?是数学方法的计算结果,还是通过参数调整试错得出的?

liuhao-97 commented 3 years ago

感谢!再次叨扰您,我又有了新的问题:

  1. vgg16的压缩率和flops以及参数量和readme种给的不对应?(vgg16的compress_rate [0.95]+[0.5]6+[0.9]4+[0.8]*2,readme给的是Flops=105.61M和Params=2.64M,但是好像不对应,和我算出来的不对应)
  2. 是每剪一层就微调一次,还是将所有层剪完之后只微调一次?如果是前者,那么在剪枝前仅计算一次各卷积层的平均秩会不会有偏差呢?

针对你的第一个问题,我算的也不是2.64M,是2.92M,还记得吗你算得是多少

Menace-Dragon commented 3 years ago

感谢!再次叨扰您,我又有了新的问题:

  1. vgg16的压缩率和flops以及参数量和readme种给的不对应?(vgg16的compress_rate [0.95]+[0.5]6+[0.9]4+[0.8]*2,readme给的是Flops=105.61M和Params=2.64M,但是好像不对应,和我算出来的不对应)
  2. 是每剪一层就微调一次,还是将所有层剪完之后只微调一次?如果是前者,那么在剪枝前仅计算一次各卷积层的平均秩会不会有偏差呢?

针对你的第一个问题,我算的也不是2.64M,是2.92M,还记得吗你算得是多少

啊,params我手算的是0.702755 M;然后我用pytorch扩展的“thop”库的profile函数算的是0.70M(精度不同)

PeiqinSun commented 2 years ago
  1. 这个repo里面的确vgg16_bn算的和readme不一致. 原因是代码: https://github.com/lmbxmu/HRankPlus/blob/master/cal_flops_params.py#L36 我理解是少了最后一层的剪枝和fc计算量增加导致计算不一致.