LINUX.ORG.RU

История изменений

Исправление ergo, (текущая версия) :

забегая вперед, отвечу на вопрос «откуда х5, ведь сетевой стек у ерланга на си написан?»

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

ключевые особенности, которые дают прирост именно в реализации ergo:

  • ETF encoder/decoder имеет stackless реализацию. у ерланга этот кусок написан очень неэффективно, особенно когда речь идет о сложных структурах (списки, мапы, комплексные структуры с вложенностью). чем сложнее структура, тем результат у ерланга драматически хуже. у ergo этот кусок очень сильно отпрофилирован и сложность структуры не оказывает сильного влияния. посмотрите графики бенчмарков. технически, я могу показать и 10х кратное превосходство просто взяв, например, массив из структур с пачкой мапов). в свое время в ерланге даже сделали atom cache в сетевом стеке ибо атомы там очень активно используются. по их оценкам в то время это дало очень значительный прирост. когда начинал реализацию этой фичи в ergo тоже ожидал что-то существенное, но по факту получил 5-10% прироста. по всей видимости у них этот кеш закрывает другой очень неэффективный кусок функционала.
  • fragmentation support реализована в рамках реализации DIST (у erlang сборка/разборка фрагментов делается в BEAM машине, что тормозит очень сильно

да, все это х5 только касаемо сетевого стека. сравнивать производительность BEAM машины и кода на го - бессмысленно. там на порядки разница, очевидно, ибо интерпретация байткода не может быть быстрой по определению

Исправление ergo, :

забегая вперед, отвечу на вопрос «откуда х5, ведь сетевой стек у ерланга на си написан?»

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

ключевые особенности, которые дают прирост именно в реализации ergo:

  • ETF encoder/decoder имеет stackless реализацию. у ерланга этот кусок написан очень неэффективно, особенно когда речь идет о сложных структурах (списки, мапы, комплексные структуры с вложенностью). чем сложнее структура, тем результат у ерланга драматически хуже. у ergo этот кусок очень сильно отпрофилирован и сложность структуры не оказывает сильного влияния. посмотрите графики бенчмарков. технически, я могу показать и 10х кратное превосходство просто взяв, например, массив из структур с пачкой мапов). в свое время в ерланге даже сделали atom cache в сетевом стеке ибо атомы там очень активно используются. по их оценкам в то время это дало очень значительный прирост. когда начинал реализацию этой фичи в ergo тоже ожидал что-то существенное, но по факту получил 5-10% прироста. по всей видимости у них этот кеш закрывает другой очень неэффективный кусок функционала.
  • fragmentation support реализована в рамках реализации DIST (у erlang сборка/разборка фрагментов делается в BEAM машине, что тормозит очень сильно

Исходная версия ergo, :

забегая вперед, отвечу на вопрос «откуда х5, ведь сетевой стек у ерланга на си написан?»

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

ключевые особенности, которые дают прирост именно в реализации ergo:

  • ETF encoder/decoder имеет stackless реализацию. у ерланга этот кусок написан очень неэффективно, особенно когда речь идет о сложных структурах (списки, мапы, комплексные структуры с вложенностью). чем сложнее структура, тем результат у ерланга драматически хуже. у ergo этот кусок очень сильно отпрофилирован и сложность структуры не оказывает сильного влияния. посмотрите графики бенчмарков. технически, я могу показать и 10х кратное превосходство просто взяв, например, массив из структур с пачкой мапов)
  • fragmentation support реализована в рамках реализации DIST (у erlang сборка/разборка фрагментов делается в BEAM машине, что тормозит очень сильно