Какие виды приложений должны быть многопоточными?
Вы можете проверить, есть ли выбор в обработчике событий click:
window.getSelection().toString();
13 ответов
Нет никакого надежного ответа, но большую часть времени Вы не будете видеть преимущества для систем, где рабочий процесс/вычисление последователен. Если однако проблема может быть разломана на задачи, которые могут быть выполнены параллельно (или сама проблема с массовым параллелизмом [как некоторая математика, или аналитические проблемы]), Вы видите большие улучшения.
, Если Ваши целевые аппаратные средства являются единственным процессором/ядром, Вы вряд ли будете видеть любое улучшение с многопоточными решениями (поскольку существует только один поток во время, выполненное так или иначе!)
Пишущий многопоточный код часто более тверд, поскольку Вам, вероятно, придется инвестировать время в создание логики управления потоком.
Некоторые примеры
- Обработка изображений может часто делаться параллельно (например, разделите изображение на 4 и сделайте работу в 1/4 времени), но это зависит от алгоритма, выполняемого, чтобы видеть, имеет ли это смысл.
- Рендеринг анимации (от 3DMax, и т.д.) с массовым параллелизмом, поскольку каждый кадр может быть представлен независимо другим - подразумевать, что 10-е или 100's компьютеров могут быть объединены в цепочку вместе для выручения.
- GUI, программирующий часто, помогает иметь по крайней мере два потока при выполнении чего-то медленного, например, обработке большого количества файлов - это позволяет интерфейсу оставаться быстро реагирующим, пока рабочий делает тяжелую работу (в C#, BackgroundWorker является примером этого)
, GUI является интересной областью, поскольку "скорость отклика" интерфейса может сохраняться без многопоточности, если алгоритм рабочего поддерживает основной GUI путем предоставления ему времени в условиях Windows API (перед.NET, и т.д.) это могло быть достигнуто примитивным циклом и никакой потребностью в поточной обработке:
MSG msg;
while(GetMessage(&msg, hwnd, 0, 0))
{
TranslateMessage(&msg);
DispatchMessage(&msg);
// do some stuff here and then release, the loop will come back
// almost immediately (unless the user has quit)
}
Серверы являются обычно многопоточными (веб-серверы, серверы радиуса, почтовые серверы, любой сервер): Вы обычно хотите быть в состоянии обработать несколько запросов одновременно. Если Вы не хотите ожидать запроса для окончания, прежде чем Вы начнете обрабатывать новый запрос, то у Вас главным образом есть две опции:
- Выполнение процесс с несколькими потоками
- Выполнение несколько процессов
Запуск процесса является обычно более ресурсоемким, чем lauching поток (или выбор того в пуле потоков), таким образом, серверы являются обычно многопоточными. Кроме того, потоки могут связаться непосредственно, так как они совместно используют то же пространство памяти.
проблема с несколькими потоками состоит в том, что их обычно более трудно кодировать прямо, чем несколько процессов.
Существует действительно три класса причин, что многопоточность была бы применена:
- Параллелизм Выполнения для улучшения вычисляют производительность : Если у Вас есть проблема, которая может быть разломана на части, и у Вас также есть больше чем один модуль выполнения (ядро процессора), доступное, тогда диспетчеризация частей в отдельные потоки является путем к способности одновременно использовать два или больше ядра сразу.
- Параллелизм ЦП и Операций IO : Это подобно в размышлении первому, но в этом случае цель состоит в том, чтобы заставить напряженно трудиться ЦП И также операции IO (т.е.: дисковый ввод-вывод) перемещающийся параллельно вместо того, чтобы чередоваться между ними.
- Проектирование программы и Скорость отклика : Много типов программ могут использовать в своих интересах поточную обработку как преимущество проектирования программы для создания программы более быстро реагирующей пользователю. Например, программа может взаимодействовать через GUI и также делать что-то в фоновом режиме.
Конкретные Примеры:
- Microsoft Word: документ Редактирования, в то время как фоновый блок проверки грамматических ошибок и программа проверки правописания работают для добавления всех зеленых и красных подчеркиваний загогулины.
- Microsoft Excel: Автоматические фоновые пересчеты после редактирований ячейки
- веб-браузер : Диспетчеризируйте несколько потоков для загрузки каждой из нескольких ссылок HTML параллельно во время единственной загрузки страницы. Страница скоростей загружает и максимизирует пропускную способность TCP/IP.
В эти дни ответ должен быть Любое приложение, которое может быть .
скорость выполнения для единственного потока в значительной степени достигла максимума несколько лет назад - процессоры становились быстрее путем добавления ядер, не путем увеличения тактовых частот. Были некоторые архитектурные улучшения, которые лучше используют доступные такты, но действительно, будущее использует в своих интересах поточную обработку.
существует тонна исследования, продолжающегося в то, чтобы находить способы параллелизации операций, что мы традиционно не думали бы о параллелизации. Даже что-то столь же простое как нахождение подстроки в строке может быть параллелизировано.
В основном существует две причины мультираспараллелить:
-
, Чтобы быть в состоянии сделать задачи обработки параллельно. Это только применяется, если у Вас будет несколько ядер/процессоров, иначе на одноядерном / компьютере процессора Вы замедлите задачу по сравнению с версией без потоков.
-
ввод-вывод, ли это быть сетевым вводом-выводом или файловым вводом-выводом. Обычно при вызове блокирующегося вызова ввода-вывода процесс должен ожидать вызова для завершения. Так как процессор/память является несколькими порядками величины, более быстрыми, чем дисковод (и сеть еще медленнее), это означает, что процессор будет ожидать долгое время. Компьютер будет работать над другими вещами, но Ваше приложение не будет делать успехов. Однако, если у Вас будет несколько потоков, компьютер запланирует Ваше приложение, и другие потоки могут выполниться. Одно общее использование является приложением GUI. Тогда, в то время как приложение делает ввод-вывод, поток GUI может продолжать обновляться, экран, не будучи похож на приложение замораживается или не ответ. Даже на единственном вводе-выводе помещения процессора в различном потоке будет иметь тенденцию ускорять приложение.
единственная потоковая альтернатива 2 должна использовать асинхронные вызовы, куда они сразу возвращаются, и Вы продолжаете управлять своей программой. Тогда необходимо видеть, когда ввод-вывод завершается, и справьтесь с использованием его. Часто более просто только использовать поток, чтобы сделать ввод-вывод с помощью синхронных вызовов, поскольку они имеют тенденцию быть легче.
причина использовать потоки вместо отдельных процессов состоит в том, потому что потоки должны быть в состоянии обменяться данными легче, чем несколько процессов. И иногда переключение между потоками является менее дорогим, чем переключение между процессами.
Как другое примечание, для № 1 потоки Python не будут работать, потому что в Python только одна инструкция по Python может быть выполнена за один раз (известный как GIL или Глобальная Блокировка Интерпретатора). Я использую это в качестве примера, но необходимо проверить вокруг языка. В Python, если Вы хотите сделать параллельные вычисления, необходимо сделать отдельные процессы.
Много платформ GUI являются многопоточными. Это позволяет Вам иметь более быстро реагирующий интерфейс. Например, можно нажать на кнопку "Cancel" в любое время, в то время как долгое вычисление работает.
Примечание, что существуют другие решения для этого (например, программа может приостановить вычисление каждая половина секунды, чтобы проверить, нажали ли Вы на Кнопку отмены или не), но они не предлагают того же уровня скорости отклика (GUI, могло бы казаться, заморозился бы в течение нескольких секунд, в то время как файл читается или сделанное вычисление).
Все ответы до сих пор фокусируются на том, что многопоточность или многопроцессорная обработка необходимы для лучшего использования современные аппаратные средства.
существует однако также то, что многопоточность может сделать жизнь намного легче для программиста. На работе я программирую программное обеспечение для управления технологическим оборудованием и испытательным оборудованием, где единственная машина часто состоит из нескольких положений та работа параллельно. Используя несколько потоков для такого программного обеспечения естественное соответствие, поскольку параллельные потоки моделируют физическую действительность вполне хорошо. Потоки не должны главным образом обмениваться никакими данными, таким образом, потребность синхронизировать потоки редка, и многие причины многопоточности, являющейся трудным, поэтому не применяются.
Редактирование:
Это не действительно о повышении производительности, как (возможно, 5, возможно, 10), потоки все главным образом спят. Это - однако огромное улучшение для структуры программы, когда различные параллельные процессы могут быть кодированы как последовательности действий, которые не знают друг о друге. У меня есть очень плохие памяти со времен Windows на 16 битов, когда я создал бы конечный автомат для каждого положения машины, удостоверьтесь, что ничто не заняло бы больше времени, чем несколько миллисекунд, и постоянно передавать управление к следующему конечному автомату. Когда были аппаратные события, которые должны были быть обслужены вовремя, и также вычисления, которые требовали времени (как FFT), тогда вещи станут ужасными очень быстро.
Не непосредственно отвечая на Ваш вопрос, я верю в самое ближайшее будущее, почти каждое приложение должно будет быть многопоточным. Производительность ЦП не выращивает тот быстро в эти дни, который компенсируется растущее число ядер . Таким образом, если мы захотим, чтобы наши приложения остались на мудрой производительностью вершине, мы должны будем найти способы использовать центральные процессоры всего Вашего компьютера и заставить их напряженно трудиться, который является настоящей трудной работой.
Это может быть сделано через сообщение Ваших программ, что сделать вместо того, чтобы говорить им точно как. Теперь, это - тема, которую я лично нахожу очень интересными недавно. Некоторые функциональные языки, как F#, в состоянии параллелизировать много задач довольно легко. Ну, не, ЧТО легко, но все еще без необходимой инфраструктуры необходим в большем количестве сред процедурного стиля.
возьмите это в качестве дополнительной информации для размышления о, не попытка ответить вопрос.
Вид приложений, что потребность для поточной обработки те, где Вы хотите сделать больше чем одну вещь сразу. Кроме того никакого приложения должно быть многопоточным.
Приложения с большой рабочей нагрузкой, которая может быть легко сделана параллельной. Трудность взятия Вашего приложения и выполнения, которое не должно быть недооценено. Легко, когда Ваши данные, которыми Вы управляете, не зависят от других данных, но v. трудно для планирования перекрестной работы потока, когда существует зависимость.
Некоторые примеры я сделал, которые являются хорошими многопоточными кандидатами..
- под управлением сценарии (например, оценка производной запаса, статистика)
- объемные файлы данных обновления (например, добавление значения / запись в 10 000 записей)
- другие математические процессы
Например, Вы хотите, чтобы Ваши программы были многопоточными, когда Вы хотите использовать несколько ядер и/или центральных процессоров, даже когда программы не делают обязательно , делают много вещей одновременно.
РЕДАКТИРОВАНИЕ: использование нескольких процессов является тем же самым. Какая техника использовать зависит от платформы и как Вы собираетесь сделать связь в рамках своей программы, и т.д.
Хотя несерьезный, игры, в целом становятся более потоковыми каждый год. На работе наша игра использует приблизительно 10 потоков, делающих физику, AI, анимацию, redering, сеть и IO.
Просто хочу добавить, что осторожность должна быть взята с шагами, если Ваше совместное использование каких-либо ресурсов, поскольку это может привести к некоторому очень странному поведению, и Вашему коду, не работающему правильно или даже потокам, блокирующим друг друга.
взаимное исключение поможет Вам там, поскольку можно использовать взаимоисключающие блокировки для защищенных регионов кода, пример защищенных регионов кода читал бы или записал бы в общую память между потоками.
просто моя ценность за 2 цента.