在Erlang W/o可伸缩性牺牲中进行计算密集型任务的最佳方式是什么？

Erlang Interoperability指南讨论了不同的互操作性机制。这里是我的结论：在Erlang W/o可伸缩性牺牲中进行计算密集型任务的最佳方式是什么？

端口和Erl_Interface程序：操作系统调度，限制可伸缩性。
端口驱动程序：危险，因为端口驱动程序崩溃导致模拟程序也下降。
C节点：节点服务器需要扩展以及Erlang应用程序以避免的可扩展性牺牲。
NIF：Loic总和他们很好。

一些人主张使用OpenCL，基本上将资源耗费的计算委托给GPU，同时让Erlang仿真器拥有CPU。这听起来很棒，但是你需要在你的服务器上安装合适的GPU。

使用JInterface并与为每个请求产生线程的Java进程进行通信可能是一个选项。

那么有没有人遇到过一个在实践中已经过测试的解决方案，而且结果很好？

2015-09-29 coolfeature

您链接到的NIF的描述看起来过时并且不准确。例如，在调度器上运行的NIF“超过几微秒”不会导致问题;只有在NIF运行超过几毫秒时才会发生这种情况。此外，['enif_schedule_nif'函数]（http://www.erlang.org/doc/man/erl_nif.html#enif_schedule_nif）提供了一个很好的方法来分解长NIF以避免调度程序问题，再加上实验[dirty调度程序功能]（http://www.erlang.org/doc/man/erl_nif.html#dirty_nifs）NIF可以在不引起调度程序打嗝的情况下运行。 –

要使用脏调度程序功能，您需要构建启用了实验性脏调度程序支持的模拟程序。我不认为运行具有实验功能的生产代码的想法会有许多爱好者。一般来说，NIF似乎有点危险。正如Loic所指出的那样，他们可能会让虚拟机崩溃编译在Windows下使用它们的库是一场噩梦 - 我不喜欢在Windows上运行Erlang。 – coolfeature

实验性的脏调度器功能有一天会成为一个常规功能，希望在Erlang 19中。我实现了Erlang/OTP的脏调度程序功能，并且启用了它的所有Erlang 17和18 VM，并且没有任何问题。此外，请参阅[这些度量]（https://medium.com/@jlouis666/erlang-dirty-scheduler-overhead-6e1219dcc7），其中显示将进程切换到脏调度程序所涉及的少量开销。 –

其实所有解决方案都发生。由于我一直在与他们中的一些人紧密合作，我可以这样说：

端口是安全的，但端口通信缓慢。如果端口崩溃，虚拟机将继续工作。如果您没有广泛地与您的端口通信，或者您不信任端口 - 这是您的选择
NIF非常快。如果你的数据流很好，你应该使用它们。当然，它们是不安全的，所以你必须仔细编程NIF库，你最好学习一些C（大多数NIF创建者跳过的点）。事实上，调度问题很容易用特定的模式来克服。在从Erlang接收数据并从Erlang线程中分离处理之后，您应该启动新的C线程来完成实际的工作。所以你很快退出NIF函数并返回Erlang并等待C代码发出消息。
Java节点或C节点用于可以完全移动到节点的任务。这是一些长期而沉重的工作。

考虑以上因素，您可以决定最适合您的任务的方式。

来源

2015-09-29 18:25:01 Lol4t0

你会同意没有银弹吗？端口是可扩展性和可靠性之间的折衷，除非写得很好，否则NIF是Erlang弹性的风险。从集成的角度来看，可伸缩的C或Java节点可能是一个很好的选择。 – coolfeature

@coolfeature，与NIF进行比较，独立节点的通信速度仍较慢。 Erlang只有有限的套接字池（如果我没有弄错），你将不得不序列化/反序列化数据。如果处理数据的时间明显大于序列化/传输/反序列化的时间，独立节点将适合您。 – Lol4t0

在Erlang W/o可伸缩性牺牲中进行计算密集型任务的最佳方式是什么？

回答

相关问题