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

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

Да ради бога. Возражай на здоровье. У нас свободная страна .

<< X:3/little-signed-integer-unit:8 >> = Number.
Я только что считал знаковое целое число в кодировке little endian, состоящее из трех элементов по 8 бит. Повтори на С++ — посмотрим, сильно ли помогут тебе битовые поля.

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

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

Там нет JIT. И возможно ОС станет доступна открыто.

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

Я тебе без проблем на Шарпе в функциональном стиле напишу. А любой рантайм любого ФЯ является императивным. (железо такое) Так что это все разговор о высокоуровневых концепциях. Фактической разницы нет.

A>А уж библиотеки у них точно разные.

И что? Это не позволяет писать рантайм на Эрлэнге?

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

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

Не нужно рассказывать сказки.

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

Что дло задачь, то ты это расскажи тем кто пишет тот самый критический код. Сколько там не критичного к скорости кода в рассчете физики современной игрушки? И что их тогда пытаются на одтельные специализированыне камни скинуть?

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

VD>>Ни о чем. Вот если они алогоритмически эквивалентны, и оба оптимизированны, то о чем-то говорит. Вот только чудес на свете не бывает.
G>Алгоритмически эквивалентны на столь разных языках ? Воистину, чудес не бывает

Алгоритм есть алгоритм. Он может быть не реализуем на чистых ФЯ, но на любом ИЯ любой рабочий алгоритм реализуем. Так что если есть алгоритм Х на ФЯ, то его за всегда можно переписать на ИЯ.

ЗЫ

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

Сейчас исследователи капают в сторону совмещения аннотации типов с выводом типов. Хороший прпимер такого подхода — это Немерл. Но для этого язык должен поддерживать аннотакцю типов! А Эрлэнг или Лисп с аннотацией типов (да и вообще Лисп с типами) — это уже другой язык!

По этому я говорю, чудес не бывает. КОмпиляторы ОКамл, и др. клонов МЛ, а так же других статически-типизированных языков имеют все шансы рано или поздно сровняться с С++-компиляторами по скорости. Возможно даже обойти их на некоторых задачах. В общем, конкурировать с ними. Но чистые динамически типизированные языки конуренты для скриптов, коеми они в общем-то и являются. И лучшее на что они могут претиндовать — это на 5х тормоза, ну, и на большую библиотеку написанную на С.

И это принципиальное ограничение, так как контоль типов в рантайме и вообще таскание описания типов за собой в рантайме не бесплатны!

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

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

Не может быть интерпретатор быстрее компилятора. Ну, не может. Это уже деверсия.

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

G>>запросто ! в форте и намека на типы нет, а работает ! я уж не говорю про ассемблер, где вся типизация представляет собой обман зрения 8))

WF>Да, но они не типобезапосны, в отличие от Erlang-а.

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

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

Извини, но ты полностью не владешь терминологией. То того и разговор конструктивный получиться не может. Зайди в Википедию и прочти определения терминов:
Type Safe.
Staticaly typet.
и т.п.

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

G>1. Сложная логика обработки. Вместо 1000 строк с if/switch получится 50 строк case

Верится с трудом.

G>2. параллельность. Тут конкурентов вообще нет

Есть.

G>3. обработка потоков данных, сложных бинарных структур

Хм. Хотел бы я знать на чем это нельзя делать?

G>4. системы повышенной надежности, для непрерывной работы на протяжении месяцев и лет. У меня есть несколько приложений, в которых сдохшие по какой-то причине системы перезапускаются себе и работают дальше, никому не вредя.

Хм. На Яве их тоже делают. Единственная заслуга Эрлэнга в этом плане — это тпобезопасность и относительно безопасная система работы с потоками (за каким-то хреном названная процессами).

Можешь назвать еще? Ну, и причин по которым в других средах нельзя получить тоже самое.

G>5. когда нужна портабельность — полностью переносим, без каких-либо заморочек. У меня один и тот же код работает под Linux/FreeBSD/Windows

Боюсь, С в этом лане более выигрышен.

G>6. распределенные системы — опять-таки не с чем сравнивать

Опять таки на той же Яве их делают тоннами.

