Здравствуйте, WolfHound, Вы писали:
WH>Классы сами по себе ничего не тормозят.

Так "сами по себе" они ничего особенного и не дают.
Просто "плоские" классы с невиртуальными методами не так уж сильно ушли от C.
Иными словами "это собствено говоря не C++".

К тому же, если у того же борлонды включить поддержку rtti, то и на плоских классах
накладные расходы появляются...

WH>Еще ты забыл про шаблоны. Они позволяют писать на С++ код который легко уделывает С как по читабельности так и по скорости.

В смысле скорости, они просто позволяют избежать накладных расходов "виртуализации".
Не более того. С на одинаковых алгоримах они не уделают (я надеюсь, ты сам понимаешь, что ерунду сказал.)

WH> Сравни хотябы qsort и std::sort на массиве int'ов.

некорректное сравнение.
из-за того, что шаблон делает частный случай алгоритма: qsort_int
если его написать именно так на С, то будет всяко не медленнее, чем шаблон
Другое дело, что это часный случай высокоуровневости и писать отдельные
qsort_int, qsort_double, ... — изврат, хотя и возможно.

WH>А полиморфизм с виртуальными функциями используется там где без него никак,

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

WH>Короче не надо расказывать байки про то что С++ тормозит. Это не правда.

Правда. В сравнении с плоским C — тормозит.
Либо это не С++, а тот же самый С (пусть и с С++ синтаксисом).

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

EXO>Так "сами по себе" они ничего особенного и не дают.
EXO>Просто "плоские" классы с невиртуальными методами не так уж сильно ушли от C.
EXO>Иными словами "это собствено говоря не C++".
Ты забыл про деструкторы.

EXO>К тому же, если у того же борлонды включить поддержку rtti, то и на плоских классах
EXO>накладные расходы появляются...
Багланд это вобще отдельная история и говорить о кривости их компиляторов я могу очень долго...

WH>>Еще ты забыл про шаблоны. Они позволяют писать на С++ код который легко уделывает С как по читабельности так и по скорости.
EXO>В смысле скорости, они просто позволяют избежать накладных расходов "виртуализации".
EXO>Не более того. С на одинаковых алгоримах они не уделают (я надеюсь, ты сам понимаешь, что ерунду сказал.)
Мне надобыло сделать оговорку: При сравнимом колличестве кода ибо всем известно что существуют трансляторы С++ -> С.

EXO>некорректное сравнение.
Очень даже корректное. Мы же языки сравниваем Вот и давай сравнивать языки и те возможности что они нам дают для минимизации наших усилий.
EXO>из-за того, что шаблон делает частный случай алгоритма: qsort_int
EXO>если его написать именно так на С, то будет всяко не медленнее, чем шаблон
EXO>Другое дело, что это часный случай высокоуровневости и писать отдельные
EXO>qsort_int, qsort_double, ... — изврат, хотя и возможно.
И я о томже. При сравнимом колличестве кода во многих случаях С проигрывает.

EXO>если бы...
EXO>в библиотеках они используются куда чаще "необходимого", просто из соображений архитектуры.
EXO>Но за это приходится платить.
Ну библиотеки разные бывают. Например найди хоть один лишний virtual в http://antigrain.com

EXO>Правда. В сравнении с плоским C — тормозит.
EXO>Либо это не С++, а тот же самый С (пусть и с С++ синтаксисом).
Попробуй переписать http://antigrain.com на чистом С посмотрим что у тебя получится...

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

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

G>Понятно, что для такого простого кода с элементарной логикой выигрыш будет НЕ на стороне Ерланга. А вот если что-то намного более сложное, то результат тебя удивит

Не удивит, не удивит. Не может никакая машина создать код более умный чем специалист на более низкоуровневом языке. В принципе не может.

Приемущество Эрленга не в том, что он код более крутой генерирует, а в том, что он более выскоуровневый и позволяет проще описать задачу. Но вот в области быстродействия Эрлэнг полная задца, так как рассчитан на отсуствие типизации.

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

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

Нехочу спорить с тем кто ничего не читал по обсуждаемому вопросу. Или просто поверь, что это приципиальное решение, или прочти описание доступное по приведенной мной ссылке.

