我的presentationQ?br />http://docs.google.com/Presentation?id=dcjk4xx7_473cv5ddgc8
Z旉考虑没有提到paper中进E间通信的解x?br />
]]>
]]>
]]>
]]>
]]>
]]>
Brook本n的不缺陗bugQ加上不习惯U学计算E序的代码风|D大多数时间都在fix bug?br />
其中de掉以后最有快感的一个bugQ（只能q么形容?>,<Q?br />
每个cell都有一个flag|管cd是doubleQ但是程序中是用一个MAGIC_CAST宏把它当作整型处理的?br />初始情况Q每个cell的flag都ؓ~fQ也是一?~28位都?Q?9~32位ؓ0的double型Q炏V根据IEEE标准Q应该是个NaN?br />CPU上没有问题，攑ֈGPU上问题就出来了，GPU不支持这U{型操作，在对q个double型进行运操作的时候，所有结果都会变成NaN?br />
解决ҎQ?br />在把数据传给GPU之前可以先把q些flagD{换ؓGPU可以操作的double型，最单的Ҏ是都先转成intQ会有truncatingQ，然后取反Q再传给GPU?br />
]]>
]]>
by Bingsheng He @ Hong Kong Univ. of Sci. & Tech.
Nage K. Govindaraju @ Microsoft Corp.
Qiong Luo, Tuyong Wang @ Sina Corp.
一些重Ҏ讎ͼ
1. Introduction
Three challenges in implementing the MapReduce framework on the GPU:
First, the synchronization overhead in the run-time system of the framework must be low.
Second, a fine-grained load balancing scheme is required.
Third, the core tasks of MapReduce, including string processing, file manipulation and concurrent reads and writes, are unconventional to GPUs and must be handled efficiently.
Each thread is responsible for a Map or a Reduce task with a small number of key/value pairs as input.
Performance improvement: 1.5-16 times
2. Priliminary and Related Work
2.1. Graphics Processors
It is desirable to schedule the tasks between the CPU and the GPU to fully exploit their computation power.
Given a kernel program, the occupancy of the GPU is the ratio of active schedule units to the maximum number of schedule units supported on the GPU.
The GPU has a hardware feature called coalesced access to exploit the spatial locality of memory accesses among threads.
2.2. GPGPU
2.3. MapReduce
Map: (k1, v1) -> (k2, v2)*
Reduce: (k2, v2*) -> v3*
3. Design and Immplementation
3.1. Design Goals
3.2. System Workflow and Configuration
3.3. APIs
3.4. Implementation Techniques
Based on this compilation information and the total computation resources on the GPU, we set the number of threads per thread group and the number of thread groups to achieve a high occupancy at run time.
4. Evaluation
4.1. Experimental Setup
]]>
The GPU Memory Model
通常使用二维的texture保存Q一是因Zltexture能存攄东西很少Q二是因为现在的GPU很难高效地写入一?ltexture?br />Iteration
stream~程模型包含了一U隐式的的q行遍历。 ?br />Generalized Arrays via Address Translation
在GPGPU~程中主要用的数据l构是随问的多位容器Q包括稀?E密数组{。每个结构定义了一个虚拟域virual grid domain和一个物理域physical grid domaiinQ以及之间相互{换的address translator?br />
4.2.1. Dense Arrays
多维数组通常先映到一l_然后再到二维?br />4.2.2. Sparse Arrays
Ҏ非零元素的位|和数量是否变化分两U，静态和动态?br />4.2.3. Adaptive Structures
]]>
4.1.1. Map
Given a stream of data elements and a function, map will apply the function to every element in the stream.
4.1.2. Reduce
Sometimes a computation requires computing a smaller stream from a larger input stream, possibly to a single element stream. This type of computation is called a reduction. For example, computing the sum or maximum of all the elements in a stream.
On GPUs, reductions can be performed by alternately rendering to and reading from a pair of textures.
也就是用分治法，不断切换输入和输出数据，每次都能减少一定比例的数据规模?br /> 4.1.3. Scatter and Gather
If the write and read operations access memory indirectly, they are called scatter and gather respectively.
4.1.4. Stream Filtering
This stream fitering operation is essentially a nonuniform reduction.
4.1.5. Sort
Classic sorting algorithms are data-dependent and generally require scatter operations.
主要的几个算法都和Sorting Network有关Q还有一Uadaptive sortQ和原来序列的有序度相关?br /> 4.1.6. Search
4.2. Data Structures
]]>
2.4.1 Hardware Machanisms for Flow Control
三种主要实现Q?
Predication q真正的data-dependent branch
MIMD branching
SIMD branching 同时q行的指令唯一Q即各个点的分支选择应该一?
2.4.2 Moving Branching Up The Pipeline
2.4.2.1 Static Branch Resolution
静态分析，避免循环内部的分支。这里D了一个在LI间Ҏ(discrete spatial grid)上解偏微分方E的例子Q不q没怎么看懂Q大致是把@环拆成两部分的做法?
2.4.2.2 Pre-computation
有时候一D|间内或者几ơ@环中某个分支的结果会是一个常数。这时候就只要在知道结果会改变的时候重新计即可?
2.4.2.3 Z-Cull
CGPU有一pd用于避免处理不会被看到的像素的技术，其中之一是Z-cull。简单的说Z-cull把没有通过深度试QZ轴覆盖）点直接放弃。在体模拟中，把land-locked障碍单元的Z深度标记?Q即可蟩q这些点的计?
2.4.2.4 Data-Dependent Looping With Occlusion Queries
同样是避免处理不可见的点的技?
3 Programming Systems
GPU的架构发展非常迅速，使得profiling和tuning需要由GPU生商解冟?
3.1 High-level Shading Languages
Cg, HLSL 和底层硬件很接近
OpenGL Shading Language 有一些不直接映射到硬件的Ҏ，比如整数支持
Sh, Ashli, ...
3.2 GPGPU Languages and Libraries
上面提到的几个语a在用时都要求编Eh员站在几何元素的视角写代码。下面的几个pȝ试着把一些GPGPU功能抽象出来Q隐藏底层的GPU实现?br /> Brook 前几星期打过交道的东?br /> Scout, Glift 都没听说q。。?br /> 3.3 Debugging Tools
GPU的调试功能很受局限。它必须提供在某一时刻昄多个点的调试信息的功能。一Uprintf-style的方法是把他们直接显C在屏幕上（汗，如果是GPGPU~程岂不是花屏了 >,<Q?
]]>
A Survey of General-Purpose Computation on Graphics Hardware
on EUROGRAPHICS 2005
1. Why GP-GPU?
1.1 Powerful and Inexpensive
高内存带宽：Nvidia GeForce 6800 Ultra - 35.2GB/sec
强大的计能力：ATI X800 XT - 63GFLOPS, Intel Pentium4 SSE unit(3.7GHz) - 14.8GFLOPS
端处理U技的应用：最新公?指该survey发布的时?的GPU包含三亿个晶体管Q由0.011微米技术制?br /> 快速发展：GeForce 6800的throughput?900的两倍。通常GPU的计能力^均每q增镉K度?.7x(pixels/second)?.3x(vertices/second)Q而根据摩定律，CPU的对应数值大概ؓ每年1.4x。粗略的_GPU性能每六个月增长一倍?
1.2 Flexible and Programmable
1.3 Limitations and Difficulties
GPU的强大计性能是徏立在它高度针对的架构上的Q因此很多应用都不适合攑ֈGPU上做。比如文字处理，主要包括内存通信Q而且很难q行化?br /> 如今的GPU也缺一些基本的计算功能Q比如整数运。而且很多只支?2位QҎQ貌似最q的R670指o集可以处理doublecd了）Q这样导致很多科学计都没法在GPU上做?br /> 另外即对于适合GPUq些Ҏ的问题Q真正用GPU做时也有不少问题。GPU的编E模型很不一P高效的GPU~程不仅仅是说多学一门高U语a。如今要借助GPU的计能力，需要编Eh员同时掌握相应的U学计算知识和计机囑Ş学知识。尽如此，GPUҎ能提升的帮助还是很׃h的?br />
1.4 GPGPU Today
http://gpgpu.org
一些GPGPU的应用包?br /> Dense and sparse matrix multiplication 计算领域
Multigrid and conjugate-gradient solves for systems partial differential equations 计算领域
Ray tracing 囑փ处理
Photon mapping 囑փ处理
Fluid mechanics solvers 物理模拟
Datamining operations 数据?数据挖掘
2. Overview of Programmable Graphics Hardware
2.1 Overview of the Graphics Pipeline
当今的GPU都采用了UCؓgraphics pipeline的架构。pipeline被分成不同的stageQ硬件上每个stage都被攑ֈtask-parallel machine organization上实现?br />
2.2 Programmable Hardware
昑֍商们把固定功能的pipeline转化成了一个更灉|的可~程的pipeliine。主要在geometry stage和fragment stage。原来的固定的操作被用户定义的vertex program和fragment program代替
通常来说Q这些可~程阶段d一l含有限数量???2位Q点的向量 数组q输Zl含有限数量?*32点向量的数l。每个可~程阶段都可以访问常数寄存器Q也可以d对应的寄存器?br />
2.3 Introduction to the GPU Programming Model
典型的GPGPUE序都用了fragment processor作ؓ计算引擎。通常的结构ؓQ?br /> a. E序员确定该应用的ƈ行部分。应用程序被分成几个独立的可q行D，每段都被看成是一个kernelQ被当成fragment program实现。每个kernel的输入输出都是一个或多个数据数组Q以texture形式保存在GPU内存中。用相关的术语表述的话Q这些在texture中的数据l成了streamQ每个stream上的元素都要被kernel分别处理?br /> b. 调用kernel前要先确定计范_E序员可以传递点的数据给GPU。注意GPU在处理一l数l时性能有所局限?br /> c. rasterizer为每个像素生成一个fragment?br /> d. 每个fragment?strong>同一?/strong>zd的kernelE序处理。fragmentE序可以dL的全局内存Q但只能写到rasterizer军_的frame buffer中?strong>q块q没怎么搞懂
e. 每个fragment的输出是一个值或者向量|可以作ؓ作中的程序结果，也可以保存ؓ一个textureQ用于后面的计算Q复杂的应用通常需要多个pipeline之间的传?multipass)
]]>
]]>
Antialias
Q抗锯Q?/span>
虽然减小像素的大可以囑փ可以更加_Q一定程度上减轻了锯齿，但是只要像素的大大到可以互相彼此区分，那么锯的生是不可避免的！抗锯齿的Ҏ一般是多点Q注意此处是“点”而不是“像素”，后面可以看出它们间的区别Q采栗?/span>
一?span style="FONT: 7pt 'Times New Roman'">
理论与方法：
1
Q?/span>
Oversampling
Q重复取PQ?/span>
Q?/span>
1
Q方法：
首先Q将场景以比你的昄器（前缓Ԍ更高分L率进行渲染：
假设当前的（?/span>
/
后缓Ԍ的分辨率?/span>
800
×
600
Q那么可以先场景渲染到
1600
×
1200
的渲染目标上Q纹理）Q?/span>
然后Q从高分辨率的渲染目标得C分L率的场景渲染l果Q?/span>
此时取每
2
×
2
个像素块颜色的^均gؓ最l渲染的像素颜色倹{?/span>
Q?/span>
2
Q优点：可以显著地改善锯齿导致的q?/span>
Q?/span>
3
Q缺点：需要更大的~冲Q同时填充缓冲导致性能消耗变大；
q行多个像素的取PD性能下降Q?/span>
׃以上~点Q?/span>
D3D
q没有采用这U抗锯Ҏ?/span>
2
Q?/span>
Multisampling
Q多取样Q：
Q?/span>
1
Q方法：
只需要对像素q行一ơ取P而是在每个像素中?/span>
N
个点Q取决于具体的取h型）Q?strong style="mso-bidi-font-weight: normal">该像素的最l颜?/span>
=
该像素原先的颜色
*
多边形覆盖的Ҏ
/
ȝ取样ҎQ?/span>
Q?/span>
2
Q优点：可以改善锯带来的失真的同时而不会增加取h敎ͼ同时比v
Oversampling
它也不需要更大的后备~冲?/span>
Q?/span>
3
Q缺点：原本当一个多边Ş覆盖了一个像素的中心ҎQ该像素的颜色才会由该多边Ş军_Q在像素线阶段典型的就是寻址到合适的U理颜色与顶点管U输出的颜色q行调制Q，但是
Multisampling
中，如果该多边Ş覆盖了其中一部分取样点却未覆盖像素中心点Q该像素颜色仍然由此多边形决定。如此一来，U理d可能出现错误Q这对于U理集（
atlas
Q会出现另一U失真效果：多边形边~颜色错误！
3
Q?/span>
Centriod Sampling
Q质心采PQ?/span>
Q?/span>
1
Q方法：
Z解决在?/span>
Multisampling
D的在U理集中q行U理d带来的错误，不再采用像素中心的颜色作为?strong style="mso-bidi-font-weight: normal">该像素原先的颜色”，而是用?strong style="mso-bidi-font-weight: normal">该像素中被多边Ş覆盖的那些取L的中心点的颜?/span>”。这样就保证了被渲染的像素点始终是多边Ş的内部（也就是说U理地址不会出多边形的范围Q?/span>
Q?/span>
2
Q如何用：
①Q何有COLOR语义作ؓ输入?span lang="EN-US">Pixel Shader会自动运用质心采P
②在Pixel Shader的输入参数的语义后中手动加入 _centroid 扩展Q例如：
float4 TexturePointCentroidPS( float4 TexCoord : TEXCOORD0_centroid ) : COLOR0
{
return tex2D( PointSampler, TexCoord );
}
Q?/span> 3 Q注意：
质心采样主要用于采用U理集的 Multisampling Q对于一整张U理对应一个的多边形网格的情况Q采用质心采样反而会D错误Q?/span>
]]>
然后貌似龙书W二版里也讲了大量的IPA优化和call graph斚w的东西，啃啊?
]]>
VI.4. Interprocedural Analysis
Interprocedural Analysis (IPA) is performed in the following phases of Open64:
• Inliner phase
• IPA local summary phase
• IPA analysis phase
• IPA optimization phase
• IPA miscellaneous
By default the IPA does the function inlining in the inliner facility. The local summary phase is done in the IPL module and the analysis phase and optimization phase in the ipa-link module.
During the analysis phase, it does the following:
• IPA_Padding Analysis (common blocks Padding/Split Analysis)
• Construction of the Callgraph
Then it does space and multigot partitioning of the Callgraph. The partitioning algorithm takes into account whether it is doing partitioning for solving space or the multigot problem.
During the optimization phase the following phases are performed:
• IPA Global Variable Optimization
• IPA Dead function elimination
• IPA Interprocedural Alias Analysis
• IPA Cloning Analysis (It propagates information about formal parameters used as symbolic terms in array section summaries. This information is later used to trigger cloning.
• IPA Interprocedural Constant propagation
• IPA Array_Section Analysis
• IPA Inlining Analysis
• Array section summaries arrays for the Dependence Analyzer of the Loop Nest Optimizer.
]]>
GCC wiki:
Analysis and optimizations that work on more than one procedure at a time. This is usually done by making walking the Strongly Connected Components of the call graph, and performing some analysis and optimization across some set of procedures (be it the whole program, or just a subset) at once.
GCC has had a callgraph for a few versions now (since GCC 3.4 in the FSF releases), but the procedures didn't have control flow graphs (CFGs) built. The tree-profiling-branch in GCC CVS now has a CFG for every procedure built and accessible from the callgraph, as well as a basic IPA pass manager. It also contains in-progress interprocedural optimizations and analyses: interprocedural constant propagation (with cloning for specialization) and interprocedural type escape analysis.
IBM的XL Fortran V10.1 for Linux:
Benefits of interprocedural analysis (IPA)
Interprocedural Analysis (IPA) can analyze and optimize your application as a whole, rather than on a file-by-file basis. Run during the link step of an application build, the entire application, including linked libraries, is available for interprocedural analysis. This whole program analysis opens your application to a powerful set of transformations available only when more than one file or compilation unit is accessible. IPA optimizations are also effective on mixed language applications.
Figure 2. IPA at the link step
The following are some of the link-time transformations that IPA can use to restructure and optimize your application:
- Inlining between compilation units
- Complex data flow analyses across subprogram calls to eliminate parameters or propagate constants directly into called subprograms.
- Improving parameter usage analysis, or replacing external subprogram calls to system libraries with more efficient inline code.
- Restructuring data structures to maximize access locality.
In order to maximize IPA link-time optimization, you must use IPA at both the compile and link step. Objects you do not compile with IPA can only provide minimal information to the optimizer, and receive minimal benefit. However when IPA is active on the compile step, the resulting object file contains program information that IPA can read during the link step. The program information is invisible to the system linker, and you can still use the object file and link without invoking IPA. The IPA optimizations use hidden information to reconstruct the original compilation and can completely analyze the subprograms the object contains in the context of their actual usage in your application.
During the link step, IPA restructures your application, partitioning it into distinct logical code units. After IPA optimizations are complete, IPA applies the same low-level compilation-unit transformations as the -O2 and -O3 base optimizations levels. Following those transformations, the compiler creates one or more object files and linking occurs with the necessary libraries through the system linker.
It is important that you specify a set of compilation options as consistent as possible when compiling and linking your application. This includes all compiler options, not just -qipa suboptions. When possible, specify identical options on all compilations and repeat the same options on the IPA link step. Incompatible or conflicting options that you specify to create object files, or link-time options in conflict with compile-time options can reduce the effectiveness of IPA optimizations.
Using IPA on the compile step only
IPA can still perform transformations if you do not specify IPA on the link step. Using IPA on the compile step initiates optimizations that can improve performance for an individual object file even if you do not link the object file using IPA. The primary focus of IPA is link-step optimization, but using IPA only on the compile-step can still be beneficial to your application without incurring the costs of link-time IPA.
Figure 3. IPA at the compile step
IPA Levels and other IPA suboptions
You can control many IPA optimization functions using the -qipa option and suboptions. The most important part of the IPA optimization process is the level at which IPA optimization occurs. Default compilation does not invoke IPA. If you specify -qipa without a level, or specify -O4, IPA optimizations are at level one. If you specify -O5, IPA optimizations are at level two.
| IPA Level | Behaviors |
| qipa=level=0 |
|
| qipa=level=1 |
|
| qipa=level=2 |
|
IPA includes many suboptions that can help you guide IPA to perform optimizations important to the particular characteristics of your application. Among the most relevant to providing information on your application are:
- lowfreq which allows you to specify a list of procedures that are likely to be called infrequently during the course of a typical program run. Performance can increase because optimization transformations will not focus on these procedures.
- partition which allows you to specify the size of the regions within the program to analyze. Larger partitions contain more procedures, which result in better interprocedural analysis but require more storage to optimize.
- threads which allows you to specify the number of parallel threads available to IPA optimizations. This can provide an increase in compilation-time performance on multi-processor systems.
- clonearch which allows you to instruct the compiler to generate duplicate subprograms with each tuned to a particular architecture.
Using IPA across the XL compiler family
The XL compiler family shares optimization technology. Object files you create using IPA on the compile step with the XL C, C++, and Fortran compilers can undergo IPA analysis during the link step. Where program analysis shows that objects were built with compatible options, such as -qnostrict, IPA can perform transformations such as inlining C functions into Fortran code, or propagating C++ constant data into C function calls.
]]>