Skip to content

P
Paddle

PaddlePaddle / Paddle
大约 2 年 前同步成功

通知 2325
Star 20933
Fork 5424
P
Paddle
“6803b882542d93a22a5f6991efb7d17019903bfc”上不存在“develop/doc/howto/cmd_parameter/detail_introduction_en.html”
提交 42fdd3fa 编写于 作者: T Travis CI
浏览文件
操作

Deploy to GitHub Pages: 7e4cbfe4

上级 24a84c03
隐藏空白更改
内联 并排
Showing with 260 addition and 138 deletion
develop/doc/_sources/design/switch_kernel.md.txt
浏览文件 @ 42fdd3fa
## Background ## Background
Every operator has many kernels because there are multiple data types, places, data layout that Fluid supports. We use the `KernelType` to describe kernel types that operators can hold. Every operator has many kernels because there are multiple data types, places, data layout, library type that Fluid supports. We use the `OpKernelType ` to describe kernel types that operators can hold.
The `KernelType` is as follows. The `OpKernelType ` is as follows:
``` ```cpp
struct KernelType { struct OpKernelType {
Place place_; Place place_;
DataType data_type_; DataType data_type_;
LayoutType layout_; DataLayout data_layout_;
LibraryType library_type_;
}; };
``` ```
The `place_` is a descriptor of the device and the computational library, e.g., `MKLDNNPlace`, `CUDAPlace`. - The `place_` is a descriptor of the device, e.g., CPUPlace, CUDAPlace.
The `data_type_` is the data type that this kernel performs on, e.g., `FP32`, `INT64`. Note that one kernel may have inputs with different data types. However, it will be a major `data_type`. For example, the `cross_entropy` takes `int64` as it label, and `double`/`float` as its input logit and output cost. The major `data_type` of `cross_entropy` is `float`/`double`. - The `data_type_` is the data type that this kernel performs on, e.g., `FP32`, `INT64`. Note that one kernel may have inputs with different data types. However, it will be a major `data_type`. For example, the `cross_entropy` takes `int64` as it label, and `double`/`float` as its input logit and output cost. The major `data_type` of `cross_entropy` is `float` or `double`.
The `layout` is useful for some computational library. One example is that MKLDNN uses many kinds of layout, such as `nChw8c`. Each kind of layout will invoke the different kernel. - The `data_layout_ ` is useful for some computational library. One example is that MKLDNN uses many kinds of layout, such as `nChw8c`. Each kind of layout will invoke the different kernel.
- The `library_type_` describes the computational library, e.g., `MKLDNN`, `CUDNN`.
## Problem ## Problem
...@@ -25,42 +28,72 @@ We register a kernel for every operator and every kernel type ideally. However, ...@@ -25,42 +28,72 @@ We register a kernel for every operator and every kernel type ideally. However,
2. Some operators will take too many memory. It is better to force them into CPU. However, the rest of operators in this neural network will be performed on GPU, i.e., model parallel problem. 2. Some operators will take too many memory. It is better to force them into CPU. However, the rest of operators in this neural network will be performed on GPU, i.e., model parallel problem.
3. Some layout and place are particular. One example is that MKLDNN uses `nChw8` and there is no other library uses `nChw8c`. 3. Some layout and place are particular. One example is that MKLDNN uses `nChw8` and there is no other library uses `nChw8c`.
Problems under these situations are similar. We can formalise this problem as follow. Take one situation to give a detailed explanation, if we have two Operators: OP1 and OP2, OP1 has one output `op1_to_op2`, and `op1_to_op2` is the input of OP2.
If OP1 and OP2 run on the same place(for example CPUPlace), then `op1_2_op2` can be used directly by OP2.
```
OP1(CPUPlace)
|
op1_2_op2
|
OP2(CPUPlace)
```
If OP1 and OP2 run one different place, then OP2 cannot `use op1_2_op2` directly.
Problems under these situations are similar. We can formalize this problem as follow.
We register kernels with types $KT = \{kt_1, kt_2, kt_3, ...\}$ for one operator. The inputs of this operator should be run on kernel type $kt_{?}$, which the $kt_{?} \notin KT$. How to cast the input of this operator from $kt_{?}$ to any of kernel type in $KT$. We register kernels with types $KT = \{kt_1, kt_2, kt_3, ...\}$ for one operator. The inputs of this operator should be run on kernel type $kt_{?}$, which the $kt_{?} \notin KT$. How to cast the input of this operator from $kt_{?}$ to any of kernel type in $KT$.
## Solution ## Solution: data transform
It is clearly that transforming inputs of an operator toadapt another kernel type is not related to the particular operator. So we should register these transformation methods as global methods. It is clear that transforming inputs of an operator to adapt another kernel type is not related to the particular operator. So we should register these transformation methods as global methods.
We can infer a kernel type from the inputs of an operators. We let this kernel type as `actual kernel type`, which means this kernel type is the actually kernel type that operator should be performed. We can infer kernel type for each input of an operator. We let this kernel type as `actual kernel type for var`, which means this kernel type is the kernel type that can process this input variable.
We can get a kernel type by 1) The configuration of operator description. (Users may want to force use `MKL` for `conv` operator). 2) The place of the current executor. (Executor is running on GPU). This kernel type is what we expect the operator will be performed on. We let this kernel type as `expect kernel type`. We can get a kernel type by 1) The configuration of operator description. (Users may want to force use `MKL` for `conv` operator). 2) The place of the current executor. (Executor is running on GPU). This kernel type is what we expect the operator will be performed on. We let this kernel type as `expect kernel type`.
We transform the input data from `actual` to `expect` if the expect kernel type is not as same as actual kernel type. We transform the input data from `actual` to `expect` if the actual kernel type is not as same as expect kernel type.
The algorithm is described as follow The algorithm is described as following
```cpp ```cpp
using DataTransformationFN = std::function<void(const Tensor& in, Tensor* out)>; void OperatorWithKernel::Run(
using KernelTypePair = std::pair<KernelType, KernelType>; const Scope& scope,
const platform::Place& place) const {
map<KernelTypePair, DataTransformationFN> g_data_transformation_; ExecutionContext ctx(...);
auto expected_kernel_key = this->GetExpectedKernelType(ctx);
void OpWithKernel::Run() {
vec<Tensor> inputs = ... Scope& new_scope = scope.NewScope();
auto actual_kernel_type = GetActualKernelType(inputs);
for (auto& var_name : this->Inputs()) {
// The expected kernel type is related to actual kernel type. auto* tensor_in = GetTensor(var_name);
// For the most operators, the expected kernel type is as same as auto kernel_type_for_var = this->GetKernelTypeForVar(...);
// actual kernel type. if (kernel_type_for_var.place_ != expected_kernel_key.place_) {
// auto* trans_var = new_scope.Var(var_name);
// So we pass `actual_kernel_type` as a parameter of auto* out = DataTransform(expected_kernel_key,
// GetExpectedKernelType kernel_type_for_var,
auto expect_kernel_type = GetExpectedKernelType(actual_kernel_type); *tensor_in);
CopyVariableWithTensor(...);
auto trans = g_data_transformation_[{actual_kernel_type, expect_kernel_type}]; }
}
kernel.run(trans(inputs));
auto kernel = kernels.find(expected_kernel_key);
kernel->Compute(ExecutionContext(...));
} }
``` ```
then the actual process for the multi-device above will be:
```
OP1(CPUPlace)
|
op1_2_op2(on CPU)
|
[transform](from CPU to GPU)
|
op1_2_op2(on GPU)
|
OP2(CUDAPlace)
```
develop/doc/design/switch_kernel.html
浏览文件 @ 42fdd3fa
...@@ -211,18 +211,22 @@ ...@@ -211,18 +211,22 @@
<div class="section" id="background"> <div class="section" id="background">
<span id="background"></span><h1>Background<a class="headerlink" href="#background" title="Permalink to this headline"></a></h1> <span id="background"></span><h1>Background<a class="headerlink" href="#background" title="Permalink to this headline"></a></h1>
<p>Every operator has many kernels because there are multiple data types, places, data layout that Fluid supports. We use the <code class="docutils literal"><span class="pre">KernelType</span></code> to describe kernel types that operators can hold.</p> <p>Every operator has many kernels because there are multiple data types, places, data layout, library type that Fluid supports. We use the <code class="docutils literal"><span class="pre">OpKernelType</span></code> to describe kernel types that operators can hold.</p>
<p>The <code class="docutils literal"><span class="pre">KernelType</span></code> is as follows.</p> <p>The <code class="docutils literal"><span class="pre">OpKernelType</span></code> is as follows:</p>
<div class="highlight-default"><div class="highlight"><pre><span></span><span class="n">struct</span> <span class="n">KernelType</span> <span class="p">{</span> <div class="highlight-cpp"><div class="highlight"><pre><span></span><span class="k">struct</span> <span class="n">OpKernelType</span> <span class="p">{</span>
<span class="n">Place</span> <span class="n">place_</span><span class="p">;</span> <span class="n">Place</span> <span class="n">place_</span><span class="p">;</span>
<span class="n">DataType</span> <span class="n">data_type_</span><span class="p">;</span> <span class="n">DataType</span> <span class="n">data_type_</span><span class="p">;</span>
<span class="n">LayoutType</span> <span class="n">layout_</span><span class="p">;</span> <span class="n">DataLayout</span> <span class="n">data_layout_</span><span class="p">;</span>
<span class="n">LibraryType</span> <span class="n">library_type_</span><span class="p">;</span>
<span class="p">};</span> <span class="p">};</span>
</pre></div> </pre></div>
</div> </div>
<p>The <code class="docutils literal"><span class="pre">place_</span></code> is a descriptor of the device and the computational library, e.g., <code class="docutils literal"><span class="pre">MKLDNNPlace</span></code>, <code class="docutils literal"><span class="pre">CUDAPlace</span></code>.</p> <ul class="simple">
<p>The <code class="docutils literal"><span class="pre">data_type_</span></code> is the data type that this kernel performs on, e.g., <code class="docutils literal"><span class="pre">FP32</span></code>, <code class="docutils literal"><span class="pre">INT64</span></code>. Note that one kernel may have inputs with different data types. However, it will be a major <code class="docutils literal"><span class="pre">data_type</span></code>. For example, the <code class="docutils literal"><span class="pre">cross_entropy</span></code> takes <code class="docutils literal"><span class="pre">int64</span></code> as it label, and <code class="docutils literal"><span class="pre">double</span></code>/<code class="docutils literal"><span class="pre">float</span></code> as its input logit and output cost. The major <code class="docutils literal"><span class="pre">data_type</span></code> of <code class="docutils literal"><span class="pre">cross_entropy</span></code> is <code class="docutils literal"><span class="pre">float</span></code>/<code class="docutils literal"><span class="pre">double</span></code>.</p> <li>The <code class="docutils literal"><span class="pre">place_</span></code> is a descriptor of the device, e.g., CPUPlace, CUDAPlace.</li>
<p>The <code class="docutils literal"><span class="pre">layout</span></code> is useful for some computational library. One example is that MKLDNN uses many kinds of layout, such as <code class="docutils literal"><span class="pre">nChw8c</span></code>. Each kind of layout will invoke the different kernel.</p> <li>The <code class="docutils literal"><span class="pre">data_type_</span></code> is the data type that this kernel performs on, e.g., <code class="docutils literal"><span class="pre">FP32</span></code>, <code class="docutils literal"><span class="pre">INT64</span></code>. Note that one kernel may have inputs with different data types. However, it will be a major <code class="docutils literal"><span class="pre">data_type</span></code>. For example, the <code class="docutils literal"><span class="pre">cross_entropy</span></code> takes <code class="docutils literal"><span class="pre">int64</span></code> as it label, and <code class="docutils literal"><span class="pre">double</span></code>/<code class="docutils literal"><span class="pre">float</span></code> as its input logit and output cost. The major <code class="docutils literal"><span class="pre">data_type</span></code> of <code class="docutils literal"><span class="pre">cross_entropy</span></code> is <code class="docutils literal"><span class="pre">float</span></code> or <code class="docutils literal"><span class="pre">double</span></code>.</li>
<li>The <code class="docutils literal"><span class="pre">data_layout_</span></code> is useful for some computational library. One example is that MKLDNN uses many kinds of layout, such as <code class="docutils literal"><span class="pre">nChw8c</span></code>. Each kind of layout will invoke the different kernel.</li>
<li>The <code class="docutils literal"><span class="pre">library_type_</span></code> describes the computational library, e.g., <code class="docutils literal"><span class="pre">MKLDNN</span></code>, <code class="docutils literal"><span class="pre">CUDNN</span></code>.</li>
</ul>
</div> </div>
<div class="section" id="problem"> <div class="section" id="problem">
<span id="problem"></span><h1>Problem<a class="headerlink" href="#problem" title="Permalink to this headline"></a></h1> <span id="problem"></span><h1>Problem<a class="headerlink" href="#problem" title="Permalink to this headline"></a></h1>
...@@ -232,39 +236,63 @@ ...@@ -232,39 +236,63 @@
<li>Some operators will take too many memory. It is better to force them into CPU. However, the rest of operators in this neural network will be performed on GPU, i.e., model parallel problem.</li> <li>Some operators will take too many memory. It is better to force them into CPU. However, the rest of operators in this neural network will be performed on GPU, i.e., model parallel problem.</li>
<li>Some layout and place are particular. One example is that MKLDNN uses <code class="docutils literal"><span class="pre">nChw8</span></code> and there is no other library uses <code class="docutils literal"><span class="pre">nChw8c</span></code>.</li> <li>Some layout and place are particular. One example is that MKLDNN uses <code class="docutils literal"><span class="pre">nChw8</span></code> and there is no other library uses <code class="docutils literal"><span class="pre">nChw8c</span></code>.</li>
</ol> </ol>
<p>Problems under these situations are similar. We can formalise this problem as follow.</p> <p>Take one situation to give a detailed explanation, if we have two Operators: OP1 and OP2, OP1 has one output <code class="docutils literal"><span class="pre">op1_to_op2</span></code>, and <code class="docutils literal"><span class="pre">op1_to_op2</span></code> is the input of OP2.</p>
<p>If OP1 and OP2 run on the same place(for example CPUPlace), then <code class="docutils literal"><span class="pre">op1_2_op2</span></code> can be used directly by OP2.</p>
<div class="highlight-default"><div class="highlight"><pre><span></span><span class="n">OP1</span><span class="p">(</span><span class="n">CPUPlace</span><span class="p">)</span>
<span class="o">|</span>
<span class="n">op1_2_op2</span>
<span class="o">|</span>
<span class="n">OP2</span><span class="p">(</span><span class="n">CPUPlace</span><span class="p">)</span>
</pre></div>
</div>
<p>If OP1 and OP2 run one different place, then OP2 cannot <code class="docutils literal"><span class="pre">use</span> <span class="pre">op1_2_op2</span></code> directly.</p>
<p>Problems under these situations are similar. We can formalize this problem as follow.</p>
<p>We register kernels with types $KT = {kt_1, kt_2, kt_3, ...}$ for one operator. The inputs of this operator should be run on kernel type $kt_{?}$, which the $kt_{?} \notin KT$. How to cast the input of this operator from $kt_{?}$ to any of kernel type in $KT$.</p> <p>We register kernels with types $KT = {kt_1, kt_2, kt_3, ...}$ for one operator. The inputs of this operator should be run on kernel type $kt_{?}$, which the $kt_{?} \notin KT$. How to cast the input of this operator from $kt_{?}$ to any of kernel type in $KT$.</p>
</div> </div>
<div class="section" id="solution"> <div class="section" id="solution-data-transform">
<span id="solution"></span><h1>Solution<a class="headerlink" href="#solution" title="Permalink to this headline"></a></h1> <span id="solution-data-transform"></span><h1>Solution: data transform<a class="headerlink" href="#solution-data-transform" title="Permalink to this headline"></a></h1>
<p>It is clearly that transforming inputs of an operator toadapt another kernel type is not related to the particular operator. So we should register these transformation methods as global methods.</p> <p>It is clear that transforming inputs of an operator to adapt another kernel type is not related to the particular operator. So we should register these transformation methods as global methods.</p>
<p>We can infer a kernel type from the inputs of an operators. We let this kernel type as <code class="docutils literal"><span class="pre">actual</span> <span class="pre">kernel</span> <span class="pre">type</span></code>, which means this kernel type is the actually kernel type that operator should be performed.</p> <p>We can infer kernel type for each input of an operator. We let this kernel type as <code class="docutils literal"><span class="pre">actual</span> <span class="pre">kernel</span> <span class="pre">type</span> <span class="pre">for</span> <span class="pre">var</span></code>, which means this kernel type is the kernel type that can process this input variable.</p>
<p>We can get a kernel type by 1) The configuration of operator description. (Users may want to force use <code class="docutils literal"><span class="pre">MKL</span></code> for <code class="docutils literal"><span class="pre">conv</span></code> operator). 2) The place of the current executor. (Executor is running on GPU). This kernel type is what we expect the operator will be performed on. We let this kernel type as <code class="docutils literal"><span class="pre">expect</span> <span class="pre">kernel</span> <span class="pre">type</span></code>.</p> <p>We can get a kernel type by 1) The configuration of operator description. (Users may want to force use <code class="docutils literal"><span class="pre">MKL</span></code> for <code class="docutils literal"><span class="pre">conv</span></code> operator). 2) The place of the current executor. (Executor is running on GPU). This kernel type is what we expect the operator will be performed on. We let this kernel type as <code class="docutils literal"><span class="pre">expect</span> <span class="pre">kernel</span> <span class="pre">type</span></code>.</p>
<p>We transform the input data from <code class="docutils literal"><span class="pre">actual</span></code> to <code class="docutils literal"><span class="pre">expect</span></code> if the expect kernel type is not as same as actual kernel type.</p> <p>We transform the input data from <code class="docutils literal"><span class="pre">actual</span></code> to <code class="docutils literal"><span class="pre">expect</span></code> if the actual kernel type is not as same as expect kernel type.</p>
<p>The algorithm is described as follow</p> <p>The algorithm is described as following</p>
<div class="highlight-cpp"><div class="highlight"><pre><span></span><span class="k">using</span> <span class="n">DataTransformationFN</span> <span class="o">=</span> <span class="n">std</span><span class="o">::</span><span class="n">function</span><span class="o">&lt;</span><span class="kt">void</span><span class="p">(</span><span class="k">const</span> <span class="n">Tensor</span><span class="o">&amp;</span> <span class="n">in</span><span class="p">,</span> <span class="n">Tensor</span><span class="o">*</span> <span class="n">out</span><span class="p">)</span><span class="o">&gt;</span><span class="p">;</span> <div class="highlight-cpp"><div class="highlight"><pre><span></span><span class="kt">void</span> <span class="n">OperatorWithKernel</span><span class="o">::</span><span class="n">Run</span><span class="p">(</span>
<span class="k">using</span> <span class="n">KernelTypePair</span> <span class="o">=</span> <span class="n">std</span><span class="o">::</span><span class="n">pair</span><span class="o">&lt;</span><span class="n">KernelType</span><span class="p">,</span> <span class="n">KernelType</span><span class="o">&gt;</span><span class="p">;</span> <span class="k">const</span> <span class="n">Scope</span><span class="o">&amp;</span> <span class="n">scope</span><span class="p">,</span>
<span class="k">const</span> <span class="n">platform</span><span class="o">::</span><span class="n">Place</span><span class="o">&amp;</span> <span class="n">place</span><span class="p">)</span> <span class="k">const</span> <span class="p">{</span>
<span class="n">map</span><span class="o">&lt;</span><span class="n">KernelTypePair</span><span class="p">,</span> <span class="n">DataTransformationFN</span><span class="o">&gt;</span> <span class="n">g_data_transformation_</span><span class="p">;</span> <span class="n">ExecutionContext</span> <span class="n">ctx</span><span class="p">(...);</span>
<span class="k">auto</span> <span class="n">expected_kernel_key</span> <span class="o">=</span> <span class="k">this</span><span class="o">-&gt;</span><span class="n">GetExpectedKernelType</span><span class="p">(</span><span class="n">ctx</span><span class="p">);</span>
<span class="kt">void</span> <span class="n">OpWithKernel</span><span class="o">::</span><span class="n">Run</span><span class="p">()</span> <span class="p">{</span>
<span class="n">vec</span><span class="o">&lt;</span><span class="n">Tensor</span><span class="o">&gt;</span> <span class="n">inputs</span> <span class="o">=</span> <span class="p">...</span> <span class="n">Scope</span><span class="o">&amp;</span> <span class="n">new_scope</span> <span class="o">=</span> <span class="n">scope</span><span class="p">.</span><span class="n">NewScope</span><span class="p">();</span>
<span class="k">auto</span> <span class="n">actual_kernel_type</span> <span class="o">=</span> <span class="n">GetActualKernelType</span><span class="p">(</span><span class="n">inputs</span><span class="p">);</span>
<span class="k">for</span> <span class="p">(</span><span class="k">auto</span><span class="o">&amp;</span> <span class="nl">var_name</span> <span class="p">:</span> <span class="k">this</span><span class="o">-&gt;</span><span class="n">Inputs</span><span class="p">())</span> <span class="p">{</span>
<span class="c1">// The expected kernel type is related to actual kernel type.</span> <span class="k">auto</span><span class="o">*</span> <span class="n">tensor_in</span> <span class="o">=</span> <span class="n">GetTensor</span><span class="p">(</span><span class="n">var_name</span><span class="p">);</span>
<span class="c1">// For the most operators, the expected kernel type is as same as</span> <span class="k">auto</span> <span class="n">kernel_type_for_var</span> <span class="o">=</span> <span class="k">this</span><span class="o">-&gt;</span><span class="n">GetKernelTypeForVar</span><span class="p">(...);</span>
<span class="c1">// actual kernel type.</span> <span class="k">if</span> <span class="p">(</span><span class="n">kernel_type_for_var</span><span class="p">.</span><span class="n">place_</span> <span class="o">!=</span> <span class="n">expected_kernel_key</span><span class="p">.</span><span class="n">place_</span><span class="p">)</span> <span class="p">{</span>
<span class="c1">//</span> <span class="k">auto</span><span class="o">*</span> <span class="n">trans_var</span> <span class="o">=</span> <span class="n">new_scope</span><span class="p">.</span><span class="n">Var</span><span class="p">(</span><span class="n">var_name</span><span class="p">);</span>
<span class="c1">// So we pass `actual_kernel_type` as a parameter of </span> <span class="k">auto</span><span class="o">*</span> <span class="n">out</span> <span class="o">=</span> <span class="n">DataTransform</span><span class="p">(</span><span class="n">expected_kernel_key</span><span class="p">,</span>
<span class="c1">// GetExpectedKernelType</span> <span class="n">kernel_type_for_var</span><span class="p">,</span>
<span class="k">auto</span> <span class="n">expect_kernel_type</span> <span class="o">=</span> <span class="n">GetExpectedKernelType</span><span class="p">(</span><span class="n">actual_kernel_type</span><span class="p">);</span> <span class="o">*</span><span class="n">tensor_in</span><span class="p">);</span>
<span class="n">CopyVariableWithTensor</span><span class="p">(...);</span>
<span class="k">auto</span> <span class="n">trans</span> <span class="o">=</span> <span class="n">g_data_transformation_</span><span class="p">[{</span><span class="n">actual_kernel_type</span><span class="p">,</span> <span class="n">expect_kernel_type</span><span class="p">}];</span> <span class="p">}</span>
<span class="p">}</span>
<span class="n">kernel</span><span class="p">.</span><span class="n">run</span><span class="p">(</span><span class="n">trans</span><span class="p">(</span><span class="n">inputs</span><span class="p">));</span>
<span class="k">auto</span> <span class="n">kernel</span> <span class="o">=</span> <span class="n">kernels</span><span class="p">.</span><span class="n">find</span><span class="p">(</span><span class="n">expected_kernel_key</span><span class="p">);</span>
<span class="n">kernel</span><span class="o">-&gt;</span><span class="n">Compute</span><span class="p">(</span><span class="n">ExecutionContext</span><span class="p">(...));</span>
<span class="p">}</span> <span class="p">}</span>
</pre></div> </pre></div>
</div> </div>
<p>then the actual process for the multi-device above will be:</p>
<div class="highlight-default"><div class="highlight"><pre><span></span><span class="n">OP1</span><span class="p">(</span><span class="n">CPUPlace</span><span class="p">)</span>
<span class="o">|</span>
<span class="n">op1_2_op2</span><span class="p">(</span><span class="n">on</span> <span class="n">CPU</span><span class="p">)</span>
<span class="o">|</span>
<span class="p">[</span><span class="n">transform</span><span class="p">](</span><span class="kn">from</span> <span class="nn">CPU</span> <span class="n">to</span> <span class="n">GPU</span><span class="p">)</span>
<span class="o">|</span>
<span class="n">op1_2_op2</span><span class="p">(</span><span class="n">on</span> <span class="n">GPU</span><span class="p">)</span>
<span class="o">|</span>
<span class="n">OP2</span><span class="p">(</span><span class="n">CUDAPlace</span><span class="p">)</span>
</pre></div>
</div>
</div> </div>
......
develop/doc/searchindex.js
浏览文件 @ 42fdd3fa
因为 它太大了无法显示 source diff 。你可以改为 查看blob。
develop/doc_cn/_sources/design/switch_kernel.md.txt
浏览文件 @ 42fdd3fa
## Background ## Background
Every operator has many kernels because there are multiple data types, places, data layout that Fluid supports. We use the `KernelType` to describe kernel types that operators can hold. Every operator has many kernels because there are multiple data types, places, data layout, library type that Fluid supports. We use the `OpKernelType ` to describe kernel types that operators can hold.
The `KernelType` is as follows. The `OpKernelType ` is as follows:
``` ```cpp
struct KernelType { struct OpKernelType {
Place place_; Place place_;
DataType data_type_; DataType data_type_;
LayoutType layout_; DataLayout data_layout_;
LibraryType library_type_;
}; };
``` ```
The `place_` is a descriptor of the device and the computational library, e.g., `MKLDNNPlace`, `CUDAPlace`. - The `place_` is a descriptor of the device, e.g., CPUPlace, CUDAPlace.
The `data_type_` is the data type that this kernel performs on, e.g., `FP32`, `INT64`. Note that one kernel may have inputs with different data types. However, it will be a major `data_type`. For example, the `cross_entropy` takes `int64` as it label, and `double`/`float` as its input logit and output cost. The major `data_type` of `cross_entropy` is `float`/`double`. - The `data_type_` is the data type that this kernel performs on, e.g., `FP32`, `INT64`. Note that one kernel may have inputs with different data types. However, it will be a major `data_type`. For example, the `cross_entropy` takes `int64` as it label, and `double`/`float` as its input logit and output cost. The major `data_type` of `cross_entropy` is `float` or `double`.
The `layout` is useful for some computational library. One example is that MKLDNN uses many kinds of layout, such as `nChw8c`. Each kind of layout will invoke the different kernel. - The `data_layout_ ` is useful for some computational library. One example is that MKLDNN uses many kinds of layout, such as `nChw8c`. Each kind of layout will invoke the different kernel.
- The `library_type_` describes the computational library, e.g., `MKLDNN`, `CUDNN`.
## Problem ## Problem
...@@ -25,42 +28,72 @@ We register a kernel for every operator and every kernel type ideally. However, ...@@ -25,42 +28,72 @@ We register a kernel for every operator and every kernel type ideally. However,
2. Some operators will take too many memory. It is better to force them into CPU. However, the rest of operators in this neural network will be performed on GPU, i.e., model parallel problem. 2. Some operators will take too many memory. It is better to force them into CPU. However, the rest of operators in this neural network will be performed on GPU, i.e., model parallel problem.
3. Some layout and place are particular. One example is that MKLDNN uses `nChw8` and there is no other library uses `nChw8c`. 3. Some layout and place are particular. One example is that MKLDNN uses `nChw8` and there is no other library uses `nChw8c`.
Problems under these situations are similar. We can formalise this problem as follow. Take one situation to give a detailed explanation, if we have two Operators: OP1 and OP2, OP1 has one output `op1_to_op2`, and `op1_to_op2` is the input of OP2.
If OP1 and OP2 run on the same place(for example CPUPlace), then `op1_2_op2` can be used directly by OP2.
```
OP1(CPUPlace)
|
op1_2_op2
|
OP2(CPUPlace)
```
If OP1 and OP2 run one different place, then OP2 cannot `use op1_2_op2` directly.
Problems under these situations are similar. We can formalize this problem as follow.
We register kernels with types $KT = \{kt_1, kt_2, kt_3, ...\}$ for one operator. The inputs of this operator should be run on kernel type $kt_{?}$, which the $kt_{?} \notin KT$. How to cast the input of this operator from $kt_{?}$ to any of kernel type in $KT$. We register kernels with types $KT = \{kt_1, kt_2, kt_3, ...\}$ for one operator. The inputs of this operator should be run on kernel type $kt_{?}$, which the $kt_{?} \notin KT$. How to cast the input of this operator from $kt_{?}$ to any of kernel type in $KT$.
## Solution ## Solution: data transform
It is clearly that transforming inputs of an operator toadapt another kernel type is not related to the particular operator. So we should register these transformation methods as global methods. It is clear that transforming inputs of an operator to adapt another kernel type is not related to the particular operator. So we should register these transformation methods as global methods.
We can infer a kernel type from the inputs of an operators. We let this kernel type as `actual kernel type`, which means this kernel type is the actually kernel type that operator should be performed. We can infer kernel type for each input of an operator. We let this kernel type as `actual kernel type for var`, which means this kernel type is the kernel type that can process this input variable.
We can get a kernel type by 1) The configuration of operator description. (Users may want to force use `MKL` for `conv` operator). 2) The place of the current executor. (Executor is running on GPU). This kernel type is what we expect the operator will be performed on. We let this kernel type as `expect kernel type`. We can get a kernel type by 1) The configuration of operator description. (Users may want to force use `MKL` for `conv` operator). 2) The place of the current executor. (Executor is running on GPU). This kernel type is what we expect the operator will be performed on. We let this kernel type as `expect kernel type`.
We transform the input data from `actual` to `expect` if the expect kernel type is not as same as actual kernel type. We transform the input data from `actual` to `expect` if the actual kernel type is not as same as expect kernel type.
The algorithm is described as follow The algorithm is described as following
```cpp ```cpp
using DataTransformationFN = std::function<void(const Tensor& in, Tensor* out)>; void OperatorWithKernel::Run(
using KernelTypePair = std::pair<KernelType, KernelType>; const Scope& scope,
const platform::Place& place) const {
map<KernelTypePair, DataTransformationFN> g_data_transformation_; ExecutionContext ctx(...);
auto expected_kernel_key = this->GetExpectedKernelType(ctx);
void OpWithKernel::Run() {
vec<Tensor> inputs = ... Scope& new_scope = scope.NewScope();
auto actual_kernel_type = GetActualKernelType(inputs);
for (auto& var_name : this->Inputs()) {
// The expected kernel type is related to actual kernel type. auto* tensor_in = GetTensor(var_name);
// For the most operators, the expected kernel type is as same as auto kernel_type_for_var = this->GetKernelTypeForVar(...);
// actual kernel type. if (kernel_type_for_var.place_ != expected_kernel_key.place_) {
// auto* trans_var = new_scope.Var(var_name);
// So we pass `actual_kernel_type` as a parameter of auto* out = DataTransform(expected_kernel_key,
// GetExpectedKernelType kernel_type_for_var,
auto expect_kernel_type = GetExpectedKernelType(actual_kernel_type); *tensor_in);
CopyVariableWithTensor(...);
auto trans = g_data_transformation_[{actual_kernel_type, expect_kernel_type}]; }
}
kernel.run(trans(inputs));
auto kernel = kernels.find(expected_kernel_key);
kernel->Compute(ExecutionContext(...));
} }
``` ```
then the actual process for the multi-device above will be:
```
OP1(CPUPlace)
|
op1_2_op2(on CPU)
|
[transform](from CPU to GPU)
|
op1_2_op2(on GPU)
|
OP2(CUDAPlace)
```
develop/doc_cn/design/switch_kernel.html
浏览文件 @ 42fdd3fa
...@@ -230,18 +230,22 @@ ...@@ -230,18 +230,22 @@
<div class="section" id="background"> <div class="section" id="background">
<span id="background"></span><h1>Background<a class="headerlink" href="#background" title="永久链接至标题"></a></h1> <span id="background"></span><h1>Background<a class="headerlink" href="#background" title="永久链接至标题"></a></h1>
<p>Every operator has many kernels because there are multiple data types, places, data layout that Fluid supports. We use the <code class="docutils literal"><span class="pre">KernelType</span></code> to describe kernel types that operators can hold.</p> <p>Every operator has many kernels because there are multiple data types, places, data layout, library type that Fluid supports. We use the <code class="docutils literal"><span class="pre">OpKernelType</span></code> to describe kernel types that operators can hold.</p>
<p>The <code class="docutils literal"><span class="pre">KernelType</span></code> is as follows.</p> <p>The <code class="docutils literal"><span class="pre">OpKernelType</span></code> is as follows:</p>
<div class="highlight-default"><div class="highlight"><pre><span></span><span class="n">struct</span> <span class="n">KernelType</span> <span class="p">{</span> <div class="highlight-cpp"><div class="highlight"><pre><span></span><span class="k">struct</span> <span class="n">OpKernelType</span> <span class="p">{</span>
<span class="n">Place</span> <span class="n">place_</span><span class="p">;</span> <span class="n">Place</span> <span class="n">place_</span><span class="p">;</span>
<span class="n">DataType</span> <span class="n">data_type_</span><span class="p">;</span> <span class="n">DataType</span> <span class="n">data_type_</span><span class="p">;</span>
<span class="n">LayoutType</span> <span class="n">layout_</span><span class="p">;</span> <span class="n">DataLayout</span> <span class="n">data_layout_</span><span class="p">;</span>
<span class="n">LibraryType</span> <span class="n">library_type_</span><span class="p">;</span>
<span class="p">};</span> <span class="p">};</span>
</pre></div> </pre></div>
</div> </div>
<p>The <code class="docutils literal"><span class="pre">place_</span></code> is a descriptor of the device and the computational library, e.g., <code class="docutils literal"><span class="pre">MKLDNNPlace</span></code>, <code class="docutils literal"><span class="pre">CUDAPlace</span></code>.</p> <ul class="simple">
<p>The <code class="docutils literal"><span class="pre">data_type_</span></code> is the data type that this kernel performs on, e.g., <code class="docutils literal"><span class="pre">FP32</span></code>, <code class="docutils literal"><span class="pre">INT64</span></code>. Note that one kernel may have inputs with different data types. However, it will be a major <code class="docutils literal"><span class="pre">data_type</span></code>. For example, the <code class="docutils literal"><span class="pre">cross_entropy</span></code> takes <code class="docutils literal"><span class="pre">int64</span></code> as it label, and <code class="docutils literal"><span class="pre">double</span></code>/<code class="docutils literal"><span class="pre">float</span></code> as its input logit and output cost. The major <code class="docutils literal"><span class="pre">data_type</span></code> of <code class="docutils literal"><span class="pre">cross_entropy</span></code> is <code class="docutils literal"><span class="pre">float</span></code>/<code class="docutils literal"><span class="pre">double</span></code>.</p> <li>The <code class="docutils literal"><span class="pre">place_</span></code> is a descriptor of the device, e.g., CPUPlace, CUDAPlace.</li>
<p>The <code class="docutils literal"><span class="pre">layout</span></code> is useful for some computational library. One example is that MKLDNN uses many kinds of layout, such as <code class="docutils literal"><span class="pre">nChw8c</span></code>. Each kind of layout will invoke the different kernel.</p> <li>The <code class="docutils literal"><span class="pre">data_type_</span></code> is the data type that this kernel performs on, e.g., <code class="docutils literal"><span class="pre">FP32</span></code>, <code class="docutils literal"><span class="pre">INT64</span></code>. Note that one kernel may have inputs with different data types. However, it will be a major <code class="docutils literal"><span class="pre">data_type</span></code>. For example, the <code class="docutils literal"><span class="pre">cross_entropy</span></code> takes <code class="docutils literal"><span class="pre">int64</span></code> as it label, and <code class="docutils literal"><span class="pre">double</span></code>/<code class="docutils literal"><span class="pre">float</span></code> as its input logit and output cost. The major <code class="docutils literal"><span class="pre">data_type</span></code> of <code class="docutils literal"><span class="pre">cross_entropy</span></code> is <code class="docutils literal"><span class="pre">float</span></code> or <code class="docutils literal"><span class="pre">double</span></code>.</li>
<li>The <code class="docutils literal"><span class="pre">data_layout_</span></code> is useful for some computational library. One example is that MKLDNN uses many kinds of layout, such as <code class="docutils literal"><span class="pre">nChw8c</span></code>. Each kind of layout will invoke the different kernel.</li>
<li>The <code class="docutils literal"><span class="pre">library_type_</span></code> describes the computational library, e.g., <code class="docutils literal"><span class="pre">MKLDNN</span></code>, <code class="docutils literal"><span class="pre">CUDNN</span></code>.</li>
</ul>
</div> </div>
<div class="section" id="problem"> <div class="section" id="problem">
<span id="problem"></span><h1>Problem<a class="headerlink" href="#problem" title="永久链接至标题"></a></h1> <span id="problem"></span><h1>Problem<a class="headerlink" href="#problem" title="永久链接至标题"></a></h1>
...@@ -251,39 +255,63 @@ ...@@ -251,39 +255,63 @@
<li>Some operators will take too many memory. It is better to force them into CPU. However, the rest of operators in this neural network will be performed on GPU, i.e., model parallel problem.</li> <li>Some operators will take too many memory. It is better to force them into CPU. However, the rest of operators in this neural network will be performed on GPU, i.e., model parallel problem.</li>
<li>Some layout and place are particular. One example is that MKLDNN uses <code class="docutils literal"><span class="pre">nChw8</span></code> and there is no other library uses <code class="docutils literal"><span class="pre">nChw8c</span></code>.</li> <li>Some layout and place are particular. One example is that MKLDNN uses <code class="docutils literal"><span class="pre">nChw8</span></code> and there is no other library uses <code class="docutils literal"><span class="pre">nChw8c</span></code>.</li>
</ol> </ol>
<p>Problems under these situations are similar. We can formalise this problem as follow.</p> <p>Take one situation to give a detailed explanation, if we have two Operators: OP1 and OP2, OP1 has one output <code class="docutils literal"><span class="pre">op1_to_op2</span></code>, and <code class="docutils literal"><span class="pre">op1_to_op2</span></code> is the input of OP2.</p>
<p>If OP1 and OP2 run on the same place(for example CPUPlace), then <code class="docutils literal"><span class="pre">op1_2_op2</span></code> can be used directly by OP2.</p>
<div class="highlight-default"><div class="highlight"><pre><span></span><span class="n">OP1</span><span class="p">(</span><span class="n">CPUPlace</span><span class="p">)</span>
<span class="o">|</span>
<span class="n">op1_2_op2</span>
<span class="o">|</span>
<span class="n">OP2</span><span class="p">(</span><span class="n">CPUPlace</span><span class="p">)</span>
</pre></div>
</div>
<p>If OP1 and OP2 run one different place, then OP2 cannot <code class="docutils literal"><span class="pre">use</span> <span class="pre">op1_2_op2</span></code> directly.</p>
<p>Problems under these situations are similar. We can formalize this problem as follow.</p>
<p>We register kernels with types $KT = {kt_1, kt_2, kt_3, ...}$ for one operator. The inputs of this operator should be run on kernel type $kt_{?}$, which the $kt_{?} \notin KT$. How to cast the input of this operator from $kt_{?}$ to any of kernel type in $KT$.</p> <p>We register kernels with types $KT = {kt_1, kt_2, kt_3, ...}$ for one operator. The inputs of this operator should be run on kernel type $kt_{?}$, which the $kt_{?} \notin KT$. How to cast the input of this operator from $kt_{?}$ to any of kernel type in $KT$.</p>
</div> </div>
<div class="section" id="solution"> <div class="section" id="solution-data-transform">
<span id="solution"></span><h1>Solution<a class="headerlink" href="#solution" title="永久链接至标题"></a></h1> <span id="solution-data-transform"></span><h1>Solution: data transform<a class="headerlink" href="#solution-data-transform" title="永久链接至标题"></a></h1>
<p>It is clearly that transforming inputs of an operator toadapt another kernel type is not related to the particular operator. So we should register these transformation methods as global methods.</p> <p>It is clear that transforming inputs of an operator to adapt another kernel type is not related to the particular operator. So we should register these transformation methods as global methods.</p>
<p>We can infer a kernel type from the inputs of an operators. We let this kernel type as <code class="docutils literal"><span class="pre">actual</span> <span class="pre">kernel</span> <span class="pre">type</span></code>, which means this kernel type is the actually kernel type that operator should be performed.</p> <p>We can infer kernel type for each input of an operator. We let this kernel type as <code class="docutils literal"><span class="pre">actual</span> <span class="pre">kernel</span> <span class="pre">type</span> <span class="pre">for</span> <span class="pre">var</span></code>, which means this kernel type is the kernel type that can process this input variable.</p>
<p>We can get a kernel type by 1) The configuration of operator description. (Users may want to force use <code class="docutils literal"><span class="pre">MKL</span></code> for <code class="docutils literal"><span class="pre">conv</span></code> operator). 2) The place of the current executor. (Executor is running on GPU). This kernel type is what we expect the operator will be performed on. We let this kernel type as <code class="docutils literal"><span class="pre">expect</span> <span class="pre">kernel</span> <span class="pre">type</span></code>.</p> <p>We can get a kernel type by 1) The configuration of operator description. (Users may want to force use <code class="docutils literal"><span class="pre">MKL</span></code> for <code class="docutils literal"><span class="pre">conv</span></code> operator). 2) The place of the current executor. (Executor is running on GPU). This kernel type is what we expect the operator will be performed on. We let this kernel type as <code class="docutils literal"><span class="pre">expect</span> <span class="pre">kernel</span> <span class="pre">type</span></code>.</p>
<p>We transform the input data from <code class="docutils literal"><span class="pre">actual</span></code> to <code class="docutils literal"><span class="pre">expect</span></code> if the expect kernel type is not as same as actual kernel type.</p> <p>We transform the input data from <code class="docutils literal"><span class="pre">actual</span></code> to <code class="docutils literal"><span class="pre">expect</span></code> if the actual kernel type is not as same as expect kernel type.</p>
<p>The algorithm is described as follow</p> <p>The algorithm is described as following</p>
<div class="highlight-cpp"><div class="highlight"><pre><span></span><span class="k">using</span> <span class="n">DataTransformationFN</span> <span class="o">=</span> <span class="n">std</span><span class="o">::</span><span class="n">function</span><span class="o">&lt;</span><span class="kt">void</span><span class="p">(</span><span class="k">const</span> <span class="n">Tensor</span><span class="o">&amp;</span> <span class="n">in</span><span class="p">,</span> <span class="n">Tensor</span><span class="o">*</span> <span class="n">out</span><span class="p">)</span><span class="o">&gt;</span><span class="p">;</span> <div class="highlight-cpp"><div class="highlight"><pre><span></span><span class="kt">void</span> <span class="n">OperatorWithKernel</span><span class="o">::</span><span class="n">Run</span><span class="p">(</span>
<span class="k">using</span> <span class="n">KernelTypePair</span> <span class="o">=</span> <span class="n">std</span><span class="o">::</span><span class="n">pair</span><span class="o">&lt;</span><span class="n">KernelType</span><span class="p">,</span> <span class="n">KernelType</span><span class="o">&gt;</span><span class="p">;</span> <span class="k">const</span> <span class="n">Scope</span><span class="o">&amp;</span> <span class="n">scope</span><span class="p">,</span>
<span class="k">const</span> <span class="n">platform</span><span class="o">::</span><span class="n">Place</span><span class="o">&amp;</span> <span class="n">place</span><span class="p">)</span> <span class="k">const</span> <span class="p">{</span>
<span class="n">map</span><span class="o">&lt;</span><span class="n">KernelTypePair</span><span class="p">,</span> <span class="n">DataTransformationFN</span><span class="o">&gt;</span> <span class="n">g_data_transformation_</span><span class="p">;</span> <span class="n">ExecutionContext</span> <span class="n">ctx</span><span class="p">(...);</span>
<span class="k">auto</span> <span class="n">expected_kernel_key</span> <span class="o">=</span> <span class="k">this</span><span class="o">-&gt;</span><span class="n">GetExpectedKernelType</span><span class="p">(</span><span class="n">ctx</span><span class="p">);</span>
<span class="kt">void</span> <span class="n">OpWithKernel</span><span class="o">::</span><span class="n">Run</span><span class="p">()</span> <span class="p">{</span>
<span class="n">vec</span><span class="o">&lt;</span><span class="n">Tensor</span><span class="o">&gt;</span> <span class="n">inputs</span> <span class="o">=</span> <span class="p">...</span> <span class="n">Scope</span><span class="o">&amp;</span> <span class="n">new_scope</span> <span class="o">=</span> <span class="n">scope</span><span class="p">.</span><span class="n">NewScope</span><span class="p">();</span>
<span class="k">auto</span> <span class="n">actual_kernel_type</span> <span class="o">=</span> <span class="n">GetActualKernelType</span><span class="p">(</span><span class="n">inputs</span><span class="p">);</span>
<span class="k">for</span> <span class="p">(</span><span class="k">auto</span><span class="o">&amp;</span> <span class="nl">var_name</span> <span class="p">:</span> <span class="k">this</span><span class="o">-&gt;</span><span class="n">Inputs</span><span class="p">())</span> <span class="p">{</span>
<span class="c1">// The expected kernel type is related to actual kernel type.</span> <span class="k">auto</span><span class="o">*</span> <span class="n">tensor_in</span> <span class="o">=</span> <span class="n">GetTensor</span><span class="p">(</span><span class="n">var_name</span><span class="p">);</span>
<span class="c1">// For the most operators, the expected kernel type is as same as</span> <span class="k">auto</span> <span class="n">kernel_type_for_var</span> <span class="o">=</span> <span class="k">this</span><span class="o">-&gt;</span><span class="n">GetKernelTypeForVar</span><span class="p">(...);</span>
<span class="c1">// actual kernel type.</span> <span class="k">if</span> <span class="p">(</span><span class="n">kernel_type_for_var</span><span class="p">.</span><span class="n">place_</span> <span class="o">!=</span> <span class="n">expected_kernel_key</span><span class="p">.</span><span class="n">place_</span><span class="p">)</span> <span class="p">{</span>
<span class="c1">//</span> <span class="k">auto</span><span class="o">*</span> <span class="n">trans_var</span> <span class="o">=</span> <span class="n">new_scope</span><span class="p">.</span><span class="n">Var</span><span class="p">(</span><span class="n">var_name</span><span class="p">);</span>
<span class="c1">// So we pass `actual_kernel_type` as a parameter of </span> <span class="k">auto</span><span class="o">*</span> <span class="n">out</span> <span class="o">=</span> <span class="n">DataTransform</span><span class="p">(</span><span class="n">expected_kernel_key</span><span class="p">,</span>
<span class="c1">// GetExpectedKernelType</span> <span class="n">kernel_type_for_var</span><span class="p">,</span>
<span class="k">auto</span> <span class="n">expect_kernel_type</span> <span class="o">=</span> <span class="n">GetExpectedKernelType</span><span class="p">(</span><span class="n">actual_kernel_type</span><span class="p">);</span> <span class="o">*</span><span class="n">tensor_in</span><span class="p">);</span>
<span class="n">CopyVariableWithTensor</span><span class="p">(...);</span>
<span class="k">auto</span> <span class="n">trans</span> <span class="o">=</span> <span class="n">g_data_transformation_</span><span class="p">[{</span><span class="n">actual_kernel_type</span><span class="p">,</span> <span class="n">expect_kernel_type</span><span class="p">}];</span> <span class="p">}</span>
<span class="p">}</span>
<span class="n">kernel</span><span class="p">.</span><span class="n">run</span><span class="p">(</span><span class="n">trans</span><span class="p">(</span><span class="n">inputs</span><span class="p">));</span>
<span class="k">auto</span> <span class="n">kernel</span> <span class="o">=</span> <span class="n">kernels</span><span class="p">.</span><span class="n">find</span><span class="p">(</span><span class="n">expected_kernel_key</span><span class="p">);</span>
<span class="n">kernel</span><span class="o">-&gt;</span><span class="n">Compute</span><span class="p">(</span><span class="n">ExecutionContext</span><span class="p">(...));</span>
<span class="p">}</span> <span class="p">}</span>
</pre></div> </pre></div>
</div> </div>
<p>then the actual process for the multi-device above will be:</p>
<div class="highlight-default"><div class="highlight"><pre><span></span><span class="n">OP1</span><span class="p">(</span><span class="n">CPUPlace</span><span class="p">)</span>
<span class="o">|</span>
<span class="n">op1_2_op2</span><span class="p">(</span><span class="n">on</span> <span class="n">CPU</span><span class="p">)</span>
<span class="o">|</span>
<span class="p">[</span><span class="n">transform</span><span class="p">](</span><span class="kn">from</span> <span class="nn">CPU</span> <span class="n">to</span> <span class="n">GPU</span><span class="p">)</span>
<span class="o">|</span>
<span class="n">op1_2_op2</span><span class="p">(</span><span class="n">on</span> <span class="n">GPU</span><span class="p">)</span>
<span class="o">|</span>
<span class="n">OP2</span><span class="p">(</span><span class="n">CUDAPlace</span><span class="p">)</span>
</pre></div>
</div>
</div> </div>
......
develop/doc_cn/searchindex.js
浏览文件 @ 42fdd3fa
因为 它太大了无法显示 source diff 。你可以改为 查看blob。
Markdown is supported
0% 或 .
You are about to add 0 people to the discussion. Proceed with caution.
先完成此消息的编辑！
想要评论请 注册 或