Здравствуйте, faulx, Вы писали:
F>Теоретически есть возможность писать OPC-сервера и клиенты под Unix, видел библиотеки. Правда, не помню, платные они или нет. Исходников серверов и клиентов в сети много валяется. Просто по моему опыту написания систем, обращающихся с OPC-серверам, их удобнее всего делать на Эрланге. Вот мне и захотелось написать клиентскую библиотеку. Собственно, почти написал
Тут есть проблема. А именно, стабильность работы ДКОМа под Юниксами.
А ты через COMET лазишь к OPC серверам ?
EXO,
EXO>Итак: EXO>1. Аккерман (вычисления): C#, Erlang EXO>Здесь Erlang серьезно проигрывает по быстродействию — 2,85 раза (хотя выигрывает по памяти в 1,4 раза). EXO>Иными словами чистые вычисления C# делает лучше.
Здесь конечно (в данном случае очень весомый) оверхед возникает из-за неявных дополнительных проверок аргументов при выполнении арифметических операций. Казалось бы, если ввести аннотацию типов, то это позволит компилятору обойтись без проверок типов, но это ещё не всё. Требуются рантайм проверки следующего плана.
Если в C# сложить два int, мы конечно же получим int, но необязательно сумму:
int a = 2147483647;
int b = a + 1; // b стал отрицательным
Эрланговские целые на такое не способны:
A = 2147483647,
B = A + 1, %%% 2147483648, как это неудивительно
В последнем случае требуется расширение внутреннего представления. Тов. Bjorn Gustavsson пишет
The "i_plus_jd" instruction handles additions of small
integers directly. Only if one or both of the operands
are not small, or if the sum is not small, will the
erts_mixed_plus() function be called.
Knowing beforehand that both operands are integers would
not help because they may be bignums, so the type tests
would still be needed.
Это было где-то в мэйл-листе за декабрь прошлого года. Там как-раз обсуждалась эта несчастная функция Аккермана.
Здравствуйте, gandalfgrey, Вы писали:
G>Здравствуйте, faulx, Вы писали:
F>>Теоретически есть возможность писать OPC-сервера и клиенты под Unix, видел библиотеки. Правда, не помню, платные они или нет. Исходников серверов и клиентов в сети много валяется. Просто по моему опыту написания систем, обращающихся с OPC-серверам, их удобнее всего делать на Эрланге. Вот мне и захотелось написать клиентскую библиотеку. Собственно, почти написал G>Тут есть проблема. А именно, стабильность работы ДКОМа под Юниксами.
Да он и под винду стабильностью не радует, особенное если сеть падает. Но тут у Эрланга преимущество — весь КОМ в отдельном экзешнике, который при падении будет передернут супервизором, так что клиент ничего не заметит.
G>А ты через COMET лазишь к OPC серверам ?
Здравствуйте, faulx, Вы писали:
F>Да он и под винду стабильностью не радует, особенное если сеть падает. Но тут у Эрланга преимущество — весь КОМ в отдельном экзешнике, который при падении будет передернут супервизором, так что клиент ничего не заметит.
В смысле — весь КОМ ? со всеми потрохами ? а это не слишком жЫрно будет ?
G>>А ты через COMET лазишь к OPC серверам ? F>Нет, штатными средствами.
До R8 COMET был в составе дистрибутива. А потом они его оттуда удалили, мотивируя слабой надобностью сего и нехваткой времени для поддержки и развития
Здравствуйте, faulx, Вы писали:
F>Теоретически есть возможность писать OPC-сервера и клиенты под Unix, видел библиотеки.
Есть OPC XMLDA — SOAP-based протокол, недавно участвовал в разработке на C++, никаких DCOM. Но, ИМХО, на роль действительно кросс-платформенного протокола он не тянет — спецификация постоянно за деталями отсылает к более проработаноой спецфикации COM-based OPC DA 3.0. Если почитать про допустимые преобразования типов, становится ясно, что они подогнаны под функцию VariantChangeType. А в спецификации запроса Browse прямым текстом сказано, что поиск элементов по маске работает, как оператор Like из VB .
Здравствуйте, gandalfgrey, Вы писали:
G>Здравствуйте, faulx, Вы писали:
F>>Да он и под винду стабильностью не радует, особенное если сеть падает. Но тут у Эрланга преимущество — весь КОМ в отдельном экзешнике, который при падении будет передернут супервизором, так что клиент ничего не заметит. G>В смысле — весь КОМ ? со всеми потрохами ? а это не слишком жЫрно будет ?
Кажется, мы друг друга не понимаем. Я пишу под винду, по принципу наименьшего сопротивления. (Про то, что можно писать по Юникс, я только знаю, сам не пробовал). В порт (отдельный экзешник) вынесена вся низкоуровневая работа с OPC (и, следовательно, с КОМ-ом). Эрланговская программа общается уже с этим портом (по пайпу, вестимо). В общем, стандартный способ расширения Эрланга. Делать port driver с КОМ-ом внутри — спасибо, не хочется. В итоге, если что-то в КОМе пойдет не так (а он, например, очень не любит сетевых неполадок), есть возможность передернуть весь этот экзешник и заново подключиться к серверу. В контексте OPC (по крайней мере, для простых задач, вроде "считать данные с контроллера") это, по-моему, вполне допустимо.
G>>>А ты через COMET лазишь к OPC серверам ? F>>Нет, штатными средствами. G>До R8 COMET был в составе дистрибутива. А потом они его оттуда удалили, мотивируя слабой надобностью сего и нехваткой времени для поддержки и развития
Здравствуйте, faulx, Вы писали:
F>Кажется, мы друг друга не понимаем. Я пишу под винду, по принципу наименьшего сопротивления. (Про то, что можно писать по Юникс, я только знаю, сам не пробовал). В порт (отдельный экзешник) вынесена вся низкоуровневая работа с OPC (и, следовательно, с КОМ-ом). Эрланговская программа общается уже с этим портом (по пайпу, вестимо). В общем, стандартный способ расширения Эрланга. Делать port driver с КОМ-ом внутри — спасибо, не хочется. В итоге, если что-то в КОМе пойдет не так (а он, например, очень не любит сетевых неполадок), есть возможность передернуть весь этот экзешник и заново подключиться к серверу. В контексте OPC (по крайней мере, для простых задач, вроде "считать данные с контроллера") это, по-моему, вполне допустимо.
А ! Я отчего-то решил, что все это добро крутится под юниксами, а в отдельном бинарнике собран КОМ из сырцов. Оттого и ужаснулся
КОМ вообще не подходит для задач промышленной телеметрии в наших условиях. Конечно, ежели поставить ПРОФИБАС, то оно будет работать, но затраты...
F>R8 я не застал.
можно скачать сорцы. сначала посмотри change-log, когда удалили КОМ-сервер из дистрибутива. Насколько я помню, на чистом Ерланге написано
VD>Сейчас исследователи капают в сторону совмещения аннотации типов с выводом типов. Хороший прпимер такого подхода — это Немерл. Но для этого язык должен поддерживать аннотакцю типов! А Эрлэнг или Лисп с аннотацией типов (да и вообще Лисп с типами) — это уже другой язык!
В лиспе есть опциональная аннотация типов и она широко используеться в реализации ресурсоёмких алгоритмов.
По этому липс-программы работают быстрее и джавы и С#. что можно видеть из выше приведённых бенчмарков.
Здравствуйте, gandalfgrey, Вы писали:
G>Здравствуйте, VladD2, Вы писали:
G>>>1. Сложная логика обработки. Вместо 1000 строк с if/switch получится 50 строк case VD>>Верится с трудом.
G>Тем не менее — это так. Паттерн матчинг рулит !
G>>>2. параллельность. Тут конкурентов вообще нет
Я так понял "Паттерн матчинг", одна из базовых возможностей Erlang-а как языка, но что-то мне кажется (с точки зрения реализации этого в виртуальной машине) скорость "матчинга" будет существенно проигрывать вызову статического метода класса (а наверняка и виртуальному ). Наскоко я понял для "матчинга" виртульная машина при выполнении байт-кода должна:
— разобрать с какими параметрами вызывается функция
— подобрать подходящую по сигнатуре функцию
— вызвать ее.
Ну не вериться что при тотальном использовании такой механики скросторельность сможет хотя бы близко тягяться с компиляторами . Что-то тут не так...
Здравствуйте, gandalfgrey, Вы писали:
G>Здравствуйте, faulx, Вы писали:
G>КОМ вообще не подходит для задач промышленной телеметрии в наших условиях.
Золотые слова! Промышленная телеметрия на ДКОМ — это звучит как анекдот. Поэтому факт существования OPC меня ставит в тупик. Посмотреть бы в глаза тому человеку, который принял решение заложиться на КОМ для таких задач.
F>>R8 я не застал. G>можно скачать сорцы. сначала посмотри change-log, когда удалили КОМ-сервер из дистрибутива. Насколько я помню, на чистом Ерланге написано
Здравствуйте, pavel74, Вы писали:
P>Я так понял "Паттерн матчинг", одна из базовых возможностей Erlang-а как языка, но что-то мне кажется (с точки зрения реализации этого в виртуальной машине) скорость "матчинга" будет существенно проигрывать вызову статического метода класса (а наверняка и виртуальному ). Наскоко я понял для "матчинга" виртульная машина при выполнении байт-кода должна: P>- разобрать с какими параметрами вызывается функция P>- подобрать подходящую по сигнатуре функцию P>- вызвать ее.
P>Ну не вериться что при тотальном использовании такой механики скросторельность сможет хотя бы близко тягяться с компиляторами . Что-то тут не так
Наоборот, еще и выигрыш большой. Например :
case{func1(),func2(),X,Y}of
{nil,0,_,_}->...
{1,_,undefined,timeout}->...
{0,_,_,_}->......%и так далееend.
уже при десятке альтернатив код на С/С++ будет велик и нечитаем. Бинарный код — тоже
Здравствуйте, faulx, Вы писали:
F>Золотые слова! Промышленная телеметрия на ДКОМ — это звучит как анекдот. Поэтому факт существования OPC меня ставит в тупик. Посмотреть бы в глаза тому человеку, который принял решение заложиться на КОМ для таких задач.
Как обычно, политическое решение. И лобби производителей кой-какого железа ( Сименсы, Шнайдеры... )
Здравствуйте, pavel74, Вы писали:
P>Ну не вериться что при тотальном использовании такой механики скросторельность сможет хотя бы близко тягяться с компиляторами . Что-то тут не так...
а ведь можно еще guard добавить :
case {func1(),func2(),X,Y} of
{nil,Z,_,_} when Z <5 ->...
{Z,_,undefined,timeout} when is_integer(Z) ->...
{0,_,_,_}->......
%и так далее
end.
Здравствуйте, Lazy Cjow Rhrr, Вы писали:
LCR>Маленький оффтоп: постарайся использовать форматирование кода (напр. с помощью code) хорошо? Читать и тебе самому и нам будет чуть удобнее.
Попробую, может и получится чего...
Здравствуйте, EXO, Вы писали:
EXO>Ты похоже допускаешь одну и ту же ошибку (в разных темах на разных форумах): EXO>например сравниваешь с "идеальным" кодом на C/С++... И скорее даже надо говорить "на С", поскольку как только в куске кода вылазят классы/полиморфизм/виртуальные функции, так производительность сразу плывет сам знаешь куда.
Классы сами по себе ничего не тормозят. Еще ты забыл про шаблоны. Они позволяют писать на С++ код который легко уделывает С как по читабельности так и по скорости. Сравни хотябы qsort и std::sort на массиве int'ов.
А полиморфизм с виртуальными функциями используется там где без него никак, а на С в этих случаях придется руками эмулировать виртуальные функции со всеми вытикающими.
Короче не надо расказывать байки про то что С++ тормозит. Это не правда.
... << RSDN@Home 1.1.4 beta 6a rev. 436>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, gandalfgrey, Вы писали:
G>Здравствуйте, pavel74, Вы писали:
P>>... Наскоко я понял для "матчинга" виртульная машина при выполнении байт-кода должна: P>>- разобрать с какими параметрами вызывается функция P>>- подобрать подходящую по сигнатуре функцию P>>- вызвать ее. G>Совершенно не так. Код строится компилятором
G>%%%%%%%%%%% исходник %%%%%%%%%%%%%%% G>func({atom1,X})->X;
G>func({atom2,X})->X+5;
G>func(X)->{fail,X}.
G>%%%%%%%%%% полученный код %%%%%%%%%%%%%%%%%%%%% G>{function, func, 1, 2}. G> {label,1}. G> {func_info,{atom,b4},{atom,func},1}. G> {label,2}. G> {test,is_tuple,{f,5},[{x,0}]}. G> {test,test_arity,{f,5},[{x,0},2]}. G> {get_tuple_element,{x,0},0,{x,1}}. G> {get_tuple_element,{x,0},1,{x,2}}. G> {test,is_atom,{f,5},[{x,1}]}. G> {select_val,{x,1},{f,5},{list,[{atom,atom2},{f,3},{atom,atom1},{f,4}]}}. G> {label,3}. G> {bif,'+',{f,0},[{x,2},{integer,5}],{x,0}}. G> {'%live',1}. G> return. G> {label,4}. G> {move,{x,2},{x,0}}. G> return. G> {label,5}. G> {test_heap,3,1}. G> {put_tuple,2,{x,1}}. G> {put,{atom,fail}}. G> {put,{x,0}}. G> {move,{x,1},{x,0}}. G> return.
"полученный код" не осилил , можно пример как-нить более ИЯ-подобно
Другой пример:
fac(1)->1;
fac(N)->N*fac(N-1).
когда fac откудо-то вызовут то VM при проходе внутри fac(N) ,
работать должна примерно так (как я понимаю на данный момент):
fac_n(x){
//бла бла бла
//добрались до места " fac(N-1) "
//теперь надо вызвать одну из функций fac , но какую?
//это зависит от результата вычисления N-1, т.е.
if (x-1)=1 //в общем случае эта проверка может быть достаточно сложной а значит времязатратной
{ ... fac_1(1)... }
else
{ ...fac_n(x)... }
//бла бла бла
}
fac_1(x) { retrun 1 }
Т.е. еще раз поясню свою мысль, т.к. при выполнении кода виртуальной машиной (VM) "паттерн матчинг" выполняется динамически, т.к. зависит от результата вычисления предыдущего выражения ( в моем примере: N-1 ), в общем случае задача нетривиальная, что не может быть быстрее обычного виртуального вызова (фактически одна ассемблерная инструкция с выборкой адреса метода по ссылке из VMT), а уж тем более статического .
Соответственно если "паттерн матчинг" является одним из базовых механизмов ран-тайма, который как мы видим "медленнее" традиционного вызова метода , то соответственно это должно заметно сказываться и на общей скорострельности программ (в сравнении с компилируемыми).
Все верно? где здесь собака зарыта ? (если она есть)
Доводы за алгоритмы и библиотеки приводить не надо, это отдельная тема, здесь вопрос именно о "паттерн матчинге" vs "обычный вызов метода".
Здравствуйте, faulx, Вы писали:
F>Золотые слова! Промышленная телеметрия на ДКОМ — это звучит как анекдот. Поэтому факт существования OPC меня ставит в тупик. Посмотреть бы в глаза тому человеку, который принял решение заложиться на КОМ для таких задач.
Я бы тоже хотел посмотреть в глаза этому человеку. Ведь OPC это не просто COM это кривой COM. Один IOPCServer::RemoveGroup чего стоит.
... << RSDN@Home 1.1.4 beta 6a rev. 436>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, pavel74, Вы писали:
P>"полученный код" не осилил , можно пример как-нить более ИЯ-подобно
это и так ассемблер для виртуальной машины
P>Другой пример: P>fac(1)->1; P>fac(N)->N*fac(N-1).
а здесь у тебя будет истинная рекурсия, что нехорошо
P>Т.е. еще раз поясню свою мысль, т.к. при выполнении кода виртуальной машиной (VM) "паттерн матчинг" выполняется динамически, т.к. зависит от результата вычисления предыдущего выражения ( в моем примере: N-1 ), в общем случае задача нетривиальная, что не может быть быстрее обычного виртуального вызова (фактически одна ассемблерная инструкция с выборкой адреса метода по ссылке из VMT), а уж тем более статического . P>Соответственно если "паттерн матчинг" является одним из базовых механизмов ран-тайма, который как мы видим "медленнее" традиционного вызова метода , то соответственно это должно заметно сказываться и на общей скорострельности программ (в сравнении с компилируемыми).
Он не медленнее ! Вызов виртуального метода не позволяет какой-либо логической обработки, в этом-то все и дело
P>Все верно? где здесь собака зарыта ? (если она есть)
Собака зарыта не более чем по пояс и очень хорошо видна ! Паттерн матчинг — это механизм обработки логики
вот более простой пример :
исходный текст ( обрати внимание, что здесь будет хвостовая рекурсия, то-есть просто цикл )
fact(1,N)->N;
fact(X,N)->fact(X-1,N*X).
ассемблерный текст ( ассемблер виртуальной машины ерланга )
{function, fact, 2, 4}.
{label,3}.
{func_info,{atom,b6},{atom,fact},2}.
{label,4}.
{test,is_eq_exact,{f,5},[{x,0},{integer,1}]}. проверка Х на 1
{move,{x,1},{x,0}}. если да, то в результат
return. и вернуть
{label,5}. иначе
{bif,'-',{f,0},[{x,0},{integer,1}],{x,2}}. уменьшить Х
{bif,'*',{f,0},[{x,1},{x,0}],{x,1}}. умножить N на предыдущее значение Х
{move,{x,2},{x,0}}. в список аргументов
{call_only,2,{f,4}}. новый оборот цикла
Понятно, что для такого простого кода с элементарной логикой выигрыш будет НЕ на стороне Ерланга. А вот если что-то намного более сложное, то результат тебя удивит
quicksort =: (($:@(<#[),(=#[),$:@(>#[)) ({~ ?@#)) ^: (1<#)
.
. Что-то тут не так...
, можно пример как-нить более ИЯ-подобно
