Ответ на »сообщение 1118« (Geniepro)
___________________________

Ответ на »сообщение 1117« (Артем)
___________________________
"Почему никто не использует функциональные языки" Филип Вадлер
http://www.softcraft.ru/paradigm/fp/whynotfp.shtml

Там как раз анализируются причины незатребованности ФЯ...

Не устаю восхищаться Игорем Анатольевичем: хорошо выбрал ("умение выделять главное -- главный показатель ума") и перевел пару текстов -- вот кого бы ведущим этой ветки.

Помнится, как-то он сказал, что для ФЯ еще не было своего Вирта...

Ответ на »сообщение 1130« (Артем)
___________________________

Не могли бы вы привести исходник вашего 64-битного кода на F# ? :)

let dec32 n =
    let f32 x y z =
        let rec f232 x y z = if (y+1)=x then z else f232 x (y+1) (z+1)
        in if x=1 then 0 else f232 x y z
    in f32 n 0 0

let dec64 n =
    let f64 x y z =
        let rec f264 x y z = if (y+1L)=x then z else f264 x (y+1L) (z+1L)
        in if x=1L then 0L else f264 x y z
    in f64 n 0L 0L

let rec testtail k v = if k=1 then v else testtail (k-1) (v+1)
let test n = testtail n 1

let Nd32 = 1000000000
let Nd64 = 1000000000L

let st = System.DateTime.Now
let r  = dec32 Nd32
let ft = System.DateTime.Now
let t  = time ft - time st

do  System.Console.WriteLine("dec32 {0} == {1}, time == {2}", Nd32, r, t)

let st2 = System.DateTime.Now
let r2  = dec64 Nd64
let ft2 = System.DateTime.Now
let t2  = time ft2 - time st2

do  System.Console.WriteLine("dec64 {0} == {1}, time == {2}", Nd64, r2, t2)

PS. Ну про Release-то я знаю... :-))

ЗЗЫ. Кстати, понять не могу, выделил в C#-проге эти циклы в отдельные функции - 64битная стала выполняться за те же 6 сек.. Что за дела? почему в теле main она работала 7.3 сек?

Ответ на »сообщение 1129« (Geniepro)
___________________________
Действительно, на С# 32-битный расчёт в полтора раза быстрее, чем на F#, но 64-битный - на 20% медленнее!
Не могли бы вы привести исходник вашего 64-битного кода на F# ? :)

Кстати, а как Вы включаете оптимизацию в .NET? А то я, признаюсь, не в курсе... - Кнопкой включаю :)
Если быть точным, то это не оптимизация .Net, а оптимизация компилятора C#. (VS:Project/MyProject properties/Build/Optimize code)

Ответ на »сообщение 1124« (Артем)
___________________________

Так почему же тогда в следующем примере на C#, вы выбрали 64-битный?

Да, я так и думал, что Вы мне именно ЭТО припомните... :-))
Но дело в том, что этот тест я проводил и с 32-битными числами, и с 64-битными. Да, я недоглядел, и выложил куски кода с разными разрядностями. В этом виноват!

НО! Те значения времени выполнения я привёл для 64-битных тестов!
Ну хорошо, я немного приукрасил результаты, реально должно выглядеть так:

bits  C#    F#    Haskell(GHC)
32    1.2s  1.8s  5.8s
64    7.3s  6.0s  ??? (не знаю, как указать int64 в Хаскеле)

Действительно, на С# 32-битный расчёт в полтора раза быстрее, чем на F#, но 64-битный - на 20% медленнее!

Кстати, я, оказывается, зря наезжал на компилятор GHC - нужно просто уметь им пользоваться! :)
Скомпилировал им (с ключём оптимизации -O ) ту же самую функцию Клини

dec:: Int -> Int
dec n = f n 0 0 where
      f x y z  = if x==1 then 0 else f2 x y z where
              f2 x y z = if (y+1)==x then z else f2 x (y+1) (z+1)

и она тут же перестала нагружать стек и выполнилась более-менее быстро, хотя и в три раза медленнее, чем та же функция на F#.

