Есть ли преимущество от выполнения задачи в двух потоках на одном ядре?

Question

[footballer]

Дано: есть задача, состоящая из двух несвязанных подзадач. Есть одноядерный проц. И 2 варианта решения задачи:
1) написать прогу (одну функции), решающую сначала подзадачу 1, а потом подзадачу 2, друг за другом последовательно в одном потоке.
2) написать прогу из двух функций, каждая функция будет решать свою подзадачу, и вызвать эти функции одновременно, то есть создав для выполнения каждой отдельный поток и запустив параллельное выполнение.

Вопрос: в каком случае вся задача (обе подзадачи) целиком будет решена быстрее?

UPDATE: дополнительные вопросы:
1) professorweb.ru/my/csharp/thread_and_files/1/1_16.php

Значение максимально допустимого количества потоков в пуле может изменяться. В случае двуядерного ЦП оно по умолчанию составляет 1023 рабочих потоков и 1000 потоков ввода-вывода.

Для чего на двухъядерном проце 2023 потока?

2) regfordev.blogspot.ru/2010/12/thread-pool.html

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

Увеличение числа ядер в системе аналогично увеличению числа участников, так как задачи будут делиться на более мелкие кусочки и вследствие частого обращения в глобальную очередь – увеличится необходимость в синхронизации.

Не понял, "С добавлением большего числа ядер задачи начинают делиться на более мелкие кусочки" - это как? Вот у меня есть задача, которую моя прога выполняет в одном потоке. Если я запущу свою прогу на многоядерном проце, то моя задача поделится на много кусков? Каким образом? Она же однопоточная.

Comments

[sim3x]

Какой именно задачи?

[footballer]

sim3x,
Я не знаю, какой именно. Абстрактной задачи. Не важно какой. Ну, допустим, каждая подзадача должна прочитать и обработать сложными математическими операциями каждый элемент из огромного массива данных.

[sim3x]

footballer, важно
Только тип задачи важен

cpu-heavy задачи нет смысла разделять по потокам, даже при наличии hyper-threading, тк переключние между задачами будет занимать много времени и ресурсов
Задачи, которые в основном ждут данных, - имеет смысл

[footballer]

Вообще, в начале этого века почти все компы были одноядерными. Но программы уже были многопоточными (в диспетчере задач вин хр можно было увидеть кол-во потоков, создаваемых процессами, многие процессы создавали кучу потоков, для чего?).
Или вот, например, я пишу прогу на C# WCF, запускаю несколько сервисов, каждый из них создает себе отдельный поток, кроме этого еще какие-то дополнительные потоки возникают (в окне Threads показывается потоков даже больше, чем сервисов), в итоге у меня прога запускает кучу потоков. Для чего запускать кучу потоков, если у меня двухядерный проц?
Я понимаю, когда второй поток нужен, чтобы запускать код, который обрабатывает движение мыши, чтобы была возможность отлавливать клики и т.п., а в фоне что-то полезное рассчитывать. Но в WCF-проекте на моем двухъядерном проце все-равно больше двух потоков одновременно не выполнятся, и даже если куча клиентов одновременно запросят все мои сервисы, то их код не будет выполняться параллельно, а просто выполнение одного будет прерываться выполнением другого и т.д., что, как я понимаю, не ускорит никаких откликов для клиентов, а наоборот затормозит отклики каждому клиенту.

[Roman]

Попробуйте написать 2 бесконечных цикла и запустить их в 2 потока на одном ядре)

[footballer]

sim3x,
>Задачи, которые в основном ждут данных, - имеет смысл

Объясните, как на низком уровне потоки "ждут данных". И почему много потоков, запущенных на "ждание данных", всегда лучше и быстрее, чем если бы все ждали данные в одном потоке.

[footballer]

Роман,

Попробуйте написать 2 бесконечных цикла и запустить их в 2 потока на одном ядре)

что это должно показать?

[sim3x]

footballer, iowait, network wait

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

[footballer]

sim3x,

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

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

Answer 1

[d'Ivan]

По-моему, 1-й вариант будет быстрее, так как не будет тратиться время на переключение контекста. Так что преимущества может не быть, если говорить о некой абстрактной вычислительной задаче. Но на практике ускорение может быть, когда есть работа с сетью или накопителями данных.
Это моё предположение.

Comments

[footballer]

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

Вот тут https://habrahabr.ru/post/109705/ в комменте пишут:

У сервера есть 1000 клиентов и на каждого из них при его запросе будет открыватся асинхронная операция — либо паралельные вычисления либо I/O. И мы очень легко получим это «исчерпение». Но для такого сервера нужно лимитировать число одновременных клиентов для которых запускаются асинхронные операции. Т.е. для 1000 клиентов к примеру открываем, остальные будут ждать.

Для чего выполнять параллельные вычисления в 1000 параллельных потоках, если проц 1-2-х ядерный? Вы же вот выше написали, что в вычислительных задачах преимущества может не быть. Почему тогда юзер в том комменте пишет про то, что нужно лимитировать именно 1000, а не кол-вом ядер?
Или он еще пишет про I/O , но ведь чтение данных жестким диском всегда последовательное, то есть нельзя одновременно читать данные с двух мест. Снова не вижу смысла открывать 1000 потоков на I/O (чтение\запись на диск).

Answer 2

[Александр Юдаков]

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

Главный постулат в работе над повышением производительности: MOM — measure, optimize, monitor.