Skip to content

Conversation

@hbwx24
Copy link
Contributor

@hbwx24 hbwx24 commented Jan 6, 2021

PR types

Bug fixes

PR changes

APIs

Describe

paddle.save/load ,paddle.static.save/load 保存大文件的bug
原始PR:#29988
#30151

hbwx24 added 2 commits January 6, 2021 12:57
* Support storage of large parameters

* Reduce the complexity of the unittest

* Reduce the complexity of the unittest,commented out unittest for

* add unittest for static.save/load

* Increase the timeout threshold of 'test_static_save_load'

* Increase the timeout threshold of 'test_static_save_load'

* Increase the timeout threshold of 'test_static_save_load' and 'test_paddle_save_load'

* Increase the timeout threshold of 'test_static_save_load' and 'test_paddle_save_load'
@paddle-bot-old
Copy link

paddle-bot-old bot commented Jan 6, 2021

Thanks for your contribution!
Please wait for the result of CI firstly. See Paddle CI Manual for details.

@hbwx24 hbwx24 closed this Jan 7, 2021
@hbwx24 hbwx24 reopened this Jan 7, 2021
Copy link
Contributor

@chenwhql chenwhql left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM

@ZHUI
Copy link
Collaborator

ZHUI commented Jan 7, 2021

我这边测试:

模型的static_dict使用 paddle.save 下来,大概有3.3G左右,实际的参数量,计算出来大概2.2G左右。使用 numpy 存成 npz,可以做到,2.2G。而且 paddle.load 加载save下的参数,也比numpy慢很多

猜测是 pickle序列化dump的缘故。 能否优化?

@chenwhql
Copy link
Contributor

chenwhql commented Jan 7, 2021

我这边测试:

模型的static_dict使用 paddle.save 下来,大概有3.3G左右,实际的参数量,计算出来大概2.2G左右。使用 numpy 存成 npz,可以做到,2.2G。而且 paddle.load 加载save下的参数,也比numpy慢很多

猜测是 pickle序列化dump的缘故。 能否优化?

现阶段不具备这个条件:

  1. 首先dump有存储限制这个问题是最近才暴露出来的,这个是通过拆分大参数存为多个小参数,去解决这个盲点问题,拆分本身也是有开销,慢可能和这个也相关
  2. npz是numpy.savez用来存numpy array的接口,如何适配我们要存dict的需求的?简单来看npz并不适用于我们的场景
  3. 现阶段不能做不兼容的修改,重点是要确保2.0在save上不能有功能上的死角,超大参数不是高频场景,预计影响可控
  4. 这说明我们一开始动态图save采用dump去存储这个设计就是欠考虑的,且不追根渊源,目前看来这导致我们后面势必要对save的格式进行不兼容的升级了,但我理解2.0已经来不及了

@lanxianghit lanxianghit merged commit bfb6f61 into PaddlePaddle:release/2.0 Jan 7, 2021
@ZHUI
Copy link
Collaborator

ZHUI commented Jan 7, 2021

我这边测试:

模型的static_dict使用 paddle.save 下来,大概有3.3G左右,实际的参数量,计算出来大概2.2G左右。使用 numpy 存成 npz,可以做到,2.2G。而且 paddle.load 加载save下的参数,也比numpy慢很多

猜测是 pickle序列化dump的缘故。 能否优化?

现阶段不具备这个条件:

  1. 首先dump有存储限制这个问题是最近才暴露出来的,这个是通过拆分大参数存为多个小参数,去解决这个盲点问题,拆分本身也是有开销,慢可能和这个也相关
  2. npz是numpy.savez用来存numpy array的接口,如何适配我们要存dict的需求的?简单来看npz并不适用于我们的场景
  3. 现阶段不能做不兼容的修改,重点是要确保2.0在save上不能有功能上的死角,超大参数不是高频场景,预计影响可控
  4. 这说明我们一开始动态图save采用dump去存储这个设计就是欠考虑的,且不追根渊源,目前看来这导致我们后面势必要对save的格式进行不兼容的升级了,但我理解2.0已经来不及了

好的,谢谢,清楚了。
我们目前存的参数是转成numpy的,设计升级save的格式,可参考numpy的save、savez。

@chenwhql
Copy link
Contributor

chenwhql commented Jan 7, 2021

我这边测试:

模型的static_dict使用 paddle.save 下来,大概有3.3G左右,实际的参数量,计算出来大概2.2G左右。使用 numpy 存成 npz,可以做到,2.2G。而且 paddle.load 加载save下的参数,也比numpy慢很多

猜测是 pickle序列化dump的缘故。 能否优化?

现阶段不具备这个条件:

  1. 首先dump有存储限制这个问题是最近才暴露出来的,这个是通过拆分大参数存为多个小参数,去解决这个盲点问题,拆分本身也是有开销,慢可能和这个也相关
  2. npz是numpy.savez用来存numpy array的接口,如何适配我们要存dict的需求的?简单来看npz并不适用于我们的场景
  3. 现阶段不能做不兼容的修改,重点是要确保2.0在save上不能有功能上的死角,超大参数不是高频场景,预计影响可控
  4. 这说明我们一开始动态图save采用dump去存储这个设计就是欠考虑的,且不追根渊源,目前看来这导致我们后面势必要对save的格式进行不兼容的升级了,但我理解2.0已经来不及了

好的,谢谢,清楚了。
我们目前存的参数是转成numpy的,设计升级save的格式,可参考numpy的save、savez。

好的,感谢建议

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

5 participants