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

Ради любопытства провел следственный эксперемент. Декомпилировал код созданный компилятором C# в MSIL, добавил префикс tail. к концевым рекурсиям, перекомпилировал ехе-шник с IL-а и запустил. Результат получился такой:

C:\VS\Nemerle>Ackermann.exe
IL with tail. Ack(3,11): 16381   00:00:03.8472174

C:\VS\Nemerle>Ackermann-cs.exe
Ack(3,11): 16381   00:00:01.5490720

C:\VS\Nemerle>Ackermann-n.exe
Ack(3,11): 16381   00:00:00.9073141

То есть джит умудряется в два раза замедлить код если встречает хинт оптимизации.

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

Сдела еще один эксперемент. Скомпилировал код на VC 8.0:

#include "stdafx.h"
#include "TIME.H"

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));
}

int _tmain(int argc, _TCHAR* argv[])
{
  int n = 11;

  clock_t time1 = clock();

  int res = Ack(3, n);

  printf("Ack(3,%d): %d   %f\n", n, res, 
    (double(clock() - time1) / double(CLOCKS_PER_SEC)));

    return 0;
}

Резульата получился:

C:\VS\Nemerle>AckermannCpp.exe
Ack(3,11): 16381   0.871000

то есть очень близкий к Нэмерловскому.

Из чего можно сделать вывод, что VC похож тоже избавляется от концевой рекурсии. Ну, и что скорость дотнетного кода очень близка к скорость порождаемой C++-ными компиляторами.

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

Да, и еще одно замечаение. Судя по МСИЛ-у немерла он генерирует код с контрлем переполения. Так что не факт, что если сделать налогичный код на С++, то он не стаент проигрывать дотнетому.

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

VD>Думаю, что и большинству программистов нужен комплекс. Вопрос тольк в приоритетах.

Угу. Только у тебя в списке нет понятия "мощности языка" (в смысле определения Пола Грейхема):

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

PG> Все языки одинаково мощные, если рассматривать их с точки зрения эквивалентности машине Тьюринга, но это не та мощь, которая важна программисту. (Никто ведь не хотел бы программировать машину Тьюринга). Мощь языка, в которой заинтересован программист, возможно, трудно определить формальными методами, однако одно из объяснений этого понятия заключается в свойствах, которые в менее мощном языке можно получить, только написав на нем интерпретатор для более мощного языка. Если в языке A есть оператор для удаления пробелов из строк, а в языке B его нет, это не делает A более мощным, чем B, так как в B можно написать процедуру, которая делала бы это.

И вот "мощность языка" в этом смысле мне важна.
Год назад я основательно пробовал микрософтовский F#, в надежде, что ребята сделают реальные средства для "метопрограммиования" (напрмер, нормальные лямбды, с которыми удобно работать). И обломился
В этом плане F# оказался еще сильнее урезан, чем C#... (Механизм "анонимных классов" C# на мой взгляд достаточно заморочен и не тянет на полноценный механизм метапрограммирования. Это IMHO, разумеется...)

Здравствуйте, WolfHound, Вы писали:
WH>И я о томже. При сравнимом колличестве кода во многих случаях С проигрывает.

Вот с этим согласен.

( Кажется мы таки поймали за хвост кота Консенсуса... )

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

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

Флейм — пропускаю...

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

Ну и? Тебе кто-то предлагал писать движок игры на erlang-е?
Не передергивай — небыло таких предложений.
И писать SQL-сервер на erlang-е тоже никто не предлагал... Зато несколькими участниками обсуждения (например мной) подчекивалось, что речь идет о прикладном коде.
И SQL, и движок игры — это код системного уровня. К нему совершенно другие требования и другие критерии оптимизации...

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


VD>Мне вот интересно, для Эрлэнга есть профайлер?

Да. В составе дистрибутива.

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

Да.

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

Как раз сравнивал.

VD> А если вспомнить, что для Эрлэнга нет ни полноценной среды, ни другой инфраструктуры, то получится, что кодировать на Шарпе куда продуктивнее.

По этому поводу писал уже вот
здесь

Автор: EXO
Дата: 26.01.06

.


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

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

Нет. Поболе будет.
В состав дистрибутива входят:
— оптимизированный под работу с erlang-ом сервер БД (поддерживающий кластерную архитектуру, систему зеркалирования и механизмы распределенной работы на ненадежных каналах).
— средства для создания надежного многопоточного сервера приложений (или даже точнее "сети взаимосвязанных серверов", когда некоторые из них могут стоять "в цехах", а некоторые "в головном офисе", но выглядеть во вне как единое целое).
— хорошо интегрирующийся с сервером приложений мощный web-сервер. С поддержкой полного комплекта средств для создания web-сервисов.

