Raku/Rakudo 包含哪些持久数据结构?

问题描述

Raku 提供的 many 类型是 immutable,因此在创建后无法修改。直到我最近开始研究这个领域,我的理解是这些类型不是 persistent data structures——也就是说,与 Clojure 或 Haskell 中的核心类型不同,我相信 Raku 的不可变类型确实不要利用结构共享来允许廉价的副本。我认为语句 my List $new = (|$old-list,42); 从字面上复制了 $old-list 中的值,没有持久数据结构的数据共享功能。

但是,由于以下代码,我理解的描述是过去时:

my Array $a = do {
    $_ = [rand xx 10_000_000];
    say "Initialized an Array in $((now - ENTER now).round: .001) seconds"; $_}
my List $l = do {
    $_ = |(rand xx 10_000_000);
    say "Initialized the List in $((now - ENTER now).round: .001) seconds"; $_}
do { $a.push: rand;  
     say "Pushed the element to the Array in $((now - ENTER now).round: .000001) seconds" }
do { my $nl = (|$l,rand); 
     say "Appended an element to the List in $((now - ENTER now).round: .000001) seconds" }
do { my @na = |$l; 
     say "Copied List \$l into a new Array in $((now - ENTER now).round: .001) seconds" }

在一次运行中产生了这个输出:

Initialized an Array in 5.938 seconds
Initialized the List in 5.639 seconds
Pushed the element to the Array in 0.000109 seconds
Appended an element to the List in 0.000109 seconds
Copied List $l into a new Array in 11.495 seconds

也就是说,用旧值创建一个新的 List + 一个新的 List 和推送到一个可变数组一样快,而且比将 List 复制到一个新的数组快得多——这正是你期望的性能特征从持久列表中看到(复制到数组仍然很慢,因为它不能在不破坏列表不变性的情况下利用结构共享)。将 $l 快速复制到 $nl不是,因为 List 是惰性的;都不是。

以上所有使我相信 Rakudo 中的列表实际上 是持久性数据结构,具有隐含的所有性能优势。这给我留下了几个问题:

  • 关于列表是持久性数据结构,我说得对吗?
  • 所有其他不可变类型也是持久数据结构吗?或者有吗?
  • 这部分是 Raku 的任何部分,还是只是 Rakudo 做出的实施选择?
  • 是否在任何地方记录/保证了这些性能特征中的任何一个?

我不得不说,发现至少有一些 Raku(do) 的类型是持久的,我既印象深刻,也有点困惑。这是其他语言 list as a key selling point 或导致在 GitHub 上创建 libraries with 30k+ stars 的那种功能。我们真的在 Raku 拥有它甚至没有提到它吗?

解决方法

我记得实现了这些语义,而且我当然不记得当时考虑过它们会产生持久性数据结构 - 尽管将该标签附加到结果似乎是公平的!

我不认为您会找到任何明确说明这种确切行为的地方,但是语言要求的最自然的实现很自然地导致了它。取材:

  • infix:<,> 运算符是 Raku 中的 List 构造函数
  • 当创建 List 时,它在惰性和扁平化方面是不确定的(这些源于我们如何使用 List,我们通常不知道在其构造点)
  • 当我们编写 (|$x,1) 时,prefix:<|> 运算符构造了一个 Slip,它是一种 List,应该融入其周围的 List。因此,infix:<,> 看到的是 SlipInt
  • Slip 立即融入结果 List 意味着做出关于渴望的承诺,而仅凭 List 构造不应该这样做。因此,Slip 及其之后的所有内容都被放入 List 的惰性求值(“非具体化”)部分。

最后一个是导致观察到的持久数据结构样式行为的原因。

我希望可以有一个实现来检查 Slip 并选择急切地复制已知不是懒惰的东西,并且仍然符合规范测试套件。这会改变你的例子的时间复杂度。如果您想对此进行防御,那么:

do { my $nl = (|$l.lazy,rand); 
     say "Appended an element to the List in $((now - ENTER now).round: .000001) seconds" }

即使实现发生变化,也应该足以强制解决问题。

立即想到的与持久数据结构或至少尾部共享相关的其他情况:

  • 字符串的 MoarVM 实现,在 strStr 后面,通过创建一个新的字符串来实现字符串连接字符串(并对 substr 和重复执行类似的技巧)。这严格来说是一种优化,而不是语言要求,并且在一些微妙的情况下(一个字符串的最后一个字素和下一个字素的第一个字素将在结果字符串中形成单个字素),它放弃并采用复制路径。
  • 在核心之外,Concurrent::StackConcurrent::QueueConcurrent::Trie 等模块使用尾部共享作为实现相对高效的无锁数据结构的技术。

相关问答

错误1:Request method ‘DELETE‘ not supported 错误还原:...
错误1:启动docker镜像时报错:Error response from daemon:...
错误1:private field ‘xxx‘ is never assigned 按Alt...
报错如下,通过源不能下载,最后警告pip需升级版本 Requirem...