Есть ли смысл в многопоточности?

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Вот несколько ответов:

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

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

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

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

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

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

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

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

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

Большинство ответов делают вывод multicore => многопоточность неизбежным. Однако есть еще один способ использования нескольких процессоров - многопроцессорность . Особенно в Linux, где, AFAIK, потоки реализованы как просто процессы, возможно, с некоторыми ограничениями, а процессы дешевы в отличие от Windows, есть веские причины избегать многопоточности. Итак, здесь есть проблемы с архитектурой программного обеспечения, которыми нельзя пренебрегать.

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

Я бы предположил, что многопоточность сегодня - это то, чем было управление памятью во времена C:

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

Наконец, вы можете найти эту статью интересной (перейдите по этой первой ссылке на странице). Хотя признаю, что читал только аннотацию.