Чем им всем неугодила ада?

Тут кажется сравнивали Аду с Паскалем. Риалтайм это достаточно узкое применение, а в общем случае, производительность очень важный параметр.

Да и в риалтайме это далеко не последний фактор ИМХО.

$ gnatmake -gnatp -O3 -f -fomit-frame-pointer -Wall threadring.adb
gcc -c -gnatp -O3 -fomit-frame-pointer -Wall threadring.adb
gnatbind -x threadring.ali
gnatlink threadring.ali -fomit-frame-pointer

$ /usr/bin/gcc -pipe -Wall -O3 -fomit-frame-pointer -lpthread ./threadring.c -o threadring.gcc
./threadring.c: In function 'main':
./threadring.c:66: warning: control reaches end of non-void function

2.6.22, core 2 duo, 2Gb

gcc (GCC) 4.1.3 20071019 (prerelease) (Debian 4.1.2-17):
$ time ./threadring.gcc 10000000
361

real    0m17.672s
user    0m3.381s
sys     0m15.385s

GNAT 2008 GPL:
$ time ./threadring 10000000
361

real    0m28.330s
user    0m16.466s
sys     0m25.692s

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

Почти в 2 раза это не разница?

У меня на ноуте:
$ gnatchop threadring.gnat 
splitting threadring.gnat into:
   threadring.adb
$ gnatmake -gnatp -O3 -f -fomit-frame-pointer -Wall threadring.adb
gcc-4.2 -c -gnatp -O3 -fomit-frame-pointer -Wall threadring.adb
gnatbind -x threadring.ali
gnatlink threadring.ali -fomit-frame-pointer
$ gcc -c -gnatp -O3 -fomit-frame-pointer -Wall threadring.adb
$ gnatbind -x threadring.ali
$ gnatlink threadring.ali -fomit-frame-pointer
$ nano threadring.c
$ /usr/bin/gcc -pipe -Wall -O3 -fomit-frame-pointer -lpthread ./threadring.c -o threadring.gcc
./threadring.c: В функции ‘main’
./threadring.c:73: предупреждение: control reaches end of non-void function
$ erlc threadring.erl 
$ erl -noshell -run threadring main 10000000
$ time ./threadring.gcc 10000000
361

real	0m36.120s
user	0m6.796s
sys	0m28.030s
$ time ./threadring 10000000
361

real	1m26.313s
user	0m32.038s
sys	1m7.968s
$ time erl -noshell -run threadring main 10000000
361

real	0m3.184s
user	0m3.052s
sys	0m0.100s

т.е. имеем: ADA/C=2.4, ADA/Erlang=28!!!
28 раз это не космическая разница? Кстати, Erlang AFAIK как раз для realtime-систем и разрабатывался

еще есть забавная прога на Яве, которая в разделе "interesting alternative programs":

winger@winger-laptop:~/ada$ javac threadring.java 
winger@winger-laptop:~/ada$ time java threadring 10000000
361

real	0m1.805s
user	0m1.708s
sys	0m0.048s

прирост по сравнению с ADA 47 раз!

Хотя это решение не совсем честное - оно использует cooperative threads, написанные в ручную конкретно под данную задачу

Абсолютно в точку.. Под каждым словом можно подписаться ) Особенно "ДА РАБОТАЕТ ЖЕ!".

> Ерланги всякие тут отдыхают и нервно курят в сторонке.

Вот, что нашёл: http://shootout.alioth.debian.org/gp4/benchmark.php?test=all&lang=gnat&am...

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

> т.е. имеем: ADA/C=2.4, ADA/Erlang=28!!!

> 28 раз это не космическая разница?

И откуда такая уверенность, что нити в Аде и Эрланге - это одно и то же? Разберись с матчастью.

> Erlang AFAIK как раз для realtime-систем и разрабатывался

Для soft-realtime.

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

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

Кстати, проблема не столько с компиляторами, сколько со сборщиками мусора, ИМХО.

> Кстати, проблема не столько с компиляторами, сколько со сборщиками мусора, ИМХО.

Сборщики мусора где-то уже лет 30 как умеют в риалтайме работать.

> то это уж точно будет не Хаскел с его непредсказуемой ленивой производительностью :D

Естественно.

>> Кстати, проблема не столько с компиляторами, сколько со сборщиками мусора, ИМХО.

> Сборщики мусора где-то уже лет 30 как умеют в риалтайме работать.

Ссылки? А то сборщики мусора JVM для реалтайма точно не подходят. Ну если не ставить директивных сроков в секунды, конечно.

А кого колышет JVM?

Есть алгоритм Кнута, например, который применим к жесткому реальному времени (каждая итерация сборки выполняется за константное время).

Какая разница, одно и то же, или нет? Фишка Erlang'а в том, что это функциональный язык и по определению великолепно паралелится и не имеет болезней вроде dead-lock'ов.

Можешь реализовать тест на ADA как оптимальней, если сможешь), там задача простенькая.

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

