Use proto extensions with hashed field numbers for layer-specific parameters#2036
Open
jeffdonahue wants to merge 3 commits intoBVLC:masterfrom
Open
Use proto extensions with hashed field numbers for layer-specific parameters#2036jeffdonahue wants to merge 3 commits intoBVLC:masterfrom
jeffdonahue wants to merge 3 commits intoBVLC:masterfrom
Conversation
a value derived from SHA1 hash
(start from 20000 as 19000 to 19999 are reserved by the protobuf implementation -- see https://developers.google.com/protocol-buffers/docs/proto (search for 'kFirstReservedNumber') for details
reshape_param declared using a proto extension
This was referenced Mar 10, 2015
Closed
Contributor
Author
|
As hacky/scary of an idea as this might be, it's looking more attractive as it looks like we currently have at least 11 mutually unmergable PRs, which would probably all be safely mergable in any order if not for the fact that they all grab |
Contributor
|
I think it is needed cause id in proto are actually a natural way to have cross PR conflicts. Is there also a commit of ReshapeLayer? |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
3 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
This is the proof-of-concept mentioned by @shelhamer in #1896. DO NOT MERGE -- I'm not really sure if this is a good way to go, this PR is just for discussion for now.
This would facilitate self-contained independent development of layers by addressing one of the major current pain points with that -- conflicting proto field numbers. The idea is that instead of picking a field number consecutively after the previous one, which of course causes conflicts whenever other new layers are added, as long as your field name (e.g.,
convolution_param) doesn't conflict with anything else inLayerParameter, the field number is generated as a function of the name, and (with high probability) you get a unique number. (The collision odds for any given pair of extensions are 1 in 536,850,911; haven't done the birthday problem analysis to figure out what that actually means in practice, but if we were going to use this we might need to eventually add a "salt" field to escape collisions.)See
src/caffe/proto/reshape_param.proto.varextnumfor an example of what it looks like to declare a LayerParameter extension this way. The scriptscripts/fill_proto_ext_num.pycreates the actualreshape_param.protofile from the*.varextnumversion.Build notes: there is currently something finicky about my Makefile changes such that parallel builds with
make -jsometimes don't work -- a workaround is to first domake proto(no-j) before doingmake -j. I haven't attempted to add CMake support.