Ответ на »сообщение 625« (Денис Зайцев)
___________________________
Ну что ж. Видимо я был неправ, когда посчитал что цифр слишком много.
Наверное их никогда много не бывает. :))
Так что приведенные замеры на работе фиббоначи все таки оказались полезными.


Но те же функциональные языки сжирают в десятки раз больше ресурсов, чем императивные (в том числе и такой ресурс, как время процессора), не так ли?


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

Опять таки, я не буду говорить что ФЯ так же быстры как и ИЯ. Просто скажу что разница идет на проценты а не в разы.
Другой вопрос - скриптовые языки, которые не компилируются. Там да, разница в скорости может достигать от 10 до 100 раз. Но скриптовые языки не обязательно функциональные. PHP, Perl, Python, Ruby - все это полноценные императивные языки. И отставание в скорости тут не из за императивности или функциональности, а из за отсутствия компилятора. Об этом говорит и наличие скажем компилятора для Python, который доводит скорость работы python программ до нормальной. Правда это экзотика. Им практически никто не пользуется.
Просто потому что задачи, которые решаются на python в подавляющем большинстве случаев достаточно быстро работают.

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

А учитывая то что на функциональных языках распараллеливать программы либо в разы легче, либо вообще автоматом делается, то получается что писать существенно более быстрые программы легче на ФЯ нежели на ИЯ.

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

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


Хоть бы в скобочках 2-3 таких языка привели. Только те, в которых вычисление 100-разрядного числа можно выполнить с помощью встроенных средств языка (без дополнительно написанных программных "костылей"


assembler

- их, ясное дело, можно к любому языку "привинтить" :))

А чем не нравится "привинчивание"? Встроенных возможностей на всех не напасешься. Между прочим, операции с большими числами, как правило характерезуются тем, что их нужно выполнять максимально быстро, поэтому все реальные проэкты, работающие с большими числами до сих пор пишут на Си и assembler

>>>Почему компилятор языка не может вывести меня за эти жалкие рамки в
>>>64 бита?

>>>Может

Хороший ответ, а главное - полный :)
Хоть бы в скобочках 2-3 таких языка привели. Только те, в которых вычисление 100-разрядного числа можно выполнить с помощью встроенных средств языка (без дополнительно написанных программных "костылей" - их, ясное дело, можно к любому языку "привинтить" :))

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

Почему компилятор языка не может вывести меня за эти жалкие рамки в 64 бита?

Может

Добавлю еще пару слов для ясности :)
Меня всегда удивляло, почему при наличии такой большой памяти я не могу в какой-нибудь паскалевской или сишной программе взять и без всяких заморочек посчитать число, в котором 100 десятичных разрядов. Почему компилятор языка не может вывести меня за эти жалкие рамки в 64 бита? И это мне представлялось почти какой-то "родовой" убогостью традиционных языков программирования. И тут появляются языки, в которых эти вопросы решены. И все! Я уже заинтригован :) - в полку любителей поработать с ФЯ прибыло.

>>>Да, но хватит перемывать одни и те же косточки :)) От цирф прогона этого
>>>чортовго фибоначи уже в глазах рябит. We get the messge :)) Let's move on.

1) Я так понимаю, что Фибоначчи - это просто для примера. Он же не виноват, что представляет собой блестящий пример нелинейной рекурсии :)
А насчет цифр я с Вами не согласен. Если бы я, допустим, был бы противником всяких ФЯ и горячим сторонником работы исключительно только в С++, Java или С#, то признаюсь - один только пример с вычислением числа из 100 или более разрядов с помощью одних только встроенных средств языка программирования смог бы заставить меня более уважительно смотреть в сторону Haskell или Lisp. Тут "агитация" работает сразу, на уровне "подсознания" - а ну-ка назовите языки, на которых я могу "с ходу" посчитать факториал 100 и программа это дело "проглотит" и при этом никаких библиотек, кроме встроенных, мне не потребуется.


2) После последних постов боюсь не "вписаться в тему", но все-таки...
Может кто из знатоков не сочтет за труд помочь :)
Меня интересуют "физические" основы представления структур данных в различных языках и, в связи с этим, возник один вопрос.
В Haskell, Lisp и, я так понимаю, в большинстве других ФЯ "базисной" структурой являются списки. С другой стороны, в Haskell имеется модуль Array, который позволяет импортировать базовые возможности для представления и работы с массивами. Нигде не смог найти точного описания, что из себя представляет такой массив на "физическом" уровне: связанный список с указателями, для которого используется механизм индексации или это "настоящий" массив, в котором все элементы занимают смежные поля памяти и индексация выполняется путем вычисления адреса как в "обычных" массивах в императивных языках? Если это связанный список кортежей, то интересно, как же обеспечивается быстрота доступа по индексу? Может кто в курсе дела, подскажите или дайте ссылочку. Заранее спасибо.

Многопоточность интересует нас лишь постольку, поскольку позволяет увеличить производительность программы. Иначе она не нужна, я так думаю

Вы не совсем правы. Многопоточность упрощает проектирование систем параллельного обслуживания, при этом вся сложность распределения процессорного времени на каждого клиента, реализуется планировщиком операционной системы. Грамотно спроектированная вертушка на одном процессоре всегда быстрее многопоточности, иногда занчительно, поскольку содержит в себе встроенный планировщик, который может более эффективно обслуживать и меньше грузить процессор сам по себе. Кстати, в Windows для этого есть фиберы, которые также как и потоки призваны упростить труд программиста.

