Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Very slow (exponential) parsing speed when having a large depth of addto_layer #2797

Closed
xyz2357 opened this issue Jul 10, 2017 · 3 comments
Closed
Assignees
Labels

Comments

@xyz2357
Copy link

xyz2357 commented Jul 10, 2017

When there's a lot of addto_layers in a network, it will takes exponential parsing time.
E.G. 1:

def whole_network(src_embedding):
    enc = src_embedding
    for i in range(depth):
        enc = addto_layer([enc, enc])

    pred = fc_layer(input=fc_layer(
                        input=enc,
                        size=dim_embedding,
                        act=ReluActivation()
                        ),
                    size=label_dict_len,
                    act=SoftmaxActivation())
    return pred

E.G. 2:

def whole_network(src_embedding):
    enc = src_embedding
    for i in range(depth):
        enc_res = fc_layer(input=enc, size=dim_embedding)
        enc_res = fc_layer(input=enc_res, size=dim_embedding)
        enc = addto_layer([enc, enc_res])

    pred = fc_layer(input=fc_layer(
                        input=enc,
                        size=dim_embedding,
                        act=ReluActivation()
                        ),
                    size=label_dict_len,
                    act=SoftmaxActivation())
    return pred

Both will costs a huge amount of time to parse (test by the nest_diagram tool).
My parsing time:

depth: 4,   parsing time: 0.16.
depth: 8,   parsing time: 0.16.
depth: 12, parsing time: 0.33.
depth: 16, parsing time: 2.02.
depth: 20, parsing time: 32.08.
depth: 21, parsing time: 67.05.
depth: 22, parsing time: 131.48.
depth: 23, parsing time: 268.82.
@wangkuiyi
Copy link
Collaborator

Just mark that " parsing time means the time used for parsing and generating the protobuf".

@reyoung reyoung added the Bug label Jul 11, 2017
reyoung added a commit to reyoung/Paddle that referenced this issue Jul 11, 2017
* Fix  PaddlePaddle#2797
* It because trainer_config_helpers' __dfs_travel__ did not record the
  node which travelled, and if the topology has a recursive dependency,
  there are some nodes will be travelled multiple times.
* Add a `travelled` set to record which node is travelled.
* Also add a unittest for this situation.
@reyoung
Copy link
Collaborator

reyoung commented Jul 11, 2017

This issue is fixed by #2802. It because when we parsing network topology by outputs(xxx), it just runs a depth-first search without any optimization.

In #2802, if a node is visited before, that node is just skipped. It will fix this issue.

You can just change network.py in paddle python package by this patch.

@xyz2357
Copy link
Author

xyz2357 commented Jul 11, 2017

Thanks a lot!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

3 participants