函数式编程-不变性昂贵吗？[关闭]

问题分为两部分。首先是概念上的。接下来的内容将在Scala中更具体地研究相同的问题。

1. 在编程语言中仅使用不可变数据结构是否会使在实践中实现某些算法/逻辑本质上在计算上更加昂贵？这引出了一个事实，即不变性是纯功能语言的核心宗旨。还有其他因素对此有影响吗？
2. 让我们举一个更具体的例子。通常对内存数据结构使用可变操作来教授和实现Quicksort。如何以一种PURE功能方式实现这种事情，并且具有与可变版本相当的计算和存储开销。特别是在Scala中。我在下面列出了一些粗略的基准。

更多细节：

我来自命令式编程背景（C ++，Java）。我一直在探索函数式编程，特别是Scala。

纯函数式编程的一些主要原理：

1. 职能是头等公民。
2. 函数没有副作用，因此对象/数据结构是不可变的。

即使现代JVM在创建对象方面非常高效，并且垃圾回收对于短寿命的对象而言非常便宜，但将对象创建最小化可能还是更好的选择吧？至少在并发和锁定不是问题的单线程应用程序中。由于Scala是一种混合范例，因此可以根据需要选择使用可变对象编写命令性代码。但是，作为一个花了很多年尝试重用对象并最小化分配的人。我希望对不允许的思想流派有所了解。

作为一个具体案例，我对本教程 6中的代码片段感到有些惊讶。它有一个Java版本的Quicksort，然后是一个简洁的Scala实现。

这是我对实现进行基准测试的尝试。我尚未进行详细的分析。但是，我的猜测是，Scala版本的速度较慢，因为分配的对象数是线性的（每个递归调用一个）。尾叫优化有没有机会发挥作用？如果我是对的，Scala支持针对自递归调用的尾部调用优化。因此，它应该只是在帮助它。我正在使用Scala 2.8。

Java版本

public class QuickSortJ {

    public static void sort(int[] xs) {
      sort(xs, 0, xs.length -1 );
    }

    static void sort(int[] xs, int l, int r) {
      if (r >= l) return;
      int pivot = xs[l];
      int a = l; int b = r;
      while (a <= b){
        while (xs[a] <= pivot) a++;
        while (xs[b] > pivot) b--;
        if (a < b) swap(xs, a, b);
      }
      sort(xs, l, b);
      sort(xs, a, r);
    }

    static void swap(int[] arr, int i, int j) {
      int t = arr[i]; arr[i] = arr[j]; arr[j] = t;
    }
}

Scala版本

object QuickSortS {

  def sort(xs: Array[Int]): Array[Int] =
    if (xs.length <= 1) xs
    else {
      val pivot = xs(xs.length / 2)
      Array.concat(
        sort(xs filter (pivot >)),
        xs filter (pivot ==),
        sort(xs filter (pivot <)))
    }
}

Scala代码比较实现

import java.util.Date
import scala.testing.Benchmark

class BenchSort(sortfn: (Array[Int]) => Unit, name:String) extends Benchmark {

  val ints = new Array[Int](100000);

  override def prefix = name
  override def setUp = {
    val ran = new java.util.Random(5);
    for (i <- 0 to ints.length - 1)
      ints(i) = ran.nextInt();
  }
  override def run = sortfn(ints)
}

val benchImmut = new BenchSort( QuickSortS.sort , "Immutable/Functional/Scala" )
val benchMut   = new BenchSort( QuickSortJ.sort , "Mutable/Imperative/Java   " )

benchImmut.main( Array("5"))
benchMut.main( Array("5"))

结果

连续五次运行的时间（毫秒）

Immutable/Functional/Scala    467    178    184    187    183
Mutable/Imperative/Java        51     14     12     12     12

由于这里存在一些误解，我想澄清一些要点。

• “就地”快速排序不是真正的就地（按定义，快速排序也不是就地）。对于递归步骤，它需要堆栈空间形式的附加存储，其顺序为： ø（日志Ñ）在最佳情况下，但ø（Ñ在最坏的情况下）。