Ответ на »сообщение 624« (Jack Of Shadows)
___________________________
Меня давно интересует один вопрос, связанный с отношением ФП и многопоточности:

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

Но те же функциональные языки сжирают в десятки раз больше ресурсов, чем императивные (в том числе и такой ресурс, как время процессора), не так ли?

Таким образом получается, что выигрывая не более чем в N раз, гда N - число процессоров (а ведь не каждую задачу вообще можно распараллелить), мы, с другой стороны проигрываем в M раз, где M >= 10. Выигрыш теоретически возможен, только если N > 10.

В свете вышесказанного, может быть несколько преждевременно говорить о производительности как о сильной стороне ФП?

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

Разве эта ветка не должна всячески пропагандировать ФП и ФЯ?


Да, но хватит перемывать одни и те же косточки :)) От цирф прогона этого чортовго фибоначи уже в глазах рябит. We get the messge :)) Let's move on.


Ну, это вообще смешно...
Ну что мешает распараллелить виртуальную машину, так, что бы каждый поток она выполняла на отдельном ядре?


Я думаю разработчикам скриптовых языков далеко н так смешно как кам.
Может потому что они "в теме" так сказать ? :))
Если бы бы ло легко сделать многопроцессорную многопоточность, что наверное уже давно бы сделали, особоенно PHP, который имеет нехилую коммерческую поддержку и до сих пор является платформой номер 1 в интернете.

Вот разберетесь, потом расскажете нам, что ж там такого смешного.


Не многоядерность же. Каким боком она относится к принципам ФП?


Не к принципам, а к востребованности. Когда надо нагрузить все 16 ядер, то у вас вобщем то всего 2 выхода.
Либо по старинке в ручную управлять многопоточностью (невероятно трудно и доступно 1% от числа всех программистов), либо переходить на язык, берущий распараллеливание на себя, то есть на ФЯ.


Вы ведь основатель темЫ, на Вас основная ответственность за её развитие... ;-)

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


Всё-таки сомнительно, что все программеры срочно перейдут на Хаскель и ему подобные языки, инерция мышления не позволит...


Инерция мышления не помешала перейти от си к си++, не помешала перейти от компилируемых языков к языкам с виртуальной машиной.
Дело не инерции, а в востребованности большим бизнесом и соответственно вложением большого капитала.

До сих пор необходимости вкладываться в ФП не было. 100% персональных компьютеров были однопроцессорными с малюсенькой памятью и полудохлыми процессорами.
Какой смысл вкладываться в Гулливера если этот Гулливер засунут в узкую трубу где он может только ползти ?
Его в этой трубе любой лилипут обгонит.

А сейчас ситуация меняется. 2 гигабайта оперативки уже не мечта. Это уже норма.
Многоядерные процессоры к концу этого года полностью вытеснят из производства обычные. То есть однопроцессорных систем просто не останется!!

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

Бизнес не потерпит такого расточительства.
Поэтому программисты сейчас ищут разнообразные способы либо облегчить создание многопоточных приложений (erlang, active objects в обероне) либо вообще его автоматизировать (parallell haskell)

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

Я уже тут писал, что скорее всего первой ареной такого вот столкновения станет индустрия игр.
Почитайте отчет разработчика Unreal, ccakre я здесь приводил.

Ответ на »сообщение 622« (Jack Of Shadows)
___________________________

Господа, эта ветка превратилась в соревнование по скачиванию различных экзотических компиляторов и прогону на них 2-х строчек наивного алгоритма фибоначи.
Мне это не нравится.

Хм, странный наезд... Разве эта ветка не должна всячески пропагандировать ФП и ФЯ?
Информация о разных компиляторах ФЯ не может помешать...

Да и Фибоначчи как никак основатель двоичной системы счисления, а не только теории размножения кроликов. Современные компьютеры используют двоичную логику, будущие, возможно, будут работать с использованием логики, основанной на числах Фибоначчи и золотой пропорции (в целях повышения надёжности, например).


Это обсуждение началось с отличной новости о переходе Интела на многоядерную архитектуру.
Как вы думаете, что это означает для языков, которые не могут задействовать все ядра, а работают только на одном ядре ?
Что случится с такими языками когда количество ядер достигнет 8 или 16 (через 3-4 года) ?
ТО есть программы написанные на таких языках будут задействовать 1/8 или 1/16 процессора.

Видимо, произойдёт переход к таким языкам, которые поддерживают многозадачность.
Может быть, снова вспомнят Ada95 и Occam (коль скоро процессоры становятся похожими на сеть из транспьютеров)...
Да и на улице виртовского семейства наступит праздник - начнут реально использоваться активные обьекты из Active Oberon/Zonnon...

Всё-таки сомнительно, что все программеры срочно перейдут на Хаскель и ему подобные языки, инерция мышления не позволит... :-(


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

Ну, это вообще смешно...
Ну что мешает распараллелить виртуальную машину, так, что бы каждый поток она выполняла на отдельном ядре?


Но хотелось бы собрать всех заинтересованный этой темой в одной ветке.

Тогда что обсуждать-то тут??? Не многоядерность же. Каким боком она относится к принципам ФП?
К практике применения - да, как и компиляторы...


Мы топчемся на месте.

Согласен. Куда пойдём? Вы ведь основатель темЫ, на Вас основная ответственность за её развитие... ;-)