Потому что большинство алгоритмов подразумевают изменение данных на месте. Так же большинство программистов в основном умеют оперировать алгоритмами изменяющими данные, а не работающие с неизменяемыми структурами. Совокупность этих факторов делает программы на функциональных языках относительно медленными. Но, с другой стороны, кода на Хаскеле ощутимо быстрее Питона, так что
Это смотря как эту эффективность измерять. Если программа на f# в три раза короче, в десять раз меньше ошибок и при этом теряет 1% производительности в сравнении с c#, то и хрен с ней. Лучше взять комп побыстрее.
Re: Почему функциональщина считается не эффективной?
Здравствуйте, varenikAA, Вы писали:
AA>Вроде бы даже не так уж и не эффективна:
Потому что железо работает с изменяющимся стейтом. И если на отдельных бенчмарках это не так критично, то в среднем по больнице ситуация далека от радужной.
... << RSDN@Home 1.3.17 alpha 5 rev. 62>>
Re: Почему функциональщина считается не эффективной?
Здравствуйте, AeroSun, Вы писали:
AS>Здравствуйте, varenikAA, Вы писали:
AA>>Почему функциональщина считается не эффективной?
AS>А почему должно быть иначе?
Пуркуа па, почему бы и нет?
Хотя углубившись по ссылке был сильно удивлен что все императивно довольно в фарше.
но ведь по большинству тестов обошел шарпик. хм.
Re: Почему функциональщина считается не эффективной?
сам удивляюсь, но все же синтаксис фш ближе к мат записи, по-моему читать его не сложнее чем си,
правда с индексатором массива некрасиво получилось. потому мой фан ближе к лиспу, он как си только без кучи непонятных стрелочек и звездочек, хотя да эффективность мала,
вопрос открыт. эффективность выполнения, производительность труда или корректность логики.
Re[2]: Почему функциональщина считается не эффективной?
AA>>>Вроде бы даже не так уж и не эффективна: AA>>>https://benchmarksgame-team.pages.debian.net/benchmarksgame/fastest/fsharpcore-csharpcore.html LVV>>Под капотом — одна и та же виртуальная машина. LVV>>Поэтому сравнение не очень информативно. σ>А сравнение, скажем, C++ с OCaml информативно? Под капотом один и тот же x86.
Фадиез и Додиез делались в одной фирме.
С++ и Окамл — разные и по семантике, и по разработчикам.
Если бы делали одни и те же разработчики, то можно было бы говорить о разнице в скоростях.
А так фактически сравнивается квалификация разных команд (помимо разнице в семантике).
Хочешь быть счастливым — будь им!
Без булдырабыз!!!
Re[3]: Почему функциональщина считается не эффективной?
Здравствуйте, varenikAA, Вы писали:
AA>сам удивляюсь, но все же синтаксис фш ближе к мат записи, по-моему читать его не сложнее чем си, AA>правда с индексатором массива некрасиво получилось. потому мой фан ближе к лиспу, он как си только без кучи непонятных стрелочек и звездочек, хотя да эффективность мала, AA>вопрос открыт. эффективность выполнения, производительность труда или корректность логики.
Писать лично мне код приятнее на F#, будь возможность-все на нем бы делал, причем в функциональном стиле.
Но есть нюанс, чисто функциональные подходы создают большой мемори траффик+интенсивную работу GC(если мы говорим конкретно о GC), что сильно ухудшает применимость функциональщины в задачах, где требуется latency.
Здравствуйте, LaptevVV, Вы писали:
AA>>>>Вроде бы даже не так уж и не эффективна: AA>>>>https://benchmarksgame-team.pages.debian.net/benchmarksgame/fastest/fsharpcore-csharpcore.html LVV>>>Под капотом — одна и та же виртуальная машина. LVV>>>Поэтому сравнение не очень информативно. σ>>А сравнение, скажем, C++ с OCaml информативно? Под капотом один и тот же x86. LVV>Фадиез и Додиез делались в одной фирме. LVV>С++ и Окамл — разные и по семантике, и по разработчикам.
F# и OCaml являются представителями одного семейства языков-ML.
По истории происхождения F# тут подробнее: https://fsharp.org/history/hopl-draft-1.pdf
Re[2]: Почему функциональщина считается не эффективной?
Здравствуйте, Poopy Joe, Вы писали:
PJ>Здравствуйте, varenikAA, Вы писали:
AA>>Вроде бы даже не так уж и не эффективна:
AA>>https://benchmarksgame-team.pages.debian.net/benchmarksgame/fastest/fsharpcore-csharpcore.html
PJ>Это смотря как эту эффективность измерять. Если программа на f# в три раза короче, в десять раз меньше ошибок и при этом теряет 1% производительности в сравнении с c#, то и хрен с ней. Лучше взять комп побыстрее.
Там, где код на F# идет в ноздрю по скорости с C#-это код как правило императивный, который проще всего писать тогда сразу на C#.
Re[2]: Почему функциональщина считается не эффективной?
Согласен, хотя не совсем често, т.к. в первом случае вы получили новую коллекцию, а во втором мутировали оригинал.
код по факту разный
F#
open System.Diagnostics
let watch f =
let sw = Stopwatch()
sw.Start()
f()
sw.Stop()
sw.Elapsed
let size = 1000
let origin = Array.init<int> size (fun i -> i + 1)
let funway () =
origin
|> Array.mapi (fun i e -> if i = 0 then e else (e + origin.[ i - 1]))
|> ignore
let impway1 () =
let copy = Array.zeroCreate<int>(size)
origin.CopyTo(copy, 0)
for i = 1 to copy.Length - 1 do
copy.[i] <- copy.[i] + copy.[i - 1]
copy |> ignore
let impway2 () =
for i = 1 to origin.Length - 1 do
origin.[i] <- origin.[i] + origin.[i - 1]
funway |> watch |> printfn "%A" // => 00:00:00.0013835
impway1 |> watch |> printfn "%A" // => 00:00:00.0004016
impway2 |> watch |> printfn "%A" // => 00:00:00.0001720
