Grand Central Dispatch vs NSThreads?

Ответ 1

Преимущества отправки

Преимущества отправки в основном описаны здесь:

Миграция из потоков

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

• Это уменьшает штраф за память, который ваше приложение оплачивает для хранения стеков потоков в памяти приложений.
• Он устраняет код, необходимый для создания и настройки ваших потоков.
• Он устраняет код, необходимый для управления и планирования работы с потоками.
• Это упрощает код, который вы должны написать.

Эмпирически использование блокировки типа GCD вместо @synchronized составляет примерно 80% быстрее или больше, хотя микро-тесты могут обманывать. Подробнее здесь, хотя я думаю, что совет по асинхронному использованию записей не применяется во многих случаях, и он медленнее (но он асинхронен).

Преимущества потоков

Почему вы продолжаете использовать Threads? Из того же документа:

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

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

Блоки в Objective-C?

Блоки действительно ужасны в Objective-C из-за ужасного синтаксиса (хотя Xcode иногда может помочь с автозавершением, по крайней мере). Если вы посмотрите на блоки в Ruby (или на любом другом языке, в значительной степени), вы увидите, насколько они просты и элегантны для диспетчерских операций. Я бы сказал, что вы привыкнете к синтаксису Objective-C, но я действительно думаю, что вы скоро привыкнете к копированию из своих примеров:)

Вы можете найти мои примеры здесь, чтобы быть полезными или просто отвлекать. Не уверен.

Ответ 2

Пока ответы до сих пор касаются контекста потоков против GCD внутри домена одного приложения и различий, которые он имеет для программирования, причина, по которой вы всегда должны отдавать предпочтение GCD, связана с многозадачными средами (поскольку вы находитесь на MacOSX и не iOS). Темы одобрены, если ваше приложение работает на вашем компьютере. Скажем, у вас есть программа для видеорекламы и вы хотите применить некоторый эффект к видео. Резерв будет принимать 10 минут на машине с восемью ядрами. Хорошо.

Теперь, когда видео-приложение перевернуто в фоновом режиме, вы открываете программу для редактирования изображений и воспроизводите изображение с высоким разрешением, решаете применить какой-то специальный фильтр изображения, а ваше графическое приложение умело обнаруживает, что у вас есть восемь ядер и начинается восемь потоки для обработки изображения. Приятно, не правда ли? Кроме того, что ужасно для исполнения. Приложение для редактирования изображений ничего не знает о видеоприложении (и наоборот), и поэтому оба запросят их оптимальное количество потоков. И будет боль и кровь, в то время как ядра пытаются переключиться с одного потока на другой, потому что, чтобы избежать голодания, процессор в конечном итоге позволит запускать все потоки, хотя в этой ситуации было бы более оптимальным запускать только 4 потока для видео приложение и 4 потока для графического приложения.

Для получения более подробной информации ознакомьтесь с http://deusty.blogspot.com/2010/11/introducing-gcd-based-cocoahttpserver.html, где вы можете увидеть тест HTTP-сервера с использованием GCD в сравнении с потоком и посмотреть, как он масштабируется, Как только вы поймете, что проблемы для многоядерных машин в многопользовательских средах, вы всегда хотите использовать GCD, просто потому, что потоки не всегда оптимальны, а GCD потенциально может быть, поскольку ОС может масштабировать расход потоков для каждого приложения в зависимости от нагрузки.

Пожалуйста, помните, что в ближайшее время у нас не будет больше ГГц в наших машинах. Отныне у нас будет только больше ядер, поэтому ваш долг - использовать лучший инструмент для этой среды, и это GCD.

Ответ 3

Блоки позволяют передавать исполняемый блок кода. Когда вы пройдете "странный синтаксис", они достаточно мощные.

GCD также использует очереди, которые при правильном использовании могут помочь с блокировкой free concurrency, если код, выполняющийся в отдельных очередях, изолирован. Это более простой способ предложить фон и concurrency, минимизируя вероятность блокировок (если используется правильно).

"Странный синтаксис" заключается в том, что они выбрали каретку (^), потому что это был один из немногих символов, которые не были перегружены как оператор в С++

См: https://developer.apple.com/library/ios/#documentation/General/Conceptual/ConcurrencyProgrammingGuide/OperationQueues/OperationQueues.html

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

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

...

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

Ответ 4

GCD (Grand Central Dispatch): GCD предоставляет и управляет очередями FIFO, к которым ваше приложение может отправлять задания в виде блочных объектов. Работа, отправленная в очереди отправки, выполняется в пуле потоков, полностью управляемом системой. Никакой гарантии не делается в отношении потока, на котором выполняется задача. Почему GCD по потокам:

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

Я поделился своим опытом с потоками, операционной системой и GCD AT http://iosdose.com