Что забыл?

Забыл ответить на заданный вопрос.

Ядро в opencl сугубо последовательное, и с другими потоками не взаимодействует.

Не совсем правда.

В Хаскеле это делается тривиально.

Можно увидеть код на хакселе?

В чистом си тоже может быть неявная параллельность, если архитектура позволяет (reordering + pipelining).

Равные длины векторов

Ещё — http://stackoverflow.com/questions/10534744/static-types-polymorphism-and-spe....

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

Забавно. А с таким определением «конкурентности», вообще существуют «параллельные» языки?

В чистом си тоже может быть неявная параллельность, если архитектура позволяет (reordering + pipelining).

Так это не фишка сей, это фишка процессора которая будет работать с любыми программами на любых языках.

Эх, интересная для меня тема, как-нить подниму процессоросрачь в Development.

Точнее: это один из способов оптимизации дженериков.

Да. В порядке оптимизации это вполне катит.

Можно увидеть код на хакселе?

Как-то так:

class InnerProduct a where innerProduct :: a -> a -> Integer
data Nil = Nil
data Cons a = Cons Integer a
instance InnerProduct Nil where innerProduct Nil Nil = 0
instance InnerProduct a => InnerProduct (Cons a) where innerProduct (Cons a as) (Cons b bs) = a * b + innerProduct as bs
generateAndMultiply i =
  let g :: InnerProduct a => Int -> Integer -> a -> a -> Integer
       g 0 _ as bs = innerProduct as bs
       g i n as bs = g (i-1) (n+1) (Cons (2*n+1) as) (Cons (n*n) bs)
  in g i 1 Nil Nil

Конкретнее? Если без local address space. Никаких фичей в самом языке для параллельности нет и быть не должно.

Забыл ответить на заданный вопрос.

Для тупых. Дженерики, сделанные по-нормальному, это позволяют. Дженерики, сделанные путём генерирования мономорфного кода (темплейтами, если угодно) — не позволяют.

Забыл ответить на заданный вопрос.

Для тупых.

Тупые - это те, которые забывают вопрос, на который отвечают. Да и вообще - остынь. Ответ «тебе я ничего не буду отвечать, потому что твой уровень квалификации слишком низок» вполне катит.

Ну да, а чем barrier() не форма синхронизации?

А с таким определением «конкурентности», вообще существуют «параллельные» языки?

Разница между http://en.wikipedia.org/wiki/List_of_concurrent_and_parallel_programming_lang... и https://en.wikipedia.org/wiki/Category:Concurrent_programming_languages ?)

Немного мыслью по древу:

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

Concurrent computing is a form of computing in which programs are designed as collections of interacting computational processes that may be executed in parallel.

may выделено курсивом.

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

A concurrent language is defined as one which uses the concept of simultaneously executing processes or threads of execution as a means of structuring a program.

Откуда полагаем, что тут «simultaneously» может быть «не настоящая».

То есть если не may, то point не теряется, так как суть в структуре программ.

A parallel language is able to express programs that are executable on more than one processor.

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

Тут можно взять can, и если не can, то весь point теряется (кто будет использовать OpenMP на одном ядре?), только в качестве незапланированного поведения (выявляемого профилированием), так что не should/shall.

Both types are listed as concurrency is a useful tool in expressing parallelism, but it is not necessary.

anonymous говорил про семантику — как минимум семантически в «конкурентном» языке должна быть нотация для (денотации) p | q (и !p), сообщения или общие ресурсы уже опциональны. Что будет делать планировщик уже не важно — регистрировать процессы по ядрам/нодам и на каждом переключать их или переключать задачи в последовательном режиме на одном вычислителе.

Для «параллельности» аналогичная денотация f on A | g on B должна предполагать именно железно параллельное выполнение f и g на A и B. Повыше уровнем могут быть менее строгие (но с синхронизацией по времени) !f и f | g, а f[g] может неявно компилироваться в f | g.

Ещё говорят, что «конкурентность» индетерминированна, а «параллельность» — детерминированна.

Для примера — в Haskell есть p >> forkIO q для p | q (forkIO p для !p) и f `par` g для f | g. Там это совсем разные вещи. Конечно, f `par` g не даёт точных гарантий, да и ядро может быть одно, но в целом оно «работает».

В C++ есть std::thread и OpenMP, TBB (parallel_ и concurrent_).

Ещё говорят про coarse-grained concurrency и fine-grained parallelism.

