LINUX.ORG.RU

std::reduce (и собратия) с ограничением на число тредов

 , ,


1

3

Привет ЛОР.

Как ограничить максимальное число тредов, доступных для std::reduce с parallel_unsequenced_policy? Я просмотрел соответствующие страницы в cppreference, но не нашёл ответа. Я попробовал поиграться на уровене prlimit, но получил ошибку thread_monitor Resource temporarily unavailable in pthread_create. Хотелось бы не городить костылей в виде семафоров и мьютексов только ради такой казалось бы простой задачи.

UPD: В стандартной библиотеке так сделать нельзя, а вот в HPX можно. Вот пример: https://github.com/STEllAR-GROUP/hpx/blob/master/examples/quickstart/vector_zip_dotproduct.cpp

★★★★★

Последнее исправление: luke (всего исправлений: 1)

Ответ на: комментарий от anonymous

если линукс то можете поменять _SC_NPROCESSORS_ONLN

Знать бы только как поменять.

luke ★★★★★
() автор топика
Ответ на: комментарий от annulen

В какое Спортлото написать? Трупу страуса? Или в gcc попросить сделать нестандартное расширение?

luke ★★★★★
() автор топика
Ответ на: комментарий от luke

Если на серьезе это обсуждать, то сначала с разработчиками стандартных библиотек, libstdc++ или libc++. Если ты, конечно, не вхож в комитет, но тогда таких вопрос бы не возникало :)

Ну или выкинуть каку и переходить на openmp

annulen ★★★★★
()
Ответ на: комментарий от annulen

то сначала с разработчиками стандартных библиотек, libstdc++ или libc++

разрабы libc++ не реализовали Parallelism TS вовсе. О чём с ними можно разговаривать?

Там parallel_unsequenced_policy нет.

fsb4000 ★★★★★
()
Последнее исправление: fsb4000 (всего исправлений: 1)
Ответ на: комментарий от fsb4000

Но у них наверняка есть об этом мнение, и в комитет они вхожи

annulen ★★★★★
()
Ответ на: комментарий от annulen

то сначала с разработчиками стандартных библиотек, libstdc++ или libc++

Они всегда могут отбрехаться, что это не в стандарте.

Ну или выкинуть каку и переходить на openmp

По счастию я пока на std::reduce перейти не успел, так что OpenMP будет скорее всего самым простым решением.

luke ★★★★★
() автор топика
Ответ на: комментарий от luke

думаю openmp под капотом в libcxx аля clang

anonymous
()
Ответ на: комментарий от luke

Они всегда могут отбрехаться, что это не в стандарте.

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

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

annulen ★★★★★
()
Последнее исправление: annulen (всего исправлений: 1)

Вся автоматическая многопоточность в цепепе ИМХО сделана через жопу.

ox55ff ★★★★★
()
Ответ на: комментарий от vertexua

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

annulen ★★★★★
()
Ответ на: комментарий от annulen

развивать стандарт

Это не «неразвитость», это сознательное решение сделать максимально просто. Многим хватит, другие и так возьмут что-то замороченное.

anonymous
()
Ответ на: комментарий от anonymous

Это не «неразвитость», это сознательное решение сделать максимально просто. Многим хватит, другие и так возьмут что-то замороченное.

До C++11 в стандарте не было кортежей, а только пары. Многим хватало, другие брали boost.

annulen ★★★★★
()
Ответ на: комментарий от annulen

Ошибки в дизайне не так работают. Это не что-то со временем. Это когда делают std::reduce и говорят «готово!»

vertexua ★★★★★
()

@annulen @fsb4000 @ox55ff @vertexua (раз пошла такая пьянка в понедельник вечером): а вы случаем не знаете, как дела с подобным обстоят в современном Фортране? Спрашиваю чисто из любопытства. Говорят, в 2003 стандарте есть некие co-arrays, что это за зверь такой и с чем его едят?

luke ★★★★★
() автор топика
Ответ на: комментарий от luke

_Х_оспаде, да возьмите любой libcxx или std из msvc

и пропачте под себя

закиньте в другой namespace и third-libraries

и юзайте на _с_даровье

anonymous
()
Ответ на: комментарий от anonymous

Я не против того, что он под капотом, но мне нужно ограничить reduce по числу тредов, см. ОП.

luke ★★★★★
() автор топика
Ответ на: комментарий от annulen

Потому то и не доводилось, потому что он умер как сказали выше.

И да, язык может умереть если на нем ещё три калеки пишут

vertexua ★★★★★
()
Последнее исправление: vertexua (всего исправлений: 1)
Ответ на: комментарий от luke

не люблю чувствовать себя попугаем

будем считать - моя твоя не понимать

anonymous
()
Ответ на: комментарий от anonymous

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

dvetutnev
()
Последнее исправление: dvetutnev (всего исправлений: 1)
Ответ на: комментарий от luke

