Являются ли однопоточные приложения мертвой технологией?

Я только что купил новый ноутбук стоимостью до 1000 долларов США, который был нацелен прямо на потребительский рынок, не являющийся разработчиком, и, глядя на спецификации, с удивлением обнаружил, что он поставляется с двухъядерным процессором.

Это привело меня к вопросу: с многоядерными машинами, становящимися нормой, правильно ли написать однопоточное приложение?

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

Ответ 1

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

Даже если одноядерные процессоры полностью устарели, однопоточное программирование не будет.

Двойные ядра, особенно на потребительском рынке, отлично подходят для многозадачности. Если каждое приложение занимает каждое ядро ​​процессора, возможно, мы столкнемся с теми же проблемами, что и с одноядерными процессорами.

Я говорю, что не сходите с ума и начинайте все с ума. Держите его в одном потоке, если нет веской причины не слишком.

Ответ 2

Вы не должны быть многопоточными, если приложение не должно быть многопоточным.

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

Ответ 3

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

У Microsoft есть набор расширений, которые, как мне кажется, добавляются в среду выполнения под названием Parallels?? Я знаю, что они называют версию PLINQ с поддержкой LINQ. По сути, он пытается удалить много ошибок, связанных с сантехникой из многопоточных алгоритмов.

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

Ответ 4

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

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

Ответ 5

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

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

Ответ 6

Определенно, параллельное программирование в будущем значительно продвинется вперед, так как процессор не будет намного быстрее, у нас их будет много. Наличие двухъядерных или четырехъядерных ядер - это только начало, в ближайшем будущем появятся системы с гораздо большим числом процессоров (в настоящее время есть процессор с 256 ядрами, Windows 7 будет поддерживать такие процессоры).

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

У Дэвида Каллахана была интересная статья в журнале MSDN о смещении проектных соображений в отношении параллельного программирования: Paradigm Shift: Вопросы проектирования для параллельного программирования

Ответ 7

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

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

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

Ответ 8

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

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

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

Ответ 9

Как обычно в оптимизации производительности; вы не можете делать общие утверждения о том, достаточно ли "достаточно" для произвольных приложений. Вопрос в том, достаточно ли он "достаточно эффективен" для приложения X.

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

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

Ответ 10

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

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

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

Помимо этого, есть непосредственные преимущества. Увеличенное адресное пространство памяти. Сами операционные системы, которые уже оплотизированы для двойного, также принесут немедленные выгоды.

Также: если у вас есть библиотека, оптимизированная для двухъядерных процессоров, все последующее ее развитие принесет пользу. Примером могут служить алгоритмы поиска и сортировки (выбор нарта для "разделения потоков" из-за делимости данных), которые могут быть оптимизированы для двухъядерного ядра, а затем будут использоваться с преимуществом.

Ответ 11

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

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

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

Ответ 12

Может быть, вопрос должен быть переформулирован так: "запускает программу на одном только ядре мертвую технологию". Это сделало бы его намного более общим. Если вы посмотрите на недавно добавленных веб-работников, добавленных в firefox 3.5 и другие основные браузеры, то они поддерживают несколько ядер, но используют процессы и передачу сообщений. Это гораздо более здравый подход, чем нарезка. В конечном итоге все зависит от проблемы. Использование нескольких ядер действительно имеет значение только в том случае, если проблема связана с ЦП.

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

Ответ 13

Хороший способ использования нескольких процессоров без многопоточности:

cat data.txt | sed 's/,/ /g' | awk '{print $4}' | gzip > foo.txt.gz

Отвечает ли это на ваш вопрос о двухъядерном погодных условиях, все приложения должны быть многопоточными? Вышесказанное может теоретически насытить 3 процессора. (исключая cat, только используя его, потому что это делает строку более читаемой)