Archives

帖子来自 甘驰 (Intel) RSS

Intel® Parallel VTune™ Amplifier XE的信息采集方法

作者： 甘驰 (Intel) (20 篇文章) 日期： 三月 2, 2011 在 2:36 下午
评论 (3)

VTune Amplifier有两种信息采集方式，实现的技术也各有不同。 User-mode sampling and tracing collection 对于由VTune Amplifier启动的程序，user-mode sampling and tracing ...

继续 ›

分类: 并行计算, 英特尔信息技术峰会, 软件开发工具

Intel® Parallel VTune™ Amplifier XE的基础

作者： 甘驰 (Intel) (20 篇文章) 日期： 二月 23, 2011 在 3:49 下午
评论 (0)

Amplifier每个项目以分析类型/结果为基本单元。在Project Properties弹出框中，设定、修改被测程序，参数，是Native或Managed Code（.Net）等。在New Amplifier XE Result TAB内选定分析类型，设定相应参数，如硬件事件类型等。然后按Start键启动分析。   分析结束，产生一个新TAB，本例中r002ge, r代表result，002是分析序号，ge代表分析类型General Exploration。cc 代表Concurrency, ...

继续 ›

分类: 并行计算, 软件开发工具

Intel® Parallel VTune™ Amplifier XE的改进

作者： 甘驰 (Intel) (20 篇文章) 日期： 二月 23, 2011 在 2:53 下午
评论 (0)

  1．  Intel® VTune™ Performance Analyzer只能对整个系统进行采样。Amplifier XE增加了启动某个程序并只对其采样，和只对某个已运行程序采样。 2．  被采样的硬件事件种类数量受制于CPU的PMU(Performance Monitor Unit)，当采集超过4种数量时，老VTune会执行该程序多次，因而费时颇多。Amplifier XE能在一次执行中采集所有用户选定的事件。 3．  ...

继续 ›

分类: 其他

Intel(R) Parallel VTune(TM) Amplifier XE中Lock-wait分析的Timeline图解

作者： 甘驰 (Intel) (20 篇文章) 日期： 二月 23, 2011 在 10:36 上午
评论 (0)

Lock-wait分析是Amplifer XE中的一项重要功能，它报告一个程序内线程锁操作和相互等待的状况，timeline图解则能帮用户具体连接每次锁所有权的交换，以及该次等待的时间。   上图的上半部，列出源代码，标明该锁的等待时间等，直观易懂。下半部则是timeline图解，不解释，估计难以理解。Threads区域列出程序中所有线程，本例中有4个线程。Thread Concurrency区域中列出当时用几个线程在工作。 当光标移到某根表示锁所有权传递（transition）的黄线，它被变成红色以突出，同时弹出窗口。窗口上部的数据表示哪两个线程中的那两行代码间传递锁，下部数据表示光标所在线程的当前的状态，本例中光标在第二行（Thread Ox109c），浅绿表示它在等待状态，本次等待从1.685s开始，等52.564秒。   上图光标移到第一行（WinMainCRTStartup 0x758）后，数据显示该线程从31.227s开始，等了0.017s。 按红圈提示button，则将程序运行完整过程压缩于该窗口，如这时你看到threads区域几乎被表示transition的黄线覆盖，那程序很可能有锁及等待造成的性能问题。

继续 ›

分类: 并行计算, 软件开发工具

关于科学计算中的数值误差问题

作者： 甘驰 (Intel) (20 篇文章) 日期： 一月 26, 2010 在 3:51 下午
评论 (8)

