知识点二十九:并行计算

前言

时间复杂度是衡量算法执行效率的一种标准。但是,时间复杂度并不能直接跟性能划等号。在真实的软件开发中,即便在不降低时间复杂度的情况下,也可以通过一些优化手段,提升代码的执行效率。毕竟,对于实际的软件开发来说,即便是像 10%、20% 这样微小的性能提升,也是非常可观的。

算法的目的就是为了提高代码执行的效率。那当算法无法再继续优化的情况下,我们该如何来进一步提高执行效率呢?针对这个问题有一种非常简单但又非常好用的优化方法,那就是并行计算

并行计算

并行计算(Parallel Computing)是指同时使用多种计算资源解决计算问题的过程,是提高计算机系统计算速度和处理能力的一种有效手段。它的基本思想是用多个处理器来协同求解同一问题,即将被求解的问题分解成若干个部分,各部分均由一个独立的处理机来并行计算。简单地说,并行计算就是在并行计算机上所做的计算。并行计算一般可分为:1.计算密集型:如大型科学工程计算与数值模拟等;2.数据密集型:如数字图书馆、数据仓库、数据挖掘和计算可视化等;3.网络密集型:如协同计算和远程诊断等。

为利用并行计算,通常计算问题表现为以下特征:(1)将计算任务分解成多个子任务,有助于同时解决;(2)在同一时间,由不同的执行部件可同时执行多个子任务;(3)多计算资源下解决问题的耗时要少于单个计算资源下的耗时。

下面,我们就通过几个例子,来分析一下,如何借助并行计算的处理思想对算法进行改造?

并行排序

假设我们要给大小为 8GB 的数据进行排序,并且机器的内存可以一次性容纳这么多数据。对于排序来说,最常用的就是时间复杂度为 O(nlogn) 的三种排序算法,归并排序、快速排序堆排序。从理论上讲,这个排序问题,已经很难再从算法层面优化了。但是,利用并行的处理思想,我们可以很轻松地将这个给 8GB 数据排序问题的执行效率提高很多倍。具体的实现思路有下面两种。

  1. 第一种是对归并排序并行化处理。我们可以将这 8GB 的数据划分成 16 个小的数据集合,每个集合包含 500MB 的数据。我们用 16 个线程,并行地对这 16 个 500MB 的数据集合进行排序。这 16 个小集合分别排序完成之后,我们再将这 16 个有序集合合并。
  2. 第二种是对快速排序并行化处理。先扫描一遍数据,找到数据所处的范围区间。然后,我们把这个区间从小到大划分成 16 个小区间。我们将 8GB 的数据按大小关系划分到对应的区间中。针对这 16 个小区间的数据,启动 16 个线程并行地进行排序。等到 16 个线程都执行结束之后,得到的数据就是有序数据了。

对比这两种处理思路,它们都是先利用分治的思想,对数据进行分片,然后并行处理。区别在于,第一种处理思路是,先随意地对数据分片,排序之后再合并。第二种处理思路是,先对数据按照大小划分区间,然后再排序,排完序就不需要再处理了。实际上,这个跟归并和快排的区别如出一辙。

不过,还要注意的一点是,如果现在要排序的数据规模不是 8GB,而是 1TB,那问题的重点就不是算法的执行效率了,而是数据的读取效率。因为 1TB 的数据肯定是存在硬盘中,无法一次性读取到内存中,这样在排序的过程中,就会有频繁地磁盘数据的读取和写入。如何减少磁盘的 IO 操作,减少磁盘数据读取和写入的总量,就变成了优化的重点。

并行查找

我们知道,散列表是一种非常适合快速查找的数据结构。如果我们是给动态数据构建索引,在数据不断加入的时候,散列表的装载因子就会越来越大。为了保证散列表性能不下降,我们就需要对散列表进行动态扩容。对如此大的散列表进行动态扩容,一方面比较耗时,另一方面也比较消耗内存。比如,我们给一个 2GB 大小的散列表进行扩容,扩展到原来的 1.5 倍,也就是 3GB 大小。这个时候,实际存储在散列表中的数据只有不到 2GB,所以内存的利用率只有 60%,有 1GB 的内存是空闲的。

