Здравствуйте, Evgeny.Panasyuk, Вы писали:

BZ>>CSP (а вовсе не акторы), на которых основан эрланг — это идея из 70-х, так что она тоже более чем классическая (как и сам EP>Судя по всему всё же на акторах, а не CSP:

спасибо, я всё время это забываю

BZ>>мне кажется, лучше делить подходы на shared memory/messaging

EP>Параллельные вычисления реализуются и там и там: TBB (shared memory), MPI (Message Passing).

а мы говорили о классификации подходов к concurrency. кстати, TBB реализует и message passing approach, в виде графа задач

Здравствуйте, BulatZiganshin, Вы писали:

BZ>при дефолтных настройках апач не выдержит даже одного посетителя в секунду на 8 гигах озу

Ну это уже бред) Разве что время одного коннекта часами измеряется)))

Здравствуйте, alex_public, Вы писали:

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

_>Ещё раз повторюсь: в Эрланге не получится получить ровно такую же производительность.

имеем бибилиотеку С++, реализующую лёгкие потоки (скажем boost::fiber или Win32 fiber) внутри системных и библиотеку C++, реализующую пул потоков, куда можно кидать таски. внимание вопрос — какая из них будет быстрее?

Здравствуйте, neFormal, Вы писали:

F>простая блокировка.
F>приходит сообщенька по сети, тред её обрабатывает и уходит в дедлок/ожидание внешнего ресурса/что-то-ещё. вот и блокировка.

Ну так в случае асинхронного IO это физически невозможно) А использование лёгких потоков в сочетание с асинхронным IO — это практические негласное правило в C++. ))) Правда опять же это всё предназначено для очень узкой ниши...

Здравствуйте, neFormal, Вы писали:

_>>На самом деле я не очень хороший пример показал — из него не совсем понятна разница между openmp и просто функциями типа parallel_transform. Скажем вот с таким вариантом что делать:
_>>

_>>#pragma omp parallel for
_>>for(int i=1; i<size-1; i++) d[i]=(s[i-1]+s[i]+s[i+1])/3;
_>>

F>с точки зрения энларга ничего не изменилось.
F>всё равно нужна будет лямбда.

А чем тут поможет лямбда? )Мы же про parallel_map говорим, правильно? )

Здравствуйте, alex_public, Вы писали:

F>>приходит сообщенька по сети, тред её обрабатывает и уходит в дедлок/ожидание внешнего ресурса/что-то-ещё. вот и блокировка.
_>Ну так в случае асинхронного IO это физически невозможно)

это почему это?

Здравствуйте, alex_public, Вы писали:

_>А чем тут поможет лямбда? )Мы же про parallel_map говорим, правильно? )

ничем не поможет. просто других средств нету.
ну и какой же map без лямбды?! дрянь, а не map.

Здравствуйте, alex_public, Вы писали:

_>Кстати, а что у нас с таким http://rsdn.ru/forum/flame.comp/6096387

Автор: alex_public
Дата: 30.06.15

случаем?

Есть parallel_for.

EP>>Про std::function не понял — она точно также может принимать лямбду, там же шаблонный конструктор.
_>std::function — тормоз.

Да, тем не менее лямбды может хранить.

_>Но зато не требует шаблонов (и соответственно позволяет хранить массивы и т.п.). Поэтому её любят некоторые разразботчики библиотек, но тут тормоза явно противопоказаны. )))

Здесь да, лучше шаблон функции, так как соседние итерации скорей всего будут выполняться последовательно в одном потоке, и инлайн + unroll тут эффективен.

_>>>3. А что скажешь насчёт openacc? )
EP>>Тот же подход что и в OpenMP — и если для C и Fortran это и приемлемо, то для C++ как-то не айс. Например C++ AMP выглядит более идиоматично.
_>C++ AMP — это же не кроссплатформенно.

Там же отрытая спецификация, и вроде даже есть компилятор в OpenCL.

_>Мне в общем тоже не особо нравятся подходы openmp/openac. Но если у openmp есть много сравнимых аналогов, то ничего проще openacc на рынке не видно — Cuda, OpenCL и т.п. на этом фоне выглядят просто как мегастрах. )

Думаю что для требовательных задач без них не обойтись — OpenACC скорей всего не хватит, точнее результат будет слишком неоптимальным по сравнению с возможным. Потому что потоки GPGPU очень легковесные, и там шаг вправо-влево и получаем серьёзные просадки.
Или например там есть возможность управлять локальной памятью, барьерами внутри блоков?

Здравствуйте, Философ, Вы писали:

BZ>>при неструктурированном убийстве и автоматическом переключении потоков первая проблема — возвращение памяти, принадлежащей переменным внутри этого потока. её можно решить, используя GC. вторая — неконсистентность разделяемых данных, её можно решить, используя в убиваемых потоках только message passing, и оставляя использование разделяемых данных на долю структурированно завершаемых потоков

