基于tilera的h.264解码并行算法的性能分析和基于sqlserver的煤炭产量统计方法设计与实现

基于Tilera的H.264解码并行算法的性能分析摘要: 多核已经成为当前桌面和超级计算机主流处理器技术，其中Tilera多核处理器以其功耗和并行方面的优势在网络视频处理应用中潜力颇大。本文针对高视频质量的H.264解码算法，研究其并行策略，在Tilera多核结构实现了两种宏块级并行策略，即任务池和循环行块并行算法。通过实验分析表明，循环块并行算法大大降低了线程间同步开销影响，相对任务池并行程序性能提高了30%以上，在16核规模下获得了11倍的加速效果。关键词: 多核，并行，Tilera，H.264，高性能介绍过去处理器主要依靠提高主频和挖掘指令级并行（ILP）来获得性能提升，但芯片面积和功耗成为制约其继续发展的障碍。当前，多核技术已经成为处理器的主流，无论是工业界还是学术界，多核都是重要的研究热点。在过去的几年中，Intel/AMD的通用商业多处理器的核心数目已经从2核提高到了12核。但是这些技术很难扩展到众核规模，如片内集成100-1000个核心。在众核规模下，目前通用商业多核技术会引入低效核间通信、共享有限访存带宽等性能瓶颈，更严重的是其高的功耗开销。为了克服上述通用多核处理器技术带来的扩展性问题，目前学术界和工业界正在展开大量研究，提出了许多众核处理器设计技术。IBMCell[1]是低功耗的异构的处理器，并且已经成功用于构建全球第一台实测峰值超过1Petaflops的超级计算机[2]。Nvidia、Intel和AMD都采用了GPGPU的技术路线，设计自己的众核处理器用于加速科学计算，但目前的GPU在功耗方面逐渐显露出其劣势，比如最新的Nvidia采用Fermi处理器的加速卡，其功耗超过200W。事实上，流处理器技术正成为高性能计算的重要方面，作为其典型代表，Tilera[3]由于其易用性和高性能，使其能适合多个领域的计算密集型应用，如网络、数字视频和通信领域。随着网络技术与多媒体技术的不断发展，为了能够在较低的带宽上提供高质量的图像传输，H.264[4]视频编码技术因其高压缩比、高抗误码效应和良好的网络亲和性的优势而得到广泛的使用。该技术也代表了当今通信行业融合的趋势，如广电、网络多媒体和3G移动网络等方面的需求。然而，H.264技术的高性能是以其算法复杂度为代价的。本文的主要目的是评价H.264解码在Tilera上的性能，针对H.264解码应用，以寻求其在Tilera扩展到众核的有效途径。我们实现了两种在其它多核结构上主要使用的并行化策略，测试了两种算法在Tilera上的扩展性。本论文的组织如下：第二节简要介绍Tilera多核体系结构，包括论文的实验平台TILEPro是Tilera家族中的一款多核处理器。第三节描述了H.264解码算法的基本流程，并分析了其并行化的可能性。第四节重点阐述了论文实现的两种基于宏块级并行策略。第五节结合在TILEPro上的实验，给出详细的性能评价。Tilera多核体系结构Tilera处理器的前身是MIT大学的RAW体系结构[5]，是在学术界称为Tile体系结构的典型代表，一个RAW处理器由16个可编程的Tile组成。每个Tile都有其单独的微处理器、数据Cache、存储器以及连接各个Tiles的互连网络接口。RAW适合于线程级并行，各线程可分空间并行执行。RAW把底层的物理资源如门、线、引脚等作为体系结构的实体暴露给程序员，这使得程序员面对线延迟可以更好的安排程序执行从而获得最佳性能，较好的解决线延迟的问题。Tilera公司基于RAW的研究基础开发了Tile64，于2007年发布，它具有64个处理核，采用45nm工艺，主频达900MHz。Tile64使用iMesh片上网络连接64个独立的处理核（称为Tile），具有4个DDR2控制器、2个网络接口、两个PCIE接口。图1给出了Tilera处理器（Tile64和TilePro）的硬件体系结构。每个Tile都是一个全功能通用处理核，实现了3路超长指令字（VLIW）的32位整数处理引擎，包含一个寄存器文件和三个功能单元（一个load-store单元和两个算术逻辑单元），L1和L2级cache，使用非阻塞交叉开关将Tile连入iMesh。片内互联网络有多个动态网络和一个静态网络组成，比如三个寄存器映射的体系结构定义的用户态动态网络（UDN）、输入/输出动态网络（IDN）和静态网络（STN），此外TILE64和TILEPro实现了支持主存通信和tile之间存储映射的硬件管理网络。每个Tile可以独立运行一个操作系统，或者多个Tile共同运行一个多处理操作系统（如SMP）。Tile64具有灵活的特点，多个Tile可以组成Lane，为特定应用提供足够的计算性能。同时，Tilera通过每个tile能够运行不需要修改的C代码而获得性能和编程之间的最佳平衡。H.264解码流程介绍H.264是由联合视频组提出的最新数字视频解码器的标准，包含了视频编码层（VCL）和网络提取层（NAL）。VCL包括核心压缩引擎和块、宏块和片的语法级别定义，它的设计目标是尽可能地独立于网络进行高效地编解码；而NAL层则负责将VCL产生的比特字符串适配到各种各样的网络和多元环境中，它覆盖了所有片级别以上的语法级别，同时支持：独立片解码、起始码唯一保证、支持SEI和支持流格式编码数据传送。图2描绘了H.264的解码过程。总体说来，NAL解码器负责将符合H.264码流规范的压缩视频流解码，并进行图像重建。视频编码比特流首先经过解析，分离成参数信息和图像残差数据，其中参数信息指明宏块类型和解码方案等，图像残差数据经熵解码，逆Zig_Zag重排序，反量化和反变换得到时域残差，与此同时，利用已经重建的邻近块作为参考对当前块进行帧内预测或帧间预测，预测的结果加上时域残差即得到当前块的重建值。其中熵解码包括基于上下文的自适应变长编码CAVLC和基于上下文的自适应算术二进制编码CABAC，这二者应用于H.264的不同档次级别中（本文假设的是CABAC编码）。图图1.Tile处理器硬件体系结构图2.H.264解码算法流程图3.编码比特流数据格式H.264视频编码比特流是有若干NAL单元组成，图3给出了视频流的结构。第一个单元是序列参数集SPS，第二个是图像参数集PPS，二个单元共同组成了该段视频的编码特征信息，第三个及以后的NAL单元则包含了图像数据，一般一个单元表示一副图像数据，有若干片组成，每个片又是由若干大小为16*16的宏块组成，每个宏块包括了4个8*8的亮度块，一个8*8的Cr色度块和一个8*8的Cb色度块，其中每一块又分成4个4*4的字块。H.264视频网络流解码过程存在多个级别的并行。最粗粒度的并行在于流级并行，一个流代表了一个视频文件，每个视频文件之间没有任何数据依赖关系。流级并行的问题是每个视频流的大小变化带来的负载平衡，一个小的视频流可能只有20多帧，但一个大能够到200多帧。对于单个流，解码过程中可以开发帧（frame）级并行和片（slice）级并行。从帧级看，视频流包含了B/P/I三种类型的帧，一个帧序列以I帧开始，跟随了若干B帧和P帧。I帧单独解码后，解码P帧，然后解码B帧。I帧和P帧之间通常会有一个或多个B帧，这多个B帧可以并行解码。如前所述，一帧由若干片构成，这些片的解码也能够并行完成。然而，并行的B帧或者片的数量通常相当有限，比如某些视频流的I/P帧之间的B帧只有2-3个，甚至一帧的片数量只有一个。因此，帧、片级并行度有限，不适合规模并行。 图4.宏块之间的依赖关系示图注意到片又有多个宏块组成，通常宏块的数量达到成百上千，自然可以考虑宏块（MacroBlock,MB）级并行。但宏块级也需要处理块之间的依赖关系。图4给出了一个宏块依赖关系的示例，宏块（1,4）（2,2）（3,0）正在处理解码，必须等其依赖的宏块完成解码，这三个块的解码操作才能执行，而三个宏块解码操作可以完全并行执行。相对于帧/片级，宏块级的并行度具有明显的优势，因此本文重点关注宏块级并行策略的分析。宏块级并行解码算法视频流的一帧中的宏块组织成大小为（Nhor,Nver）的2维网格，由于宏块之间的依赖关系，所有宏块的解码必须按照一定顺序执行。如图4所示，宏块之间并行主要存在对角线上的宏块，表明了宏块级并行受限于水平方向的块数量，即宏块级并行度Pmb为：例如，对一个120*67的视频流，其最大并行度为60。根据宏块和处理器之间映射策略的不同，有两种宏块级并行算法：任务池和循环行分配。图5.任务池算法模型whilewhile(1){2.等待主线程的开始信号;3.if(帧末尾)退出；4.while(队列不空){5.从任务队列中取一宏块；6.解码；7.更新依赖关系表；8.提交满足依赖关系的宏块；9.}10.}图6.任务池模式中工作线程算法任务池任务池算法用主从模式实现宏块级并行[6]，图5说明了任务池算法的实现。所有线程协作维护每个宏块（即图中的工作单元）的状态，选择满足依赖关系的宏块调度分配给空闲的工作线程。宏块的状态维护通过依赖关系表实现，调度通过任务队列方式进行。依赖关系表中的每一项的值代表其依赖宏块的数量，当该项的值变为零时，线程将该宏块插入到先进先出的任务队列中，当有空闲的从线程时，从任务队列中取出任务完成解码操作。当线程完成解码操作后，更新依赖关系表：将其右边和下方的邻接项减一。工作线程并行算法流程如图6所示。由于所有线程共享依赖关系表和任务队列，算法中的第5、7、8行需要线程间同步处理多个线程同时更新依赖关系表和任务队列的操作。考虑到单个宏块解码本身的执行时间短，同步操作的开销在一定程度会影响并行解码算法的扩展性。因此降低额外同步开销的影响成为提高扩展性的重要策略，基于这个思想，本文采用了更静态的宏块分配策略。图7.循环行分配算法模型循环行分配对一个二维的宏块矩阵，循环行分配算法循环地分配每一整个宏块行给一个线程[7]。假设有p个线程，每个线程i处理宏块行号为：while(1){while(1){2.等待主线程的开始信号;3.if(帧末尾)退出；4.while(队列不空){5.从任务队列中取一宏块；6.解码；7.更新依赖关系表；8.提交满足依赖关系的宏块；9.}10.}图7描绘了循环行分配策略的例子，这样，同一行的宏块的依赖关系的更新由一个线程完成，消除了处理一行宏块依赖关系的同步开销。循环行分配算法如图8所示，这里每个线程处于对等模式，每个线程执行的工作一样。第9行多个线程同时更新依赖关系表，第7行读取依赖关系表的状态，这是一个典型生产者-消费者模式，用简单的内存原子操作实现忙等到达线程之间同步。whilewhile(1){2.全局同步;3.if(帧末尾)退出；4．行号=线程id;//1<id<p5.while(行号i小于Nver)6.while(列号j小于Nhor){7. 等待宏块（i,j）满足依赖关系；8.解码宏块（i,j）；9.更新依赖关系表；10.}11.}图8.循环行分配模式中工作线程算法性能评价我们在TILEPro上实现了上述的两种宏块级并行算法，编程环境是TileraMulticoreDevelopmentEnvironment(MDE)2.1，多线程编程采用了Pthread，调用Pthread同步互斥函数实现线程间对共享数据（依赖关系表和任务队列）同步，利用TILEPro提供的内存原子操作实现了循环行分配算法中的更新依赖关系表操作。实验数据选取了4种不同分辨率大小的H.264视频文件，表1总结了4中视频文件的特点。表1.实验数据像素大小宏块数量最大并行度325*28818*2211720*57636*45221280*72045*80401920*107267*12060图9.任务池算法的比特率实验以任务池算法作为基准，比较循环行分配算法的性能改善情况。图9是任务池算法获得的比特率，即文件大小除以解码时间。图示性能表面算法的扩展性和宏块的数量存在直接的关系，像素为325*288的视频每帧有18*22个宏块，而最大并行度为11，当使用的tile核个数超过8时，性能开始呈下降趋势。随着分辨率的增加，并行算法的扩展性逐步提高。图10给出了循环行分配策略相对任务池策略的性能提高，可以看出，对所有的分辨率的视频解码，循环行分配策略均有较大幅度的提升，最高的的提升幅度达到35%。同时，我们分析了循环行分配算法的加速比，图11给出了优化算法的相对单tile核的加速比，在16个核的情况，加速比达到11。在4个tile核的情况下获得了线性加速比。图10.循环行分配算法相对任务池算法的提高图11.循环行分配算法的加速比图12.熵解码部分占的时间比例最后，我们分析限制并行解码算法扩展性能的主要因素。注意到如图2所示，解码算法对每个宏块需要一个熵解码的操作，而熵解码操作不能并行化，根据Amdal定律，改部分的时间决定了并行程序的加速性能。实验得到的熵解码时间如图12所示，显然，随着Tile核数目使用的增加，熵解码的时间比例明显增加，甚至占了总时间的80%。因此，未来有必要采用特殊硬件加速的方法提高该部分的性能。总结论文描述了两种基于宏块级并行H.264解码的并行算法，即任务级和循环行分配策略，并在TILEPro上实现了两种算法，通过实验分析表明，循环行分配策略相对任务池分配由于减少了同步开销，性能提高了30%以上，在16核情况获得了11倍的加速性能。致谢：论文得到了国家自然科学基金60803030的支持。References:/cell/../.ThomasWiegand,GaryJ.Sullivan,GisleBjøntegaard,andAjayLuthra,"OverviewoftheH.264/AVCVideoCodingStandard",in

IEEETransactionsonCircuitsandSystemsforVideoTechnology

(2003).MichaelBedfordTaylor,WalterLee,JasonMiller,DavidWentzlaff,IanBratt,BenGreenwald,HenryHoffmann,PaulJohnson,JasonKim,JamesPsota,ArvindSaraf,NathanShnidman,VolkerStrumpen,MattFrank,SamanAmarasinghe,andAnantAgarwal.EvaluationoftheRawMicroprocessor:AnExposed-Wire-DelayArchitectureforILPandStreams.ProceedingsofInternationalSymposiumonComputerArchitecture,June2004.M.Alvarez,A.Ramirez,A.Azevedo,C.H.Meenderinck,B.H.H.Juurlink,M.Valero,ScalabilityofMacroblock-levelParallelismforH.264Decoding,ProceedingsofInternationalConferenceonParallelandDistributedSystems(ICPADS),December2009.C.C.Chi,B.H.H.Juurlink,C.H.Meenderinck,EvaluationofParallelH.264DecodingStrategiesfortheCellBroadbandEngine,ProceedingsInternationalConferenceonSupercomputing(ICS),June2010.基于SQLServer的煤炭产量统计方法设计与实现摘要：为了方便煤矿实现班、日、月、年产量的快捷查询，更好的帮助煤矿统计产量信息，本文提出了一种基于SQLServer的煤炭产量统计方法设计。该系统整体采用C/S构架，在数据采集上使用防爆皮带秤和基于WinCE的控制仪表，在远程数据监控中心安装有采用了该数据统计方法的服务器程序。实践表明，该查询方法简单、快捷、高效，大大提高了煤矿的产量统计效率。关键词：SQLServer；煤炭产量；C/S；产量统计

DesignandimplementofCoalProductionStatisticalMethodBasedonSQLServerAbstract:Inordertoexpressqueryclasses,day,month,yearproductioniseasytorealizeforcoalmine,betterhelpcoaloutputstatisticsinformation,thispaperpresentsadesignstatisticalmethodofcoalproductionbasedonSQLServer.TheoveralluseofC/Sstructureofthesystem,dataacquisitionintheuseofexplosion-proofbeltweigherandcontrolinstrumentbasedonWinCE,usingthedataqueryserverprogramisinstalledintheremotedatamonitoringcenter.Practiceshowsthat,thestatisticalmethodissimple,fastandefficient,greatlyimprovingtheefficiencyofcoalmineproductionstatistics.Keywords:SQLServer;Coaloutput;C/S;OutputStatistics

0.引言随着国民经济的迅速发展，煤炭行业进入了前所未有的局面，煤炭行业的发展壮大带来了管理模式的改革，其采煤工作机制为每天三班循环制。一些煤矿将每班的产量作为该班的绩效考核标准的一部分，统计班产量也就成了煤炭产量查询软件的重要组成部分。本文旨在设计一种算法优良、简单高效、实用价值高的基于SQLServer的煤炭产量数据统计方法。1.SQLServer数据库SQLServer数据库是美国Microsoft公司推出的一种关系型数据库系统。它性能高，可充分利用WindowsNT的优势。系统管理先进，支持图形化管理工具。事物处理功能强大，利用各种方法保证数据的完整性。支持存储过程、视图、函数，并有自主的SQL语言。可扩展性强，为分布式C/S架构模式提供了很好的技术支持平台。在本设计中，服务程序实现产量数据的实时接收，分解后形成产量数据保存到SQLServer2005数据库。2.系统设计2.1系统整体架构系统整体架构如图1所示：图1系统整体架构图Fig.1Architecturediagramoftheoverallsystem2.2服务软件整体设计系统客户端软件以MicrosoftVisualBasic6.0为开发环境，以MicrosoftSQLServer2005做后台数据库支撑。软件中对称重数据及设备状态信息通过与称重仪表Winsock通信的方式获取，采用新的产量统计算法，降低了软件开发的难度；主备机之间采用Winsock通信，不仅实现了对两个工控机产量数据和设备状态信息的统一处理，而且降低了系统的复杂程度，使得煤矿工作人员更容易操作。在MicrosoftVisualBasic6.0开发环境中，利用Winsock控件来实现客户端和服务器的连接，并通过网络将WinCE仪表的通讯数据进行接收，然后根据其通信协议对数据进行分解和重新组合，以实现系统的功能要求。最后将收到的数据按照三班循环机制以一定的格式保存到SQLServer2005数据库中，进而完成班、日、月、年产量的查询。服务软件具有用户管理设置、历史数据查询、报表打印等功能。软件设计流程如图2所示。图2服务器端软件流程图Fig.2Theflowchartofserversoftware2.3班次统计算法要统计班产量就要根据煤矿的现实情况，确定其交班时间，并计算当前时间所在的班次。由软件记录下当前班的开始时间，当交班时间到达时计算当班的产量，并把数据保存到数据库。根据煤矿不同的交班时间需要设置四个全局变量，即三个交班时间JBTime1、JBTime2和JBTime3和当前时间CurrentTime，三个交班时间可以通过软件里设置，其循环机制如图3所示。即每天24小时内，JBTime1、JBTime2和JBTime3循环进行。考虑到00：00这一特殊时间点可能所在的时间段，如图4所示，将当前时间所处的班次判断分为三种情况。图3交班时间循环机制图图4交班时间循环机制图Fig.3Cyclemechanismchartofhanding-overtimeFig.4Cyclemechanismchartofhanding-overtime并在定时器里将当前时间与此三种情况下与各交班时间比对，得出当前时间所在的班次：1、00:00:00<=JBTime1AndJBTime1<JBTime2AndJBTime2<JBTime3AndJBTime3<=23:59:59，此情况算法流程图如图5所示：图5班次算法流程图Fig.5FlowchartoftheShiftalgorithm2、00:00:00<=JBTime3AndJBTime3<JBTime1AndJBTime1<JBTime2AndJBTime2<=23:59:59此情况算法流程图如图6所示：图6班次算法流程图Fig.6FlowchartoftheShiftalgorithm3、00:00:00<=JBTime2AndJBTime2<JBTime3AndJBTime3<JBTime1AndJBTime1<=23:59:59此情况算法流程图如图7所示：图7班次算法流程图Fig.7FlowchartoftheShiftalgorithm2.4班产量统计方法设计 WinCE仪表每一分钟发送一次数据，软件用Winsock接收仪表数据，从数据中提取瞬时流量及皮带秤总累计值，保存到数据库的shishi表中，shishi表设计如表1：表1实时数据表shishiTable1thereal-timedataintableShishi列名数据类型可否为空说明IDInt否记录号ShiJiannVarchar(50)是时间pdc_shishivalueDecimal(14，3)是瞬时流量leiDecimal(14，3)是仪表总累计值这样我们在shishi表中找到当前班之前累计值的最大值作为当前班产量的起始值BanLeiJi_Start，然后找到当前班最新累计值BanLeiJi_End，可得出当前班产量BanLeiJi=BanLeiJi_End-BanLeiJi_Start。当交班时间到达时保存当前班产量到班产量数据表CL中，CL表中数据是为查询和打印报表服务，其数据是每天一条启示，且每到交班时间更新。班产量数据表设计如表2：表2班产量数据表CLTable2classoutputdataintableCL列名数据类型可否为空说明IDInt否记录号ShiJiannVarchar(50)是时间Ban_1Decimal(14，3)