当前位置:企业应用软件行业动态 → 正文

寻找适合并行编程模型的中间件

责任编辑:editor005 作者:Tom Nolle |来源:企业网D1Net  2016-06-08 14:37:19 本文摘自:TechTarget中国

并行计算有助于应用和资源管理的合理化,但是为此方案找到找到合适的中间件却是很棘手的问题。Tom Nolle解释了应该寻找什么。

一些计算功能跟流程绑定得如此紧密,以至于如果可以(在处理器内核之间、CPU与GPU之间甚至跨系统边界)有效共享的话就可以获得极大的好处。并发性一直都是通过多线程、同步以及锁定技术来支持的,但现在有了中间件工具以后可以让并发更容易实现。为了选出最好的,你需要理解你的并发编程应用的需求,考虑应用的来源和方向,最后还要了解一些政治的并行处理语言,即便你并不认为自己需要这样的语言。

大多数业务流程最好是评估为一组过程或者步骤,其后者往往要取决于前面的过程或步骤的结果。这种线性的方案几乎归纳了所有现代软件开发的特点,编程语言和中间件工具已经为此进行了优化演进。

一些包括了复杂的流程和计算的应用可以利用传统的工具和语言开发,但也可以受益于用额外系统、处理器或者内核的形式分配多个并行处理资源。对这些流程的优化支持需要为并行流程的同步提供安身之处,以确保数据在可用之前不会被使用或者流程不会在资源使用中发生冲突。锁和信号量是并发性的固定装置,但是很难调试,在伸缩性方面受限。

并发模型由何构成?

并行计算的挑战之一是确定“并行”究竟是什么意思。一些人认为任何形式的并发性支持就是并行编程,这样的话网格或集群计算以及多实例云和微服务应用都算是。有的则认为这种模型应该泛化到包括任何形式的跨并行资源的任务分布。考虑的出发点之一是随着时间转移会出现更多的并行选项,所以把自己限定在任何受限模型之内也许不是明智之举。

结果证明,使用并行编程的大多数机会都与特定算法的实现以及可用更高级语言声明的算法有关。如果该语言的解释以及结果代码的执行是由中间件管理的话,那它天生就是资源敏捷且并发友好的,就有可能避免一切传统的并发问题。

即便是更高级的语言—所谓的“非过程性”语言—也可用为并行编程模型框定起点。因为这些语言表达的上意图而不是过程,这些是可用语言处理器而不是靠开发者来并行化的。这说明了一条普遍事实:语言越高级,程序的并行化越容易—只要有合适中间件的话。反之,如果使用了更低级的过程性编程模型,那模型就不得不从目前的概念、包括哪些现在用来支持并发线程的概念进行演变,以便优化性支持并行选项。

确定模型

所有的并行编程都应该从用什么语言开始,有半打的基本模型可以确定语言。第一种并行模型优化了当前语言并引入了并发性的概念。最新的模型比如X10,是专门用来进行一般化的并行编程的。别的像Smalltalk和LINQ属于非过程性的,适合于并行编程,如果使用合适的中间件的话。

集群和网格计算中间件工具,甚至RESTful API以及微服务也可以使用Java、C#、MPI、PALM等语言来开发“并行”应用,Active Message中间件(全部都是开源的)在大多数支持并发开发的语言中都可以使用。还有一些是针对Java、C#、C++等特定语言的中间件工具。这些模型更容易采用,但很难让并行性支持多核或者多选题网格这样的一般事情。开发者可能还会发现显式任务同步的需求很难实现。

微软的LINQ和PLINQ就是从传统应用向并行计算演进的一般模型的例子。LINQ有助于定义表示计算模型而不是计算方法的算法。PLINQ是一款.NET中间件工具,这个工具可以管理这些算法的并行执行,这样应用就可以开发为将算发性要素从过程部分分离出来。Java 8也有类似的能力,因为它采用了Streams和一种合适的数据库模型。高性能Fortran (High-Performance Fortran)是一种支持并行处理的算法型语言。

