基于线程的MPI通信加速器技术研究

第３４卷第１期　２０１１年１月　计　算　机　学　报　Ｖｏ１．３４　Ｎｏ．１　ＣＨＩＮＥＳＥ　Ｊ（）ＵＲＮＡＬ　０Ｆ　Ｃ０ＭＰＵＴＥＲＳ　Ｊａｎ．２０１１　基于线程的ＭＰＩ通信加速器技术研究　刘志强　宋君强　卢风顺　赵　娟　（国防科学技术大学计算机学院长沙４１００７３）　摘　要　为了针对多核系统构建更高效的ＭＰ１支撑环境，文中提出了一种基于线程的ＭＰＩ加速器，称作ＭＰＩＡｃｔｏｒ．　ＭＰＩＡｃｔｏｒ是一种用于协助传统ＭＰＩ库的透明中问件，用户可以在编译期选择是否在单线程ＭＰＩ程序中采用该中　间件．加入ＭＰＩＡｃｔｏｒ后，每个节点内的ＭＰＩ进程都被映射成同一进程中的多个线程，从而节点内的通信可通过轻　量级的线程通信机制实现．作者给出了ＭＰＩＡｃｔｏｒ的基本设计，详细阐述了其工作机制、通信体系结构及关键技术，　并在真实系统上分别针对ＭＶＡＰＩＣＨ２和ＯｐｅｎＭＰＩ并行环境利用ＯＳＵ　ＬＡＴＥＮＣＹ基准测试进行了性能评测．实　验结果表明在两种ＭＰＩ环境Ｊ－进行节点内８　ＫＢ～４　ＭＢ数据通信时ＭＰＩＡｃｔｏｒ都能使通信性能平均提高一倍左右．　关键词　ＭＰＩ软件结构；线程ＭＰＩ；ＭＰＩ加速器；ＭＰｌＡｃｔｏｒ　中图法分类号ＴＰ３０２　ＤＯＩ号：１０．３７２４／ＳＰ．Ｊ．１０１　６．２０１１．００１５４　Ａ　Ｓｔｕｄｙ　ｏｆ　Ｔｈｒｅａｄ—Ｂａｓｅｄ　ＭＰＩ　Ｃｏｍｍｕｎｉｃａｔｉｏｎ　Ａｃｃｅｌｅｒａｔｏｒ　Ｉ　ＩＵ　Ｚｈｉ—Ｑｉａｎｇ　ＳＯＮＧ　Ｊｕｎ　Ｑｉａｎｇ　ＬＵ　Ｆｅｎｇ—Ｓｈｕｎ　ＺＨＡＯ　Ｊｕａｎ　（Ｃｏｌｌｅｇｅ　ｏｆ　Ｃｏｍｐｕｔｅｒ，Ｎａｔｉｏｎａｌ　Ｕｎｉｖｅｒｓｉｔｙ　ｏ／Ｄｅｆｅｒｉｓｅ　Ｔｅｃｈｎｏｌｏｇｙ，Ｃｈａｎｇｓｈａ　４１００７３）　Ａｂｓｔｒａｃｔ　Ｔｏｗａｒｄｓ　ｂｕｉｌｄｉｎｇ　ａ　ｍｏｒｅ　ｅｆｆｅｃｔｉｖｅ　ＭＰＩ　ｉｎｆｒａｓｔｒｕｃｔｕｒｅ　ｆｏｒ　ｍｕｌｔｉｃｏｒｅ　ｓｙｓｔｅｍｓ，ａ　ｔｈｒｅａｄ—　ｂａｓｅｄ　ＭＰＩ　ｐｒｏｇｒａｍ　ａｃｃｅｌｅｒａｔｏｒ，ｃａｌｌｅｄ　ＭＰＩＡｃｔｏｒ，ｉｓ　ｐｒｏｐｏｓｅｄ　ｉｎ　ｔｈｉｓ　ｐａｐｅｒ．ＭＰＩＡｃｔｏｒ　ｉｓ　ａ　ｔｒａｎｓ—　ｐａｒｅｎｔ　ｍｉｄｄｌｅｗａｒｅ　ｔＯ　ａｓｓｉｓｔ　ｇｅｎｅｒａｌ　ＭＰＩ　ｌｉｂｒａｒｉｅｓ．Ｆｏｒ　ａｎｙ　ｓｉｎｇｌｅ—ｔｈｒｅａｄ　ＭＰＩ　ｐｒｏｇｒａｍ，ｔｈｅ　ＭＰＩ—　Ａｃｔｏｒ　ｉｓ　ｏｐｔｉｏｎａｌ　ｉｎ　ｃｏｍｐｉｌｉｎｇ　ｐｈａｓｅ．Ｗｉｔｈ　ｔｈｅ　ｊｏｉｎ　ｏｆ　ＭＰＩＡｃｔｏｒ，ｔｈｅ　ＭＰＩ　ｐｒｏｃｅｓｓｅｓ　ｉｎ　ｅａｃｈ　ｎｏｄｅ　ｗｉｌＩ　ｂｅ　ｍａｐｐｅｄ　ａｓ　ｓｅｖｅｒａｌ　ｔｈｒｅａｄｓ　ｏｆ　ｏｎｅ　ｐｒｏｃｅｓｓ，ａｎｄ　ｔｈｅ　ｉｎｔｒａ—ｎｏｄｅ　ｃｏｍｍｕｎｉｃａｔｉｏｎ　ｗｉｌｌ　ｂｅ　ｅｎ—　ｈａｎｃｅｄ　ｂｙ　ｔａｋｉｎｇ　ａｄｖａｎｔａｇｅ　ｏｆ　ｔｈｅ　ｌｉｇｈｔ—ｗｅｉｇｈｔ　ｔｈｒｅａｄ—ｂａｓｅｄ　ｍｅｃｈａｎｉｓｍ．Ｔｈｅ　ａｕｔｈｏｒｓ　ｈａｖｅ　ｄｅ—　ｓｉｇｎｅｄ　ａｎｄ　ｉｍｐｌｅｍｅｎｔｅｄ　ｔｈｅ　ｐｏｉｎｔ　ｔＯ—ｐｏｉｎｔ　ｃｏｍｍｕｎｉｃａｔｉｏｎ　ｍｏｄｕｌｅ．Ｔｈｉｓ　ｐａｐｅｒ　ｄｅｔａｉｌｓ　ｔｈｅ　ｍｅｃｈａ—　ｎｉｓｍ．ｔｈｅ　ｃｏｍｍｕｎｉｃａｔｉｏｎ　ａｒｃｈｉｔｅｃｔｕｒｅ　ａｎｄ　ｋｅｙ　ｔｅｃｈｎｉｑｕｅｓ，ａｎｄ　ｅｖａｌｕａｔｅｓ　ｉｔ　ｗｉｔｈ　ＯＳＵ　ＬＡＴＥＮＣＹ　ｂｅｎｃｈｍａｒｋ　ｏｎ　ａ　ｒｅａｌ　ｐｌａｔｆｏｒｍ．Ｔｈｅ　ｅｘｐｅｒｉｍｅｎｔａｌ　ｒｅｓｕｌｔｓ　ｓｈｏｗ　ｔｈａｔ　ｔｈｅ　ｉｎｔｒｏｄｕｃｔｉｏｎ　ｏｆ　ＭＰＩＡｃｔｏｒ　ｃａｎ　ａｃｈｉｅｖｅ　ａ　２Ｘ　ｐｅｒｆｏｒｍａｎｃｅ　ｆｏｒ　ｔｒａｎｓｆｅｒｒｉｎｇ　８　ＫＢ　ａｎｄ　４　ＭＢ　ｍｅｓｓａｇｅｓ　ｏｎ　ＭＶＰＩＣＨ２　ａｎｄ　ＯｐｅｎＭＰＩ　ｐａｒａｌｌｅｌ　ｅｎｖｉｒｏｎｍｅｎｔｓ．　Ｋｅｙｗｏｒｄｓ　ＭＰＩ　ｓｏｆｔｗａｒｅ　ａｒｃｈｉｔｅｃｔｕｒｅ；ｔｈｒｅａｄｅｄ　ＭＰＩ；ＭＰＩ　ａｃｃｅｌｅｒａｔｏｒ；ＭＰＩＡｃｔｏｒ　认为是一种能够继续保持处理器性能发展遵循摩尔　１　引　言　多核技术，即在同一芯片内包含更多的核心，被　定律的有效手段．在过去的几年中，多核处理器的发　展验证了该手段的有效性，其间处理器内的核心数　目也基本保持每１８个月左右增长一倍①②．可以预　收稿日期：２０１０—０７　１２；最终修改稿收到日期：２０１０－０９—２０．本课题得到国家自然科学创新群体“千万亿次高性能计算关键技术”基金　（６０９２１０６２）资助．刘志强，男，１９８１年生，博ｉ研究生，助理研究员，主要研究方向为并行算法及高效ＭＰＩ基础软件设计与优化．Ｅ－ｍａｉｌ：　ｌｉｕｚｑ＠ｎｕｄｔ．ｅｄｕ．ｃｎ．宋君强，男，１　９６２年生，研究员，博士生导师，主要研究领域为并行算法及数值天气预报．卢风顺，男，１９８２年生，博士　研究生，主要研究方向为并行算法及ＧＰＵ计算．赵①娟，女，１９８１年生，硕士，助理工程师，主要研究方向为并行算法．　Ｉｎｔｄ官方网站．ｈｔｔｐ：／／ｗｗｗ．ｉｎｔｅ１．ｃｏｍ（最后访问时问：２Ｏ１０．６．２２）　②ＡＭＤ官方网站．ｈｔｔｐ：／／ｗｗｗ．ａｍｄ．ｃｏｒｎ（最后访问时间：２０１０．６．２２）　１期　刘志强等：基于线程的ＭＰＩ通信加速器技术研究　见，在相当的一段时问内多核处理器的核心数目还　会持续增长．　在多核处理器高速发展的背景下，近年来，采用　多核处理器的集群系统（简称多核集群）主导了高性　能计算（ＨＰＣ）领域的主流硬件平台．消息传递接口　（ＭＰＩ）是该领域并行程序开发的事实标准．基于　ＭＰＩ的并行程序通过ＭＰＩ运行时库提供的消息传　递接口函数进行通信；随着节点内核心数目的增多，　节点内通信的性能将会对ＭＰＩ程序的整体性能产　生越来越重要的影响．例如当６４个ＭＰＩ进程平均分　布在１６个节点上进行ＨＰＩ　基准测试时，约有５７％　的通信发生在节点内ｕ］．　传统ＭＰＩ基础软件（如ＭＰＩＣＨ２￣、ＯｐｅｎＭＰＩ￣　和ＭＶＡＰＩＣＨ④）的节点内通信性能受限于低效的操　作系统进程问通信．这一问题归因于传统ＭＰＩ基础　软件将每个ＭＰＩ逻辑进程映射为一个操作系统进　程；相应地ＭＰＩ逻辑进程问通信只能通过高代价的　操作系统进程问通信完成，由此带来的性能缺陷难以　通过单纯地改进通信算法来克服．　在２０世纪９０年代末大规模ＳＭＰ系统发展的顶　峰时期，一些工作口一曾针对大规模ＳＭＰ系统对线程　ＭＰＩ（Ｔｈｒｅａｄｅｄ　ＭＰＩ）进行过研究．线程ＭＰＩ即：在共　享内存系统中，将ＭＰＩ逻辑进程映射为同一操作系　统进程中的多个线程．虽然这些早期的工作随着大规　模ＳＭＰ系统淡出市场没有得到延续，但这些工作的　结果表明：线程ＭＰＩ可以通过改进ＭＰＩ程序的运行　机制来提供高效的节点内通信．　理论上线程ＭＰＩ同样是一种可以用于改进多核　系统上节点内通信性能的有效途径．但ＭＰＩ多年来　的发展和用户对ＭＰＩ应用需求的提高使得线程ＭＰＩ　面临两方面的问题．首先，线程ＭＰＩ难以支持ＭＰＩ逻　辑进程内的多线程．支持ＭＰＩ逻辑进程内的多线程　是ＭＰＩ　２．０标准中的一项重要内容④，它的缺失将会　导致多线程应用程序（如基于ＭＰＩ＋ＯｐｅｎＭＰ的应用　程序）无法在线程ＭＰＩ环境中正常运行．其次，传统　的ＭＰＩ基础软件历经数年的发展，规模已非常庞大，　由于底层机制的改变，即使在已有代码的基础上开发　一套完整的线程ＭＰＩ基础软件也需要庞大的工作　量．据我们所知，目前仍无成熟的线程ＭＰ１支撑环境　供用户使用．　为了实现高效的线程ＭＰ１支撑环境，本文提出　了一种基于线程的ＭＰＩ加速器技术，称作ＭＰＩＡｃｔｏｒ．　ＭＰＩＡｃｔｏｒ是一种可协助传统ＭＰＩ软件的透明中间　件，它位于用户ＭＰＩ程序和ＭＰＩ运行时库之间并　对用户ＭＰＩ程序提供线程ＭＰ１支撑环境．传统的　ＭＰ１支撑环境由单一ＭＰＩ运行时库实现所有通信；　引入ＭＰＩＡｃｔｏｒ后，ＭＰ１支撑环境则由独立并低耦　合的两部分运行时库分别完成节点内通信和节点间　通信．ＭＰＩＡｃｔｏｒ的贡献在于：　（１）以低耦合的软件结构化解了线程ＭＰＩ和　ＭＰＩ逻辑进程内多线程之间的矛盾．程序员可以根　据需要在编译期选择是否加入ＭＰＩＡｃｔｏｒ，编译时　加入ＭＰＩＡｃｔｏｒ得到的ＭＰＩ可执行程序是线程　ＭＰＩ的，编译时不加入ＭＰＩＡｃｔｏｒ得到的ＭＰＩ可执　行程序能够支持ＭＰＩ逻辑进程内多线程．　（２）实现了线程ＭＰ１支撑环境并充分利用了传　统的ＭＰＩ基础软件，降低了开发线程ＭＰＩ的难度和　工作量．在基于ＭＰＩ＋ＭＰＩＡｃｔｏｒ的并行程序中，节点　内通信由ＭＰＩＡｃｔｏｒ完成，节点问通信由ＭＰＩＡｃｔｏｒ　转发到下层的ＭＰＩ库完成．因此，ＭＰＩＡｃｔｏｒ可以　专注于实现高效的节点内通信，而对节点间通信只　需实现简单的转发．　（３）不依赖于特定的传统ＭＰＩ基础软件提高节　点内通信性能，即ＭＰＩＡｃｔｏｒ即可用于ＭＶＡＰＩＣＨ２　也可用于ＯｐｅｎＭＰＩ或其它符合ＭＰＩ２．０标准的基　础软件．　我们目前已实现了ＭＰＩＡｃｔｏｒ的基本框架和节　点内点对点通信模块．本文在一个双路四核Ｎｅｈａｌｅｍ　系统　上利用ＯＳＵ　ＬＡＴＥＮＣＹ基准测试③分别在　ＭＶＡＰＩＣＨ２和Ｃ’ｐｅｎＭＰＩ环境中对ＭＰＩＡｃｔｏｒ进　行了性能评测，实验结果表明ＭＰＩＡｃｔｏｒ能够在不　影响节点间通信的情况下有效地提高ＭＰＩ运行环境　的节点内通信性能．在两种ＭＰＩ环境上传输８　ＫＢ～　４　ＭＢ之间的数据时，ＭＰＩＡｃｔｏｒ能够使节点内通信　性能平均提高一倍左右．这些数据表明ＭＰＩ加速器　技术是一种对传统ＭＰＩ基础软件有效的节点内通　信性能优化技术．　本文第２节介绍相关工作；第３节阐述ＭＰＩ—　Ａｃｔｏｒ的工作机制；第４节介绍ＭＰＩＡｃｔｏｒ的通信体　系结构；第５节和第６节介绍实现ＭＰＩＡｃｔｏｒ两个　方面的关键技术：通信操作聚合和基于单次内存拷　贝的节点内点对点通信；第７节在真实平台上进行　①ＭＰＩＣＨ２网站．ｈｔｔｐ：／／ｗｗｗ．ｍｃｓ．ａｎ１．ｇｏｖ／ｍｐｉ／ｍｐｉｃｈ２（最后　访问时间：２０１０．６．２２）　②ＯｐｅｎＭＰＩ网站．ｈｔｔｐ：／／ｗｗｗ．ｏｐｅｎ－ｍｐｉ．ｏｒｇ（最后访问时间：　２０１０．６．１４）　③　ＭⅥ　ＩＣＨ网站．ｈｔｔｐ：／／ｍｖａｐｉｃｈ．ｃｓｅ．ｏｈｉｏ－ｓｔａｔｅ．ｅｄｕ（最后访　问时间：２Ｏ１０．６．１４）　④ＭＰＩ　Ｆｏｒｕｍ　ｗｅｂｓｉｔｅ．ｈｔｔｐ：／／ｗｗｗ．ｍｐｉ－ｆｏｒｕｍ．ｏｒｇ（最后访问　时间：２Ｏ１０．６．１５）　计　算　机　学　报　２０１１年　性能评测；最后一节对本文的工作进行总结并提出　对未来工作的展望和设想．　代码做任何手工改动．我们在下文将基于ＭＰＩ＋　ＭＰＩＡｃｔｏｒ的应用程序简称为ＭＰＩＡｃｔｏｒ程序，相应　的并行作业称为ＭＰＩＡｃｔｏｒ并行作业．本节的以下　２　相关工作　ＭＰＩ标准的制定计划诞生于１９９２年，并于　１９９４年发布第一个版本．ＭＰＩ的初衷是为分布内存　内容首先阐述ＭＰＩＡｃｔｏｒ程序的运行期机制，其次　介绍将ＭＰＩＡｃｔｏｒ加入传统ＭＰＩ程序的编译期　机制．　系统上的消息传递并行编程模式提出统一的标　准④，因此，在基于传统ＭＰＩ基础软件的程序中，每　个逻辑上的ＭＰＩ进程在运行时都将被映射成一个　操作系统进程．　ＭＰＩ具有直观的编程模式和良好的可扩展性，　因此它迅速成为高性能计算领域并行程序设计的事　实标准，并广泛地应用于共享内存系统，如大规模　ＳＭＰ系统．但在共享内存系统中，进程级并行相对　于线程级并行的交互开销往往要大数倍．传统上基　于进程的ＭＰＩ难以发挥出共享内存系统的最佳性　能，于是，早期也有多个工作关注于线程ＭＰＩ¨２　．　Ｔ０ＭＰＩＬ３　和ＭＰＩ～Ｌｉｔｅ　研究在单台共享内存系统　中以线程为单位运行ＭＰＩ程序．ＴＭＰＩ一。　是公开发　布的第一个可以用于共享、分布内存混合系统上的　线程ＭＰＩ．但随着２０００年左右大规模ＳＭＰ系统淡　出市场，这几项线程ＭＰＩ的工作都没有继续下去．　近年来，采用多核处理器的集群系统（简称多核　集群）主导了高性能计算领域的主流硬件平台④．随　着多核处理器的发展，主流集群系统各节点内的计　算核心数目不断增长，节点内通信性能的重要性不　断增加，线程ＭＰＩ又再次被关注．ＡｚｅｑｕｉａＭＰＩ　是　一项目前正在进行中的工作，它是西班牙“Ｉｎｇｅｎｉｏ　２０１０”政府计划＠中的一个子项目，其目标是建立一　套完全支持ＭＰＩ　１．３标准的线程ＭＰＩ基础软件．　不同于ＴＭＰＩ和ＡｚｅｑｕｉａＭＰＩ，ＭＰＩＡｃｔｏｒ以透　明中间件的方式基于传统ＭＰＩ基础软件提供线程　ＭＰＩ环境，从而解耦了线程ＭＰＩ与ＭＰＩ进程内多　线程之间的矛盾．引入ＭＰＩＡｃｔｏｒ后，传统ＭＰＩ基　础软件的结构得到改进，节点内通信和节点问通信　分别由低耦合的独立模块完成，即：传统ＭＰＩ库完　成节点间通信；ＭＰＩＡｃｔｏｒ专注于实现节点内通信．　３　工作机制　如图１所示，ＭＰＩＡｃｔｏｒ通过编译期和运行期　的相关支持使传统的用户ＭＰＩ程序在线程ＭＰＩ环　境中执行，期间不需要用户专门为ＭＰＩＡｃｔｏｒ对源　图１　用户ＭＰＩ程序在编译期被转换为基于ＭＰＩ＋　ＭＰＩＡｃｔｏｒ的可执行程序，运行期在线程ＭＰＩ环境中执行　３．１运行期机制　传统ＭＰＩ程序的运行机制如图２（ａ）所示，在此　运行机制下，每个ＭＰＩ逻辑进程在运行时都被映射　为一个操作系统进程，不论节点内通信还是节点问　通信都通过ＭＰＩ运行时库完成并最终通过某种进　程问通信机制实现．　禽　◇　◇　／＼　（ａ）传统ＭＰＩ程序的运行机制　圃圃…ＭＰＩＡｃｔ０ｒ运行时库　　ＭＰＩ运行时库　◇ｉ　◇　◇　（ｂ）ＭＰＩＡｃｔｏｒ程序的运行机制　图２传统ＭＰＩ程序与ＭＰＩＡｃｔｏｒ程序的运行机制比较　①　Ｔｈｅ　Ｈｉｓｔｏｒｙ　ｏｆ　ＭＰＩ．ｈｔｔｐ：／／ｂｅｉｇｅ．ＵＣＳ．ｉｎｄｉａｎａ．ｅｄｕ／Ｉ５９０／　ｎｏｄｅ５４．ｈｔｍｌ（最后访问时间：２０１０．６．１４）　②Ｔｏｐ５００官方网站．ｈｔｔｐ：／／ｗｗｗ．ｔｏｐ５００．ｏｒｇ（最后访问时　间：２Ｏ１０．６．１５）　③　西班牙Ｉｎｇｅｎｉｏ　２０１０政府计划官方网站．ｈｔｔｐ：／／ｗｗｗ．ｉｎ—　ｇｅｎｉｏ２０１０．ｅｓ（最后访问时间：２０１０．６．１５）　１期　刘志强等：基于线程的ＭＰＩ通信加速器技术研究　１５７　ＭＰＩＡｃｔｏｒ程序的运行机制如图２（ｂ）所示，在　ＭＰＩＡｃｔｏｒ的支持下，同节点的ＭＰＩ逻辑进程被映　函数ｍａｉｎ改名为ｍｐｉ—ｍａｉｎ；（２）将全局变量和静态　变量改为线程局部存储（ｔｈｒｅａｄ　ｌｏｃａｌ　ｓｔｏｒａｇｅ）　］的　射为同一进程（称容器进程）中的多个线程．这些线　程由容器进程的主线程根据ＭＡｒｕｎ传人的参数派　生，其中ＭＡｒｕｎ是用来提交ＭＰＩＡｃｔｏｒ并行作业的　变量；（３）将程序中调用的非线程安全的函数（如　ｇｅｔｏｐｔ）改为调用ＭＰＩＡｃｔｏｒ运行时库中相应线程安　全的函数．　脚本程序，它将用户命令参数分解，一部分传递给　在编译和链接阶段，ＭＡｃｃ利用ｍｐｉｃｃ完成对　ＭＰＩ作业提交器，另一部分传递给容器进程．　ＭＰＩＡｃｔｏｒ运行时库为ＭＰＩ逻辑进程构建了以　预编译转换后代码的编译和链接工作．在编译阶段，　ＭＡｃｃ指定ｍｐｉ．ｈ的路径到ＭＰＩＡｃｔｏｒ提供的ｍｐｉ．ｈ．　在链接阶段，ＭＡｃｃ添加ＭＰＩＡｃｔｏｒ的运行时库．　线程为单位执行的基础结构，它位于用户ＭＰＩ程序　和ＭＰＩ运行时库之间，处理运行时用户ＭＰＩ程序　中的ＭＰＩ调用，其中节点内通信由ＭＰＩＡｃｔｏｒ运行　时库单独完成，节点间通信由ＭＰＩＡｃｔｏｒ转发到底　层的ＭＰＩ库完成．我们将这种由ＭＰＩＡｃｔｏｒ协同标　准ＭＰＩ库处理ＭＰＩ通信调用的方法称为通信操作　聚合技术，它是ＭＰＩＡｃｔｏｒ成为透明中间件的关键　技术之一，将在本文的第５节中详细阐述．　３．２编译期机制　为了不给用户增加额外的工作量，ＭＰＩＡｃｔｏｒ　在改变ＭＰＩ程序运行方式的同时保持了传统的　ＭＰＩ编程模式．但在传统的ＭＰＩ编程模式中存在一　个潜在假设：每个ＭＰＩ逻辑进程都有独立的内存地　址空间．传统基于进程的ＭＰＩ恰好自然地满足这一　假设，因此用户在编写ＭＰＩ程序时往往习惯于使用　全局变量实现ＭＰＩ逻辑进程全局范围内的数据共　享或者使用静态变量实现对数据的静态访问．不幸　的是基于线程的ＭＰＩ无法满足这一假设，若不改变　用户的编程习惯，就需要对线程ＭＰＩ提供编译期　支持．　在ＭＰＩＡｃｔｏｒ的支撑软件中，ＭＡＣＣ（ＭＰＩＡｃｔｏｒ　Ｃ　Ｃｏｍｐｉｌｅｒ）为基于ＭＰＩＡｃｔｏｒ的Ｃ语言程序提供　编译期支持．它的工作原理如图３所示，由用户　ＭＰＩ程序源代码到ＭＰＩＡｃｔｏｒ可执行程序需要经过　３个阶段：预编译、编译和链接．　面　图３　ＭＡｃｃ的上作过程　在预编译阶段，ＭＡｃｃ将用户ＭＰＩ程序代码转　换为线程安全的程序代码，确保用户ＭＰＩ程序在映　射为同一进程中多个线程执行时彼此的数据空间无　重叠．ＭＡｃｃ主要完成３项工作：（１）将程序的人口　目前我们正在设计用于编译Ｆｏｒｔｒａｎ语言和　Ｃ＋＋语言程序的编译器，其工作步骤与ＭＡｃｃ类　似，但需要注意的是Ｆｏｒｔｒａｎ语言目前还不支持线　程局部存储，支持Ｆｏｒｔｒａｎ语言程序的预编译器要　比用于Ｃ和Ｃ＋＋语言的预编译器复杂得多．通过　编译期的支持，用户可不对原程序代码作任何修改　将基于传统ＭＰＩ软件的程序代码编译成基于　ＭＰＩ＋ＭＰＩＡｃｔｏｒ的可执行程序．　４通信体系结构　ＭＰＩＡｃｔｏｒ的通信体系结构是实现通信操作聚　合和节点内通信的基础．如图４所示，在此通信体系　结构中，Ｎ个ＭＰＩ逻辑进程问通过　个虚拟通道　实现点对点通信，即任意一对ＭＰＩ逻辑进程ＰＡ和　Ｐ　对应两个独立的虚拟通道Ｃｎ　和Ｃ　．　Ｐ　ｌ　４　ＭＰＩＡｃｔｏｒ的通信体系结构　若　和Ｐ。属于同一节点，则Ｃ　和Ｃ　ｎ为节点　内通信虚拟通道（ＯＮ－ｈｏｓｔ　Ｖｉｒｔｕａｌ　Ｃｈａｎｎｅｌ，（）ＮＶＣ），　它是ＭＰｌＡｃｔｏｒ实现节点内通信的物理基础结构，　节点内通信操作在此基础上实施．图４中的每个灰　色圆形都表示一个ＯＮＶＣ，ＯＮＶＣ是单向通信通　道，它被接收端ＭＰＩ逻辑进程创建并由发送端ＭＰＩ　逻辑进程持有引用指针，即Ｃ　用于Ｐｎ发送消息到　１５８　ｉ１一　算　机　学　报　ｐ　，Ｃ。　用于相反方向通信．另外，ＯＮＶＣ内包含　３个用于实现节点内点对点通信的先入先出（ＦＩＦＯ）　Ａｃｔｏｒ的运行机制，ＭＰＩ通信请求须根据其通信位　置特征由不同的运行时库处理，因此ＭＰＩＡｅｔｏｒ在　队列：接收请求队列、发送请求队列和ａｎｙｓｏｕｒｃｅ接　收请求队列．节点内通信的细节部分将在本文第６　节中详细讨论．　若Ｐ　和Ｐ　属于不同节点，则（　ｎｅ和Ｃ　为节　点间通信虚拟通道（ＯＦｆ—ｈｏｓｔ　Ｖｉｒｔｕａｌ　Ｃｈａｎｎｅｌ，　ｏＦＶＣ）．与ＯＮＶＣ不同，ＯＦＶＣ并不作为节点间通　重载ＭＰＩ接口时需要在过程中辨别通信的类型，我　们称这一过程为通信请求分离，简称ＣＲＳ（Ｃｏｍｍｕ—　ｎｉｃａｔｉｏｎ　Ｒｅｑｕｅｓｔ　Ｓｅｐａｒａｔｉｎｇ），它是通信操作聚合过　程中的第一个关键步骤．　从ＣＲＳ的输入角度看可将ＭＰＩ通信请求分为　两类，具体分类如表１所示．　信的物理基础结构，仅缓存用于转发节点间通信所　需的一些必要信息，包括远端节点ｒａｎｋ（Ｒｅｍｏｔｅ　Ｎｏｄｅ　Ｒａｎｋ，ＲＮＲ）、发送标记基数（Ｓｅｎｄ　Ｔａｇ　Ｂａｓｅ，　ＳＴＢ）和接收标记基数（Ｒｅｃｅｉｖｅ　Ｔａｇ　Ｂａｓｅ，ＲＴＢ）．　图４中的白色圆形表示ＯＦＶＣ，ＯＦＶＣ是双向通信　通道，它由各个进程创建并独立持有，即Ｃｎｅ由Ｐｎ　持有并缓存与Ｐ。通信的相关信息，Ｃ。　由Ｐ　持有　并存放与Ｐ　通信的相关信息．　５通信操作聚合技术　通信操作聚合是ＭＰｌＡｃｔｏｒ整合自身运行时库　与底层标准ＭＰＩ库实现ＭＰＩ通信语义的关键技　术．其基本过程如图５所示，我们将每一次ＭＰＩ通　信接口调用作为一次通信请求，ＭＰＩＡｃｔｏｒ程序发　出的通信请求首先经由“通信请求分离”过程判断通　信属于何种类型，再根据通信的类型将请求递交给相　应的聚合过程处理．本节将详细讨论这一关键技术．　Ｅ　ＭＰ１库中的　处理过程　通信操作　返回结果　图５通信操作聚合过程框图　５．１通信请求分离　在多核集群系统上，ＭＰＩ消息传递通信究竟发　生在节点间还是在节点内是一个运行时特征，我们　称此特征为通信位置特征，ＭＰＩ标准中定义的通信　接口语义并不区分类似的运行时特征．根据ＭＰＩ—　表１从ＣＲＳ角度分类ＭＰＩ通信请求　第１类通信请求须根据接口参数进行ＣＲＳ．　ＭＰＩＡｃｔｏｒ通过虚拟通道通信体系结构建立了ＭＰＩ　逻辑进程问的通信关系，在此基础上第１类通信请　求通过输人参数获取虚拟通道，并根据通道的类型　判断通信请求的通信位置特征．　另一类通信请求根据通信请求对象中的通信位　置特征进行通信请求分离，其中这些通信请求对象　由第１类通信请求的非阻塞通信过程返回．　经由ＣＲＳ过程，ＭＰＩ通信请求将会被传递给　ＭＰＩＡｃｔｏｒ的通信过程、标准ＭＰＩ库的通信过程或　ＭＰＩＡＮＹ～ＳＯＵＲＣＥ处理过程作进一步处理．　５．２节点间通信请求的转发方法　设ｒ为输入ＭＰＩＡｃｔｏｒ的通信请求，若ｒ对应　的通信发生在节点间，则ｒ会被ＭＰＩＡｃｔｏｒ转发到　底层的标准ＭＰＩ库处理，在此过程中ＭＰＩ库需要　知道与对方节点容器进程中的哪个线程进行消息交　互，这是节点间通信请求转发需要解决的问题．本小　节将以转发节点间ＭＰＩ—Ｉｒｅｅｖ请求为例详细讨论节　点间通信请求转发的方法及规则．我们有以下定义．　定义１（通信请求对象）．　通信请求对象是一　个三元组ＣＲ０一＜Ｓ，Ｄ，Ｔ＞，其中：　５一（ｉ　ｉ∈Ｎ，０　ｉ＜Ｐ　｝Ｕ｛ＭＰＩ—ＡＮＹ—　ＳＯＵＲＣＥ）表示通信源ＭＰＩ进程，其中Ｐ…为ＭＰＩ　辑进程个数．　Ｄ一｛ｉ｝ｉ　Ｅ　Ｎ，Ｏ　＜Ｐ　）表示通信目的ＭＰＩ　进程．　丁一｛ｔ　ｆ￡Ｅ　Ｎ）Ｕ（ＭＰＩ—ＡＮＹ—ＴＡＧ）表示通信　标记．　１期　刘志强等：基于线程的ＭＰＩ通信加速器技术研究　１５９　定义２（接收请求）．　接收请求是一个二元组　ＲＲ一（Ｓ，丁＞，表示从源ＭＰＩ进程接收某标记的数　据，其中Ｓ和Ｊ『的定义同定义１．　定义３（ＭＰＩ进程的节点位置）．　称ＭＰＩ进程　所在的节点为节点位置：　ｎｐｏｓ：Ｐｒｏｃ　Ｎｏｄｅ，　其中Ｐｒｏｃ，Ｎｏｄｅ＇Ｓ＿Ｎ，ｎｐｏｓ（　）能够得到ＭＰＩ进程　Ｐ的节点位置．　定义４（非阻塞接收）．　非阻塞接收以非阻塞　方式处理接收请求并返回一个通信请求对象：　ＭＰＩ—Ｉｒｅｃｖ：｛Ｐ｝×ＲＲ—　ＣＲ０．　ＭＰＩ—Ｉｒｅｃｖ（Ｐ，（Ｓ，　））一（Ｐ，Ｓ，ｆ），其中Ｐ为当前　ＭＰＩ进程的进程序列号（ｒａｎｋ）．　对非阻塞接收ＭＰＩ—Ｉｒｅｃｖ（Ｐ，＜Ｓ，ｔ＞），在Ｓ不等　于ＭＰＩ—ＡＮＹ—ＳＯＵＲＣＥ的情况下，如果ｎｐｏｓ（　）不　等于ｎｐｏｓ（ｓ），则＜Ｓ，ｔ＞需要被转换为＜Ｓ　，ｔ　＞并通过　底层ＭＰＩ库中的ＭＰＩ—Ｉｒｅｃｖ（Ｐ　，（Ｓ　，ｔ　））操作完成　通信，其中：　Ｐ　一ｎｐｏｓ（ｐ）。ｓ　一ｎｐｏｓ（ｓ）．　当ｔ不等于ＭＰＩ—ＡＮＹ—ＴＡＧ时：　ｔ　＝Ｌ（ｓ）《ｏｆｆｓｅｔ　＋Ｌ（户）《ｏｆｆｓｅｔ　＋ｔ，　其中ｏ＿，ｆｓｅｔ　和ｏｆｆｓｅｔ　分别表示发送位置偏移和接　收位置偏移，Ｌ（ｚ）表示ＭＰＩ进程　的本地进程号．　可知ＭＰＩＡｃｔｏｒ程序进行节点通信时源进程和目的　进程通过底层ＭＰＩ接口中的通信标记参数识别．另　外，若　为Ｐ到Ｓ的通信虚拟通道，则有　Ｃ　ｒｔｂ＝＝＝Ｓ《ｏｆｆｓｅｔ　十Ｐ《ｏｆｆｓｅｔ　＋ｔ，　其中Ｃ　ｒｔｂ为Ｃ　中的接收标记基数．在实现节点　间通信请求转发时可利用此基数转换通信标记．　当ｆ—ＭＰＩ—ＡＮＹ—ＴＡＧ时，　一ｔ，此类型的节　点间通信将通过ＭＰＩＡｅｔｏｒ内置的特殊过程处理．　５一ＭＰＩ—ＡＮＹ—ＳＯＵＲＣＥ情况下的通信请求处理方　法将在５．３节讨论．　５．３对ＭＰＩ＿ＡＮＹ＿ＳＯＵＲＣＥ类型请求的处理方法　ＭＰＩ—ＡＮＹ—ＳＯＵＲＣＥ可作为ＭＰＩ接收（Ｒｅｃｖ）　或检查（Ｐｒｏｂｅ）接口中“数据源进程号”的参数值，表　示任意数据源．当ＭＰＩ程序调用接收或检查操作时　的“数据源进程号”参数值为ＭＰＩ—ＡＮＹ—ＳＯＵＲＣＥ　时，算法无法通过输入参数的静态值确定其发出的通　信请求对应节点间通信还是节点内通信，我们称此类　通信请求为ＭＰＩ—ＡＮＹ—ＳＯＵＲＣＥ类型的请求，或　简称ＡＳＲ（Ａｎｙ　Ｓｏｕｒｃｅ　Ｒｅｑｕｅｓｔｓ）类型的请求．　ＡＳＲ通过专门的处理过程协同ＭＰＩＡｃｔｏｒ通　信库和ＭＰＩ通信库中的通信操作完成，涉及此类　通信的ＭＰＩ接口有ＭＰＩ—ＲｅＣＶ、ＭＰＩ—Ｉｒｅｃｖ、ＭＰＩ—　Ｉｐｒｏｂｅ、ＭＰＩ—Ｐｒｏｂｅ和所有第２类通信请求接口．　本小节的以下内容将以ＭＰＩ—Ｉｐｒｏｂｅ为例讨论　针对ＡＳＲ的处理方法．ＭＰ１一Ｉｐｒｏｂｅ操作的定义为　ＭＰＩ—Ｉｐｒｏｂｅ（ＳＯＵｔ＇Ｃｅ，ｔａｇ，￣ｏｍＴｉｑ，ｆｌａｇ，ｓｔａｔｕｓ），　其语义是在不实际接收输入消息的情况下检查是否　收到ＣＯＤ＇ｔＴｌ＂ｌ通信域中源为Ｓ０１￣＇ｇ＇ＣＣ标记为ｔａｇ的消　息．当调用ＭＰＩ—Ｉｐｒｏｂｅ“数据源进程号”参数的值为　ＭＰＩ—ＡＮＹＳＯＵＲＣＥ时，通信请求由ＣＲＳ传给　ＡＳＲＭＰＩ—Ｉｐｒｏｂｅ处理，其定义和算法如图６所示．　ＡＳＲ—ＭＰＩ—Ｉｐｒｏｂｅ算法通过ＭＰＩ—Ｉｐｒｏｂｅ检查　并获取发送给所属容器进程的节点间通信消息，若收　到则根据获取到的信息检查消息是否为发送给本　ＭＰＩ逻辑进程的消息；另一方面，ＡＳＲ＿ＭＰＩ　Ｉｐｒｏｂｅ通　过检查虚拟通道的发送队列检查是否有节点内通信．　图６　ＡＳＲ—ＭＰＬＩｐｒｏｂｅ算法　除ＡＳＲ　ＭＰＩ—Ｉｒｅｃｖ外，其余ＡＳＲ通信请求对　应的处理方法在基本原理上都与ＡＳＲ—ＭＰＩ—Ｉｐｒｏｂｅ　算法相似．ＡＳＲ　ＭＰＩ—Ｉｒｅｃｖ较为特殊的原因是它的　非阻塞数据接收机制，如何协同ＭＰＩＡｅｔｏｒ通信库　和ＭＰＩ通信库有效实现这一机制是一个难点．ＡＳＲ　ＭＰＩＩｒｅｅｖ的基本原理是若通过ＭＰＩ—Ｉｐｒｏｂｅ未发　现匹配的请求则同时启动节点内ＭＰＩ—Ｉｒｅｃｖ通信和　节点间ＭＰＩ＿Ｉｒｅｃｖ通信，然后在接收到数据后再对其　中一个选择性取消．为此我们在ＭＰＩＡｅｔｏｒ的通信体　系结构中为每一个ＭＰＩ逻辑进程增加了一个ａｎｙ—　ｓｏｕｒｃｅ请求队列，并将其连人虚拟通道．ＡＳＲ　ＭＰＩ—　Ｉｒｅｃｖ的实现方法我们将在后续工作中详细介绍．　６基于单次内存拷贝的　节点内点对点通信　基于单次内存拷贝的节点内点对点通信是　１６０　计　算　机　学　报　２０１１薤　ＭＰＩＡｃｔｏｒ提高通信性能最重要的技术手段之一．　在ＭＰｌＡｃｔｏｒ程序的运行机制下，若点对点通　信发生在节点内则源ＭＰＩ进程中的发送缓冲区和　目的ＭＰＩ进程中的接收缓冲区都属于同一进程地　址空间，进而节点内点对点通信可自然地通过单次　内存拷贝实现．　本节的以下内容主要讨论ＭＰＩＡｃｔｏｒ中基于单　步骤进行通信请求匹配，第２个步骤根据第１个步　骤的运行时结果选择创建或处理通信请求．　发送算法的第１个步骤遍历虚拟通道的接收请　求队列并获取第１个匹配的通信请求对象ｒｅｑ，此过　程的时间复杂度为０（ｎ）．算法第２个步骤的两个分　支分别对应成功获取匹配的通信请求对象和未获取　通信请求对象的情况，如果成功获取匹配的通信请　求对象ｒｅｑ则将ｒｅｑ从接收请求对列中移出并根据　请求中的接收缓存地址和大小完成数据拷贝；如果未　次内存拷贝的点对点通信算法．另外，为了更清晰地　说明ＭＰＩＡｃｔｏｒ节点内通信的性能优势，我们将在　最后一个小节详细介绍基于核心态内存映射的单次　获取匹配的通信请求对象则申请一个新的通信请求　对象并填充本次发送请求的信息，之后加入发送请求　队列．两个步骤都在虚拟通道访问锁的保护下进行．　接收算法与发送算法的结构相同，具体过程对　偶．图７用黑体标记了两种算法的区别．　内存拷贝机制并与之进行比较．　６。１　节点内单次拷贝点对点通信算法　ＭＰＩＡｃｔｏｒ中的节点内点对点通信算法如图７　所示，包括相互配合的发送算法和接收算法．接收和　发送算法的基本结构类似，均包含两个步骤：第１个　算法．Ｉｎｔｒａ—ＭＰＩ—Ｓｅｎｄ．　输入：ｂｕｆ，ｂｓｉｚｅ，ｄｅｓｔ，ｔａｇ，ｔ．＇ＯｌｎｌＨ　输出：ｂｕｆ　ＢＥＧＩＮ　算法．１ｎｔｒａ～ＭＰｌ—Ｒｅｃｖ．　输入：Ｃｏｕ￣ｔ，ＳＦ￣，ｔａｇ，ｃ０　输出：ｂｕｆ　ＢＥＧＩＮ　／＊步骤１＊／　通过本进程号（ｒａｎｋ）和ｄｅｓｔ从ＣＯｌＹｌ？？Ｉ对应的通信域对象中得　到通信虚拟通道ＣＶＣ：　ｍｕｔｅｘｌｏｃｋ（＆ＣＶＣ．７￣ｂｔｔｅｌ－）；／／＊加锁＊　／Ｘ步骤１＊　通过本进程号（ｒａｎｋ）和Ｓ７％从ＣＯ？ｌｑｔＹｌ对应的通信域对象中得　到通信虚拟通道ＣＶＣ；　ｒｎｕｔｅｘｌｏｃｋ（Ｃ　．ｍｕｔｅｘ）；／＊加锁＊／　ｒ钾　ＣＶＣ．ｒｅｅｖｒｅｑ—ｑｕｅｕｅ．ｈｅａｄ；　ＩＦ　ｒｅｑ！　ＮＵＩ　Ｌ　ｒｅｑ　ＣＶＣ．ｓｅｎｄｒｅｑｑｕｅｕｅ．ｈｅａｄ；　—ＩＦ　ｒｅｑ　ｌ：ＮＵＩ　Ｉ　ＷＨＩＩ　Ｅ（ｒｅｑ！：ＮＵＬＩ　＆＆　ｒｅ口一＞ｓｔａｔｅ＞ＷＡＩＴＦＯＲＡＮＳＷＥＲ＆＆　ＷＨＩＬＥ（ｒｅｑ！一ＮＵ１　１　＆＆　ｒＰｑ一＞ｓｔａｔｅ￣ＷＡＩＴＦＯＲ　ＡＮＳＷＥＲ＆＆　ｒｅｑ与本发送请求匹配）　ｒｅｑ　ｒｅｑ一＞￣ｌｅｉｔ；　ｒｅｑ与本接收请求匹配）　ｒＰｑ—ｒｅｑ～＞ｎｅｘｔ；　ＥＮＤ　ＥＮＤ　／＊步骤２＊／　ＩＦ　ｒｅｑ！＝ＮＵＬＬ　／　＊步骤２＊　ＩＦ　ｒｅｑ　ｆ＝ＮＵＩ　Ｌ　—ｄｅｑｕｅｕｅ（ＣＶＣ．ｒｅｃｖｒｅｑＥＬＳＥ　ｑｕｅｕｅ，ｒｅｑ）；／＊将ｒｅｑ＆｛歹０＊　ｍｅｍｃｐｙ（ｒｅｑ一＞ｒｅｃｖｂｕｆ，ｂｕｆ，ｒｅｑ＂￣＞ｂｓｉｚｅ）；　ｄｅｑｕｅｕｅ（ＣＶＣ．ｓｅｎｄｒｅｑ—ｑｕｅｕｅ，ｒｅｑ）；／＊将ｒｅｑ出列＊／　ｍｅｍｃｐｙ（ｂｕｆ，ｒｅｑ－－￣ｓｅｎｄｂｕｆ，ｂｓｉｚｅ）；　ＥＩ　ＳＥ　申请一个新的通信请求对象ｒｅｑ，并初始化；　ｒｅｑ一＞ｓｅｎｄｂｕｆ＝　“，；　ｅｎｑｕｅｕｅ（ＣＶＣ．ｓｅｎｄｒｅｑｑｕｅｕｅ，ｒｅｑ）：／＊将ｒｅｑ人列＊／　申请一个新的通信请求对象ｒｅｑ，并初始化；　ｒｅｑ—＞ｒｅｃｖ妇ｆ＝＝ｂｕｆ；　ｅｎｑｕｅｕｅ（ＣＶＣ．ｒｅｃｖｒｅｑｑｕｅｕｅ，ｒｅｑ）；／＊将ｒｅｑ入列＊／　ＥＮＤ　ｍｕｔｅ２ｄＥＮＤ　ｕｎｌｏｃｋ（＆ＣＶＣ．ｍｕｌＰ　ｒ）；／／　解锁＊／　ｍｕｔｅａ－ｕｎｌｏ￣ｋ（＆ＣＶＣ．ｍｕｔｅｘ）；／＊解锁＊／　ＥＮＩ）　ＥＮＤ　（ａ）发送算法　（ｂ）接收算法　匿ｆ　７　节点内点对点通信算法　６．２进程间单次内存拷贝的点对点通信　于该通信机制的通信过程仅需单次内存拷贝．　ＫＢＭＭＣＭ的基本原理如图８（ａ）所示．　传统的ＭＰＩ软件通常基于用户态共享内存实　现节点内点对点通信，通信的基本原理是将源ＭＰＩ　进程中的消息拷贝到共享内存的缓冲区，再从共享　ＫＢＭＭＣＭ需要在系统中建立一个内核模块，此模　块可通过相应的ＫＢＭＭ驱动进行使用．　基于ＫＢＭＭＣＭ的点对点通信过程主要通过　６步完成：　１．发送端将发送缓冲区的起始地址　厂厂和缓冲区大　小ｓｉｚｅ发送给ＫＢＭＭ驱动．　内存缓冲区拷贝到目的ＭＰＩ进程中的接收缓冲区，　整个通信过程需要通过两次内存拷贝．　近年来的一些工作（如ＭＶＡＰＩＣＨ　２中的ＬｉＭｉＣＥ。］　和ＯｐｅｎＭＰＩ中的ＫＮＥＭ　）为传统的进程ＭＰＩ提　出了一种新的节点内点对点通信机制：基于核心态　内存映射的通信机制（Ｋｅｒｎｅｌ　Ｂａｓｅｄ　Ｍｅｍｏｒｙ　Ｍａｐ—　ｐｉｎｇ　Ｃｏｍｍｕｎｉｃａｔｉｏｎ　Ｍｅｃｈａｎｉｓｍ，ＫＢＭＭＣＭ），皋　２．ＫＢＭＭ接收到　和ｓｉｚｅ后将发送进程的进程指　针（ｃｕｒｒｅｎｔ）、内存指针（ｃｕｒｒｅｎｔ一＞ｍｍ）、ｂｕ＿厂，占用的页大　小等信息存在一个数据结构ｋｂｍｍ一５中返回给发送进程．　１期　刘志强等：基于线程的ＭＰＩ通信加速器技术研究　釜　一　Ｃ　Ｌ　用户态空问　ｌ，核心态空间『　～　核心态虚拟地址　（ａ）基于核心态内存映射的　（ｂ）ＭＰＩＡｃｔｏｒ中的ＭＰＩ逻辑　进程间点对点通信　进程间点对点通信　网８单次内存拷贝点对点通信机制的比较　３．发送进程将ｋｂｍｍ—Ｓ打包并通过ＭＰＩ点对点通信发　送给接收端．　４．接收端将ｋｂｍｍ—Ｓ发送给ＫＢＭＭ驱动，ＫＢＭＭ驱　动根据ｋｂｍｍ—Ｓ得到发送缓冲区的页列表ｐａｇｅｓ—ｌｉｓｔ．　５．ＫＢＭＭ驱动通过ｋｒｎａｐ将ｐａｇｅｓ—ｌｉｓｔ映射到一个核　心态内存地址ｋｂｕｆｆ．　６．将ｋａｕＪ７拷贝到接收缓冲区．　此过程只需一次内存拷贝，但同时会产生较大　的处理开销，在某些情况下处理开销甚至会超过减少　一次内存拷贝带来的收益，造成性能下降，因此基于　核心态内存映射是一种重量级的单次内存拷贝机制．　与之相比ＭＰＩＡｃｔｏｒ中的单次内存拷贝机制不　需要进行繁琐的内存转换过程，是一种轻量级的通　信机制．　７实验与结果　７．１实验环境与方法　我们的实验环境是一个１２８个节点的双路四核　Ｎｅｈａｌｅｍ集群（本文实验只需要其中的两个节点），每　个节点都包含两颗Ｘｅｏｎ　Ｅ５５４Ｏ处理器和３２　ＧＢ内　存，测试时处理器主频为２．５３　ＧＨｚ，外频为１０６６　ＭＨｚ．　操作系统采用Ｒｅｄｈａｔ　Ｌｉｎｕｘ　Ｅｎｔｅｒｐｒｉｓｅ　４．　我们实验的性能测试工具采用ＯＳＵ　Ｂｅｎｃｈ—　ｍａｒｋ中的ＯＳＵ—ＬＡＴＥＮＣＹ，其内部采用ｐｉｎｇ—　ｐｏｎｇ测试方法，是一种用于测试ＭＰＩ点对点通信　性能的通用工具．　通过ＯＳＵ—Ｉ　ＡＴＥＮＣＹ，我们的实验分为两个　部分：第１部分的实验用于评测在ＭＶＡＰＩＣＨ２基　础上ＭＰＩＡｃｔｏｒ节点内通信的性能，对比以下ＭＰＩ　通信配置的性能：　（１）基于用户级共享内存的ＭＶＡＰＩＣＨ２　１．４；　（２）基于ＬｉＭｉＣ的ＭＶＡＰＩＣＨ２　１．４；　（３）ＭＶＡＰＩＣＨ２　１．４＋ＭＰＩＡｃｔｏｒ．　另外，在这一部分实验中我们还将对比节点问　通信的性能，目的是为了测试经ＭＰＩＡｃｔｏｒ转发通　信后性能是否会受到显著影响．　第２部分的实验用于评测在ＯＰＥＮＭＰＩ基础　上ＭＰＩＡｃｔｏｒ节点内通信的性能，对比以下ＭＰＩ通　信配置的性能：　（１）基于用户级共享内存的ＯＰＥＮＭＰＩ　１．５ａｌ；　（２）基于ＫＮＥＭ的ＯＰＥＮＭＰＩ　１．５ａｌ；　（３）ＯＰＥＮＭＰＩ　１．５ａ１＋ＭＰＩＡｃｔｏｒ．　对以上每一种配置我们都分别测试了处理器内　通信和处理器间通信．　７．２实验结果与分析　将两部分实验结果综合，可以得出如图９～　图１１的实验结果．可以发现，ＭＰＩＡｃｔｏｒ有效的提　高了ＭＶＡＰＩＣＨ２和ＯｐｅｎＭＰＩ的节点内点对点通　信的性能，同时对节点问通信性能几乎不造成影响．　处理器内的通信性能评测结果如图９所示，相　对于基于用户级共享内存的ＭＶＡＰＩＣＨ２，ＭＰＩＡｃ—　ｔｏｔ在传输大小为８　ＫＢ－－２５６　ＫＢ的消息时通信性能　提高了３７　～ｌ１４　；在传输２５６　ＫＢ～２　ＭＢ的消息　时性能提高了６８　～１１１　；在传输４ＭＢ－－８ＭＢ的　消息时性能提高了６Ｏ　～１２　．相对于（）ｐｅｎＭＰＩ，　ＭＰＩＡｃｔｏｒ在传输大小为８ＫＢ￣２５６ＫＢ的消息时通　信性能提高了４８　～９１　；在传输２５６　ＫＢ～２　ＭＢ　字节的消息时性能提高了４７　～１０６　；在传输　４ＭＢ－－８ＭＢ的消息时性能提高了５６　～１０　．另　外，Ｉ　ｉＭｉＣ在传输大小为１６　ＫＢ－－２５６　ＫＢ数据时性　能提高了５　～３５　，但在传输其余大小区间的消　息时通信性能较使用用户态共享内存的ＭＶＡＰＩ—　ＣＨ２有明显下降；ＫＮＥＭ对处理器内点对点通信　的性能没有任何提高，我们进行多次实验都得到了　相似的结果．　处理器间的通信性能评测结果如图１Ｏ所示，相　对于基于用户级共享内存的ＭＶＡＰＩＣＨ２，ＭＰＩＡｃ—　ｔｏｒ在传输大小为８　ＫＢ～２５６　ＫＢ的消息时通信性能　提高了３０　～１４４　；在传输２５６ＫＢ～２ＭＢ的消息　时性能提高了７４　～１１７％；在传输２　ＭＢ～１６　ＭＢ　的消息时性能提高了４４　～６４　．相对于　ＯｐｅｎＭＰＩ，ＭＰＩＡｃｔｏｒ在传输大小为８　ＫＢ～２５６　ＫＢ　的消息时通信性能提高了４６　～９８　；在传输　２５６ＫＢ～２ＭＢ的消息时性能提高了７Ｏ　～７２　；　传输２　ＭＢ～１６　ＭＢ的消息时性能提高了３８　～　７Ｏ％．另外，ＬｉＭｉＣ在传输３２ＫＢ～４ＭＢ的数据时有　１６２　计　算　机　学　报　２０１１在　３７　Ａ～９８　的性能提升，在传输更大的消息时性能　０节点问通信的性能比较如图１１所示，可以发现　节点间通信经由ＭＰＩＡｃｔｏｒ转发性能几乎不受影响．　十＋＋—有５％左右的提升．　ＭＶＡＰＩＣＨ２　１．４　ＭＶＡＰＩＣＨ２　１．４（ＬｉＭｉＣ）　ＭＶＡＰＩＣＨ２　１．４＋ＭＰＩＡｃｔｏｒ　Ｅ　＾一（）ｐｅｎＭＰＩ　１．５　十ＯｐｅｎＭＰＩ　１．５（Ｋｎｅｍ）　—争－Ｏｉ￣ｅｎＭＰＩ　１．５＋ＭＰＩＡｃｔｏｒ　露　剁　茸一　５１２Ｋ　１　Ｍ　２　Ｍ　４Ｍ　８Ｍ　ｌ６Ｍ　消息大ｄ￣／Ｂｙｔｅ　消息大小／Ｂｙｔｅ　（ｂ）长消息（＞２５６　ＫＢ）通信　（ａ）短消息（　２５６　ＫＢ）通信　７　６　５　４　３　２　１　羞　删　上　７　６　５　４　３　２　１　消息大ｄ￣／Ｂｙｔｅ　（ｃ）相对于ＭＶＡＰＩＣＨ２　１．４的加速比　消息大ｄ￣／Ｂｙｔｅ　（ｄ）相对ＪａＯｐｅｎＭＰＩ　１．５ａｌ的加速比　图９处理器内点对点通信延迟　｝一ＭＶＡＰｌＣＨ２　１．４　｝一ＭＶＡＰＩＣＨ２　１．４（ＬｉＭｉＣ）　—　——・一ＭＶＡＰＩＣＨ２　１．４＋ＭＰＩＡｃｔｏｒ　一皇　ＯｐｅｎＭＰＩ　１．５　ＯｐｅｎＭＰＩ　１　５（Ｋｎｅｒｏ）　ＯｐｅｎＭＰＩ　１．５＋ＭＰＩＡｃｔｏｒ　——　露　露　牛　５ｌ２Ｋ　１　Ｍ　２Ｍ　４Ｍ　８Ｍ　１６Ｍ　消息大ｄ￣／Ｂｙｔｅ　（ａ）短消息（　２５６　ＫＢ）通信　消息大ｄ￣／Ｂｙｔｅ　（ｂ）长消息（＞２５６　ＫＢ）通信　羞　心　口　蔓　删　舞　消息大ｄｘ／Ｂｙｔｅ　消息大ｄＶＢｙｔｅ　（ｃ）相对于ＭＶＡＰＩｃＨ２　１．４的加速比　（ｄ）相对于ＯｐｅｎＭＰＩ　１．５ａｌ的加速比　１Ｏ处理器间点对点通信延迟　刘志强等：基于线程的ＭＰＩ通信加速器技术研究　１６３　１Ｏ　９　８　７　ｇ　ｓ　＼　５　３　２　１　消息大ｄｘ／Ｂｙｔｅ　消息大ｄ，／Ｂｙｔｅ　（ａ）短消息（≤２５６　ＫＢ）通信　（ｂ）长消息（＞２５６　ＫＢ）通信　图１１　点问点对点通信延迟　ｒｕｎｔｉｍｅ　ｓｕｐｐｏｒｔ　ｆｏｒ　ｔｈｒｅａｄｅｄ　ＭＰＩ　ｅｘｅｃｕｔｉｏｎ　ｏｎ　ｓｈａｒｅｄ　ｍｅｍｏｒｙ　８总结和未来的工作　ｍａｃｈｉｎｅｓ．ＡＣＭ　Ｔｒａｎｓａｃｔｉｏｎｓ　ｏｎ　Ｐｒｏｇｒａｍｍｉｎｇ　Ｌａｎｇｕａｇｅｓ　ａｎｄ　Ｓｙｓｔｅｍｓ，２０００，２２（４）：６　７３　７０Ｏ　［３］　Ｄｅｍａｉｎｅ　Ｅ　Ｄ．Ａ　ｔｈｒｅａｄｓ　ｏｎｌｙ　ＭＰＩ　ｉｍｐｌｅｍｅｎｔａｔｉｏｎ　ｆｏｒ　ｔｈｅ　ｄｅ—　ＭＰＩ加速器是一种对传统ＭＰＩ基础软件有效　ｖｅｌｏｐｍｅｎｔ　ｏｆ　ｐａｒａｌｌｅｌ　ｐｒｏｇｒａｍｓ／／ｔ　ｒｏｃｅｅｄｉｎｇｓ　ｏｆ　ｔｈｅ　１　１　ｔｈ　Ｉｎ　的通信性能优化技术．它以透明中间件的形式提供　ｔｅｒｎａｔｉｏｎａｌ　Ｓｙｍｐｏｓｉｕｍ　ｏｎ　Ｈｉｇｈ　Ｐｅｒｆｏｒｍａｎｃｅ　Ｃｏｍｐｕｔｉｎｇ　Ｓｙｓ　了一个线程ＭＰＩ运行环境．采用这种形式，ＭＰＩ　ｔｅｍｓ．Ｗｉｎｎｉｐｅｇ，Ｍａｎｉｔｏｂａ，Ｃａｎａｄａ。１　９９７：ｌ５３　１６３　Ａｃｔｏｒ一方面解耦了线程ＭＰＩ与ＭＰＩ进程内多线　［，Ｉ　Ｐｒａｋａｓｈ　Ｓ，Ｂａｇｒｏｄｉａ　Ｒ．Ｍｔ　Ｉ　ＳＩＭ：Ｕｓｉｎｇ　ｐａｒａｌｌｅｌ　ｓｉｍｕｌａｔｉｏｎ　程之间的矛盾，另一方面简化了线程ＭＰＩ软件的开　ｔｏ　ｅｖａｌｕａｔｅ　ＭＰＩ　ｐｒｏｇｒａｍｓ／／Ｐｒｏｃｅｅｄｉｎｇｓ　ｏｆ　ｔｈｅ　Ｗｉｎｔｅｒ　Ｓｉｍｕｌａ　ｔｉｏｎ．Ｉ　ｏｓ　ＡｌａｍｉｔＯｓ．ＣＡ，ＵＳＡ，１　９９８：４６７　４７４　发工作量．　［５］　Ｓａｉｎｉ　Ｓ，Ｎａｒａｉｋｉｎ　Ａ　ｅｔ　ａ１．Ｅａｒｌｙ　ｐｅｒｆｏｒｍａｎｃｅ　ｅｖａｌｕａｔｉｏｎ　ｏｆ　ａ　实验表明：　Ｎｅｈａｌｅｍ”ｃｌｕｓｔｅｒ　ｕｓｉｎｇ　ｓｃｉｅｎｔｉｆｉｃ　ａｎｄ　ｅｎｇｉｎｅｅｒｉｎｇ　ａｐｐｌｉｃａ—　（１）ＭＰＩＡｃｔｏｒ能够有效地全面提高传统ＭＰＩ　ｔｉｏｎｓ／／Ｐｒ０ｃｃｅｄｌｎｇｓ　ｏｆ　ｔｈｅ　ＳＣ’０９．　Ｎｅｗ　Ｙｏｒｋ，ＵＳＡ，２００９，　软件的节点内通信性能，同时不影响节点问通信　Ａｒｔｉｃｌｅ　２，１，１　２　ｐａｇｅｓ　性能．　［６］　Ｄｉａｚ　Ｍａｒｔｉｎ　Ｊ　Ｃ。Ｒｉｃｏ　Ｇａｌｌｅｇｏ　Ｊ　Ａ　ｅｔ　ａ１．Ａｎ　ＭＰＩ　１　ｃｏｒｎ　ｐｌｉａｎｔ　ｔｈｒｅａｄ　ｂａｓｅｄ　ｉｍｐｌｅｍｅｎｔａｔｉｏｎ／／Ｐｒｏｃｅｅｄｉｎｇｓ　ｏｆ　ｔｈｅ　ＥｕｒｏＰＶＭ／　（２）线程ＭＰＩ的点对点通信比ＬｉＭｉＣ和　ＭＰ１　２００９．Ｂｅｒｌｉｎ，Ｈｅｉｄｅｌｂｅｒｇ，２００９：３２７　３２８　ＫＮＥＭ等基于核心级内存映射机制的点对点通信　［７］　Ｓａｄｅ　Ｙ。Ｓａｇｉｖ　Ｓ，Ｓｈａｈａｍ　Ｒ．Ｏｐｔｉｍｉｚｉｎｇ　Ｃ　ｍｕ１ｔｉｔｈｒｅａｄｅｄ　优化方法更高效．　ｍｅｍｏｒｙ　ｍａｎａｇｅｍｅｎｔ　ｕｓｉｎｇ　ｔｈｒｅａｄ　ｌｏｃａｌ　ｓｔｏｒａｇｅ／／Ｐｒ。ｃｅｅｄｉｎｇｓ　下一步我们将在ＭＰＩＡｃｔｏｒ的基础上通过基于　ｏｆ　ｔｈｅ　ＣＣ’０５．Ｂｅｒｌｉｎ，Ｈｅｉｄｅｌｂｅｒｇ。２００５：１３７—１　５５　共享内存的算法进一步优化集合通信性能．　［８　Ｊｉｎ　Ｈ　Ｗ・Ｓｕｒ　Ｓ，Ｃｈａｉ　Ｉ　，Ｐａｎｄａ　Ｄ　Ｋ．ＬｉＭＩＣ：Ｓｕｐｐｏｒｔ　ｆｏｒ　ｈｉｇｈ—　ｐｅｒｆｏｒｍａｎｃｅ　ＭＰＩ　Ｉｎｔｒａ——Ｎｏｄｅ　ｃｏｍｍｕｎｉｃａｔｉｏｎ　ｏｎ　Ｌｉｎｕｘ　ｃｌｕｓｔｅｒ，／，／Ｐｒｏｃｅｅｄｉｎｇｓ　ｏｆ　ｔｈｅ　ＩＣＰＰ’０５．Ｗａｓｈｉｎｇｔｏｎ，ＤＣ，ＵＳＡ，　参　考　文　献　２００５：１　８４　ｉ９１　［９］　Ｍｏｒｅａｕｄ　Ｓ，Ｇｏｇｌｉｎ　Ｂ，Ｇｏｏｄｅｌ１　Ｄ，Ｎａｍｙｓｔ　Ｒ．Ｏｐｔｉｍｉｚｉｎｇ　ＭＰＩ　［１］　Ｃｈａｉ　Ｌ，　Ｇａｏ　Ｑ，Ｐａｎｄａ　Ｄ　Ｋ．　Ｕｎｄｃｒｓｔａｎｄｉｎｇ　ｔｈｅ　ｉｍｐａｃｔ　ｏｆ　ｃｏｍｍｕｎｉｃａｔｉｏｎ　ｗｉｔｈｉｎ　ｌａｒｇｅ　ｍｕｈｉｃｏｒｅ　ｎｏｄｅｓ　ｗｉｔｈ　ｋｅｒｎｅｌ　ａｓｓｉｓ—　ｍｕｈｉ　ｃｏｒｅ　ａｒｃｈｉｔｅｃｔｕｒｅ　ｉｎ　ｃｌｕｓｔｅｒ　ｃｏｍｐｕｔｉｎｇ：Ａ　ｃａｓｅ　ｓｔｕｄｙ　ｔａｎｃｅ／／ｔ　ｒｏｃｅｅｄｉｎｇｓ　ｏｆ　ｔｈｅ　Ｗｏｒｋｓｈｏｐ　ｏｎ　Ｃｏｍｍｕｎｉｃａｔｉｏｎ　Ａｒ　ｗｉｔｈ　ＩｎｔｅＩ　Ｄｕａｌ（：ｏｒｅ　ｓｙｓｔｅｍ／／Ｐｒｏｃｅｅｄｉｎｇｓ　ｏｆ　ｔｈｅ　ＣＣＧｒｉｄ’０７．　ｃｈｉｔｅｃｔｕｒｅ　ｆｏｒ　Ｃｌｕｓｔｅｒｓ，ｈｅｌｄ　ｉｎ　Ｃｏｎｊｕｎｃｔｉｏｎ　ｗｉｔｈ　ＩＰＤＰＳ　２Ｏ１０．　Ｒｉｏ　ｄｅ　Ｊａｎｅｉｒｏ，Ｂｒａｚｉｌ，２００７：４７１　４　７８　Ａｔｌａｎｔａ，ＵＳＡ，２Ｏ１０　［２］　Ｔａｎｇ　Ｈ，Ｓｈｅｎ　Ｋ，Ｙａｎｇ　Ｔ．Ｐｒｏｇｒａｍ　ｔｒａｎｓｆｏｒｍａｔｉｏｎ　ａｎｄ　ＬＩＵ　Ｚｈｉ—Ｑｉａｎｇ，ｂｏｒｎ　ｉｎ　１９８１，Ｐｈ．ｎ　ＳＯＮＧ　Ｊｕｎ—Ｑｉａｎｇ，ｂｏｒｎ　ｉｎ　１９６２，Ｍ．Ｓ．，ｐｒｏｆｅｓｓｏｒ，　ｃａｎｄｉｄａｔｅ．Ｈｉｓ　ｒｅｓｅａｒｃｈ　ｉｎｔｅｒｅｓｔｓ　ｉｎｃｌｕｄｅ　Ｐｈ．Ｄ．ｓｕｐｅｒｖｉｓｏｒ．Ｈｉｓ　ｒｅｓｅａｒｃｈ　ｉｎｔｅｒｅｓｔｓ　ｉｎｃｌｕｄｅ　ｐａｒａｌｌｅｌ　ａｌ—　ｐａｒａｌｌｅｌ　ａｌｇｏｒｉｔｈｍ　ａｎｄ　ＭＰＩ（Ｍｅｓｓａｇｅ　ｇｏｒｉｔｈｍ　ａｎｄ　ｎｕｍｅｒｉｃａｌ　ｗｅａｔｈｅｒ　ｆｏｒｅｃａｓｔ．　Ｐａｓｓｉｎｇ　Ｉｎｔｅｒｆａｃｅ）ｉｎｆｒａｓｔｒｕｃｔｕｒｅ　ｓｏｆｔ—　ＬＵ　Ｆｅｎｇ－Ｓｈｕｎ．ｂｏｒｎ　ｉｎ　１　９８２，Ｐｈ．Ｄ．ｃａｎｄｉｄａｔｅ．Ｈｉｓ　ｒｅ—　ｗａｒｅ　ｄｅｓｉｇｎ．　ｓｅａｒｃｈ　ｉｎｔｅｒｅｓｔｓ　ｆｏｃｕｓ　ｏｎ　ｐａｒａｌｌｅｌ　ａｌｇｏｒｉｔｈｍ　ａｎｄ　ＧＰＵ　ｃｏｍｐｕｔｉｎｇ．　ＺＨＡＯ　Ｊｕａｎ，ｂｏｒｎ　ｉｎ　１９８１，Ｍ．Ｓ．，ａｓｓｉｓｔａｎｔ　ｅｎｇｉｎｅｅｒ．　Ｈｅｒ　ｒｅｓｅａｒｃｈ　ｉｎｔｅｒｅｓｔｓ　ｆｏｃｕｓ　ｏｎ　ｐａｒａｌｌｅｌ　ａｌｇｏｒｉｔｈｍ．　１６４　Ｂａｃｋｇｒｏｕｎｄ　汁　算　机　学　报　２０１１正　Ｔｏｄａｙ，ＭＰＩ　ｉｓ　ｔｈｅ　ｄｅ　ｆａｃｔｏ　ｐａｒａｌｌｅｌ　ｐｒｏｇｒａｍｍｉｎｇ　ｓｔａｎｄ　ａｒｄ　ｉｎ　ＨＰＣ　ｄｏｍａｉｎ．Ｉｎ　ｍｏｓｔ　ＭＰＩ　ａｐｐｌｉｃａｔｉｏｎｓ，ｔｈｅ　ｃｏｍｍｕｎｉ—　ｃａｔｉｏｎ　ｉｓ　ｐｅｒｆｏｒｍｅｄ　ｂｙ　ＭＰＩ　ｏｐｅｒａｔｉｏｎｓ，ａｎｄ　ｔｈｅ　ｐｅｒｆｏｒｍａｎｃｅ　ｍｕｈｉｃｏｒｅ　ｔｅｃｈｎｏｌｏｇｙ，ｔｈｅ　ｎｕｍｂｅｒ　ｏｆ　ｃｏｒｅｓ　ｉｎ　ｅａｃｈ　ｎｏｄｅ　ｗｉｌｌ　ｇｒｏｗ　ａｎｄ　ｔｈｅ　ｐｒｏｐｏｒｔｉｏｎ　ｏｆ　ｉｎｔｒａ—ｎｏｄｅ　ｃｏｍｍｕｎｉｃａｔｉｏｎ　ｗｉｌｌ　ｂｅ　１ａｒｇｅｒ．　ｏｆ　ｔｈｅｓｅ　ｏｐｅｒａｔｉｏｎｓ　ｉｓ　ｉｍｐｏｒｔａｎｔ　ｔＯ　ｔｈｅ　ｇｌｏｂａｌ　ｐｅｒｆｏｒｍａｎｃｅ　ａｎｄ　ｉｓ　ｔｈｅ　ｋｅｙ　ｆａｃｔｏｒ　ｆｏｒ　ｔｈｅ　ｓｃａｌａｂｉｌｉｔｙ　ｏｆ　ｐａｒａｌｌｅｉ　ｐｒｏｇｒａｍｓ．　Ｒｅｃｅｎｔ　ｙｅａｒｓ，ｔｈｅ　ｄｅｖｅｌｏｐｍｅｎｔ　ｏｆ　ｍｕｌｔｉｃｏｒｅ　ｔｅｃｈｎｏｌｏｇｙ　ｃａｕｓｅｓ　ａ　ｒｅｖｏｌｕｔｉｏｎ　ｏｎ　ｈａｒｄｗａｒｅ　ｅｎｖｉｒｏｎｎｌｅｎｔｓ　ｏｆ　ｐａｒａｌｌｅｌ　ｃｏｍｐｕｔｉｎｇ，ａｎｄ　ｆｕｒｔｈｅｒ　ｉｔ　ｐｏｓｅｓ　ａ　ｎｅｗ　ｃｈａｌｌｅｎｇｅ　ｔｏ　ＭＰＩ　ｉｎ　ｆｒａｓｔｒｕｃｔｕｒｅ　ｓｏｆｔｗａｒｅ　ｆｏｒ　ｅｆｆｅｃｔｉｖｅｌｙ　ｓｕｐｐｏｒｔｉｎｇ　ＭＰＩ　ｐｒｏ—　ｇｒａｍｓ．Ｈｏｗ　ｔｏ　ｐｒｏｖｉｄｅ　ｈｉｇｈ　ｐｅｒｆｏｒｍａｎｃｅ　ＭＰＩ　ｓｏｆｔｗａｒｅ　ｅｎｖｉ—　ｒｏｎｍｅｎｔｓ　ｏｎ　ｍｕｈｉｅｏｒｅ　ｓｙｓｔｅｍｓ　ｉｓ　ｃｒｉｔｉｃａｌ　ｆｏｒ　ｗｈｅｔｈｅｒ　ａ　ＭＰＩ　ｐｒｏｇｒａｍ　ｃａｎ　ｕｔｉｌｉｚｅ　ｃｕｒｒｅｎｔ　ｈａｒｄｗａｒｅ　ｅｆｆｅｃｔｉｖｅｌｙ．　Ｔｈｉｓ　ｗｏｒｋ　ｆｏｃｕｓｅｓ　ｏｎ　ｈｏｗ　ｔＯ　ｉｍｐｒｏｖｅ　ｔｈｅ　ｐｅｒｆｏｒｍａｎｃｅ　ｏｆ　ｉｎｔｒａ—ｎｏｄｅ　ｃｏｍｍｕｎｉｃａｔｉｏｎ．Ｉｔ　ｉＳ　ｏｎｅ　ｏｆ　ｔｈｅ　ｋｅｙ　ｐｒｏｂｌｅｍｓ　ｆｏｒ　ＭＰＩ　ｉｎｆｒａｓｔｒｕｃｔｕｒｅ　ｏｎ　ｍｕｈｉｃｏｒｅ　ｓｙｓｔｅｍｓ．Ｗｉｔｈ　ｔｈｅ　ｇｒｏｗｔｈ　ｏｆ　Ｈｏｗｅｖｅｒ，ｔｈｅ　ｃｏｎｖｅｎｔｉｏｎａｌ　ＭＰＩ　ｂａｓｅｄ　ｐｒｏｇｒａｍｓ　ａｒｅ　ｓｕｆｆｅｒｉｎｇ　ｆｒｏｍ　ｐｏｏｒ　ｉｎｔｒａ—ｎｏｄｅ　ｃｏｍｍｕｎｉｃａｔｉｏｎ　ｐｅｒｆｏｒｍａｎｃｅ．　ＭＰ１　ｗａｓ　ｏｒｉｇｉｎａｌｌｙ　ｄｅｓｉｇｎｅｄ　ｔｏ　ｂｅ　ａｄｏｐｔｅｄ　ｏｎ　ｄｉｓｔｒｉｂｕｔｅｄ—　ｍｅｍｏｒｙ　ｍａｃｈｉｎｅｓ．Ｓｏ，ｉｎ　ａ　ｃｏｎｖｅｎｔｉｏｎａｌ　ＭＰＩ　ｂａｓｅｄ　ｐｒｏ—　ｇｒａｍ，ｅａｃｈ　ｌｏｇｉｃ　ＭＰＩ　ｐｒｏｃｅｓｓ　ｉｓ　ｍａｐｐｅｄ　ｔｏ　ａｎ　ＯＳ　ｐｒｏｃｅｓｓ．　Ａｎｄ　ｎａｔｕｒａｌｌｙ，ｉｎｔｒａ—ｎｏｄｅ　ｃｏｍｍｕｎｉｃａｔｉｏｎｓ　ａｒｅ　ｐｅｒｆｏｒｍｅｄ　ｂｙ　ｈｅａｖｙ—ｗｅｉｇｈｔｅｄ　ｉｎｔｅ￣ｐｒｏｅｅｓｓ　ｃｏｍｍｕｎｉｃａｔｉｏｎｓ．　Ｔｏｗａｒｄｓ　ｔｈｉｓ　ｐｒｏｂｌｅｍ，ｔｈｉｓ　ｗｏｒｋ　ｔｒｉｅｓ　ｔｏ　ｂｕｉｌｄ　ｔｈｅ　ｍｏｒｅ　ｅｆｆｅｃｔｉｖｅ　ｍｅｃｈａｎｉｓｍ　ｆｏｒ　ｒｕｎｎｉｎｇ　ＭＰＩ　ｐｒｏｇｒａｍｓ．Ｔｈｉｓ　ｗｏｒｋ　ｉｓ　ｓｕｐｐｏｒｔｅｄ　ｂｙ　ｔｈｅ　Ｎａｔｉｏｎａｌ　Ｓｃｉｅｎｃｅ　Ｆｏｕｎｄａｔｉｏｎ　ｆｏｒ　Ｉｎｎｏｖａｔｉｎｇ　Ｇｒｏｕｐ（６０９２１０６２）