请教：分布式计算接口的问题

(Y)

分布式计算的任务分配需要交互信息。
目前看BOINC用的文件方式。包括算法和数据都用的文件。的确兼容性非常好，但是交互的速度太慢了。

我在想，如果改用接口的方式来交互信息呢？先不说算法，数据的交互如果用借口来传递。是否可行，是否可以有一种兼容性好的通用接口。它是否存在很多优势呢？

如果可以。那类接口比较适合？如何编译效率更高，更容易被调用？

请大家指点。

feynord

呼唤JUST。。。

JUST

来了。。。
不过我没怎么看过BOINC的文档。。。

不太明白你说“数据的交互如果用借口来传递”，能否举个具体点的例子
一个数据文件应该要被计算很长时间的，计算之中的数据应该都在一个进程中的，没有交互的代价

(Y)

阿，终于有人回复啦。

boinc很简单的，用的是文件传输来交互计算任务信息。

但是它的延时很长。一次交互（任务下载和结果上传）都是分钟级甚至小时级的。
两边的程序先发信息变成文件，通过ftp服务进行传输。过程非常慢。
所以文件传输方式只能适合非常松散耦合的任务。


接口传递一般是秒级的。比如说在论坛上发帖子、浏览网页，用的是http服务传递信息。所以可以使用于耦合度更加紧密地任务。随着以后会联网速度的提高，接入更加稳定。甚至ipv6的时候，每个设备都是固定ip。接口的方式也会更加有优势。

一个好的接口除了可以用在互联网上的分布式计算，可以适用于局域网内甚至告诉互联的集群内分布式计算。

目前的操作系统还不能支持分布式任务，只能应用程序层面来支持，因为操作系统不知道应用程序的分布式计算的要求，无法对其任务的分布进行优化。这个工作只能由应用程序根据自己特点来设计分布的模式。这个情况会在很长时间内存在。所以我想和大家探讨一下。接口方式是否可行。

JUST

BOINC本身并不限制你去做这些交互。客户端的程序是native的，你可以随便来写。

不过BOINC的设计就是为SETI-like的程序提供平台，他不必考虑别的应用场景。BOINC的模型就是一种离线式的的协同计算，他不期望网络成本很高。

你所说的场景更像是RPC或者MPI，当然他们都是比较底层的协议。

(Y)

我说的更类似于RPC。
MPI是从代码级支持并行的库。而不是架构级分布的东东。需要非常紧密的耦合。

RPC是一种C/S模式的远程调用的应用级上层协议。更像是提供某种服务的方式。也是一种很不错的思路。

谢谢JUST。


相对于编译级的并行，我认为架构级的分布式设计更有效果。可以不用重新培训大量的程序员，只要架构师调整策略就可以了。

JUST

不客气

自动并行一直是一个很热的话题，有些编译器，如ICC，可以做到一些基础的向量化（指令级并行）和线程并行。更多的需要编译制导语句来完成，比如openmp。关键问题是编译器难以挖掘并行。

另外，对于一个问题，其串行算法不一定可以被直接并行。很多情况下，并行算法和串行算法完全不同。除非编译器能够直接理解问题本身，否则不可能从串行算法生成并行版本。

这些还都是本地的并行，都是shared memory模型。对于message模型，就更复杂了，还要考虑通信成本，可靠性。

其实并行本身就是针对性能的，而所有针对性能的优化一定是特化的，用很general的方法来解决就不太适合。

彬彬

楼主的意思就像是网络计算的实现方法，各节目随时都在线，不像当前分布式计算的实现方法。只有自己可控的场合才能要求它能快速、随时按需进行信息交换。在分布式计算这种场合，你根本没办法控制任何一个计算节点何时上线，所以都是尽可能地设计成少数据交换，因为不需要数据交换的时候就是在计算，假如需要交换而不在线没法交换时，那就是浪费计算时间在等待。而且，一个动不动就要算几天的任务，几天才上传下载一次，它在分钟还是小时的级别也不重要了。假如现在定期交换需要一个小时的话，一个小时的交换肯定要传很多东西，要传这么多东西的话，难道你想要人家天天交换，然后每天只传其中一部分? 那不是跟前面说的一样吗? 假如它今天不上线，交换不了，那它可能就停下来，等待你上线。


