ANI, новый язык программирования

Нет. И рядом не валялось. Здесь очень частный случай.

>high-performance, statically-safe, fully implicitly parallel, object-oriented, general-purpose dataflow programming language ANI

works on all of the popular operating systems

lightweight programming that runs even faster than typical C

resulting binary will be statically safe and deadlock-free

ANI stands for «Animus»

Видимо код компилятора состоит из трёх директив:

ЭТИС! АТИС! АНИМАТИС!

> Я сказал, что надо знать язык на уровне «смогу написать компилятор, если захочу». Для этого не надо писать компилятор каждого встреченного языка, ага.

Откуда ты знаешь, что можешь написать компилятор для 20 языков, если ты не пробовал? Я, например, представляю, как написать компилятор императивного языка (хотя и не написал ни одного), но не компилятор функционального языка с их замороченными внутренними формализмами.

Впрочем, вопросов больше нет.

>> Там четко выделено понятие пайпа который может параллелится, и этот пайп определяется всегда explicitly.

Алё! Последовательность вычислений в любом императивном языке - тот же «пайп».

Бред.

Распараллелить её неявно как раз и есть интересная задача.

Для которой новый язык нафиг не нужен.

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

Интересно, зачем эта конструкция в ANI? :)

>Видимо код компилятора состоит из трёх директив:

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

Последовательность вычислений в любом императивном языке - тот же «пайп». Распараллелить её неявно как раз и есть интересная задача.

Але - внутренности пайпов не параллелятся - паралеллятся пайпы. То есть явно продекларированные пайпы «неявно» параллелятся - ага-да, неявно.

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

Ну да - явная разметка потенциально параллельного кода не помогает.

А чем плох подход?

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

Даже с Task Parallel Library в .NET оно работает. В Occam оно работает.

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

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

А чем плох подход? Даже с Task Parallel Library в .NET оно работает. В Occam оно работает

Хм, а в Occam праллелизм тоже неявный? :)

>но не компилятор функционального языка

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

> > Я сказал, что надо знать язык на уровне «смогу написать компилятор, если захочу». Для этого не надо писать компилятор каждого встреченного языка, ага.

Откуда ты знаешь, что можешь написать компилятор для 20 языков, если ты не пробовал? Я, например, представляю, как написать компилятор императивного языка (хотя и не написал ни одного), но не компилятор функционального языка с их замороченными внутренними формализмами.

Я (другой анонимус), пробовал (до ленивых ФП языков не добрался, ничего, в отпуске поиграюсь) - ничего сложного. Мы же не говорим про оптимизирующие компиляторы с хорошим error detection & recovery? %)

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

Это сферического в вакууме вроде лямбда-калкулуса. А такого на котором можно будет реально работать - не все так просто.

ы же не говорим про оптимизирующие компиляторы с хорошим error detection & recovery? %)

:))

> Я (другой анонимус)

Если ты другой, то ты не говорил и про «не можешь писать компиляторы для 2- языков - не вякай».

в отпуске поиграюсь

не говорим про оптимизирующие компиляторы с хорошим error detection & recovery? %)

Я уж точно не об «поиграюсь в отпуске» говорю :)

>А такого на котором можно будет реально работать - не все так просто.

оно и будет реально( что не значит полезно) работать, это же свойство фс, что всё вычисляется прямолинейно, только для ИО нужно всё огораживать на уровне языка и разбивать вычисления на что типа sequence point.

> Если ты считаешь, что мощь и стройность концепции можно влёгкую продемонстрировать на примерах уровня «Hello, world», то мне не удастся тебя просветить при всём желании. Потому что из идиота не получится Капицы, хоть ты тресни.

Совершенно согласен с тобой, анонимус:

ты не можешь продемонстрировать мощь и стройность концепции на примерах уровня «Hello, world», поскольку ТЫ — идиот.

Умные же люди смогут продемонстрировать преимущества например шаблонов над полиморфизмом через наследование если и не в одну строку ( как например template<class T> T max(const T& a, const T& b) {return a<b? a:b; } ) то в несколько строк.

Охренеть, я не успеваю запоминать как они называются, а они все новые и новые пишут

> Откуда ты знаешь, что можешь написать компилятор для 20 языков, если ты не пробовал?

Пробовал. Писал.

но не компилятор функционального языка с их замороченными внутренними формализмами.

Тю. Функциональщину намного проще делать. SECD-машина вообще примитивна. STG я делал интереса ради, и поверх си, и с прямой трансляцией в x86.

WAM тоже делал, так что и логические языки не страшны. Самый кошмар все же императивные языки, их оптимизировать тяжело.

Всё даже проще. Рекомендую всем читать «ZINC experiment» Лероя, весьма доступно изложены подходы к реализации eager functional языков.

> Хм, а в Occam праллелизм тоже неявный? :)