Последнее (http://en.wikipedia.org/wiki/Cilk — Paradigm(s): parallel, Categories: Concurrent programming languages o_0) — с одной стороны spawn, с другой — determinism и sync, то есть параллелизм в овечьей шкуре :)

Разница между http://en.wikipedia.org/wiki/List_of_concurrent_and_parallel_programming_lang... и https://en.wikipedia.org/wiki/Category:Concurrent_programming_languages ?)

...высосана из пальца. Как сказало наше всё, «computer science masturbation».

Для «параллельности» аналогичная денотация f on A | g on B должна предполагать именно железно параллельное выполнение f и g на A и B. Повыше уровнем может быть !f, а f[g] может неявно компилироваться в f | g.

Юзабельное определение. И где языки, в которых гарантируется железное параллельное исполнение (потому что «должна полагать» не катит)? Ну разве что Occam с конструкцией PLACED, но Occam ты уже отнес к конкурентным.

Тупые - это те, которые забывают вопрос, на который отвечают.

Или вопрос, которые сами же и задали. Хотя он был процитирован: «и почему же?»

Дальнейшая отмотка треда платная.

Или вопрос, которые сами же и задали

А, так ответ звучит как «на тупые вопросы не отвечаю». Окей.

Дальнейшая отмотка треда платная.

Да мне даже произведенная не нужна была.

А, так ответ звучит как «на тупые вопросы не отвечаю».

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

?)

...высосана из пальца

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

Parallel and Concurrent Programming in Haskell (комментарий) и по ссылке по этой ссылке.

Иначе скажи что ты называешь параллельным и конкурентным — интересно.

И где языки, в которых гарантируется железное параллельное исполнение (потому что «должна полагать» не катит)?

Я сказал — OpenMP, rpar в Haskell, если не удаётся добиться от них железного параллелизма, то мы что-то делаем не так — оно брыкаться от этого не будет, продолжит «работать», но это инженерный tradeoff.

Occam ты уже отнес к конкурентным

http://en.wikipedia.org/wiki/Occam_(programming_language)

Если я правильно предполагаю про PLACED — да, у обычных тредов и процессов тоже есть affinity, это следствие того, что, согласно «моей» терминологии, конкурентность тредов и процессов оптимизирована параллелизмом по ядрам, как следствие — есть возможность использовать это самое affinity. Но если ядро одно — никакого placed, а конкурентность на месте :)

Так это не фишка сей

Разумеется

В чистом $LANGUAGE_NAME тоже ...

даже если LANGUAGE_NAME = CPython :)

Но си обычно компилируемый и reordering это ещё и фишка компилятора сей.

Иначе скажи что ты называешь параллельным и конкурентным — интересно.

Я не вижу никакой существенной разницы между «параллельным» и «конкурентным» языком. Думаю, ее высосал из пальца Пайк, чтобы казаться умнее, чем он есть на самом деле.

Occam ты уже отнес к конкурентным

http://en.wikipedia.org/wiki/Occam_(programming_language)

И? Если ты хотел сказать «не я отнес» - совершенно неважно, кто именно.

И где языки, в которых гарантируется железное параллельное исполнение (потому что «должна полагать» не катит)? Ну разве что Occam с конструкцией PLACED

Если я правильно предполагаю про PLACED — да

«Да» - это ответ на вопрос «где языки» или «является ли Occam параллельным»? Если второе, то он уже записан в конкурентные, нет ли здесь противоречия?

если ядро одно — никакого placed, а конкурентность на месте :)

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

LANGUAGE_NAME = CPython :)

Нет такого языка.

Нет такого языка.

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

В тред врывается курсера

https://www.coursera.org/course/compilers курс по компиляторам, в ходе которого пишется компилятор под мипс для паскалеподобного языка с ООП.
Thanks to SMD

CPython :)

Нет такого языка.

Ну только ты не начинай.

Это не я начал. Или ты тоже считаешь, что CPython, Jython и PyPy - разные языки?

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

*пожимая плечами* некоторые считают, что термины важны.

некоторые считают, что термины важны.

Некоторые буквоедством на ночь глядя занимаются.

https://www.coursera.org/course/compilers курс по компиляторам, в ходе которого пишется компилятор под мипс для паскалеподобного языка с ООП.

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

Мне нравится подход когда ты постоянно видешь результат — начинаешь с чего-то простого и наколеночного, потом постепенно апгрейдишь а между делом узнаёшь что-то новое. Тут как-то треть-половину я уже знал, а оставшиеся вещи меня не волновали. Но за первые двадцать лекций я не почувствовал что приблизился к цели. Реально пользы было больше поспрашивать на лоре и своей головой подумать.

