Здравствуйте, Arioch2, Вы писали:

G>>1) Операции со строками — слабое место Erlang.

A>Но все же ejabberd как-то справляется
И не только он . Так же совершенно пострясяюще справляется yaws.
И меня это сильно удивляет . Вспоминается анекдот про летающих крокодильчиков в цирке.

Короче, пытливому уму нет препятствий. "Были бы крылья, разбить можно", как говорил один из персонажей Duck Tales.

Но тезиса это не снимает. Написать быстрый код, работающий со строками — не самая прямолинейная задача. Надо либо переходить от строк к атомам, либо к binaries. Так, кстати, и сделано в парсерах XML для Erlang. Так они и справляются.

G>>Из пропущенных плюсов самый важный — binaries. Языку нет равных в описании бинарных данных и протоколов, сериализации и прочего. В этом он рвет всех, благодаря binaries.

A>Хммм, а C++ ?

Даже не смешно. Посоревнуемся? В этом вопросе — готов спорить на деньги. Впрочем, покажу сначала, с чем придется соревноваться. Я ж не зверь, все-таки — надо предупредить.

-define(IP_VERSION, 4).
-define(IP_MIN_HDR_LEN, 5).

DgramSize = size(Dgram),
case Dgram of 
    <<?IP_VERSION:4, HLen:4, SrvcType:8, TotLen:16, 
      ID:16, Flgs:3, FragOff:13,
      TTL:8, Proto:8, HdrChkSum:16,
      SrcIP:32,
      DestIP:32, RestDgram/binary>> when HLen >= 5, 4 * HLen =< DgramSize ->
            OptsLen = 4*(HLen - ?IP_MIN_HDR_LEN),
            <<Opts:OptsLen/binary, Data/binary>> = RestDgram,
    ...
end.

Здравствуйте, Gaperton, Вы писали:

G> Дык , Когда в основу библиотеки ложится значительная часть фреймворка промышленного коммутатора AXD301, то получается весьма изобильно. Как вам, например, наличие в стандартной библиотеке полного стека мультимедийных протоколов (Megaco)? Или распределенной отказоустойчивой базы данных (mnesia)? А вебсервера (inets)? И все в исходниках.
Пока не встречал людей, которые используют Мегако. И задачи с ним не попадались. Вот ASN.1 другое дело — вещь популярная и универсальная. Мнезию использую часто, но для сильно больших баз собираюсь приделать к ней back-end BERKELEY DB, чтоб Мнезия обрабатывала логику только верхнего уровня.

G>Все не так плохо, кстати. Hipe компилирует плавающую запятую по человечески, если на забыть поставить guard на float.
G>В Erlang maillist есть люди, которые рещают на Erlang DSP-задачи, и производительностью довольны.
У меня почему-то получается так, что задачи под Юниксами не нуждаются в float операциях, а вот под Вынями, где HIPE не собран, занимаются расчетами интенсивно

G>Но — если задача состоит в основном из числодробления — то Erlang все равно не лучший выбор.
Именно. Для этого есть Окамл, Сисал, Фортран...

G>> Нет штатного способа запихать все в один выполняемый файл ( несколько неудобно )
G>Есть работы в этом направлении. Я их не отслеживаю — но скоро все будет хорошо. Если не уже.
Да ? Я думал, что как Джо Армстронг на это поклал, то и работ никаких было

G>Пропущен один серьезный недостаток. Даже два.

G>1) Операции со строками — слабое место Erlang. Чтобы добиться хорошей скорости, надо использовать binaries для представления строк. По умолчанию, если написать "прпропро" — это будет список целых чисел. Оверхэд на ровном месте в 8 раз. Erlang — не самый лучший выбор для строковых манипуляций, если задача состоит только из них. Он не конкурент перлу.
Это по памяти...А по быстродействию — очень даже хорошо получается !

G>2) Массивы. В языке нет средств деструктивного изменения массивов. Это — реально плохо и неудобно, так как длинные массивы тормозят.
Вот чего не надо ! Принцип Once-Bounded Variable очень полезен, и спасает от многих глюков. Зачем вообще нужны очень большие списки ( или имелся в виду dict ) ?

G>Из пропущенных плюсов самый важный — binaries. Языку нет равных в описании бинарных данных и протоколов, сериализации и прочего. В этом он рвет всех, благодаря binaries.
Это да — но для очень некоторых применений. Я их использовал широко при работе с железом, но вот последние полгода бинарисы мне совершенно не нужны

