一尘不染

快速功能合并排序

algorithm

这是我在Scala中实现合并排序的实现:

object FuncSort {
  def merge(l: Stream[Int], r: Stream[Int]) : Stream[Int] = {
    (l, r) match {
      case (h #:: t, Empty) => l
      case (Empty, h #:: t) => r
      case (x #:: xs, y #:: ys) => if(x < y ) x #:: merge(xs, r) else y #:: merge(l, ys)
    }
  }

  def sort(xs: Stream[Int]) : Stream[Int] = {
    if(xs.length == 1) xs
    else {
      val m = xs.length / 2
      val (l, r) = xs.splitAt(m)
      merge(sort(l), sort(r))
    }
  }
}

它可以正常工作,并且渐近似乎还可以,但是它比Java实现慢得多(大约10倍),可从此处http://algs4.cs.princeton.edu/22mergesort/Merge.java.html进行,并使用很多内存。是否有更快的合并排序
功能实现 ?显然,可以逐行移植Java版本,但这不是我想要的。

UPD:我更改Stream为to List#::to
::,并且排序例程变得更快,仅比Java版本慢三到四倍。但是我不明白为什么它不会因堆栈溢出而崩溃?merge不是尾递归,所有参数都经过严格评估…这怎么可能?


阅读 246

收藏
2020-07-28

共1个答案

一尘不染

您提出了多个问题。我尝试按照逻辑顺序回答它们:

流版本中没有堆栈溢出

您并没有真正问过这个问题,但是它带来了一些有趣的发现。

在Stream版本中,您正在函数#:: merge(...)内部使用merge。通常,这将是递归调用,并可能导致堆栈溢出,无法容纳足够大的输入数据。但在这种情况下不是。运算符#::(a,b)在中实现class ConsWrapper[A](存在隐式转换),并且是的同义词cons.apply[A](hd: A, tl: ⇒ Stream[A]): Cons[A]。如您所见,第二个参数是按名称调用的,这意味着它是惰性计算的。

这意味着merge返回一个新创建的类型的对象,cons该对象最终将再次调用merge。换句话说:递归不是在堆栈上发生,而是在堆上发生。通常,您有很多堆。

使用堆进行递归是处理非常深的递归的好方法。但这比使用堆栈要慢得多。因此,您将速度与递归深度进行了交换。这是主要原因,使用Stream速度如此之慢。

第二个原因是,为了获得长度Stream,Scala必须实现整体Stream。但是在排序过程中Stream,无论如何都必须实现每个元素,因此这不会造成太大的伤害。

列表版本中没有堆栈溢出

当更改Stream for
List时,实际上是在使用堆栈进行递归。现在可能会发生堆栈溢出。但是通过排序,您的递归深度log(size)通常为base的对数2。因此,要对40亿个输入项目进行分类,您将需要大约32个堆栈帧。默认堆栈大小至少为320k(在Windows上,其他系统具有更大的默认值),因此有很多递归空间,因此可以对许多输入数据进行排序。

更快的功能实现

这取决于 :-)

您应该使用堆栈,而不要使用堆进行递归。您应该根据输入数据决定策略:

  1. 对于小数据块,请使用一些简单算法将它们排序到位。算法的复杂性不会给您带来麻烦,并且通过将所有数据都缓存在缓存中可以提高性能。当然,对于给定的大小,您仍然可以手动编写代码分类网络
  2. 如果您有数字输入数据,则可以使用基数排序并按处理器或GPU上的矢量单位处理功(可以在GPU Gems中找到更复杂的算法)。
  3. 对于中型数据块,可以使用分而治之的策略将数据拆分为多个线程(仅当您具有多个内核时!)
  4. 对于巨大的数据块,请使用合并排序并将其拆分为适合内存的块。如果需要,可以在网络上分发这些块并在内存中排序。

不要使用swap并使用缓存。如果可以并使用适当的位置,请使用可变数据结构。我认为功能排序和快速排序不能很好地协同工作。为了使排序真正快速,您将必须使用有状态操作(例如,对可变数组进行就地归并排序)。

我通常在所有程序上都尝试这样做:尽可能使用纯函数样式,但在可行的情况下对小部分使用有状态的操作(例如,因为它具有更好的性能,或者代码只需要处理很多状态,而在我用vars代替vals)。

2020-07-28