我目前正在使用Java，我在网上阅读了很多关于Erlang的内容，我有两大问题：
Erlang会比简单的Java慢多少（如果有的话）？ 我在这里假设Java将从网络上的shootout benchmarks更快（Erlang做得不好）。那么，我需要多少CPU才能让Erlang超越单线程Java（在我的特殊情况下，如下所示）？
在阅读了Erlang一段时间后，我发表了大量评论/帖子，说大多数大型Erlang系统包含大量的C / C ++。 这是出于速度原因（我的假设）还是别的什么？即为什么需要这样做？
我已经读过大多数机器的处理器数量上升和线程模型很难（我同意）但是我想找出什么时候会越过“线”以便我可以改变语言/范式在合适的时间。
一些背景/背景：
我在Java服务的服务器端工作，它非常受CPU限制，很容易并行。这通常是由于单个传入更新（通过TCP）触发了对多个（100个）输出的更改。
计算通常很简单（很少的循环，只需很多算术），输入速度非常快（100 / s）。
目前我们在4台CPU机器上运行，并在每台机器上运行多项服务（因此多线程非常无意义，而Java似乎运行得更快，没有同步块等，使其成为多线程）。现在有一个强大的速度推动，我们现在可以访问24台处理器机器（如果需要，每个进程），所以我想知道如何最好地继续 - 大规模多线程Java或更容易编码的东西，如Erlang。
答案 0 :(得分：7)
由于这是一个算术繁重的工作负载，并且您已经完成了将代码拆分为单独的服务进程的工作，因此您无法从Erlang中获得太多收益。你的工作似乎很适合Java。 Erlang擅长微小交易 - 例如msg切换或提供静态或简单动态的网页。不是 - 在企业数字运算或数据库工作负载方面。
但是，您可以在外部数值库和数据库的基础上构建并使用Erlang作为MSG交换机：D就是沙发数据库所做的：P
- 编辑 -
如果你将你的算术运算转移到一个Erlang async-IO驱动程序中，那么erlang就像语言输出一样好 - 但是有24个cpu可能就没那么重要了; erlang数据库是程序性的，而且速度非常快 - 这可以在你的应用程序中利用，在每次交易时更新100个实体。
erlang运行时系统需要是C和C ++的混合，因为（a）erlang模拟器是用C / C ++编写的（你必须从某处开始），（b）你必须与内核对话做异步文件io和网络io，以及（c）系统的某些部分需要快速起泡 - 例如，数据库系统的后端（失忆症）。
- 讨论 -
在使用共享内存总线的6核* 4 CPU拓扑中使用24个CPU - 您有4个NUMA实体（CPU）和一个中央内存。你需要对范式有所了解，无共享的多进程方法可能会扼杀你的记忆。
要解决此问题，您需要创建4个具有6个处理线程的进程，并将每个处理线程绑定到相应CPU中的相应核心。这6个线程需要进行协作多线程 - Erlang和Lua天生就有这个 - Erlang以硬核方式完成它，因为它有一个完整的调度程序作为其运行时的一部分，它可以使用创建任意数量的进程。
现在，如果您要在4个进程中划分任务（每个物理CPU 1个），那么您将是一个快乐的人，但是您正在运行4个Java VM正在做（可能是）认真的工作（因为很多原因而烦恼）。需要通过更好的切割和切割问题的能力来解决问题。
在Erlang OTP系统中，它专为冗余强大的网络系统而设计，但现在它正朝着同一台机器的NUMA-esque CPU发展。它已经有一个kick-ass SMP模拟器，很快就会成为NUMA。通过这种编程模式，您可以更好地使功能强大的服务器饱和，而无需终止您的总线。
也许这个讨论是理论上的;但是，当您获得8x8或16x8拓扑时，您也可以使用它。 所以我的回答是当你的主板上有超过2个 - 现代 - 物理CPU的时候，你应该考虑一个更好的编程范例。
作为此后讨论的主要产品示例：构建数据库引擎的Microsoft's SQL Server is CPU-Level NUMA-aware in the SQL-OS layer。
答案 1 :(得分：6)
您是否比较过新硬件的成本与在Erlang中重新培训员工的成本以及用新语言重新设计软件的成本？
我不会低估重新训练自己（或其他人）的费用以及在Erlang中雇佣熟悉的人的成本（他们将比很多找到比Java人更难找到的人）。服务器显然在存储成本/电力/维护等方面成本很高，但它们仍然比合格的员工便宜很多。如果您可以在使用当前技能组合的同时取得进步并保持可扩展性，我怀疑这是最实用的方法。
答案 2 :(得分：2)
编程语言的速度问题与问题一样复杂。 Java倡导者可以指出很多领域并声称速度最快，并且他们将100％正确。 Ruby / Python的拥护者指出了一组不同的参数，声称速度更快，而且它们也是正确的。然后，Erlang提倡指向并发连接，并声称在处理数百或数千个并发连接或计算时最快，并且也没有错。
看看有问题的项目的基本描述，在我看来，Erlang将非常适合您的需求。不知道细节我会说这实际上是一个非常简单的Erlang程序，并且可以在很短的时间内完成。
答案 3 :(得分：0)
这取决于几个因素。快速回答是，您需要对每个不同的程序进行基准测试，以了解静止水印的位置。
以下是可能影响该福利比率的一些相关方面：
1）计算依赖性：如果逻辑流与外部资源（DBMS，磁盘访问，网络）有很多依赖关系。并发处理中可分解的计算依赖性越大，采用分布式计算平台（如erlang）的好处就越大。
2）逻辑流原子性：如果您的程序必须在单个顺序同步流控制上花费大量计算时间，并且无法在较小的逻辑代码段上进行细分。代码原子性越大，分解为CPU传播流的可能性就越小。
3）状态共享开销：必须在各种功能上分配的数据量越大，框架只需传输和接收状态所需的开销就越大。换句话说，如果您在没有公共共享缓存区域的情况下重复发送大量数据，那么优势将会降低，尽管根据采用的编程模式，这有不同的方法。
因此，鉴于基于上述标准的巨大可能性和变化，不可能有一个所有情景都可接受的共同估计。
答案 4 :(得分：-6)
如果你每秒得到100，但每次得100分，它怎么可能跟上？也许我误读了这一部分，但无论如何，除非数秒或数百万的请求一秒钟，你的同步代码不应该花费很长时间。如果是，你做错了，可能在你执行整个工作时锁定。
对于多线程代码，使用更高级别的语言可能是一个错误。即使您在erlang中编写应用程序部分，或者多线程应该使用Java编写，或者如果性能确实成为问题，请转移到C ++。