http://en.wikipedia.org/wiki/Real_time_Java

> Какая разница, одно и то же, или нет?

Долго объяснять. Если интересно, то почитай о threading models (моделях нитевания, хе) M:N против 1:1

> не имеет болезней вроде dead-lock'ов.

Эрланг фанбой детектед.

> http://en.wikipedia.org/wiki/Real_time_Java

Спасибо, Капитан Очевидность.

Это как раз таки не real time.

Жабе в этом плане ничего не светит, её модель злоупотребления памятью несовместима с GC реального времени.

Я знал, я знааал :). Я чувствовал это :)

//true_admin

В Erlang'е не совсем threads, там что-то вроде процессов,они не имеют общего контекста и общаются с помощью сообщений и, соответсвенно, без lock-ов вообще

З.ы. реализованы они как N:M

> В Erlang'е не совсем threads, там что-то вроде процессов

Нить, по опредленеию, это контекст исполнения в рамках адресного пространства. Процессы Эрланга - это нити.

> общаются с помощью сообщений и, соответсвенно, без lock-ов вообще

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

Написание deadlock'а на Эрланге оставлено как домашнее задание для читателя.

>a thread is contained inside a process and different threads in the same process share some resources while different processes do not. (с википедии)

Процессы Erlang'а не "share some resources"

>> a thread is contained inside a process and different threads in the same process share some resources while different processes do not. (с википедии)

> Процессы Erlang'а не "share some resources"

Правда? И адресное пространство у них всех (в рамках VM) - не общее? Тогда ой :D

И процессы из "космически отличного" теста запускались в разных адресных пространствах? Или даже на разных машинах? :D

deadlock в Erlang'е обычно получается только при неправильной логике программы, на пустом месте его получить почти нереально, в отличии от deadlock'ов в императивных языках

> deadlock в Erlang'е обычно получается только при неправильной логике программы

Но он возможен? ЧИТД. И не бросайся фразами "не имеет болезней вроде dead-lock'ов".

> на пустом месте его получить почти нереально, в отличии от deadlock'ов в императивных языках

Ты удивишься, но и в императивных языках deadlock'и - это результат "неправильной логики программы".

В том то и фишка, что "рулит" всем этим не программист, а VM, т.е. он в принципе не может что-либо испортить, это не его забота, как оно там внутри выполняется.

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

Да, кстати... Эрланг - не чисто функциональный язык. Спроси Армстронга :D

> Ты удивишься, но и в императивных языках deadlock'и - это результат "неправильной логики программы".

Да ну? То есть если я в одном потоке засинхронизировал сначала объект A, потом объект B, а в другом наоборот, то это относится к логике программы?

Чисто функциональных языков не бывает, это фантастика )

Вообще, чтобы в эрланге сотворить дедлок нужно постараться, ибо есть возможность ставить таймаут на receive. И уж скорее один из процессов у тебя умрет из-за таймаута (и будет перезапущен супервизором), чем образуется deadlock. Хотя, конечно, если очень захотеть, то можно и не такое сотворить...

ЗЫ: Процессы в эрланге, они как хомячки: пожрать, потрахаться и сдохнуть.

> То есть если я в одном потоке засинхронизировал сначала объект A, потом объект B, а в другом наоборот, то это относится к логике программы?

Да.

>> То есть если я в одном потоке засинхронизировал сначала объект A, потом объект B, а в другом наоборот, то это относится к логике программы?

>Да.

обоснуй

ИМХО это "особенности реализации"

>>> То есть если я в одном потоке засинхронизировал сначала объект A, потом объект B, а в другом наоборот, то это относится к логике программы?

>> Да.

> обоснуй

Ну нифига себе.

Перефразирую: что ты понимаешь под логикой программы?

ИМХО в эрланге дедлок/гонку можно устроить с помощью ets, но тут уж ССЗБ.

> Перефразирую: что ты понимаешь под логикой программы?

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

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

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

А разные потоки могли писать два программиста независимо, и не знать, в каком порядке лочит его коллега

> Я имел в виду логический каркас программы, то есть то что делает архитектор

Каркасы бывают разные. Может быть, эрланговские gen_* что-то там и облегчают с точки зрения дедлоков, не знаю.

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

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

> А разные потоки могли писать два программиста независимо, и не знать, в каком порядке лочит его коллега

А еще они могут не знать, какие единицы использует другой :D Интерфейсы нужно описывать.

> Есть алгоритм Кнута, например, который применим к жесткому реальному времени (каждая итерация сборки выполняется за константное время).

Не подойдет. Если это "константное время" будет достаточно большим, то сборщик мусора нельзя будет всё время держать запущенным. Лучше бы иметь неблокирующий сборщик, ну или с константным временем блокировки :)

Статья про жавовый риалтаймовый GC: http://www.ibm.com/developerworks/java/library/j-rtj4/index.html

Pl/Sql

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

(с вики)