File vec5.c
void vec5(int* a, int n)
{
int i;
for(i=0;i<n;i++)
a[i] = a[i-1];
}

对上面这个例子， 由于存在flow-dependence关系， 程序中的循环明显是不能被向量化的。

vec5.c
C:\test\vec5.c(6) (col. 2): remark: loop was not vectorized: existence of vector dependence.
C:\test\vec5.c(7) (col. 3): remark: vector dependence: assumed FLOW dependence between a line 7 and a line 7.
此时我们加上#pragma ivdep想让编译器忽略循环之间的依赖关系(当然这种操作是不符合原始语义的)。

void vec5(int* a, int n)
{
int i;
#pragma ivdep
for(i=0;i<n;i++)
a[i] = a[i-1];
}

这时编译该程序， 程序的输出与不加#pragma ivdep时相同。 编译器在进行编译的时候检查发现了循环之间不可避免的依赖关系， 即使有#pragma ivdep存在， 编译器也还是不会对该循环进行向量化。
如果我们加上#pragma simd， 重新编译程序:

void vec5(int* a, int n)
{
int i;
#pragma simd
for(i=0;i<n;i++)
a[i] = a[i-1];
}

这时编译输出:

vec5.c
C:\test\vec5.c(6) (col. 2): remark: SIMD LOOP WAS VECTORIZED.

程序中的循环被向量化了， 但是此时我们显然不会得到一个正确的结果。
我们再看一个用SIMD的正确的例子。 比如下面这个程序：

void vec5(int* a, int n, int m)
{
int i;
for(i=0;i<n;i++)
a[i] = a[i-m];
}

编译该程序: icl /O2 /c /Qvec_report:3, 编译器会报告该程序因为存在向量依赖关系而不能被向量化。在该程序中， 如果我们可以保证m大于等于4， 那么我们可以加入#pragma simd指示如下所示：

void vec5(int* a, int n, int m)
{
int i;
#prgama simd
for(i=0;i<n;i++)
a[i] = a[i-m];
}

此时编译该程序可以得到正确的自动向量化的代码。

SIMD的支持可以使得程序员可以更自由的控制程序中的向量化。 相比其他编译指示来说， SIMD提供更丰富的语法来满足程序员在各种条件下的向量化处理。 如果你发现现有的编译指示如法满足语义的需要或者向量化性能无法满足期望， 你可以尝试使用SIMD指示。 但是由于SIMD是有程序员来保证程序向量化语义的正确性， 在自由使用的同时，程序员需要很小心的检查程序的语义以保证程序的正确性。
关于SIMD编译指示的详细使用， 请参考其他文档。

Optimization Notice
Intel® Compiler includes compiler options that optimize for instruction sets that are available in both Intel® and non-Intel microprocessors (for example SIMD instruction sets), but do not optimize equally for non-Intel microprocessors. In addition, certain compiler options for Intel® Compiler are reserved for Intel microprocessors. For a detailed description of these compiler options, including the instruction sets they implicate, please refer to "Intel® Compiler User and Reference Guides > Compiler Options". Many library routines that are part of Intel® Compiler are more highly optimized for Intel microprocessors than for other microprocessors. While the compilers and libraries in Intel® Compiler offer optimizations for both Intel and Intel-compatible microprocessors, depending on the options you select, your code and other factors, you likely will get extra performance on Intel microprocessors.

While the paragraph above describes the basic optimization approach for Intel® Compiler, with respect to Intel's compilers and associated libraries as a whole, Intel® Compiler may or may not optimize to the same degree for non-Intel microprocessors for optimizations that are not unique to Intel microprocessors. These optimizations include Intel® Streaming SIMD Extensions 2 (Intel® SSE2), Intel® Streaming SIMD Extensions 3 (Intel® SSE3), and Supplemental Streaming SIMD Extensions 3 (Intel® SSSE3) instruction sets and other optimizations. Intel does not guarantee the availability, functionality, or effectiveness of any optimization on microprocessors not manufactured by Intel. Microprocessor-dependent optimizations in this product are intended for use with Intel microprocessors.

Intel recommends that you evaluate other compilers to determine which best meet your requirements.