• 实现对数组进行操作的quicksort的功能变体无法达到目的。数组永远是不可变的。

• 快速排序的“适当”功能实现使用不可变列表。它当然不是就地，但它具有相同的最坏情况渐近运行时（O（n ^ 2））和空间复杂度（O（n））。

  平均而言，其运行时间仍与就地变型（O（n log n））相同。但是，其空间复杂度仍为O（n）。

有 功能快速排序实现两个明显的缺点。下面，让我们考虑在Haskell（我不知道斯卡拉...）从这个参考实现哈斯克尔介绍：

qsort []     = []
qsort (x:xs) = qsort lesser ++ [x] ++ qsort greater
    where lesser  = (filter (< x) xs)
          greater = (filter (>= x) xs)

1. 第一个缺点是 枢轴元件的选择非常不灵活。现代快速排序实现的强大功能在很大程度上取决于对数据透视表的明智选择（比较Bentley 等人的 “设计排序功能”）。在这方面，上述算法很差，这会大大降低平均性能。

2. 其次，该算法使用列表级联是O（n）操作的（而不是列表构造）。这不会影响渐近复杂性，但这是一个可测量的因素。

第三个缺点是隐藏的：与“就地”变体不同，此实现 不断从堆中请求列表的cons单元的内存，并有可能将内存分散到整个位置。结果，该算法的缓存局部性很差。我不知道现代函数式编程语言中的智能分配器是否可以缓解这种情况-但在现代计算机上，缓存未命中已成为主要的性能杀手。

结论如何？与其他人不同，我不会说quicksort本质上是必不可少的，这就是为什么它在FP环境中表现不佳的原因。恰恰相反，我认为快速排序是功能算法的完美示例：它无缝地转换为不可变的环境，其渐近运行时间和空间复杂度与过程实现相当，甚至其过程实现也使用递归。

但是这个算法 当将约束到不可变域时，其仍然较差。这样做的原因是该算法具有独特的特性，即可以从很多（有时是低级别的）微调中受益，这些微调只能在数组上有效地执行。对快速排序的幼稚描述忽略了所有这些复杂性（在功能和过程上都是如此）。

阅读“设计排序功能”后，我不再认为quicksort是一种优雅的算法。有效地实施，这是一个笨拙的混乱，是工程师的工作，而不是艺术家的工作（不要贬低工程学！这有其自身的美学意义）。

但我也想指出，这一点是Quicksort特有的。并非每种算法都适用于相同类型的低级调整。确实有很多算法和数据结构在不可变的环境中，可以表达而不会降低性能。

不变性甚至可以 消除对昂贵副本或跨线程同步的需求，从而降低性能成本。

因此，回答最初的问题，“ 不变性昂贵吗？” –在快速分类的特定情况下，确实存在成本，这是不可变性的结果。但总的来说，没有。

作为函数式编程的基准，这有很多问题。重点包括：

• 您正在使用图元，可能必须将它们装箱/拆箱。您不是要测试包装原始对象的开销，而是要测试不变性。
• 您选择的算法在就地运算中异常有效（并且证明是有效的）。如果您想证明存在可变实现时更快的算法，那么这是一个不错的选择。否则，这可能会产生误导。
• 您使用了错误的计时功能。使用System.nanoTime。
• 基准测试太短了，您无法确信JIT编译不会在所测时间中占很大的比例。
• 数组未有效拆分。
• 数组是可变的，因此将它们与FP一起使用还是一个奇怪的比较。

因此，此比较很好地说明了您必须详细了解语言（和算法）才能编写高性能代码。但这并不是FP与非FP的很好比较。如果需要的话，请在Computer Languages Benchmark Game中查看Haskell vs. C ++。带回家的消息是，罚款通常不超过2或3倍左右，但这确实取决于。（也不保证Haskell的人已经编写了可能最快的算法，但至少其中一些人可能尝试过！然后，某些Haskell调用C库...。）

