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

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

PAR и SEQ нужны потому что ответа на поставленный мной вопрос компилятор найти не может самостоятельно, равно как и сгенерировать эффективный параллельный код для двух строчек как альтернативу этому поставленному вопросу. Именно поэтому програмисту самому предполагается решить какой код можно параллелить эффективно, а какой нельзя.

И возвращаясь к сабжу учитывая что там пайпы не обединяются явно в SEQ или наоборот явно не параллелятся с помощью PAR, а каждый пайп будет по заявлениюб автора параллельным, выдает то что афтор просто не понимает что делает (именно потому он углубился в синтаксис и считает строчки в мудрецах вместо того чтобы предьявить proof-of-concept самой идеи), и скорее всего это студент с курсовиком.

> PAR и SEQ нужны потому что ответа на поставленный мной вопрос компилятор найти не может самостоятельно, равно как и сгенерировать эффективный параллельный код для двух строчек как альтернативу этому поставленному вопросу. Именно поэтому програмисту самому предполагается решить какой код можно параллелить эффективно, а какой нельзя.

Дурак. Компилятор сам не может вообще решить, что можно параллелить, а что нельзя. Без всяких там «эффективно».

И программист про «эффективно» не думает, потому как накладные расходы на это дело минимальны. Ты хоть раз Inmos живой видел?

ну куда уж мне до академиков и пейсателей компиляторов - так, быдлокодю понемногу, и в отличии от последних не претендовал никогда на большее, только вот странно - я быдлокодер, но могу показать, что написал, а вот многоуважаемые «академики» почему-то оставляют после себя только тонны говна но ЛОР, странно это все ;)

Это «решение» на практике сводится к «разпараллеливаем всё, что можно».

Следовательно на практике ты напишешь:

INT x,y,x:
INT a IS 2:
INT b IS 2:

SEQ
   PAR
     x := a + b
     y := a - b
   z := x + y


вместо


SEQ
   x := a + b
   y := a - b
   z := x + y

так чтоли?

> я быдлокодер

Да, ты быдло

но могу показать, что написал

Покажи, раз можешь. Пока после тебя куча говн остаётся. Странно это всё.

Пока что ты только чешешь языком. Я раньше думал, что ты строишь из себя дурака, но, видимо, я ошибался. Ты и в самом деле недалёкий.

> Да, ты быдло

да еще и какое :)

Покажи, раз можешь

гугль в помощь - я на ЛОР не раз писал, если ты так внимательно следил, как я годами «позорюсь» на ЛОР, то должен был видеть

Ты и в самом деле недалёкий.

д'Артаньян и Ваганыч в одном лице? это становится интересно

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

Повторяю для идиотов

Такой академичный стиль, просто прелесть :)

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

«Если вас не интересует результат» (с), то конечно. А вообще, неплохо бы, чтобы f(x) и g(x) были хоть примерно равны по сложности.

А где противоречие? Программист решает запустить f и g одновременно и запускает. Делов.

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

Если оверхеда на парализацию мало - то можно запросто плодить гринтреды/етц

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

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

В зеркало посмотри.

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

Я читал маны :) В них не было утверждения «каждая переменная - это процесс».

Дурак. Компилятор сам не может вообще решить, что можно параллелить, а что нельзя. Без всяких там «эффективно».

Ну елки палки, а «решить» он не может потому что он бондинка с ПМС или (толстый намек) по причине задач которые я сформулировал? И если бы ты подумал чуть головой вначале когда начал возводить себя на постамент а остальныхз называть идиотами - ты бы не оказался в такой яме.

И программист про «эффективно» не думает, потому как накладные расходы на это дело минимальны.

Следовательно ты напишешь с помощью какой угодно технологии более скоростной параллельный код для двух строк чем последовательный да?

А вообще, неплохо бы, чтобы f(x) и g(x) были хоть примерно равны по сложности.

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

