ну, это действительно зависит от того, что вы разрабатываете. Ответ, в зависимости от того, что вы разрабатываете, может варьироваться от «он незначительный» до «он абсолютно важен, и мы ожидаем, что все в команде будут хорошо понимать и использовать параллельные реализации».
в большинстве случаев хорошее понимание и использование блокировок, потоков, задач и пулов задач будет хорошим началом, когда потребуется параллелизм. (зависит от языка / lib)
добавьте к этому различия в конструкциях, которые вы должны внести - для нетривиальной многопроцессорной обработки часто приходится изучать несколько новых моделей программирования или стратегий распараллеливания. в этом случае время на обучение, провал достаточно времени, чтобы иметь твердое понимание, и для обновления существующих программ может потребоваться команда год (или больше). Как только вы достигнете этой точки, вы (надеюсь!) не будете воспринимать или подходить к проблемам / реализациям, как вы это делаете сегодня (при условии, что вы еще не сделали этот переход).
Еще одним препятствием является то, что вы эффективно оптимизируете программу для определенного исполнения. если вам не дают много времени на оптимизацию программ, то вы действительно не получите от этого столько пользы, сколько должны. распараллеливание на высоком уровне (или очевидное) может улучшить воспринимаемую скорость вашей программы с довольно небольшими усилиями, и сегодня многие команды пойдут так далеко: «Мы распараллелили действительно очевидные части приложения» - в некоторых случаях это нормально. будет ли польза от того, что плоды будут низко висящими, а простая парализация будет пропорциональна количеству ядер? часто, когда есть два-четыре логических ядра, но не так часто за этим. во многих случаях это приемлемый возврат, учитывая затраты времени. эта параллельная модель представляет собой введение многих людей в реализацию правильного использования параллелизма.
то, что вы изучите, используя эти тривиальные параллельные модели, не будет идеальным во всех сложных параллельных сценариях; эффективное применение сложных параллельных конструкций требует совершенно другого понимания и подхода. эти простые модели часто обособлены или имеют тривиальное взаимодействие с другими компонентами системы. Кроме того, многие реализации этих тривиальных моделей плохо масштабируются для создания эффективных сложных параллельных систем - плохая сложная параллельная конструкция может занять столько же времени, сколько и простая модель. плохо: он выполняется в два раза быстрее однопоточной модели, используя при этом 8 логических ядер. Наиболее распространенные примеры использования / создания слишком большого количества потоков и высокого уровня помех синхронизации. в общем, это называется параллельным замедлением. это довольно легко встретить, если подойти ко всем параллельным задачам как к простым.
Итак, допустим, вы действительно должны использовать эффективную многопоточность в своих программах (меньшинство в сегодняшнем климате): вам нужно эффективно использовать простую модель, чтобы изучить сложную модель, а затем заново изучить, как вы подходите к потоку программ и взаимодействию. Сложная модель - это то, где ваша программа должна быть в конечном счете, поскольку именно там сегодня находится аппаратное обеспечение и где будут сделаны наиболее важные улучшения.
выполнение простых моделей можно представить как разветвление, а сложные модели работают как сложная экосистема. Я думаю, что понимание простых моделей, включая общую блокировку и многопоточность, следует ожидать или ожидать от промежуточных разработчиков, когда домен (в котором вы разрабатываете) использует его. понимание сложных моделей все еще немного необычно сегодня (в большинстве областей), но я думаю, что спрос будет расти довольно быстро. Как разработчики, гораздо больше наших программ должны поддерживать эти модели, и большинство из них довольно далеко отстают в понимании и реализации этих концепций. Поскольку количество логических процессоров является одной из наиболее важных областей улучшения аппаратного обеспечения, спрос на людей, которые понимают и могут внедрять сложные системы, несомненно, возрастет.
наконец, есть много людей, которые думают, что решение - это просто «добавить распараллеливание». часто лучше сделать существующую реализацию быстрее. это намного проще и намного проще во многих случаях. многие дикие программы никогда не были оптимизированы; у некоторых людей просто создалось впечатление, что неоптимизированная версия скоро будет затмена аппаратными средствами. Улучшение дизайна или алгоритмов существующих программ также является важным навыком, если важна производительность - использование большего количества ядер для решения проблем не обязательно является лучшим или самым простым решением.
при ориентации на современные ПК большинству из нас, кому необходимо реализовать хорошие параллельные системы, не нужно выходить за рамки многопоточности, блокировок, параллельных библиотек, ценности чтения книг и большого опыта написания и тестирования программ (в основном, существенной реструктуризации того, как вы Подход к написанию программ).