Как функционально программировать для параллельных вычислений на C#?

Question

[Сергей Кореневский]

Много слышу, что за функциональным программированием будущее, и при этом приводят пример F# и Lisp. Одновременно попадается материал о том, что C# так же идет в ногу со временем и имеет функциональную возможность. Но нигде нет материала, чтобы было описание C# как функциональное параллельное программирование.
Где и какой материал на эту тему есть?
.
Я в начале думал, что, мол, F# более перспективный, чем C#, меня синтаксис испугал в F#. А может, не в языке проблема, а в способе программирования? Зачем учить новый велосипед, если можно пользоваться старым?
Я имею ввиду не просто параллельное программирование, а именно, чтобы оно было функциональным. Чтобы не приходилось задумываться над дебагом и изменяемостью объектов.

Answer 1

[Александр Павлов]

Возможно Вам стоит посмотреть в сторону PLINQ.

Answer 2

[khimalex]

Чисто функционально, как в F#, на C# будет сложно что-то сделать, а так:
Как упоминалось - это PLINQ.
А ещё метод Task.ContinueWith.
Обратите внимание что лучше использовать в сочетании с Task.WhenAll, тогда будет параллельность.
Не помню точно, но то ли Дж. Рихтер упоминал, то ли Ст. Клири, что Task создавали с прицелом на функциональный подход к разработке.
Ещё есть TPL Dataflow и Rx.NET.
Это более высокие уровни абстракции над Task.
И всё это можно объединить как TPL.

Answer 3

[chibitko]

чтобы разрабатывать на C# в функциональном стиле нужно использовать immutable objects - https://habr.com/post/266873/
это не всегда оправдано, т.к. требует больше ресурсов, но позволяет избегать сложных багов с разделяемыми объектами

Answer 4

[dollar]

Много слышу, что за функциональным программированием будущее

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

Comments

[Сергей Кореневский]

Если бы не гнался бы то до сих пор на C# императивно бы программировал только Goto нет в C#, а так как в старом досовском бейсике.
.
Я думаю надо изучать патерны, стили, шаблоны, любой чужой опыт полезен.
Тем более масшабная многопроцессорность это тренд сегодняшнего времени и он в новинку по сути. Прежде это была задача не обязательна для быта, но теперь она обязательна для любой сложности проектов.

[Сергей Кореневский]

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

[dollar]

Не все задачи можно распараллелить даже чисто логически. А если это легко, то и париться не нужно.

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

Ну а мелкие задачи типа юзерского интерфейса и т.п., которые не требуют ресурсов, вполне себе пусть живут на одном ядре. Там распараллеливание действительно производит ОС, но на уровне отдельных приложений. И об этом тоже, само собой, не нужно париться.

[dollar]

Вот, например, мне нужно сгенерировать рандомную карту для игры - долгий процесс со 100% нагрузкой на ЦП. Он состоит из этапов, каждый из которых использует результат предыдущего этапа. Как это распараллелить? Никак. Каждый этап - это последовательность однотипных операций с картой, для которой выделена память. Все обращаются к одной и той же памяти. Как это распараллелить? Никак.

[Сергей Кореневский]

А почему бы и нет, то чтобы ОС знала зависимости функции и сама решала о параллельном вычислении. Если зависимость последовательна но ОС решит о том что ее надо последовательно выполнять а если зависимость паралельная, что пусть ОС этим париться.
.
Я вижу Вы не против того что диструктор и сборщик мусора автоматический и Вас это не парит. А я вот общался с С++шником и он мне с пеной доказывал что код должен быть контролируем (удаление объектов).
.
Почему не выйти на более высокую абстракцию где программист будет писать трлько бизнес логику и не париться ядрами. А это уже наступило. ПК уже растут в ядрах, а дальше будет больше и больше ядер.
.
У меня массив, его можно параллельно вычислять. Тем более по статистике большие нагрузки всегда в большинстве случаев приходяться на массивы. Даже если массив состоит из двух сложных элементов.

