Распределенные вычисления против потоков

Question

Насколько похожи распределенные вычисления и многопоточность? Я нашел две статьи, которые приходят к совершенно противоположным выводам:

" Многопоточность проще, чем работа в сети. Как многопоточность проста и похожа на сетевой код "

http://software.intel.com/file/14723

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

" заметка о распределенных вычислениях "

http://research.sun.com/techrep/1994/abstract -29.html

(и это сильно отличает)

Я уверен, что истина где-то посередине. Что золотая середина? Существуют ли технологии, которые объединяют эти две парадигмы? Или такие попытки потерпели неудачу из-за фундаментальных различий между сетью и параллелизмом?

Answer 1

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

Каждый узел обычно будет выполнять некоторую обработку, и должен быть какой-то тип связи между узлами. Обычно первый экземпляр этого сообщения сообщает узлу, что делать. Для этой связи я могу использовать общую память, семафоры, общие файлы, именованные каналы, сокеты, удаленные вызовы процедур, распределенный COM и т. Д. Но самые простые в использовании, общая память и семафоры, обычно недоступны по сети. Общие файлы могут быть доступны, но производительность, как правило, низкая. Сокеты, как правило, являются наиболее распространенным и наиболее гибким выбором в сети, а не более сложными механизмами. На этом этапе вам придется разобраться с деталями сетевой архитектуры, включая задержку, пропускную способность, потерю пакетов, топологию сети и многое другое.

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

В общем, я обнаружил, что люди, занимающиеся этим типом параллельной архитектуры, склонны выбирать смущающие параллельные задачи для решения. Raytracing приходит на ум. Не требуется много связи между узлами, кроме распределения работы. Конечно, есть много подобных проблем, но я нахожу немного неискренним, чтобы предположить, что распределенные вычисления - это то же самое, что и многопоточность.

Теперь, если вы собираетесь писать потоки, которые ведут себя одинаково в распределенной системе, используя чистую передачу сообщений и не предполагая, что какой-либо поток является «основным». один и такой, тогда да, они будут очень похожи. Но вы сделали вид, что у вас есть распределенная архитектура и реализовали ее в потоках. Дело в том, что многопоточность является гораздо более простым случаем параллелизма, чем истинно распределенные вычисления. Вы можете абстрагировать их в одну проблему, но выбрав более сложную версию и строго придерживаясь ее. И результаты не будут такими хорошими, как могли бы быть, когда все узлы локальны для машины. Вы не пользуетесь особым случаем.

Answer 2

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

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

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

Answer 3

Кажется, что разница возвращается в общее состояние потоков, процессы передают сообщения.

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

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

Передача сообщений (например, Erlang) требует другого подхода к проектированию, вы должны думать о возможностях параллелизма с самого начала, но состояние каждого распределенного процесса изолированно, что облегчает решение проблем блокировки / гонки.

Answer 4

Я думаю, что гораздо полезнее сравнивать процессы с подходами распределенных вычислений, чем сравнивать потоки с ним. Потоки существуют внутри одного процесса и используют одни и те же данные и одну и ту же память. Это невозможно на нескольких машинах. Процессы, с другой стороны, имеют собственную память, хотя в некоторых случаях они содержат точно такие же данные, что и другой процесс (например, после fork ()). Это может быть достигнуто через сеть.

К этой аналогии придает дополнительный вес тот факт, что многие инструменты, используемые для межпроцессного взаимодействия, прозрачны для сети. Хорошим примером могут служить сокеты Unix, которые используют тот же интерфейс, что и сетевые сокеты (за исключением кода подключения).

Answer 5

Да, во время разработки подход очень похож, но использование каждого очень разное. Я не совсем ясно представляю вашу идею, дайте мне знать, если я ошибаюсь: когда речь идет о распределенных вычислениях, мы предполагаем, что несколько компьютеров или серверов обрабатывают код в одном приложении, но когда мы говорим о многопоточности, мы речь идет об одновременной обработке разных потоков приложения на одном компьютере. Вы можете представить пример распределенных вычислений, когда одно приложение обращается к веб-службе, расположенной в Интернете. В одном приложении работают два разных компьютера.

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

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

Answer 6

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

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

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