Linux: процессы и потоки в многоядерном процессоре - PullRequest
5 голосов
/ 03 августа 2010

Правда ли, что потоки по сравнению с процессами с меньшей вероятностью выиграют от многоядерного процессора?Другими словами, примет ли ядро ​​решение о выполнении потоков на одном ядре, а не на нескольких ядрах?

Я говорю о потоках, принадлежащих одному и тому же процессу.

Ответы [ 6 ]

9 голосов
/ 03 августа 2010

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

Таким образом, планировщик может решить запускать потоки процесса на одном и том же процессоре , если есть другие процессы, требующие времени процессора .

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

2 голосов
/ 03 августа 2010

Многопоточность совместно используемой памяти влечет за собой огромные затраты на сложность всего, от цепочки инструментов, до разработки, отладки, анализа и тестирования вашего кода. НИКОГДА не используйте многопоточность совместно используемой памяти, где вы можете разумно использовать многопроцессорное проектирование.

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

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

2 голосов
/ 03 августа 2010

Это новость для меня.В частности, в Linux мало различий между потоками и процессами.На самом деле это просто процессы, которые совместно используют свое адресное пространство.

2 голосов
/ 03 августа 2010

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

1 голос
/ 03 августа 2010

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

Ничего не принимайте, тестируйте, тестируйте, тестируйте!

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

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

Одно можно сказать наверняка: если это система «HyperThreaded», потоки становятся намного более эффективными благодаря тесному совместному использованию памяти.

Если это обычная многоядерная обработка .. она должна быть похожей.

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

Если вы занимаетесь производством HPC (суперкомпьютеров), TEST !.Все зависит от машины (а преимущества составляют в среднем 10-25%, это важно, если вы говорите о днях разницы)

0 голосов
/ 03 августа 2010

В то время как Windows использует волокна и потоки, я иногда думаю, что Linux использует процессы и шпагат. Я обнаружил, что при написании многопоточных процессов вы действительно должны быть строгими, педантичными, дисциплинированными и кровавыми при разработке многопоточных процессов, чтобы они могли достичь баланса в использовании любого количества ядер, доступных на машине что процесс должен продолжаться.

Правда ли, что в Linux потоки по сравнению с процессами с меньшей вероятностью выиграют от многоядерного процессора? Никто не знает.

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