VD>> И возможно ОС станет доступна открыто.
A>Это, типа, евангелизм? Зачем?

Это типа информация к сведению.

A>Ну хорошо, станет доступна открыто — будет еще больше похожа на уже открытый Erlang :D

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

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

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

С точки зрения возможности реализации алгоритмов любой ЯП общего назначения функционально идентичен любому другому. Разница только в том заточен ли язык под компиляцию или нет. А от этого уже завист скорость конечного кода и применимость.

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

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

Вопрос был почему рантайм Эрлэн нельзя написать на нем самом же.

A>Что до рантайма — не знаю, на Яве вроде писали soft-realtime мини-OS.

Чисто Ява ОС есть вроде только одна. Ну, да то все же Ява.

A>Вдруг что интересное пропустишь? Так нет у Эрлангеров ресурсов Microsoft Research.

Эриксон контора тоже не маленькая.

Мне кажется тупиковым в Эрланге является именно его "не типизированность". И это не даст стать этому языку языком общего назначения в полном смысле этого слова.

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

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

Скорее треп в форумах.

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

Еще одна сказка.

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

EXO>Но вот только я уже давно не встречал в прикладных алгоритмах этого самого "идеального кода". Это нонче совершенно реликтовый зверь.

Возьми любой SQL-сервер, Офис, движек игры и т.п. — это все примеры кода который не просто пишется в рассчете на максимальную производительность, а долго и тщательно вылизывается и даже проектируется в рассчете на производительность. Люди проводят месяцы сидя в профайлере и делая всяческие тестя.

Мне вот интересно, для Эрлэнга есть профайлер? И кто-нибудь из исползовавших этот язык хоть раз пробовал профайлить свои приложения?

EXO> Реально же тот же C++ это часто например STL (а реализация map-ов в нем "мама не горюй...").

И? Хорошая реализация STL в хороших руках дает возможность писать код близкий к оптимальному. Эрланг даже с компилятором рядом за версту не подползет.

EXO> Или офигеннейшее "дерево классов" или еще что в том же духе. Тот же dynamic cast например (порой зарытый в библиотеки).

Это все пести в пользу бедных. Такие проблемы выявляются в лет. Запускаешь программу под профайлером и смотришь где узкие места. После чего переписываешь их более оптимально. Слава болгу императивные языки вроде плюсов дают немало возможностей по оптимизации.

EXO>Или посмотри асемблерник дельфийского приложения, там местами вообще шитый код с динамической типизацией вылазит.

Ну, ну. Только Дельфи порвет любой Эрланг как Тузик грелку.

EXO>Народ и на статически типизированных, компилируемых языках пишет так, как "удобнее" и "сопровождаемее", а вовсе не под "идеальное быстодействие".

Бывает. Кто же спорит. Но на С++ можно писать медленный и быстрый код. Если бы разница между Эрлагом и лучшими С++-компиляторами измерялось бы хотя бы в процентах, то конечно сэкономленное время (за счет более высокого уровня языка) можно было бы пустить на оптимизацию тонких мест. Более того когда пишутся задачи для которых железо превышает потребности в производительности в 10 и более раз, то вообще по фигу. Но бывают задачи которые и так на грани. И Эрлэнг для них попросту окажется не применим.

Между тем высокоуровневость Эрлэнга смотрится столь внушительной тольк на фоне убогости и низкоуровневости С++. Сравни его хотя бы с Шарпом и окажется, что приемущества уже очень туманны. А если вспомнить, что для Эрлэнга нет ни полноценной среды, ни другой инфраструктуры, то получится, что кодировать на Шарпе куда продуктивнее. Ну, а если начать сравнивать Эрлэнг с какими ниубдь Нэмерал или Скалой, то и вовсе неизвесно что удобнее и лучше.

EXO> И правильно делает — time-критичные куски надо выносить в библиотеки на плоском C. И если таких кусков много — то это косяк постановки.

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

EXO>Так что ты просто "не туда копаешь".

Нет, я просто реально смотрю на жизнь. Я фанат удобства и простоты, а не выпендрежа и наворотов.