Ф>Всё правильно, я тоже за категорический отказ от многопоточности. Позволю себе повториться:
Ф>[q]
Ф>Я с многопоточностью воюю уже лет семь, наверное.
Ф>Знаешь, я до сих пор не осилил: всё равно периодически допускаю ошибки синхронизации и падение производительности там, где теоретически она должна была бы вырасти.

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

сейчас я пишу на С++, ошибки есть, и мне интересно попробовать TBB чтобы всё делалось через него — общение между задачами, их убийство

Ф>Если нет проблемы с производительностью, то лучшим выходом здесь будет отказ от многопоточности — проблема уйдёт сама собой

напоминает мне дидактическую историю о чуваках, которые пошли в кафе, напились до хрюканья и покалечились в драке. теперь они приняли меры — не ходят в кафе

у тебя проблемы с синхронизацией, так попробуй использовать m.p. вместо неё

Ф>Ты здесь предлагаешь почти тоже самое, ибо вынесение всей конкуренции в один "синхронизирующий" поток — фактический отказ от многопоточности. Может лучше вообще не заморачиваться, а?

о нет, речь у меня во-первых, о выносе разделяемых данных (а не всей конкуренции), а во-вторых, в структурно убиваемые потоки (а не один поток). т.е. поток, который работает только с локальными данными и messages, можно убивать прямо средствами ОС. и наоборот — если реализовать механизм работы с сообщениями, который я описал, то поток может спокойно работать с разделяемыми данными

Ф>Понимаешь, если совсем нет связи по данным, то незачем связываться с многопоточностью: вполне можно обойтись многопроцессностью, а для надёжности код на разных машинах выполнять.

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

что касается выноса задач в процессы ОС, то ради бога. по сути это и есть эмуляция process isolation & control из erlang

Здравствуйте, alex_public, Вы писали:

BZ>>при дефолтных настройках апач не выдержит даже одного посетителя в секунду на 8 гигах озу

_>Ну это уже бред) Разве что время одного коннекта часами измеряется)))

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

и на бис — как исходя из этих чисел посчитать сколько озу требуется апачу

Здравствуйте, Mamut, Вы писали:

Ф>>>>Зачем всё это? (зачем управлять потоками)
Ф>>>>Почему нельзя положиться на рантайм — пусть он управляет.

M>>>Действительно, ведь рантайм наделен телепатической силой и знает о том, что программист хочет сделать.

Ф>>Объясни рантайму, что ты хочешь.

M>О. Внезапно. То есть уже надо управлять потоками.

Задачи и потоки — разные вещи. Как бы то ни было, но задачу ты каким-либо образом определяешь. Даже просто написав функции, и упорядочив их исполнение, ты определил задачи и связь между ними. При таком же подходе, у тебя задачи становятся чем-то весомым, осязаемы, тем, ты можешь манипулировать в процессе исполнения. При желании, их можно на экране отобразить, например затем, чтобы смотреть на скорость создания/завершения.
Потоки это не задачи, это то, что задачи исполняет.

Определять задачи и "управлять" ими я вижу необходимость, рулить потоками — нет.


Ф>>Хочешь ты наверняка не потоками управлять, а задачу (в фоне) выполнить. Так и создавай задачу, например вот так:
Ф>>Задача — это не поток, задача может использовать отдельный поток, но не обязательно. Задачи ты можешь комбинировать (сцеплять, задавать зависимости между ними), отменять отдельные задачи — совершенно другой уровень.

M>Каким образом это я буду делать, если мне ни язык ни библиотеки не предоставляют никакой возможности это делат, кроме как устраивать закаты вручную?

Например с помощью TPL, которая входит в B ase C lass L ibrary.

Ф>>Повторюсь: убивать поток — плохая идея.
Ф>>Для прекращения выполнения кода существуют другие методы. Самый удачный, на мой взгляд — реакция самой задачи на CancellationToken.

Ф>>Может быть ты знаешь какую-то магию, которую я не знаю в этой области? Как эта проблема решается в Erlang'е?

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

гм...
с моей точки зрения это ничем не отличается от упомянутого ранее CancellationToken'а: когда задача становится способной обработать завершение, то в зависимости от ситуации, может быть брошено исключение (если выставлен ThrowIfCancellationRequested), либо она сама прочитает IsCancellationRequested и штатно завершиться. Тут я тоже вижу штатное завершение — никак не TerminateThread, и не Thread.Abort

Здравствуйте, alex_public, Вы писали:

_>>>На самом деле я не очень хороший пример показал — из него не совсем понятна разница между openmp и просто функциями типа parallel_transform. Скажем вот с таким вариантом что делать:
_>>>

_>>>#pragma omp parallel for
_>>>for(int i=1; i<size-1; i++) d[i]=(s[i-1]+s[i]+s[i+1])/3;
_>>>

F>>с точки зрения энларга ничего не изменилось.
F>>всё равно нужна будет лямбда.
_>А чем тут поможет лямбда? )Мы же про parallel_map говорим, правильно? )

В случае с parallel_map можно использовать ленивый список индексов по типу boost::irange

Здравствуйте, Evgeny.Panasyuk, Вы писали:

