MC>Здравствуйте, lomeo, Вы писали: L>>Ну, для Set это не имеет значения, но для некоторых типов (функторов) singleton есть функция pure, она же return. MC>Вот был бы Set монадой... Полагаю, просто разработчик Set'а решил последовать принципу бритвы Оккама для хаскеля: "Не плоди монад сверх необходимого".
Для чего Set должен быть монадой?
Недетерминизм? На списках он лучше.
Для чего ещё?
Yours truly, Serguey Zefirov (thesz NA mail TOCHKA ru)
Здравствуйте, Mr.Cat, Вы писали:
L>>Однако, в Haskell её монадой не сделаешь. MC>А почему?
Если без ТК, то вот пример, как сделать в Хаскеле множества почти монадами:
{-# LANGUAGE NoImplicitPrelude #-}import qualified Data.Set as Set
import Prelude(Int, ($), fromInteger, (+), Ord)
import Data.Set(Set)
return = Set.singleton
m >>= k = Set.unions $ Set.toList $ Set.map k m
fail = Set.empty
test = do x <- Set.fromList [1..3]
y <- Set.fromList [1..3]
return (x+y)
Операция (>>=) здесь имеет тип (Ord a, Ord b) => Set a -> (a -> Set b) -> Set b. Другими словами, ее тип практически совпадает с типом (>>=) из класса Monad, но контекст (Ord a, Ord b) все портит.
Здравствуйте, awson, Вы писали:
A>Да, это так. Но сейчас это уже не пропасть. GHC — очень большой и там есть просто неоптимально сделанные места, причем многие давно известны, но не хватает manpower, чтобы этим заниматься. Например, скорость компиляции выросла в 5 раз при переходе (если я правильно помню) от 6.4 к 6.6 просто потому, что пофиксили баг производительности.
путаешь. раза в три в 6.8 просто потому, что перестали использовать gcc. плюс код стал быстрее на 10-20%
а тормозит он потому, что написан на хаскеле — ленивом fp языке
Здравствуйте, BulatZiganshin, Вы писали:
BZ>путаешь. раза в три в 6.8 просто потому, что перестали использовать gcc. плюс код стал быстрее на 10-20%
Ты прав про 6.8, действительно — это был переход от 6.6 к 6.8. Я таки поискал, вот — про 5 раз. По поводу gcc — для *не* -O2 и до 6.8 gcc не использовался, однако оно все равно компилировалось в разы медленней. Я, откровенно говоря, сходу не нашел ссылки на тот баг в ghc < 6.8, который я имел в виду, притом, что я не помню в чем он конкретно состоял. Но, даже и устранение gcc и perl'а — разве это не свидетельство именно *технических* проблем?
BZ>а тормозит он потому, что написан на хаскеле — ленивом fp языке
Ну да — в том смысле, что его никто специально не оптимизировал в конкретно этом смысле. Да, на сегодняшем уровне GHC без специальных костылей и без учета качества рантайма (который примерно сопоставим) — только по качеству генерируемого кода проиграет ocaml'у раза в полтора, максимум два. Но *не больше*. Однако, с моей точки зрения, на 90% это — инженерная задача, а не проблема с ленивостью как таковой. Остальное (в смысле времени компиляции) обусловлено тем, что Хаскелл, очевидно, более сложный язык.
Здравствуйте, awson, Вы писали:
BZ>>путаешь. раза в три в 6.8 просто потому, что перестали использовать gcc. плюс код стал быстрее на 10-20% A>Ты прав про 6.8, действительно — это был переход от 6.6 к 6.8. Я таки поискал, вот — про 5 раз. По поводу gcc — для *не* -O2 и до 6.8 gcc не использовался, однако оно все равно компилировалось в разы медленней. Я, откровенно говоря, сходу не нашел ссылки на тот баг в ghc < 6.8, который я имел в виду, притом, что я не помню в чем он конкретно состоял. Но, даже и устранение gcc и perl'а — разве это не свидетельство именно *технических* проблем?
BZ>>а тормозит он потому, что написан на хаскеле — ленивом fp языке A>Ну да — в том смысле, что его никто специально не оптимизировал в конкретно этом смысле. Да, на сегодняшем уровне GHC без специальных костылей и без учета качества рантайма (который примерно сопоставим) — только по качеству генерируемого кода проиграет ocaml'у раза в полтора, максимум два. Но *не больше*. Однако, с моей точки зрения, на 90% это — инженерная задача, а не проблема с ленивостью как таковой. Остальное (в смысле времени компиляции) обусловлено тем, что Хаскелл, очевидно, более сложный язык.
слушай, ты рассказываешь о вкусе устриц профессиональному дегустатору
6.8 на моей проге раза в 3 быстрее. без -O большой разницы нет, думаю как раз те самые 10-20%, которые обусловлены улучшением кодогенерации (ghc ведь компилируется сам собой)
далее — winhugs загружает прогу раз в 10 быстрее, чем ghci. твоя вера в то, что ленивость (и ещё монады, широко используемые в реализации ghc) замедляют программы всего в 1.5 раза, а не в 10 или к примеру 100 — опять же прелположение из воздуха. реально разница в 1.5-2-3 раза идёт только если написать программу в императивном низкоуровневом стиле, без всякой ленивости и связанных с ней типов данных — списков, к примеру. при написании же в нативном стиле разница достигает сотен раз — смотри к примеру статьи:
Здравствуйте, BulatZiganshin, Вы писали:
BZ>слушай, ты рассказываешь о вкусе устриц профессиональному дегустатору
Ну, ты человек публичный, любишь там сям пописать. Я лет 5 читаю все mailing lists, касающиеся Хаскелла, поэтому знаю кому что рассказываю.
BZ>6.8 на моей проге раза в 3 быстрее. без -O большой разницы нет, думаю как раз те самые 10-20%, которые обусловлены улучшением кодогенерации (ghc ведь компилируется сам собой)
И? Если без -O нет большой разницы, а с -O есть, это как-то доказывает теорию об *исключительном влиянии* gcc? Или, может быть, это бага в оптимизаторе, э?
BZ>далее — winhugs загружает прогу раз в 10 быстрее, чем ghci. твоя вера в то, что ленивость (и ещё монады, широко используемые в реализации ghc) замедляют программы всего в 1.5 раза, а не в 10 или к примеру 100 — опять же прелположение из воздуха. реально разница в 1.5-2-3 раза идёт только если написать программу в императивном низкоуровневом стиле, без всякой ленивости и связанных с ней типов данных — списков, к примеру. при написании же в нативном стиле разница достигает сотен раз — смотри к примеру статьи:
Почему "вера"? Ты думаешь, я программ на Хаскелле не писал? Я пишу про качество генерируемого кода в сравнении с окамлом, ты мне про монады и списки. Что такое "нативный" стиль для окамла? Как на окамле обойтись без императивного стиля и без монад одновременно? Ты что с чем сравниваешь?
BZ>Rewriting Haskell Strings [http://www.cse.unsw.edu.au/~dons/papers/fusion.pdf] BZ>An approach to fast arrays in Haskell [http://www.cse.unsw.edu.au/~chak/papers/afp-arrays.ps.gz]
Этим статьям сто лет в обед. Те, кому интересна производительность, давно это все прочитали. Я — в том числе.
Я никак не пойму, чего ты силишься донести до нашего разума? Что *наивный* Хаскелл (пока) не подходит для числодробилок? Да, не подходит. Только дурак будет с этим спорить. Что на С++ можно написать чтоб работало быстрее? Да, можно. Я сам, когда нужна скорость, на C++ пишу. Что-то еще?
Здравствуйте, awson, Вы писали:
BZ>>6.8 на моей проге раза в 3 быстрее. без -O большой разницы нет, думаю как раз те самые 10-20%, которые обусловлены улучшением кодогенерации (ghc ведь компилируется сам собой) A>И? Если без -O нет большой разницы, а с -O есть, это как-то доказывает теорию об *исключительном влиянии* gcc? Или, может быть, это бага в оптимизаторе, э?
не может. в ghc есть ключик, включающий/выключающий использование gcc
BZ>>далее — winhugs загружает прогу раз в 10 быстрее, чем ghci. твоя вера в то, что ленивость (и ещё монады, широко используемые в реализации ghc) замедляют программы всего в 1.5 раза, а не в 10 или к примеру 100 — опять же прелположение из воздуха. реально разница в 1.5-2-3 раза идёт только если написать программу в императивном низкоуровневом стиле, без всякой ленивости и связанных с ней типов данных — списков, к примеру. при написании же в нативном стиле разница достигает сотен раз — смотри к примеру статьи: A>Почему "вера"? Ты думаешь, я программ на Хаскелле не писал? Я пишу про качество генерируемого кода в сравнении с окамлом, ты мне про монады и списки. Что такое "нативный" стиль для окамла? Как на окамле обойтись без императивного стиля и без монад одновременно? Ты что с чем сравниваешь?
на окамле у тебя просто нет удобных монад, поэтому тебе не придёт в голову их использовать как это сделано в ghc. окамл — строгий язык, в нём нет еype classes, а это основные источники замедления haskell. наконец, многоаргументные функции в нём не каррируются — это тоже источник замедления хаскела
BZ>>Rewriting Haskell Strings [http://www.cse.unsw.edu.au/~dons/papers/fusion.pdf] BZ>>An approach to fast arrays in Haskell [http://www.cse.unsw.edu.au/~chak/papers/afp-arrays.ps.gz] A>Этим статьям сто лет в обед. Те, кому интересна производительность, давно это все прочитали. Я — в том числе.
A>Я никак не пойму, чего ты силишься донести до нашего разума? Что *наивный* Хаскелл (пока) не подходит для числодробилок? Да, не подходит. Только дурак будет с этим спорить. Что на С++ можно написать чтоб работало быстрее? Да, можно. Я сам, когда нужна скорость, на C++ пишу. Что-то еще?
а в каком по-твоему стиле ghc написан? тот код, который всего в несколько раз медленней сишного — пишется на низком уровне, и это ещё сложнее чем просто писать на C
ghc же, как и любые джругие программы на хаскеле, написан высокоуровнево, и это означает применение ленивости, монад и всех прочих кунштюков.это и делает его таким медленным в сравнении с хагсом, который реализует сравнимую с ghci функциональность
Здравствуйте, BulatZiganshin, Вы писали:
BZ>не может. в ghc есть ключик, включающий/выключающий использование gcc BZ>на окамле у тебя просто нет удобных монад, поэтому тебе не придёт в голову их использовать как это сделано в ghc. окамл — строгий язык, в нём нет еype classes, а это основные источники замедления haskell. наконец, многоаргументные функции в нём не каррируются — это тоже источник замедления хаскела BZ>не может. в ghc есть ключик, включающий/выключающий использование gcc BZ>а в каком по-твоему стиле ghc написан? тот код, который всего в несколько раз медленней сишного — пишется на низком уровне, и это ещё сложнее чем просто писать на C BZ>ghc же, как и любые джругие программы на хаскеле, написан высокоуровнево, и это означает применение ленивости, монад и всех прочих кунштюков.это и делает его таким медленным в сравнении с хагсом, который реализует сравнимую с ghci функциональность
Вот ты сам не поленился новые ghc с -fvia-C погонять и сам открыл, что все работало в 5 раз (ну, у тебя — в 3) медленнее *только* потому, что вместо нативной компиляции запускался сначала perl, а потом — gcc, т.е., проблема была чисто инженерная, а Хаскелл как язык тут вообще никаким боком. После этого ты буквально тут же начинаешь атрибутировать все проблемы со скоростью работы ghc тому, что он написан на "меделенном" Хаскелле. Еще для примера: был, например, глюк GHC с экспоненциальным временем компиляции type synonyms. Пока с этим не сталкивались, никого это особенно не интересовало, когда начало мешать — поправили и скорость компиляции некоторых программ с практической точки зрения выросла бесконечно. Про другие неоптимальные куски SPJ несколько раз упоминал, но оно работает и пока та или иная проблема не окажется критической — вряд ли кто-нибудь будет особенно чесаться.
Потом, GHC уже много лет, так куча legacy кода. С тех пор стали лучше понимать как работает GHC и как на *идиоматическом* Хаскелле писать намного более быстрые программы. Но никто не кинется переписывать половину GHC, чтобы оно работало быстрее. Или вот, например, компилятор mingw gcc в несколько раз медленнее microsoft c при примерно одинаковом качестве генерируемого кода. Почему?
Обычные расчеты на Хаскелле пишутся на обычном уровне и, условно говоря, оно получается в 1,5-5 раз медленнее сишного. Кое-какой код, написанный на низком уровне, после переписывания на идиоматический становится *быстрее*.
Предмет обсуждения стал расплывчатым и постоянно меняется местами язык и реализация, например, твоя любимая тема что type classes — зло для производительности, поскольку приходится в runtime таскать за собой словари, относится на 90% к существующим имплементациям, а не к Хаскеллу как таковому, да и GHC кое-что умеет optimize away. Поэтому я сформулирую свою позицию более конкретно — подавляющее большинство программ можно написать на идиоматическом Хаскелле (ghc), оставаясь в порядке производительности идиоматического C (gcc), те, что нельзя — лечатся точечными инъекциями C.
A>Предмет обсуждения стал расплывчатым и постоянно меняется местами язык и реализация, например, твоя любимая тема что type classes — зло для производительности, поскольку приходится в runtime таскать за собой словари, относится на 90% к существующим имплементациям, а не к Хаскеллу как таковому, да и GHC кое-что умеет optimize away. Поэтому я сформулирую свою позицию более конкретно — подавляющее большинство программ можно написать на идиоматическом Хаскелле (ghc), оставаясь в порядке производительности идиоматического C (gcc), те, что нельзя — лечатся точечными инъекциями C.
Присоединюсь.
Факты (наподобие скорости Language.C, мой опыт) подтверждают эту точку зрения.
Yours truly, Serguey Zefirov (thesz NA mail TOCHKA ru)
Здравствуйте, FR, Вы писали:
FR>A разве у Хаскеля не одна пригодная для реальной работы реализация?
Для *реальной* работы — одна. Для *микробенчмарков* — не одна.
T>>Дело в том, что они не обобщаются. Map.singleton /= Set.singleton. Твои проблемы, однако, решаются использованием import Data.Map qualified as Map — замени Data.Map на Data.IntMap и разницы не заметишь. RD>Точно никак не обобщаются? Я допускаю, что может быть какая-то суровая причина на то. Особенно в случае с Map. Но глядя на singleton в Seq и Set я вижу следующие типы:
RD>a -> Set a RD>a -> Seq a
RD>Неужели type inference в haskell не просечет что если я делаю singleton "1" и дальше пользуюсь им как Set, то я использую singleton из Set а не из Seq? Особенно, если есть некий typeclass Singletonable с этим методом и Set с Seq являются частными случаями.
Я, собственно, и не предлагал.