EXO>Erlang — не самый быстый из декларативных языков (OCaml его уделает на раз), но он есть часть полноценной промышленной платформы. И сравнивать его надо с такими же языками платформ.

Не. Эрланг — это язык общего назначения. И сравнивать его нужно с такими же языками. Возможно в контексте некоторых задач.

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

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

EXO>Бенчмарков с C# .Net я не нашел, но нашлись сравнения с C# Mono.

Моно откровенный тормоз. На втором фрэймворке Шарп дает производительность в пределах от 0% до 20% от компилятора MS VC. Это конечно при условии, что код написан грамотно и со знанием дела.

EXO>Тесты правда "фрагментарные" — на отдельные элементы алгоритмов, что "не выгодно" Erlang-у, в котором оптимизиуется именно сложные алгоритмы в целом.

Ыгым. "котором ... алгоритмы" чушь да и только. Для оптимизации на уровне алгоритмов нужно или иметь "закладки" махающие один извесный алгоритм на другой, или искуственный интелект. Первое мошейничество работающее только в тестах, второе на сегодня не достижимо для человечества.

EXO> Ну да пусть.
EXO>Итак:
EXO>1. Аккерман (вычисления): C#, Erlang
EXO>Здесь Erlang серьезно проигрывает по быстродействию — 2,85 раза (хотя выигрывает по памяти в 1,4 раза).

Забудь ссылки на этот бред. "Серьезно проигрывает... в тир раза" ты вряд ли найщешь чесный тест, чтобы Эрлэнг был всего в 3 раза медленее. Эти тесты как ибольшинство подобных просто шарлатанство. Начать с того, что как и во всех пдобных шарлотанствах замеры времени видустя "из командной строки". Любому ребенку извесно, что измеряя время запуска управляемого кода, ты в основном измеряшь время потраченное на иницилизацию VM и на джит-компляцию. Замеры нужно провдить внутри тестов. Причем делать это полсе привентивных прогонов позволяющих скомпилироваться коду.

Далее берем код и смотрим:

public static int Ack(int m, int n) 
{
    if (m == 0) return n + 1;
    if (n == 0) return Ack(m-1, 1);
    else return Ack(m-1, Ack(m, n-1));
}

Что же мы видим? Ух ты! Концевая рекурсия на императивном языке! Зашибись. Чтобы разоблочить этих подтасовшиков достаточно объяснить, что современные компиляторы C# просто не делают оптимизации устранения концевой рекурсии. Ну, и любому школьнику извесно, что для ФЯ это жизненно важна оптимизация, так что если та таком тесте C# выиграл, то реализацее его кокурента можно только посочувствовать.

EXO>Иными словами чистые вычисления C# делает лучше.

Не то слово. А если еще использовать не Моно, а второй фрэймоврк...

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

А, ну, ну. Запустил это дело у себя и измерил по человечески:

stretch tree of depth 17         check: -1
131072   trees of depth 4        check: -131072
32768    trees of depth 6        check: -32768
8192     trees of depth 8        check: -8192
2048     trees of depth 10       check: -2048
512      trees of depth 12       check: -512
128      trees of depth 14       check: -128
32       trees of depth 16       check: -32
long lived tree of depth 16      check: -1
00:00:01.3681160

Уж не знаю что у них там был за компьютер, вряд ли он был в 8 раза медленнее моего.

Ну, и не нужно забывать, что такие примитивные тесты имеют мало отношения к рельной жизни. Выовд типов для нетипизированных языков замечательно работает, на тестах, и зачастую оказывается блефом в реальных условиях.

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

Этот тест вообще завязан на библиотечные реализации. Причем класса BigInteger просто нет в дотнете. В Моно используется реализация BigInteger из Моно, а в D из D. Дай мне исходники этого лкасса из D и я тебе продемонстрирую, что скорость этого теста будет приблизительно такой же как у D.

В общем, надоело смотреть на эти подтасовки. Загляни в Философию. Там разбирались эти тести и вроде как все сошлись во мнении, что это фуфло, а не тесты.

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

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