Ты глупый, да?

В Occam всё, что угодно - отдельный поток. А уж будет оно параллельно или последовательно - это уже как получится. И производительность от этого самого «всё распараллелить» не проседает.

>> Откуда ты знаешь, что можешь написать компилятор для 20 языков, если ты не пробовал?

Пробовал. Писал.

Ну так ты дашь список языков, для которых написал компиляторы? Как бы академические традиции - список публикаций и всё такое.

>> Хм, а в Occam праллелизм тоже неявный? :)

Ты глупый, да?

Нет, а ты?

В Occam всё, что угодно - отдельный поток.

Какой бред. Отдельными _процессами_ является только то, что запускается коструктором PAR. Если ты _это_ называешь «неявным параллелизмом», то у тебя какой-то свой, собственный русский язык.

А уж будет оно параллельно или последовательно - это уже как получится.

Программист должен явно пометить параллельные блоки кода и соединить их каналами, что тебе непонятно?

К чему эта мода на свои собственные языки программирования? Такими темпами и до объектно-ориентированого Брейнфака дойдём. Хотя, в принципе, побольше языков, ООП-шных и разных!

В Occam всё, что угодно - отдельный поток.

Только не в том понимании в котором его имеет операционка. Окамовский процесс - этор скорее процедура (кусок кода).

А уж будет оно параллельно или последовательно - это уже как получится.

как указано явно конструктами типа SEQ/PAR.

И производительность от этого самого «всё распараллелить» не проседает.

Потому что там параллелится не все а то что сказано распаралелить программистом.

Си для одной экзотической однокристаллки. Оптимизирующий Форт. Простенький Лисп и ещё более простой ML.

> Только не в том понимании в котором его имеет операционка. Окамовский процесс - этор скорее процедура (кусок кода).

В Occam каждая переменная - это процесс.

Потому что там параллелится не все а то что сказано распаралелить программистом.

Принято параллелить всё что можно, а компилятор + железо уже решают, надо ли оно.

и все это конечно жутко засекречено и предъявлению не подлежит? :) у нас в локалке такой же «профи» есть - всем рассказывал как он крут, только вот когда устраивался на работу - во всех конторах все на полу валялись от смеха :)))

> Какой бред. Отдельными _процессами_ является только то, что запускается коструктором PAR. Если ты _это_ называешь «неявным параллелизмом», то у тебя какой-то свой, собственный русский язык.

Да нет же, ты глупый. Почему не веришь? Никто не говорил, что в Occam неявный параллелизм. Говорилось, что в программах на Occam параллелят всё, что можно, не разбираясь, нужно ли это, и в результате никаких проблем с производительностью нет. Так что, если это же делать автоматически, результаты будут не столь страшными, как тут всякие теоретики пугают.

>> Только не в том понимании в котором его имеет операционка. Окамовский процесс - этор скорее процедура (кусок кода).

В Occam каждая переменная - это процесс.

O_o

Приведи пример конструкции.

Потому что там параллелится не все а то что сказано распаралелить программистом.

Принято параллелить всё что можно, а компилятор + железо уже решают, надо ли оно.

Не компилятор, но пусть. В любом случае, никакого отношения к неявному параллелизму подход Оккама не имеет. Так же, как и подход shell. И там, и там - CSP во все поля.

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

В Occam каждая переменная - это процесс.

Тебе что процитировать определение процесса из самого оккама?

Принято параллелить всё что можно, а компилятор + железо уже решают, надо ли оно.

В понятие все что можно входит каждая строчка. Если параллелится все что можно - зачем там вообще сонструкты типа SEQ/PAR?

Распараллель эффективно хотя бы теоретически приведенный код:

x = a + b y = c + d z = x + y

Или приведи алгоритм для компилятора который может принять эффективное решение об распараллеливании ли не распараллеливании следующего кода:

x = f(a) y = g(b) z = t(x,y)

> А оно надо

т.е. пока дело не доходит до предъявления фактов - мы распинаемся и про свой интеллектуальный уровень, и научную работу, и про написанные компиляторы, а как только надо хоть что-то показать - так сразу «а оно надо»? :))) хватит позориться, клоун :)

>> Какой бред. Отдельными _процессами_ является только то, что запускается коструктором PAR. Если ты _это_ называешь «неявным параллелизмом», то у тебя какой-то свой, собственный русский язык.

Да нет же, ты глупый.

Да нет же, ты.

Почему не веришь?

Почему я должен тебе верить?

Никто не говорил, что в Occam неявный параллелизм.

Ну наконец-то. Не прошло и недели, как на вопрос «а в Occam праллелизм тоже неявный?» получен:ответ «нет».

Никто не говорил, что в Occam неявный параллелизм.

Все ходы записаны.

Говорилось, что в программах на Occam параллелят всё, что можно, не разбираясь, нужно ли это, и в результате никаких проблем с производительностью нет

