docs/tutorial/net_layer_blob.md

   1 ---
   2 title: Blobs, Layers, and Nets
   3 ---
   4 # Blobs, Layers, and Nets: anatomy of a Caffe model
   5
   6 Deep networks are compositional models that are naturally represented as a collection of inter-connected layers that work on chunks of data. Caffe defines a net layer-by-layer in its own model schema. The network defines the entire model bottom-to-top from input data to loss. As data and derivatives flow through the network in the [forward and backward passes](forward_backward.html) Caffe stores, communicates, and manipulates the information as *blobs*: the blob is the standard array and unified memory interface for the framework. The layer comes next as the foundation of both model and computation. The net follows as the collection and connection of layers. The details of blob describe how information is stored and communicated in and across layers and nets.
   7
   8 [Solving](solver.html) is configured separately to decouple modeling and optimization.
   9
  10 We will go over the details of these components in more detail.
  11
  12 ## Blob storage and communication
  13
  14 A Blob is a wrapper over the actual data being processed and passed along by Caffe, and also under the hood provides synchronization capability between the CPU and the GPU. Mathematically, a blob is an N-dimensional array stored in a C-contiguous fashion.
  15
  16 Caffe stores and communicates data using blobs. Blobs provide a unified memory interface holding data; e.g., batches of images, model parameters, and derivatives for optimization.
  17
  18 Blobs conceal the computational and mental overhead of mixed CPU/GPU operation by synchronizing from the CPU host to the GPU device as needed. Memory on the host and device is allocated on demand (lazily) for efficient memory usage.
  19
  20 The conventional blob dimensions for batches of image data are number N x channel K x height H x width W. Blob memory is row-major in layout, so the last / rightmost dimension changes fastest. For example, in a 4D blob, the value at index (n, k, h, w) is physically located at index ((n * K + k) * H + h) * W + w.
  21
  22 - Number / N is the batch size of the data. Batch processing achieves better throughput for communication and device processing. For an ImageNet training batch of 256 images B = 256.
  23 - Channel / K is the feature dimension e.g. for RGB images K = 3.
  24
  25 Note that although many blobs in Caffe examples are 4D with axes for image applications, it is totally valid to use blobs for non-image applications. For example, if you simply need fully-connected networks like the conventional multi-layer perceptron, use 2D blobs (shape (N, D)) and call the InnerProductLayer (which we will cover soon).
  26
  27 Parameter blob dimensions vary according to the type and configuration of the layer. For a convolution layer with 96 filters of 11 x 11 spatial dimension and 3 inputs the blob is 96 x 3 x 11 x 11. For an inner product / fully-connected layer with 1000 output channels and 1024 input channels the parameter blob is 1000 x 1024.
  28
  29 For custom data it may be necessary to hack your own input preparation tool or data layer. However once your data is in your job is done. The modularity of layers accomplishes the rest of the work for you.
  30
  31 ### Implementation Details
  32
  33 As we are often interested in the values as well as the gradients of the blob, a Blob stores two chunks of memories, *data* and *diff*. The former is the normal data that we pass along, and the latter is the gradient computed by the network.
  34
  35 Further, as the actual values could be stored either on the CPU and on the GPU, there are two different ways to access them: the const way, which does not change the values, and the mutable way, which changes the values:
  36
  37     const Dtype* cpu_data() const;
  38     Dtype* mutable_cpu_data();
  39
  40 (similarly for gpu and diff).
  41
  42 The reason for such design is that, a Blob uses a SyncedMem class to synchronize values between the CPU and GPU in order to hide the synchronization details and to minimize data transfer. A rule of thumb is, always use the const call if you do not want to change the values, and never store the pointers in your own object. Every time you work on a blob, call the functions to get the pointers, as the SyncedMem will need this to figure out when to copy data.
  43
  44 In practice when GPUs are present, one loads data from the disk to a blob in CPU code, calls a device kernel to do GPU computation, and ferries the blob off to the next layer, ignoring low-level details while maintaining a high level of performance. As long as all layers have GPU implementations, all the intermediate data and gradients will remain in the GPU.
  45
  46 If you want to check out when a Blob will copy data, here is an illustrative example:
  47
  48     // Assuming that data are on the CPU initially, and we have a blob.
  49     const Dtype* foo;
  50     Dtype* bar;
  51     foo = blob.gpu_data(); // data copied cpu->gpu.
  52     foo = blob.cpu_data(); // no data copied since both have up-to-date contents.
  53     bar = blob.mutable_gpu_data(); // no data copied.
  54     // ... some operations ...
  55     bar = blob.mutable_gpu_data(); // no data copied when we are still on GPU.
  56     foo = blob.cpu_data(); // data copied gpu->cpu, since the gpu side has modified the data
  57     foo = blob.gpu_data(); // no data copied since both have up-to-date contents
  58     bar = blob.mutable_cpu_data(); // still no data copied.
  59     bar = blob.mutable_gpu_data(); // data copied cpu->gpu.
  60     bar = blob.mutable_cpu_data(); // data copied gpu->cpu.
  61
  62 ## Layer computation and connections
  63
  64 The layer is the essence of a model and the fundamental unit of computation. Layers convolve filters, pool, take inner products, apply nonlinearities like rectified-linear and sigmoid and other elementwise transformations, normalize, load data, and compute losses like softmax and hinge. [See the layer catalogue](layers.html) for all operations. Most of the types needed for state-of-the-art deep learning tasks are there.
  65
  66 <img src="fig/layer.jpg" alt="A layer with bottom and top blob." width="256">
  67
  68 A layer takes input through *bottom* connections and makes output through *top* connections.
  69
  70 Each layer type defines three critical computations: *setup*, *forward*, and *backward*.
  71
  72 - Setup: initialize the layer and its connections once at model initialization.
  73 - Forward: given input from bottom compute the output and send to the top.
  74 - Backward: given the gradient w.r.t. the top output compute the gradient w.r.t. to the input and send to the bottom. A layer with parameters computes the gradient w.r.t. to its parameters and stores it internally.
  75
  76 More specifically, there will be two Forward and Backward functions implemented, one for CPU and one for GPU. If you do not implement a GPU version, the layer will fall back to the CPU functions as a backup option. This may come handy if you would like to do quick experiments, although it may come with additional data transfer cost (its inputs will be copied from GPU to CPU, and its outputs will be copied back from CPU to GPU).
  77
  78 Layers have two key responsibilities for the operation of the network as a whole: a *forward pass* that takes the inputs and produces the outputs, and a *backward pass* that takes the gradient with respect to the output, and computes the gradients with respect to the parameters and to the inputs, which are in turn back-propagated to earlier layers. These passes are simply the composition of each layer's forward and backward.
  79
  80 Developing custom layers requires minimal effort by the compositionality of the network and modularity of the code. Define the setup, forward, and backward for the layer and it is ready for inclusion in a net.
  81
  82 ## Net definition and operation
  83
  84 The net jointly defines a function and its gradient by composition and auto-differentiation. The composition of every layer's output computes the function to do a given task, and the composition of every layer's backward computes the gradient from the loss to learn the task. Caffe models are end-to-end machine learning engines.
  85
  86 The net is a set of layers connected in a computation graph -- a directed acyclic graph (DAG) to be exact. Caffe does all the bookkeeping for any DAG of layers to ensure correctness of the forward and backward passes. A typical net begins with a data layer that loads from disk and ends with a loss layer that computes the objective for a task such as classification or reconstruction.
  87
  88 The net is defined as a set of layers and their connections in a plaintext modeling language.
  89 A simple logistic regression classifier
  90
  91 <img src="fig/logreg.jpg" alt="Softmax Regression" width="256">
  92
  93 is defined by
  94
  95     name: "LogReg"
  96     layer {
  97       name: "mnist"
  98       type: "Data"
  99       top: "data"
 100       top: "label"
 101       data_param {
 102         source: "input_leveldb"
 103         batch_size: 64
 104       }
 105     }
 106     layer {
 107       name: "ip"
 108       type: "InnerProduct"
 109       bottom: "data"
 110       top: "ip"
 111       inner_product_param {
 112         num_output: 2
 113       }
 114     }
 115     layer {
 116       name: "loss"
 117       type: "SoftmaxWithLoss"
 118       bottom: "ip"
 119       bottom: "label"
 120       top: "loss"
 121     }
 122
 123 Model initialization is handled by `Net::Init()`. The initialization mainly does two things: scaffolding the overall DAG by creating the blobs and layers (for C++ geeks: the network will retain ownership of the blobs and layers during its lifetime), and calls the layers' `SetUp()` function. It also does a set of other bookkeeping things, such as validating the correctness of the overall network architecture. Also, during initialization the Net explains its initialization by logging to INFO as it goes:
 124
 125     I0902 22:52:17.931977 2079114000 net.cpp:39] Initializing net from parameters:
 126     name: "LogReg"
 127     [...model prototxt printout...]
 128     # construct the network layer-by-layer
 129     I0902 22:52:17.932152 2079114000 net.cpp:67] Creating Layer mnist
 130     I0902 22:52:17.932165 2079114000 net.cpp:356] mnist -> data
 131     I0902 22:52:17.932188 2079114000 net.cpp:356] mnist -> label
 132     I0902 22:52:17.932200 2079114000 net.cpp:96] Setting up mnist
 133     I0902 22:52:17.935807 2079114000 data_layer.cpp:135] Opening leveldb input_leveldb
 134     I0902 22:52:17.937155 2079114000 data_layer.cpp:195] output data size: 64,1,28,28
 135     I0902 22:52:17.938570 2079114000 net.cpp:103] Top shape: 64 1 28 28 (50176)
 136     I0902 22:52:17.938593 2079114000 net.cpp:103] Top shape: 64 (64)
 137     I0902 22:52:17.938611 2079114000 net.cpp:67] Creating Layer ip
 138     I0902 22:52:17.938617 2079114000 net.cpp:394] ip <- data
 139     I0902 22:52:17.939177 2079114000 net.cpp:356] ip -> ip
 140     I0902 22:52:17.939196 2079114000 net.cpp:96] Setting up ip
 141     I0902 22:52:17.940289 2079114000 net.cpp:103] Top shape: 64 2 (128)
 142     I0902 22:52:17.941270 2079114000 net.cpp:67] Creating Layer loss
 143     I0902 22:52:17.941305 2079114000 net.cpp:394] loss <- ip
 144     I0902 22:52:17.941314 2079114000 net.cpp:394] loss <- label
 145     I0902 22:52:17.941323 2079114000 net.cpp:356] loss -> loss
 146     # set up the loss and configure the backward pass
 147     I0902 22:52:17.941328 2079114000 net.cpp:96] Setting up loss
 148     I0902 22:52:17.941328 2079114000 net.cpp:103] Top shape: (1)
 149     I0902 22:52:17.941329 2079114000 net.cpp:109]     with loss weight 1
 150     I0902 22:52:17.941779 2079114000 net.cpp:170] loss needs backward computation.
 151     I0902 22:52:17.941787 2079114000 net.cpp:170] ip needs backward computation.
 152     I0902 22:52:17.941794 2079114000 net.cpp:172] mnist does not need backward computation.
 153     # determine outputs
 154     I0902 22:52:17.941800 2079114000 net.cpp:208] This network produces output loss
 155     # finish initialization and report memory usage
 156     I0902 22:52:17.941810 2079114000 net.cpp:467] Collecting Learning Rate and Weight Decay.
 157     I0902 22:52:17.941818 2079114000 net.cpp:219] Network initialization done.
 158     I0902 22:52:17.941824 2079114000 net.cpp:220] Memory required for data: 201476
 159
 160 Note that the construction of the network is device agnostic - recall our earlier explanation that blobs and layers hide implementation details from the model definition. After construction, the network is run on either CPU or GPU by setting a single switch defined in `Caffe::mode()` and set by `Caffe::set_mode()`. Layers come with corresponding CPU and GPU routines that produce identical results (up to numerical errors, and with tests to guard it). The CPU / GPU switch is seamless and independent of the model definition. For research and deployment alike it is best to divide model and implementation.
 161
 162 ### Model format
 163
 164 The models are defined in plaintext protocol buffer schema (prototxt) while the learned models are serialized as binary protocol buffer (binaryproto) .caffemodel files.
 165
 166 The model format is defined by the protobuf schema in [caffe.proto](https://github.com/BVLC/caffe/blob/master/src/caffe/proto/caffe.proto). The source file is mostly self-explanatory so one is encouraged to check it out.
 167
 168 Caffe speaks [Google Protocol Buffer](https://code.google.com/p/protobuf/) for the following strengths: minimal-size binary strings when serialized, efficient serialization, a human-readable text format compatible with the binary version, and efficient interface implementations in multiple languages, most notably C++ and Python. This all contributes to the flexibility and extensibility of modeling in Caffe.