自动向量化是英特尔编译器提供的一个可以自动的使用SIMD指示的功能。 在处理数据时， 编译器自动选择MMX™, Intel® Streaming SIMD 扩展（Intel® SSE, SSE2, SSE3 和SSE4）等指令集， 对数据进行并行的处理。 使用编译器提供的自动向量化功能是提高程序性能的一个非常有效的手段。自动向量化在IA-32和Intel® 64的平台上均提供很好的支持。

英特尔编译器提供的自动向量化相关的编译选项如下所示。”/Q”开头的选项是针对Windows平台的， “-“开头的选项是针对Linux*和Mac平台的。

-x, /Qx
按照该选项指定的处理器类型生成相应的优化代码。 比如-xSSE3, 该选项指定编译器生成Intel® SSE3指令的代码。 又比如-xSSE3_ATOM, 该选项针对Intel® Atom™ 处理器进行优化。
-ax, /Qax
如果指定该选项， 在生成的单一目标文件中， 不但会生成专门针对指定的处理器类型进行优化的代码， 同时也生成通用的IA-32架构的代码。 该选项主要是为了生成代码的兼容性考虑。

-vec, /Qvec
打开或者关闭编译器的向量化优化。 默认情况下自动向量化是打开的。

-vec-report, /Qvec-report
该选项用户控制在编译过程中产生的向量化消息报告。

编译器提供的自动向量化优化默认情况下是打开的。 在编译过程中我们可以使用-vec-report选项来打开向量化诊断消息报告。 这样编译器可以告诉我们有哪些循环被向量化了， 有哪些循环没有被向量化已经无法向量化的原因。

在编译程序的过程中， 有时候我们会发现编译器报告说某个循环无法被向量化。 很多时候无法向量化的原因都是因为循环中存在的变量依赖关系。 有时候我们可以修改程序来消除这种依赖关系，有的时候我们可以使用编译器提供的一些编译指示来显示的告诉编译器如何处理这种依赖关系。 即使在某个循环已经可以被自动向量化的时候， 使用编译器提供的对向量化的语言支持和编译指示还可以提高编译器向量化的效率， 提高程序执行的性能。

下面我们来详细解释一下编译器提供的编译指示以及这些指示对编译器编译的影响。

在Intel编译器中， 我们提供下面这样一些对自动向量化的语言支持和编译指示。

__declspec(align(n))
指导编译器将变量按照n字节对齐
__declspec(align(n,off))
指导编译器将变量按照n字节再加上off字节的编译量进行对齐
restrict
消除别名分析中的二义性
__assume_aligned(a,n)
当编译器无法获取对齐信息时，假定数组a已经按照n字节对齐

#pragma ivdep
提示编译器忽略可能存在的向量依赖关系
#pragma vector {aligned|unaligned|always}
指定向量化的方式
#pragma novector
指定不做向量化

下面我们就这些编译指示做一些详细的了解。

• __declspec(align(n))

首先我们来看看如何使用__declspec(align(n))来进行自动向量化。该指示主要是用来告诉编译器一个变量的对齐方式。 当一个变量的对齐方式为16字节对齐时， 生成的向量化指令是最高效的。 当编译器不知道一个变量的对齐方式的时候， 他可能没有办法对该变量的使用进行向量化， 或者编译器会不得不生成条件语句来进行有条件的向量化。 我们来看一下下面这个例子。

File: vec1.c
char a[];
void vec1(void)
{
int i;
for(i=0;i<1024;i++)
a[i] = 1;
}

使用下面命令编译该程序:
icl vec1.c -O2 -c /Qvec-report:3
这时编译器输出：

vec1.c
vec1.c(10) (col. 2): remark: LOOP WAS VECTORIZED.

我们可以看到编译器对上面这个程序进行了自动向量化。 但是实际上， 由于编译器不知道a的对齐字节数， 所以他对变量a数据进行了一些条件处理。 我们可以在编译的时候加上-S选项来查看编译器生成的汇编代码。 实际上， 编译器对该程序做了如下处理：

temp = a&0x0f;
if(temp != 0)
{
temp = 16-temp;
for(i=0;i<temp;i++) a[i] = 1;
}
/*下面是对齐的访问*/
for(i=temp;i<1024;i++) a[i] = 1;

如果我们指定了a的对齐方式， 比如我们使用__declspec(align(16))来定义变量a, 如下所示：

__declspec(align(16)) char a[];
void vec1(void)
{
int i;
for(i=0;i<1024;i++)
a[i] = 1;
}