[dollar]

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

Вот если у вас есть конкретная(!) задача, реализация которой требует максимальной скорости, вот тогда и можно думать в сторону многопоточности, да и то не всегда.

[Сергей Кореневский]

dollar, спасибо за совет. Так и зделаю.

[Олег]

Сергей Кореневский, у вас есть ссылка на источник информации, утверждающий, что ФП это именно та чушь про ядра и синхронность, что вы написали? Специально погуглил даже, вдруг я какое-то другое ФП всё время знал, на нашел ничего нового.

[Сергей Кореневский]

Ну драсте, вместо того чтобы искать ответ у спеца на свои вларосы, наоборот я доказываю свой вопрос.
https://m.habr.com/post/142351/, я долго не искал что бы дать краткую ссылку на Ваш вопрос, с телефона имхо пишу .
Вы наверно поверхностно знанте о ФП. Причем я замечу что Вы судмте о ФП исключительно по JS. Но ФП это не только JS. А в добавок у JS будет большое будущее в параллельных вычислениях, всего несколько лет назад было трудно предположить что JS можно использовать как в сервере. В предь не судите о ФП по JS, и интересуйтесь о других ФП.

[Сергей Кореневский]

Здравствуйте, вот пожалуйста посмотрите это видео, описаны проблемы ООП в C#. О проблемах в языке сказано с точки зрения различгых гуру програмирования этого языка. Рекомендую смотреть на ускоренке , вы пользуетесь для прослушивания ютуба Кастов ускоренкой? Зря!
https://youtu.be/zqxVI_kEdq8

[ayazer]

Сергей Кореневский,

только Goto нет в C#

есть https://docs.microsoft.com/en-us/dotnet/csharp/lan...

[Сергей Кореневский]

ayazer, и я об этом же, что в любом случае идти со временем придется.

Answer 5

[Виктор П.]

Привет!
Первое, .net языки транслируются в промежуточный язык (IL) при компиляции. То, что можно написать на F#, можно так же написать на C#, разницы не будет никакой. F# выбирают лишь из-за синтаксиса (кому он нравится).
То есть на F# вы будете писать в функциональном стиле, но это не даст никаких преимуществ перед c#. Lisp и F# так же некорректно сравнивать, у них разные компиляторы и разные механизмы обработки. Если есть желание, попробуйте функциональные языки, вроде lisp. Утверждение, что за ним будущее, спорное. В энтерпрайзе применяют c# и java. И будут применять в будущем.
Второе. Для параллельных вычислений не обязательно писать на функциональных языках. Параллельные вычисления не сложно делать и на c#, но, как уже сказали, далеко не все операции можно распараллелить, это не зависит от языка. А иногда этим и не нужно заниматься. Например, веб программирование. Сервер имеет свои механизмы распараллеливания, он обрабатывает одновременно много различных запросов от пользователей. При этом со стороны программиста не нужно писать что-либо, касаемое параллельности.
Запрос от пользователя - валидация данных - запрос в базу - упаковка ответа - возврат ответа. Чисто теоретически можно распараллелить отдельно взятый шаг, но зачем? Не факт, что это прибавит производительности.

Для информации, вы спрашивали, посмотрите лямда-вычисления на c#

Answer 6

[DarkByte2015]

В F# имхо самый красивый и понятный синтаксис из всех чисто ФП-шных ЯП. Учи дальше и разберешься. Другой вопрос - целесообразность... Я лично не вижу смысла ни в F#, ни в Lisp, Clojure, Haskell... Ну просто вакансий на них почти нет. А зачем учить то что не востребовано. Другой вопрос что во многих современных языках есть элементы ФП-шности. Даже в чистом Си можно передавать указатели на функции в параметрах, не говоря уж о C#. Передача функций как параметры это первый шаг (функции высшего порядка). Простейший пример монад это IEnumerable в C#, а в Java 8 появился тип Optional - монада MayBe. Так что лучший вариант это комбинировать функциональные приемы с ООП в "классических" языках.