这些方案还是需要开发者适应并行性,要么通过在编程中树立意识,要么要做算法处理中隐藏好它。由IBM发起作为开源项目开发的X10语言侧采取了不同的办法。它通过创建围绕着place以及异步任务这样的新概念开发的并行友好型过程性编程模型修改了“过程性”编程的概念。跟非过程性方案不一样的是,X10让开发者开发和管理并行性而不是隐藏它。

考虑你的目标

并行编程路径的数量令人眼花缭乱,很可能还会变得更加复杂。对于开发团队而言,考虑的关键是应用的来源和方向。如果你进行的是传统的商业化编程,希望给特定的算法处理增加并行支持的话,那可以看看针对特定语言的并发性中间件或者PLINQ。如果你更关心并行性而不是集群(网格)计算或微服务的话,把前者看成是基本方案。后者用来针对一般的并行化。

作为要素,开发的方向更难考虑进并行编程规划里面,这仅仅是因为很难知道有哪些选项。业界的一般硬件趋势正朝着每处理器内核数量更高、每小题处理器更多的方向发展。从更高的层面来说,这股趋势正朝着组件化以及计算、存储和网络功能分离的方向发展。即便中间件也日益被视为“服务”,系统展示的只是非常轻量的操作系统,并汇总微服务之类的平台功能。

这一基本事实是的像X10之类的东西成为合理选择。X10有一个基于Eclpse的开发环境,为了方便执行框架是用Java编写的。X10社区有着很好的文档和向导,对于任何计划使用并行编程模型的组织来说,花点时间学习这门语言并理解在系统—集群层次对并行性的适应会影响到语言结构和中间件工具是明智的。要想充分意识到一门看不见的技术之潜能总是很困难的,并行相关的开发最终也会证明这一点。

关键字:中间件编程应用并行编程

本文摘自:TechTarget中国

x 寻找适合并行编程模型的中间件 扫一扫
分享本文到朋友圈
当前位置:企业应用软件行业动态 → 正文

寻找适合并行编程模型的中间件

责任编辑:editor005 作者:Tom Nolle |来源:企业网D1Net  2016-06-08 14:37:19 本文摘自:TechTarget中国

并行计算有助于应用和资源管理的合理化,但是为此方案找到找到合适的中间件却是很棘手的问题。Tom Nolle解释了应该寻找什么。

一些计算功能跟流程绑定得如此紧密,以至于如果可以(在处理器内核之间、CPU与GPU之间甚至跨系统边界)有效共享的话就可以获得极大的好处。并发性一直都是通过多线程、同步以及锁定技术来支持的,但现在有了中间件工具以后可以让并发更容易实现。为了选出最好的,你需要理解你的并发编程应用的需求,考虑应用的来源和方向,最后还要了解一些政治的并行处理语言,即便你并不认为自己需要这样的语言。

大多数业务流程最好是评估为一组过程或者步骤,其后者往往要取决于前面的过程或步骤的结果。这种线性的方案几乎归纳了所有现代软件开发的特点,编程语言和中间件工具已经为此进行了优化演进。

一些包括了复杂的流程和计算的应用可以利用传统的工具和语言开发,但也可以受益于用额外系统、处理器或者内核的形式分配多个并行处理资源。对这些流程的优化支持需要为并行流程的同步提供安身之处,以确保数据在可用之前不会被使用或者流程不会在资源使用中发生冲突。锁和信号量是并发性的固定装置,但是很难调试,在伸缩性方面受限。

并发模型由何构成?

并行计算的挑战之一是确定“并行”究竟是什么意思。一些人认为任何形式的并发性支持就是并行编程,这样的话网格或集群计算以及多实例云和微服务应用都算是。有的则认为这种模型应该泛化到包括任何形式的跨并行资源的任务分布。考虑的出发点之一是随着时间转移会出现更多的并行选项,所以把自己限定在任何受限模型之内也许不是明智之举。

