Количество доступных потоков pthread

Нужно попробовать создать, сколько получится.

Теоритически: free RAM / thread stack size.

Не делайте так, это опасно! Во всем мире можно создать 2^64 потоков. Бездумно создавая потоки, вы лишатете остальных пользователей возможности создавать потоки и приближаете конец света! Приблизительно в 2038-м году все потки будут использованы, и компьютеры перестанут рабоать. Только те, программы, которые не используют потоки выживут!

Церковь адвентистов последнего потока?

Где кнопка «лайк»?

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

а как же hyperthreading & GPU?

При чем здесь GPU, когда речь идёт о pthread?

hyperthreading-ом я бы не стал топикстартеру голову забивать, раз он пока ещё такие вопросы спрашивает. Опять же, Дреппер про HT 10 лет назад писал нелестно в своём трактате, изменилось ли что-нибудь принципиально за эти 10 лет?

Создавай пул задач из 4-8 потоков (сколько там железо поддерживает кароч. В линуксах можно узнать с помощью sysconf(_SC_NPROCESSORS_ONLN) + нужно позаботиться о CPU affinity чтобы потоки чётенько легли на ядра). Добавляй таски в пул через очередь (tbb::concurent_queue можно взять, например), и дело сделано (не совсем, нужно еще позаботиться о синхронизациях, но это уже как-нибудь сам разберешься). Создав сотню потоков, помимо того, что ты весь стэк забьешь, твой CPU будет в основном переключать контексты с одного потока на другой.

[offtopic trollmode]
Можешь попробовать DragonflyBSD или старую солярку. Там потоки к железу индифферентны
[/offtopic trollmode]

hyperthreading-ом я бы не стал топикстартеру голову забивать, раз он пока ещё такие вопросы спрашивает. Опять же, Дреппер про HT 10 лет назад писал нелестно в своём трактате, изменилось ли что-нибудь принципиально за эти 10 лет?

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

Это только если параллелишь что-то. А бывают еще КА, где каждый автомат — отдельный поток. Ну или обслуживание веб-клиентов демоном: у меня, например, основной процесс сразу порождает поток, тупо открывающий сокет и ждущий соединений. Как присоединился кто-то, запускается отдельный поток, работающий с клиентом и взаимодействующий через те или иные IPC с основным потоком.

Кстати, может ТСу будет полезно: определение количества ядер при помощи cmake. Аналогичную штуку можно и в Makefile сделать, но я обычно чистый make только на чем-нибудь совсем простом использую, где нет 100500 зависимостей.

Я в cmake не силен, но в make можно просто использовать что-то вроде:

N := $(shell getconf _NPROCESSORS_ONLN)

определение количества ядер при помощи cmake

Какой странный подход. Число CPU определяется на машине, где софт собирается, а не на машине, на которой он исполняется. И главное, зачем? OpenMP самостоятельно определяет максимальное число потоков. Если хочется его ограничить, это можно сделать либо функцией его API, либо через переменную окружения.

Ух, ē-моē! Я не знал про getconf!

Спасибо!

Число CPU определяется на машине, где софт собирается, а не на машине, на которой он исполняется

Это что за деление на нуль? У меня гента, да и вообще, даже если не гента, мой софт собирается на той же машине, где будет исполняться! Я не маюсь дурью с перетаскиванием бинарников!

OpenMP самостоятельно определяет максимальное число потоков

Где про это почитать? Я не нашел.

Это что за деление на нуль? У меня гента, да и вообще, даже если не гента, мой софт собирается на той же машине, где будет исполняться! Я не маюсь дурью с перетаскиванием бинарников!

Ага, и программки с использованием OpenMP с бекендом на CUDA будут использовать 8 потоков на GPU, потому что на хосте 8 ядер. Ну круто, чё.

Где про это почитать? Я не нашел.

Например, вот тут: https://gcc.gnu.org/onlinedocs/libgomp/OMP_005fNUM_005fTHREADS.html

В спеке написано, что это implementation defined.

А бывают еще КА, где каждый автомат — отдельный поток.

Если у тебя есть КА, то ему уже не надо быть отдельным потоком ;-)

Это что за деление на нуль? У меня гента, да и вообще, даже если не гента, мой софт собирается на той же машине, где будет исполняться! Я не маюсь дурью с перетаскиванием бинарников!

Гента, это видимо диагноз такой.

использовать 8 потоков на GPU, потому что на хосте 8 ядер

Ничего подобного! Это — для openmp, а для куды у меня cmake собирает тестилку, которая проверяет параметры видюхи и жестко их вкорячивает в исходники #define'ами. Но, в принципе, то же самое можно и при запуске делать во время инициализации. Аналогично и с количеством ядер CPU.

Например, вот тут: https://gcc.gnu.org/onlinedocs/libgomp/OMP_005fNUM_005fTHREADS.html

Про это я и так знаю: я таким образом и задаю количество потоков. Ты мне говорил, что openmp знает, сколько у меня ядер CPU!

If undefined one thread per CPU is used.

А это точно не DoS?

Учитывая, что PIDы конечны, тот ещё DoS :)

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

Бонусные баллы за удаление последнего лимита, в ядре. Дополнительные бонусные баллы за удаление лимита в стоковом ядре, на ходу.