Кстати, очень показательно, что во многих тестах на этом сате просто нет результатов для Intel C++. Знаешь почему? Да потому, что подобные тесты он щелкает как семячки. Многие из функций он или векторизует, или так разворачивает и инлайнит, что "мама не горюй".

EXO>Лет 8 назад занимался я этим классом задачь. Так что знакомо.

Лет 8 назад о таких задачах на ПК и говорить не приходилось.

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

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

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


ЗЫ

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

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

LCR>Если в C# сложить два int, мы конечно же получим int, но необязательно сумму:
LCR>

LCR>int a = 2147483647;
LCR>int b = a + 1; // b стал отрицательным
LCR>

Для контроля переполнения в C# есть ключевое оператор checker() или ключи компилятора. Ну, и разрабатывая алгоритмы на C# надо учитывать что язык статически типизированный и заточенный на скорость рассчетов, а не на супер простоту. И если уж класс задачи подразумевает рабту с окромными числами, то стоит выбрать оптимальную стратегию. Как то: Выбрать более вемтительный тип данных (long, double). Воспользоваться классом эмулирующим безразмерные числа. Или еще что придумать.


LCR>Эрланговские целые на такое не способны:
LCR>

LCR>A = 2147483647,
LCR>B = A + 1,      %%% 2147483648, как это неудивительно
LCR>

LCR>В последнем случае требуется расширение внутреннего представления.

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

А ведь есть языки с выводом типов которые просто увидив потенциально большое число могут просто перейти на использование более вемтительного типа.

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

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

Ага. Золотые слова. И я бьюсь об заклад, что у каждого человека человекомесяц разный.

G>Мне есть с чем сравнивать — первая версия системы была на С++, и в нее вбито 20 чел. месяцев

А вторая была на C# или еще пуще на каком-нить Немерле?

G>на Ерланге, с ноля, я написал БОЛЕЕ устойчивую вещь менее чем за 3 месяца

Ой, с нуля ли? А может в виду, того что был прототип на С++ ты просто знал что писать и не тратил время на эксперементы?

К тому же опять таки не надо сравнивать с С++. С++ хорош там где унжно любой ценой вызать скорость. Ты сравни с тем же C#. Боюсь, что при этом все будет зависить не от языка, а от умений человека. И не удивлюсь, если я на туж е сисему убью 1 "человекомесяц". Просто потому, что пишу быстрее и пользуюсь человеческой IDE с рефакторингом.

Ну, а если мы потом попробуем сравнить быстродействие (после оптимизаций), то я даже не сомневаюсь, что я получу более быстрое решение. И это на отндь не идельно компиляторе. Через пару лет компиляторы Явы и C# сравняются по скорости с С++-ным, а уровень языков будет только рости. Дальше делай выводы сам.

G>А про биллинг на С++/Жабе лучше и не упоминать !

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

G> Я знаю положение дел в 4 более-менее крупных конторах, кои пишут биллинг для сотовых, и везде кучи глюков, падения и прочие радости. А сколько там народа на этом сидит !

Писали бы они код на Эрлинге была бы та же куча глюков что и на Яве. Главное что родинт Эрлинг и Яву — это типобезопасность. Большинство трудноуловимых глюков именно от ошибок связанных с типами. Не даром все ФЯ выпячивают этот аспект так сильно.

Логические же ошибки будут на любом языке.

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

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

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

Это откровенная неправад (мягко выражаясь). В разницу в 2-3 раза над C# я еще поверю. И то если на C# писать с упором на производительность. Ну, если писать в стиле "по короче", то получится вообще очень близко к тексту. Эрланг явно выигрывает только при описании иерархии типов. Но она далеко не основной объем кода занимает. А на алгоритмических задачах или на ОО-задачах выигрыш у Эрлинга будет разве что за счет отсуствия той самой аннотации типов.

В 50 раз — это голимый пиар.

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

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

Куча решений. От экзотических активных объектов в Обероне, до банальных библиотек легвовесных потоков и обмена сообщениями. Возмем хотя бы Сингулярит и его Sing#. Общение между процессами обеспечивает ОС, а язык делает его очень простым и понятным (декларотивное описание сообщений и их протоколов и конструкции упрощающие обработку сообщений).

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