EP>В общем случае будет parallel_for (есть и в TBB и PPL):
EP>

EP>parallel_for(1, size-1, [&](auto i)
EP>{
EP>   d[i] = (s[i-1]+s[i]+s[i+1])/3;
EP>});
EP>

Воот, это уже другое дело. Это уже может заменить самые стандартные применения openmp. Правда опять же оно такое мало где есть под рукой (скажем в __gnu_parallel)...

Здравствуйте, BulatZiganshin, Вы писали:

_>>Ещё раз повторюсь: в Эрланге не получится получить ровно такую же производительность.
BZ>имеем бибилиотеку С++, реализующую лёгкие потоки (скажем boost::fiber или Win32 fiber) внутри системных и библиотеку C++, реализующую пул потоков, куда можно кидать таски. внимание вопрос — какая из них будет быстрее?

При схеме N лёгких на N системных будет почти одинаково (с поправкой на обработку бесполезных вызовов yield в случае лёгких).

Здравствуйте, alex_public, Вы писали:

_>>>Ещё раз повторюсь: в Эрланге не получится получить ровно такую же производительность.
BZ>>имеем бибилиотеку С++, реализующую лёгкие потоки (скажем boost::fiber или Win32 fiber) внутри системных и библиотеку C++, реализующую пул потоков, куда можно кидать таски. внимание вопрос — какая из них будет быстрее?

_>При схеме N лёгких на N системных будет почти одинаково (с поправкой на обработку бесполезных вызовов yield в случае лёгких).

а чем эрланг хуже?

Здравствуйте, neFormal, Вы писали:

F>>>приходит сообщенька по сети, тред её обрабатывает и уходит в дедлок/ожидание внешнего ресурса/что-то-ещё. вот и блокировка.
_>>Ну так в случае асинхронного IO это физически невозможно)
F>это почему это?

Ну потому что асинхронное IO в принципе не блокируется.
http://www.boost.org/doc/libs/1_58_0/doc/html/boost_asio/overview/core/basics.html и http://www.boost.org/doc/libs/1_58_0/doc/html/boost_asio/overview/core/async.html — тут хорошие картинки на эту тему.

http://www.boost.org/doc/libs/1_58_0/doc/html/boost_asio/overview/core/threads.html — что касается системных потоков при таком раскладе.
http://www.boost.org/doc/libs/1_58_0/doc/html/boost_asio/overview/core/spawn.html — использование лёгких потоков (поверх системных) при таком раскладе, по сути для "выпрямления" кода.

Здравствуйте, neFormal, Вы писали:

F>ничем не поможет. просто других средств нету.
F>ну и какой же map без лямбды?! дрянь, а не map.

Ну т.е. мы не можем написать на Эрланге аналог такого простейшего многопоточного кода? )

Здравствуйте, BulatZiganshin, Вы писали:

BZ>неправда.

Не думаю.

BZ>короутины, futures, message passing, вообще все средства конкурентного программирования используются и в параллельных задачах тоже

Если опуститься еще на уровень ниже, то окажется, что futures/promises, message passing и даже stm, реализуется посредством низкоуровневых примитивов синхронизации вроде атомиков, критических секций, семафоров, мутексов, событий, кондишенов и т.д.

Имеет ли смысл инструментарий относить к конкретному классу задач?

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

Не вижу противоречий. Parallel computing и concurrent computing -- это разные типы задач. В реализации которых используется один и тот же набор базовых механизмов. Набор этот зачастую именуют concurrency, что создает дополнительную путаницу.

Посему, возвращаясь к вопросу AlexRK "Вот таски в Ada — это средства для параллелизма или конкурентности?" получается, что сам по себе таск в Ada -- это один из набора механизмов для обеспечения concurrency. Но вот будет ли таск использован для решения задачи из категории parallel computing или из категории concurrent computing -- зависит уже от конкретного прикладного кода.

Здравствуйте, Evgeny.Panasyuk, Вы писали:

_>>C++ AMP — это же не кроссплатформенно.
EP>Там же отрытая спецификация, и вроде даже есть компилятор в OpenCL.

Спецификации — это дело десятое. Нужна именно реализация. MS вряд ли создаст реализацию под другие платформы. А другие тем более не будут.

EP>Думаю что для требовательных задач без них не обойтись — OpenACC скорей всего не хватит, точнее результат будет слишком неоптимальным по сравнению с возможным. Потому что потоки GPGPU очень легковесные, и там шаг вправо-влево и получаем серьёзные просадки.

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

EP>Или например там есть возможность управлять локальной памятью, барьерами внутри блоков?

Не знаю, я ещё не пробовал на практике) Тем более, что в gcc оно поддерживает только Nvidia.

Здравствуйте, BulatZiganshin, Вы писали:

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

BZ>и на бис — как исходя из этих чисел посчитать сколько озу требуется апачу

Так это же зависит от реализации сайта. Если там скажем код по полчаса в БД сидит, то понятно что быстро всё сдохнет. А если код вменяемый, то Апач спокойно держит такие смешные нагрузки как один клиент в секунду. )))