现在，假设您确实想要一个更合理的Quicksort基准，并意识到这可能是FP与可变算法最坏的情况之一，并且忽略了数据结构问题（即，假设我们可以拥有一个不变的Array）：

object QSortExample {
  // Imperative mutable quicksort
  def swap(xs: Array[String])(a: Int, b: Int) {
    val t = xs(a); xs(a) = xs(b); xs(b) = t
  }
  def muQSort(xs: Array[String])(l: Int = 0, r: Int = xs.length-1) {
    val pivot = xs((l+r)/2)
    var a = l
    var b = r
    while (a <= b) {
      while (xs(a) < pivot) a += 1
      while (xs(b) > pivot) b -= 1
      if (a <= b) {
        swap(xs)(a,b)
        a += 1
        b -= 1
      }
    }
    if (l<b) muQSort(xs)(l, b)
    if (b<r) muQSort(xs)(a, r)
  }

  // Functional quicksort
  def fpSort(xs: Array[String]): Array[String] = {
    if (xs.length <= 1) xs
    else {
      val pivot = xs(xs.length/2)
      val (small,big) = xs.partition(_ < pivot)
      if (small.length == 0) {
        val (bigger,same) = big.partition(_ > pivot)
        same ++ fpSort(bigger)
      }
      else fpSort(small) ++ fpSort(big)
    }
  }

  // Utility function to repeat something n times
  def repeat[A](n: Int, f: => A): A = {
    if (n <= 1) f else { f; repeat(n-1,f) }
  }

  // This runs the benchmark
  def bench(n: Int, xs: Array[String], silent: Boolean = false) {
    // Utility to report how long something took
    def ptime[A](f: => A) = {
      val t0 = System.nanoTime
      val ans = f
      if (!silent) printf("elapsed: %.3f sec\n",(System.nanoTime-t0)*1e-9)
      ans
    }

    if (!silent) print("Scala builtin ")
    ptime { repeat(n, {
      val ys = xs.clone
      ys.sorted
    }) }
    if (!silent) print("Mutable ")
    ptime { repeat(n, {
      val ys = xs.clone
      muQSort(ys)()
      ys
    }) }
    if (!silent) print("Immutable ")
    ptime { repeat(n, {
      fpSort(xs)
    }) }
  }

  def main(args: Array[String]) {
    val letters = (1 to 500000).map(_ => scala.util.Random.nextPrintableChar)
    val unsorted = letters.grouped(5).map(_.mkString).toList.toArray

    repeat(3,bench(1,unsorted,silent=true))  // Warmup
    repeat(3,bench(10,unsorted))     // Actual benchmark
  }
}

请注意对功能性Quicksort的修改，因此，只要有可能，它仅对数据进行一次遍历，并与内置排序进行比较。当我们运行它时，我们得到如下内容：

Scala builtin elapsed: 0.349 sec
Mutable elapsed: 0.445 sec
Immutable elapsed: 1.373 sec
Scala builtin elapsed: 0.343 sec
Mutable elapsed: 0.441 sec
Immutable elapsed: 1.374 sec
Scala builtin elapsed: 0.343 sec
Mutable elapsed: 0.442 sec
Immutable elapsed: 1.383 sec

因此，除了了解尝试编写自己的排序不是一个好主意之外，我们发现，如果对不可变的快速排序进行一些仔细的实现，则约有3倍的罚款。（您也可以编写一个trisect方法，该方法返回三个数组：小于，等于和大于枢轴的数组。这可能会加快速度。）

我不认为Scala版本实际上是尾递归的，因为您正在使用Array.concat。

另外，仅因为这是惯用的Scala代码，但这并不意味着它是最佳方法。

最好的方法是使用Scala的内置排序功能之一。这样，您将获得不变性保证，并且知道自己拥有快速算法。

请参阅堆栈溢出问题。如何在Scala中对数组排序？举个例子

不变性并不昂贵。如果只测量程序要做的一小部分任务，然后根据启动的可变性选择解决方案，例如测量快速排序，那肯定会很昂贵。

简而言之，在使用纯函数式语言时，您不会快速排序。