有些任务只求一个计算结果，所以结果的数据量不大，返回给服务器的时间就很快，上传可能一两分钟就搞定。但有些任务是需要返回整个计算过程中生成的大量数据，所以就要传好久喽。

像原来算 PI 的时候，假如是保留所有位的话，那每个包所生存的数据文件之大是可想而知，估计这样的任务也很难搞，因为网络需求太大了。

(Y)

JUST真是研究很核心的东东呢。我在上学的时候还看过共享内存的介绍。那是并行机才能实现的东西吧。连集群都未必能达到的互联速度。

我们平时多是接触boinc的那些项目。都是极度松散的任务。和JUST不是一个技术层面的。

8楼估计也都是习惯了弱耦合的任务。那我来举一个适合适合更快速交互的例子吧。

比如我们的任务是寻找一个适合某个条件的最大值。或者说是比已知最大值更大的值。
当一个计算者。忽然找到一个更大值得时候。就意味着，还在计算着比这个数值小的任务都作废了。这时候需要通过所有该任务的计算者。新的已知最大值已经更新要所有作废任务的计算机重新领取新任务。
当然这个模式不符合目前boinc的积分模式。但也就是可以做那些超出目前范围的任务。

(Y)

也就是说，任务的偏序中涉及到计算结果影响后续的计算内容、范围或方法。都需要计算单元和任务管理服务器有更紧密地交互。来减少计算上的无用功。

再一个例子。
一个项目是从100个因素中来寻找规律。比如CPDN类的（但CPDN不是按照如下方法进行。）
项目由100组任务组成，每组任务来重点寻找一个因素的规律和其他因素与这个因素之间的关系。
每组任务都由大量的wu组成。分配给不同的计算单元。
每个因素的规律是否容易寻找在计算前是不十分确定的，就导致有些因素的规律很快被找出来了。有些则摸索的很漫长。
已经计算出的因素应该尽快地通知还在计算其它因素的计算节点。减少它们寻找中的不确定性。优化他们的算法。

这样的情况在目前BOINC项目中是很难实现的。

JUST

对于现在大部分桌面多处理器系统来说，都是共享内存模型。cluster有一些还是能够让节点之间快速通信的，但就算再快也和本地内存访问速度差几个量级

至于让Internet实现更紧耦合的应用，达到现在cluster的水平，估计至少也要10年

彬彬

原帖由 JUST 于 2009-7-4 23:13 发表
对于现在大部分桌面多处理器系统来说，都是共享内存模型。cluster有一些还是能够让节点之间快速通信的，但就算再快也和本地内存访问速度差几个量级

至于让Internet实现更紧耦合的应用，达到现在cluster的水平，估计至少也要 ...

互联网永远跟不上吧。10 年后互联网是快了，但主机内部更快，到时还是存在很大的距离。

现在一般超级计算机里各节点间的通信方法有几十G的速度了，就是不知道延迟是多少，除带宽外，延迟也算是很重要的。

(Y)

不一定哦，技术的发展很多超出我们预料的

U的速度上不去主要在于电路延迟。延迟对运算模块就意味着速度，但是对于传输模块则不一定。

一个简单的电路的频率可以做得很高，但传输的过程可能很慢。就如在信上写一个字需要几秒的时间，但将信送到其他城市，需要几天。所以我们从来都写很多字的信，而且很多信一起送。大多数情况下，U需要一次性获得很多数据，而不只是几个。

有10GHz的光纤链路，可没有10GHz的处理器。

由于激光器的集成度不购高（光感应器的集成度已经可以了），所以目前主板还使用电路传输。
10年前就有这样的方案：在CPU上集成一组激光器和光感器，由光纤来直接与存储器和其他I/O设备连接。（光纤的集成度，比电路高，可以做成立体的，并且带柔性）光传输设备可以在10GHz或更高的频率下传输，在有限的距离内（最大不超过0.5米），传输延时也会很低。

跑题了。
我的初衷是使类似boinc这种分钟级甚至小时级的交互速度地分布式计算，利用接口来缩短到秒级或毫秒级，来实现更多的可能。


PS：楼上说的“超级计算机里各节点间的通信方法有几十G的速度了”，那个速度是用多位传输的。128位总线以100MHZ速度传输，就是1.6GB/秒的传输速度。