На чем угодно, если конечно знашь что такое абстракция и как правильно ее понимать.

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

Знашь, все извесные мне торговые системы рабтают месяцев без перезапуска. Тут даже говорить не о чем.

G>И процессы в Ерланге — это именно процессы, ибо они полностью изолированы, и обмениваются лишь сообщениями.

В Яве любой набор объектов можно сделать полностью изолированным. Изоляция ведь основывается на базе типобезопасности. Вон в Сингулярити тоже полностью изолированные процессы и тоже общение между ними тольк через сообщения, но при этом еще есть потоки которые могут без проблем пересекать границы процессов. И в чем тут магия Эрлэнг?

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

Отлично! Пара тайпдэфов и вперед с песней. Лучше расскажи как Элринг может быть более портабельным чем С, если сам рантайм Эрленга написан на С?

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

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

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

Да, да.

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

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

A>Ну, ты совсем не веришь в E2K

А что мне в него врить? Бабаян давно пашет на Интел.

A>А если серьезно, вроде нативные Java-процессоры хоть и мало расрпостраненны — но кажется таки существуют.

Ага. И сильно поигрывают универсальным на кторых запущен Джит. А скоро Ява будет мало уступать по скорости С++-ному коду и тогда о таких процессорах вообще можно будет забыть.

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

Все процессоры Явы, реально просто эмулируют ее. Правда есть процессоры МСИЛ-а. Но и они мало чего достигли.

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

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

Цитирую тебя же:

Алгоритмически эквивалентны на столь разных языках ?

Далее могу только повторить свои слова.

Ладно, чтобы не быть голословным давай возмем простой пример. Вот есть алгоритм сортировки в памяти.

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

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

CP>В лиспе есть опциональная аннотация типов и она широко используеться в реализации ресурсоёмких алгоритмов.

В Лиспе нет никаких аннотаций. Они есть в расширениях. А то можно поговорить и о том, что в Лиспе есть императивные конструкции.

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

CP>По этому липс-программы работают быстрее и джавы и С#. что можно видеть из выше приведённых бенчмарков.

Верь в эту сказку дальше.

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

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

Я их не мешаю. Я сказал фразу, что если ты не слышишь за словом "байткод" слова "джит", то речь пойдет о степени тормознутости.

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

Хм. Тут восхваляют Эрлэнг как массу небесную. Судя по постам в этом форуме, Эрлэнг это такое чудо природы. Одни достоинства и никаких недостатков. А остальные слепые и тупые, не в состоянии понять где бозественный промысел, а где посредственность.

A>Говорят о том, что на Erlang'e привычно и удобно писать некотороые классы программ,

Ну, и где об этом хоть слово в памфлетах первой подветки этой темы?

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

А вот это уже не понял.

A>Мне этот спор напоминает ASM vs C.

А мне такие сравнения напоминают попытку подменить понятия.

A>Ясно, что если у меня нет ограничений по времени и мозги на месте, то я оттюнингую ассемблерный код лучше компиляторного.

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

Но тут вот в чем дело. Эрлинг конечно выше уровнем чем С++. Но не на столько чтобы уж порождать такую катастрофическую разницу как между асмом и С++. Ну, а если вспомнить, то есть языки сильно выше уровнем чем С++ и сравнивать Эрлен с ними, то окажется, что разница по сравнению с ними или минимальна, или вообще отрицательна. К примеру, у языка типа Явы может оказаться куда более обширная библиотека, что невилирует все приемущества Эрленга. Ну, а сравни с другим ФЯ? И где тут вообще разница? Чуть компактнее синтаксис? А хорошо ли это?

A> Также ясно, что случаи где эта оптимизация оправдает гигантское потраченное время сейчас исчезающе редки.

Об этом мы же говорили. Все зависит от задачи.

A> И аньше они были много чаще, но постепенно баланс стал смещаться. И тамкже Erlang vs С++, сегодня один баланс, завтра будет другой и т.д.

А давай Эрлэнг вс. Немерел. Или на худой конец Эрлеэн вс. C#?

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