让我们从另一个角度考虑。让我们考虑以下两个功能：

// Version using mutable data structures
def tailFrom[T : ClassManifest](arr: Array[T], p: T => Boolean): Array[T] = {
  def posIndex(i: Int): Int = {
    if (i < arr.length) {
      if (p(arr(i)))
        i
      else
        posIndex(i + 1)
    } else {
      -1
    }
  }

  var index = posIndex(0)

  if (index < 0) Array.empty
  else {
    var result = new Array[T](arr.length - index)
    Array.copy(arr, index, result, 0, arr.length - index)
    result
  }
}

// Immutable data structure:

def tailFrom[T](list: List[T], p: T => Boolean): List[T] = {
  def recurse(sublist: List[T]): List[T] = {
    if (sublist.isEmpty) sublist
    else if (p(sublist.head)) sublist
    else recurse(sublist.tail)
  }
  recurse(list)
}

使用基准THAT，您会发现使用可变数据结构的代码的性能要差得多，因为它需要复制数组，而不可变的代码则不必担心。

当使用不可变的数据结构进行编程时，可以对代码进行结构化以利用其优势。它不仅是数据类型，甚至不是单独的算法。该程序将被设计不同的方式。

这就是基准测试通常毫无意义的原因。您要么选择一种样式或另一种样式固有的算法，然后以该样式为准，要么对整个应用程序进行基准测试，这通常是不切实际的。

排序数组是宇宙中最必要的任务。毫不奇怪，许多优雅的“不变”策略/实现在“对数组进行排序”的微基准测试中失败极少。但是，这并不意味着不变性通常是昂贵的。在许多任务中，不变的实现将与可变的实现相比，但是数组排序通常不是其中之一。

如果您只是将命令性算法和数据结构重写为函数式语言，那确实是昂贵且无用的。为了让事情变得光彩照人，您应该使用仅在函数式编程中可用的功能：数据结构持久性，惰性评估等。

不变性的代价 Scala

这是一个几乎与Java一样快的版本。;）

object QuickSortS {
  def sort(xs: Array[Int]): Array[Int] = {
    val res = new Array[Int](xs.size)
    xs.copyToArray(res)
    (new QuickSortJ).sort(res)
    res
  }
}

此版本创建数组的副本，使用Java版本对其进行排序，然后返回副本。Scala不会强迫您在内部使用不可变结构。

因此，Scala的好处是您可以根据需要利用可变性和不变性。缺点是，如果您做错了，您将不会真正获得不变性的好处。

众所周知，QuickSort在就地完成时会更快，因此这不是一个公平的比较！

这么说... Array.concat？如果没有其他说明，那么您将展示针对命令式编程进行优化的集合类型如何在功能算法中尝试使用时特别慢。几乎任何其他选择都会更快！

另外很重要的一点考虑，也许在比较这两种方法时最重要的问题是：“这种方法在多大程度上扩展到多个节点/核心？”

很有可能，如果您正在寻找一个不变的快速排序，那么您这样做是因为您实际上想要一个并行的快速排序。维基百科对此主题有一些引用： http //en.wikipedia.org/wiki/Quicksort#Parallelizations

scala版本可以在函数递归之前简单地进行派生，如果拥有足够的可用内核，它可以非常快速地对包含数十亿个条目的列表进行排序。

现在，如果我可以在其上运行Scala代码，则我系统中的GPU可以使用128个内核，并且这是在比当前一代落后两年的简单台式机系统上。

我想知道如何与单线程命令式方法相提并论...

因此，也许更重要的问题是：

“考虑到单个内核不会更快，并且同步/锁定对并行化提出了真正的挑战，可变性是否昂贵？”

据说OO编程使用抽象来隐藏复杂性，而功能编程则使用不变性来消除复杂性。在Scala的混合世界中，我们可以使用OO来隐藏命令性代码，而使应用程序代码更明智。实际上，馆藏库使用了大量命令性代码，但这并不意味着我们不应该使用它们。正如其他人所说，谨慎使用，您确实可以在这里两全其美。