当我启动我的 Erlang 模拟器时，第一部分有一堆信息性的东西。（为了效果稍微重新格式化。）
manoa:~ stu$ erl
Erlang (BEAM) emulator version 5.6.5
[source] [smp:2] [async-threads:0] [hipe] [kernel-poll:false]
Eshell V5.6.5 (abort with ^G)
1>
其中一些我可以猜到，可能是准确的，但其中一些意味着“这里有魔法”。
Erlang (BEAM) emulator version 5.6.5: 当然是版本[source]: 模拟器是从源代码编译的？[smp:2]: 检测到两个 CPU 内核并可用[async-threads:0]：[hipe]: ?[kernel-poll:false]: ?我还想知道是否还有其他[foo]项目可能会弹出不同的配置、构建或启动参数。
那么，Erlang 模拟器信息语句是什么意思呢？
从 Erlang 20.0开始，完整的版本字符串标签集是：
BEAM 仿真器旨在充分利用 64 位 CPU。
这是指 Erlang 模拟器的异步线程池中的线程数，它或多或少地告诉您在模拟器停止之前可以将多少阻塞的系统调用分离到后台线程中。
虽然它目前默认为 10，但多年来默认为 0，这意味着所有系统调用都在每个 Erlang 仿真器线程中同步运行。当系统调用阻塞时，它会停止运行 Erlang 模拟器线程，直到系统调用完成。当前较小的默认值允许模拟器在系统调用阻塞异步 I/O 线程之一时尝试关闭并执行其他操作。
+A您可以使用Erlang 运行时的选项更改默认值。（例如erl +A 50）如果您要更改此设置，请注意您的结果将取决于您的特定系统和工作负载。过高的值可能会损害性能，因为它会导致系统在系统非常繁忙时尝试在后台执行许多操作，这只会使其更加繁忙。在某些工作负载上，禁用该功能erl +A 0可能是最佳选择。
仅当您不遗余力地构建备用 BEAM 仿真器并设置编译器选项以使生成的可执行文件更易于调试时，才会出现这种情况，就像使用gdb或类似的一样。您还必须以特殊方式运行此备用 BEAM 仿真器。
Erlang BEAM 仿真器通常是为速度而构建的，这通常会使调试器的工作变得更加困难。如果您正在开发 BEAM 仿真器的下一个版本，您可能会发现在改进工作时运行它的特殊调试版本会很有帮助。
要启用此模式，请在运行后cd进入erts/emulatorErlang 源代码树下 configure，然后键入类似ERL_TOP=../.. make FLAVOR=smp debug. 然后，要运行新的可调试 BEAM 仿真器，您必须bin/cerl -debug在构建完 Erlang/OTP 系统的其余部分之后，从 Erlang 源代码树的顶层运行。
有关此主题的更多信息，请参阅如何构建启用调试的 Erlang 运行时系统。
从 ERTS 9.0 开始，如果您构建了支持 SMP 的 BEAM 仿真器，则应始终显示此信息。它指的是“脏调度程序”功能。这些值描述了该系统上的功能配置。
这个特性是在 Erlang 19.0 中引入的，最初是作为一个实验特性，在 SMP 构建中默认情况下没有编译，就像在 Erlang 20.0 中一样。
如果您传递--with-dynamic-trace=dtrace给configure脚本以启用在 R15B01 中添加的实验性DTrace检测功能，则会出现。此功能预计仅适用于 OS X、Solaris 和 FreeBSD。将来它可能会在其他平台上运行。请参阅下面的[systemtap]以了解同时为 Linux 系统添加的替代方案。
这是上面[debug-compiled]选项的一个特例，除了它只禁用帧指针优化。在上面的命令中使用frmptr而不是启用此模式。debug
该模拟器是在启用HiPE功能的情况下编译的，它是 Erlang 的即时本地代码编译器。它只适用于 Erlang 支持的最流行的 CPU 类型，即使在那些 CPU 上也不能适用于所有配置，这就是它是可选的原因。
如果您ERTS_OPCODE_COUNTER_SUPPORT在构建期间定义，则会出现，这将启用 BEAM 操作码计数功能，这可能对那些分析 BEAM 仿真器性能的人有用。
Erlang 模拟器代码知道几种不同的方式来询问操作系统的网络堆栈，一组文件描述符和套接字中的哪一个可用于 I/O。唯一一个几乎在所有地方都可以使用的是旧的 BSDselect()调用，由于其设计，它相对较慢，此外还有其他可伸缩性问题。因此，大多数系统都有一个或多个更快且更具可扩展性的替代品——例如，kqueueepoll()等——但它们中的任何一个都不受任何地方的支持。当模拟器启动消息false在此处显示时，这可能意味着内核轮询不可用，或者它是但您没有传递+K true到erl.
如果您传递--enable-lock-check给配置脚本，则会出现。
如果您传递--enable-lock-counter给配置脚本，则会出现。
如果您传递--with-dynamic-trace=lttng给configure脚本以启用对LTTNG（Linux 的跟踪框架）的支持，则会出现。
当您运行Erlang BEAM 仿真器的特殊Purify感知版本时，就会出现这种情况。这些说明与上面[debug-compiled]部分中的说明相同，不同之处在于您使用purifyin commands 而不是debug.
如果您传递--enable-sharing-preserving给configure脚本，则会出现这种情况，这会导致在节点内共享不可变术语，而不是展平和重新创建它们。此选项是否使您的程序更快或更慢取决于程序的详细信息，因此在默认构建中未设置它的原因。
[ smp:2]标签在 Erlang R13 中更改为这种格式，表示 2 个调度程序，这两个调度程序都在线。如果你说“erl +S1”，它会改为[smp:1:1] 。您可以在运行时使用 erlang:system_flag(schedulers_online, N) 使调度程序脱机，其中 N 可以是 1 和检测到的内核数之间的任何值，包括在内。
这意味着某些第三方（可能是您，可能是您的操作系统发行版的软件包维护者，可能是您的系统管理员）从源代码构建了 Erlang。另一种方法是从 Erlang.org 下载官方二进制版本。
如果您从Git 存储库构建 Erlang ，此消息将更改为[source-8acc644]之类的内容，其中十六进制数字是存储库当前Git 哈希的片段，它允许您检查构建的源的确切版本给定可执行文件。
如果您传递--with-dynamic-trace=systemtap给configure脚本，则会出现。=dtrace这是此配置选项值的替代方案，使用SystemTap在 Linux 上提供基本相同的功能，因为 DTrace 通常在 Linux 上不可用。请参见上面的[dtrace]。
当您取消注释 中的ET_DEBUG行时出现erts/emulator/beam/erl_term.h，从而启用对所有特定于类型的数据访问的运行时检查。默认情况下未启用，因为它会减慢模拟器的速度。
当您运行特殊的Valgrind感知版本的 Erlang BEAM 仿真器时，就会出现这种情况。这些说明与上面[debug-compiled]部分中的说明相同，不同之处在于您使用valgrindin commands 而不是debug.
（此列表来自erts/emulator/beam/erl_bif_info.cErlang OTP 源代码树。请参阅erts_system_version文件顶部附近的定义。）
过时的标签：
可供加载的驱动程序使用的异步线程池的大小。这允许阻塞系统调用在与梁虚拟机不同的内核线程中执行。使用命令开关+A N调整池的大小。
支持 erlang 源代码和字节码的原生编译。往往对数字运算代码很有用。IO 绑定代码在字节码解释器上运行良好。
有旧的 select(2) 和 poll(2) 系统调用来接收通知，即某些文件描述符已准备好解除阻塞写入或读取。它们不能很好地扩展到大量打开的文件描述符。现代操作系统有替代接口，linux有epoll，freebsd有kqueue。使用命令开关启用+K true