G>Впрочем, покажу сначала, с чем придется соревноваться. Я ж не зверь, все-таки — надо предупредить.

По-моему тут демонстрируется pattern-mathcing и binding

А само описание битовых полей тут очень похоже на C++ ,кажется

Здравствуйте, Arioch2, Вы писали:

G>>Из пропущенных плюсов самый важный — binaries. Языку нет равных в описании бинарных данных и протоколов, сериализации и прочего. В этом он рвет всех, благодаря binaries.

A>Хммм, а C++ ?
Вах ! Когда, после долгого писания классов для обмена с левыми устройствами и системами по левым протоколам на С++, я использовал Ерланг, меня обуяло Щастье ! Обычное соотношение количества строк С++/Ерланг около 6, но для таких вещей — все 20
Да и скорость, как ни странно, часто бывает выше для Ерланга. Это за счет более эффективной логики обработки ( соответственно, не очень эффективной для С++ ) 8))

Здравствуйте, gandalfgrey, Вы писали:

G>Здравствуйте, Gaperton, Вы писали:

G>> Дык , Когда в основу библиотеки ложится значительная часть фреймворка промышленного коммутатора AXD301, то получается весьма изобильно. Как вам, например, наличие в стандартной библиотеке полного стека мультимедийных протоколов (Megaco)? Или распределенной отказоустойчивой базы данных (mnesia)? А вебсервера (inets)? И все в исходниках.
G> Пока не встречал людей, которые используют Мегако. И задачи с ним не попадались. Вот ASN.1 другое дело — вещь популярная и универсальная. Мнезию использую часто, но для сильно больших баз собираюсь приделать к ней back-end BERKELEY DB, чтоб Мнезия обрабатывала логику только верхнего уровня.

Это уже сделали ребята из Synapse, они доклад делали на эту тему на конференции. Тока не знаю, выложили ли они исходники. Говорят, к мнезии довольно легко прикрутить backend.

G>>Пропущен один серьезный недостаток. Даже два.

G>>1) Операции со строками — слабое место Erlang. Чтобы добиться хорошей скорости, надо использовать binaries для представления строк. По умолчанию, если написать "прпропро" — это будет список целых чисел. Оверхэд на ровном месте в 8 раз. Erlang — не самый лучший выбор для строковых манипуляций, если задача состоит только из них. Он не конкурент перлу.
G> Это по памяти...А по быстродействию — очень даже хорошо получается !

Возможно. Но в конфе пришли к выводу, что для строк рулят binaries.

G>>2) Массивы. В языке нет средств деструктивного изменения массивов. Это — реально плохо и неудобно, так как длинные массивы тормозят.
G> Вот чего не надо ! Принцип Once-Bounded Variable очень полезен, и спасает от многих глюков. Зачем вообще нужны очень большие списки ( или имелся в виду dict ) ?

Надо! Попробуй заведи тупл размером в 100 тыщ элементов (это аналог массива). И сделай ему несколько setelement-ов.

G>>Из пропущенных плюсов самый важный — binaries. Языку нет равных в описании бинарных данных и протоколов, сериализации и прочего. В этом он рвет всех, благодаря binaries.
G> Это да — но для очень некоторых применений. Я их использовал широко при работе с железом, но вот последние полгода бинарисы мне совершенно не нужны

Строки. Строки. И еще раз строки. А также сериализация. Плюс — binaries не копируются при передаче от процесса к процессу в качестве мессаги — оч. полезное свойство.

Здравствуйте, Arioch2, Вы писали:

G>>Впрочем, покажу сначала, с чем придется соревноваться. Я ж не зверь, все-таки — надо предупредить.

A>По-моему тут демонстрируется pattern-mathcing и binding
Конечно. А еще тут демонстрируются binaries, на которых происходит и то и другое.

A>А само описание битовых полей тут очень похоже на C++ ,кажется
Похоже Ну мало ли что на что похоже — ты берешься написать программу короче и понятнее — на С++?

Даже не так. Пусть у тебя есть некие объекты, и бинарный протокол. И тебе надо написать сериализацию этих объектов. Посмотрим, на что это будет похоже в С++ и в Erlang? Или и так понятно? Я вот писал и то, и другое, причем больше на С++. Разницу представляю. Она должна получиться раза в 4 — суммарно.

