Помогите навести ясность.
Рекламируя функциональные языки, их сторонники утверждают, что программы на этих языках чуть ли не атоматически распараллеливаются.
С другой стороны, уважаемые авторы, резюмируя текущее состояние дел в области автоматического распараллеливания программ — утверждают, что серебряной пули еще нет и даже на горизонте не видно.
В чем подвох?
Ну понятно, что если программа специально разбита на куски, изолированные по данным, с использованием специальных библиотек в императивных языках или специальных языковых конструкций, как в эрланге, будут параллелиться и исполняться эффективно,
но приимуществ собственно функциональной парадигмы тут, вроде, не видно.
Так есть ли в этом плане реальные преимущества у ФЯ?
Здравствуйте, Chrome, Вы писали:
C>Помогите навести ясность. C>Рекламируя функциональные языки, их сторонники утверждают, что программы на этих языках чуть ли не атоматически распараллеливаются. C>С другой стороны, уважаемые авторы, резюмируя текущее состояние дел в области автоматического распараллеливания программ — утверждают, что серебряной пули еще нет и даже на горизонте не видно. C>В чем подвох? C>Ну понятно, что если программа специально разбита на куски, изолированные по данным, с использованием специальных библиотек в императивных языках или специальных языковых конструкций, как в эрланге, будут параллелиться и исполняться эффективно, C>но приимуществ собственно функциональной парадигмы тут, вроде, не видно. C>Так есть ли в этом плане реальные преимущества у ФЯ?
Ключевая фраза у тебя это "чуть ли".
Реально же Ф-код сам собой не становится параллельным. Но распараллелить Ф-код проще. И уж точно проще проектировать параллельную программу с использованием ФП.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, IT, Вы писали: IT>Теоретически или практически?
Возьмем среднестатистическую программу на современном императивном языке, которая создавалась без прицела на параллельное исполнение. Мне видится, что и теоретически и практически, для того, что бы заставить ее параллелиться на многоядерной архитектуре, ее следует переписать.
Возьмем аналогичную программу на функциональном языке.
Возможно ли, Теоретически или практически, не переписывая ее, добиться реального масштабирования на на многоядерной архитектуре?
C>Возможно ли, Теоретически или практически, не переписывая ее, добиться реального масштабирования на на многоядерной архитектуре?
Частично переписывать все равно придется Потому что принуждение к распараллеливанию из ниоткуда не возьмется
А сам вопрос о распараллеливании программы зависит, естественно, от программы
Здравствуйте, VladD2, Вы писали:
VD>Ключевая фраза у тебя это "чуть ли".
VD>Реально же Ф-код сам собой не становится параллельным. Но распараллелить Ф-код проще. И уж точно проще проектировать параллельную программу с использованием ФП.
Ну, поскольку, на фя абсолютно все "проще", пассаж про проектирование параллельной программы является частным случаем этого утверждения. Опустим его.
Мне интересно, рекламируемая уникальная приспособленность фя для параллельного программирования — просто необоснованная реклама,
или некакя теоретическая возможность, по какой то причине не очень реализуемая на практике.
Если второе, то в чем практический затык? Почему не получается?
Здравствуйте, Chrome, Вы писали:
C>Возьмем среднестатистическую программу на современном императивном языке, которая создавалась без прицела на параллельное исполнение. Мне видится, что и теоретически и практически, для того, что бы заставить ее параллелиться на многоядерной архитектуре, ее следует переписать. C>Возьмем аналогичную программу на функциональном языке. C>Возможно ли, Теоретически или практически, не переписывая ее, добиться реального масштабирования на на многоядерной архитектуре?
Дело не в языке. Дело в стиле. Скажем тот же компилятор Nemerle написан на функциональном языке. Но вот исходно он был написан в стиле Красного Дракода и С. Есть и изменяемые общие данные. И куча статических переменных. Хотя большая часть кода написана в функциональном стиле, не так то просто превратить этот код в многопоточный не устранив те самые статические переменные (хотя бы).
Конечно если бы код был написан в 100%-но функциональном стиле, то задачу было бы решить элементарно. Но так не бывает. Даже если вы возьметесь решать сложную вычислительную задача скажем на Хаскеле, то вы все равно будете вынуждены заниматься оптимизациями, а значит и иметь где-то изменяемое состояние. И этого уже может хватить чтобы нельзя было эффективно распараллелить программу.
А так все просто. Функциональный код = отсутствие разделяемого состояния. Отсутствие разделяемого состояния = легкое распараллеливание.
В том же компиляторе основная работа — это типизация методов/функций (операторов в программах по определению во много раз больше чем скажем методов). Методов/функций в большой программе много и если у нас нет глобального вывода типов, то каждый метод можно типизироваться отдельно. А раз так, можно практически линейно масштабировать компилятор путем добавления новых процессоров.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Chrome, Вы писали:
C>Мне интересно, рекламируемая уникальная приспособленность фя для параллельного программирования — просто необоснованная реклама, C>или некакя теоретическая возможность, по какой то причине не очень реализуемая на практике. C>Если второе, то в чем практический затык? Почему не получается?
Если их не много, то FP их может хорошо загрузить. При ленивых вычислениях — их можно делать на других ядрах "про запас", раз всё равно они простаивают. И когда нужда в них возникнет — они уже вычеслены. И данные в основном immutable, то есть не надо синхронизировать кэши ядер при записи данных, и вообще синхронизация не нужна — а в ней одной будут самые большие потери при небольшом количестве ядер.
Когда я в одном проекте на java пробовал ввести параллелизм, то сразу наткнулся на всякие проблемы с архитектурой самой программы. Начиная с того, что один тред итерировал по списку, а другой в это время изменял этот список. Хорошо, к тому времени уже были java.util.concurent контейнеры, специально приспособленные к такой ситуации. А без них — это жизнь на минном поле. В любой момент может выскочить ошибка, и никакими юнит-тестами её обнаружить невозможно.
Если же ядер очень много, сотни и тысячи — то проблема будет не в том, параллелятся или нет вычисления в программе. А в том, что саму архитектуру программного обеспечения надо будет менять — память не будет общей, процессоры не будут связаны со всеми другими, а только с ближайшими. Это совершенно другой способ программировать, более близкий к нейронным сетям, чем к программированию в нынешнем понимании этого процесса.
В таких условиях будет лучше работать что-то вроде erlang-а, но именно в силу его ориентированности на приём сообщения (данных), простую обработку, посылку сообщения дальше. То есть модель "актёров". Что действительно никакого отношения к FP не имеет.
Здравствуйте, VladD2, Вы писали:
VD>А так все просто. Функциональный код = отсутствие разделяемого состояния. Отсутствие разделяемого состояния = легкое распараллеливание.
Отсутствие разделяемого состояния = легкое распараллеливание = 100% загрузка всех ядер != линейная масштабируемость скорости работы приложения
Отсутствие разделяемого состояния = легкое распараллеливание = 100% загрузка всех ядер возможно= деградация скорости работы приложения
Если как конечную цель ставить 100%-ную загрузку всех ядер (кодом, который как-то связан с кодом приложения), то Да, всё легко. Если как конечную цель ставить близкую к линейной масштабируемость скорости работы приложения — то, увы, Нет, всё не так просто.
Здравствуйте, Chrome, Вы писали:
C>Мне интересно, рекламируемая уникальная приспособленность фя для параллельного программирования — просто необоснованная реклама, или некакя теоретическая возможность, по какой то причине не очень реализуемая на практике. C>Если второе, то в чем практический затык? Почему не получается?
Тут нужно уточнить одну вещь. Написание кода, который легко параллелить и само распараллеливание — это две разные вещи. Так вот с первым в ФЯ проблем нет, а второе это целый комплекс решений, включающих как процесс кодирование, так и архитектуру приложения и пр.
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, mkizub, Вы писали:
M>Здравствуйте, Chrome, Вы писали:
M>Насколько многоядерная? M>C 2, 4, 16, 1024 ядрами?
M>Если их не много, то FP их может хорошо загрузить. При ленивых вычислениях — их можно делать на других ядрах "про запас", раз всё равно они простаивают. И когда нужда в них возникнет — они уже вычеслены.
Загрузить ядра-то — не проблема. Проблема — ещё при этом получить близкое к линейному увеличение скорости работы приложения. И если первое и легко, то про второе я бы не был так уверен.
M>И данные в основном immutable, то есть не надо синхронизировать кэши ядер при записи данных, и вообще синхронизация не нужна — а в ней одной будут самые большие потери при небольшом количестве ядер.
Тут совсем не понятно. Если речь идёт о распараллеливании "однопоточного" приложения, то тут в любом случае (ни в каком языке) нет никаких изначальных издержек на синхронизацию. А если говорить про то, как ран-тайм будет достигать автоматического распараллеливания, то тут в любом случае (в любом языке) будут издержки на синхронизацию — как будем делать балансировку нагрузки? как будем распределять работу между потоками? как будем синхронизировать асинхронные ленивые вычисления? и т.д.
Иммутабельность имеет значение, если говорить о *ручном* и *явном* создании многопоточной программы. (зы в чём проблема иметь не изменяемые данные не в ФП языке? тем более если уж говорить о явном и осознанном создании многопоточной программы)
Здравствуйте, IT, Вы писали:
C>>Мне интересно, рекламируемая уникальная приспособленность фя для параллельного программирования — просто необоснованная реклама, или некакя теоретическая возможность, по какой то причине не очень реализуемая на практике. C>>Если второе, то в чем практический затык? Почему не получается?
IT>Тут нужно уточнить одну вещь. Написание кода, который легко параллелить и само распараллеливание — это две разные вещи. Так вот с первым в ФЯ проблем нет, а второе это целый комплекс решений, включающих как процесс кодирование, так и архитектуру приложения и пр.
Тут тоже надо уточнить одну вещь. Если мы уже провели "само распараллеливание", т.е. провели анализ проблемы, проработали архитектуру, выбрали алгоритмы и т.д. То насколько серьёзные проблемы у нас вызовет в НЕ функциональном языке сделать, допустим, неизменяемый объект, или написать функцию сортировки массива без побочных эффектов?
Здравствуйте, mkizub, Вы писали:
M>Хорошо, к тому времени уже были java.util.concurent контейнеры, специально приспособленные к такой ситуации. А без них — это жизнь на минном поле. В любой момент может выскочить ошибка, и никакими юнит-тестами её обнаружить невозможно.
Здравствуйте, VladD2, Вы писали:
C>>Так есть ли в этом плане реальные преимущества у ФЯ?
VD>Ключевая фраза у тебя это "чуть ли".
VD>Реально же Ф-код сам собой не становится параллельным. Но распараллелить Ф-код проще. И уж точно проще проектировать параллельную программу с использованием ФП.
Ты наверное думал, никто не заметит тонкой подмены ФЯ на ФП
Интересные принципы ФП, такие как неизменяемость и отсутствие побочных-эффектов, действительно делают *некоторые* задачи параллельных вычислений проще. Но они имеют лишь косвенное отношение к ФЯ в данном контексте, в том смысле, что ФЯ *ограничены* только этими подходами (некоторые "ФЯ" не ограничены, но тогда уже наверное мало смысла говорить о ФЯ и о ФП), в то время как НЕ ФЯ языки обычно тоже могут в полном объёме использовать упомянутые подходы, но в то же время не ограничены ими (что может положительно сказаться на реализации *других* некоторых параллельных задач).
Здравствуйте, remark, Вы писали:
R>Здравствуйте, VladD2, Вы писали:
C>>>Так есть ли в этом плане реальные преимущества у ФЯ?
VD>>Ключевая фраза у тебя это "чуть ли".
VD>>Реально же Ф-код сам собой не становится параллельным. Но распараллелить Ф-код проще. И уж точно проще проектировать параллельную программу с использованием ФП.
R>Ты наверное думал, никто не заметит тонкой подмены ФЯ на ФП R>Интересные принципы ФП, такие как неизменяемость и отсутствие побочных-эффектов, действительно делают *некоторые* задачи параллельных вычислений проще. Но они имеют лишь косвенное отношение к ФЯ в данном контексте, в том смысле, что ФЯ *ограничены* только этими подходами (некоторые "ФЯ" не ограничены, но тогда уже наверное мало смысла говорить о ФЯ и о ФП), в то время как НЕ ФЯ языки обычно тоже могут в полном объёме использовать упомянутые подходы, но в то же время не ограничены ими (что может положительно сказаться на реализации *других* некоторых параллельных задач).
Дабы не быть голословным. Такие библиотеки поддержки параллелизма как Intel TBB (C++), Cilk (C), Cilk++ (C++), TPL (.NET), PPL (C++), Fork/Join (Java) для НЕ ФЯ языков, все требуют, что бы "функции" для параллельного выполнения были (1) без побочных эффектов, (2) не зависели от порядка выполнения оных и (3) не требовали параллелизма. Чем *не* *не* ФЯ? Чем не ФП? К тому же все эти библиотеки предоставляют удобное хранилище для "локальных" данных — будь то объект задачи или стек. Уж с чем-чем, но с этими требованиями к "функциям" для параллельного выполнения не возникает никаких проблем и сложностей в не ФЯ языках.
Здравствуйте, remark, Вы писали:
R>Тут тоже надо уточнить одну вещь. Если мы уже провели "само распараллеливание", т.е. провели анализ проблемы, проработали архитектуру, выбрали алгоритмы и т.д. То насколько серьёзные проблемы у нас вызовет в НЕ функциональном языке сделать, допустим, неизменяемый объект, или написать функцию сортировки массива без побочных эффектов?
Здесь можно провести параллель с строготипизированные языки vs нетипизированные. В первом случае компилятор тебе помогает, во втором — это твоя личная проблема. Так же и здесь.
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, IT, Вы писали:
IT>Тут нужно уточнить одну вещь. Написание кода, который легко параллелить и само распараллеливание — это две разные вещи. Так вот с первым в ФЯ проблем нет, а второе это целый комплекс решений, включающих как процесс кодирование, так и архитектуру приложения и пр.
Можно добавить? Да? Спасибо.
Вот тут в ветке, на данный момент, мне понравилось как изложил mkizub — что-то более-менее нормальное и по теме, широкий взгляд. Нет, ты безусловно прав конечно тоже.
Просто тут вот, я с появления темы ждал высказывания Влада, о "преимуществах", и таки оно прозвучало... в иммутабельности! Честно говоря и самому оно в голову пришло. А следом... пришло и другое — получается как несколько лет назад, кричим лозунги, а что они значат — мы не понимаем, то память не ресурс, теперь ФП популяризируется, однако доводов нет. Никаких нет. Никаких адекватных не сравнений и тестов. Хотя я знаю почему их нет, правильно, мы выучили, что есть задача — есть адекватный инструмент. А иммутабельность точно так же как мутабельность может привести к деградации.
Меня конечно можно упрекнуть в том или ином искажении реальности, просто каждая гарная фича несёт за собой расплату. И как сборка мусора несёт за собой свои нюансы, так и иммутабельность. Просто мне не нравится что её подают как решение проблем распараллеливания.
Я в своё время делал простенький рэйтресер. И мимолётом мне Mamut подсказал рэйтрэсер на эрланге (я к эрлангу очень хорошо отношусь, из всех ФЯ мне он наиболее симпатичен), так вот, рэйтресинг это не для эрланга. Умении масштабироваться — да, есть. Но тока я на C++ сделал то, шо бы реализация на эрланге потребовала ~20 процов. Просто не его конёк. И открытых косяков там не было.
И у мну с Мамутом возник вопрос — а что происходит-то с реальными параметрами в функции? раз оно иммутабельно их можно не копировать? Дима ответ не знал, кроме того что в процессах там всегда копирование, а что внутри — бог его знает. Всё зависит от компилятора/интерпретатора ФП получается. Как мне это напоминает долгие рассказы в этом форуме про возможности оптимизатора дотнета... а на практике ж ничего нет. (Тока опять жеж, не нужно меня упрекать в... нелояльности, сам по себе "дотнетнчик" и сам юзаю, и досих пор доволен, не зря перелез ).
Если кого-то прямо или косвенно обидел, то не со зла.
PS: Хотелось бы услышать по этому всему делу более авторитетное мнение чем моя думка.
Здравствуйте, IT, Вы писали:
IT>Здравствуйте, remark, Вы писали:
R>>Тут тоже надо уточнить одну вещь. Если мы уже провели "само распараллеливание", т.е. провели анализ проблемы, проработали архитектуру, выбрали алгоритмы и т.д. То насколько серьёзные проблемы у нас вызовет в НЕ функциональном языке сделать, допустим, неизменяемый объект, или написать функцию сортировки массива без побочных эффектов?
IT>Здесь можно провести параллель с строготипизированные языки vs нетипизированные. В первом случае компилятор тебе помогает, во втором — это твоя личная проблема. Так же и здесь.
Параллель провести безусловно можно. И я не спорю, что некоторые вещи в ФЯ несколько проще и легче.
Можно так же проводить параллели, например, со скрепкой-помощником из Microsoft Word, которая тоже была призвана помогать.
Но важный момент — насколько сложно без этой помощи? нет, не в абстрактных терминах, а в терминах реального программиста реализующего что-то реальное, сколько времени у него ушло? сколько моральных сил у него ушло? результат какого качества удалось получить? Далее — насколько это помощь именно в том, в чём разработчику хотелось и требуется?
Так же хороший вопрос — а что если компилятор мне не помагает, а мешает?
Здравствуйте, Chrome, Вы писали:
C>Помогите навести ясность. C>Рекламируя функциональные языки, их сторонники утверждают, что программы на этих языках чуть ли не атоматически распараллеливаются.
Если нам не помогут, то мы тоже никого не пощадим.
Потому что принуждение к распараллеливанию из ниоткуда не возьмется 
Хотя я знаю почему их нет, правильно, мы выучили, что есть задача — есть адекватный инструмент. А иммутабельность точно так же как мутабельность может привести к деградации.