Похоже данная сложнейшая концепция непостижима для нашего академика.

хехе..

я бы не стал уповать на гугл, как на истину в последней инстанции

http://translate.google.ru/#ru|en|%D1%8D%D1%82%D0%BE%20%D0%BD%D0%B5%20%D0%BF%D1%80%D0%BE%D0%B8%D0%B7%D0%BE%D1%88%D0%BB%D0%BE

Зачем нужен очередной ненужный ЯП?

Экспериментальных языков с оригинальными идеями очень мало. Большая часть экспериментальных языков - повторение старого на новый лад, и достаточно 10-15 минут на каждый из них, дабы это определить.

вобщем-то я как раз про это Вам и говорил, не знаю зачем Вы стали возражать

> к примеру реализовать адекватный (!) компилятор, к примеру, для С++ это не то же самое что для scheme..

Я говорю о принципиальной способности это сделать, а не о желании.

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

> Вы вот сами подписались бы на создание (хотя бы) компилятора переднего плана для С++?

Если бы вдруг очень надо было - то подписался бы. Сейчас, когда есть GLR и PEG, это намного проще чем раньше.

ололо, Вы не первый с шапкозакидательскими настроениями такой и, видимо, не последний кто обломается :)

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

И не надо их писать. Я говорю об уровне понимания языка.

я не пойму как в Вашем сознании уровень понимания языка отождествляется с написанием компилятора?

> ну и обоснуйте теперь :)

Чего обосновывать? Что параллелизм в Erlang явный? Это как бы следует из самой используемой модели message passing.

Неявный параллелизм - это если компилятор возьмёт конструкцию for(i=0;i<N;i++) count+=a; и разобьёт её на несколько потоков автоматически.

так и запишем: Erlang'a не знает, спорит беспредметно :)

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

ну, не согласен... где-то в интернетах была история о том как ребятки компилятор для С++ ваяли и как это вылилось в несколько лет с учётом того что они были далеко не лузеры у ним был тестовый фреймворк для языковых фич

> ололо, Вы не первый с шапкозакидательскими настроениями такой и, видимо, не последний кто обломается :)

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

я не пойму как в Вашем сознании уровень понимания языка отождествляется с написанием компилятора?

Если ты не знаешь, как язык реализовать, ты язык не знаешь.

Знаю я этих ребяток из МГУ. Они таки были лузеры, вообще-то.

>> Ну, если в одно лицо писать нетривиальный компилятор, это несколько месяцев работы.

ну, не согласен... где-то в интернетах была история о том как ребятки компилятор для С++ ваяли и как это вылилось в несколько лет

Статья Зуева о компиляторе Си++? Она не очень показательна, потому что работоспособный компилятор у них появился раньше, а сам Си++ очень сложен (грубо говоря, писать такую фигню в одиночку нельзя). ПерваЯ версия Си++-фронтенда для GNU CC была написана за 3 или 4 месяца, AFAIK.

> я не пойму как в Вашем сознании уровень понимания языка отождествляется с написанием компилятора?

Если ты не знаешь, как язык реализовать, ты язык не знаешь.

как язык реализовать? засуньте его поглубже :)

а если без шуток я только одного не могу понять - как Вы эти две вещи между собой связываете? и как распознать «я решил что стал достаточно крутым чтобы смочь написать компилятор» от реальной способности?

>> Ну, если в одно лицо писать нетривиальный компилятор, это несколько месяцев работы.

ну, не согласен... где-то в интернетах была история о том как ребятки компилятор для С++ ваяли и как это вылилось в несколько лет

Статья Зуева о компиляторе Си++? Она не очень показательна, потому что работоспособный компилятор у них появился раньше, а сам Си++ очень сложен (грубо говоря, писать такую фигню в одиночку нельзя). ПерваЯ версия Си++-фронтенда для GNU CC была написана за 3 или 4 месяца, AFAIK.

не, ну если в таком разрезе рассматривать - тогда согласен...