Здравствуйте, Gaperton, Вы писали:

G>> Это по памяти...А по быстродействию — очень даже хорошо получается !

G>Возможно. Но в конфе пришли к выводу, что для строк рулят binaries.
Странно...Сколько использую, для типично строчных операций — строки и быстрее. Для типично байтовых — понятно, быстрее бинарисы. как пример :
getb(Out,<<L,D:L/binary,R/binary>>)->getb([proceed(D)|Out],R).

G>Надо! Попробуй заведи тупл размером в 100 тыщ элементов (это аналог массива). И сделай ему несколько setelement-ов.
Гм. А зачем такое ? Я дикт заведу, или в етс положу. Это уже архитектурные проблемы

G>Строки. Строки. И еще раз строки. А также сериализация. Плюс — binaries не копируются при передаче от процесса к процессу в качестве мессаги — оч. полезное свойство.
При shared куче — вообще ничего не копируется

A>>По-моему тут демонстрируется pattern-mathcing и binding
G>Конечно. А еще тут демонстрируются binaries, на которых происходит и то и другое.

A>>А само описание битовых полей тут очень похоже на C++ ,кажется
G>Похоже

Я, скажем вежливо, не спец в C++, я его синтаксис очень ен люблю.
Но именно в битовых полях, как мне показалось, Эрланг и плюсы одинаковы.
Т.е. я возражаю против фразы "нет равных в описании бинарных данных "

G>Ну мало ли что на что похоже — ты берешься написать программу короче и понятнее — на С++?
Нет, не берусь, но не потому что битовые поля сделаны (офрмлены, описаны) лучше — так же.
А потому что работать с ними удобнее, равно как и с другими структурами — тот самый pattern-matching и binding
Ты же не будешь говорить, что описания структур в C++ сделаны хуже описаний record'ов в Эрланге ,потому что другие средства языка позволяют с ними удобнее работать

G>>Ну мало ли что на что похоже — ты берешься написать программу короче и понятнее — на С++?
A>Нет, не берусь, но не потому что битовые поля сделаны (офрмлены, описаны) лучше — так же.
A>А потому что работать с ними удобнее, равно как и с другими структурами — тот самый pattern-matching и binding
A>Ты же не будешь говорить, что описания структур в C++ сделаны хуже описаний record'ов в Эрланге ,потому что другие средства языка позволяют с ними удобнее работать


Имеется в виду не только описание, но и сериализация/десериализация описанных структур — все же данные надо будет потом передавать куда-то. В этом отношении Эрланг рулит

Здравствуйте, Mamut, Вы писали:

M>Имеется в виду не только описание, но и сериализация/десериализация описанных структур — все же данные надо будет потом передавать куда-то. В этом отношении Эрланг рулит

И все же главное — изоляция процессов и возможность написания НАДЕЖНОГО софта в присутстсвии программных ошибок.

Здравствуйте, Gaperton, Вы писали:

G>Ну да . А насчет "отсутствия статической типизации" можно было бы сказать "Dyalizer".

Сказать можно много чего. Но тут народ говорит о исходном Эрлэнге. И не нужно придумывать отмазки "почему не говорять всей правды". Или уж стоит сразу говорить, что речь идет не о системе испльзуемой в куче мест, а о исследовательском прокте Ххх. Но тогда и отношение людей будет другое.

Здравствуйте, gandalfgrey, Вы писали:

G> Не то чтоб совсем так. Байт-код, порождаемый компилятором, весьма быстр, И не уступит, к примеру, Жабе по скорости. И это именно КОМПИЛЯТОР.

Вот если услышишь слово "байт-код" и рядом не услышишь слова Jit-компилятор или пре-Jit, то сразу знай, что тебя обманывают.
Любой "быстрый" байткод в 10 и более раз медлнеее чем оптимизированный машинный.

VD>>Использовать в риалтайм системах может и можно, а вот написать на оном реалтайм-рантайм вряд ли. Хотя железо сейчас конечно многое позволяет, так что как знать.
G> Опять-таки не то говорите. Пару лет писал на Ерланге диспетчерские задачи ( мягкий реалтайм ), работу с железом... Время реакции порядка миллисекунд обеспечиваются свободно, причем на весьма дохлом железе.