对于上面这段程序， 编译器做了自动向量化。 如果我们检查生成的汇编代码可以发现，对于a的对齐方式的条件处理代码已经不见了。
正确使用__declspec(align(n))以及其他align相关编译指示可以帮助编译器进行自动向量化以及提高编译器自动向量化的效率。

• restrict

使用restrict关键字可以显式的告诉编译器取消指针之间的二义性。 我们还是用下面这个例子来说明restrict的使用。

File: vec2.c

void vec2(char* a, char* b, int n)
{
int i;
for(i=0;i<n;i++)
a[i] = b[i];
}

使用以下命令进行编译：
icl vec2.c -O2 -c /Qvec-report:3
编译器输出：

vec2.c
restrict.c(5) (col. 2): remark: LOOP WAS VECTORIZED.
restrict.c(5) (col. 2): remark: loop skipped: multiversioned.

此时编译器输出multiversioned向量化代码， 对同一个循环产生了多个版本的实现。实际上编译器对代码进行了条件处理， 如下所示：

void vec2(char* a, char* b, int n)
{
int i;
if(a+n<b || b+n<a)
for(i=0;i<n;i++) a[i] = b[i]; /*向量化循环*/
else
for(i=0;i<n;i++) a[i] = b[i]; /*串行循环*/
}

可以看出，由于编译器不知道指针a 和b之间是否存在重叠， 所以他对循环进行了条件处理。 如果我们从语义上能够保证a和b是不会发生重叠的， 那么我们就可以使用restrict关键字来显式的告诉编译器这一点。

void vec2(char* restrict a, char* restrict b, int n)
{
int i;
for(i=0;i<n;i++)
a[i] = b[i];
}

此时编译器输出没有multiversioned。

restrict.c
restrict.c(5) (col. 2): remark: LOOP WAS VECTORIZED.

注意C90里面不支持restrict关键字， 在windows平台编译的时候我们需要加上选项/Qrestrict来让编译器认识restrict关键字。

• #pragma vector

使用#pragma vector编译指示来显式告诉编译器使用某种方式来进行自动向量化。 比如在下面这个例子中， 我们可以保证变量a的地址是16字节对齐的，那么我们就可以使用#pragma vector aligned来显式的告诉编译器不需要考虑非对齐的情况。这样产生的向量化代码是最高效的。

File: vec3.c
#include <malloc.h>
void vec3(void)
{
int i;
char* a=_aligned_malloc(1024, 16);
#pragma vector aligned
for(i=0;i<1024;i++)
a[i] = 1;
}

在上面这个例子中， 如果我们不加上#pragma vector aligned, 编译器会对循环进行条件处理后的向量化。 大家可以对比一下两种情况下生成的汇编代码的区别。请注意我们在使用#pragma vector aligned的时候需要保证被处理变量的对齐方式是16字节对齐的， 否则在使用了该编译指示后可能会产生错误的结果。在上面这个例子中， 我们稍作如下修改：

#include <malloc.h>
void vec3(void)
{
int i;
char* a=_aligned_malloc(1024, 16);
char* b = a+1;
#pragma vector aligned
for(i=0;i<1023;i++)
b[i] = 1;
}

循环中的b的地址不是16字节对齐的， 但是如果我们还是按照aligned的方式来做向量化， 产生的结果是编译出来的可执行程序运行时异常。 在上面的例子中， 我们需要使用#pragma vector unaligned 编译指示来正确的引导编译器。

• #pragma ivdep

使用#pragma ivdep显式的告诉编译器忽略向量之间可能存在的依赖关系。参考下面这个例子。

File: vec4.c
void vec4(int* a, unsigned int n, unsigned int m)
{
int i;
for(i=0;i<n;i++)
a[i] = a[i+m];
}

使用编译器编译该程序：
icl vec4.c –O2 -c /Qvec-report:3
编译器输出：

vec4.c
vec4.c(6) (col. 2): remark: loop was not vectorized: existence of
vector dependence.
vec4.c(7) (col. 3): remark: vector dependence: assumed ANTI dependence between a line 7 and a line 7.
vec4.c(7) (col. 3): remark: vector dependence: assumed FLOW dependence between a line 7 and a line 7.
vec4.c(7) (col. 3): remark: vector dependence: assumed FLOW dependence between a line 7 and a line 7.
vec4.c(7) (col. 3): remark: vector dependence: assumed ANTI dependence between a line 7 and a line 7.