Знаю я этих ребяток из МГУ. Они таки были лузеры, вообще-то.

ну с учётом того что Вы и этого не осилили Вам помолчать бы должно, а лучше сразу идите в газпром работать... скважиной :)

Как я понимаю если f(x) и g(x) равны по времени исполнения это идеальный случай, в общем виде имеем time(fork) + max(time(f(x)), time(g(x))) + time(randevu) + time(h(f,g)). В последовательном виде time(f(x))+time(g(x))+time(h(f,g)).

И если компилятору удалось сделать время запуска потоков + время их рандеву меньшим, чем время вычисления или f(x) или g(x), то, как не странно, мы тоже получаем выигрыш, по сравнению, с нераспараллеленым кодом.

Точно оценить время исполнения функции невозможно (у нее есть параметр), но т.к. время разделения и встречи потоков величины не космического масштаба, то тут можно применить какую-либо вероятностную оценку или эвристику для оценки времени выполнения f,g. Т.е. пусть у нас оверхед от параллельности составляет 20 тактов. Тогда если время выполнения любой из функций f или g больше 20 тактов в 95% вызовов - мы получаем гарантированный выигрыш. И пусть в 5% случаев мы проиграли, зато в остальных 95% вызовов мы этого выигрыша добились.

Здесь, конечно, будут уместны советы программиста компилятору (не явные указания типа SEQ/PAR а именно советы по диапазонам параметров, и по частоте их встречаемости). Например можно подсказать что чаще всего x>20, или наоборот x всегда меньше 5. Либо собирать статистику с профайлера.

Как вариант компилятор предлагает несколько вариантов разбиения, а на этапе исполнения выбирается лучший. Например если x<5 то не распараллеливаем. Здесь, даже в худшем случае, мы имеем небольшой оверхед от проверки, а не гораздо больший от неудачного форка. Ну и больший размер исполняемого блоба, хотя кого сейчас этим напугаешь :P.

P.S. Поправьте меня если я ошибаюсь, а оно скорей всего так и есть, все таки второй час ночи.

То, что доктор прописал для потоковых машин!

Классная штука! А детишкам в памперсах! Прежде чем критиковать. Попробуйте прогу на C распараллелить на несколько десятков тысяч процессоров...

tmp/lexerStructGen.exe: bld/lexerStructGen.cpp
@echo Building lexer structure generator...
@mkdir -p tmp
@g++ bld/lexerStructGen.cpp -o tmp/lexerStructGen.exe

Вот такие штуки в Makefile встречаются. Зачем тут exe, если пути типа /usr/bin? Автор работает под виндой?

И если компилятору удалось....

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

то тут можно применить какую-либо вероятностную оценку или эвристику для оценки времени выполнения f,g.

....а именно например?:))

И пусть в 5% случаев мы проиграли, зато в остальных 95% вызовов мы этого выигрыша добились.

А если 96% - это же лучше чем 95%? А еще лучше - 98%. Тут почти не сомневаться можно в этих высосаных из пальца цифрах:)

Я уж не говорю о 20 тактах на мультитрединг и синхронизацию - это как минимум корки процессора так договариваться уметь должны....

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

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

Ага - в каждой строчке (у нас же параллелиться каждая строка да?). Жесть. К тому же с суммарный эффект таких советов на таком микроуровне весьма нуждается в в практикотеоретических исследованиях. Кто сказал что эффект коммулятивный?

С такими советами компилятору проще аннотировать действительно нуждающийся в параллелизации код.

Либо собирать статистику с профайлера.

А что я там говорил про JIT/HotSpot?

Например если x<5 то не распараллеливаем.

Ну это даже всякие либы осиливают без необходимости в языке.

оно скорей всего так и есть, все таки второй час ночи.

Оно то есть только это оно к сабжу никакого отношения не имеет.

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

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

