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