G>Если хоть что-то из этого используется в разрабатываемом приложении — Ерланг в руки !

Сдается мне ты преукрашиваешь.

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

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

Ну, а МТС вроде как учет то ли на С++-ных, то ли на Явских приложениях ведет. Тоже вроде связать неплохая.

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

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

M>>А можно поинтересоваться, какие системы? Ну хотя бы приблизительно

G>Распределенный сбор данных с промышленных датчиков.

OPC не используете? А то я на досуге по вечерам пишу библиотеку для доступа к OPC-серверам из Erlang-а. Велосипед изобретаю?

Здравствуйте, VladD2, Вы писали:
VD>Не нужно рассказывать сказки.

А никто и не рассказывает. Цифры с реальных проектов...

Ты похоже допускаешь одну и ту же ошибку (в разных темах на разных форумах):
например сравниваешь с "идеальным" кодом на C/С++... И скорее даже надо говорить "на С", поскольку как только в куске кода вылазят классы/полиморфизм/виртуальные функции, так производительность сразу плывет сам знаешь куда.

Но вот только я уже давно не встречал в прикладных алгоритмах этого самого "идеального кода". Это нонче совершенно реликтовый зверь. Реально же тот же C++ это часто например STL (а реализация map-ов в нем "мама не горюй..."). Или офигеннейшее "дерево классов" или еще что в том же духе. Тот же dynamic cast например (порой зарытый в библиотеки).
Или посмотри асемблерник дельфийского приложения, там местами вообще шитый код с динамической типизацией вылазит.

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

Так что ты просто "не туда копаешь". Erlang — не самый быстый из декларативных языков (OCaml его уделает на раз), но он есть часть полноценной промышленной платформы. И сравнивать его надо с такими же языками платформ.
Бенчмарков с C# .Net я не нашел, но нашлись сравнения с C# Mono.
Тесты правда "фрагментарные" — на отдельные элементы алгоритмов, что "не выгодно" Erlang-у, в котором оптимизиуется именно сложные алгоритмы в целом. Ну да пусть.
Итак:
1. Аккерман (вычисления): C#, Erlang
Здесь Erlang серьезно проигрывает по быстродействию — 2,85 раза (хотя выигрывает по памяти в 1,4 раза).
Иными словами чистые вычисления C# делает лучше.

2. Добавляем элементы логики. Хотя бы минимальные — обход двоичного дерева: C#, Erlang
Здесь проигрыш Erlang-а по производительности составляет уже только 1,45 раза и при этом выигрышь по памяти в 1,63 раза. Если еще учесть 29 строк исходного кода Erlang-а против 42 строк C#, то еще большой вопрос, кто здесь выигрывает.

3. Еще увеличим "логический элемент" теста. Вычисление знаков числа Pi. Алгоритм содержит достаточно много условных конструкций. (По этому показателю приближается к биллинговым задачам, о которых я писал в прошлом сообщении.)
Вот тесты: C# и Erlang.
Здесь уже Erlang выигывает у C# в 1,9 раза (проигрывая по памяти в 1,02 — практически на равне).
Но самое существенное: 34 строки кода Erlang-а против 126 строк на C#.
Последнее, для прикладных алгоитмов (требующих постоянного сопровождения) — решающий фактор.
Очень советую зайти по ссылочкам и глазами посмотреть исходники последнего теста...

