我读过很多关于分布式Haskell的文章.已经做了很多工作,但似乎是在分配计算领域.我看到远程包似乎实现了Erlang风格的消息传递,但它是0.1和早期阶段.
我想实现一个系统,其中有许多单独的进程提供不同的服务,并由几个主要进程捆绑在一起.这似乎是Erlang的自然选择,但对于Haskell则不然.但我喜欢Haskell的类型安全性.
Haskell最近是否采用过Erlang风格的流程管理?
acf*_*zer 16
如果您想了解更多关于remote包的信息,也就是CloudHaskell,请参阅论文以及Jeff Epstein的论文.它的目的是准确地提供你想要的演员抽象,但正如你所说它处于早期阶段.关于parallel-haskell邮件列表的改进正在积极讨论,所以如果你有特定的需求remote没有提供,我们很高兴你跳进去帮助我们决定它的未来方向.
更成熟的但较低级别比remote是haskell-mpi包.如果你坚持使用Simple接口,可以发送包含任意Serialize实例的消息,但抽象仍然低于remote.
有一些实验系统,如在Haskell中实现高级分布式内存并行Haskell(Patrick Maier和Phil Trinder,IFL 2011,无法在线找到pdf)中所述.它融合了monad-par确定性数据流并行性的方法和使I结构在网络上可序列化的有限能力.这些抽象有望进行分布式计算,但由于重点是计算纯函数值而不是提供Erlang样式的过程,因此它们可能不适合您的应用程序.
另外,为了完整起见,我应该指出云上的Haskell wiki页面和HPC Haskell,它涵盖了我在这里描述的内容,以及分布式Haskell的子部分,它似乎需要刷新.
我经常感觉到IPC和演员都是超卖特征.有很多有吸引力的消息传递系统都有Haskell绑定,例如MessagePack,0MQ或Thrift.恕我直言,你唯一需要补充的是正确处理流程并决定谁/什么管理这种寻址能力.
顺便说一句:许多编码人员在他们的Erlang环境中采用了例如0MQ,这仅仅是因为它提供了通过消息代理构建消息传递的可能性,而不是依靠纯粹的流程来处理超大规模的消息传递.
在"大规模多核世界"中,我个人认为共享内存方法最终会超越消息传递.当然,有人可以随时提出异议.但是当你写下你想要通过"几个主要过程"将你的过程"联系在一起"时,你实际上已经谈到了同步.此外,您当然可以质疑单个函数,进程或线程是否是正确的并行化级别.
简而言之:我可能会看到MessagePack或0MQ是否能满足我在Haskell中的需求,并在我的代码中关注其余部分.
| 归档时间: |
|
| 查看次数: |
2426 次 |
| 最近记录: |