Во-вторых, у меня есть такое ощущение, чтобы параллелить всё, что можно, PAR/SEQ не нужен, а нужен всего лишь data flow analysis.

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

Возьми вычислительную задачу на Haskell, распараллель абсолютно всё с помощью par и seq и посмотри на результат.

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

Отсуствие защиты памяти в транспьютере, аппаратный планировщик, аппаратные же каналы :)

Блин. Ничего неполучается скомпилить. %(

Эта картинка проясняет всю суть этого язычка http://www.macalester.edu/mathcs/images/IMG_1726crop.PRES.edited.jpg

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

В Parallel Haskell — есть. Чего-то мне кажется, что в Occam — тоже.

Occam на особом железе работает.

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

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

[

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

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

можно прекрасно понимать язык но не будучи знакомым с паттернами проектирования и наработанным опытом изобретать наново «лисапеты» и кроить уютный «быдлокодик» и я такие примеры видел :)

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

ну всё в кучу смешали :) Вы то сам пишете в машинных кодах?

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

Мне хватает общих знаний об устройстве компиляторов.

И не звезди, что видишь конкретные машкоды стоящие за каждым выражением. Обкакаешься.

>Си для одной экзотической однокристаллки.

ну несомненно ты сразу крут, да. только вот нахрена ?

Оптимизирующий Форт.

таки правда? да?

Простенький Лисп и ещё более простой ML.

ну это фактически любой более менее грамотный инженер из области ИТ может.

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

толсто, глупо, ты - идиот.

Предлагаю завершить тему общего ля ля!

Еще раз обращаю ваше вниманиие на то, что предлагаемый язык програмирования «заточен» для программирования компьютеров следующего поколения! А тут базар - вокзал! Большинство же вообще не ведает, как поведет себя тот или иной проц от Intel при дурной оптимизации кода!

Лучше обсудить темы, преимуществ и недостатков самого языка!

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

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

это ж плохой тролль.

>ну несомненно ты сразу крут, да.

Причем тут кстати крутость?

Так любой хоть немного грамотный инженер и может оценить каждый новый язык. И должен это делать. А не кричать сразу «не нужно».

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

Отсуствие защиты памяти в транспьютере, аппаратный планировщик, аппаратные же каналы :)

А в видеокартах есть защита памяти? :)

> Еще раз обращаю ваше вниманиие на то, что предлагаемый язык програмирования «заточен» для программирования компьютеров следующего поколения!

Что-то на сайте я таких утверждений не видел.

Лучше обсудить темы, преимуществ и недостатков самого языка!

Так давай. Вот, например, я спрашивал: http://www.linux.org.ru/jump-message.jsp?msgid=4420884&cid=4426838 Мне так никто ничего вразумительного не ответил.

>> Отсуствие защиты памяти в транспьютере, аппаратный планировщик, аппаратные же каналы :)

А в видеокартах есть защита памяти? :)

Нет. А видеокарты стали программировать на Occam? O_o

Introduction

anic is the reference implementation compiler for the experimental, high-performance, statically-safe, fully implicitly parallel, object-oriented, general-purpose dataflow programming language ANI.

И всем. Кто кроме x86 PC ничего не видел. Для получения минимальной инфы о параллельных системах зайти на parallel.ru

> Нет. А видеокарты стали программировать на Occam? O_o

Ого, а что, защита памяти обязательная фича для системы для оккам?

Отличный пиар сайта. Зарегался специально для этого?

> anic is the reference implementation compiler for the experimental, high-performance, statically-safe, fully implicitly parallel, object-oriented, general-purpose dataflow programming language ANI.

Нахер ты тут это цитируешь? Я по ссылкам хожу и читать умею. Только там одни пионерские туториалы. После заголовка «Warning: Computer Science Content!» никаким computer science и не пахнет.

Ты лучше приведи описание concurrent модели сабжа, в частности как там реализован concurrency control. А то у меня такое подозрение, что никак.