如果我们可以保证a[0]到a[n-1]和a[m]到a[m+n-1]之间不存在重叠， 那么我们就可以使用#pragma ivdep来显式的告诉编译器可以忽略a[i]和a[i+m]之间的依赖关系， 修改程序如下:

void vec4(int* a, unsigned int n, unsigned int m)
{
int i;
#pragma ivdep
for(i=0;i<n;i++)
a[i] = a[i+m];
}

这样程序中的循环就可以被自动向量化了。

英特尔编译器提供了强大的自动向量化支持，并且对自动向量化的优化也一直在进行之中。 在新版本的编译器中， 我们可以看到更多的自动向量化有关的支持。 更多的内容请参考后续博客更新。

SIMD 向量化是英特尔编译器12.0版支持的一个新功能。 该向量化使用 #pragma simd (c/c++) 或者 !DIR$ SIMD(fortran) 编译指示来有效地实现循环向量化。该向量化语法如下所示：

#pragma simd [clause[ [,] clause]...]

在#pragma simd之后可以带一些字句来让编译器得到更多的信息以便做更好的优化。 这些字句可以是：

vectorlength (vl_list)
private (expr_list, expr)
linear (var_step_list)
reduction (oper_var_list)
[no]assert

在本文中， 我们针对vectorlength子句来进行一些讨论。

vectorlength(num1, num2, …, numN)

vectorlength (简称VL) 用来指导向量优化单元从指定的若干向量长度num1, num2, … , numN中选择某个长度来进行向量化。对于选定的VL，向量循环的每一次执行的计算工作相当于原来标量循环VL次执行的计算工作。多个向量长度子句会合并成一个集合， 编译器从这些指定的长度中选择某个针对目标机器的最优长度进行向量化。
看下面这个例子。

void foo(int* a, int* b)
{
#pragma simd vectorlength(4)
#pragma nounroll
for(int i=0;i<1024;i++)
{
a[i]=b[i];
}
}

在支持128bit向量长度的机器上， 编译器生成相应的SSEx指令来向量化上面程序中的循环。 用户指定的VL是4， 理论上说， 一次向量循环相当于4次标量循环。 在上面这个例子中， 每次向量操作的长度正好是32*4=128bit。理论上的向量循环次数为1024/4=256次。如果我们指定VL为8， 理论上说编译器在一次向量循环中会做两次128位的向量操作， 相当于做了256位(32*4+32*4)的向量操作， 对应的循环次数为1024/8=128次。 当然，如果我们不加上编译指示#pragma nounroll来阻止编译器的loop unroll优化，编译器会进行循环展开优化， 这样实际的循环次数可能更少。

在上面的例子中， 如果我们指定多个VL， 比如#pragma simd vectorlength(4,8)。编译器会根据目标机器的向量长度和其内部的cost-modeling计算选择最优的VL。

Vectorlength 不是必须指定的。 如果没有指定vectorlength, 一般情况下编译器会根据目标机器的向量长度和标量循环的变量类型来选择合适的VL。 那我们在什么情况下需要指定vectorlength呢？ 一般情况下， 这需要根据程序的语义和对性能的要求来决定。 比如下面这个例子。

void foo(double a*, double * b, int m, int n)
{
for(int i=n; i<m;i++)
{
a[i] = b[i];
}
}

我们要对该例子中的循环进行向量化。 但是如果a 和 b存在别名关系, 比如a = b+n, 那么我们就无法通过restrict关键字来向量化上面这个循环。 如果我们的程序语义可以保证n一定满足: n=2 或者n=3, 那么我们就可以通过simd来向量化这个循环。 比如加上#pragma vectorlength(2). 这样在支持SSEx的目标机器上， 可以做到128bit的循环向量化。 在支持AVX的目标机器上， 默认情况下的向量化长度是256bit的， 所以如果没有VL为2的指定， 那么编译器可能会生成256bit的向量化循环， 对应的VL为4， 在这种情况下这样的向量化是不符合程序的语义的， 也就会产生运行时错误。 所以我们需要显式指定vectorlength(2)来满足语义的需要。

Vectorlength的值一定是2的幂次方。 不同类型的数据针对不同的目标机器有不同的VL的范围。 比如对于支持128bit SSEx的机器来说， char类型操作的VL为16， short类型可以为8或16， int类型则可以为4，8，16。 如果指定了不合适的VL， 编译器会报告一个warning， 同时放弃对应的向量化操作。