Ну значит покоментировать поставленную задачку будет не вопрос правда? Или опять нет времени на нас сирых и только за сто миллионов?

> Приведи пример конструкции.

Читай спеки. Я с 95-го года на Оккаме не писал.

В любом случае, никакого отношения к неявному параллелизму подход Оккама не имеет.

Имеет. Он демонстрирует, что не так уж и страшно всё что только можно разделить на параллельные процессы. Проще потом обратно собрать в последовательность, если нет ресурсов на параллельное исполнение.

> Все ходы записаны.

Вот и прочитай, в каком контексте об Occam-е говорилось. Там же говорилось, что неявный параллелизм никто ещё и не реализовал до сих пор.

Ну значит покоментировать поставленную задачку будет не вопрос правда?

Какую задачу? Ты о чём вообще?

>> Приведи пример конструкции.

Читай спеки.

Ну вот всегда так.

Да, ты только подтверждаешь в очередной раз. Ты не просто глупый, ты невменяемый. На всю голову.

Повторяю для идиотов - неявного параллелизма нет вообще нигде ещё. Только обещают, во всяких там хаскеллях.

Occam приводился в пример на безответственный взвяк о том, что мол якобы надо знать, сколько времени займёт f(x) и g(x), чтоб решать, а надо ли их засунуть в PAR. Ответ - не надо ни хрена знать. Засовывай смело, там разберутся.

>>> Приведи пример конструкции.

Читай спеки.

Ну вот всегда так.

Тут где-то была тема, как получить помощь линукс-гуру, когда те отсылают к манам. Сейчас как раз тот случай =)

> Ну вот всегда так.

А вообще хватит тролить анонимусов. Сколько можно?

Ну, во первых, клоун здесь ты. Известный клоун. Давно тут позоришься.

Во вторых, про «интеллектуальный уровень» вонять как раз гораз ды и прочие хвостоганнеры. Я говорю только о науке. Только всякое дерьмо (ты, например) считает, что можно и нужно чего-то не знать. Нормальные люди считают, что не знать стыдно. Только и всего, урод.

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

Да е мое:

Кто заявил сначала что:

www.linux.org.ru/view-message.jsp?msgid=4420884&lastmod=1263230687019&amp...

Детали подхода к реализации implicit parallelism, как минимум, заслуживают внимания.

А потом:

www.linux.org.ru/view-message.jsp?msgid=4420884&lastmod=1263230687019&amp...

А чем плох подход? Даже с Task Parallel Library в .NET оно работает. В Occam оно работает. Почему тут не сработает?

Какую задачу? Ты о чём вообще?

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

анонимус начал исходиться на говно? забавное зрелище :) вы ж не забывайте вашу роль - интеллектуал и академик, у которого каждая минута стоит бешеных денег ;)

Компилятор тупой, он не знает, какие участки кода независимы друг от друга. Для того только и нужны PAR/SEQ. Каждая примитивная конструкция языка является процессом, и PAR/SEQ просто сшивают эти процессы в последовательность явным образом.

Occam приводился в пример на безответственный взвяк о том, что мол якобы надо знать, сколько времени займёт f(x) и g(x), чтоб решать, а надо ли их засунуть в PAR. Ответ - не надо ни хрена знать. Засовывай смело, там разберутся.

Феерический бред. Occam это пример языка где такое решение оставлено за программистом.

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

Я, кажется, знаю, какой профессионал живёт у вас сети, и над кем смеялись в каждой конторе над собеседованием. Ну, ну откуда ты знаешь о всех его собеседованиях? Думаю, что это таки ты :p

> Феерический бред. Occam это пример языка где такое решение оставлено за программистом.

Ты на Occam писал? Нет? Тогда чего вякаешь? Это «решение» на практике сводится к «разпараллеливаем всё, что можно». Думать не надо. Накладных расходов на PAR там, где ему не место, там нет.

Евгений Ваганыч, вы???

А где противоречие? Программист решает запустить f и g одновременно и запускает. Делов. А после окончания вычисления всё собирается вместе. Если оверхеда на парализацию мало - то можно запросто плодить гринтреды/етц. Есть ресурсы - прекрасно, оно работает одновременно. Нет - ну что ж, всё равно загруженно всё. Или я не правильно понял?

Да ты тоже невменяем, на пару с tailgunner.

Дурачишка, «Чем плох подход?» было в ответ на «запараллелить все что параллелится.». Именно это и делается при программировании на Occam - тупо, бездумно. Да, не автоматически, но какая разница? Подход то работает, что бы там дурачки всякие не теоретизировали.

И, дурачок, это работает даже с таким говном как .NET - Task Parallel Library так и используют - на каждый чих по task-у, а уж делать из него отдельный процесс, или не делать - оно само решит.

Извиняюсь за мой русский