最近看到有开发HPC应用的程序员反映换了编译器后，新程序的结果不正确。我不禁想起20年前在16位IBM PC AT/XT台式机上开发CAD/CAM程序, 程序在计算边界状况时，如两圆柱的轴夹角为1分求交线，结果经常匪夷所思，都是精度惹得祸。进入64bit时代同样的问题仍然存在，单次运算的精度提高了，但HPC程序中的大量的迭代计算，累积了误差，导致结果不同。我读了Intel同事的文章（http://software.intel.com/en-us/articles/consistency-of-floating-point-results-using-the-intel-compiler），略有所得，与大家分享。 人们要求结果的复现性有以下几方面， -同一程序，同一数据集，执行若干次的结果相同（近） -同一代码，不同编译选项产生的程序，相同的数据集，执行的结果相同（近） -同一代码，不同编译器产生的程序，相同的数据集，执行的结果相同（近） -同一代码，相同的数据集，在不同架构的CPU上执行的结果相同（近） 最好运行速度也要快。这些要求有时是相互矛盾的。让我们先分析计算结果有差别的原因，注意这里我用了差别，而不是误差。 首先，通常十进制的浮点数用二进制数表示时就有误差，便有了‘原罪’。 其二，计算机运算是不符合结合律的，如A+B+C不一定等于A+(B+C)。当A= -B且C为极小值时，A+B+C=C，但A+(B+C)=0，极小值C和B相加时由于精度限制，被忽略了或者说表示B的有效位不能包含C的值；但A+B=0,再加C后，结果为C。当你多线程或多进程化程序运行时，原来的数据被切成几分，分给不同的进程/线程执行，于是原先的次序被打破，用MPI或OpenMP的程序都有引入的这类潜在的结果差别。 其三，X87 FPU是以80位（1位符号，15位指数，64位数值）、扩展双精度浮点数运算的。SIMD执行单元可能不是（查遍手册，未见答案，至少其数据是以64位存放的）。 其四，四舍五入，(a) 1.0001 0000 1000 0011 ...

继续 ›

分类: 并行计算, 英特尔® 软件网络 2.0
标签：

读针对AVX优化代码 --- 优化issue port的使用

作者： 甘驰 (Intel) (20 篇文章) 日期： 一月 26, 2010 在 3:50 下午
评论 (1)

本文中的issue port专指CPU内部向其他执行单元(ALU, SSE MUL, DIV, Load, STD…)发送指令的通道，在Intel Micro Architectur(Sandy Bridge)中共有6个ports，port2,3,4负责存储单元，port0,1,5负责计算单元。若干计算单元会共享一个port，由于每个issue ...

继续 ›

分类: 并行计算
标签：,

读针对AVX优化代码 --- AVX/SSE切换

作者： 甘驰 (Intel) (20 篇文章) 日期： 一月 11, 2010 在 11:02 上午
评论 (1)

你可从http://www.intel.com/idf/technology-tracks/ -> "32 nm Implementation of... " -> "See sessions ...

继续 ›

分类: 其他, 英特尔® 软件网络 2.0
标签：

读AVX编程参考的一点所得

作者： 甘驰 (Intel) (20 篇文章) 日期： 十二月 29, 2009 在 1:09 下午
评论 (5)

AVX(Advanced Vector Extensions)是下一代Intel CPU中一个重要的新技术，抽空看了一点，记一些笔记。  增加了256-bit的SIMD寄存器，YMM0~YMM15, 其中低128-bit即 以前的XMM。  新增了FMA(fused-multiply-add)等指令以加强浮点运算能力, 如VFMADD132PD ymm0, ymm1, ymm2/256将ymm0和ymm2/mem中双精度浮点数相乘和ymm1相加并存入ymm0中。两步并一步。该指令有相应的Intrinsic ...

继续 ›

分类: 并行计算, 英特尔® 软件网络 2.0
标签：,

Parallel Advisor怎么工作的？

作者： 甘驰 (Intel) (20 篇文章) 日期： 十一月 23, 2009 在 3:26 下午
评论 (0)

