haskell haskell应用场景 - 混合Erlang和Haskell




3 Answers

许多Haskell和Erlang人对Erlang监督分发的模型感兴趣,而Haskell并行运行共享内存节点执行所有数字运算/逻辑。

这方面的一个开始是haskell-erlang库: http://hackage.haskell.org/package/erlanghttp://hackage.haskell.org/package/erlang

我们在Ruby的土地上也有类似的努力,通过Hubris: http://github.com/mwotton/Hubris/tree/masterhttp://github.com/mwotton/Hubris/tree/master

现在的问题是找到某人实际推动Erlang / Haskell互操作以找出棘手的问题。

haskell知乎 haskell语言

如果您已经购买了函数式编程范例,那么您很可能同时喜欢Erlang和Haskell。 两者都具有纯粹的功能核心和其他优点,如轻量级线程,使其非常适合多核世界。 但也存在一些差异。

Erlang是一种经过商业验证的容错语言,具有成熟的分发模型。 它具有看似独特的功能,能够通过热代码加载在运行时升级其版本。 (太酷了!)

另一方面,Haskell拥有任何主流语言中最复杂的类型系统。 (我将'主流'定义为任何已发布的O'Reilly书籍的语言,因此Haskell很重要。)它的直线单线程性能看起来优于Erlang,其轻量级线程看起来更轻。

我正在尝试为我的编码生命的其余部分组建一个开发平台,并且想知道是否有可能将Erlang和Haskell混合以实现最佳的平台。 这个问题有两个部分:

  1. 我想使用Erlang作为一种容错MPI来将GHC运行时实例粘合在一起。 每个GHC运行时会有一个Erlang进程。 如果“不可能发生”并且GHC运行时死亡,那么Erlang进程会以某种方式检测到并且也会死亡。 Erlang的热代码加载和分发功能将继续工作。 GHC运行时可以配置为仅使用一个核心,或本地计算机上的所有核心,或其间的任何组合。 一旦编写了Erlang库,Erlang级别代码的其余部分应该是纯粹的样板,并在每个应用程序的基础上自动生成。 (例如,可能以Haskell DSL为例。)如何实现至少其中一些内容?
  2. 我希望Erlang和Haskell能够共享同一个收集器。 (这是一个比1更远的想法。)在JVM和CLR上运行的语言通过共享运行时实现更大的质量。 我知道在JVM或CLR上运行Erlang(热代码加载)和Haskell(更高的kinded多态)存在技术限制。 但是如果只拆分垃圾收集器呢? (函数式语言的运行时的开始排序。)分配显然仍然必须非常快,所以也许这个位需要静态链接。并且应该有一些机制来区分可变堆和不可变堆(因为GHC需要这个,所以包括懒惰写一次内存)。 是否可以修改HIPE和GHC以便垃圾收集器可以共享堆?

请回答任何经验(积极或消极),想法或建议。 事实上,任何反馈(没有直接滥用!)都是受欢迎的。

更新

感谢迄今为止的所有4个回复 - 每个回复教我至少一个我不知道的有用的东西。

关于其余的编码生活事物 - 我在脸颊上稍微用舌头包括引发辩论,但实际上是真的。 有一个我想到的项目,我打算继续工作直到我死,它需要一个稳定的平台。

在我上面提到的平台中,我只会编写Haskell,因为将自动生成样板Erlang。 那么Haskell会持续多久? 好吧,Lisp仍然和我们在一起,看起来不会很快消失。 Haskell是BSD3的开源软件,已达到临界质量。 如果编程本身在50年左右仍然存在,我会期望Haskell,或者Haskell的一些不断演变,仍然会在这里。

更新2 以回应rvirding的帖子

同意 - 实现一个完整的“Erskell / Haslang”通用虚拟机可能并非绝对不可能,但确实非常困难。 尽管如此,将垃圾收集器级别作为VM之类的东西共享虽然仍然很难 ,但听起来要小一些。 在垃圾收集模型中,函数式语言必须有许多共同点 - 不可变数据(包括thunk)的无处不在和非常快速分配的要求。 因此,将通用性与单片VM紧密捆绑在一起这一事实似乎有些奇怪。

虚拟机确实有助于实现临界质量。 看看像F#和Scala这样的“精简”功能语言是如何起飞的。 Scala可能没有Erlang的绝对容错能力,但它为许多与JVM绑定的人提供了一条逃生路线。

虽然拥有单个堆会使消息传递速度非常快,但它会引入许多其他问题,主要是因为它必须是交互式的且全局不中断的,所以做GC会变得更加困难,所以你不能使用相同的简单算法。进程堆模型。

当然,这对我来说非常有意义。 GHC开发团队中非常聪明的人似乎试图通过平行的“停止世界”GC来解决部分问题。

http://research.microsoft.com/en-us/um/people/simonpj/papers/parallel-gc/par-gc-ismm08.pdf

(显然,“停止世界”不会因为它的主要用例而对一般的Erlang飞行。)但即使在“停止世界”的用例中也是如此,它们的加速似乎并不普遍。 所以我同意你的观点,不太可能有一个普遍最好的GC,这就是我在我的问题第1部分中指出的原因。

GHC运行时可以配置为仅使用一个核心,或本地计算机上的所有核心,或其间的任何组合。

通过这种方式,对于给定的用例,我可以在基准测试后选择使用Erlang方式,并运行一个GHC运行时(使用单线程GC)和每个核心一个Erlang进程,让Erlang在内核之间复制内存以获得良好的局部性。

或者,在处理器上具有4个核心/处理器并具有良好内存带宽的双处理器计算机上,基准测试可能表明我运行一个GHC运行时(使用并行GC)和每个处理器一个Erlang进程。

在这两种情况下,如果Erlang和GHC可以共享一个堆,那么共享可能会绑定到以某种方式在单个核上运行的单个OS线程。 (我在这里深入了解,这就是我问这个问题的原因。)

我还有另一个议程 - 独立于GC的功能语言基准测试。 我经常阅读OCaml v GHC v Erlang v ...的基准测试结果,并想知道不同的GC会对结果造成多大的影响。 如果选择GC可以与函数式语言的选择正交怎么办? GC究竟有多昂贵? 看到这个恶魔倡导者博客文章

http://john.freml.in/garbage-collection-harmful

由我的Lisp朋友约翰弗雷姆林,他迷人地,给他的帖子标题“自动垃圾收集是垃圾”。 当约翰声称GC很慢并且没有真正加速那么多时,我希望能够用一些数字来对抗。




虽然这是一个非常古老的线程,但如果读者仍然感兴趣,那么值得一看的是Cloud Haskell ,它将Erlang风格的并发和分发带入了GHC稳定版。

即将推出的distributed-process-platform库增加了对OTP-esque构造的支持,例如gen_servers,监督树以及从Erlang / OTP借鉴和启发的各种其他“haskell风格”抽象。




正如dizzyd在他的评论中提到的那样,并不是所有的消息数据都被复制,大型二进制文件存在于进程堆之外并且不会被复制。

使用不同的存储器结构以避免具有单独的每个进程堆当然是可能的并且已经在许多早期实现中完成。 虽然拥有单个堆会使消息传递速度非常快,但它会引入许多其他问题,主要是因为它必须是交互式的且全局不中断的,所以做GC会变得更加困难,所以你不能使用相同的简单算法。进程堆模型。

只要我们使用具有不可变数据结构,就没有鲁棒性和安全性的问题。 决定使用哪种内存和GC型号是一个很大的权衡,不幸的是那里有普遍最好的模型。

虽然Haskell和Erlang都是函数式语言,但它们在许多方面都是非常不同的语言,并且具有非常不同的实现。 很难想出能够有效处理这两种语言的“Erskell”(或Haslang)机器。 我个人认为将它们分开并确保它们之间有一个非常好的接口要好得多。




Related

haskell functional-programming erlang garbage-collection ghc