实际上,我们还是可以利用分治+并行计算的处理思路,先将数据随机分割成 k 份(比如 16 份),每份中的数据只有原来的 1/k,然后我们针对这 k 个小数据集合分别构建散列表。这样,散列表的维护成本就变低了。当某个小散列表的装载因子过大的时候,我们可以单独对这个小散列表进行扩容,而其他散列表不需要进行扩容。还是刚才那个例子,假设现在有 2GB 的数据,我们放到 16 个散列表中,每个散列表中的数据大约是 125MB。当某个散列表需要扩容的时候,我们只需要额外增加 125*0.5=62.5 MB 的内存(假设还是扩容到原来的 1.5 倍)。因此,不管从扩容的执行效率还是内存的利用率上,这种多个小散列表的处理方法,都要比大散列表高效。当我们要查找某个数据的时候,我们通过 16 个线程,并行地在这 16 个散列表中查找数据。这样的查找性能,比起在一个大散列表中查找的做法,也并不会下降,反倒有可能提高。此外,当往散列表中添加数据的时候,我们可以选择将这个新数据放入装载因子最小的那个散列表中,这样也有助于减少散列冲突。

并行字符串匹配

在文本中查找某个关键词这样一个功能,可以通过字符串匹配算法来实现,比如 BF、RKBM、KMP 等算法。当在一个不是很长的文本中查找关键词的时候,这些字符串匹配算法中的任何一个,都可以表现得非常高效。但是,如果我们处理的是超级大的文本,那处理的时间可能就会变得很长,那有没有办法加快匹配速度呢?

同样地,我们还是可以利用分治+并行计算的处理思路,我们把大的文本分割成 k 个小文本。假设 k 是 16,我们就启动 16 个线程,并行地在这 16 个小文本中查找关键词,这样整个查找的性能就提高了 16 倍。16 倍效率的提升,从理论的角度来说并不多。但是,对于真实的软件开发来说,这显然是一个非常可观的优化。不过,这里还有一个细节要处理,那就是如果原本包含在大文本中的关键词被一分为二,分割到两个小文本中,这就会导致尽管大文本中包含这个关键词,但在这 16 个小文本中查找不到它。不过,这个问题其实也不难解决,我们只需要针对这种特殊情况,做一些特殊处理就可以了。假设待查找的关键词的长度是 m,我们就在每个小文本的结尾和开始处各取 m 个字符,前一个小文本的末尾 m 个字符和后一个小文本的开头 m 个字符,组成一个长度是 2m 的字符串。然后,我们再拿关键词,在这个长度为 2m 的字符串中再重新查找一遍,就可以补上刚才的漏洞了。

并行搜索

图上的搜索算法有很多,比如深度优先搜索算法、广度优先搜索算法Dijkstra 最短路径算法A* 启发式搜索算法。对于广度优先搜索算法,我们也可以将其改造成并行算法。

广度优先搜索是一种逐层搜索的搜索策略。基于当前这一层顶点,我们可以启动多个线程,并行地搜索下一层的顶点。此外,为了解决多线程的并发问题,在代码实现方面,原来广度优先搜索的代码实现,是通过一个队列来记录已经遍历到但还没有扩展的顶点。现在,经过改造之后的并行广度优先搜索算法,我们利用两个队列来完成扩展顶点的工作。假设这两个队列分别是队列 A 和队列 B。多线程并行处理队列 A 中的顶点,并将扩展得到的顶点存储在队列 B 中。等队列 A 中的顶点都扩展完成之后,队列 A 被清空,我们再并行地扩展队列 B 中的顶点,并将扩展出来的顶点存储在队列 A。这样两个队列循环使用,就可以实现并行广度优先搜索算法。

小结

并行计算是一个工程上的实现思路,尽管跟算法关系不大,但是,在实际的软件开发中,它确实可以非常巧妙地提高程序的运行效率,是一种非常好用的性能优化手段。特别是,当要处理的数据规模达到一定程度之后,无法通过继续优化算法来提高执行效率的时候,我们就需要在实现的思路上做文章,利用更多的硬件资源,来加快执行的效率。所以,在很多超大规模数据处理中,并行处理的思想,应用非常广泛,比如 MapReduce 实际上就是一种并行计算框架。

参考

《数据结构与算法之美》
王争
前Google工程师

并行计算及并行算法:https://blog.csdn.net/lulu950817/article/details/80686126
知乎上关于并行计算的话题:https://www.zhihu.com/topic/19582194/top-answers

发布了45 篇原创文章 · 获赞 2 · 访问量 1724

猜你喜欢

转载自blog.csdn.net/Mr_SCX/article/details/104213507