使用并行计算大幅提升递归算法效率

前言:

无论什么样的并行计算方式,其终极目的都是为了有效利用多机多核的计算能力,并能灵活满足各种需求。相对于传统基于单机编写的运行程序,如果使用该 方式改写为多机并行程序,能够充分利用多机多核cpu的资源,使得运行效率得到大幅度提升,那么这是一个好的靠谱的并行计算方式,反之,又难使用又难直接 看出并行计算优势,还要耗费大量学习成本,那就不是一个好的方式。

由于并行计算在互联网应用的业务场景都比较复杂,如海量数据商品搜索、广告点击算法、用户行为挖掘,关联推荐模型等等,如果以真实场景举例,初学者很容易被业务本身的复杂度绕晕了头。因此,我们需要一个通俗易懂的例子来直接看到并行计算的优势。

数字排列组合是个经典的算法问题,它很通俗易懂,适合不懂业务的人学习,我们通过它来发现和运用并行计算的优势,可以得到一个很直观的体会,并留下深刻的印象。问题如下:

请写一个程序,输入M,然后打印出M个数字的所有排列组合(每个数字为1,2,3,4中的一个)。比如:M=3,输出:

1,1,1
1,1,2
……
4,4,4

共64个

注意:这里是使用计算机遍历出所有排列组合,而不是求总数,如果只求总数,可以直接利用数学公式进行计算了。

一、单机解决方案:

通常,我们在一台电脑上写这样的排列组合算法,一般用递归或者迭代来做,我们先分别看看这两种方案。

1) 单机递归

可以将n(1<=n<=4)看做深度,输入的m看做广度,得到以下递归函数(完整代码见附件CombTest.java)

public void comb(String str){
    for(int i=1;i<n+1;i++){
        if(str.length()==m-1){
            System.out.println(str+i);
            total++;
        } else {
            comb(str+i);
        }
    }
}

但是当m数字很大时,会超出单台机器的计算局限导致缓慢,太大数字的排列组合在一台计算机上几乎很难运行出,不光是排列组合问题,其他类似遍历求解的递归或回溯等算法也都存在这个问题,如何突破单机计算性能的问题一直困扰着我们。

2) 单机迭代

我们观察到,求的m个数字的排列组合,实际上都可以在m-1的结果基础上得到。

比如m=1,得到排列为1,2,3,4,记录该结果为r(1)

m=2, 可以由(1,2,3,4)* r(1) = 11,12,13,14,21,22,…,43,44得到, 记录该结果为r(2)

由此,r(m) =(1,2,3,4)*r(m-1)

如果我们从1开始计算,每轮结果保存到一个中间变量中,反复迭代这个中间变量,直到算出m的结果为止,这样看上去也可行,仿佛还更简单。

但是如果我们估计一下这个中间变量的大小,估计会吓一跳,因为当m=14的时候,结果已经上亿了,一亿个数字,每个数字有14位长,并且为了得到 m=15的结果,我们需要将m=14的结果存储在内存变量中用于迭代计算,无论以什么格式存,几乎都会遭遇到单台机器的内存局限,如果排列组合数字继续增 大下去,结果便会内存溢出了。

二、分布式并行计算解决方案:

我们看看如何利用多台计算机来解决该问题,同样以递归和迭代的方式进行分析。

1) 多机递归

做分布式并行计算的核心是需要改变传统的编程设计观念,将算法重新设计按多机进行拆分和合并,有效利用多机并行计算优势去完成结果。

我们观察到,将一个n深度m广度的递归结果记录为 r(n,m),那么它可以由(1,2,…n)*r(n,m-1)得到:

r(n,m)=1r(n,m-1)+2r(n,m-1)+…+n*r(n,m-1)

假设我们有n台计算机,每台计算机的编号依次为1到n,那么每台计算机实际上只要计算r(n,m-1)的结果就够了,这里实际上将递归降了一级, 并且让多机并行计算。

如果我们有更多的计算机,假设有n*n台计算机,那么:

r(n,m)=11r(n,m-2)+12r(n,m-2)+…+nn*r(n,m-2)

拆分到n*n台计算机上就将递归降了两级了

可以推断,只要我们的机器足够多,能够线性扩充下去,我们的递归复杂度会逐渐降级,并且并行计算的能力会逐渐增强。

这里是进行拆分设计的分析是假设每台计算机只跑1个实例,实际上每台计算机可以跑多个实例(如上图),我们下面的例子可以看到,这种并行计算的方式相对传统单机递归有大幅度的效率提升。

这里使用fourinone框架设计分布式并行计算,第一次使用可以参考分布式计算上手demo指南, 开发包下载地址:http://www.skycn.com/soft/68321.html