结果证明,使用并行编程的大多数机会都与特定算法的实现以及可用更高级语言声明的算法有关。如果该语言的解释以及结果代码的执行是由中间件管理的话,那它天生就是资源敏捷且并发友好的,就有可能避免一切传统的并发问题。

即便是更高级的语言—所谓的“非过程性”语言—也可用为并行编程模型框定起点。因为这些语言表达的上意图而不是过程,这些是可用语言处理器而不是靠开发者来并行化的。这说明了一条普遍事实:语言越高级,程序的并行化越容易—只要有合适中间件的话。反之,如果使用了更低级的过程性编程模型,那模型就不得不从目前的概念、包括哪些现在用来支持并发线程的概念进行演变,以便优化性支持并行选项。

确定模型

所有的并行编程都应该从用什么语言开始,有半打的基本模型可以确定语言。第一种并行模型优化了当前语言并引入了并发性的概念。最新的模型比如X10,是专门用来进行一般化的并行编程的。别的像Smalltalk和LINQ属于非过程性的,适合于并行编程,如果使用合适的中间件的话。

集群和网格计算中间件工具,甚至RESTful API以及微服务也可以使用Java、C#、MPI、PALM等语言来开发“并行”应用,Active Message中间件(全部都是开源的)在大多数支持并发开发的语言中都可以使用。还有一些是针对Java、C#、C++等特定语言的中间件工具。这些模型更容易采用,但很难让并行性支持多核或者多选题网格这样的一般事情。开发者可能还会发现显式任务同步的需求很难实现。

微软的LINQ和PLINQ就是从传统应用向并行计算演进的一般模型的例子。LINQ有助于定义表示计算模型而不是计算方法的算法。PLINQ是一款.NET中间件工具,这个工具可以管理这些算法的并行执行,这样应用就可以开发为将算发性要素从过程部分分离出来。Java 8也有类似的能力,因为它采用了Streams和一种合适的数据库模型。高性能Fortran (High-Performance Fortran)是一种支持并行处理的算法型语言。

这些方案还是需要开发者适应并行性,要么通过在编程中树立意识,要么要做算法处理中隐藏好它。由IBM发起作为开源项目开发的X10语言侧采取了不同的办法。它通过创建围绕着place以及异步任务这样的新概念开发的并行友好型过程性编程模型修改了“过程性”编程的概念。跟非过程性方案不一样的是,X10让开发者开发和管理并行性而不是隐藏它。

考虑你的目标

并行编程路径的数量令人眼花缭乱,很可能还会变得更加复杂。对于开发团队而言,考虑的关键是应用的来源和方向。如果你进行的是传统的商业化编程,希望给特定的算法处理增加并行支持的话,那可以看看针对特定语言的并发性中间件或者PLINQ。如果你更关心并行性而不是集群(网格)计算或微服务的话,把前者看成是基本方案。后者用来针对一般的并行化。

作为要素,开发的方向更难考虑进并行编程规划里面,这仅仅是因为很难知道有哪些选项。业界的一般硬件趋势正朝着每处理器内核数量更高、每小题处理器更多的方向发展。从更高的层面来说,这股趋势正朝着组件化以及计算、存储和网络功能分离的方向发展。即便中间件也日益被视为“服务”,系统展示的只是非常轻量的操作系统,并汇总微服务之类的平台功能。

这一基本事实是的像X10之类的东西成为合理选择。X10有一个基于Eclpse的开发环境,为了方便执行框架是用Java编写的。X10社区有着很好的文档和向导,对于任何计划使用并行编程模型的组织来说,花点时间学习这门语言并理解在系统—集群层次对并行性的适应会影响到语言结构和中间件工具是明智的。要想充分意识到一门看不见的技术之潜能总是很困难的,并行相关的开发最终也会证明这一点。

关键字:中间件编程应用并行编程

本文摘自:TechTarget中国

电子周刊
回到顶部

关于我们联系我们版权声明隐私条款广告服务友情链接投稿中心招贤纳士

企业网版权所有 ©2010-2024 京ICP备09108050号-6 京公网安备 11010502049343号

^