И еще (чтобы небыло разговоров, про сравнение только с C#) вот последний тест на Java.
Java здесь проигрывает Erlang-у в 2,5 раза по скорости и в 2,6 раза по памяти.
При этом имеет 78 строк кода (правда стоит признать — выигрышь по строкам отностительно C# отчасти за счет фоматирования циклов в однк строку).

То есть одна из основных "родных" областей Erlang-а — анализ ситуаций (в сумме например с некотрым количеством вычислений или управляющих воздействий).


VD>Что дло задачь, то ты это расскажи тем кто пишет тот самый критический код. Сколько там не критичного к скорости кода в рассчете физики современной игрушки? И что их тогда пытаются на одтельные специализированыне камни скинуть?

Лет 8 назад занимался я этим классом задачь. Так что знакомо.
Там критичного кода много — на вскидку около 30% (это действительно много). Да только вот доля "физики" в общем коде игрушки (если это не совершенно тупая стрелялка) не столь уж велика. Так что "физику" целиком можно рассматривать как некую "библиотеку". ("Специализированную", как я уже и писал.)

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

Это меня переглючило Массивы, конечно, для этого случая.
А обратные ссылки помогут для тех случаев, когда советуют строку развернуть ногами... В смысле, хвостом вперёд, и обрабатывать с хвоста. А потом развернуть обратно.

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

VD> Там нет JIT.
Определятся с требованиями и железом — и подумают, решат, что нужно — сделают. Пока может в любую стороны изменться.

VD> И возможно ОС станет доступна открыто.
Это, типа, евангелизм? Зачем?
Ну хорошо, станет доступна открыто — будет еще больше похожа на уже открытый Erlang :D


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

VD>Я тебе без проблем на Шарпе в функциональном стиле напишу. А любой рантайм любого ФЯ является императивным. (железо такое) Так что это все разговор о высокоуровневых концепциях. Фактической разницы нет.

Ну изхвини, так можно скзаат mxnj между языками разницы вообще нет, в конце концов рано или поздно исполняется машинный код

A>>А уж библиотеки у них точно разные.
VD>И что? Это не позволяет писать рантайм на Эрлэнге?

Нет, это к вопросу о разнице в языках. Согласись, что стандартные библиотеки сильно определяют стиль.

Что до рантайма — не знаю, на Яве вроде писали soft-realtime мини-OS.
Может быть не сильно нужно. Ну вот к примеру, захочу я сделать распределенную систему работающую с деньгами.
Понятно что возникает куча проблем с перехватом / подменой данных.
Сейчас я запускаю рантайм в Win/Linux/etc,etc а в рамках ОС настраиваю фиксированные зашифрованные соединения, которыми Эрланг пользуется.

Делаем ОС на Эрланге — и эти же проблемы надо решать с нуля. Сетевые настройки, шифрование... Зачем? Just for fun ? Можно и существующий рантайм улучшать, пример — HiPE.
Вдруг что интересное пропустишь? Так нет у Эрлангеров ресурсов Microsoft Research.

VD>И это принципиальное ограничение, так как контpоль типов в рантайме и вообще таскание описания типов за собой в рантайме не бесплатны!

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

A>>А ты на всё одну десятку лепишь

VD>Не может быть интерпретатор быстрее компилятора. Ну, не может. Это уже деверсия.

Не может. По крайней мере в при равном качестве реализации.
Но согласись, что JIT и интерпретатор — тоже сильно разные вещи, а ты их в одно валишь.

И кроме того, тут вроде никто не предлагает сравнивать в чистом виде C и Erlang ,как компиляторы/интерпретаторы.

Говорят о том, что на Erlang'e привычно и удобно писать некотороые классы программ, используя алгоритмы, которые обгонят алгоритмы, которые (для этих классов задач) привычно и удобно писать на C++.

Мне этот спор напоминает ASM vs C.
Ясно, что если у меня нет ограничений по времени и мозги на месте, то я оттюнингую ассемблерный код лучше компиляторного. Также ясно, что случаи где эта оптимизация оправдает гигантское потраченное время сейчас исчезающе редки. И аньше они были много чаще, но постепенно баланс стал смещаться. И тамкже Erlang vs С++, сегодня один баланс, завтра будет другой и т.д.

В конце концов, ты же пишешь на C#, хотя сам говоришь, что JIT должен проигрывать нативному компилятору

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

F>OPC не используете? А то я на досуге по вечерам пишу библиотеку для доступа к OPC-серверам из Erlang-а. Велосипед изобретаю?
OPC — это по определению WIN32, ибо COM. У меня система гетерогенная, и на Виндовс только клиентские машины, так что OPC не использую.
Но встречал я упоминание в сетях об открытых сорцах С++ OPC сервера, в эхе ASUTP мелькало. По слухам, код там небольшой, и его можно будет прикрутить как драйвер к Ерлангу.

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

VD>Алгоритм есть алгоритм. Он может быть не реализуем на чистых ФЯ, но на любом ИЯ любой рабочий алгоритм реализуем. Так что если есть алгоритм Х на ФЯ, то его за всегда можно переписать на ИЯ.

Вообще-то, алгоритм не есть самоцель. Некую поставленную задачу я буду решать разными способами, в зависимости от инструмента. Так и реализация алгоритмов на ФЯ и ИЯ будут существенно отличаться. Возможно, будут отличаться и сами алгоритмы.

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

G>>1. Сложная логика обработки. Вместо 1000 строк с if/switch получится 50 строк case
VD>Верится с трудом.

Тем не менее — это так. Паттерн матчинг рулит !

G>>2. параллельность. Тут конкурентов вообще нет
VD>Есть.
Гм. А что еще имеет столь же легковесные процессы и такую же простоту взаимодействия между ними ?

G>>3. обработка потоков данных, сложных бинарных структур
VD>Хм. Хотел бы я знать на чем это нельзя делать?
А вот я хотел бы знать, на чем это можно ПРОСТО сделать ?

G>>4. системы повышенной надежности, для непрерывной работы на протяжении месяцев и лет. У меня есть несколько приложений, в которых сдохшие по какой-то причине системы перезапускаются себе и работают дальше, никому не вредя.
VD>Хм. На Яве их тоже делают. Единственная заслуга Эрлэнга в этом плане — это тпобезопасность и относительно безопасная система работы с потоками (за каким-то хреном названная процессами).
Я еще понял бы, если б упоминалась Ада, Модула-2/3...Но Ява ! Можно пример таковых систем ?
И процессы в Ерланге — это именно процессы, ибо они полностью изолированы, и обмениваются лишь сообщениями.

G>>5. когда нужна портабельность — полностью переносим, без каких-либо заморочек. У меня один и тот же код работает под Linux/FreeBSD/Windows
VD>Боюсь, С в этом лане более выигрышен.
Да ? А как с длиной целого, например ? Портабельность С — это легенда. Даже при смене версии ОС может вылезти что-нибудь непотребное...

G>>6. распределенные системы — опять-таки не с чем сравнивать
VD>Опять таки на той же Яве их делают тоннами.
Не такого размаха, я бы сказал.

G>>Если хоть что-то из этого используется в разрабатываемом приложении — Ерланг в руки !
VD>Сдается мне ты преукрашиваешь.
Да не ! Правда-правда ! 8))

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

