2016-12-16 3 views
0

Представьте, что у меня есть две задачи, каждая из которых требует 2 секунды, чтобы закончить работу.fork vs thread на одном сердечнике

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

Что делать, если я использую fork для создания двух процессов (машина по-прежнему одноядерна), и каждый процесс отвечает за одну задачу? Может ли это сэкономить в любое время?

Если нет, то у меня есть вопрос:

В текущей современной машине (включая многоядерный), если у меня есть несколько тяжелых задач, какой метод следует использовать?

  • fork?
  • нить?
  • fork + thread, что означает создание некоторых процессов и каждый процесс содержит несколько потоков?
+0

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

ответ

0

«занятие занимает 2 секунды». Если эти 2 секунды полностью занимают процессор (100% -ная загрузка), вы ничего не получите ни с нитью, ни с fork, если у вас нет ядер для обмена. Одноядерный процессор просто занят, и вы не можете сделать его более занятым.

В случае, если эти 2 секунды включают в себя время ожидания (например, на вводе/выводе, в хранилище, что угодно), вы могли бы получить что-то, даже с одним ядром. Коэффициент усиления зависит от отношения CPU к процессору и количества ожиданий процессора и накладных расходов на многопроцессорность. Большинство нетривиальных программ имеют как минимум некоторое количество «ожиданий процессора», поэтому многопоточность часто бывает полезной даже для одноядерных процессоров.

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

Традиционно, для потоков, которые раньше были значительно меньше, чем процессы (в конце концов, именно поэтому они были изобретены), но «значительно», возможно, со временем исчезло. В современных Linux-системах процессы лишь чуть медленнее настроены, чем потоки (на самом деле оба используют одни и те же системные вызовы).Вы скорее решаете между потоком или процессом на основе требований, связанных с объемом защиты (или совместного использования) данных, чем скоростью выполнения.

1

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

О fork vs threads, threads требуется меньше ресурсов, поэтому в принципе это должен быть первый выбор. Но есть два оговорки: 1) возможно, вы хотите, чтобы иметь возможность прекратить параллельную процедуру, это гораздо безопаснее делать с процессами, чем с потоками, и 2) некоторые языки (в частности, Python и Ruby) предоставляют библиотеки псевдопотоков, которые не используйте реальные потоки, но переключайтесь между подпрограммами, используя тот же поток. Эта смоделированная потоковая передача может быть очень полезна, например, при ожидании сетевых запросов, но она должна быть принята во внимание, что она не является реальной многопоточной.

Поправка: Как отметил Серхио Туленцев, Ruby и Python действительно обеспечивают настоящие потоки, а не только сопрограммы.

+1

Не знаю о python, но Ruby имеет настоящие потоки уже много лет. –

+0

Да, действительно есть класс Thread в Ruby. Мое предостережение в основном касалось того, как глобальная блокировка интерпретатора может повлиять на параллелизм потоков в Ruby и Python. В чем причина, я думаю, почему так много библиотек для обработки событий async, сопрограммы и т. Д. Для Python есть краткий список параллельных программных инструментов [здесь] (https://wiki.python.org/moin/ Параллелизм /) –

+0

Предлагаю вам изменить свой ответ. Потому что ruby ​​имеет реальные отдельные потоки. Просто они пострадали от GVL. Тем не менее, они не зеленые нити, что совсем другое. –