Действительно ли однопоточные приложения являются мертвой технологией? [закрытый]
Вам нужно
guard let stringValue = metadataObj.stringValue else { return }
if let res = try? JSONSerialization.jsonObject(with:Data(stringValue.utf8), options: []) as? [String:String] ,let fin = res {
guard let number = fin["number"] , let amount = fin["amount"] else { return }
print(number)
print(amount)
}
ИЛИ
if let res = try? JSONDecoder().decode(Root.self, from: Data(stringValue.utf8)) {
print(res.number)
print(res.amount)
}
struct Root : Decodable {
let number,amount:String
}
13 ответов
Начиная с поточной обработки всегда добавляет дополнительную сложность к приложениям, я полагаю, что единственные потоковые приложения будут всегда иметь свое место.
Даже то, когда ядерные процессоры являются абсолютно устаревшими, не будет единственное потоковое программирование закончиться.
Двойные ядра, особенно на рынке потребительских товаров, являются большими для многозадачности. Если каждое приложение берет каждое ядро процессора, оно возможно может мы сталкиваться с теми же проблемами, которые мы имели с ядерными процессорами.
Я говорю, не сходят с ума и запускают mulithreading все. Сохраните его в одном потоке, если нет серьезное основание не также.
... будет приложение, которое работает во всем одном потоке быть серьезно ухудшенным по тому, как современное OSs распространило их выполнение через ядра, когда никакие указания не даются приложением относительно того, как оптимизировать такое разделение?
Нет, это будет все еще работать, точно так же как это привыкло выполненный для на одножильном ЦП.
Вы не должны быть многопоточностью, если приложение не должно быть многопоточным.
Просто, потому что можно мультираспараллелить, не означает, что Вы должны. Несколько ядер/процессоров действительно не изменяют этот факт.
Многопоточные приложения значительно более трудно записать, и поддержать. Я думаю, что Вы начнете видеть больше приложений, которые усиливают многопоточность благодаря усовершенствованиям в обоих аппаратных средствах, но также и в усовершенствованиях в технологическом стеке.
Microsoft имеет ряд расширений, которым я верю, добавляются в названное время выполнения?? Параллели?? Я знаю, что они звонят, LINQ включил версии PLINQ. По существу это пытается удалить большую подверженную ошибкам инфраструктуру от многопоточного algorithims.
Только время говорит однако, и я держал бы пари, что было все еще быть большим количеством единственных потоковых приложений там, потому что они не будут algorithims, которые выравнивают по ширине стоимость производительности вращения, распараллеливает.
Аппаратные средства действительно не изменяют то, что любая задача в конкретном приложении собирается заблокироваться или не блок, и это действительно, что собирается определить, необходимо ли использовать многопоточность или нет.
Однако современные языки программирования добавляют новые опции для помощи и более безопасный для программиста реализовать поточные приложения. Какао, например, имеет NSOperationQueue, который абстрагирует модель рабочего потока, и существует больше улучшений, происходящих в следующий выпуск OS X. В дополнение к помощи реализовать простую модель потоков, NSOperationQueue также управляет потоками способом, что общее количество потоков подходит для количества процессоров и ядер, поэтому если Ваше приложение использует много потоков могут быть некоторые довольно значительные выигрыши в быстродействии без слишком большой дополнительной работы.
Программирование для нескольких потоков является в настоящее время несколько трудным, подверженным ошибкам, и трудным протестировать (тестирующий на условия состязания, не легко). Поэтому это должно быть зарезервировано для того, когда преимущества преодолевают недостатки.
Для большого количества программ, запущенных достаточно быстро почти во всех целях, и, не нужно никакое повышение производительности. Некоторые требуют времени, но по причинам, которые действительно не включают ЦП и не будут улучшенными несколькими потоками. Для них, с помощью больше чем одного потока делает их тяжелее для разработки, не помогая конечному пользователю.
Тем временем несколько ядер могут быть полезными без многопоточности. Большинство операционных систем имеет несколько движений процессов (контроль, фоновое обслуживание, вирусы, шпионское ПО, спам-роботы, безотносительно), и разрешение их работать на другом ядре может освободить один для пользовательского кода.
Несколько ядер рекламируются для пользовательского преимущества, не программиста. Пользователю скажут, что наличие нескольких ядер означает, что они могут запустить много сложных приложений одновременно, например, обновление большой электронной таблицы в Excel и просмотре Презентации PowerPoint и т.д.
Очевидно, как разработчик Вы CAN хорошо используют дополнительные ядра; большинство пакетов редактирования видео, выполненных намного быстрее на многоядерных машинах.
Если бы Вы пишете приложение, которое серьезно извлекло бы выгоду из использования большего количества ядер, то может стоить инвестировать дополнительное время разработки, поскольку самые новые машины теперь имеют больше чем одно ядро, но как всегда, думайте о ROI.
Как обычно, в оптимизации производительности; Вы не можете сделать универсальные операторы о том, достаточно ли что-то "производительно" о произвольных приложениях. Вопрос, это "достаточно производительный" для приложения X.
Однако, возможно, больше к Вашей точке, чтобы продолжить видеть преимущества Закона Гордона Мура, который больше не делает процессоры быстрее, но делает их меньшими (и следовательно больше ядер на микросхеме) приложения должны будут стать многопоточными.
Однако стоимость создавания многопоточного приложения (разработка, тестирование, поддержка) является все еще значительной, таким образом, Вы действительно не должны делать этого, если Вам не нужна производительность. Я думаю, снижаясь, пика является некоторыми более легкими способами сделать многопоточное программирование с некоторыми различными библиотеками, а также вещами как функциональное программирование и оптимизированные компиляторы, таким образом, я думаю, что это станет легче, в то время как мы продолжаем переход в многоядерный мир.
Definetely, параллельное программирование будет совершенствоваться много в будущем, так как ЦП не собирается становиться намного быстрее больше, у нас просто будут многие из них. Наличие двойных или квадратических ядер является только началом, будут системы с намного более высоким количеством процессоров в ближайшем будущем (в настоящее время существует ЦП с 256 ядрами, Windows 7 будет иметь поддержку таких процессоров).
Однако я думаю, что параллелизм не подходит для решения никакой проблемы, и это требует другого стиля программирования. Используя современную технологию, многопоточность добавляет довольно высокий уровень сложности к приложению. Поэтому парадигмы, такие как функциональное программирование, а также библиотеки/компиляторы, поддерживающие распараллеливание, станут все более важными в будущем.
У David Callahan была интересная статья в MSDN Magazine на сдвиге в конструктивных соображениях относительно параллельного программирования: Сдвиг Парадигмы: Конструктивные соображения Для Параллельного программирования
Ответ на Ваш вопрос хитер, потому что он просит, чтобы мы размышляли о будущей разработке. Простой ответ на Ваш вопрос - это:
Нет, единственные потоки являются основанием для нескольких потоков, Вы не можете иметь один без другого. Таким образом способность к единственным потоковым приложениям будет всегда существовать, и они будут несомненно записаны в течение последующих лет.
Сложный ответ следующие: причина компьютеров, имеющих двухъядерный стандарт процессоров, состоит в том, потому что это - следующий шаг в разработке процессора. в то время как много приложений не воспользуются прямым преимуществом двухъядерного, некоторые будут. По сути, компания как Intel должна разместить или быть раздавлена конкуренцией.
Вне этого существуют прямые преимущества. Большее адресуемое пространство памяти. Сами Операционные системы, уже являющиеся optomized для двойного также, получают непосредственную выгоду.
Также: Если у Вас будет библиотека, которая оптимизирована для двухъядерных процессоров, то вся последующая разработка извлечет выгоду. Пример ищет и сортирует алгоритмы (nartural выбор для "разделения потока" из-за делимости данных), который может оптимизироваться для двухъядерного, и затем perpectually использоваться с преимуществом.
Давайте признаем, что большинство приложений написано для бизнеса, они обращаются к базе данных и позволяют просматривать, редактировать и добавлять данные в ней. Затем, возможно, какие-нибудь отчеты об анализе данных и так далее.
За исключением отдельного потока пользовательского интерфейса, если запросы к базе данных будут занимать время, для его выполнения очень мало причин, поскольку выигрыш будет частичным и в значительной степени незаметным для конечного пользователя. Возможно, есть несколько случаев, когда параллельный цикл может быть полезен приложениям.
Я считаю, что реальная выгода от использования нескольких ядер в настоящий момент заключается в том, что несколько приложений обращаются к разным ядрам одновременно. Подумайте только, сколько процессов Windows выполняется в фоновом режиме, их можно запускать одновременно на любом количестве ядер.
Может быть, вопрос следует переформулировать так: «работает программа только на одном ядре - мертвая технология». Это сделало бы его более общим. Если вы посмотрите на недавно добавленных веб-воркеров, добавленных в firefox 3.5 и другие основные браузеры, то они действительно поддерживают несколько ядер, но используют процессы и передачу сообщений. Более разумный подход, чем многопоточность. В конце концов, все зависит от решаемой проблемы. Использование нескольких ядер действительно имеет значение, только если проблема связана с процессором.
Я также хотел бы добавить, что ваше приложение может быть не единственным запущенным процессом на машине ( подсказка ).
Хороший способ использования нескольких процессоров без многопоточности:
cat data.txt | sed 's/,/ /g' | awk '{print $4}' | gzip > foo.txt.gz
Это ответ на ваш вопрос о погодном двухъядерном процессоре означает, что все приложения должны быть многопоточными? Вышеупомянутое теоретически может насытить 3 процессора. (кроме cat, используется только потому, что это делает строку более читаемой)