Неявный параллелизм ^ может взять на себя большое бремя многих программистов, поместив его на компьютер. Итак ... почему это не является более распространенным в настоящее время?
Ответы:
Потому что за несколькими исключениями (Haskell) компилятор не может развернуть цикл. Проблема в том, что каждая итерация цикла может изменять глобальное состояние. Таким образом, выполнение этого в другом порядке может привести к поломке. В haskell вы можете рассчитывать на чистую функцию, то есть она не читает и не изменяет глобальное состояние, поэтому они могут выполняться в любом порядке.
Реальная проблема заключается в том, что, за несколькими исключениями, правильное выполнение параллелизма все еще остается открытой проблемой. Сообщества Erlang и Haskell, кажется, справляются довольно хорошо, но до того, как мы действительно поймем, как запрограммировать систему N-core для больших N., еще далеко.
Большинство языков программирования, которые мы используем сейчас, появилось в то время, когда однопоточное программирование и однопользовательское взаимодействие наиболее часто используются во многих приложениях (например, автономные настольные приложения). С появлением веб-приложений, облачных вычислений и многопользовательских приложений теперь нам нужно больше многопоточных приложений.
Устаревшие языки программирования стараются медленно поддерживать многопоточные функции из самого языка (как в java, добавленном java.util.concurrent).
Новые языки, которые появятся в будущем, будут иметь лучшую встроенную поддержку потоков и параллелизма.
Помимо пунктов, упомянутых в других ответах (трудно доказать, что операции независимы, а программисты думают последовательно), существует еще один фактор, который необходимо учитывать: стоимость распараллеливания.
Правда в том, что параллелизм потоков имеет очень значительные затраты, связанные с ним:
Создание потока очень дорого: для ядра запуск потока примерно такой же, как запуск процесса. Я не уверен насчет точных затрат, но я верю, что это порядка десяти микросекунд.
Связь между потоками через мьютексы обходится дорого: обычно для этого требуется системный вызов с каждой стороны, возможно, перевести поток в спящий режим и снова разбудить его, что приводит к задержке, а также кешу и холодным TLB. В среднем, взятие и освобождение мьютекса стоит около одной микросекунды.
Все идет нормально. Почему это проблема для неявного параллелизма? Потому что неявный параллелизм легче всего доказать в небольших масштабах. Одно дело доказать, что две итерации простого цикла независимы друг от друга, совсем другое дело доказать, что печать чего-либо stdoutи отправка запроса в базу данных независимы друг от друга и могут выполняться параллельно ( процесс базы данных может быть на другой стороне трубы!).
Таким образом, неявный параллелизм, который может доказать компьютерная программа, вероятно, нецелесообразен, поскольку затраты на распараллеливание больше, чем преимущество параллельной обработки. С другой стороны, крупномасштабный параллелизм, который действительно может ускорить приложение, не доказуем для компилятора. Подумайте, сколько работы процессор может выполнить за микросекунду. Теперь, если предполагается, что распараллеливание будет быстрее, чем последовательная программа, параллельная программа должна быть в состоянии поддерживать все процессоры занятыми в течение нескольких микросекунд между двумя вызовами мьютекса. Это требует очень грубого параллелизма, который почти невозможно доказать автоматически.
Наконец, нет правила без исключения: использование неявного параллелизма работает там, где не задействованы потоки, как в случае с векторизацией кода (с использованием наборов команд SIMD, таких как AVX, Altivec и т. Д.). Это действительно работает лучше всего для небольшого параллелизма, который относительно легко доказать.
Программисты думают поочередно, и современные языки создаются для поддержки этой модели. За исключением дополнительных языков, таких как Haskell Erlang и т. Д., Языки (я воздерживаюсь от использования прилагательного «современный») по сути являются сборкой высокого уровня, где мы все еще говорим компьютеру, что делать, когда это делать и как это делать. Пока у нас нет эхо-системы, в которой мы сообщаем компьютеру, какой результат мы хотим получить, мы не обладаем умственными способностями, как программисты, в полной мере использовать возможности многопоточности.
то есть это не естественно ......
don't have the patienceэто более точная оценка, чем, don't have the mental capacityхотя. За свою карьеру я видел гораздо больше ленивых программистов, чем глупых . Мне повезло, хотя меня учили функциональному программированию и мелкозернистому параллельному программированию наряду с процедурным и ОО на первом курсе университета. Я подозреваю, что многим программистам не так повезло, и в результате их мыслительные процессы оказались безуспешными.
Транзакции должны быть ACID, поэтому программист в основном думает об одном потоке.
Языки и платформы должны защищать программиста от параллелизма настолько, насколько они могут себе позволить
И параллелизм не так легко проверить, как сама функциональность, поэтому программисты склонны уходить помимо этих проблем и, даже не думая об обработке параллелизма коммитов, что является ошибкой