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

_>Кстати, насчёт вручную... Ну просто не могу не задать один коротенький практический вопрос. Вот есть у меня такой код (из реального теста):
_>который очевидно выполняет некую многопоточную обработку массива данных, с использованием всех ресурсов процессора. И я даже не буду просить написать код работающий быстрее (зачем смешить людей). Я предложу всего лишь написать на Эрланге код с той же функциональностью, но при этом более простой и удобный в написание, чем данный пример. Ведь на Эрланге у нас же не требуется "закатывать солнце вручную" для реализации многопоточности, не так ли? )

будет то же самое, только вместо omp+for будет parallel_map.
но т.к. этого нет в дефолтной поставке, то будет либо дополнительный код, либо подключённая библиотека, которые уже будут использовать эрланговские потоки.
если придираться, то да, кода типа больше. но за omp тоже скрывается много.

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

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

F>>>я что-то не понял, почему.
F>>>поток убили снаружи? а его в этот момент использовали?
Ф>>Он использовал.
Ф>>Или не использовал — ты в общем случае не знаешь, поэтому можешь перекреститься, и надеяться на то, что не использовал.

F>кого же он использовал или не использовал?

Кого угодно — в общем случае ты не знаешь, кого он использовал.
Мог, например, из файла читать, периодически дёргая SetFilePointer(), или общие счётчики увеличивать/уменьшать. А ты ему вот так бряк, и TerminateThread(), посреди дороги. В самом лучшем случае он мог на экран что-нибудь выводить — хотя бы данные не испортишь.

F>>>аргументы?
F>я всё ещё надеюсь их увидеть.

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

Т.е. исправишь, конечно, но только фактическим отказом от многопоточности: как тут предлагают, переносом всей конкуренции в один "критический" (синхронизирующий) поток.

Ф>>>>Проблема не в технологии, а в том, что в общем случае ты не знаешь что и в какое состояние нужно всё возвращать. Простой пример: нужно ли закрывать файл, открытый в другом потоке? Может быть его удалить нужно?
F>>>почему не знаю? файл нужно закрыть, если он был открыт.
Ф>>А если создан, стало быть, удалить? Бгг ))

F>зачем? тоже закрыть. это не транзакции, даже не надейся.

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

EP>>В контексте C++ основное (и возможно единственное) преимущество OpenMP — это доступность из коробки в популярных средах.
_>1. Только если parallel_transform умеет принимать лямбду (а не std::function), иначе это не подойдёт для распараллеливания прямо в коде (без выноса в функцию — обычно то просто цикл с неким кодом стоит).

Обычно parallel_transform это шаблон функции.
Про std::function не понял — она точно также может принимать лямбду, там же шаблонный конструктор.

_>2. Библиотечку надо ещё собирать и подключать...

Тут согласен, у OpenMP как раз плюс в доступности, правда тоже есть свои нюансы.

_>Кстати, а какую ты тут имел в виду? )

Конкретно такой parallel_transform есть в PPL. В libstdc++ есть аналогичный __gnu_parallel::transform. В Intel TBB был бы какой-нибудь parallel_for.
И есть кстати proposal подобных алгоритмов (там небольшое отличие).

_>3. А что скажешь насчёт openacc? )

Тот же подход что и в OpenMP — и если для C и Fortran это и приемлемо, то для C++ как-то не айс. Например C++ AMP выглядит более идиоматично.

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

_>>Ну даже если мы сумеем сделать их маленькими (в Эрланге кстати не выйдет
F>это почему это? какие там такие большие расходы?

Так обсудили же это уже. В Эрланге кроме расходов на планировщик идут ещё и расходы на поддержку кооперативной многозадачности (то самое прерывание потоков и т.п.). В C++ реализации лёгких потоков мы такие вещи ставим руками, так что в случае чего-то типа числодробилки мы можем минимизировать потери. Хотя это в любом случае бредовая идея, даже на C++ — гораздо проще взять системные потоки, причём возможно даже в автоматической реализации (типа openmp).

F>для равномерного выполнения и балансировки.
F>опять же никакой поток не сможет заблокировать всю работу.

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

Ну а разбалансировка между системными потоками конечно теоретически возможно, но только при малом числе запросов (а тогда и смысла в лёгких потоках нет). А при большом очевидно всё будет нормально.

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

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

Всё правильно, я тоже за категорический отказ от многопоточности. Позволю себе повториться:

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

Простой пример: в одном из 100 случаев не валидируются данные клиента. Такое нельзя отдебажить — в дебаге у тебя всё будет работать как часы. Нужно перечитывать код, и переделывать его так, чтобы ошибка стала очевидна. А это значительное время, и учитывая мою зарплату большие деньги. Если нет проблемы с производительностью, то лучшим выходом здесь будет отказ от многопоточности — проблема уйдёт сама собой.

http://rsdn.ru/forum/flame.comp/6064110.1

Автор: Философ
Дата: 31.05.15

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

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

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

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

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

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

F>>апач много лет уже не в тренде.

_>Опять же сайты с высокой посещаемость не являются большинством в вебе. )

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

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

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

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

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

это, похоже, та самая проблема с shared memory.
от неё приходится отказываться, иначе — да, всё, как ты и описываешь.

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

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

Согласен) Вот если бы Mamut писал бы только подобные фразы, то разве с ним кто-нибудь тут спорил бы? )))

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

S>Задачи решаются посредством инструментов. Поэтому таск в Ada может быть использован как для реализации параллельности, так и для реализации конкурентности.

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

даже банальное создание потоков не является средством параллельности в win95

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

_>Так обсудили же это уже. В Эрланге кроме расходов на планировщик идут ещё и расходы на поддержку кооперативной многозадачности (то самое прерывание потоков и т.п.).

это всё работа планировщика.

_>В C++ реализации лёгких потоков мы такие вещи ставим руками, так что в случае чего-то типа числодробилки мы можем минимизировать потери. Хотя это в любом случае бредовая идея, даже на C++ — гораздо проще взять системные потоки, причём возможно даже в автоматической реализации (типа openmp).

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

F>>для равномерного выполнения и балансировки.
F>>опять же никакой поток не сможет заблокировать всю работу.
_>Какая блокировка то и равномерное выполнение? )

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

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

F>это, похоже, та самая проблема с shared memory.
F>от неё приходится отказываться, иначе — да, всё, как ты и описываешь.

Если у тебя нет разделяемых данных, то нафига тебе многопоточность? Юзай процессы.

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

S>А вот уже параметры инструмента могут определять, насколько он пригоден или не пригоден к решению тех или иных задач. Например, короутины хороши при работе с async IO, но доставляют много хлопот в вычислительных задачах.

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

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

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

Ф>Если у тебя нет разделяемых данных, то нафига тебе многопоточность? Юзай процессы.

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

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

F>будет то же самое, только вместо omp+for будет parallel_map.
F>но т.к. этого нет в дефолтной поставке, то будет либо дополнительный код, либо подключённая библиотека, которые уже будут использовать эрланговские потоки.
F>если придираться, то да, кода типа больше. но за omp тоже скрывается много.

На самом деле я не очень хороший пример показал — из него не совсем понятна разница между 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;

Здравствуйте, 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;
_>

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

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

EP>Обычно parallel_transform это шаблон функции.

В хороших библиотека, да). Кстати, а что у нас с таким http://rsdn.ru/forum/flame.comp/6096387

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

случаем?

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

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

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

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

Здравствуйте, 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;
_>

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

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

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

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

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

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

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

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