Optimization Notice
Intel® Compiler includes compiler options that optimize for instruction sets that are available in both Intel® and non-Intel microprocessors (for example SIMD instruction sets), but do not optimize equally for non-Intel microprocessors. In addition, certain compiler options for Intel® Compiler are reserved for Intel microprocessors. For a detailed description of these compiler options, including the instruction sets they implicate, please refer to "Intel® Compiler User and Reference Guides > Compiler Options". Many library routines that are part of Intel® Compiler are more highly optimized for Intel microprocessors than for other microprocessors. While the compilers and libraries in Intel® Compiler offer optimizations for both Intel and Intel-compatible microprocessors, depending on the options you select, your code and other factors, you likely will get extra performance on Intel microprocessors.

While the paragraph above describes the basic optimization approach for Intel® Compiler, with respect to Intel's compilers and associated libraries as a whole, Intel® Compiler may or may not optimize to the same degree for non-Intel microprocessors for optimizations that are not unique to Intel microprocessors. These optimizations include Intel® Streaming SIMD Extensions 2 (Intel® SSE2), Intel® Streaming SIMD Extensions 3 (Intel® SSE3), and Supplemental Streaming SIMD Extensions 3 (Intel® SSSE3) instruction sets and other optimizations. Intel does not guarantee the availability, functionality, or effectiveness of any optimization on microprocessors not manufactured by Intel. Microprocessor-dependent optimizations in this product are intended for use with Intel microprocessors.

Intel recommends that you evaluate other compilers to determine which best meet your requirements.

http://software.intel.com/en-us/blogs/2010/06/15/introducingconcurrent-collections-for-distributed-memory-systems-distcnc/

下载试用CnC请访问：

http://software.intel.com/en-us/articles/intel-concurrent-collections-for-cc/

这3个元素其实也是我们在开发一般程序的时候需要考虑的问题。 根据这3个元素， 我们就可以构造一个程序的流程图(Graph). 这个Graph的实质就是在描述数据依赖关系和控制依赖关系。举个例子来说， 在我们的程序里面我们可以有这样一些元素：
Item Data: [I1], [I2]
Step function: (S1), (S2)
Tag: ,
那么我们可以这样描述我们的程序：
::(S1) 只有当Tag 准备好的时候， S1才可以被执行
::(S2) 只有当Tag 准备好的时候， S2才可以被执行
[I1]-> (S1) -> [I2], ->(S2)
数据[I1]输入给function (S1), (S1)在执行完后生成数据[I2], 并且生成Tag 。
实际上， 在这个例子中， 我们就是在用文本的方式来描述我们的程序流程图：
[I1]-->(S1)-->[I2]-->(S2)
只是在模块S1和模块S2之间， 我们用T2来控制S1 和S2之间的Control Dependence. 那么S2什么时候开始执行呢？ 根据这个关系我们知道， 当S1执行完成生成Tag 后， S2就被调度到线程池。 当数据I2准备好之后， S2就可以开始真正执行了。
当我们把上述关系用文本的方式记录在一个文件中后， 我们就可以开始CnC编程了。
下面这个图描述了CnC这种并行编程模式。

用户在定义好文本方式的关系图后， CnC中的Translator会把它转换成一个C++头文件以及一个C++程序提示文件。 在C++程序提示文件里面定义好了系统的框架， 用户需要做的大部分工作就是往这些具体的功能模块里面填写具体的程序代码即可。在程序开发完成后， 编译器会自动链接一个CnC的Runtime库， 生成最终的应用程序。 当然， 这个应用程序是真成的多线程并行应用程序。
CnC支持各种形式的并行开发，比如Data, Task, 和Pipeline Parallel. 目前CnC同时提供Windows 版和Linux版。 在Windows 版本下， CnC可以嵌入Visual Studio 中， 用户可以在Visual Studio的框架下开发基于CnC的并行程序。
下载和使用CnC或者想要了解更多的关于CnC的信息， 请访问网站: http://software.intel.com/en-us/articles/intel-concurrent-collections-for-cc/

对于该段程序来说， 他可以串行的执行， 也可以有多个线程并行的执行。 如上图所示， 在A点， 我们衍生出一个新的任务(3)。 这里稍微解释一下， 我们把这种情况下的任务(3)叫子任务(Child), 把任务(2)叫后续任务(Continuation)。 在大多数的文档里面， 我们都保持这个命名规则。
在上述程序中，如果是串行的执行，各个任务的执行顺序如下图所示：

