Параллельное кодирование По сравнению с Многопоточностью (на единственном CPU)

В некоторых демонстрациях, которые я видел в .NET 4.0, изменения параллельного кода кажутся проще, чем выполнение потоков. Для поддержки параллельной обработки появился новый синтаксис для циклов For Loops и прочего. Так что есть разница.

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

После некоторой настройки и большого количества усилий, вероятно, можно заставить gcc скомпилировать ваш Obj -C исходный код на Ubuntu в двоичную форму, которая будет совместима с процессором iPhone ARM. Но это не может считаться «разработкой приложений для iPhone», потому что у вас не будет доступа ко всем проприетарным API iPhone (всем материалам Cocoa).

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

Кроме того, вы не сможете протестировать свой код, так как это не симулятор iPhone с открытым исходным кодом ... может быть, вы могли бы что-то сделать с qemu, но опять же , впереди много усилий для небольшого результата. Я предлагаю вам не торопиться и начать учиться с основ. Поймите, ПОЧЕМУ многопоточность становится важной, в чем разница между процессами, потоками и волокнами, как вы синхронизируете один из них и т. Д.

Имейте в виду, что параллельное кодирование, как вы его называете, довольно сложно, особенно по сравнению с последовательное кодирование, так что будьте готовы. Также не торопитесь. Тот факт, что вы используете 3 потока вместо одного, не ускорит вашу программу, а может даже сделать ее медленнее. Вы должны понимать, как и почему. Не все можно сделать параллельным, и все, что можно, должно быть.

Имейте в виду, что параллельное кодирование, как вы его называете, довольно сложно, особенно по сравнению с последовательным кодированием, так что будьте готовы. Также не торопитесь. Тот факт, что вы используете 3 потока вместо одного, не ускорит вашу программу, а может даже сделать ее медленнее. Вы должны понимать, как и почему. Не все можно сделать параллельным, и все, что можно, должно быть.

Имейте в виду, что параллельное кодирование, как вы его называете, довольно сложно, особенно по сравнению с последовательным кодированием, так что будьте готовы. Также не торопитесь. Тот факт, что вы используете 3 потока вместо одного, не ускорит вашу программу, а может даже сделать ее медленнее. Вы должны понимать, как и почему. Не все можно сделать параллельным, и все, что можно, должно быть.

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

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

] Многопоточность будет полезна везде, параллельность - это не парадигма повседневных вычислений, поэтому она может быть «нишей» в карьерной перспективе.

Дело в том, что вы не можете добиться «настоящего» параллелизма на одном CPU. Есть несколько библиотек (например, C MPI), которые немного помогают в этой области. Но концепция параллелизма не используется разработчиками, работающими над популярными решениями.

Многопоточность стала обычным явлением в наши дни благодаря внедрению нескольких ядер на одном процессоре, это ' их легко и почти прозрачно реализовать на любом языке благодаря библиотекам потоков и потокобезопасным типам, методам, классам и так далее. Таким образом вы можете имитировать параллелизм.

В любом случае, если вы начинаете с этого, начните с чтения о параллелизме и темах многопоточности. И, конечно же, потоки + параллелизм хорошо работают вместе.

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

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

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

Конечно, можно запрограммировать параллельную разработку, используя потоки с такими языковыми фреймворками, как OpenMP . Я слышал о многокомпонентных графических интерфейсах / приложениях, которые полагаются на отдельную обработку, которая теоретически может работать где угодно. На практике первых больше, чем вторых.

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

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

Конечно, можно запрограммировать параллельную разработку, используя потоки с такими языковыми фреймворками, как OpenMP . Я слышал о многокомпонентных графических интерфейсах / приложениях, которые полагаются на отдельную обработку, которая теоретически может работать где угодно. На практике первых больше, чем вторых.

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

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

Конечно, можно запрограммировать параллельную разработку, используя потоки с такими языковыми фреймворками, как OpenMP . Я слышал о многокомпонентных графических интерфейсах / приложениях, которые полагаются на отдельную обработку, которая теоретически может работать где угодно. На практике первых больше, чем вторых.

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

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

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

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

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