Каково различие между параллельным программированием и параллельным программированием?
Попробуйте это
$(document).ready(function(){
$("button").click(function(){
$("#toggle").toggle();
});
});div {
height:200px;
width:200px;
background-color:red;
}<!DOCTYPE html>
<html>
<head>
<script src="https://ajax.googleapis.com/ajax/libs/jquery/3.3.1/jquery.min.js"></script>
</head>
<body>
<div id="toggle">
</div>
<button>Toggle between hide() and show()</button>
</body>
</html>5 ответов
Если вы программируете с использованием потоков (параллельное программирование), оно не обязательно будет выполняться как таковое (параллельное выполнение), поскольку это зависит от того, может ли машина обрабатывать несколько потоков.
Вот пример наглядный пример. Потоки на однопоточной машине:
-- -- --
/ \
>---- -- -- -- -- ---->>
Потоки на многопоточной машине:
------
/ \
>-------------->>
Штрихи представляют исполняемый код. Как видите, они оба разделяются и выполняются отдельно, но многопоточная машина может выполнять сразу несколько отдельных частей.
Просто совместно использовав пример, который помогает выделить различие:
Параллельное программирование: Говорят, что Вы хотите реализовать алгоритм сортировки с объединением . Каждый раз, когда Вы делите проблему на две подпроблемы, у Вас может быть два потока, которые решают их. Однако, чтобы сделать, слияние ступает, необходимо ожидать этих двух потоков для окончания, так как слияние требует обоих подрешений. Это "обязательное ожидание" делает это параллельной программой.
Параллельная Программа: Говорят, что Вы хотите к сжатие n текстовые файлы и генерируете сжатый файл для каждого из них. Вы можете иметь от 2 (до n) потоки что каждый дескриптор, сжимающий подмножество файлов. Когда каждый поток сделан, он просто сделан, он не должен ожидать или сделать что-либо еще. Так, так как различные задачи выполняются чередованным способом в "любом произвольном порядке" программа, параллельно, но не параллелен.
, Поскольку кто-то еще упомянул, каждая параллельная программа параллельна (должен быть на самом деле), но не наоборот.
Я полагаю Параллельное программирование относится к многопоточному программированию, которое позволяет вашей программе запускать несколько потоков, абстрагированных от деталей оборудования.
Параллельное программирование относится к специальной разработке ваших программных алгоритмов для использования преимуществ доступного параллельного выполнения. Например, вы можете параллельно выполнять две ветви некоторых алгоритмов, ожидая, что результат будет достигнут раньше (в среднем), чем если бы вы сначала проверили первую, а затем вторую ветвь.
Это две фразы, описывающие одно и то же с (очень немного) разных точек зрения. Параллельное программирование описывает ситуацию с точки зрения аппаратного обеспечения - как минимум два процессора (возможно, в одном физическом пакете) работают над проблемой параллельно. Параллельное программирование описывает вещи больше с точки зрения программного обеспечения - два или более действия могут происходить в одно и то же время (одновременно).
Проблема здесь в том, что люди пытаются использовать эти две фразы, чтобы провести четкое различие когда ничего не существует. Реальность такова, что разделительная линия, которую они пытаются провести, десятилетиями была нечеткой и нечеткой, а со временем стала еще более нечеткой.
Они пытаются обсудить тот факт, что когда-то давным-давно, у большинства компьютеров был только один процессор. Когда вы выполняли несколько процессов (или потоков) на одном ЦП, ЦП действительно выполнял только одну инструкцию из одного из этих потоков за раз. Появление параллелизма было иллюзией - ЦП переключался между выполнением инструкций из разных потоков достаточно быстро, чтобы для человеческого восприятия (для которого все, что меньше 100 мс или около того выглядело мгновенно), казалось, что он выполняет много вещей одновременно.
Очевидным отличием от этого является компьютер с несколькими процессорами или процессор с несколькими ядрами, поэтому машина выполняет инструкции из нескольких потоков и / или процессов в одно и то же время; код, выполняющий один, не может / не влияет на выполнение кода в другом.
Теперь проблема: такого четкого различия почти никогда не существовало. Разработчики компьютеров на самом деле довольно умны, поэтому они давно заметили, что (например), когда вам нужно было прочитать некоторые данные с устройства ввода-вывода, такого как диск, это заняло долгое время (в с точки зрения циклов ЦП) до конца. Вместо того, чтобы оставлять ЦП в режиме ожидания, пока это происходит, они придумали различные способы разрешить одному процессу / потоку сделать запрос ввода-вывода и позволить коду из другого процесса / потока выполняться на ЦП, пока запрос ввода-вывода завершен.
Итак, задолго до того, как многоядерные процессоры стали нормой, операции из нескольких потоков выполнялись параллельно.
Но это только верхушка айсберга. Десятилетия назад компьютеры также начали обеспечивать другой уровень параллелизма. Опять же, будучи довольно умными людьми, разработчики компьютеров заметили, что во многих случаях у них есть инструкции, которые не соответствуют действительности. t влияют друг на друга, поэтому можно было выполнять более одной инструкции из одного потока одновременно. Одним из первых примеров, который стал довольно известным, был Control Data 6600. Это был (с довольно большим отрывом) самый быстрый компьютер в мире, когда он был представлен в 1964 году - и большая часть той же базовой архитектуры используется и сегодня. Он отслеживал ресурсы, используемые каждой инструкцией, и имел набор исполнительных модулей, которые выполняли инструкции, как только ресурсы, от которых они зависели, становились доступными, что очень похоже на конструкцию последних процессоров Intel / AMD.
Но (как в рекламе говорили) погоди - это еще не все. Есть еще один элемент дизайна, который добавляет путаницы. Ему дали несколько разных имен (например, «Hyperthreading», «SMT», «CMP»), но все они относятся к одной и той же базовой идее: ЦП, который может выполнять несколько потоков одновременно, используя комбинацию некоторых ресурсов, независимых для каждого потока, и некоторых ресурсов, совместно используемых потоками. В типичном случае это сочетается с описанным выше параллелизмом на уровне команд. Для этого у нас есть два (или более) набора архитектурных регистров. Затем у нас есть набор исполнительных модулей, которые могут выполнять инструкции, как только становятся доступными необходимые ресурсы. Они часто хорошо сочетаются, потому что инструкции из отдельных потоков практически никогда не зависят от одних и тех же ресурсов.
Затем, конечно, мы получаем современные системы с несколькими ядрами. Здесь все очевидно, правда? У нас есть N (где-то от 2 до 256 или около того, на данный момент) отдельных ядер, которые могут выполнять инструкции одновременно, так что у нас есть явный случай реального параллелизма - выполнение инструкций в одном процессе / потоке не влияет на выполнение инструкций в другом.
Ну, вроде того. Даже здесь у нас есть некоторые независимые ресурсы (регистры, исполнительные блоки, по крайней мере один уровень кеш-памяти) и некоторые общие ресурсы (обычно, по крайней мере, нижний уровень кеш-памяти и, безусловно, контроллеры памяти и пропускная способность для памяти).
Подводя итог : простые сценарии, которые люди любят противопоставлять разделяемым и независимым ресурсам, в реальной жизни практически не встречаются. Когда все ресурсы разделены, мы получаем что-то вроде MS-DOS, где мы можем запускать только одну программу за раз, и мы должны остановить выполнение одной, прежде чем мы вообще сможем запустить другую. С полностью независимыми ресурсами, у нас есть N компьютеров под управлением MS-DOS (даже без сети для их подключения), которые не имеют возможности делиться чем-либо между ними вообще (потому что, если мы даже можем поделиться файлом, ну, это общий ресурс, нарушение основной предпосылки ничего не разделяется).
Каждый интересный случай включает некоторую комбинацию независимых ресурсов и общих ресурсов. Каждый достаточно современный компьютер (а многие из них совсем не современные) имеет хотя бы некоторую способность выполнять по крайней мере несколько независимых операций одновременно, и что-то более сложное, чем MS-DOS, воспользовалось этим, чтобы по крайней мере в некоторой степени.
Красивого и четкого разделения на «одновременное» и «параллельное», которое люди любят рисовать, просто не существует и почти никогда не существовало. Что люди любят классифицировать как "параллельные" обычно все еще включает по крайней мере один, а часто и несколько различных типов параллельного выполнения. То, что они любят классифицировать как «параллельный», часто включает в себя совместное использование ресурсов и (например) блокировку выполнения одним процессом другого процесса при использовании ресурса, совместно используемого между ними.
Люди пытаются провести четкое различие между «параллельным» и «параллельным» "живут в фантазиях о компьютерах, которых на самом деле никогда не существовало.
Я понял разницу в следующем:
1) Одновременный - выполняется в тандеме с использованием общих ресурсов 2) Параллельная работа - работа бок о бок с использованием разных ресурсов
Таким образом, вы можете иметь две вещи, происходящие одновременно, независимо друг от друга, даже если они объединяются в точках (2) или две вещи, использующие одни и те же резервы в ходе выполняемых операций (1).