Есть ли смысл в многопоточности? - PullRequest
7 голосов
/ 05 августа 2010

Я не хочу делать это субъективным ...

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

Будут ли JavaScript или ActionScript лучше, если бы они были многопоточными?

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

Ответы [ 11 ]

13 голосов
/ 05 августа 2010

Я не знаю, обращали ли вы внимание на тенденции аппаратного обеспечения в последнее время (последние 5 лет), но мы движемся к многоядерному миру.

Обычным будильником была эта статья "Бесплатный обед окончен" .

На двухъядерном ПК однопоточное приложение получит только половину циклов ЦП.И процессоры больше не становятся быстрее, эта часть закона Мура умерла.

8 голосов
/ 05 августа 2010

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

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

7 голосов
/ 05 августа 2010

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

4 голосов
/ 05 августа 2010

Большинство процессоров в наши дни многоядерные. Проще говоря, это означает, что они имеют несколько процессоров на одном чипе.

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

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

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

3 голосов
/ 05 августа 2010

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

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

2 голосов
/ 05 августа 2010

Нет. Вы не можете продолжать получать новые циклы ЦП, потому что они существуют на другом ядре, и ядро, на котором существует ваше однопоточное приложение, не будет работать быстрее. Многопоточное приложение, с другой стороны, получит выгоду от другого ядра. Хорошо написанный параллельный код может работать примерно на 95% быстрее - на двухъядерном процессоре, который является всеми новыми процессорами за последние пять лет. Это вдвое больше, чем для четырехъядерного процессора. Поэтому, хотя ваше однопоточное приложение не получает больше циклов, чем пять лет назад, мое четырехпоточное приложение имеет в четыре раза больше и значительно превосходит ваше по времени отклика и производительности.

1 голос
/ 05 августа 2010

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

Итак, с точки зрения производительности, вам нужно несколько потоков для загрузки ЦП.

Кроме того, некоторые задачи также проще выразить с помощью многопоточности.

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

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

1 голос
/ 05 августа 2010

Вот некоторые ответы:

  • Вы пишете "Если проблемы, связанные с вводом / выводом, не являются узкими местами ...".Это большое «если».У многих программ есть подобные проблемы, помня, что проблемы с сетью включены в «IO», и в этих случаях многопоточность явно стоит того.Если вы пишете одно из тех редких приложений, в которых нет ввода-вывода и нет связи, то многопоточность может не быть проблемой
  • «Однопоточный код получит все циклы ЦП».Не обязательно.Многопоточный код вполне может получить больше циклов, чем однопоточное приложение.В наши дни приложение едва ли когда-либо является единственным приложением, работающим в системе.
  • Многопоточность позволяет вам использовать преимущества многоядерных систем, которые в наши дни становятся почти универсальными.
  • Многопоточность позволяет поддерживать чувствительность графического интерфейса пользователя во время выполнения каких-либо действий.Даже если вы не хотите, чтобы два пользовательских действия выполнялись одновременно, вы можете захотеть, чтобы графический интерфейс мог перекрашивать и реагировать на другие события во время вычислений.

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

1 голос
/ 05 августа 2010

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

1 голос
/ 05 августа 2010

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

Так что на самом деле у вас будет максимум 25% циклов ЦП, а не 100%. Поскольку сегодняшняя технология заключается в добавлении большего количества ядер и уменьшении тактовой частоты, многопоточность будет иметь все большее значение для производительности.

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