Еще раз. Надо понимать разницу между понятием "риалтайм" и "быстрый". Не удивлюсь если самые тормозные интерпретаторы вроде Руби окажутся пригодными для софт-риалтам-задач. Вот только говорить о создании на таких языках софта способного конкурировать по скорости с тем что создается на компилируемых языках нельзя. А задач живущих на грани (а то и за гранью) процессорных возможностей еще ой как не мало.

Простой пример. Интерактивные игршуки. Да скрпты с успехом применяются для отработки логики в играх. Хотя игры ой как требуют скорости. Но писать движок физики или рендеринга на скриптах — это маразм. Работать конечно будет, но со скоростью черепахи.

G> Только С, и никаких ++. Собственно, как и у большинства других компиляторов и сред выполнения.

Это уже не важно. Главное, что не на самом себе.

Здравствуйте, Gaperton, Вы писали:

G>А рантайм, разумеется, на plain C. Было бы странно увидеть там другой язык.

Интересно, а почему не странно, что в Singularity рантайм написан в основном на C#? Что есть какие-то координальные различия между C# и Эрлэнг (как у языков)?

M>>Имеется в виду не только описание, но и сериализация/десериализация описанных структур — все же данные надо будет потом передавать куда-то. В этом отношении Эрланг рулит

G> И все же главное — изоляция процессов и возможность написания НАДЕЖНОГО софта в присутстсвии программных ошибок.

И не только программных, но и хардварных тоже

Making reliable distributed systems in the presence of hardware errors

Здравствуйте, VladD2, Вы писали:

VD>Любой "быстрый" байткод в 10 и более раз медлнеее чем оптимизированный машинный.
Это верно. Но только если сравнивать голое быстродействие. А вот ежели сравнивать на реальных задачах, то появляются очень странные результаты
Кроме того, HIPE сейчас является частью стандартной библиотеки. К сожалению, код под Виндозу пока не генерит — только под Линукс и Соляру

VD>Еще раз. Надо понимать разницу между понятием "риалтайм" и "быстрый". Не удивлюсь если самые тормозные интерпретаторы вроде Руби окажутся пригодными для софт-риалтам-задач. Вот только говорить о создании на таких языках софта способного конкурировать по скорости с тем что создается на компилируемых языках нельзя. А задач живущих на грани (а то и за гранью) процессорных возможностей еще ой как не мало.
Что такое скорость ? Если приложение на С++ работает медленнее, чем на Ерланге, это о чем говорит ? О скорости кода ? Совсем не уверен

VD>Простой пример. Интерактивные игршуки. Да скрпты с успехом применяются для отработки логики в играх. Хотя игры ой как требуют скорости. Но писать движок физики или рендеринга на скриптах — это маразм. Работать конечно будет, но со скоростью черепахи.
Для этого есть биндинг к низкоуровневым вещам. На Ерланге существуют игрушки, отображение у них сделано через OpenGL/SDL

G>> Только С, и никаких ++. Собственно, как и у большинства других компиляторов и сред выполнения.

VD>Это уже не важно. Главное, что не на самом себе.
Чтобы быть точнее :
Виртуальная машина на С ( + несколько встроенных функций )
Библиотеки на Ерланге (+ небольшой С++ модуль для КОРБЫ + махонький С модуль для АСН.1 + С для криптографии)

Здравствуйте, gandalfgrey, Вы писали:

G>Здравствуйте, VladD2, Вы писали:

VD>>Любой "быстрый" байткод в 10 и более раз медлнеее чем оптимизированный машинный.
G> Это верно. Но только если сравнивать голое быстродействие. А вот ежели сравнивать на реальных задачах, то появляются очень странные результаты

Это от "рельных" задач зависит. Если задача укладывается в область действия высокоуровневых библиотечкных функций, то да. А если нет, и нужно именно что на самом языке написать, то приплыли. Иначе зачем бы делали эти эксперементальные проекты на которыет тут ссылки давали рядом?

G> Кроме того, HIPE сейчас является частью стандартной библиотеки. К сожалению, код под Виндозу пока не генерит — только под Линукс и Соляру

Вот. Вот. И таких "к сожалению" море.

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

G> Что такое скорость ? Если приложение на С++ работает медленнее, чем на Ерланге, это о чем говорит ?