ParkServerDemo:负责工人注册和分布式协调

CombCtor:是一个包工头实现,它负责接收用户输入的m,并将m保存到变量comb,和线上工人总数wknum一起传给各个工人,下达计算命令,并在计算完成后累加每个工人的结果数量得到一个结果总数。

CombWorker:是一个工人实现,它接收到工头发的comb和wknum参数用于递归条件,并且通过获取自己在集群的位置index,做为递 归初始条件用于降级,它找到一个排列组合会直接在本机输出,但是计数保存到total,然后将本机的total发给包工头统计总体数量。

运行步骤:

为了方便演示,我们在一台计算机上运行:

  1. 启动ParkServerDemo:它的IP端口已经在配置文件的PARK部分的SERVERS指定。
  2. 启动4个CombWorker实例:传入2个参数,依次是ip或者域名、端口(如果在同一台机器可以ip相同,但是端口不同),这里启动4个工人是由于1<=n<=4,每个工人实例刚好可以通过集群位置 index进行任务拆分。
  3. 运行CombCtor查看计算时间和结果

下面是在一台普通4cpu双核2.4Ghz内存4g开发机上和单机递归CombTest的测试对比

M=14 M=15 M=16 CPU利用率
单机递归计算 10秒 41秒 169秒 29%
单机并行计算 6秒 26秒 112秒 99%
多机并行计算 按机器数量成倍提升效率 99%

通过测试结果我们可以看到:

  1. 可以推断,由于单机的性能限制,无法完成m值很大的计算。
  2. 同是单机环境下,并行计算相对于传统递归提升了将近1.6倍的效率,随着m的值越大,节省的时间越多。
  3. 单机递归的CPU利用率不高,平均20-30%,在多核时代没有充分利用机器资源,造成cpu闲置浪费,而并行计算则能打满cpu,充分利用机器资源。
  4. 如果是多机分布式并行计算,在4台机器上,采用4*4的16个实例完成计算,效率还会成倍提升,而且机器数量越多,计算越快。
  5. 单机递归实现和运行简单,使用c或者java写个main函数完成即可,而分布式并行程序,则需要利用并行框架,以包工头+多个工人的全新并行计算思想去完成。

2) 多机迭代

我们最后看看如何构思多机分布式迭代方式实现。

思路一:

根据单机迭代的特点,我们可以将n台计算机编号为1到n

第一轮统计各工人发送编号给工头,工头合并得到第一轮结果{1,2,3,…,n}

第二轮,工头将第一轮结果发给各工人做为计算输入条件,各工人根据自己编号累加,返回结果给工头合并,得到第二轮结果:{11,12,13,1n,…,n1,n2,n3,nn}

这样迭代下去,直到m轮结束,如上图所示。

但很快就会发现,工头合并每轮结果是个很大的瓶颈,很容易内存不够导致计算崩溃。

思路二:

如果对思路一改进,各工人不发中间结果给工头合并,而采取工人之间互相合并方式,将中间结果按编号分类,通过receive方式(工人互相合并及receive使用可参见sayhello demo),将属于其他工人编号的数据发给对方。这样一定程度避免了工头成为瓶颈,但是经过实践发现,随着迭代变大,中间结果数据越来越大,工人合并耗用网络也越来越大,如果中间结果保存在各工人内存中,随着m变的更大,仍然存在内存溢出危险。

思路三:

继续改进思路二,将中间结果变量不保存内存中,而每次写入文件(详见Fourinone2.0对分布式文件的简化操作),这样能避免内存问题,但是增加了大量的文件io消耗。虽然能运行出结果,但是并不高效。

总结:

或许分布式迭代在这里并不是最好的做法,上面的多机递归更合适。由于迭代计算的特点,需要将中间结果进行保存,做为下一轮计算的条件,如果为了利用多机并行计算优势,又需要反复合并产生中间结果,所以导致对内存、带宽、文件io的耗用很大,处理不当容易造成性能低下。

我们早已经进入多cpu多核时代,但是我们的传统程序设计和算法还停留在过去单机应用,因此合理利用并行计算的优势来改进传统软件设计思想,能为我们带来更大效率的提升。

下载完整代码点击这里

This entry was posted in Achitecture, Best Practices. Bookmark the permalink.

发表评论

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / 更改 )

Twitter picture

You are commenting using your Twitter account. Log Out / 更改 )

Facebook photo

You are commenting using your Facebook account. Log Out / 更改 )

Google+ photo

You are commenting using your Google+ account. Log Out / 更改 )

Connecting to %s