Что означают утверждения информации эмулятора Erlang?

Когда я запускаю свой эмулятор 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]: обнаружены и доступны два ядра процессора
  • [async-threads:0]: текущие рабочие задания?
  • [hipe]:?
  • [kernel-poll:false]:?

Я также задаюсь вопросом, есть ли другие элементы [foo], которые могут появляться с различными конфигурациями, строками или параметрами запуска.

Итак, что означают операторы информации эмулятора Erlang?

ОТВЕТЫ

Ответ 1

[асинхронная тема: 0]

Размер пула потоков async для загруженных драйверов. Это позволяет блокировать системные вызовы в отдельном потоке ядра из луча vm. Используйте команду switch +A N, чтобы настроить размер пула.

[HIPE]

Поддержка родной компиляции источника erlang и байт-кода. Как правило, он полезен для кода хруста. Код, привязанный к IO, отлично работает с интерпретатором байт-кода.

[ядро-опрос: ложь]

Существует системный вызов old select (2) и poll (2) для получения уведомления о том, что некоторый файловый дескриптор готов для разблокирования записи или чтения. Они недостаточно масштабируются для большого количества дескрипторов открытых файлов. Современные операционные системы имеют альтернативные интерфейсы, linux имеет epoll, freebsd имеет kqueue. Включить с помощью командного переключателя +K true

Ответ 2

По сравнению с Erlang 20.0 полный набор тегов строки версии:

[64-битный]

Эмулятор BEAM построен для полного использования 64-битного процессора.

[асинхронных потоки: 10]

Это относится к числу потоков в пуле асинхронных потоков эмулятора Erlang, который более или менее говорит вам, сколько заблокированных системных вызовов можно выделить в фоновом потоке до того, как эмулятор закроется.

Несмотря на то, что в настоящее время по умолчанию используется значение 10, значение по умолчанию равно 0 в течение многих лет, а это означает, что все системные вызовы выполнялись синхронно в каждом потоке эмулятора Erlang. Когда системный вызов заблокирован, он прекратил работу потока эмулятора Erlang до завершения системного вызова. Текущее небольшое значение по умолчанию позволяет эмулятору попытаться отключиться и сделать что-то еще, в то время как системный вызов блокирует один из потоков асинхронного ввода-вывода.

Вы можете изменить значение по умолчанию с помощью параметра +A для среды выполнения Erlang. (например, erl +A 50). Если вы собираетесь изменить это, остерегайтесь того, что ваши результаты будут зависеть от вашей конкретной системы и рабочей нагрузки. Слишком высокое значение может повредить производительность, потому что это заставляет систему пытаться делать много вещей в фоновом режиме, когда система очень занята, что только делает ее еще более занятой. При некоторых нагрузках оптимальным вариантом может быть отключение функции с помощью erl +A 0.

[отлаживать скомпилированный]

Это появляется только в том случае, если вы выберете свой альтернативный эмулятор BEAM с параметрами компилятора, чтобы облегчить отладку полученного исполняемого файла, например, gdb или тому подобное. Вы также должны запускать этот альтернативный эмулятор BEAM особым образом.

Эмулятор Erlang BEAM обычно создается для скорости, что часто затрудняет работу отладчика. Если вы работаете над разработкой следующей версии эмулятора BEAM, вам может быть полезно запустить специальные сборки отладки, поскольку вы улучшаете свою работу.

Чтобы включить этот режим, cd в erts/emulator в дереве источников Erlang после запуска configure на нем, введите что-то вроде ERL_TOP=../.. make FLAVOR=smp debug. Затем, чтобы запустить новый отлаживаемый эмулятор BEAM, вы должны запустить bin/cerl -debug с верхнего уровня исходного дерева Erlang, после того как остальная часть системы Erlang/OTP была построена.

Подробнее об этой теме см. Как создать отладочную систему Erlang RunTime System.

[DS: 1:1: 1]

Как и в случае с ERTS 9.0, это всегда должно появляться, если вы создали эмулятор BEAM с поддержкой SMP. Это относится к функции грязные планировщики. Значения описывают конфигурацию функции в этой системе.

Эта функция была введена с Erlang 19.0, первоначально как экспериментальная функция, которая по умолчанию не была скомпилирована в сборках SMP, как и в Erlang 20.0.

[DTrace]

Появляется, если вы передали --with-dynamic-trace=dtrace в configure script, чтобы включить экспериментальную функцию инструмента DTrace, добавленную в R15B01, Предполагается, что эта функция будет работать только на OS X, Solaris и FreeBSD. Он может работать на других платформах в будущем. См. [systemtap] ниже для альтернативы, добавленной одновременно для систем Linux.

[кадр указатель]

Это особый случай параметра [debug-compiled] выше, за исключением того, что он отключает оптимизацию указателя фрейма. Используйте frmptr вместо debug в приведенных выше командах, чтобы включить этот режим.

