Есть ли смысл создавать потоки количество которых больше чем количество ядер процессора?

Сабж. Есть ли смысл? Ведь одновременно одно ядро процессора не может выполнять более одной задачи (а поток это задача)

0

Сообщение от ct0r тебе стоит почитать про то, что такое concurrency, а что такое parallelism, зачем они нужны и чем отличаются.

Про это читал, но к какой составляющей именно ты клонишь не могу понять

Сообщение от ct0r green threads.

Это вроде только в виртуальных машинах есть, а в си нет виртуальной машины (тема изначально была создан в разеделе Си)

Сообщение от ct0r Принять к сведению существование hyper-threading technology

Нашел информацию. Но эта технология только у intelовских процессоров и судя по всему логический процессор все равно не может параллельно выполнить 2 потока

Добавлено через 1 минуту
Выходит 1 ядро = 1 поток идеальный вариант

0

Сообщение от sys_beginner Выходит 1 ядро = 1 поток идеальный вариант

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

Вполне может получиться так, что 3 потока работают быстрее, чем 4. Такая ситуация будет скорее исключением, чем правилом, но при определённых раскладах она может случиться и при проектировании программы нужно иметь её в виду

0

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

Кеш насколько мне известно вышибается при переключении контекста, что фактически неизбежно

0

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

Поведение кэша зависит исключительно от того, по каким адресам в память идут запросы. Чем больше покрытие по адресам (при суммарном объёме, превышающем размер кэша), тем чаще будет инвалидация. И проблема с потоками может в некотором пограничном случае. Допустим, у на 6 мегабайт кэша. Каждый их потоков активно использует память в количестве 2 мегабайт. При трёх работающих потоков постоянно активными должны быть 6 мегабайт и они уместятся в кэше. А при четырёх потоках активными должны быть 8 мегабайт, и при таком раскладе данные из кэша постоянно будут вытравливаться, что может весьма значительно повлиять на производительность

0

Сообщение от sys_beginner Про это читал, но к какой составляющей именно ты клонишь не могу понять

К тому, что если у тебя одно ядро, но нужно одновременно что-то считать, скачивать из интернета, отвечать на запросы пользователя, то как думаешь, "есть ли смысл создавать потоки количество которых больше чем количество ядер процессора?"

Сообщение от sys_beginner логический процессор все равно не может параллельно выполнить 2 потока

Логический не может, физический может.

0

Сообщение от ct0r К тому, что если у тебя одно ядро, но нужно одновременно что-то считать, скачивать из интернета, отвечать на запросы пользователя, то как думаешь, "есть ли смысл создавать потоки количество которых больше чем количество ядер процессора?"

В плане расчета на их параллельное выполнение - думаю нет

Сообщение от ct0r Логический не может, физический может.

Как так? Одно ядро ведь не может параллельно выполнять 2 потока

0

Сообщение от sys_beginner В плане расчета на их параллельное выполнение

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

Сообщение от sys_beginner Как так? Одно ядро ведь не может параллельно выполнять 2 потока

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

1

Сообщение от ct0r В том и дело, что тут параллельность не нужна, а нужна конкуррентность, поэтому естественно нам нужно несколько потоков чтобы решить задачу, даже если ядро у нас одно.

Это да.

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

Это очевидно. Но не думаю что такое поведение проявляется всегда. Наверное зависит от того насколько эффективно задание использует процессорное время и у кого какие приоритеты

0

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

Сие возможно только для hyperthreading. Поэтому вам двоим прежде чем спорить, надо определиться с терминологией. sys_beginner под "ядром" понимает простое ядро, а ct0r - ядро с hyperthreading'ом

0

Возвращаясь к истокам

Сообщение от sys_beginner Ведь одновременно одно ядро процессора не может выполнять более одной задачи (а поток это задача)

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

Именно в этом все дело. Провозгласить идеальную архитектуру (число ниток = числу ядер + (может) 1) очень легко - но реализовать ее нередко столь же трудно, т.к. все заботы по "кормлению ниток задачами" ложатся на программиста. Если "любая нитка выполняет любую задачу", то надо предусмотреть что напр "задача 2" не должна выполняться до того как закончилась "задача 1". А если напр появилась "задача 10" то она должна быть выполнена как можно быстрее, ее приоритет максимальный и.т.д.

Распределение задач по ниткам часто резко упрощает логику, но увы, часто в ущерб производительности. А примитивное "заводим нитку на каждую задачу" быстро заводит в тупик и (справедливо) осуждается.

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

1

Согласен с предыдущим оратором. 99% задач обладают свойством того, что подзадачи НЕ сбаллансированы. А потому простые варианты типа распихать каждую подзадачу в отдельный поток не дадут предельной производительности, т.к. потоки будут исполняться разное время. Но такие варианты будут быстрее последовательного исполнения при более-менее правильном разбитии на потоки. Т.е. если программист понимает, что 2+3 вычислять в отдельном потоке слишком накладно

0

Я на вычислительных задачах типа перемножения матриц получал (почти) четырёхкратное ускорение на двух-ядерном процессоре с гипер-трейдингом.

0

Перемножение матриц - сбаллансированная задача. В том смысле, что при распараллеливании потоки получают одинаковую нагрузку. Но далеко не не все задачи обладают таким свойством. Двумя постами выше я сказал, что 99% задач не такие - тут я явно погорячился, написав цифру в 99%

Добавлено через 1 минуту

Сообщение от Shamil1 получал (почти) четырёхкратное ускорение на двух-ядерном процессоре с гипер-трейдингом

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

Добавлено через 3 минуты


Добавлено через 1 минуту

1

Сообщение от Igor3D А примитивное "заводим нитку на каждую задачу" быстро заводит в тупик и (справедливо) осуждается.

А в чем тупик? Можно создать тредпул куда помещать задачи и треды готовые их выполнить, не вижу никаких проблем. При наличии задачи, тред который освободился хватает следующую задачу. Что тут осудительного и что предлагается в замен?

Добавлено через 5 минут

Сообщение от Igor3D Если "любая нитка выполняет любую задачу", то надо предусмотреть что напр "задача 2" не должна выполняться до того как закончилась "задача 1". А если напр появилась "задача 10" то она должна быть выполнена как можно быстрее, ее приоритет максимальный и.т.д.

В таком случае да, немного сложно. Но если нет ухищрений с приоритетами то думаю особых проблем возникать не должно

0

Сообщение от sys_beginner А в чем тупик? Можно создать тредпул куда помещать задачи и треды готовые их выполнить, не вижу никаких проблем. При наличии задачи, тред который освободился хватает следующую задачу. Что тут осудительного и что предлагается в замен?

Так это и не тот вариант что осуждается.

Сообщение от sys_beginner В таком случае да, немного сложно. Но если нет ухищрений с приоритетами то думаю особых проблем возникать не должно

Проблемы найдут Вас сами Напр "схватила" нитка задачу - ну как минимум надо определить тип задачи и получить "контекст", т.е. связанные с задачей данные. При этом весьма вероятно что контекст используется и др нитками. Часто нужно приостановить выполнение какой-то задачи, потом продолжить или вообще отменить и.т.п. - все это "само по себе" не сделается. В общем, начнете делать - увидите

0

Сообщение от Igor3D При этом весьма вероятно что контекст используется и др нитками.

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

0