该执行次序完全保证了串行的语义。 假设有2个工作线程(I)和(II)， 那么执行的次序可以用下图来描述。

当前线程(I)在执行到A点时衍生出新的任务（3）。 该线程(I)会保存当前执行状态， 然后继续执行子任务（3）。 Intel® Cilk™ Plus线程调度发现此时线程(II)空闲, 就会激活线程(II)去密取(steal)线程(I)的后继任务（2）来执行。 两个工作线程在B点进行同步(cilk_sync)。 同步后线程(I)继续执行任务(4)。 这种工作调度模式我们就称之为工作密取。
在Intel® Cilk™ Plus中我们使用工作密取方式进行多任务调度。 除了工作密取方式， 在多线程调度中还经常采用工作共享(work sharing)方式调度。 在工作共享方式中， 当线程产生新的工作子任务时， 调度程序会转移一些子任务到别的工作线程以期望使用当前空闲处理器来处理这些任务。 而在工作密取方式中， 空闲的处理器采取主动出击的办法， 通过”秘密偷取”的方式来得到可以执行的任务。 从概念上来说， 工作密取方式要比工作共享方式高效。 比如当程序有足够的并行度的时候， 也就说当所有处理器都有工作在执行的时候， 工作密取方式下不会发生任务的转移（从一个处理器到另一个处理器的任务转移）， 而工作共享方式总是会产生这种转移。因而相比工作共享方式， 工作密取方式会有较少的通讯和同步的开销。关于这两种调度模式更进一步的对比， 请参考相关的技术文档。 这里不再讨论。总之， 在Intel® Cilk™ Plus中采用的是一种高效的工作密取调度。
工作密取的调度方式自动保证了各个处理器之间的负载平衡。当一个处理器空闲的时候， 它会主动获取新的工作任务。 当程序的并行度足够高的时候， 每个处理器都不会空闲下来。
工作密取是有一定的开销的， 因为它涉及到一个工作任务的转移， 这必然带来通讯和同步的开销。 但是在Intel® Cilk™ Plus中， 大多数的衍生都不会导致工作密取的发生。 在我们的程序设计中， 我们应该尽量保证处理任务的在各个处理器上的平衡。 这种负载的分配越是平衡， 就会产生越少的工作密取， 因而带来的密取开销也越少。

我们知道， cilk_spawn衍生出一个新的可以并行执行的任务。 这时可以分为密取发生和不发生两种情况。 当密取不发生的时候， 如下图所示， 此时的程序执行是串行的， 没有新的线程来并行执行， 也就没有新的Reducer 视图被创建。

当密取行为发生的时候，如下图所示， 此时在A点， 我们的主线程(I)有一个Reducer的当前执行视图(V1)， 线程(I)执行strand (3), strand(3)中使用的视图就是V1. 另一线程(II)密取工作strand (2), 这时strand(2)会得到一个新的Reducer视图(V2)。新生成的V2拥有Reducer的恒等值(identity value)， strand(2)基于该V2进行操作。 在B点进行Reducer同步的时候， 新生成的V2与原来的视图V1进行合并。 合并后， V2被注销。 strand(4) 继续基于V1进行操作。

理论上说， 我们可以理解为每个strand都有一个reducer的私有视图。 然而基于性能的考虑， 视图的产生是延迟的(Lazy semantics)。并不是每一次的衍生调用都会有新的视图的生成。新视图的创建了必须符合下面两个条件:
1. 首先，新的视图的创建必须在密取行为发生之后。 如果密取行为没有发生， 程序的执行其实是线性的。 这时就没有必要产生新的视图。
2. 其次， 只有在新的strand里面首次存取reducer的时候， 新的视图才会被创建。 也就是说， 当密取行为发生后， 视图也不是马上被创建出来的。 如果在新的strand里面没有基于reducer的存取操作， 那么我们是没有必要产生新的reducer视图的。 如果新的strand里面有对reducer的存取操作， 那么在首次存取该reducer的时候， 系统才会在该存取点创建新的视图实例。
如果新的视图被创建， 他会在cilk_sync点与先前的视图进行合并。 如果没有新的视图生成， 合并是不必要的。