VD>Ну, а МТС вроде как учет то ли на С++-ных, то ли на Явских приложениях ведет. Тоже вроде связать неплохая

Весь вопрос в человеко-месяцах, которыми обеспечивается должная надежность и устойчивость.
Мне есть с чем сравнивать — первая версия системы была на С++, и в нее вбито 20 чел. месяцев
на Ерланге, с ноля, я написал БОЛЕЕ устойчивую вещь менее чем за 3 месяца
я говорю о пересекающейся функциональности обоих систем, конечно
А про биллинг на С++/Жабе лучше и не упоминать ! Я знаю положение дел в 4 более-менее крупных конторах, кои пишут биллинг для сотовых, и везде кучи глюков, падения и прочие радости. А сколько там народа на этом сидит !

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

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

F>>OPC не используете? А то я на досуге по вечерам пишу библиотеку для доступа к OPC-серверам из Erlang-а. Велосипед изобретаю?
G>OPC — это по определению WIN32, ибо COM. У меня система гетерогенная, и на Виндовс только клиентские машины, так что OPC не использую.
G>Но встречал я упоминание в сетях об открытых сорцах С++ OPC сервера, в эхе ASUTP мелькало. По слухам, код там небольшой, и его можно будет прикрутить как драйвер к Ерлангу.

Теоретически есть возможность писать OPC-сервера и клиенты под Unix, видел библиотеки. Правда, не помню, платные они или нет. Исходников серверов и клиентов в сети много валяется. Просто по моему опыту написания систем, обращающихся с OPC-серверам, их удобнее всего делать на Эрланге. Вот мне и захотелось написать клиентскую библиотеку. Собственно, почти написал