В современном фортране (после 2003) есть почти-что стандартные OpenMP и MPI, и работать с ними достаточно просто. Но это подключаемые библиотеками/модулями.

Я вот в стандарте языка (именно языка) есть как раз co-arrays. Которые предполагают параллелизацию (видимо поверх thread-ов). Но ввиду того что первые две сущности и так весьма просты, я даже палочкой не тыкал.

sshestov ★★
()
Ответ на: комментарий от sshestov

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

Однако по ходу изучения всплывает очень (реально дофига) тонкостей, поэтому рекомендую воспользоваться книгой. Книги есть (в основном англоязычные), но заходит далеко не любая: они там то уж очень базовые вещи объясняют, то воды очень много. Мне нра Илья Чернов «Фортран сегодня» (поиском или могу кинуть ссылку).

sshestov ★★
()
Ответ на: комментарий от vertexua

От них экосистему не дождешься

Там экосистема создавалась десятилетиями, начиная от BLAS и LAPACK. Вычислительная химия до сих пор сидит на фортране, у ФЭЧ до сих пор используется MINUIT и куча Монте Карло генераторов. По счастью всё это в принципе можно дёргать из Си и питона, и проблема тут не в переписывании на плюсах, а в том, что это переписывание не даст ничего нового.

luke ★★★★★
() автор топика
Ответ на: комментарий от sshestov

У меня времени учить новые языки нет, но наверное в следующем семестре я-таки наберусь смелости и схожу на курс LRZ (всё-таки живые люди).

luke ★★★★★
() автор топика
Ответ на: комментарий от annulen

это не повод не развивать стандарт

Они тебя пошлют за выхлопом профайлера в каком месте ты видишь выигрыш от своего частного случая, потом покажут в каком месте ты находишься в очереди самых умных :) Хочешь микроменеджмент потоков? Не используй std или запили свою реализацию СБИШ std::reduce() и покажи им (Или не показывай :) Вдруг они сделают выводы, которые тебе не нравятся)

slackwarrior ★★★★★
()
Последнее исправление: slackwarrior (всего исправлений: 1)
Ответ на: комментарий от luke

Курс выглядит интересно. С другой стороны с фортран очень простой и порог вхождения скорее отрицательный (или даже комплексный). Начать на нем можно практически немедленно, а книгу смотреть когда возникаю вопросы.

sshestov ★★
()
Ответ на: комментарий от sshestov

Я не против книг на самом деле, но наши авторы люди довольно странные.

Кстати, в этой теме по-идее должен быть постоянно обновляемый список ресурсов, надо туда LRZ’товский курс закинуть (и неважно, что я его нашёл через ссылку на фортран вики с лора).

luke ★★★★★
() автор топика

Нету в libstdc++ тред-пулов. Сам на днях охренел. Писать в комитет бесполезно – эти говноделы безнадёжно отстали даже от двадцатилетней давности жавы.

dimgel ★★★★★
()
Ответ на: комментарий от dimgel

треидпулы аля executors только в С++23 хотят успеть

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

умеет ли так ваша Г*** ява? точно не умеет

лучше бы в своей Г**** яве, gc пофиксили, а то как жрала память как не в себе, так до сих пор и жрет, а за окном 21 год

anonymous
()
Ответ на: комментарий от dimgel

Так ладно бы не было, про это же ещё и инфы никакой не найдешь: как будто никому не надо или никто эти reduce не использует.

luke ★★★★★
() автор топика
Ответ на: комментарий от luke

Хм, то конкретное что я находил чёт не вижу. Но по запросу «C++ thread pool» довольно много всякого вылезает. В т.ч. васяновых реализаций – которые были бы не нужны, если бы был стандартный.

Да и зачем тебе ещё доказательства, что стандартных нет: выше ж аноним отписал, что в C++23 пытаются успеть.

dimgel ★★★★★
()
Последнее исправление: dimgel (всего исправлений: 1)
Ответ на: комментарий от luke

А зачем ты вообще хочешь уменьшить количество потоков?

Бред какой-то.

В Windows в std в параллельных алгоритмах и так используется ThreadPool:

CreateThreadpoolWork

SubmitThreadpoolWork

CloseThreadpoolWork

https://docs.microsoft.com/en-us/windows/win32/api/threadpoolapiset/nf-threadpoolapiset-createthreadpoolwork

Без всяких сторонних жирных либ.

Ну и да. std::reduce параллелит без смены кода и на CUDA и на OpenCL и на всё на свете. Там был Vendor Neutrality в приоритете. Nvidia по-моему предложила этот API…

fsb4000 ★★★★★
()
Последнее исправление: fsb4000 (всего исправлений: 1)
Ответ на: комментарий от dimgel

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

luke ★★★★★
() автор топика
Ответ на: комментарий от fsb4000

А зачем ты вообще хочешь уменьшить количество потоков?

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

luke ★★★★★
() автор топика
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.