До комплектации .Net он недотягивает по двум пунктам.
— Средства создания клиентского интерфейса. (Есть, но слабее, чем WinForms.)
— Интегрировання среда разработки. (О ней уже писал. И писал, что не считаю этот момент очень критичным.)

И кое в чем обходит...
— Например, в наличие средств создания компиляторов DSL-языков ("языков предметной области"). Что для современных систем на трехзвенной архитектуре, достаточно существенный момент.

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

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

Мне кажется "у страха глаза велики"
Загляни в околодотнетовские эхи, там тоже во многих сообщениях .Net "пиарится как просто каое-то волшебное средсво". Не буду утверждать, что специально... Будем считать, что пишущим так про .Net он просто нравится. Так вот и erlang пишущим про него просто нравится...


VD>Забудь ссылки на этот бред. "Серьезно проигрывает... в тир раза" ты вряд ли найщешь чесный тест, чтобы Эрлэнг был всего в 3 раза медленее. Эти тесты как ибольшинство подобных просто шарлатанство.

Предположим я здесь с тобой даже и согласился бы... ну и что?
Собственно а что остается, если мы не будем обращать внимания на тесты? Толко реальные продукты.
Так что тогда мы возвращаемся к сообщениям gandalfgrey о разработанной им системе, которая пришла на смену C++ версии. И заказчикам, которые (на сколько мне известно) успешно покупают обновления.

Не, ну можно еще громко кричать "Пиар!!!" "Не верю!!!"...
Тут уж как говорится "вольному — воля, блаженному — рай".


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# просто не делают оптимизации устранения концевой рекурсии.

Здесь расходящееся дерево. Оно и erlang-ом полностью не разверуто.
Что и видно из результатов теста. Для полноценной хвостовой рекурсии стоило бы написать алгоритм с парой "накопителей". Так что похоже erlang-овцы как раз старались "играть честно".

Ну а в остальном, я уже сказал.
Предположим, уберем тесты. Что останется?
— Рекламные заявления от того же MS? А почему я им должен верить больше?
— Реальные проекты? Ну дак они дают достаточно хорошую для erlang-а картину.
— Твои заявления о том, что "не может быть, потому, что не может быть никогда"? Для меня тоже звучат неубедительно, поскольку от "теретических умозаключений" до реальности "дистанция огромного размера".

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

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

Правильно. Для этого есть Fortran, С... Или например OCaml.
Прочитай квотинг. Я где-нибудь предлагал использовать erlang "для вычислительных задач"?

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

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

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

Пока не начался флейм, в половине сообщений назывались и недостатки.
Вот здесь

Автор: gandalfgrey
Дата: 25.01.06

, например.
Тебе показалось, что недостатков названо недостаточно? Ну дак "перца и соли — по вкусу..."

VD> а так же оратить внимание на то, что язык применим и эффективен в оределенном классе задачь.

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

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

VD>Не удивит, не удивит. Не может никакая машина создать код более умный чем специалист на более низкоуровневом языке. В принципе не может.
Это верно. Но есть одна проблема — время и усилия, потребные на написание шустрого кода на низкоуровневом языке. Вот уж на что я люблю ассемблер, но писать на нем ( что-то практическое ) за последние 8 лет довелось только один раз : функцию для чтения процессорного таймера через RDTSC

VD>Приемущество Эрленга не в том, что он код более крутой генерирует, а в том, что он более выскоуровневый и позволяет проще описать задачу. Но вот в области быстродействия Эрлэнг полная задца, так как рассчитан на отсуствие типизации.
а это как-то слабо влияет на РЕАЛЬНОЕ быстродействие. я его выбрал как основной инструмент еще и по причине предсказуемости быстродействия, в отличие от С++, где с этим проблемы при смене масштабов нагрузок/потоков/обьемов...

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

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

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

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

G>>А про биллинг на С++/Жабе лучше и не упоминать !
VD>Упоминай не упоминай, но в нашей стране он на них и как видишь миллионов 50 пользуются результатом и более чем довольны.
Вот только почему-то те из моих знакомых, кто занимаются эксплуатацией этих систем, матюкаются на них со страшной силой.

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

