Get rid of pickle for fluid inference

[kexinzhao]

fixes #7221

Put fetch_var_names and feed_var_names as repeated string fields in the ProgramDesc

To test this PR：

1. build paddle based on this pr
2. Use pip install -U /home/liuyiqun01/PaddlePaddle/Paddle/build_paddle/dist/opt/paddle/share/wheels/paddlepaddle_gpu-0.11.0-cp27-cp27mu-linux_x86_64.whl to install the latest Paddle and run python test_recognize_digits_mlp.py to train the model, then you will get the inference model in sub-directory recognize_digits_mlp.inference.model

After these steps, you can run the example using:

$ GLOG_v=3 ./paddle/inference/example --dirname=/home/liuyiqun01/PaddlePaddle/Paddle/python/paddle/v2/fluid/tests/book/recognize_digits_mlp.inference.model 

The output is similar to #7097

[wangkuiyi]

Why do we need to add feed_var_names and fetch_var_names here? The current ProgramDesc, which supports training, should be able to read training data — maybe from some data feeding operators I vaguely remember? If so, it seems that we can reuse these feeding operators, or invent some new operators for data feeding specifically at inference time?

[wangkuiyi]

BTW, given the fact that we are moving to use a WhileOp to represent the iteration loop at training time, I don’t expect a ProgramDesc that describes a training program can be shared and reused without any modification at inference time. As we’d need a new ProgramDesc specifically for inference, we can have inference data feeding operators in this new ProgramDesc.

[kavyasrinet]

@wangkuiyi This is the approach we have been discussing too here: #7328 . Defining a ProgramDesc for Inference separately that has all Inference specific requirements addressed separately, and that can reuse our already existing ProgramDesc.

[kexinzhao]

Thanks @wangkuiyi for the clarification on ProgramDesc. We are exploring different paths of obtaining a Desc for inference and discussing which one to use. Based on your comment, I think we will follow things the proposal in #7328. @abhinavarora is working on a PR based on that.

[Xreki]

There is no feed_op or fetch_op in current train and inference ProgramDesc. Each time we run a train ProgramDesc, the Executor will clone a copy of the train ProgramDesc and insert feed_ops and fetch_ops to the copy of the train ProgramDesc.
@wangkuiyi do you mean to insert feed_op and fetch_op to inference ProgramDesc when saving? It is a way to solve this problem.
There is a proposal of mine, with no need to modify the current ProgramDesc or define another ProgramDesc, but I am not sure if it works. @kexinzhao @abhinavarora @kavyasrinet

• We can traverse all the non-persistable variables in the inference ProgramDesc. If the variable is not an output of any operators, we think it is a feed variable. If the variable is not an input of any operators, we think it is a fetch variable.

Update:
I find a disadvantage of my proposal. User may specify the output of some middle operator (some operator in the middle position of the network and has output) to the fetch list.