Вот все об этом говорят, и в теории я понимаю что вроде верно говорят. А как начать? Какой можно взять учебный проект и на каком языке чтобы прояснить все до деталей? В голову не приходит.
все что угодно не подойдет. нужна задача, где указанные в пропаганда-статье проблемы всплывают наиболее ярко. я, кстати, не уверен что "бложик на хаскеле" тоже является примером такой задачи. В чем там может быть рейс кондишен ? что два юзера написали в одно и то же время коммент к одной блогозаписи? так это база данных где все хранится должна и может разруливать.
Я думал, вы просто хотите научиться функциональному программированию, а не ищете высокопараллельную задачу. В моей области (финансы) таких задач полно. Но, например, web spider — вполне себе toy project для этой области, хотя тут скорее concurrency, чем parallelism. Ну или любая задача из image processing — процессоров на компьютере сейчас, чай, больше одного.
Задача обязательно должна быть. Вот, для примера берёте любую задачу отсюда и выполняете по мере сил. Если упираетесь в проблему, качаете чьи-то решения и смотрите, как это сделали те, кто уже умеет. http://users.livejournal.com/_darkus_/646993.html
Когда мне было 16 лет, я читал ровно такие же тексты, но там вместо многоядерных процессоров были симметрично-мультипроцессорные системы, а вместо Хаскелля и Эрланга - Пролог.
В упор не понимаю чего они так привязались к этой concurency, и еще ФП как панацею преподносят. Там же CAP с одной стороны и ФП тут не поможет, а с другой стороны у всех все нормально и без ФП живет.
Надо на вход обработчику запросов подавать результат работы предыдущего. Но так никто не делает. Юзают мутабельный стейт в какой-нибудь MVar, которая со встроенной синхронизацией уже.
Короче если у тебя два запроса обрабатываются параллельно - у тебя одна и та же проблема что в дотнетах, что в хаскеле. Да и вообще везде тоже самое с concurency - что в дотнетах, что в хаскелях.
Но, при использовании MVar, в типе функции всегда будет видно, что она IO. А также в функции, которая вызывает эту функцию и т.п. Не знаю дотнета, но сомневаюсь, что в C# это так.
С concerrency сложности не пропадают, конечно, но какая-то помощь от языка и компилятора появляется.
Исходный текст про параллельные вычисления я бы рассматривал как декларацию о "нише" (kill-app), а не как описание всех преимуществ H и FP. Ну, может о том, как автор пришел к FP. Преимуществ и применений Haskell гораздо больше. Совсем не обязательно параллельностями заниматься...
Так я как раз и негодую за то, что как только начинается разговор про ФП - сразу приплетают concurency и преподносят ФП как панацею. А про остальное как-то мимо.
Ну и вот это вот: >There are no data races in purely functional languages because they don’t have mutable variables.
В посылке. Все ФП-языки имеют mutable state, без него просто два потока просто не смогут общаться. Ну и гонки и дедлоки - тоже будут.
Безусловно за счет того что этот опасный код в том же Хаскеле скорее всего будет локализован в небольшом куске, а стейт не будет размазан, там все проще. Но что прям вот нет гонок - это ложь.
Одна переменная, обернутая в lock {} - тоже не имеет ни гонок, ни дедлоков.
На двух таких переменных, как и на двух MVar-ах - можно устроить себе и гонки, и дедлоки.
Понятно что так стараются не делать в Хаскеле, и сплошь и рядом делают в дотнетах. Но это в большей мере только потому что в ФП народ сообращает круче.
Да легко. Счётчик — это бесконечный ленивый immutable список целых, возрастающих на 1.
А вот как реализовать счётчик параллельно выполняющихся запросов — гораздо смешнее вопрос. Вроде как CAP-теорема накладывает на него ограничения. Как их решают в БД (где sequences), я, например, не в курсе; кажется, иногда кэшированием кусков и пропуском значений. Есть ли красивре FP-решение для сериализации, не знаю.
Ну, в Oracle или Postgres sequence гарантирует, что выдаёт строго возрастающие числа, в сколь угодно параллельных запросах. Оно вроде бы шага строго в 1 не гарантирует, он обычно обеспечивает.
В другом месте они приямо говорят: "Selecting the ORDER option ensures that each NEXTVAL request across the cluster will be synchronized so that usage is chronologically ordered. This is achieved by having all sessions share a single cache for this sequence. Each reference to NEXTVAL will involve a lock request to claim a new value".
Понятно, что для линеаризации в рамках одной сессии достаточно NOORDER и просто неповторяющихся чисел.
Да я не об этом. Если запросы параллельные, как можно говорить о "строго возрастающих" числах? Иными словами, время commit параллельных запросов не определяется "строго возрастающим" числом.
"Строго возрастающее" число определяет, какие транзакции вы будете обозревать. Если у вас два типа транзакций - одни читают X и модифицируют Y, другие дописывают новые строки в X, в ACID нет ничего, что бы заставляло транзакции первого типа обозревать какие-либо изменения в X вообще.
![[identity profile]](https://www.dreamwidth.org/img/silk/identity/openid.png){kind=small}
![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png)
timeasmymeasure
no subject
Date: 2012-04-12 05:48 am (UTC)ты за большэвиков или за коммунистовVerilog -- он императивный или функцыональный?no subject
Date: 2012-04-12 06:41 am (UTC)no subject
Date: 2012-04-12 07:16 am (UTC)no subject
Date: 2012-04-12 07:33 am (UTC)no subject
Date: 2012-04-12 07:46 am (UTC)Можно бложек на хаскеле сделать, или вытягивалку картинок с лепры на эрланге, или всё что угодно на скале.
Можно, конечно, тупо решать задачки с Project Euler, но предпочитаю что-нибудь более приземлённое.
no subject
Date: 2012-04-12 09:01 am (UTC)все что угодно не подойдет. нужна задача, где указанные в пропаганда-статье проблемы всплывают наиболее ярко. я, кстати, не уверен что "бложик на хаскеле" тоже является примером такой задачи. В чем там может быть рейс кондишен ? что два юзера написали в одно и то же время коммент к одной блогозаписи? так это база данных где все хранится должна и может разруливать.
no subject
Date: 2012-04-12 09:21 am (UTC)no subject
Date: 2012-04-12 09:41 am (UTC)http://users.livejournal.com/_darkus_/646993.html
no subject
Date: 2012-04-12 08:03 am (UTC)no subject
Date: 2012-04-13 02:51 am (UTC)Вот когда я ещё читать не умел, везде, говорят, рекламировали лисп, и даже пытались поддержать железом.
no subject
Date: 2012-04-12 09:28 am (UTC)no subject
Date: 2012-04-12 01:18 pm (UTC)no subject
Date: 2012-04-12 02:02 pm (UTC)и монадично выражаться можно и на императивном языке. замечательно помогает с линеаризацией.
а вот CPS открывает новые возможности. я даже не о message passing (который я почему-то не вижу как что-то концептуально отличающееся от лока).
no subject
Date: 2012-04-12 10:54 am (UTC)как реализовать, например, счетчик запросов, не используя мутабельные данные?
no subject
Date: 2012-04-12 12:00 pm (UTC)Короче если у тебя два запроса обрабатываются параллельно - у тебя одна и та же проблема что в дотнетах, что в хаскеле. Да и вообще везде тоже самое с concurency - что в дотнетах, что в хаскелях.
no subject
Date: 2012-04-13 08:51 am (UTC)А также в функции, которая вызывает эту функцию и т.п.
Не знаю дотнета, но сомневаюсь, что в C# это так.
С concerrency сложности не пропадают, конечно, но какая-то помощь от языка и компилятора появляется.
Исходный текст про параллельные вычисления я бы рассматривал как декларацию о "нише" (kill-app), а не как описание всех преимуществ H и FP. Ну, может о том, как автор пришел к FP. Преимуществ и применений Haskell гораздо больше. Совсем не обязательно параллельностями заниматься...
no subject
Date: 2012-04-13 09:20 am (UTC)Ну и вот это вот:
>There are no data races in purely functional languages because they don’t have mutable variables.
- наглая ложь же
no subject
Date: 2012-04-13 09:36 am (UTC)no subject
Date: 2012-04-13 09:43 am (UTC)Безусловно за счет того что этот опасный код в том же Хаскеле скорее всего будет локализован в небольшом куске, а стейт не будет размазан, там все проще. Но что прям вот нет гонок - это ложь.
no subject
Date: 2012-04-13 10:26 am (UTC)MVar их не имеет, STM тоже.
Дедлоки у меня возникали при определении тишины в канале. Это не считается.
no subject
Date: 2012-04-13 11:02 am (UTC)На двух таких переменных, как и на двух MVar-ах - можно устроить себе и гонки, и дедлоки.
Понятно что так стараются не делать в Хаскеле, и сплошь и рядом делают в дотнетах. Но это в большей мере только потому что в ФП народ сообращает круче.
no subject
Date: 2012-04-13 03:09 pm (UTC)ну и? там, где без STM может быть race condition, там с STM будет lack of progress (redo).
no subject
Date: 2012-04-16 01:26 pm (UTC)Т.е., формально, мне не кажется, что там ложь.
Скорее уж "умалчивание о проблемах", "great propaganda"...
От проблем синхронизации ничто не избавляет. Даже в БД, для которых поддержка многопользовательской работы подразумевается, надо за этим следить.
no subject
Date: 2012-04-13 03:02 am (UTC)А вот как реализовать счётчик параллельно выполняющихся запросов — гораздо смешнее вопрос. Вроде как CAP-теорема накладывает на него ограничения. Как их решают в БД (где sequences), я, например, не в курсе; кажется, иногда кэшированием кусков и пропуском значений. Есть ли красивре FP-решение для сериализации, не знаю.
no subject
Date: 2012-04-13 08:04 am (UTC)CAP не накладывает ограничения на счётчик. ограничения на счётчик накладывает ACID.
no subject
Date: 2012-04-13 09:19 am (UTC)Про CAP и ACID согласен, погорячился.
no subject
Date: 2012-04-13 02:46 pm (UTC)на самом деле sequence - это инструмент линеаризации обозреваемости committed транзакций.
no subject
Date: 2012-04-14 09:19 am (UTC)В другом месте они приямо говорят: "Selecting the ORDER option ensures that each NEXTVAL request across the cluster will be synchronized so that usage is chronologically ordered. This is achieved by having all sessions share a single cache for this sequence. Each reference to NEXTVAL will involve a lock request to claim a new value".
Понятно, что для линеаризации в рамках одной сессии достаточно NOORDER и просто неповторяющихся чисел.
no subject
Date: 2012-04-15 08:22 am (UTC)"Строго возрастающее" число определяет, какие транзакции вы будете обозревать. Если у вас два типа транзакций - одни читают X и модифицируют Y, другие дописывают новые строки в X, в ACID нет ничего, что бы заставляло транзакции первого типа обозревать какие-либо изменения в X вообще.
no subject
Date: 2012-04-15 08:38 am (UTC)no subject
Date: 2012-04-12 01:16 pm (UTC)