VladD2 wrote:
> Здравствуйте, CrazyPit, Вы писали:
> CP> А если нужно просто проверить на тип входной параметр то это легко.
>
> Интересно как? В конце концов параметр может быть функцией возвращающей
> булево значение при выполнении. К тому же большинство кода не
> типизированно так что с него вообще до выполнения ничего не получишь.
> Ну, и опять возвращаемся к вопросу что называть Лиспом. В Схеме макросы
> отличные, а средств работы с типами нема.
Новые средства синтаксиса, как здесь — это, вроде, дословно syntax-rules
Схемы (в простейших случаях, дальше, вероятно, небольшие отличия),
только на языке с нормальным синтаксисом. Я на своём препроцессоре
Паскаль такой функциональности добивался (правда, в узких случаях — но
мне они очень помогли). В Лиспе (вероятно, в любом, даже в Схеме
реализуются негигиеничные макросы) это что-то типа

    (defmacro if (c x y)
      `(cond
        (,c ,x)
        (t ,y)
        )
      )

— макрос просто представляет из себя не генератор кода, а сам код,
который получится (с некоторыми поправками).
> CP> А некоторые вещи вообще не возможны, типа анофорических макр.
>
> Что означает "анофорических"?
>
> CP>
>
> CP>(awhen (compr x y)
> CP> (blah it))
> CP>
>
>
>
> CP>раскрывается в
>
> CP>
>
> CP>(let (it (compr x y))
> CP> (when it
> CP> (blah it))
> CP>
>
>
>
> Не въехал, а что тут необычного?
В исходном вызове it не упоминается. Им становится первый параметр на
время вычисления второго. Некоторый способ сэкономить на печати let и —
самое главное — на их синхронной модификации. Ещё один шаг на пути к
исчезновению copy-paste в программировании.

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

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

VladD2 wrote:
>
> Все восхваления лиспа обычно разбиваются на две части:
> 1. Ах Лисп позволяет писать в функциональном стиле.
> 2. Ах какое в Лиспе метапрограммирвание/макросы.
>
Вопросы: Немерле отделим от дотнета? Имеет интерепретатор? Позволяет
использовать весь язык без ограничений в описаниях макросов?
Хотелось бы нет-да-да. И поставить на наладонник вместо схемы.. И
бросить писать свою обёртку над Си с целью иметь синтаксис Паскаль,
компилятор от Си и макросы от Лисп.

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

VD>Ну, извини, тут советуют Эрлэнг как некую манну небесну.



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

Что считать низкоуровневым?

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

+1

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

Весьма неплохой круг задач, однако — Making reliable distributed systems in the presence of hardware errors

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

"Нельзя объять необъятное" (с) Козьма Прутков

Если есть возможность эффективно решить отдельный класс задач специально заточенным для этого дела инструментом, то поему бы и нет?

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

Согласен, все это можно сделать и в C# и в Яве Но я не ищу легких путей (или все же ищу? )

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

Возможно. Но какая часть из этих библиотек используется? 10%? Еще меньше?
Все, что мне надо, пока есть А если понадобится что-нибудь "странно", то его и в .NET'e и Яве будет сложновато найти, ИМХО.

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

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

Надо будет пощупать за вымя

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

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

Ну, для SOAP'a это некритично

VD>Причем, учитывая слова явно не предвзятого Гапертона, ты еще потрахашся со строками при этом.

Увы

VD>В итоге твоя реализация будет и хуже, и сложнее.

Возможно

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

здесь

Telecom Trends International (TTI) has ranked Ericsson as the top supplier of next-generation mobile infrastructure in terms of revenue. In a 2003 report, “3G Mobile Networks: Vendor Positioning and Deployment Strategies,” the research firm estimates that Ericsson’s share of the 2.5/3G mobile infrastructure market to be 20.9 percent. The next vendor in terms of market position is Nortel Networks with a share of 19.0 percent. The other two companies with market shares in double digits are Nokia and Lucent Technologies. The Siemens/NEC alliance ranks the next followed by Motorola. The other significant players in the market are Samsung and Alcatel.

Nortel сейчас тоже использует Эрланг в своих системах...



Правда, если изменить фразу на "довольно мало значащей в IT индустрии конторой", то да — увы

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

Он незадокументирован, использует старую версию xmerl и не развивается

Я, правда, все еще не дотянулся пощупать его руками

Здравствуйте, Mamut, Вы писали:
M>Он незадокументирован, использует старую версию xmerl и не развивается

Это да. Правильно они сделали, что не стали включать его основной в дстрибутив.

Вообще говоря, если задумывать разаботку соответсвующей библиотеки, то прежде всего стоит разобраться, что делать с "зоопарком SOAP-ов". Коий только "выглядит как стандарт" (ну типа "совсем как живой"). А посмотреть реальную совместимость Java и .Net версии, и вылазит вагон подводных камней.
Я вот ушел на XML-RPC, просто потому, что надоело натыкаться на "непонимание" то одних, то других клинтских библиотек.
Так что может стоит дождаться, пока SOAP несколько устоится...

EXO>Вообще говоря, если задумывать разаботку соответсвующей библиотеки, то прежде всего стоит разобраться, что делать с "зоопарком SOAP-ов". Коий только "выглядит как стандарт" (ну типа "совсем как живой"). А посмотреть реальную совместимость Java и .Net версии, и вылазит вагон подводных камней.

Если честно, мне SOAP вообще не нужен Для внутренних нужд я планирую Erlang как на сервере, так и на клиенте. Мне просто хочется синхронизатор с РСДНом написать не Эрланге Но это — чур, только между нами

EXO>Я вот ушел на XML-RPC, просто потому, что надоело натыкаться на "непонимание" то одних, то других клинтских библиотек.
EXO>Так что может стоит дождаться, пока SOAP несколько устоится...

А он устоится? "Не верю" (с)

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

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


VD>А почему так сложилось исторически и не перекладывается сейчас?

CP>>также как например с виндой. Рынок никогда не завоёвывают самые лучшие решения

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

VD>Просто у рынка другие критерии нежели от отдельных личностей. То что ты считашь важным, не важно для большинтсва и надоборот.

[Небольшой офтоп, сорри]

Хорош, винду оставим в стороне, возьмём более радикальный пример: CISC vs. RISC процессоры. Причём возьмём явного лидера — интел, есть линейка X86 и выход из проблемности цискового направления развития процессоров — Itanium. Далеко не секрет, что последний даёт далеко не слабые преимущества по оптимизации кода, т.е. реальный выигрыш в скорости приложений, но вот рынок его не так просто "ест", потому Интел с ХулитПаккардом вот недавно приняли решение, кажись, 10 милиардов вложить в, по сути, пропагандирование итаниума. Т.е. ты считашеь что для большинства критерий скорости неважен? Хотя тут несколько сложнее, т.к. это далеко не единственный критерий (самый сильный противодействующий — преемственность решений)

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

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

EXO>Ну и? Тебе кто-то предлагал писать движок игры на erlang-е?
EXO>Не передергивай — небыло таких предложений.

Кстати, были такие проекты . Движок сервера RPG, и движок игровой трехмерной графики (через OpenGL). Можно поискать в гугле. Но эрланговское сообщество относится к подобным экспериментам (трехмерная графика) скорее как к экстравагантным трюкам.

EXO>И писать SQL-сервер на erlang-е тоже никто не предлагал... Зато несколькими участниками обсуждения (например мной) подчекивалось, что речь идет о прикладном коде.
EXO>И SQL, и движок игры — это код системного уровня. К нему совершенно другие требования и другие критерии оптимизации...

Кстати, были такие проекты . Mnesia, входящая стандартную поставку — вполне себе движок базы данных, и довольно неплохой. Особенно, если к нему BerkleyDB backend подключить. Это, кстати, вполне нормально — все равно в диск затыкается...

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

К>[Небольшой офтоп, сорри]

Если тема разовьется, снесу ее в Философию.

К>Хорош, винду оставим в стороне, возьмём более радикальный пример: CISC vs. RISC процессоры. Причём возьмём явного лидера — интел, есть линейка X86 и выход из проблемности цискового направления развития процессоров — Itanium. Далеко не секрет, что последний даёт далеко не слабые преимущества по оптимизации кода, т.е. реальный выигрыш в скорости приложений, но вот рынок его не так просто "ест", потому Интел с ХулитПаккардом вот недавно приняли решение, кажись, 10 милиардов вложить в, по сути, пропагандирование итаниума. Т.е. ты считашеь что для большинства критерий скорости неважен? Хотя тут несколько сложнее, т.к. это далеко не единственный критерий (самый сильный противодействующий — преемственность решений)

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

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

А что до РИСК... На сегодня почти все процессоры РИСК. Только внутри. Фанаты РИСК-архитектуры не учли того, что внешний интерфейс важен для пользователя и не важен для реализации.

Здравствуйте, Gaperton, Вы писали:
G>Кстати, были такие проекты . Движок сервера RPG, и движок игровой трехмерной графики (через OpenGL). Можно поискать в гугле. Но эрланговское сообщество относится к подобным экспериментам (трехмерная графика) скорее как к экстравагантным трюкам.

Можно разделить логику движка, вычленив оттуда поведеньческий элемент (и может быть анализ стокновений).
И это сделать на эрланге. Но основное ядро скорее всего придется оставить С-шным.
Да и вообще для игр с серьезной динамикой я бы такой вариант использовать не стал.
Так что это скорее эксперименты и попытки нащупать "границы применимости"...

G>Кстати, были такие проекты . Mnesia, входящая стандартную поставку — вполне себе движок базы данных, и довольно неплохой. Особенно, если к нему BerkleyDB backend подключить. Это, кстати, вполне нормально — все равно в диск затыкается...

Здесь два возражения:
1. Мнезия все-таки не SQL, и не ставит своей задачей всенеприменно шустро выполнять даже кривые запросы. И соответсвенно "тупое быстродействие" у хороших SQL все-таки повыше будет. (Мнезия сорее может существенно выиграть по пыстродействию, за счет использования других алгоримов и структур данных.)
2. BerkleyDB — таки C-шная тулзовина. Так что это как раз получается правильное "разделение обязанностей".

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

Если я все правильно понял, то на Нэмерле можно все тоже самое и намного болше. А главное роще, предсказуемее и удобнее.