Функциональное программирование и многоядерная архитектура

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

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

Другое преимущество - то, что некоторые процессы, которые параллелизируют очень легко, как повторение, абстрагированы к функциям. В C++ Вы могли бы иметь для цикла, который выполняет некоторую обработку данных по каждому объекту в списке. Но компилятор не имеет никакого способа знать, могут ли те операции быть безопасно выполнены параллельно - возможно, результат, каждый зависит от того перед ним. Когда функция как map() или reduce() используется, компилятор может знать, что нет никакой зависимости между вызовами. Несколько объектов могут таким образом быть обработаны одновременно.

Когда нет никаких побочных эффектов, порядок оценки не имеет значения. Тогда возможно оценить выражения параллельно.

Основной аргумент - то, что трудно автоматически параллелизировать языки как C/C ++/etc, потому что функции могут установить глобальные переменные. Рассмотрите два вызова функции:

a = foo(b, c);
d = bar(e, f);

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

Функциональные языки гарантируют, что нечто и панель независимы: нет никакого globals и никаких побочных эффектов. Поэтому нечто и панель могли быть безопасно выполнены на различных ядрах, автоматически, без вмешательства программиста.

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

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

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

различием между multi-U сервером и многоядерным ЦП в сервере или ПК являются сбережения скорости, которые Вы продвигаетесь, имея его на той же ШИНЕ, позволяя лучше и более быстрой коммуникации к ядрам.

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

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

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

И совместно используемые данные то, что вызывает половину головных болей с многопоточностью.

Книга , Программируя Erlang: программное обеспечение для Параллельного Мира Joe Armstrong (создатель Erlang) говорит вполне немного об использовании Erlang для многоядерного (/многопроцессорная система) системы. Поскольку в статье Википедии говорится:

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

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

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

К сожалению, это убеждение давно опровергнуто по нескольким причинам:

• Абсолютная производительность чисто функциональных структур данных низка. Поэтому чисто функциональное программирование - это большой начальный шаг в неверном направлении в контексте производительности (которая является единственной целью параллельного программирования).

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

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

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

Однако более распространенное определение функционального программирования как стиля, который подчеркивает использование функций первого класса, на самом деле оказывается очень полезным в контексте многоядерного программирования, поскольку эта парадигма идеально подходит для факторизации параллельных программ. Например, смотрите новую функцию высшего порядка Parallel.For из пространства имен System.Threading.Tasks в .NET 4.