Но это мои тараканы, я просто устал от длинных курсов. Обычно я более-менее точно знаю чего хочу и, скажем, 70% материала курса мне не нужно.

Я не вижу никакой существенной разницы между «параллельным» и «конкурентным» языком.

(Физический) параллелизм это буквально параллельное выполнение задач на разных физических вычислителях со строгим и наперёд известным control-flow, конкурентность это несколько более общее понятие о структурировании программ на независимые взаимодействующие процессы с более свободным (I/O зависимым в т.ч.) потоком выполнения, тут параллелизм процессов может быть физическим или виртуальным, или и тем и другим. Связь между процессами и между ними и I/O может вовлекать какие-то event-based механизмы в планировщике.

Это как я это вижу.

И говорить нужно не про языки, а про языковые средства — в Haskell Control.Concurrent и Control.Parallel это разные вещи которые используют для разных вещей. Как и std::thread и OpenMP в С++.

«Да» - это ответ на вопрос «где языки» или «является ли Occam параллельным»?

«Да» тут это ничего не значащее вводное слово, то есть я не вижу чем наличие placed или affinity противоречит конкурентности — если та вовлекает физический параллелизм в своей реализации, то естественно есть возможность иметь placed или affinity.

Должен ли я понимать это так, что программы на «параллельных языках» не запускаются на однопроцессорных машинах?

Вот кстати про «параллельные языки» я ничего не говорил, это anonymous. Я просто сказал, что occam конкурентный и не предполагает (физического, я это подразумеваю, говоря «параллелизм») параллелизма.

«occam конкурентный» значит что в нём есть соответствующие языковые средства — их может иметь смысл использовать на любых машинах.

Имеет ли смысл использовать языковые средства параллельного программирования (типа OpenMP) на однопроцессорных машинах?

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

«Да» - это ответ на вопрос «где языки» или «является ли Occam параллельным»?

«Да» тут это ничего не значащее вводное слово

Тогда где всё-таки языки с гарантированным аппаратным параллелизмом?

просто сказал, что occam конкурентный и не предполагает (физического, я это подразумеваю, говоря «параллелизм») параллелизма.

С PLACED PAR - предполагает.

Имеет ли смысл использовать языковые средства параллельного программирования (типа OpenMP) на однопроцессорных машинах?

Да, конечно. От чисто отладочных целей до параллелизации на IO и гипертрединга.

Или ты тоже считаешь, что CPython, Jython и PyPy - разные языки?

В порядке тупнячка — конечно! (hint: язык = множество цепочек над словарём, что-то мне подсказывает, что есть цепочка из множества PyPy которая не принадлежит множеству CPython, ещё, например, есть понятие «диалект» у gcc — диалект это тоже язык (c++11, gnu++1y и т.п.)).

Или ты тоже считаешь, что CPython, Jython и PyPy - разные языки?

