The layers of Caffe are processed by Instantiate_class and Register_layer_class to each layer class. Each layer inherits the base class layer, where Basedatalayer is the base class for the input data, and the main inheritance from this class is:
This diagram can be very good to see the inheritance of these layers, the structure of the entire layer is very clear, using an abstract factory to build the entire layer, and then just the macro to register the layer as an abstract service class, and then use the server provider to request the call to each class, This makes it possible to invoke the proto file as a different kind of configuration file, much like the Java Spring Framework, using the SOA approach.
When you understand this structure, it is believed that most people will be much clearer when analyzing the Caffe layer, except that most traditional C + + or Java uses this dynamic to create classes using the XML language to describe them. And Caffe this thing is described using Proto, a non-mainstream way of customizing. The layer and other structures are analyzed independently when the entire Caffe is analyzed. (Nonsense: It seems that learning more about design patterns is very useful.) This design is a bit and a disadvantage of the obvious, can make the compiler language at runtime a part of the flexibility, but still can not completely solve the flexibility problem, but for the algorithm this flexibility, but also similar to the strategy mode, the data can be changed in the choice of data in a variety of ways. And this transformation is just a transformation strategy, because many people on the Internet analysis Caffe layer, how each layer of the gradient down, so the advantages and disadvantages of such a decline too much, I do not swim here, do not say these are many people said things, I only say Caffe the entire project structure. And how we can make changes to meet our own needs.
In this way we can see how Caffe is structured, and IO uses OPENCV leveldb lmdb for data reading and storage. Solver This class is the combination of the final execution of all layers combining the solution process.
The core part of the entire Caffe code is in the layer, each layer corresponds to a function gradient descent, understanding these functions need mathematics and traditional machine learning Foundation, can not be short-term crash so here I also do not do nonsense. This stay for the rest of the time to share, to share a weekly analysis of a layer.
This is the macro template function that initializes the various classes for the entire schema.
#define INSTANTIATE_CLASS (classname) char ginstantiationguard# #classname; Template class classname<float>; Template class Classname<double>
The following is a typical SOA approach to registering each class, and the container that holds these classes, Of course this is a simple and rude way of writing. Plus a bunch of templates and macros to make the entire system looks very tall, in fact, as long as the C + + templates and macros familiar, these weapons will let you develop more easily.
Template <typename dtype>class layerregisterer {public:layerregisterer (const string& type, S hared_ptr<layer<dtype> > (*creator) (const layerparameter&)) {//LOG (INFO) << "Registering Layer Type: "<< type; Layerregistry<dtype>::addcreator (type, creator); }}; #define Register_layer_creator (type, CREATOR) static layerregisterer<float> g_ creator_f_# #type (#type, creator<float>); Static layerregisterer<double> g_creator_d_# #type (#type, creator<double>) #define REGISTER_LAYER_CLASS ( Type) template <typename dtype> shared_ptr<layer<dtype> > creator_# #type # #Layer (const layerparameter& param) { Return shared_ptr<layer<dtype> > (new Type # #Layer <dtypE> (param)); } register_layer_creator (Type, creator_# #type # #Layer)}//Namespace Caffe
After reading these believe that everyone to the Caffe source analysis positioning can be quickly started.
Copyright NOTICE: This article for Bo Master original article, without Bo Master permission not reproduced.
Layer Structure of Caffe