Я не говорю что должен. Я говорю, что пока немного проигрывает. Ты не верно понял мои слова про джит. Повтояю последний раз. Если кто-то говорит о байткоде и не упоминает о джите, то он или верт или говорит о торозах.

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

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

Что мешает создать библиотеку/фрэймворк для других языков?

Особенно для тех что поддерживают метапрограммирование?

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

Ну, убью я день на создание фрэймворка или библиотеки, а потом все будет ОК. Зато когда в языке готового решения не будет, то придется сушуть весла или применять ту же тактику.

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

VD>Мне вот интересно, для Эрлэнга есть профайлер? И кто-нибудь из исползовавших этот язык хоть раз пробовал профайлить свои приложения?

Есть, а также есть серьёзное специальное руководство (http://www.erlang.se/doc/doc-5.4.12/doc/efficiency_guide/part.html) по созданию эффективных программ. Меня вообще очень радует дока по erlangу

VD>Между тем высокоуровневость Эрлэнга смотрится столь внушительной тольк на фоне убогости и низкоуровневости С++. Сравни его хотя бы с Шарпом и окажется, что приемущества уже очень туманны. А если вспомнить, что для Эрлэнга нет ни полноценной среды, ни другой инфраструктуры, то получится, что кодировать на Шарпе куда продуктивнее. Ну, а если начать сравнивать Эрлэнг с какими ниубдь Нэмерал или Скалой, то и вовсе неизвесно что удобнее и лучше.

Да ну нет. Есть куча тулзов и емакс с хорошей модой + esense. И вообще установите себе базовую систему эрланг и посмотрите сколько там всего есть.

EXO>> И правильно делает — time-критичные куски надо выносить в библиотеки на плоском C. И если таких кусков много — то это косяк постановки.

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

Потомучто для тех задач где его используют — он лучший:) А для других действительно нужно что-то другое использовать.


EXO>>Erlang — не самый быстый из декларативных языков (OCaml его уделает на раз), но он есть часть полноценной промышленной платформы. И сравнивать его надо с такими же языками платформ.

VD>Не. Эрланг — это язык общего назначения. И сравнивать его нужно с такими же языками. Возможно в контексте некоторых задач.

Де юре общего назначения. А де факто используют его для определённого круга задач.


VD>Далее берем код и смотрим:
VD>

VD>public static int Ack(int m, int n) 
VD>{
VD>    if (m == 0) return n + 1;
VD>    if (n == 0) return Ack(m-1, 1);
VD>    else return Ack(m-1, Ack(m, n-1));
VD>}
VD>

VD>Что же мы видим? Ух ты! Концевая рекурсия на императивном языке! Зашибись. Чтобы разоблочить этих подтасовшиков достаточно объяснить, что современные компиляторы C# просто не делают оптимизации устранения концевой рекурсии.

Я могу ошибаться, но помойму таки может оптимизировать.

ЗЫ: насчёт тестов. Эти тесты открыты. Вы можете запостить туда менее ресурсоёмкую версию на С#.

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

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

CP>>В лиспе есть опциональная аннотация типов и она широко используеться в реализации ресурсоёмких алгоритмов.

VD>В Лиспе нет никаких аннотаций. Они есть в расширениях. А то можно поговорить и о том, что в Лиспе есть императивные конструкции.

Да ну? В каких таких расширениях. Она есть в стандарте, которому около 20 лет. И которым пользуеться все реализации Common Lisp.

http://www.supelec.fr/docs/cltl/clm/node104.html (искать "(declare (type" ). Так что вы ошиблись. И императивные конструкции все в стандарте. И ООП тоже в стандарте. Это всё есть в Common Lisp. Вообще CL не функциональный язык. Или может быть вы имели ввиду что Common Lisp — это "расширение", относительно некого мифического — труъ функионального лиспа? ;)

VD>Лисп с выводм типов — это уже совсем не динамически типизированный язык. Это уже совсем другой язык, я бы сказал.

Вывода типов нет. А декларация есть. А вообще при желание можно добавить в лисп возможности любого языка с помощью макр.