一段源代码， for (int p = 3; p <= limit; p += ...

继续 ›

分类: 博客征文专栏, 英特尔® 软件网络 2.0
标签：

Parallel Advisor能干啥？

作者： 甘驰 (Intel) (20 篇文章) 日期： 十一月 2, 2009 在 3:28 下午
评论 (2)

顾名思义，给你一些编写并行程序的指导。它是Intel Parallel Studio套件中的四大组件之一，帮助编程者将现有的单线程程序改成多线程。 面对几年前开发的数十万、上百万行代码，即使是原设计师也会觉得棘手，从何处着手加入并行代码？可能会造成什么错误？完成后性能提高多少？一系列问题可能会阻挠你做正确的事，但Parallel Advisor将帮你在动手改代码前，得到这些问题的答案。 图示了Parallel Advisor的工作流程。首先，它分析该程序的运行，发现程序的热点，即耗时较多的部分。这时我们需要进一步分析该段代码，确定并行区域和任务。并行区域一般是一个循环体，任务是指将循环体内代码和数据被细分，未来被分配给多个线程同时运行的。这时我们并不需要直接改代码，而是以一种Parallel Advisor能识别的方法将并行区域和任务标识出来。 其次，Parallel Advisor运行和分析新代码，找到数据竞争访问（Data Race）的错误。同样我们也无需改动代码，只需标识对该数据进行保护。我们需要重复此步骤若干次，直至无错。 最后，将那些Parallel Advisor能识别的标识，用各种线程实现的方法逐个替换。 强调一下，前两步时无需改写代码。具体如何实现的，下次再讲。

继续 ›

分类: 其他, 并行计算, 英特尔® 软件网络 2.0
标签：

Parallel Amplifier的Lock&Wait分析

作者： 甘驰 (Intel) (20 篇文章) 日期： 五月 11, 2009 在 4:06 下午
评论 (0)

Parallel Amplifier中的锁和等待分析是一个非常实用的功能。因为有了多核/多处理器，需要多线程程序；因为多个线程可能并发访问公共变量，所以需要锁，进而为得到锁的所有权产生了等待；过多的锁导致多个线程串行。一切似乎回到的原地，但我们已经把问题推升到如何优化锁来减少等待。哪些锁需要被优化？这就是Amplifier的锁和等待分析要告诉你的。 把一个线程获得锁称为上锁。上锁次数和上锁时其他线程等待的时间总和是两个的重要指标，但仍需参考当时CPU/Core的使用率。如CPU/Core使用率高，那么这个锁和由它造成的等待就不是很重要，因为即使这些线程不等也没有空闲的CPU/Core来运行。主线程执行WaitForMultipleObjects(NumThreads, h, TRUE, INFINITE)等待所有子线程退出，即使等23.9秒并不影响总体性能。相反CPU/Core使用率低时，缩短等待的时间能提高性能。 Amplifier Lock&Wait分析告诉你某个锁分别在CPU/Core的Idle/Poor/OK/Ideal/Over状态下的等待时间。 但CPU/Core使用率高时，锁和由它造成的等待总体上不影响性能是有前提的，即CPU/Core的数量不变，当你在一台高配置的计算机上运行该程序时，CPU/Core的数量增加了，等待就成了那时性能的瓶颈。

继续 ›

分类: 并行计算, 英特尔® 软件网络 2.0
标签：

Parallel Amplifier的并行度分析（续一）

作者： 甘驰 (Intel) (20 篇文章) 日期： 四月 30, 2009 在 1:36 下午
评论 (1)

Parallel Amplifier分析程序后，能得到热点函数的并行度和整个程序的并行度。对于单个函数，它报告运行该函数的时间和并行度，据此你决定是否有必要多线程化它。 Amplifier产生下图告知整个程序的并行度。 Logical CPU Count：运行该程序的计算机上的CPU/Core的数量。本例中为2. 'Poor'表示激活的线程数小于计算机的核数，本例中为1. 'ideal'表示激活的线程数和计算机的核数相同，即充分利用CPU/Core的资源。本例中为2. 'Over'表示激活的线程数大于计算机的核数。 光标移至小点上时，窗口浮出。显示在两个激活线程时程序运行的时间，12.891sec。同样得到在单个激活线程时程序运行的时间，4.509sec 小方块1.74表示并行度。（12.891*2+4.509）/17.4 = 1.74  

继续 ›

分类: 并行计算, 英特尔® 软件网络 2.0
标签：

Parallel Amplifier的并行度分析

作者： 甘驰 (Intel) (20 篇文章) 日期： 四月 27, 2009 在 10:34 上午
评论 (1)

今天讨论一下Parallel Amplifier中并行度分析（Concurrency Analysis）。并行度是衡量一个多线程程序在运行中对多个CPU或核的利用率。在解释几个相关定义前先作一个假设，大家知道一台计算机上除了OS以外总有若干个后台程序在运行，假定这些程序运行时占用CPU的时间很小，不影响被Amplifier分析的程序的正常运行。 1. Available CPU time（可用CPU时间）= Elapsed time * Target ...

继续 ›

分类: 并行计算, 英特尔® 软件网络 2.0
标签：,

Parallel Inspector (续二)

作者： 甘驰 (Intel) (20 篇文章) 日期： 四月 2, 2009 在 10:35 上午
评论 (0)

上回我们讲到Inspector能检测的错误。大家知道这类的runtime的测试一般都需在代码中插入一些检测代码，因而会造成性能的下降。根据耗时和错误的危害性，Inspector让用户设定检测深度。上图是Inspector中线程检测的设置窗口，内存检测也有一个。下表表示检测深度和错误的关系， Data race - ti2(first access), ti4(second access) Dead lock - ti1 Invalid ...

继续 ›

分类: 并行计算, 英特尔® 软件网络 2.0
标签：

Parallel Inspector (续一)

作者： 甘驰 (Intel) (20 篇文章) 日期： 三月 30, 2009 在 11:16 上午
评论 (0)

费了些力在Inspector手册中找到的它能检测的错误集，有些用处，至少以后不必为这类错误而困惑。 l         Data race是最常见的，多个线程访问公共变量不加锁，导致运行结果飘忽不定，最难被发现，很头疼。 l         Dead lock是加锁次序不对，两个相互等待对方先解锁。病症较可怕，由于操作系统的调度原因，该病并不每次运行时一定发生。 l         Invalid Memory Access是先malloc数据，read/write使用之，free后再访问read/write。在单线程程序，这明显是一个低级错误。但在多线程程序中， 切忌在子线程中free公共指针。 l         Invalid ...

继续 ›

分类: 并行计算, 英特尔® 软件网络 2.0
标签：

用Parallel Inspector发现释放指针的错误

作者： 甘驰 (Intel) (20 篇文章) 日期： 三月 27, 2009 在 3:59 下午
评论 (0)

这几天试用Parallel Inspector，完成正常功能测试后，兴趣颇高，试试一些边界状况。 int main(int argc, char* argv[]) {unsigned int i = ...

继续 ›

分类: 并行计算, 英特尔® 软件网络 2.0

Debugger Extersion (续三)

作者： 甘驰 (Intel) (20 篇文章) 日期： 三月 20, 2009 在 10:22 下午
评论 (0)

承接上个话题event filter.  Transparent原意为透明的、显著的，但在计算机领域中它意为因为透明，而不被感知，意思完全相反。我开始认为event filter是把要的东西留下，象洗菜的篓子，但这个event filter却是设要被忽略的事件，奇怪的很，但转念一想，滤水器不就把胀东西留下吗？ 所以event filter是用来设定你不关心的事件，data sharing event就不会暂停程序运行并显示相关信息。我认为设定关心的事件可能更有用，在洋洋晒晒的，几十万、甚至上百行代码的程序运行时，可能产生大量的data sharing events, ...

继续 ›

分类: 并行计算, 英特尔® 软件网络 2.0
标签：

Debugger Extension (续二)

作者： 甘驰 (Intel) (20 篇文章) 日期： 三月 20, 2009 在 12:41 下午
评论 (4)

因为OpenMP是将循环的计算多线程化，所以data sharing event一般都在某行/段代码反复发生，这会影响纠错工作，你不会希望看100000...次同一个事件。event filter 能帮你滤掉已知或暂不关心的事件。 下图显示怎样滤掉发生在某个函数中的thread data sharing事件 下图显示怎样滤掉发生在某个变量上的thread data sharing事件  当你设完后，在thread data ...

继续 ›

分类: 并行计算, 英特尔® 软件网络 2.0
标签：

Debugger Extension (续一)

作者： 甘驰 (Intel) (20 篇文章) 日期： 三月 19, 2009 在 12:58 下午
评论 (22)

通过引入OpenMP把原来单线程的程序改为多线程，窃以为最难得莫过于设定数据共享特征，如shared, private, firstprivate, lastprivate, threadprivate，数据是否在OpenMP的并行区域内是否被各线程所共享由此决定，新手难免设错。Thread data sharing event是Intel debugger extension为发现这类问题而新增的。 Enable ...

继续 ›

分类: 并行计算, 英特尔® 软件网络 2.0
标签：

关于Intel Parallel Composer的Debugger Extension

作者： 甘驰 (Intel) (20 篇文章) 日期： 三月 18, 2009 在 1:58 下午
评论 (6)

 越来越多的人使用OpenMP来开发多线程程序，因为它简单易学易用。但也使调试变得更困难，本来调试多线程程序就不容易，而OpenMP封装几乎所有的线程操作，在代码中你不找到显式的线程创建、同步和销毁，因而很难找到合适的地方设置断点。  Intel作为OpenMP的积极推广者，早就考虑到了。Intel Parallel Debugger Extension作为Intel Parallel Composer的一个部分，可集成到微软的Visual studio. 其工作原理图如下，     首先用Intel Parallel Composer中Intel编译器编译代码，并设选项/debug:parallel和/Qopenmp。编译器重构（instrument）代码能在运行时触发特定exception. Intel ...

继续 ›

分类: 并行计算, 英特尔® 软件网络 2.0
标签：