Ни о чем. Вот если они алогоритмически эквивалентны, и оба оптимизированны, то о чем-то говорит. Вот только чудес на свете не бывает.

Здравствуйте, Arioch2, Вы писали:

A>Я, скажем вежливо, не спец в C++, я его синтаксис очень ен люблю.
A>Но именно в битовых полях, как мне показалось, Эрланг и плюсы одинаковы.
A>Т.е. я возражаю против фразы "нет равных в описании бинарных данных "
Дело в том, что в C++ битовые поля вообще не предназначены для сериализации. Ну т.е. вообще никак (хотя их можно для этого использовать, если хотеть проблем или не нужна переносимость). Это неудивительно, т.к. в стандарте C++ ничего не гарантируется — ни представление чисел, ни порядок битовых полей в слове, ни порядок байт. Битовые поля позволяют экономить память — это все, что они переносимо могут делать.
Ну и pattern matching'a тоже в С++ нет.
Сравнивать нечего.

Здравствуйте, VladD2, Вы писали:
VD>Вот. Вот. И таких "к сожалению" море.

Ш-ш-... Остыньте "горячие эстонские парни"
"К сожалению" море в любом языке...

G>> Что такое скорость ? Если приложение на С++ работает медленнее, чем на Ерланге, это о чем говорит ?
VD>Ни о чем. Вот если они алогоритмически эквивалентны, и оба оптимизированны, то о чем-то говорит. Вот только чудес на свете не бывает.

Вот именно что "алгоритмически эквивалентны"... здесь-то собака и порылась.
Во-первых, в большинстве задач time-китичными является не более 10% кода. Который достаточно просто уложить на стандартные библиотеки. И практически везде они этими стандартными библиотеками уже закыты. ( Исключения — задачи типа "рендеинга", но они в большинсве случаев так же оформлены в виде библиотек, но уже специализированных. )

А вот дальше уже интереснее.
Пусть есть некий time-критичный элемент алгоритма T.
И есть два алгритма верхнего уровня A и B. Причем алгоритм A вызывает элемент T 100 раз, а алгоритм B — 1 раз.
Если весь остальной код не time-критичен, то получим, что алгоритм B, быстрее на два порядка.
НО! Может оказаться так, что на том же C (C++) алгорим B писать просто нельзя.
И не потому что "невозможно", а потому что там он "слипнется" в огромный кусок "лапши"... и в результате
1) станет неотлаживаемым (или крайне долго отлаживаемым)
2) станет несопровождаемым (главное! ведь речь не о системном, а о прикладном алгоритме).

Что же касается "чистого" быстродействия то я сравнивал ОДИНАКОВЫЕ алгоимтмы типа "проверки-вычисления" (АСКУЭ-биллинг с вариантами) на erlang и borland c++ builder. Соответсвенно под виндами, и без компиляции erlanga в HIPE.
В этих условиях erlang проигрывает c++ примерно в 1,8 раза (если откомпилить c++ интеловским компиляорм разрыв станет больше — примерно 2,6). Все это весьма легко перекрывается алгоримикой.
Кстати, что касается С#... делали ребята этот алгоритм на нем (переписали c++ версию) — .Net проиграл плюсам примерно в 3 раза, а значит получается проиграл и erlang-у. Не смотря на Jit-компилятор. Уж не знаю почему (подозреваю, что if-ы там слишком навороченно обрабатываются)...

VD>Вот если услышишь слово "байт-код" и рядом не услышишь слова Jit-компилятор или пре-Jit, то сразу знай, что тебя обманывают.

Нет, погоди, так байт-код или JIT ?
Были когда-то тесты Portable.NET интерпретатора (unroller'a, преобразует MSIL в более простой промежуточный язык, и дальше, кажется, пытается что-то типа шитого кода устроить) и JIT-компилятора — и цифры были сильно разные.
А ты на все[ одну десятку лепишь

VD>Интересно, а почему не странно, что в Singularity рантайм написан в основном на C#?

Экспериментальный проект. Запрототипируют, определятся на каких процессорах это будет запускаться, определят требования к скорости — и привет. А кроме того, кстати, неплохой тест для .NET библиотек и JIT

VD>Что есть какие-то координальные различия между C# и Эрлэнг (как у языков)?
Функциональный vs императивный ? Наверное есть
А уж библиотеки у них точно разные.