CP>>По этому липс-программы работают быстрее и джавы и С#. что можно видеть из выше приведённых бенчмарков.

VD>Верь в эту сказку дальше.

Мне вот интерестно вы думаете что люди которые проводят те бэнчмарки (для почти всех языков) такие ярые фанаты лиспа, эрланга, etc. Что они намеренно подрстраивают так чтоб лисп, скажем, рулил а джава наоборот? Им это надо? Тем более лисп компилируеться в нативный код, а джава и C# нет. ТАк что он быстрее — ничего удивительного нет. И это заметим OpenSource реализации. Коммерческие генерят ещё более быстрый код. Другое дело что лисп прожорлив до памати, почти как джава.

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


VD>Мне вот очень понравилось решение Nemerle где просто можно реализовать такой синтаксис как тебе нужен, а потом еще и применить его банальным импоротом модуля.

Да, да — весьма новое, можно сказать революционное решение:))

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

VD>Что мешает создать библиотеку/фрэймворк для других языков?

Руки И объем работы, который обычно с этим связан. Люблю я, когда все до меня уже сделано и разжевано

VD>Особенно для тех что поддерживают метапрограммирование?

VD>Мне вот очень понравилось решение Nemerle где просто можно реализовать такой синтаксис как тебе нужен, а потом еще и применить его банальным импоротом модуля.

Хм. Лисп?

VD>Ну, убью я день на создание фрэймворка или библиотеки, а потом все будет ОК. Зато когда в языке готового решения не будет, то придется сушуть весла или применять ту же тактику.

Ну, этого никто на отменял. Например в Эрланге нет библиотеки SOAP (она, правда, никому пока особа и не нужна была — все же там уже есть CORBA, ASN.1, легкая работа с binary да и вообще — он же distributed по определению, так? ). Вот я сейчас тоже думаю — а оно мне надо? А хочется написать, да

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

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

Влад, язык, который ради удобства программиста приципиально не жертвует производительностью уже есть, называется он С и других нафиг не нужно. Хочется именно удобный язык.

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

M>Руки И объем работы, который обычно с этим связан. Люблю я, когда все до меня уже сделано и разжевано

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

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

Так что весма странно, что приемуществом языка является заточенность его под один довольно узкий круг задач.

Мне всегда казалось, что хороший язык тот который позволяет быстро и просто написать эффективное решение для большинства задач.

Если уж выбирать по библиотекам и закладкам, то кроме как на дотнет и на Яву вообще можно ни на что не смотреть. У них библиотеки самые обширные.

VD>>Мне вот очень понравилось решение Nemerle где просто можно реализовать такой синтаксис как тебе нужен, а потом еще и применить его банальным импоротом модуля.

M>Хм. Лисп?

Лисп отдыхает по полно. Нумерл позволяет получить поддержку семантического анализатора языка. И вообще Лисп сам по себе не сравннено сложнее в применении чем язык в котором присуствует что-то большее чем AST.

Все восхваления лиспа обычно разбиваются на две части:
1. Ах Лисп позволяет писать в функциональном стиле.
2. Ах какое в Лиспе метапрограммирвание/макросы.

Вот Нэмерл как раз и привосходит Лисп, или хотя бы не уступает Лиспу, в этих показателях, при этом являюсь куда более привычным и поддерживая (исходно, а не как расширение) статическую типизацию.

В итоге языки вроде Нэмерла и Скалы преращают фанатов Лиспа из борцов со штампами в их ярых защитников.

M>Ну, этого никто на отменял. Например в Эрланге нет библиотеки SOAP (она, правда, никому пока особа и не нужна была — все же там уже есть CORBA, ASN.1, легкая работа с binary да и вообще — он же distributed по определению, так? ). Вот я сейчас тоже думаю — а оно мне надо? А хочется написать, да

А написав ты поймешь, что она принципиально медленее того что можно было написать на статически типизированном языке. Причем, учитывая слова явно не предвзятого Гапертона, ты еще потрахашся со строками при этом. В итоге твоя реализация будет и хуже, и сложнее. Так стоит ли проливать столько соплей по поводу динамически типизированного языка развиваемого довольно мало значащей в индустрии конторой?