В-общем, всё-таки не стоит считать Хаскель просто игрушкой. ;-)


Как видите, миллиард влазит и в 32-битный целый. :)

Спасибо, вижу! :))

ЗЫ. Кстати, а как Вы включаете оптимизацию в .NET? А то я, признаюсь, не в курсе... :-))

Ответ на »сообщение 1127« (Артем)
___________________________
Сложность все больше становится неконтролируемой.
Боюсь, что и ФП с этой проблемой не покончит :)

Так 20-летний пример внедрежа ООП в массы показывает, что это и не требуется. Достаточно под видом борьбы с кризисом переключить внимание всех на нечто такое особое, что подается как панацея. Пока разберутся в чем дело, успеют по уши погрязнуть в том, что для них станет привычным, удобным и без непременной совместимости с чем любое новое (или хорошо забытое старое) будет просто отторгаться.

Программисты IMHO упорно хотят облегчать себе жизнь, требуя по максимуму самых невероятных наворотов в языках и инструментах (даешь скрещивание ФП с ООП, а заодно уж и с генетическим программированием!), часто не понимая, что одно из самых важных, бесценных и утраченных качеств - чувство меры. Часто нужно идти на сильные ограничения и самоограничения, чтобы плод твоего творчества/труда поддавался последующему разумному контролю по сложности и через 3-5 лет не шел в корзину, а мог находить свое развитие и применение.

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

Ответ на »сообщение 1123« (bb)
___________________________
Сложность все больше становится неконтролируемой.
Боюсь, что и ФП с этой проблемой не покончит :)

Ответ на »сообщение 1124« (Артем)
___________________________
Пардон, я вместо F#-вского Haskell-вский тектст запхал в прошлом сообщении. Но суть от этого не меняется.

let rec f2 x y z = if (y+1) = x then z else f2 x (y+1) (z+1)
let f x y z = if x = 1 then 0 else f2 x y z
let dec n = f n 0 0
let Nd = 1000000000
do  Printf.printf "dec %d = %d\n" Nd (dec Nd)

Ответ на »сообщение 1118« (Geniepro)
"Почему никто не использует функциональные языки" Филип Вадлер
http://www.softcraft.ru/paradigm/fp/whynotfp.shtml
Понятно теперь, откуда Jack черпает лозунги:
Функциональное программирование прекрасно, оно - радость созерцания. Как только кто-то поймет функциональное программирование, он немедленно перейдет к нему. Массы, которые застряли в устаревшем императивном и объектно-ориентированном программировании, делают это из слепого предубеждения. Они просто не понимают.

Ответ на »сообщение 1121« (Geniepro)
___________________________
Ув. Geniepro! Как вы думаете, какой тип для x,y,z выбирается в результате type inference?

dec n = f n 0 0
f x y z  = if x == 1 then 0 else f2 x y z
f2 x y z = if (y+1) == x then z else f2 x (y+1) (z+1)
main = print (dec 1000000)

Так почему же тогда в следующем примере на C#, вы выбрали 64-битный?

long x, y, z;
const long N = 1000000000L;
x = N; y = 0; z = 0;
while ((y+1) != x)
{
    y++; z++;
}

Здесь (если у вас, конечно, не 64-битная Винда) идет эмуляция 64-битной арифметики. Для корректного сравнения надо было написать так:

int x, y, z;
const int N = 1000000000;
x = N; y = 0; z = 0;
while ((y + 1) != x)
{
  y++; z++;
}

Как видите, миллиард влазит и в 32-битный целый. :)
Даже без включения оптимизации (надеюсь, вы знаете, что и в .Net можно включить оптимизацию) код выполнился гораздо быстрее.

Вывод. Вот такие горе-тесты, как в сообщении 1088, и дают искаженную картину производительности.

P.S. Gienpro! Не обижайтесь. Просто тесты должны быть более продуманы...

Ответ на »сообщение 1122« (Сергей Перовский)
___________________________

Кстати, многие аргументы могут быть перенесены и в ветку по Оберонам.

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