В порядке тупнячка — конечно! (hint: язык = множество цепочек над словарём, что-то мне подсказывает, что есть цепочка из множества PyPy которая не принадлежит множеству CPython

Если в порядке тупнячка, то нужно сказать, что не существует языка CPython - существуют, например, CPython 2.[0-7], CPython 3.[0-4].

А то когда в PyPy наконец запилят STM, выяснится, что Python еще и параллельный.

Тогда где всё-таки языки с гарантированным аппаратным параллелизмом?

Бери любой и гарантируй.

С PLACED PAR - предполагает.

Вот значит и его можно брать, помимо уже названных C++ и Haskell.

отладочных целей до параллелизации на IO

Первое — ок, а второе это как?

гипертрединга

*совсем-совсем однопроцессорных.

Тогда где всё-таки языки с гарантированным аппаратным параллелизмом?

Бери любой и гарантируй.

Мне бы существующие.

отладочных целей до параллелизации на IO

Первое — ок, а второе это как?

Одна нить блокируется на IO, вторая исполняется.

Мне бы существующие.

Я не предлагал «любой из несуществующих». Любой значит любой — существующий, общего назначения, пусть будет высокого уровня — C, C++, ... + онтопик (ОС которая умеет SMP, affinity и гарантии, если считать что онтопик умеет гарантии affinity) + многоядерный(е) узел(ы), думаю будет достаточно.

Одна нить блокируется на IO, вторая исполняется.

И будут они переключаться на одном ядре. ИМХО, one-to-one и вынесение IO за скобки конструкций с прагмами OpenMP выглядит более оптимально и правильно.

З.Ы. Ещё — «высокий параллелизм» Эрланг и «высокая конкурентность» GPU это с ног на голову, как мне кажется.

Я не предлагал «любой из несуществующих»

Ты предлагал «бери любой и гарантируй». Мне нужен список тех, в которых это уже гарантировано, до меня.

Любой значит любой — существующий, общего назначения, пусть будет высокого уровня — C, C++

Здесь я окончательно перестал тебя понимать.

Хватит офтопить уже. Выкладывай карты — что не так? В «любом» C или С++ нет pthread (или std::thread и TBB в C++)? Я не назвал уже языки предоставляющие более идиоматические (чем pthread) средства параллельного программирования (OpenMP, Parallel Haskell, Cilk, пусть они работают и через свой рантайм + pthread)? Ты сам уже сказал что occam умеет. В крайнем случае есть Erlang и тупо spawn на другой ноде — вот уже где гарантии «параллельности». Или тебе не нравится требование иметь многоядерные узлы и онтопик? Ну так если нам нужен аппаратный параллелизм и его гарантии, то в первую очередь нам нужен будет программно-аппаратный комплекс который это умеет, иначе о чём речь? Короче, я не вижу проблем.

Выкладывай карты — что не так?

Выкладываю карты еще раз:

tailgunner> Я не вижу никакой существенной разницы между «параллельным» и «конкурентным» языком. Думаю, ее высосал из пальца Пайк, чтобы казаться умнее, чем он есть на самом деле.

Не понимаю — как можно не видеть разницу между, например, тем что есть «конкурентность» в nginx (в основном достигаемая мультиплексированием) и «параллелизм» в нём же (достигаемый воркерами по ядрам).

Не понимаю - какое отношение имеет nginx к языкам программирования.

Ещё раз — не нужно про языки («параллельные» и «конкурентные» языки — нет, так говорить плохо :)), нужно про конкретные языковые средства (и даже библиотечные). Тут интересно как конкурентность достигается в рантаймах Erlang и GHC — в одном треде ОС могут существовать тысячи их лёгких тредов взаимодействующих с IO тем же мультиплексированием и планируемых рантаймом, самих тредов ОС рантайму достаточно по количеству ядер (можно больше если нужно, и это уже параллелизм), прямая аналогия с nginx, только видим где языковые средства конкурентности (forkIO и spawn). В GHC ещё есть языковые средства параллелизма — http://www.haskell.org/ghc/docs/latest/html/users_guide/lang-parallel.html :

The expression (x `par` y) sparks the evaluation of x (to weak head normal form) and returns y. Sparks are queued for execution in FIFO order, but are not executed immediately. If the runtime detects that there is an idle CPU, then it may convert a spark into a real thread, and run the new thread on the idle CPU. In this way the available parallelism is spread amongst the real CPUs.

Concurrent Haskell != Parallel Haskell. Совсем.

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

нужно про конкретные языковые средства (и даже библиотечные)

Нужно _что_? Ты можешь сказать, являются pthreads конкурентным средством или параллельным? И почему именно так?

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

Если говорить про Linux, то, я так понимаю, это универсальный API, поэтому его можно использовать как для конкурентности, так и для параллелизма — можем делать много pthread_create, IO, общения, довериться планировщику (конкурентность (_и_ параллелизм, но просто со стороны планировщика на системах с SMP), есть книжка C++ concurrency in action, там про средства нового стандарта, но они суть обвёртка над pthread на Linux), либо посмотреть топологию и если она нам нравится — делать мало pthread_create, выставлять affinity, обходиться без IO и сильной связности/общения, что-то считать и собирать результат (параллелизм). Собственно, OpenMP и GHC для параллелизма используют pthread (с ним и линкуются). Разве что у GHC и Erlang получается лучше сделать планировщик (в расчёте на свойства этих языков) лёгких тредов с мультиплексированием, так что они не используют pthread для конкурентности, как и nginx.

это универсальный API, поэтому его можно использовать как для конкурентности, так и для параллелизма

И то же самое про любой «конкурентный» язык. </thread>

любой

Concurrent Haskell != Parallel Haskell. Совсем.

Первое — универсально подобно pthread, второе — нет, только параллелизм (если нет «idle CPU», то оно теряет смысл).

</thread>

Пожалуй.

Разделение на лексер и парсер это и есть шаг назад. ... За пегом будущее

Не пори чушь.

25.01.2013 «как быстро создать свой ЯП?»
23.08.2013 «из AST в c/cpp/objc: как?»

Через пару лет выкатит преальфу.

Эй, не делайте вид что меня тут нет!

Неужели через 2 недели релиз?

Сам ты чушь. Ты некомпетентен.