[HIPE]

Эмулятор был скомпилирован с включенной функцией HiPE, которая является компилятором собственного кода на лету для Erlang. Он работает только на самых популярных типах процессоров, которые поддерживает Erlang, и он не работает со всеми конфигурациями даже на этих CPU, поэтому он необязателен.

[инструкция подсчета]

Появляется, если вы определяете ERTS_OPCODE_COUNTER_SUPPORT во время сборки, что позволяет использовать функцию подсчета количества операций BEAM, предположительно полезную для этих профилирующих характеристик эмулятора BEAM.

[ядро-опрос: ложь]

Код эмулятора Erlang знает несколько разных способов спросить сетевой стек OS, который из набора дескрипторов файлов и сокетов доступен для ввода-вывода. Единственный, который работает почти повсеместно, - это старый вызов BSD select(), который относительно медленный из-за его дизайна и имеет другие проблемы с масштабируемостью. Таким образом, большинство систем имеют одну или несколько более быстрых и масштабируемых замен -— например, kqueue, epoll() и т.д. — но ни одна из них не поддерживается повсюду. Когда сообщение запуска эмулятора говорит false здесь, это может означать, что этот опрос ядра недоступен или что он есть, но вы не прошли +K true до erl.

[блокировка проверка]

Появляется, если вы передали --enable-lock-check в конфигурацию script.

[блокировка счета]

Появляется, если вы передали --enable-lock-counter в конфигурацию script.

[lttng]

Появляется, если вы передали --with-dynamic-trace=lttng в configure script, чтобы включить поддержку LTTNG, структуру трассировки для Linux.

[очистить скомпилированные]

Это появляется, когда вы запускаете специальную Purify -аву версию эмулятора Erlang BEAM. Инструкции те же, что и в разделе [debug-compiled], за исключением того, что вы используете purify в командах вместо debug.

[обмен сохраняющий]

Это появляется, если вы передаете --enable-sharing-preserving в configure script, что приводит к обменивать неизменяемые термины intra- node вместо сплющивания и воссоздания. Является ли эта опция более быстрой или медленной, ваша программа зависит от деталей программы, поэтому почему она не установлена ​​в сборке по умолчанию.

[SMP: 2: 2]

Тег [smp: 2] был изменен на этот формат в Erlang R13, что означает 2 планировщика, оба из которых находятся в сети. Если вы скажете "erl + S1", вместо него будет указано [smp: 1:1]. Вы можете запускать планировщики в автономном режиме во время выполнения с помощью erlang: system_flag (schedulers_online, N), где N может быть чем угодно между 1 и количеством обнаруженных ядер, включительно.

[источник] или [источник-ВЕРСИЯ]

Это означает некоторую третью сторону (возможно, вы, возможно, ваш поддерживающий дистрибутив ОС, может быть, ваш системный администратор) построили Erlang из исходного кода. Альтернативой является загрузка официальной бинарной версии с сайта Erlang.org.

Если вы создадите Erlang из репозитория Git, это сообщение изменится на нечто вроде [source-8acc644], где шестнадцатеричное число является фрагментом текущего репозитория Git хеш, который позволяет вам проверить точную версию источник, который построил данный исполняемый файл.

[Systemtap]

Появляется, если вы передали --with-dynamic-trace=systemtap в configure script. Это альтернатива значению =dtrace для этой опции конфигурации, предоставляя по существу те же функции в Linux, что и SystemTap, поскольку DTrace is обычно не доступны в Linux. См. [dtrace] выше.

[тип-Утверждения]

Появляется, когда вы раскомментируете строку ET_DEBUG в erts/emulator/beam/erl_term.h, что позволяет проверять время выполнения всех запросов доступа к конкретному типу. Не включен по умолчанию, поскольку он замедляет эмулятор.

[Valgrind скомпилированные]

Это появляется, когда вы запускаете специальную Valgrind - версию эмулятора Erlang BEAM. Инструкции те же, что и в разделе [debug-compiled], за исключением того, что вы используете valgrind в командах вместо debug.

(Этот список исходит от erts/emulator/beam/erl_bif_info.c в исходном дереве Erlang OTP. См. определение erts_system_version в верхней части файла.)

Устаревшие теги:

  • Оптимизация [64-бит halfword] для 64-битных сборников эмулятора BEAM была добавлена ​​в R14, а затем удалена без объяснений в 19.0. Это также удаляет возможность видеть тег [no-c-stack-objects], который был связан с эмулятором halfword.

  • Тег [rq: 2] относится к системе очереди выполнения, предназначенной для повышения масштабируемости в SMP-сборках эмулятора Erlang BEAM. Добавлено в R13B, оно было заменено в R15B на лучшее решение.

  • [гибридная куча] и [инкрементный GC]теги и связанные с ними функции были удалены в R15B02 по существу потому, что они были неудачные опыты.