Володя, это ты с потоками в астрале перепутал :)

Можешь попробовать DragonflyBSD или старую солярку. Там потоки к железу индифферентны

Даже к количеству доступной памяти?

Ну и нафиг мне один поток на камень, если камень у меня один, но в нем 8 ядер?

32768 - 300 -> практический лимит.
300 минимальный пид который может получить обычный процес. Не помню откуда его считать... Кароче ulimit -u

Ну и нафиг мне один поток на камень, если камень у меня один, но в нем 8 ядер?

Знаешь, твои сообщения не смешные, это уже глупо.

Во-первых, термин CPU имеет несколько значений. То, что ты называешь «камень», называют CPU package. В нём может быть одна или несколько пластинок. На каждой пластинке может быть несколько ядер, каждое из которых может иметь несколько «железных» потоков исполнения. Всё может быть ещё сложнее устроено, например SMT на стероидах, как в «бульдозерах» от AMD, где непонятно, считать ли пару таких блоков ядром или это два ядра. Некоторые могут под CPU понимать один package. Некоторые — одно ядро. Некоторые — какой-нибудь модуль, на котором сразу несколько package смонтировано. А ещё раньше наверняка были системы, в которых CPU состоял из нескольких микросхем. По отдельности ни одна из них не была CPU, а вот вместе — да.

Это со стороны железа. А со стороны софта CPU сейчас это обычно то, что может исполнять инструкции (не встречал ничего другого). Если у тебя железка, в которой один package с четыремя ядрами, каждое из которых может исполнять одновременно два потока, в /proc/cpuinfo будет 8 блоков. Даже в доках OpenMP от GCC понятие CPU используется как нечто, к которому можно привязать поток исполнения (affinity).

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

32768

Можно увеличить: /proc/sys/kernel/pid_max.

Вопрос не стоит «как увеличить». Вопрос стоит «узнать максимальное количество»...

Оморош дотролился до 4х звезд и до сих пор не забанен? :}

Если у тебя каждый поток занимается вычислениями, а не висит на памяти или другом IO, то HT будет мешать

Т.е. ничего не изменилось, чтд

GPU ты вне потоков будет загружать работой?

до сих пор не забанен? :}

Это временно.

Разблокирован  JB 17.08.15 08:50 Заблокирован  JB Причина: троллинг 08.07.15 10:46

Т.е. ничего не изменилось, чтд

HT для того и создавался же ну.

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

Где почитать о нагруженных вычислениях ( не так уж что бы в турбо-подробностях ) , но основные аспекты написаны. погуглю конешно, но от лишней ссылки не откажусьбб

Правильно понимаю , что для того что бы достичь максимальной вычислительной мощности(БЕЗ GPU) нужно использовать потоков=ядер.

Вот кстати HT будет мешать как раз таки если потоки висят на памяти, LLC же шареный и условно делится из-за пополам (собственно, об этом и писалось в Писании).

https://software.intel.com/en-us/articles/parallel-programming-books

Сам не читал, но рекомендую (хотя бы книжку с гусями ,про structured parallel programming).

Ну, тут уел!

Пруфы есть? В рендерах 4ядра с ht сравнимы(быстрее если частота выше) 6ядер без ht.

Пруфы вот: https://www.akkadia.org/drepper/cpumemory.pdf

Прозреваю, что рендеры твои cpu-bound и ессно в таком случае ht helps

Объясни тогда, зачем на SO куча тем о том, как определить на стадии компиляции или стадии исполнения, сколько ядер в системе, если, как ты говоришь, это тупо автоматом будет сделано?

Объясни тогда, зачем на SO куча тем о том <...>

Это SO. Там всегда куча тем. Обо всём.

И почему-то ни в одной не нашлось того, кто подсказал бы, что ничего делать не надо — pthreads самостоятельно оптимальное количество потоков выделит!

pthreads самостоятельно оптимальное количество потоков выделит!

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

Речь же шла про OpenMP. Там в явном виде треды создавать не нужно. Реализация сама решит, сколько стоит создать. Или даст пользователю подтюнить через переменные среды, если нужно. Хардкодить число потоков внутри своей программы — вредно. Разве что ты точно знаешь, что выбранное тобой значение лучше, чем то, что выберет конкретная реализация.

Когда я впервые с openmp столкнулся, такой фичи не было. Явно она появилась не так давно! Иначе не пришлось бы выдумывать, как определить количество ядер CPU.

Когда я впервые с openmp столкнулся, такой фичи не было. Явно она появилась не так давно!

Первый релиз GCC с OpenMP был 4.2.4, который релизнулся 19 мая 2008 года. И там уже было в доках написано: https://gcc.gnu.org/onlinedocs/gcc-4.2.4/libgomp/OMP_005fNUM_005fTHREADS.html

Может, ты какой-то другой реализацией пользовался?

Нет, той же. Но, задавшись вопросом, как оптимальное количество потоков определить, нагуглил кучу заметок на SO. А вот документацию (конкретно эту часть) не нагуглил!

Вот, кстати, не помню насчет gcc-4.2.4, но что-то мне сдается, что еще году в 2014 я пользовался версией 4.6.