Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 271
Классная статья, спасибо за перевод.
Над назад у нас был предмет параллельное программирование. Это был первый и последний непростой предмет по специальности после того, как я начал заниматься программированием.
Тогда жутко понравилось =) Мы писали на С, и из терминалки работали с суперкомпом ВЦ Новосибирского Академгородка. Если честно, прониклись очень немногие в группе, буквально четыре-пять человек, но блин, это было интересно! Вот если бы ещё препод хоть чуть-чуть знал бы этот предмет... Впрочем, хватит ностальгий.
Всё это я к тому, что параллелизм - это круто и интересно. Скорее всего, именно в эту область я направлюсь, когда мне наскучит (если мне наскучит, "если я позвоню тебе в следующем декабре") веб.
Над назад у нас был предмет параллельное программирование. Это был первый и последний непростой предмет по специальности после того, как я начал заниматься программированием.
Тогда жутко понравилось =) Мы писали на С, и из терминалки работали с суперкомпом ВЦ Новосибирского Академгородка. Если честно, прониклись очень немногие в группе, буквально четыре-пять человек, но блин, это было интересно! Вот если бы ещё препод хоть чуть-чуть знал бы этот предмет... Впрочем, хватит ностальгий.
Всё это я к тому, что параллелизм - это круто и интересно. Скорее всего, именно в эту область я направлюсь, когда мне наскучит (если мне наскучит, "если я позвоню тебе в следующем декабре") веб.
О_о абсолютно солидарен, у меня преподавали и тот и другой, про Малышкина вообще ничего хорошего сказать не могу, а вот Корнеев разложил все по полочкам :)
Корнеев не из МАИ случаем?
И почему я учусь в какой-то фигне :(
Ну, я тоже проникся, даже курсяк на эту тему писал. К сожалению, кроме меня больше не проникся никто, и то что препод досконально знал и понимал предмет — не помогло…
Угу. Очень даже может быть, что процессы - это как раз то, чего не хватает другим функциональным языкам, чтобы на них проще писались программы для реального мира. Сообщение - это как раз та форма переменной, которая не слишком переменная, но позволяющая проводить декомпозицию программы достаточно свободно.
Но только автора статьи надо попровать. Асинхронная пересылка сообщений - это основной метод достижения массового параллелизма сегодня. Возьмите хоть суперкомпьютеры (MPI - message passing interface), хоть программирование для Cell (micro MPI). Хоть Linda, хоть куча ещё всяких разных инструментов. Так что Erlang не такой уж и уникальный.
Но только автора статьи надо попровать. Асинхронная пересылка сообщений - это основной метод достижения массового параллелизма сегодня. Возьмите хоть суперкомпьютеры (MPI - message passing interface), хоть программирование для Cell (micro MPI). Хоть Linda, хоть куча ещё всяких разных инструментов. Так что Erlang не такой уж и уникальный.
Поправка следующая: мы сначала берём языки с общей памятью, а потом начинаем к ним прикручивать сбочку методы работы с сообщениями. Получается... так себе. На Erlang же это всё встроено в язык. Проблема в том, что всё-таки он необычный и всё-таки он функциональный. Не так много народу может это осилить (хотя когда-то и C/C++ для многих какзался кошмаром, так что может всё и не так страшно).
Не, у разработчиков эрланга изначально была цель сделать язык, которому можно быстро научить нового человека — и он действительно очень простой, местами даже слишком.
Не соглашусь. Erlang всё же один из самых простых языков программирования. Да, немного необычно, циклы организовывать через рекурсию и вручную протаскивать состояние между несколькими функциями, но к этому быстро привыкаешь. И благодаря возможности разбить всё на процессы это не напрягает, как, например в Haskell, где программы быстро превращаются в сплошные абстракции.
Просто в качестве примера: у нас одна контора в городе которая, если её не ограничивают в выборе языка, пишет всё на Erlang'е. Так новички осваивают язык практически за неделю. Он действительно простой.
Вот. А насчёт прикручивания методов сбоку... Так тоже по-разному бывает. Хотя, если честно, мне не понятно, что именно делает Erlang таким удобным.
Просто в качестве примера: у нас одна контора в городе которая, если её не ограничивают в выборе языка, пишет всё на Erlang'е. Так новички осваивают язык практически за неделю. Он действительно простой.
Вот. А насчёт прикручивания методов сбоку... Так тоже по-разному бывает. Хотя, если честно, мне не понятно, что именно делает Erlang таким удобным.
У ерланга есть есть одна мааленькая проблемка, сложные системы на нем писать существенно сложнее, чем на C++ или Java или любом другом объектном языке.
Человеку без практического опыта написания сложных распределёных систем, существенно проще писать на ерланге, чем на ++ или Java. Единственная сложность с которой я столкнулся - это когда работаешь со специфичными данными и понимаешь что нецелесообразно их хранить в ets. Хотя не знаю что там сейчас, уже несколько лет не слежу за изменениями.
А сравнение с объектными языками - это как минимум говорит о том, что вы не написали ниодного приложения на языке подобном ерлангу. Может тогда бы вас осенило, что объектность там ни к чему.
А сравнение с объектными языками - это как минимум говорит о том, что вы не написали ниодного приложения на языке подобном ерлангу. Может тогда бы вас осенило, что объектность там ни к чему.
Человеку без практического опыта написания сложных распределёных систем, существенно проще писать на ерланге, чем на ++ или Java.
В зависимости что писать.
А сравнение с объектными языками - это как минимум говорит о том, что вы не написали ниодного приложения на языке подобном ерлангу.
Как минимум я читал спецификации erlang и знаю что такое функциональное программирование. И я не говорил что там нужна объектность. Я говорю о построении на нем сложных систем. Решение не иметь изменяемых переменных выйдет боком при написании систем где в случае объектной модели таких переменных много и они изменяются часто. Сугубо говоря в случае erlang если вам это потребуется то прийдется писать много много мелких кусков и плодить много много процессов. Или же думать как это оптимизировать именно под erlang.
Решение не иметь изменяемых переменных выйдет боком при написании систем где в случае объектной модели таких переменных много и они изменяются часто.
Читается: сложно скопировать один в один существующую ООП программу, где переменных много и они изменяются часто.
Далее вы сами даете решение
в случае erlang если вам это потребуется писать много много мелких кусков и плодить много много процессовДейстидельно много много процессов это хорошо, а в случае erlang и очень дешево, там процесс стоит меньше, чем процесс и поток в C#, Java, etc.
Далее вы сами даете решение
Я просто представляю как это можно сделать в Erlang.
Дейстидельно много много процессов это хорошо, а в случае erlang и очень дешево, там процесс стоит меньше, чем процесс и поток в C#, Java, etc.
Вот тут-то и возникает проблема. Много процессов это много сообщений между ними и чем больше их там больше сообщений. Это кстати является бичем всех микроядреных ОС. И именно по этому микроядреные ОС не получили широкого распрастранения.
меньше - это слабо сказано :) Он практически ничего не стоит по сравнению с полноценными трэдами. И плодить их нужно миллионами )
Если не сложно, поясните пожалуйста, каким же образом Erlang создаёт "потоки", они не завязаны на потоках системы? Откуда такая дешевизна?
не завязаны.
Уже плохо помню как всё там сделано, но насколько мне не изменяет память - то их преемптив переключение между процессами(ерланга) происходит с помощью простого счётчика вызова встроенных функций(не помню как они зовутся). А процесс - это маленькая структурка с входящей очередью сообщений, линками на другие процессы(чтобы оповещать при смерти итп) и ещё всякие мелочи.
Уже плохо помню как всё там сделано, но насколько мне не изменяет память - то их преемптив переключение между процессами(ерланга) происходит с помощью простого счётчика вызова встроенных функций(не помню как они зовутся). А процесс - это маленькая структурка с входящей очередью сообщений, линками на другие процессы(чтобы оповещать при смерти итп) и ещё всякие мелочи.
Тогда из этого сразу следует, что это "нужно миллионами" процессов не будут работать параллельно, плюс будут тратить время на общение с менеджером, в итоге должно работать медленнее, чем если бы мы запустили потоков столько, сколько процессов.
Сколько процессов будет параллельно работать зависит от кол-ва ядер, процессоров, нодов в сети и как вы всё это настроите :)
Да, будут тратить, будут работать медленее до того как начнут массово появляться железяки с большим кол-вом ядер. И тут уже встанет вопрос - а на чём проще разрабатывать приложения под такие мощности, в случае с ерлангом - это уже готовое и проверенное решение с которым легко научиться работать.
Да, будут тратить, будут работать медленее до того как начнут массово появляться железяки с большим кол-вом ядер. И тут уже встанет вопрос - а на чём проще разрабатывать приложения под такие мощности, в случае с ерлангом - это уже готовое и проверенное решение с которым легко научиться работать.
Так и думал, что все фразу про "очень много" не больше чем миф. И всё прекрасно понимают, что быстрее чем в N Раз на N потоках не сделать. Так что не нужно там ничего пложить тысячами и миллионами. Поживём-увидим, как будет идти распространиние Эрланга в массы :)
*плодить* и, разумеется, *распространение*.
>И всё прекрасно понимают, что быстрее чем в N Раз на N потоках не сделать. Так что не нужно там ничего пложить тысячами и миллионами.
Создание процессов не для увеличения производительности, это идеология, где каждый объект в этом параллельном миру должен быть независимым процессом, к которому можно обращаться только с помощью сообщений.
И для создания крупного приложения в любом случае придётся плодить миллионы процессов, иначе его не написать.
Создание процессов не для увеличения производительности, это идеология, где каждый объект в этом параллельном миру должен быть независимым процессом, к которому можно обращаться только с помощью сообщений.
И для создания крупного приложения в любом случае придётся плодить миллионы процессов, иначе его не написать.
За универсальность нужно платить. Если процесс в Эрланге дешовый по сравнению с вызовом создания процесса на WinAPI под виндой, то это не означает, что он будет эффективнее процессов в какой-нибудь *nix системе, или фаст тредов какого-нибудь микроядра.
Яркий пример, в Mac OS, еще до версии X, существовало API (и сейчас свое отживает) Carbon. Оно использует свой собственный Thread Manager и не завязывается на тридах системы. И если в 9-ке это работало нормально, то как оказалось в последствии, карбоновские cooperative threads имеют неслабый перформанс пенальти по сравнению с preemtive threads микроядра Mach L4, на котором основана Mac OS X.
Яркий пример, в Mac OS, еще до версии X, существовало API (и сейчас свое отживает) Carbon. Оно использует свой собственный Thread Manager и не завязывается на тридах системы. И если в 9-ке это работало нормально, то как оказалось в последствии, карбоновские cooperative threads имеют неслабый перформанс пенальти по сравнению с preemtive threads микроядра Mach L4, на котором основана Mac OS X.
Всё мы прекрасно знаем :)
нажми меня
нажми меня
Ну извиняюсь. Нитки в Linux - они очень неторопливые, как известно. В микроядрах они гораздо эффективнее реализованы обычно. Про Mach не знаю, но, например, в QNX на два порядка все примитивы быстрее работают, чем аналогичные в Linux.
И, кстати, совершенно, например, не понятно, за счёт чего выигрывают в этом тесте системы с собственным runtime для нитей/процессов. Например, вполне может быть, что там всё выполняется последовательно в одной нити, кооперативно. Естественно, это будет быстрее. Вобщем, разбираться надо. Только параллелизма это никак не прибавляет системе.
просто в системе с собственными процессами (вроде Erlang) их исполнение размазывается по "настоящим" процессам OS
т.е. если у вас в Erlang будет миллион процессов — все 4 ядра вашего Core Quad будут полностью загружены ими
это и есть scalability — когда программа не привязана к кол-ву ядер/машин на которых физически исполняется код
т.е. если у вас в Erlang будет миллион процессов — все 4 ядра вашего Core Quad будут полностью загружены ими
это и есть scalability — когда программа не привязана к кол-ву ядер/машин на которых физически исполняется код
В таком случае это не даёт ничего нового по сравнению с существующими возможностями параллелизма в других языках, кроме другого подхода к разработке.
P.S. И снова я вижу эту странную цифру - миллион. Согласитесь, на 4х ядрах посчитать даже интеграл будет быстрее разбив его на 4 куска, чем на миллион и тратить время на их переключение/создание.
P.S. И снова я вижу эту странную цифру - миллион. Согласитесь, на 4х ядрах посчитать даже интеграл будет быстрее разбив его на 4 куска, чем на миллион и тратить время на их переключение/создание.
alex_blank> т.е. если у вас в Erlang будет миллион процессов — все 4 ядра вашего Core Quad будут полностью загружены ими
Только в случае, если Erlang для выполнения своего миллиона задействует 4 или больше процессов или потоков ОС! А если там один процесс и один поток, то весь миллион виртуальных процессов эрланга будет сидеть на одном ядре.
Только в случае, если Erlang для выполнения своего миллиона задействует 4 или больше процессов или потоков ОС! А если там один процесс и один поток, то весь миллион виртуальных процессов эрланга будет сидеть на одном ядре.
Позновательно. Думаю — наверняка в скором времени появится какой-нибудь objectErlang :) было бы железо доступно, а чем его загрузить найдут.
Больше бы таких статей на Хабре! Интересно, особенно для тех кто из другого лагеря программистов - веб :)
Было бы неплохо видеть такого рода статьи про разные ЯП - что для чего, с чем едят и что щас в них актуально и где используется.
Познавание окружающего мира - это круто.
Было бы неплохо видеть такого рода статьи про разные ЯП - что для чего, с чем едят и что щас в них актуально и где используется.
Познавание окружающего мира - это круто.
— «Здраствуйте. Я, Кирилл. Хотел бы чтобы вы сделали игру на Эрлонг, 3Д-экшон суть такова...
просто интересно на нем можно делать нечто вроде игр и прочего? я могу слабо представить сложный проект без ооп
просто интересно на нем можно делать нечто вроде игр и прочего? я могу слабо представить сложный проект без ооп
См. вот например 3D редактор wings3D, на чистом ерланге.
Единственная вещь из OOP-языков, которая действительно необходима в сложных системах - это слабая инкапсуляция (packages в Java, namespaces в C++). Всё остальное - не так важно, а пакеты напрямую к OOP отношения не имеют.
если я правильно понимаю, то объект в ерланге представлен потоком. А поток так-же принимает и посылает сообщения к другим, как объект дергает другие объекты за методы....
Очень интересная статья. Спасибо!
На самом деле обьектно-ориентированный подход укладывается в рамки привычного восприятия мира. Поэтому его и толкают в универах на младших курсах. На самом деле уже сложились некие базовые принципы написания "правильного" кода, и в них ООП жестко доминирует.
Erlang - интересный, а главное - "живой", но пока ещё не вошедший в широкое использование язык. Как часто бывает, "самый лучший" не всегда становится мейнстримом. Потому что программисты, реализующие подобные задачи, должны иметь серьёзный опыт работы - т.е. начинать им в любом случае приходилось с сишника. А отказаться уже хорошо изученного языка довольно сложно.
objectErlang - бред. Слишком разные концепции написания кода.
Erlang - интересный, а главное - "живой", но пока ещё не вошедший в широкое использование язык. Как часто бывает, "самый лучший" не всегда становится мейнстримом. Потому что программисты, реализующие подобные задачи, должны иметь серьёзный опыт работы - т.е. начинать им в любом случае приходилось с сишника. А отказаться уже хорошо изученного языка довольно сложно.
objectErlang - бред. Слишком разные концепции написания кода.
Если кому интересна параллельная разработка на .Net, Microsoft выпустила библиотеку Microsoft’s Parallel Extensions Library
Стиль статьи идеально подходит под формат "магазин на диване".
"Мы представляем вам революционно новое устройство, с ним вы сможете работать в 10, 20, и даже в 30 раз быстрее! Мы предлагаем вам параллелизм! ДЕВЯТЬ ДЕВЯТОК НАДЕЖНОСТИ!! Заказывайте прямо сейч^W"
"Мы представляем вам революционно новое устройство, с ним вы сможете работать в 10, 20, и даже в 30 раз быстрее! Мы предлагаем вам параллелизм! ДЕВЯТЬ ДЕВЯТОК НАДЕЖНОСТИ!! Заказывайте прямо сейч^W"
Серебрянная пуля параллельного программирования? А как быть в ситуациях когда нужно синхронизировать потоки при доступе к разделяемому ими ресурсу на запись (такие задачи довольно часто имеют место быть, например БД)? И вообще, если заостряете внимание на параллельном программировании, то и приводите примеры по теме, а не показывайте очередной Python vs Java vs NET.
У меня есть подозрения, что такую асинхронную архитектуру обмена сообщениями можно без проблем построить на ООП языках (с тем же самым повышением производительности).
У меня есть подозрения, что такую асинхронную архитектуру обмена сообщениями можно без проблем построить на ООП языках (с тем же самым повышением производительности).
Угу, у интела даже есть DLL'ка которая сама это делает, с программой, которая о параллельности вообще ничего не знает.
Можно. Только порождение процессов или потоков будет жрать больше ресурсов. Хотя далеко не факт что решение на erlang при этом будет жрать меньше ресурсов из-за этого.
Вообще можно, см. actors в Scala — они по мотивам эрланга сделаны.
Но в случае эрланга фишка в том что весь дизайн языка построен вокруг этой модели, ей удобно пользоваться и сломать что-то очень сложно. То, что два процесса не могут иметь разделяемых данных — это одна из основных фишек, а не недостаток.
Насчет расделяемого ресурса — в двух словах, создается специальный серверный процесс, который общается с этим ресурсом, а остальные общаются с этим процессом посредством тех же сообщений.
Но в случае эрланга фишка в том что весь дизайн языка построен вокруг этой модели, ей удобно пользоваться и сломать что-то очень сложно. То, что два процесса не могут иметь разделяемых данных — это одна из основных фишек, а не недостаток.
Насчет расделяемого ресурса — в двух словах, создается специальный серверный процесс, который общается с этим ресурсом, а остальные общаются с этим процессом посредством тех же сообщений.
насколько мне изветсно, в ерланге есть встроенная или просто отдельный проект БД, так что если не использовать напрямую обычные базы, то все ок
Что бы там не говорили программисты, есть такая жесткая вещь, как практика.
А на практике встречается такая задача:
На 8-ядерном сервере с 16 гектарами оперативки нужно запустить 4 серверных приложения для Windows Server 2003. При этом необходимо обеспечить максимальное быстродействие. Ни одно приложение не относится к разряду "самопальных", называть их не буду, но кто хоть раз в жизни администрировал крупные офисы (больше 1000 машин) их отлично знают.
Сразу был установлен винсервер, на него поставили 4 сервиса, раскидали их по разным процессорам. Производительность не устраивала.
Поставили ксен и 4(!) винды. На каждую по сервису. Производительность выросла на 18%
Мораль: "Угу, у интела даже есть DLL'ка которая сама это делает, с программой, которая о параллельности вообще ничего не знает." - полнейший бред. Мультитредность должна закладываться на этапе проектировки дизайна проекта, а если этого нету - ни одна дллька не поможет.
А на практике встречается такая задача:
На 8-ядерном сервере с 16 гектарами оперативки нужно запустить 4 серверных приложения для Windows Server 2003. При этом необходимо обеспечить максимальное быстродействие. Ни одно приложение не относится к разряду "самопальных", называть их не буду, но кто хоть раз в жизни администрировал крупные офисы (больше 1000 машин) их отлично знают.
Сразу был установлен винсервер, на него поставили 4 сервиса, раскидали их по разным процессорам. Производительность не устраивала.
Поставили ксен и 4(!) винды. На каждую по сервису. Производительность выросла на 18%
Мораль: "Угу, у интела даже есть DLL'ка которая сама это делает, с программой, которая о параллельности вообще ничего не знает." - полнейший бред. Мультитредность должна закладываться на этапе проектировки дизайна проекта, а если этого нету - ни одна дллька не поможет.
Спасибо за перевод :)
Но некоторые вещи вызывают удивление, возможно и из-за того что я не в курсе этого языка.
Каким образом модель с передачей сообщений в рамках одного процессора может быть лучше чем модель с общей памятью? Мне думается что в такой ситуации не стоит изучать специально Erlang, а пользоваться C + OpenMP, так будет быстрее и проще, и время на пересылку сообщений тратиться не будет.
Для приведённых в статье применений я не оспариваю полезность этого языка, но он не становиться популярным именно потому, что распараллелить и убыстрить код можно и другими, менее затратными способами, и пока что этого вполне хватает :)
Думаю не всё так просто и с написанием крупных приложений. Наверняка там код не такой прозрачный, как в примере, и нужно уже самому продумывать и прописывать взаимодействие процессов, блокировки и пересылки. И тогда по затраченному времени на написание это не будет быстрее, чем тотже MPI...
Но некоторые вещи вызывают удивление, возможно и из-за того что я не в курсе этого языка.
Каким образом модель с передачей сообщений в рамках одного процессора может быть лучше чем модель с общей памятью? Мне думается что в такой ситуации не стоит изучать специально Erlang, а пользоваться C + OpenMP, так будет быстрее и проще, и время на пересылку сообщений тратиться не будет.
Для приведённых в статье применений я не оспариваю полезность этого языка, но он не становиться популярным именно потому, что распараллелить и убыстрить код можно и другими, менее затратными способами, и пока что этого вполне хватает :)
Думаю не всё так просто и с написанием крупных приложений. Наверняка там код не такой прозрачный, как в примере, и нужно уже самому продумывать и прописывать взаимодействие процессов, блокировки и пересылки. И тогда по затраченному времени на написание это не будет быстрее, чем тотже MPI...
Там на самом деле 'хитрая' пересылка сообщений. Данные не копируются, а передаются по указателю. В парадигме static single assignment (то есть без переменных) это можно сделать. Фактически, сообщения эти реализованы поверх особого сборщика мусора. Это если речь идёт о процессах, работающих внутри smp или numa. А если это всё на другой коробке через сеть, то всё прозрачно для программиста копируется. На самом деле - очень мощная штука. И очень удобная, уступающая в удобстве разве только компилятору, который за вас циклы распараллеливать будет. Но не все программы состоят из 'умножений матриц' :) А писать на MPI ГОРАЗДО сложнее, чем на Erlang. С его pattern matching'ом на структурированных сообщениях. Вот.
В HPC Erlang по другой причине не используется - он, конечно, относительно быстрый, но матрицы на нём не поумножаешь достаточно эффективно и экономно.
В HPC Erlang по другой причине не используется - он, конечно, относительно быстрый, но матрицы на нём не поумножаешь достаточно эффективно и экономно.
Каким образом модель с передачей сообщений в рамках одного процессора может быть лучше чем модель с общей памятью?
На одном одноядерном процессоре - никак. А вот если ядер 30-50, то это уже беда: каналы связи между процессорами перегружаются, доступ в кеш "чужого" процессора жутко томозной, etc. Собственно идеальный процессор для языков с передачей сообщений выглядит примерно так, но есть одно но: язык-то на подобные процессоры рассчитан, а вот имеющиеся реализации - пока нет.
Мне думается что в такой ситуации не стоит изучать специально Erlang, а пользоваться C + OpenMP, так будет быстрее и проще, и время на пересылку сообщений тратиться не будет.Предел - где-то 8-16 ядер, дальше уже накладные расходы от общей памяти начинают перевешивать.
Multicore - пока ещё молодое направление, но похоже назревает очередная (после появления ООП) революция...
Предел - где-то 8-16 ядер, дальше уже накладные расходы от общей памяти начинают перевешивать.
Но ведь и затраты на пересылку при таком количестве взаимодействующих процессов будут велики?
Хм. Так общая память тоже построенна на передачи сообщений: процессоры пуляются друг в друга запросами и ответами по общей шине или по сети (NUMA). Это, конечно, всё автоматизировано и программист этого не видит, но тем не менее. При этом протоколы должны быть достаточно сложными, чтобы для программиста поддерживалась иллюзия общей памяти. А сложные алгоритмы означают сложное и относительно медленное оборудование. Явная пересылка сообщений гораздо проще реализуется в аппаратуре, а благодаря всяким иерархическим коммутаторам (например, технологий много на самом деле) может распространятся не на всю систему, а только на те узлы, которые в обменах учавствуют.
В итоге, несмотря на то, что кажется, что работы делается больше, всё может работать гораздо эффективней. Смотрите на тот же Cell. Или на всякие mesh-процессоры (это когда куча ядер связана квадратной сеткой из каналов связи). Ну и как историческй факт: советские транспьютеры, построенные на основе парадигмы с пересылкой сообщения обладали отличной производительностью. У нас на них до сих пор кое-что расчитывают.
В итоге, несмотря на то, что кажется, что работы делается больше, всё может работать гораздо эффективней. Смотрите на тот же Cell. Или на всякие mesh-процессоры (это когда куча ядер связана квадратной сеткой из каналов связи). Ну и как историческй факт: советские транспьютеры, построенные на основе парадигмы с пересылкой сообщения обладали отличной производительностью. У нас на них до сих пор кое-что расчитывают.
Согласен. Но где вы в моих постах увидели разговор про NUMA или распределённые системы с общей памятью? Я говорю про использование многоядерных процессоров, в которых можно не использовать пересылку сообщений, а использовать DMA к общей памяти на аппаратном уровне.
Думаю не стоит мешать в одну кучу всё многообразие существующих архитектур, в 09:59 я хотел сказать лишь о преимуществе (судя по переводу) OpenMP над Erlang на одной машине с множеством ядер, видимо это было не так истолковано :)
Думаю не стоит мешать в одну кучу всё многообразие существующих архитектур, в 09:59 я хотел сказать лишь о преимуществе (судя по переводу) OpenMP над Erlang на одной машине с множеством ядер, видимо это было не так истолковано :)
Именно про них (подчеркну: про многоядерные, SMP и NUMA - машины с общей, а не с распределённой, памятью тоже - я и говорю :) Прочитайте о протоколах поддержки согласованности кэшей (даже согласованность L1 кэшей надо поддерживать, если у вас L2 общий). Да и просто об обмене данными с памятью. Да и даже про внутреннюю организацию процессоров. Все современные сложные цифровые устройства построены на парадигме пересылки данных. Даже собственно сами модули памяти - это устройства, которые принимают запросы и отвечают на них. И это, вобщем-то, относительно медленные устройства. Например, по PCI-Express данные можно гнать со скоростью гораздо большей, чем их можно считывать из памяти, или записывать. Так что, пересылка сообщений не обязательно должна быть медленней, чем даже чтение значения переменной из памяти в регистр.
Ну вот речь и зашла о низкоуровневых примитивах, которые основаны на особенностях архитектуры. Что лишний раз доказывает то, что концепция языка играет совсем не самую важную роль при распаралеливании и оптимизации. Нужно учитывать специфику задачи и целевую архитектуру. Потому, разрекламированая универсальность Эрланга похожа на миф :)
Ну... Думается, что нельзя архитектуры рассматривать отдельно от приложений. Всё же системы сейчас строятся под конкретные задачи. И то, в какой парадигме будут создаваться приложения играет важную роль. А в Эрланге что не универсальное? Любой алгоритм записать можно... Всё универсально.
Мы же выше решили, что для HPC он не так уж и подходит, на данный момент пока что.
Я вижу его применение в основном для разнообразных "серверов", где нужно относительно небольшое(сотни?) число потоков, которые выполняют в один момент разные задачи, и без интенсивного обмена данными между собой. Хотя и остаётся вопрос, зачем для этого использовать именно Erlang :)
Я вижу его применение в основном для разнообразных "серверов", где нужно относительно небольшое(сотни?) число потоков, которые выполняют в один момент разные задачи, и без интенсивного обмена данными между собой. Хотя и остаётся вопрос, зачем для этого использовать именно Erlang :)
Хотя я похоже снова на HPC зацикливаюсь :)
А может мне кто-нибудь пояснить, вот пример в конце, он уже ускорен в 4 раза на четырехядерном процессоре или еще что-то надо делать? Еще хотелось бы знать, как erlang работает на windows, каким образом он в одном winapi процессе умудряется делать распаралелливание без тех же winapi потоков? Раскрывается ли erlang на windows?
На четырехядерном процессе будет 4 "настоящих" потока ОС, в которых будут исполняться десятки тысяч эрланговских потоков.
на 4хядерных не интересно :) можно писать под одноядерный на Си без распараллеливания и будет работать быстрее. Но когда будет 32ядра и больше...
Зависит от того как будешь писать на ергланге и на Си, можно и на ерланге писать немасштабируемый софт. Да, изначально на ерланге проще, но это всё относительно и зависит от опыта. Ну кроме поиска ошибок, отладки, и хот-апдейтов которые ерланг предоставляет изкаропки, этого у ерланга не отнять :)
Ну. Опять же не факт :) Вопрос в том, как именно на Си писать. Ничего ведь не мешает в точности повторить те процессы, которые происходят в runtime Erlang'а. Да вобщем-то это и на уровне библиотек (pth, например) делается.
Да и потом, никто не мешает на Erlang'е написать программу, которая не будет масштабироваться. И масштабируется хорошо только определённый класс задач. Который хорошо разбивается на процессы. Но такое разбиение не всегда возможно.
Да и потом, никто не мешает на Erlang'е написать программу, которая не будет масштабироваться. И масштабируется хорошо только определённый класс задач. Который хорошо разбивается на процессы. Но такое разбиение не всегда возможно.
Поддерживаю, особенно учитывая, что проблемы распараллеливания как правило носят содержательный, фундаментальный характер, они вообще не имеют отношения к конкретному языку программирования. Язык программирования - это всего ли ФОРМА выражения мыслей, но он сам по себе не является СОДЕРЖАНИЕМ.
Кстати run-time среды языков типа Erlang написаны на том же "C" или "C++".
Вообще конечно не имею ничего против функциональных языков - но не стоит превращать их в религию, думая, что они автоматически решают фундаментальные проблемы, тогда как язык это лишь способ записи мыслей (алгоритмов), сам по себе он не может решить проблемы. Плохо только тогда, когда язык мешает.
Кстати run-time среды языков типа Erlang написаны на том же "C" или "C++".
Вообще конечно не имею ничего против функциональных языков - но не стоит превращать их в религию, думая, что они автоматически решают фундаментальные проблемы, тогда как язык это лишь способ записи мыслей (алгоритмов), сам по себе он не может решить проблемы. Плохо только тогда, когда язык мешает.
проблема распараллеливания имеет самое прямое отношение к языку, вы очень сильно ошибаетесь и вводите в заблуждение других читателей этой ветки
вот вам простой пример: в Haskell можно запускать выполнение любой функции в параллельном потоке потому что сама семантика языка гарантирует отсутствие скрытых зависимостей от других контекстов исполнения (например чтения-записи в общую память или же какого-либо I/O с интерфейсами OS, могущими привести к этому)
то есть, это поведение зашито в саму модель языка Haskell
в C++ же компилятору придётся проводить сложный семантический анализ кода для распараллеливания, чтобы выяснить, есть ли скрытые зависимости — и в общем случае эта задача там неразрешима
вот вам простой пример: в Haskell можно запускать выполнение любой функции в параллельном потоке потому что сама семантика языка гарантирует отсутствие скрытых зависимостей от других контекстов исполнения (например чтения-записи в общую память или же какого-либо I/O с интерфейсами OS, могущими привести к этому)
то есть, это поведение зашито в саму модель языка Haskell
в C++ же компилятору придётся проводить сложный семантический анализ кода для распараллеливания, чтобы выяснить, есть ли скрытые зависимости — и в общем случае эта задача там неразрешима
Только не стоит забывать, что это "распараллеливание" не совсем точное понятие и выполняться программа будет на отведённых для выполнения потоках.
Так что в итоге это не даёт каких-то особых преимуществ перед хорошо написанным кодом на C(++), кроме как включение параллелизма в концепцию языка. Но это избавление от сложности распараллеливания в C(++) наверняка имеет и недостатки в виде более сложной реализации некоторых вещей на Erlang'е.
В общем случае не всякая "программа" может быть откомпилирована, а не всякая откомпилированная будет правильно работать, не так ли? Всё-таки C++ и Erlang вроде бы компилируемые языки, стоит смотреть больше на качестко и скорость работы полученного байткода, чем на время компиляции.
P.S. Я не против этого языка, но не нужно же считать его панацеей.
P.P.S. Мне даже уже интересно стало, если в Эрланге всё так не связанно друг с другом, то как при работа с ним поступают в случае, если программа должна записать в разные места одного файла данные, которые получаются при работа разных потоков? :)
Так что в итоге это не даёт каких-то особых преимуществ перед хорошо написанным кодом на C(++), кроме как включение параллелизма в концепцию языка. Но это избавление от сложности распараллеливания в C(++) наверняка имеет и недостатки в виде более сложной реализации некоторых вещей на Erlang'е.
в C++ же компилятору придётся проводить сложный семантический анализ кода для распараллеливания, чтобы выяснить, есть ли скрытые зависимости — и в общем случае эта задача там неразрешима
В общем случае не всякая "программа" может быть откомпилирована, а не всякая откомпилированная будет правильно работать, не так ли? Всё-таки C++ и Erlang вроде бы компилируемые языки, стоит смотреть больше на качестко и скорость работы полученного байткода, чем на время компиляции.
P.S. Я не против этого языка, но не нужно же считать его панацеей.
P.P.S. Мне даже уже интересно стало, если в Эрланге всё так не связанно друг с другом, то как при работа с ним поступают в случае, если программа должна записать в разные места одного файла данные, которые получаются при работа разных потоков? :)
>>Так что в итоге это не даёт каких-то особых преимуществ перед преимуществ перед хорошо написанным кодом
.. а так же перед хорошо написанным кодом на x86-опкодах, угу
давайте не будем толочь воду в ступе
мы же здесь не про сферических коней в вакууме — есть Эрланг, на нём хорошо распараллеленый код писать в разы проще, чем на C++, это и есть основной concern
>> чем на время компиляции.
при чём тут время компиляции? я говорил про то, что задача автоматического параллелизма разрешима в C++ лишь в частных случаях, а в Erlang - в общем
>> Всё-таки C++ и Erlang вроде бы компилируемые языки
интерпретируемый язык или компилируемый — это очень странный и абсолютно некорректный критерий оценки, компиляция — это преобразование кода, и "интерпретируемые" и "компилируемые" программы проходят через длинные цепочки преобразований до фактического исполнения их железом
>> P.S. Я не против этого языка, но не нужно же считать его панацеей.
забавно, покажите мне место в статье или в комментариях к ней, где утверждается: "Эрланг — это панацея, ребяты!"
>> то как при работа с ним поступают в случае, если программа должна записать в разные места одного файла данные, которые получаются при работа разных потоков?
делаете процесс, принимающий сообщение "записать кусок байтов в файл"
все остальные процессы посылают сообщение с байтами этому процессу
.. а так же перед хорошо написанным кодом на x86-опкодах, угу
давайте не будем толочь воду в ступе
мы же здесь не про сферических коней в вакууме — есть Эрланг, на нём хорошо распараллеленый код писать в разы проще, чем на C++, это и есть основной concern
>> чем на время компиляции.
при чём тут время компиляции? я говорил про то, что задача автоматического параллелизма разрешима в C++ лишь в частных случаях, а в Erlang - в общем
>> Всё-таки C++ и Erlang вроде бы компилируемые языки
интерпретируемый язык или компилируемый — это очень странный и абсолютно некорректный критерий оценки, компиляция — это преобразование кода, и "интерпретируемые" и "компилируемые" программы проходят через длинные цепочки преобразований до фактического исполнения их железом
>> P.S. Я не против этого языка, но не нужно же считать его панацеей.
забавно, покажите мне место в статье или в комментариях к ней, где утверждается: "Эрланг — это панацея, ребяты!"
>> то как при работа с ним поступают в случае, если программа должна записать в разные места одного файла данные, которые получаются при работа разных потоков?
делаете процесс, принимающий сообщение "записать кусок байтов в файл"
все остальные процессы посылают сообщение с байтами этому процессу
Не путайте Erlang c Haskell. В Erlang есть функции, для которых не выполняется referntial transparency. Возьмите ту же работу с файлами.
Вот. А если говорить о Haskell, то решение многих задач на нём очень быстро превращается в головную боль. Я не говорю про все задачи. Но очень многие важные. Например, физика. Например, задачи на графах. Например, моделирование процессов. Всё же миру нужны состояния, а манады их инкапсулируют уж очень негибко. Да ещё и таким способом, что вычисления строго последовательные выходят. И никак их не расцепить.
Таким образом, чистые функции теоретически - это хорошо. Но на практике они сильно органичивают программиста и имеют свои накладные расходы, когда приходится реализовывать нечто, что без состояний - никак. И если в рамках Си, например, компилятор может быть крутым и выявить ref.trans. функции, и программисту ничто не мешает их писать, то в случае чистого функционального подхода, программисту постоянно будет мешаться stateless. Можно посмотреть любой большой проект на Haskell и убедится в этом.
Вот. Что хотелось сказать. Функциональное программирование хорошо, как концепт. Но для реальной жизни его надо расширять как-то. Вот Erlang его расширяет процессами - это совсем не функциональный подход. ML императивными конструкциями... И наоборот. Многие императивные языки сейчас расширены функциональными возможностями. Тот же C++ с boost'ом. Есть даже варианты расширения Си, и даже расширения с целью быстро писать параллельные программы. Вроде T-системы.
Так что вот. Не нужно в абсолют возводить теорию, которая не проверена практикой (то есть, экспериментом).
P.S. Кстати, stackless python или rinda, или тот же smalltalk, тоже позволяют общаться тысячам потоков вполне себе плавно. И не функциональность этих систем этому не мешает.
Вот. А если говорить о Haskell, то решение многих задач на нём очень быстро превращается в головную боль. Я не говорю про все задачи. Но очень многие важные. Например, физика. Например, задачи на графах. Например, моделирование процессов. Всё же миру нужны состояния, а манады их инкапсулируют уж очень негибко. Да ещё и таким способом, что вычисления строго последовательные выходят. И никак их не расцепить.
Таким образом, чистые функции теоретически - это хорошо. Но на практике они сильно органичивают программиста и имеют свои накладные расходы, когда приходится реализовывать нечто, что без состояний - никак. И если в рамках Си, например, компилятор может быть крутым и выявить ref.trans. функции, и программисту ничто не мешает их писать, то в случае чистого функционального подхода, программисту постоянно будет мешаться stateless. Можно посмотреть любой большой проект на Haskell и убедится в этом.
Вот. Что хотелось сказать. Функциональное программирование хорошо, как концепт. Но для реальной жизни его надо расширять как-то. Вот Erlang его расширяет процессами - это совсем не функциональный подход. ML императивными конструкциями... И наоборот. Многие императивные языки сейчас расширены функциональными возможностями. Тот же C++ с boost'ом. Есть даже варианты расширения Си, и даже расширения с целью быстро писать параллельные программы. Вроде T-системы.
Так что вот. Не нужно в абсолют возводить теорию, которая не проверена практикой (то есть, экспериментом).
P.S. Кстати, stackless python или rinda, или тот же smalltalk, тоже позволяют общаться тысячам потоков вполне себе плавно. И не функциональность этих систем этому не мешает.
я про Haskell и ссылочную прозрачность и не говорил
в Erlang код не параллелится per function, просто там процесс и способы их коммуникации — это примитивы языка, что и обеспечивает целостность программы, в отличие от низкоуровневого C++
в Erlang код не параллелится per function, просто там процесс и способы их коммуникации — это примитивы языка, что и обеспечивает целостность программы, в отличие от низкоуровневого C++
Но это не на автомате.
В смысле - это не автоматическое распараллеливание. А встроенные процессы/нити есть во многих языках. В Erlang что хорошо, так это удобная работа с этими сообщениями. Но ничто не мешает этот message matching сделать в рамках и другой системы.
Можно. Только невольно приходит на ум, что Армстронг прав в своём шутливом дополнении к десятому правилу Гринспуна (которое, как мы помним, о Лиспе):
Вообще, почитайте диссертацию Армстронга «Making reliable distributed systems in the presence of software errors» (она есть в свободном доступе). Там он очень подробно и доходчиво объясняет, почему Эрланг именно такой и никакой другой, какие цели преследовались при создании языка и платформы и т. д. Распараллеливаемость с целью повышения быстродействия в духе HPC никогда не была краеугольной задачей. Надёжность, масштабируемость, распределённость — для этого делался Эрланг, и со своими задачами он отлично справляется.
И вот буквально в последние год-полтора в связи с бумом многоядерников начался (в том числе усилиями самого Армстронга, и большое ему за это спасибо) весь этот hype, о котором статья.
Any sufficiently advanced concurrent program contains an ad hoc, informally-specified, bug ridden, slow implementation of half of Erlang.
Вообще, почитайте диссертацию Армстронга «Making reliable distributed systems in the presence of software errors» (она есть в свободном доступе). Там он очень подробно и доходчиво объясняет, почему Эрланг именно такой и никакой другой, какие цели преследовались при создании языка и платформы и т. д. Распараллеливаемость с целью повышения быстродействия в духе HPC никогда не была краеугольной задачей. Надёжность, масштабируемость, распределённость — для этого делался Эрланг, и со своими задачами он отлично справляется.
И вот буквально в последние год-полтора в связи с бумом многоядерников начался (в том числе усилиями самого Армстронга, и большое ему за это спасибо) весь этот hype, о котором статья.
Другой - это императивной, например.
Кроме компилятора есть еще и программист. То, что не может сделать компилятор - может за него сделать программист. Кто бы спорил, что функциональные языки потенциально избавляют программиста от изрядной части работы по распараллеливанию кода на нижнем уровне - это и стимулировало research в области функционального программирования.
Но, во-первых, это преимущество по большей части носит чисто теоретический характер, когда в умных книжках рассуждают об автоматических преобразованиях программ, редукциях и лямбда-исчислении. На практике же компиляторы функциональных языков - доступные нам в ощущениях, а не те, о которых ходят легенды - не умеют сами распараллеливать вычисления так хорошо, как следует из теории. Они вообще не очень-то сильны как компиляторы в машинный код, а тем более как распараллеливающие компиляторы. Вместо этого разработчики сред стараются вынести все, связанное с распараллеливанием в run-time - оно и понятно, так намного проще, ведь не нужно привлекать большую науку с переднего края при написании компилятора.
Отсюда и появление всяких конструкций явного параллелизма в, казалось бы, "чистых" функциональных языках, которые могли бы и сами этот параллелизм выявить.
А во-вторых, на практике за все приходится платить. Функциональные языки избавляют нас от траха мозгов с низкоуровневым распараллеливанием кода - но своим pattern matching, динамической типизацией, сборкой мусора, типичной для них компиляцией в байт-коды и т.п., привносят столько накладных расходов, что это де-факто съедает выигрыш от автоматического распараллеливания.
Не говоря уже о том, что мыслить в такой форме возможно, но неудобно - по сравнению с императивными языками. Считайте меня тупым, если Вам так удобнее - но я убедился, что голова меньше болит при написании обычного кода на "C".
Но, во-первых, это преимущество по большей части носит чисто теоретический характер, когда в умных книжках рассуждают об автоматических преобразованиях программ, редукциях и лямбда-исчислении. На практике же компиляторы функциональных языков - доступные нам в ощущениях, а не те, о которых ходят легенды - не умеют сами распараллеливать вычисления так хорошо, как следует из теории. Они вообще не очень-то сильны как компиляторы в машинный код, а тем более как распараллеливающие компиляторы. Вместо этого разработчики сред стараются вынести все, связанное с распараллеливанием в run-time - оно и понятно, так намного проще, ведь не нужно привлекать большую науку с переднего края при написании компилятора.
Отсюда и появление всяких конструкций явного параллелизма в, казалось бы, "чистых" функциональных языках, которые могли бы и сами этот параллелизм выявить.
А во-вторых, на практике за все приходится платить. Функциональные языки избавляют нас от траха мозгов с низкоуровневым распараллеливанием кода - но своим pattern matching, динамической типизацией, сборкой мусора, типичной для них компиляцией в байт-коды и т.п., привносят столько накладных расходов, что это де-факто съедает выигрыш от автоматического распараллеливания.
Не говоря уже о том, что мыслить в такой форме возможно, но неудобно - по сравнению с императивными языками. Считайте меня тупым, если Вам так удобнее - но я убедился, что голова меньше болит при написании обычного кода на "C".
>> Они вообще не очень-то сильны как компиляторы в машинный код, а тем более как распараллеливающие компиляторы.
это верно, как компиляторы в эффективный машинный код они сегодня — тупое говно
здесь есть 2 проблемы:
1. академикам влом реализовывать алгоритмы из своих PhD диссертаций в реальных компиляторах (попробуйте разобраться в сорцах GHC какого-нибудь — да там чёрт ногу сломит), у них просто нет мотивации никакой этого делать, им за это никто не заплатит
2. фундаментальная математическая проблема — неразрешимость программ в общем случае, что следует из теоремы Гёделя о неполноте — это означает, что "серебряную пулю" никто и никогда не создаст
>> Считайте меня тупым, если Вам так удобнее - но я убедился, что голова меньше болит при написании обычного кода на "C".
когда у меня голова болит за производительность — и я беру в руки C
потому что если мне нужно решать задачу в терминах архитектуры PC, то глупо использовать для этого абстракцию над ней
это верно, как компиляторы в эффективный машинный код они сегодня — тупое говно
здесь есть 2 проблемы:
1. академикам влом реализовывать алгоритмы из своих PhD диссертаций в реальных компиляторах (попробуйте разобраться в сорцах GHC какого-нибудь — да там чёрт ногу сломит), у них просто нет мотивации никакой этого делать, им за это никто не заплатит
2. фундаментальная математическая проблема — неразрешимость программ в общем случае, что следует из теоремы Гёделя о неполноте — это означает, что "серебряную пулю" никто и никогда не создаст
>> Считайте меня тупым, если Вам так удобнее - но я убедился, что голова меньше болит при написании обычного кода на "C".
когда у меня голова болит за производительность — и я беру в руки C
потому что если мне нужно решать задачу в терминах архитектуры PC, то глупо использовать для этого абстракцию над ней
А каким образом связана проблема написания эффективного компилятора с функцинального языка и теорема Гёделя?
зависит от того, что для вас — эффективный компилятор
вот я хочу компилятор, который мог бы анализировать код на предмет незавершаемости (логических ошибок, могущих привести к бесконечному циклу для некоторых input'ов)
и это только самый простой пример (самое актуальное это, наверное, анализ worst-case execution time для автоматической мемоизации и замены ленивости на энергичность)
это невозможно в Тьюринг-полном языке
решение есть — программировать на ограниченных языках, где эти проблемы разрешимы в общем случае, но мне пока неизвестны ни примеры, ни то, насколько это могло бы быть удобно
вот я хочу компилятор, который мог бы анализировать код на предмет незавершаемости (логических ошибок, могущих привести к бесконечному циклу для некоторых input'ов)
и это только самый простой пример (самое актуальное это, наверное, анализ worst-case execution time для автоматической мемоизации и замены ленивости на энергичность)
это невозможно в Тьюринг-полном языке
решение есть — программировать на ограниченных языках, где эти проблемы разрешимы в общем случае, но мне пока неизвестны ни примеры, ни то, насколько это могло бы быть удобно
Хм... А зачем? Язык программирования - это не средство анализа алгоритма, а средство его записи для некой системы исполнения. Если вы хотите проанализировать алгоритм, так на то есть куча других методов. Те же TLA или Abstract State Machines. Где всякие неполадки в алгоритме вылавливаются очень быстро. В конце концов, можно просто подоказывать теоремы, в том числе и автоматически, в том числе и об программе на императивном языке (даже если есть side-эффекты).
Язык программирования - это не средство анализа алгоритма
да ну, а я вот, к примеру, не мыслю Haskell без статической типизации и гарантий exhaustiveness паттерн-матчинга
что это, как не средства анализа алгоритма?
да ну, а я вот, к примеру, не мыслю Haskell без статической типизации и гарантий exhaustiveness паттерн-матчинга
что это, как не средства анализа алгоритма?
Это не средства анализа программы, imho. Это инструмент для того, чтобы избежать некоторых ошибок в его записи. И типизация, и разбор случаев это всё из этой оперы. Ну... Можно так смотреть, по-моему. Можно и с этими инструментами написать корявую программу с корявым алгоритмом. Ну да, кое что будет отловлено.
Но это всё же не средства анализа, а механизмы для генерации корректного кода. Статическая типизация, кстати, именно для этого предназначена, imho: полиморфизмы всякие, перегрузки функций и тому подобное.
И, вобщем-то, полный pattern matching нужен тоже для генерации кода, функция должна как-то работать для ВСЕХ значений аргументов, к которым она применяется. Если бы какой-то вариант не был бы описан, то как должна была бы выполнятся программа? Генерировать исключения? Но в Haskell их нет, без специальных монад. Поэтому они пошли по такому вот пути. Всё это махровое моё личное мнение, конечно. Но, вроде, так тоже можно к этому подходить.
Но это всё же не средства анализа, а механизмы для генерации корректного кода. Статическая типизация, кстати, именно для этого предназначена, imho: полиморфизмы всякие, перегрузки функций и тому подобное.
И, вобщем-то, полный pattern matching нужен тоже для генерации кода, функция должна как-то работать для ВСЕХ значений аргументов, к которым она применяется. Если бы какой-то вариант не был бы описан, то как должна была бы выполнятся программа? Генерировать исключения? Но в Haskell их нет, без специальных монад. Поэтому они пошли по такому вот пути. Всё это махровое моё личное мнение, конечно. Но, вроде, так тоже можно к этому подходить.
связанЫ, то есть.
>> На практике же компиляторы функциональных языков - доступные нам в ощущениях, а не те, о которых ходят легенды - не умеют сами распараллеливать вычисления так хорошо, как следует из теории.
А они сами ничего и не распараллеливают. Параллельность находится в описании программы. И если у вас lambda-граф программы - это длинные висюльки, а не широкое дерево, то среда исполнения ничего сделать не сможет. В этом подходе нет ничего такого особо мифического и круто-теоретического. Всё просто.
Проблема не в компиляторах, а в том, чтобы эффективно записать программу в функциональной форме, да ещё и так, чтобы она потом эффективно работала. Это настоящий challenge. То есть, понятно, что ping/pong запишется. А вот та же распределённая база данных? Да ещё такая, которая искать умеет эффективно? Где нужно индексы строить за n*log(n) железно, а не с вероятностью, как в quicksort? Это уже начинает вызывать проблемы.
А они сами ничего и не распараллеливают. Параллельность находится в описании программы. И если у вас lambda-граф программы - это длинные висюльки, а не широкое дерево, то среда исполнения ничего сделать не сможет. В этом подходе нет ничего такого особо мифического и круто-теоретического. Всё просто.
Проблема не в компиляторах, а в том, чтобы эффективно записать программу в функциональной форме, да ещё и так, чтобы она потом эффективно работала. Это настоящий challenge. То есть, понятно, что ping/pong запишется. А вот та же распределённая база данных? Да ещё такая, которая искать умеет эффективно? Где нужно индексы строить за n*log(n) железно, а не с вероятностью, как в quicksort? Это уже начинает вызывать проблемы.
согласен
производительность программы на С ограничена
Это чем же?
Да и стоимость разработки программы на С намного выше...
В какой области и для чего? Я согласен, что erlang будет хорошо работать в сфере коммуникаций и т.п. подобных задач, которые хорошо укладываются в модель erlang. Но вот писать на нем прикладной софт... к примеру тот медиа-проигрыватель или IM-клиент это знаете из разряда мазохизма.
Ну. IM-клиент - это тоже коммуникация. И пишется довольно просто. И не только IM. А проигрыватель проигрыватель из-за кодеков, да - уже мазахизм.
Я говорю не про CLI IM-клиент, а про что-то типа Pidgin хотя бы. И мне не кажется что это будет просто. А проигрыватель сложно будет не только из-за кодеков, но еще из-за вывода на экран.
>а про что-то типа Pidgin хотя бы
проблема с UI?! см. Wings3d
>но еще из-за вывода на экран
с этим как раз не будет никаких проблем :)
проблема с UI?! см. Wings3d
>но еще из-за вывода на экран
с этим как раз не будет никаких проблем :)
В качестве GUI в стандартной поставке идет TK, неплохо с erlang стыкующийся по стилю, как мне показалось. Wings3D использует SDL. В теории, можно сделать биндинги и для других библиотек UI.
Не в биндингах дело, а в том что реализация интерфейса пользователя на императивном языке реализуется проще чем на функциональном.
Erlang императивен в достаточной мере. Да и отдельно взятый Tcl/Tk, на котором базируется стандартный GUI, не назовешь чисто императивной системой.
Вообще говоря, вы хотя бы с Tk-примерами из стандартного пакета знакомились?
PS. Я, конечно, не буду спорить, что Erlang изначально для создания GUI-приложений не предназначен. Но, тем не менее, получаться может вполне неплохо.
Вообще говоря, вы хотя бы с Tk-примерами из стандартного пакета знакомились?
PS. Я, конечно, не буду спорить, что Erlang изначально для создания GUI-приложений не предназначен. Но, тем не менее, получаться может вполне неплохо.
не проще, наоборот, сложнее
посмотрите, к примеру, Functional Reactive Programming — есть даже JavaScript-фреймворк в этой парадигме (FLAPJAX)
там вы декларативно (а не императивно) описываете интерактивность — что позволяет с легкостью реализовать это в любом функциональном языке
кстати, WPF/XAML в .NET 3 — живой пример этому (Bindings в XAML — это FRP), ведь XAML это вполне себе декларативный язык, многое можно сделать в нём даже без императивного code behind
посмотрите, к примеру, Functional Reactive Programming — есть даже JavaScript-фреймворк в этой парадигме (FLAPJAX)
там вы декларативно (а не императивно) описываете интерактивность — что позволяет с легкостью реализовать это в любом функциональном языке
кстати, WPF/XAML в .NET 3 — живой пример этому (Bindings в XAML — это FRP), ведь XAML это вполне себе декларативный язык, многое можно сделать в нём даже без императивного code behind
Извините меня, но вы не считаете, что приобразовывать GUI в dataflow а затем их обрабатывать довольно странное IMHO дело и требует дополнительной прослойки между GUI тулкитом (который кстати как раз написан на императивном языке) и собственно фукнциональным языком? В случае веба это конечно удобно поскольку там уже есть такая прослойка, которая в указанной вами парадигме может быть тоньше. Но вот в случае GUI мне кажется она будет толще.
а чем в вашем понимании интерфейсы в вебе отличаются от "GUI"?
не вижу никакого криминала, кстати, в преобразовании declarative -> imperative, декларативный код сам по себе святым духом исполняться не будет ведь
а FRP возможен в любом языке, хоть в C
функциональное/декларативное программирование не привязано к языку, просто в языке, который на семантическом и синтаксическом уровне поддерживает такой стиль — это делать проще, только и всего
к примеру, в .NET всё это дело прекрасно живет в среде императивного C#, просто из-за негибкости языка пришлось сделать доп. декларативную прослойку в виде XAML, в случае Haskell или Erlang этого делать бы не пришлось
не вижу никакого криминала, кстати, в преобразовании declarative -> imperative, декларативный код сам по себе святым духом исполняться не будет ведь
а FRP возможен в любом языке, хоть в C
функциональное/декларативное программирование не привязано к языку, просто в языке, который на семантическом и синтаксическом уровне поддерживает такой стиль — это делать проще, только и всего
к примеру, в .NET всё это дело прекрасно живет в среде императивного C#, просто из-за негибкости языка пришлось сделать доп. декларативную прослойку в виде XAML, в случае Haskell или Erlang этого делать бы не пришлось
а чем в вашем понимании интерфейсы в вебе отличаются от "GUI"?
Вообще-то они различаются подходами и механизмами. И кстати очень сильно.
не вижу никакого криминала, кстати, в преобразовании declarative -> imperative, декларативный код сам по себе святым духом исполняться не будет ведь
Пока не появится машины которая будет выполнять функциональный язык на уровне железа будет всегда наблюдаться преобразование функционал в императив.
функциональное/декларативное программирование не привязано к языку.
На любом тьюринг полном языке можно сделать все что угодно. Но вот количество затраченных ресусров может сильно различаться для разных задач.
>> Вообще-то они различаются подходами и механизмами. И кстати очень сильно.
не вижу разницы — это интерфейс человек-машина, мышкоклавиатурновизуальный
задачи у веб-приложений и десктоп-приложений одинаковые, просто сегодня еще есть это разделение из-за несовершенства технологий, а завтра его уже не будет
>> Пока не появится машины которая будет выполнять функциональный язык на уровне железа будет всегда наблюдаться преобразование функционал в императив.
такого железа никогда не появится, потому что машина Тьюринга — это наиболее близкая к реальности абстракция
>> Но вот количество затраченных ресусров может сильно различаться для разных задач.
именно это я и сказал — FRP проще в функциональном языке
а учитывая то, что FRP проще "императивной интерактивности" следует то, что программировать GUI в функциональных языках — проще
не вижу разницы — это интерфейс человек-машина, мышкоклавиатурновизуальный
задачи у веб-приложений и десктоп-приложений одинаковые, просто сегодня еще есть это разделение из-за несовершенства технологий, а завтра его уже не будет
>> Пока не появится машины которая будет выполнять функциональный язык на уровне железа будет всегда наблюдаться преобразование функционал в императив.
такого железа никогда не появится, потому что машина Тьюринга — это наиболее близкая к реальности абстракция
>> Но вот количество затраченных ресусров может сильно различаться для разных задач.
именно это я и сказал — FRP проще в функциональном языке
а учитывая то, что FRP проще "императивной интерактивности" следует то, что программировать GUI в функциональных языках — проще
не вижу разницы — это интерфейс человек-машина, мышкоклавиатурновизуальный
Механизмы что заложенны в их основе и то как они организовываются различны и очень сильно различны. Сравните к примеру CGI с тем же QT или GTK и поймете чем разница.
просто сегодня еще есть это разделение из-за несовершенства технологий, а завтра его уже не будет
Для того чтобы убрать разницу вам потребуется немного немало, а сломать нафиг весь современный веб.
такого железа никогда не появится
В 70-80 годах строили lisp машины. В их разработке кстати участвовал Столлман.
именно это я и сказал — FRP проще в функциональном языке
Вообще-то я говорил про то что многие задачи проще решаются на императивных языках.
а учитывая то, что FRP проще "императивной интерактивности" следует то, что программировать GUI в функциональных языках — проще
Ну если вы так настаиваете, то я вам советую написать простой почтовый GUI-клиент который имеет настройку pop3 ящика отображения списка почты пометку того что оно прочитанно и вывод письма в виде плантекста, сначала на erlang а затем на императивном языке. К примеру java, а затем сравните объем кода который потребуется для работы логики интерфейса.
>> Сравните к примеру CGI с тем же QT или GTK и поймете чем разница
CGI - это common gateway interface? ну и как его можно сравнивать с GUI фреймворком? это же разные вещи
вот например Yahoo UI library для яваскрипта и GTK очень даже можно сравнить
>> В 70-80 годах строили lisp машины.
это были просто беспомощные игрушки, они были слишком сложные, чтобы работать эффективнее, чем Core 2 :)
сложные вещи не работают
>> Вообще-то я говорил про то что многие задачи проще решаются
многие — это какие? не будьте голословны
я пока не вижу ни одной large-scale задачи, которая проще решается на императивном языке
существует критерий эффективности рендеринга в hardware execution модель — здесь императивные языки, безусловно, обладают большим потенциалом, т.к. они ближе к этой модели
но чтобы простота и в императивном языке — я такого не видел
>> Ну если вы так настаиваете, то я вам советую написать простой почтовый GUI-клиент
я вас уверяю, что на Erlang кода будет меньше и он будет чище, чем с Java — это подсказывает мне мой опыт в императивных и функциональных языках
сделать для Erlang биндинг к какому-нибудь рендереру для рисования "квадратиков и кнопочек" — много ума не надо
разумеется, если мне надо будет написать почтовый клиент для десктопа — я возьму WPF а не erlang, потому что для Erlang надо писать биндинги, а WPF уже сегодня работает из коробки
CGI - это common gateway interface? ну и как его можно сравнивать с GUI фреймворком? это же разные вещи
вот например Yahoo UI library для яваскрипта и GTK очень даже можно сравнить
>> В 70-80 годах строили lisp машины.
это были просто беспомощные игрушки, они были слишком сложные, чтобы работать эффективнее, чем Core 2 :)
сложные вещи не работают
>> Вообще-то я говорил про то что многие задачи проще решаются
многие — это какие? не будьте голословны
я пока не вижу ни одной large-scale задачи, которая проще решается на императивном языке
существует критерий эффективности рендеринга в hardware execution модель — здесь императивные языки, безусловно, обладают большим потенциалом, т.к. они ближе к этой модели
но чтобы простота и в императивном языке — я такого не видел
>> Ну если вы так настаиваете, то я вам советую написать простой почтовый GUI-клиент
я вас уверяю, что на Erlang кода будет меньше и он будет чище, чем с Java — это подсказывает мне мой опыт в императивных и функциональных языках
сделать для Erlang биндинг к какому-нибудь рендереру для рисования "квадратиков и кнопочек" — много ума не надо
разумеется, если мне надо будет написать почтовый клиент для десктопа — я возьму WPF а не erlang, потому что для Erlang надо писать биндинги, а WPF уже сегодня работает из коробки
CGI - это common gateway interface? ну и как его можно сравнивать с GUI фреймворком? это же разные вещи
То что это разные вещи я знаю и без вас. Это вы уверяете, что нет никакой разницы между обычным веб-приложением и десктоп-приложением. А вообще эта разница есть.
вот например Yahoo UI library для яваскрипта и GTK очень даже можно сравнить
Их можно сравнить только как средства построения интерфейса.
сложные вещи не работают
Среда обеспечивающая работу Erlang сложна, но при этом она работает.
не будьте голословны
GUI-приложения, различные десктопные окружения аля KDE.
я пока не вижу ни одной large-scale задачи, которая проще решается на императивном языке
Какие из? Таких задач довольно много. К примеру моделирование погоды. Я что-то не слышал чтобы там использовали Erlang.
я вас уверяю, что на Erlang кода будет меньше и он будет чище, чем с Java — это подсказывает мне мой опыт в императивных и функциональных языках
А я вот сильно сомневаюсь. И могу сказать, что это будет сильно зависеть от того как у вас написаны биндинги и как вы построите интерфейс.
сделать для Erlang биндинг к какому-нибудь рендереру для рисования "квадратиков и кнопочек" — много ума не надо
Проблема не в рисовании, а в том как это правильно использовать, чтобы получить меньше кода чем на императивном языке.
разумеется, если мне надо будет написать почтовый клиент для десктопа — я возьму WPF а не erlang, потому что для Erlang надо писать биндинги, а WPF уже сегодня работает из коробки
Это просто целесообразнее и даст более быстрый результат. Собственно о чем я и толкую.
>> А вообще эта разница есть.
для меня, как для пользователя — разницы нет, какая разница, что находится внизу стека технологий, если в конечном счете работа идет с вершиной стека
>> Среда обеспечивающая работу Erlang сложна, но при этом она работает.
вам кажется — на самом деле, оптимизирующий компилятор C++ с поддержкой OpenMP на порядок сложнее виртуальной машины Эрланга
>> GUI-приложения, различные десктопные окружения аля KDE.
хочется продолжить: .. операционные системы :)
*thumbs up*
>> чтобы получить меньше кода чем на императивном языке
вообще-то, объем код сокращается не языком, а программными абстракциями, например — FRP
абстракции проще моделировать на функциональном языке — это факт
>> К примеру моделирование погоды. Я что-то не слышал чтобы там использовали Erlang.
а я бы использовал там Erlang - для распределенности, а числодробилку вынес бы в C-код
получилось бы очень эффективно и малой ценой
многие числодробильные задачи раскладываются на scatter/gather, т.е. параллелизм по данным
для меня, как для пользователя — разницы нет, какая разница, что находится внизу стека технологий, если в конечном счете работа идет с вершиной стека
>> Среда обеспечивающая работу Erlang сложна, но при этом она работает.
вам кажется — на самом деле, оптимизирующий компилятор C++ с поддержкой OpenMP на порядок сложнее виртуальной машины Эрланга
>> GUI-приложения, различные десктопные окружения аля KDE.
хочется продолжить: .. операционные системы :)
*thumbs up*
>> чтобы получить меньше кода чем на императивном языке
вообще-то, объем код сокращается не языком, а программными абстракциями, например — FRP
абстракции проще моделировать на функциональном языке — это факт
>> К примеру моделирование погоды. Я что-то не слышал чтобы там использовали Erlang.
а я бы использовал там Erlang - для распределенности, а числодробилку вынес бы в C-код
получилось бы очень эффективно и малой ценой
многие числодробильные задачи раскладываются на scatter/gather, т.е. параллелизм по данным
для меня, как для пользователя — разницы нет
Пользователя вообще не волнует что там работает. Но мы то свами смотрим изнутри а не снаружи.
а самом деле, оптимизирующий компилятор C++ с поддержкой OpenMP на порядок сложнее виртуальной машины Эрланга
Компилятор с виртуальной машиной сравнивать не корректно. Если кто-то начнет сделает компилятор Erlang то я не думаю что он будет напорядок проще чем компилятор C++ с поддержкой OpenMP.
хочется продолжить: .. операционные системы :)
И они тоже. :)
вообще-то, объем код сокращается не языком, а программными абстракциями, например — FRP
Абстракции обычно привязаны к парадигме языка. В функциональной парадигме это будут одни абстракции, в императивной совсем другие.
абстракции проще моделировать на функциональном языке — это факт
Не всегда. Зависит от предметной области. Я просто когда диплом писал читал одну замечательную работу в которой математики моделировали биллинг математическими методами. Мягко говоря это было нечто. Особенно порадовало то как они выводили ту модель которая бы позволила им универсально обрабатывать услуги.
а я бы использовал там Erlang - для распределенности, а числодробилку вынес бы в C-код
получилось бы очень эффективно и малой ценой
И требовала бы человека который все это знает. К тому же OpenMP это тоже позволяет, хотя возможно и более затратно нежели это делает Erlang.
многие числодробильные задачи раскладываются на scatter/gather, т.е. параллелизм по данным
Вот на это Erlang хорошо заточен в силу того куда он специализируется. Для софтовой начинки различного телекоммуникационного оборудования очень удобная штука.
>> Если кто-то начнет сделает компилятор Erlang
у эрланга и так есть JIT-компилятор HiPe, да и мы сейчас сравниваем существующие уже сегодня решения для параллелизма — Эрланг проще на порядок и на прикладном уровне эффективнее, чем C++ с OpenMP, факт
>> К тому же OpenMP это тоже позволяет
OpenMP не позволяет разнести числодробление на 1000 машин, а в Erlang это встроено — какой смысл запускать моделирование погоды на одном компе, пусть и с 32-ядерным процессором
P.S. тред уже слишком затянулся, хабр начинает глючить при таком уровне вложенности
у эрланга и так есть JIT-компилятор HiPe, да и мы сейчас сравниваем существующие уже сегодня решения для параллелизма — Эрланг проще на порядок и на прикладном уровне эффективнее, чем C++ с OpenMP, факт
>> К тому же OpenMP это тоже позволяет
OpenMP не позволяет разнести числодробление на 1000 машин, а в Erlang это встроено — какой смысл запускать моделирование погоды на одном компе, пусть и с 32-ядерным процессором
P.S. тред уже слишком затянулся, хабр начинает глючить при таком уровне вложенности
OpenMP не позволяет разнести числодробление на 1000 машин, а в Erlang это встроено
Уже может, есть Intel Cluster OpenMP.
На прикладном уровне да, но в больших системах, когда на уровне продумывания рассчётов и минимизации пересылок всё продумано, никакого прироста в производительности Erlang не даст. В любом случае лимитирующим фактором будет являться время пересылки между узлами, даже в самых быстрых сетях.
И от этапа продумывания, на котором вычисления собственно и распараллеливаются никуда не деться, а если он пройден, то уже не столь важно на чём писать.
К примеру моделирование погоды. Я что-то не слышал чтобы там использовали Erlang.
Значит, он еще просто не популярен в этой отрасли. Кстати, наверняка, зря не используют. В моем понимании, Erlang там очень подойдет.
К примеру моделирование погоды. Я что-то не слышал чтобы там использовали Erlang.Да что уж говорить, в таких задачах и Fortran до сих пор используют, и не жалеют об этом ;)
Сравните к примеру CGI с тем же QT или GTK
Вот тут вы смешиваете теплое с мягким. CGI к UI не имеет отношения явно.
сломать нафиг весь современный веб
Собственно, к этому дело и идет. А вообще, что вы имеете ввиду под "современный веб"?
написать простой почтовый GUI-клиент
Занятная идея для саморазвития, надо попробовать. =)
Вот тут вы смешиваете теплое с мягким. CGI к UI не имеет отношения явно.
Аналог CGI есть внутри каждого фреймвока аля QT, но у десктопа во первых нет такой латентности и внутри фреймворка каждый может городить свою систему того как будут вызываться события.
Собственно, к этому дело и идет. А вообще, что вы имеете ввиду под "современный веб"?
http протокол и собственно методы взаимодействия клиента и сервера.
Занятная идея для саморазвития, надо попробовать. =)
Попробуйте. Для понимания почему это не стоит делать это сделать стоит.
>> http протокол и собственно методы взаимодействия клиента и сервера.
вот недавно писал терминал на Flex/ActionScript с сервером на PHP — никакого http протокола я не видел, работал на уровне SOAP-вызовов
пересылку по HTTP за меня делала программная абстракция
и "взаимодействие клиента и сервера" свелось в коде к прямому вызову функций
вот недавно писал терминал на Flex/ActionScript с сервером на PHP — никакого http протокола я не видел, работал на уровне SOAP-вызовов
пересылку по HTTP за меня делала программная абстракция
и "взаимодействие клиента и сервера" свелось в коде к прямому вызову функций
вот недавно писал терминал на Flex/ActionScript с сервером на PHP — никакого http протокола я не видел, работал на уровне SOAP-вызовов
Во флеше так можно. Еще четыре года назад мы предлагали одному товарищу написать интерфейс целиком на флеше, а с сервером обмениваться при помощи XML. А я вообще-то говорил про взаимодействие браузера с сервером через протокол http.
Flex это и есть флеш (абстракция над ним)
>> А я вообще-то говорил про взаимодействие браузера с сервером через протокол http.
угу, вот мой терминал работает в браузере и взаимодействует с сервером через протокол http — хоть я напрямую и не работаю с http
что я делаю не так? :)
как мне увидеть разницу-то?
>> А я вообще-то говорил про взаимодействие браузера с сервером через протокол http.
угу, вот мой терминал работает в браузере и взаимодействует с сервером через протокол http — хоть я напрямую и не работаю с http
что я делаю не так? :)
как мне увидеть разницу-то?
В случае флеша вы его не увидите. Но флеш вообще-то не является частью бразуера. И если я удалю флеш-плагин, то ваш сайт перестанет рабоать. К тому же в случае флеша http не более чем транспорт используемый для SOAP.
нет, ну вы конечно сейчас забрели в какие-то логические дебри
флеш является частью браузера, пусть и опциональной
точно так же можно сказать — javascript не является частью браузера, ведь его можно отключить!
короче, ответьте на вопрос — чем для программиста десктоп-приложения отличаются от веб-приложений?
я разницы не вижу — как программировал раньше для десктопа, так сейчас и для веба программирую
флеш является частью браузера, пусть и опциональной
точно так же можно сказать — javascript не является частью браузера, ведь его можно отключить!
короче, ответьте на вопрос — чем для программиста десктоп-приложения отличаются от веб-приложений?
я разницы не вижу — как программировал раньше для десктопа, так сейчас и для веба программирую
Аналог CGI есть внутри каждого фреймвока аля QT
А можно более конкретно? Что вы назовете аналогом CGI в том же QT? Я просто не могу провести аналогию... Вообще, AFAIK, CGI - это стандарт имеющий мало отношения к непосредственно интерфейсу пользователя, это интерфейс связи.
Далее, латентность. Как она зависит от парадигмы языка реализации интерфейса? Латентность, в данном случае, вопрос лишь канала связи.
http протокол...
А это-то причем? Для кода UI это все закрыто бесчисленными абстракциями.
Вообще, AFAIK, CGI - это стандарт имеющий мало отношения к непосредственно интерфейсу пользователя, это интерфейс связи.
Это скорее интерфейс преобразования. Он преобразовывает полученные сервером от бразуера пользователя данные в более удобосваримый формат. В случае QT эта та часть которая переводит нажатие клавиши пользователя в событие которое затем вызывает какой либо метод.
Далее, латентность. Как она зависит от парадигмы языка реализации интерфейса? Латентность, в данном случае, вопрос лишь канала связи.
А причем тут парадигма языка реализации интерфейса? Я про парадигму самого интерфейса. Методики построения эффективных веб-интерфейсов и десктоп-интерфейсов различаются.
А это-то причем? Для кода UI это все закрыто бесчисленными абстракциями.
При том что в каждом вебфремворке его прийдется учитывать и использовать.
Да скажите вы вообще веб-приложения писали?
>> Методики построения эффективных веб-интерфейсов и десктоп-интерфейсов различаются.
это неправда, они ничем не отличаются
говорю вам, как разработчик вебсервисов и десктоп-приложений
это неправда, они ничем не отличаются
говорю вам, как разработчик вебсервисов и десктоп-приложений
вы вообще веб-приложения писали?
Приходилось, хотя значительно реже десктопных.
Я про парадигму самого интерфейса.
Простите, а что есть императивность и декларативность в случае интерфейса? Точнее, являются ли они чем-то кроме методики реализации его?
Веб-фреймворк - это уровень абстракции, "учитывать и использовать" это его задача. Причем тут непосредственно UI, о которых изначально шла речь?
Это скорее интерфейс преобразования.
Это интерфейс связи между UI и серверной частью. Формально говоря, это даже интерфейс связи между веб-сервером и непосредственно обаботчиком. Повторяюсь, причем здесь собственно UI?
Точнее, являются ли они чем-то кроме методики реализации его?
Если вы вернетесь к началу то увидите что я говорил про подходы реализации.
Веб-фреймворк - это уровень абстракции, "учитывать и использовать" это его задача. Причем тут непосредственно UI, о которых изначально шла речь?
Повторяюсь, причем здесь собственно UI?
UI тут вообще не причем. Я говорил про разные подходы используемые при создании web-приложения и desktop-приложения. Если вы считаете что нет никакой разницы, то скажите мне что одинакового у django MVC-вебфреймворка и у QT-тулкита именно на уровне реализации.
Да, раз уж пошел разговор за GUI. А не кажется ли вам, что большая часть фреймворков, по меньшей мере на десктопе, построена на сообщениях? Да, вокруг этого есть ОО-обертки, но механизмы сообщений все еще активно используются. Теперь взглянем на Erlang, и что мы видим? Ту же концепцию сообщений, только в профиль. Т.е. для взаимодействия с большей частью UI-систем Erlang подходит просто-таки на уровне концепции.
В случае erlang вам прийдется вместо каждого объекта плодить процесс, что приведет к усложению кода. И как мне кажется вызов метода объекта по событию будет менее трудоемко. Я отлично понимаю что создание процесса в ерланге дешево, но поблема у вас начнет возникать когда их будет много.
вызов метода объекта по событию будет менее трудоемко
Интересный вопрос. По идее, реализация приема сообщения и реакции на него в Erlang должна быть просто безукоризненной - это ключевой элемент языка. А принципиальных различий в этих методиках, AFAIK, нет.
Процессы вместо объектов, судя по все тем же стандартным примерам, нисколько не усложняют код, он остается абсолютно прозрачным и логичным.
Процесс плодить для каждого примитива не придется. Значительная часть примитивов обслуживается фремворком или ОС.
По идее, реализация приема сообщения и реакции на него в Erlang должна быть просто безукоризненной - это ключевой элемент языка.
Не забывайте еще про генерацию.
Процессы вместо объектов, судя по все тем же стандартным примерам, нисколько не усложняют код, он остается абсолютно прозрачным и логичным.
Это сильно зависит от их количества.
Процесс плодить для каждого примитива не придется.
Это уже будет зависеть от задачи и того как реализовано.
Не забывайте еще про генерацию.
На уровне Erlang VM, опять таки, это должно быть очень оптимизировано. Разницы-то особой и нет, что фреймворк поймает сообщение от ОС и вызовет метод объекта, что фреймворк отправит соответственное сообщение процессу.
Это сильно зависит от их количества.
Которое уже зависит "от задачи и того как реализовано".
Кстати, еще интересно, что "тяжеловеснее" - множество процессов, обменивающихся сообщениями, или множество объектов, обменивающихся вызовами методов. =)
А стоимость обучения персонала?
Отличный язык, когда создадут 128 ядерный процессор, он станет работать также быстро, как вас старый С на дуал коре. Отличный язык.
Я что-то не очень понимаю каким образом (барабанная дробь) Concurrency Oriented Programming связано с вычисление площади кружочка.
Почему-бы не привести в пример какое-то более мотивированное и связанное с сутью языка применение.
Честно говоря, уже утомили примеры кода "как я в одну строчку пишу никому не нужный функционал, а на Java/C++/C# эта функция занимает 5 строчек, хотя ее кроме как на уроке информатики никто никогда не напишет".
Почему-бы не привести в пример какое-то более мотивированное и связанное с сутью языка применение.
Честно говоря, уже утомили примеры кода "как я в одну строчку пишу никому не нужный функционал, а на Java/C++/C# эта функция занимает 5 строчек, хотя ее кроме как на уроке информатики никто никогда не напишет".
статья написана техническим "евангелистом" — задача была поднять интерес общественности к Erlang, а не грузить техническими подробностями
это что-то вроде интро
пример кода был дан чтобы показать мощь pattern matching для декомпозиции структур данных / мульти-диспатча — на Erlang только так и программируют
это что-то вроде интро
пример кода был дан чтобы показать мощь pattern matching для декомпозиции структур данных / мульти-диспатча — на Erlang только так и программируют
btw, добавил в конец статьи пример с ping-pong
Пример очень похож на маркетинговую политику компании Ectaco - что мешало все определения классов на яве запихать в библиотеку, ведь это и сделано на примере Erlang? А в остальном - наверное правда... в институте писал простенькие игрухи, где каждым юнитом AI управлял отдельный поток - и на многоядреных процессорах было опять же пропорциональное увеличение производительности... Но это все сугубо ИМХО
Ну и толку в этой рекламе? Покажите мне серьезный работающий пример. Черт возьми, да хотя бы один паттерн. Я знаю как пользоваться гуглом, я нашел какую-то книгу, но пока такого примера нет в этом посте, он для меня просто реклама, восторженное эссе маркетолога ниочем.
вы зря.
на ерланге пишут часто. CouchDB - последнее что мне попадалось.
на ерланге пишут часто. CouchDB - последнее что мне попадалось.
Скорее всего это и есть реклама. Попытка заинтересовать людей Эрлангом.
Тоже неплохо.
Тоже неплохо.
Amazon SimpleDB — плохой пример?
предполагается, что тех, кого заинтересует Erlang сами найдут любые технические подробности — в том же гугле
>> восторженное эссе маркетолога ниочем
не "ни о чём", а про Erlang
без рекламы вы бы про Erlang вообще не услышали
>> восторженное эссе маркетолога ниочем
не "ни о чём", а про Erlang
без рекламы вы бы про Erlang вообще не услышали
перефразирую: зачем реклама такая длинная? Я потратил 5 минут своего времени на фигню. Я честно пытался найти в тексте что-то стоящее.
вы потратили 5 минут времени на то, чтобы узнать, что есть вот такая штука — Erlang, и "о чём" эта штука
а каков синтаксис языка для передачи сообщений — это тема для другой статьи
вам что, надо Hello World но в терминах message-passing? классический пример "ping-pong" или thread ring? вы потратите куда больше времени, чем 5 минут на то, чтобы разобрать такой код на незнакомом языке, а практическая ценность такого кода не больше, чем "вычислить площадь с pattern matching"
хотите "реальных примеров" — скачайте ejabberd в исходниках
а каков синтаксис языка для передачи сообщений — это тема для другой статьи
вам что, надо Hello World но в терминах message-passing? классический пример "ping-pong" или thread ring? вы потратите куда больше времени, чем 5 минут на то, чтобы разобрать такой код на незнакомом языке, а практическая ценность такого кода не больше, чем "вычислить площадь с pattern matching"
хотите "реальных примеров" — скачайте ejabberd в исходниках
мне кажется Вы прекрасно поняли что я имел ввиду. Но все-таки я поясню: я захожу на хабр, открываю пост с интересным заголовком и вижу спам, я пробегаю глазами первый абзац - это все ещё спам, второй - нет результата. Но заголовок интересный а пост большой, я продолжаю читать. Я прочитываю ВЕСЬ пост, все несколько абзацев спама и не нахожу ничего интересного, т.е. вообще ничего. Уберите рекламные обороты и текст сократится в 3 раза, а то и больше.
Мне не нравится что прочитав так много я получил так мало, вот и всё. Если бы пост был маленьким, то я бы просто ознакомился с ним и успокоился.
Мне не нравится что прочитав так много я получил так мало, вот и всё. Если бы пост был маленьким, то я бы просто ознакомился с ним и успокоился.
специально для вас — добавил в конец статьи пример с ping-pong
спама на хабре хватает, а это статья, которая полезна людям, разрабатывающим распределенные приложения (скалируемый server-side, например, в контексте веба)
>> второй - нет результата.
почему же, есть результат — посмотрите на кол-во комментов к статье, куча народу сегодня узнали про Erlang
>> Уберите рекламные обороты и текст сократится в 3 раза, а то и больше.
и что от статьи останется? "есть вот такая штука Erlang, да, вот такие-то цифры показывают то-то", очень интересная статья
а главное, что тогда задачи своей она не выполнит — не вызовет интереса
спама на хабре хватает, а это статья, которая полезна людям, разрабатывающим распределенные приложения (скалируемый server-side, например, в контексте веба)
>> второй - нет результата.
почему же, есть результат — посмотрите на кол-во комментов к статье, куча народу сегодня узнали про Erlang
>> Уберите рекламные обороты и текст сократится в 3 раза, а то и больше.
и что от статьи останется? "есть вот такая штука Erlang, да, вот такие-то цифры показывают то-то", очень интересная статья
а главное, что тогда задачи своей она не выполнит — не вызовет интереса
ну не знаю, не знаю. Я обычно статьи написанные в таком стиле пропускаю на автомате. А интерес можно вызывать и по другому, ближе к техническим деталям.
>> ближе к техническим деталям
ну это будет совсем другая статья и не совсем про Erlang
к примеру, чтобы объяснить нетривиальность распараллеливания в языках с shared memory надо целую книгу написать
без таких "рекламных" статей у языка никогда не появится такого же комьюнити, как у Ruby или Python — Erlang существует уже пару десятков лет, но до недавнего времени о нём вообще никто не слышал
ну это будет совсем другая статья и не совсем про Erlang
к примеру, чтобы объяснить нетривиальность распараллеливания в языках с shared memory надо целую книгу написать
без таких "рекламных" статей у языка никогда не появится такого же комьюнити, как у Ruby или Python — Erlang существует уже пару десятков лет, но до недавнего времени о нём вообще никто не слышал
сравнивать erlang с Си (как там люди вверху делали) - абсурд. На си для 128-ядерного сервера всегда будет можно написать монстроидальное приложение, загрузив сервер на максимум. Вот только времени это займёт - тонну.
Сравнивать ерланг по производительности с чем-то там ещё вообще нет смысла. Суть-то в том, что даже на питоне занять 128 ядер можно (пока) только форкая процессы. Тут 3 месяца назад была задачка - многопоточный парсинг лога, которая превратилась в конкурс (погуглите). Так вот там на ерланге за полчаса кто-то наваял малююююсенькую штучку которая просто разорвала питон и все остальное (даже си). Ребята всполошились и понеслась... в течении недели все улучшали код на разных языках. Питон потом обогнал ерланг (но ТАКОЙ ценой, стоило только посмотреть что было в исходниках чтобы понять сложность). Затем кто-то вывел в перёд перл, и так он там и остался. Вот только код на перле тоже был сумасшедшим. И всего на чуть-чуть процентов быстрее чем на ерланге =). Собственно - полчаса vs неделя? Ни один сервер не стоит столько денег, сколько составила бы разница в стоимости разработчиков для большого проекта.
Сравнивать ерланг по производительности с чем-то там ещё вообще нет смысла. Суть-то в том, что даже на питоне занять 128 ядер можно (пока) только форкая процессы. Тут 3 месяца назад была задачка - многопоточный парсинг лога, которая превратилась в конкурс (погуглите). Так вот там на ерланге за полчаса кто-то наваял малююююсенькую штучку которая просто разорвала питон и все остальное (даже си). Ребята всполошились и понеслась... в течении недели все улучшали код на разных языках. Питон потом обогнал ерланг (но ТАКОЙ ценой, стоило только посмотреть что было в исходниках чтобы понять сложность). Затем кто-то вывел в перёд перл, и так он там и остался. Вот только код на перле тоже был сумасшедшим. И всего на чуть-чуть процентов быстрее чем на ерланге =). Собственно - полчаса vs неделя? Ни один сервер не стоит столько денег, сколько составила бы разница в стоимости разработчиков для большого проекта.
А подробности можно?
можно ссылку?
Проект называется Wide Finder
Все началось с публикации Tim Bray http://www.tbray.org/ongoing/When/200x/2… и проект продолжил шествие
* http://www.tbray.org/ongoing/When/200x/2…
* http://www.dalkescientific.com/writings/…
Все началось с публикации Tim Bray http://www.tbray.org/ongoing/When/200x/2… и проект продолжил шествие
* http://www.tbray.org/ongoing/When/200x/2…
* http://www.dalkescientific.com/writings/…
угу
результаты первой половинки - http://www.tbray.org/ongoing/When/200x/2…
результаты первой половинки - http://www.tbray.org/ongoing/When/200x/2…
ээ.. вы про это?
http://www.tbray.org/ongoing/When/200x/2…
далеко не с первой попытки в 10 раз проиграл руби на дуалкоре
http://www.tbray.org/ongoing/When/200x/2…
далеко не с первой попытки в 10 раз проиграл руби на дуалкоре
а вы правила читали? Какой дуалкоре нафик.
э, дуалкор появился позже.
покажите мне лучше где там малюсенькая штучка на ерланге за полчаса с лучшим результатом? 300+ строк эрланга против 130 питона и уж тем более 60 перла - это не "малюсенькая", а про полчаса я совсем не нашёл. Java'ы со Scala'ой, жаль, ещё нету, хотя я больше groovy люблю :)
покажите мне лучше где там малюсенькая штучка на ерланге за полчаса с лучшим результатом? 300+ строк эрланга против 130 питона и уж тем более 60 перла - это не "малюсенькая", а про полчаса я совсем не нашёл. Java'ы со Scala'ой, жаль, ещё нету, хотя я больше groovy люблю :)
да вы же уже результаты смотрите конечные. Эрланга вариантов там и то куча =). Вначале был эрланг который рвал всех (условием был минимум 8-ядерник SUN) и был достаточно прост.
Если бы вы почитали о вариантах на перле и питоне - там не в количествах строк дело, а в абстракции логики. mmap io, chunked reading... это всё весело, но использовать постоянно - нереально (не разумно сложно). Стоит ещё иметь ввиду что задача-то предельно простая =). При более сложной задаче это будет в разы сложнее.
Эрланг тоже не строками мерить надо, а сложностью. Для всех кто понимает эрланг и питон решение на эрланги выглядит проще, чем решение на питоне =).
Если бы вы почитали о вариантах на перле и питоне - там не в количествах строк дело, а в абстракции логики. mmap io, chunked reading... это всё весело, но использовать постоянно - нереально (не разумно сложно). Стоит ещё иметь ввиду что задача-то предельно простая =). При более сложной задаче это будет в разы сложнее.
Эрланг тоже не строками мерить надо, а сложностью. Для всех кто понимает эрланг и питон решение на эрланги выглядит проще, чем решение на питоне =).
ээ, линк на результаты вы сами дали, это раз, пруфлинк про полчаса и малюсенькую я так и не увидел. Энивэй, жду результатов scala\java
ну.. сорри но сейчас уже довольно непросто найти все что происходило =)
там когда запостили впервые о Wide Finder - куча блогов писали о нём, так вот через полчаса кто-то сразу на эрланге прислал решение. В упор не помню кто, а шарахаться по рсскам и анализировать кто же это был - мне тяжеловато. Хотите верьте, хотите - нет =).
там когда запостили впервые о Wide Finder - куча блогов писали о нём, так вот через полчаса кто-то сразу на эрланге прислал решение. В упор не помню кто, а шарахаться по рсскам и анализировать кто же это был - мне тяжеловато. Хотите верьте, хотите - нет =).
А насколько я помню, ситуация была как раз наоборот. Изначально писалось на Erlang, а вот другие уже соревновались с ним. http://www.tbray.org/ongoing/When/200x/2… , а на русском всю суть можно прочитать http://softwaremaniacs.org/blog/2007/10/…
выше был пример про атс, но от себя скажу, что если вы пользуетесь сотовой связью, то даже и не подозреваете что эрланг работает на вас каждый день) очень много продуктов эриксона реализовано на эрланге. чаще всего это оборудование радиоподсистемы. gprs-комплекс, а именно sgsn эриксон - чистый эрланг, ну и железо sun) надежность этого продукта действительно высока. да, забавный момент. в швеции чуть ли не каждая вторая компания, делающая продукты для телекома пишет на эрланге.
А почему пример кода - не "Hello World"? :))
Слишком предвзято. Тот же пример с площадью взять - нужные либы уже есть в Erlang и ими пользуются. Если эти либы были бы написаны для Java, код также был бы из трех строк (со статическими методами Square(..)). Не говорю, что язык плохой, говорю, что стоит почитать другие источники.
чтобы читать другие источники — надо сначала заинтересоваться Erlang'ом
в этом и заключается задача статьи
в этом и заключается задача статьи
Безотносительно релевантности примера для статьи:
«Либы» тут не при чём. Это фундаментальная возможность языка, pattern matching.
Надеюсь, флейма «PM — это всего лишь сахар, всё можно написать на Java» не последует, мне на RSDN хватило.
«Либы» тут не при чём. Это фундаментальная возможность языка, pattern matching.
Надеюсь, флейма «PM — это всего лишь сахар, всё можно написать на Java» не последует, мне на RSDN хватило.
"портируем некоторые приложения на 4-х ядерные процессоры — и знаете, что? После легкого допиливания они работают практически в 4 раза быстрее"
Есть задачи, на которых как ни пили не будет такого ускорения на 4х процессорах. Все дело в интенсивном обмене данными между процессорами. Делая лабораторные работы на MPI мы в этом убедились. Особенно заметно если процессоры связаны медленным каналом.
Есть задачи, на которых как ни пили не будет такого ускорения на 4х процессорах. Все дело в интенсивном обмене данными между процессорами. Делая лабораторные работы на MPI мы в этом убедились. Особенно заметно если процессоры связаны медленным каналом.
Вообще-то основная сложность в том, чтобы придумать такой алгоритм, который содержательно допускает распараллеливание. Если алгоритм придуман, то его можно запрограммировать на чем угодно (имея соответствующий базовый инструментарий) - хоть на C, хоть на Erlang, хоть вообще на Fortran-е. :) Да, чисто теоретически функциональные языки, в которых нет переменных, лучше подходят для распараллеливания кода, чем императивные, типа C. Но на практике нет свободно доступных компиляторов для функциональных языков, которые генерировали бы код сопоставимый по быстродействию с "C". Получается, что теоретически они лучше - а на практике побеждает "C", несмотря на такие фундаментальные проблемы оптимизации кода на нем, как aliasing указателей.
Далее, большинство функциональных языков явным или неявным образом завязаны на распределение памяти со сборкой мусора. Которое никогда не работало быстро и я думаю, что никогда быстро работать не будет. Самые лучшие аллокаторы со сборкой мусора ужасным образом трешат все кэши процессора и напрягают виртуальную память, а так же сами являются узким бутылочным горлом при параллельном программировании - они попросту вообще не thread-safe, обложены тем же mutex-ом. Thread-safe распределению памяти со сборкой мусора посвящена куча академических статей, но на практике такие аллокаторы в разы проигрывают обычным, так как требуют обвязки в виде многих машинных команд при вообще любом обращении по указателю.
Существует так же миллион других ФУНДАМЕНТАЛЬНЫХ проблем программирования и проблем ДИЗАЙНА ПРОЦЕССОРОВ, от которых никуда не уйти, ВНЕ ЗАВИСИМОСТИ от того, какой именно язык программирования используется. Не забывайте, что интерпретаторы или run-time среды языков типа Erlang написаны в конечном итоге на том же C или C++. :)
И еще с моей личной точки зрения писать большие проекты на функциональном языке гораздо сложнее и этот процесс больше напрягает голову, чем программирование на старом добром императивном языке. Хотя в узких областях функциональные языки "рулят" - дополняя код на каком-нибудь "C". :)
Далее, большинство функциональных языков явным или неявным образом завязаны на распределение памяти со сборкой мусора. Которое никогда не работало быстро и я думаю, что никогда быстро работать не будет. Самые лучшие аллокаторы со сборкой мусора ужасным образом трешат все кэши процессора и напрягают виртуальную память, а так же сами являются узким бутылочным горлом при параллельном программировании - они попросту вообще не thread-safe, обложены тем же mutex-ом. Thread-safe распределению памяти со сборкой мусора посвящена куча академических статей, но на практике такие аллокаторы в разы проигрывают обычным, так как требуют обвязки в виде многих машинных команд при вообще любом обращении по указателю.
Существует так же миллион других ФУНДАМЕНТАЛЬНЫХ проблем программирования и проблем ДИЗАЙНА ПРОЦЕССОРОВ, от которых никуда не уйти, ВНЕ ЗАВИСИМОСТИ от того, какой именно язык программирования используется. Не забывайте, что интерпретаторы или run-time среды языков типа Erlang написаны в конечном итоге на том же C или C++. :)
И еще с моей личной точки зрения писать большие проекты на функциональном языке гораздо сложнее и этот процесс больше напрягает голову, чем программирование на старом добром императивном языке. Хотя в узких областях функциональные языки "рулят" - дополняя код на каком-нибудь "C". :)
пока вы пишете на C "супер-эффективный" код, вылизывая каждый его байт так, чтобы он идеально ложился на x86...
дядя Петя собрал кластер из многопроцессорных тачек, набросал пару строк на Erlang для решения той же задачи — и грызет семки
это я шучу, разумеется
>> Но на практике нет свободно доступных компиляторов для функциональных языков, которые генерировали бы код сопоставимый по быстродействию с "C"
есть, компиляторы семейства ML — сопоставимы по эффективности генерируемого кода с C
>> Далее, большинство функциональных языков явным или неявным образом завязаны на распределение памяти со сборкой мусора
в функциональных языках возможен ескейп-анализ кода для замены heap allocations на stack allocations, чтобы не пришлось на каждый чих выделять объект на хипе
вообще исходя из моей практики — если у вас производительность упирается в работу кэша из-за нелокальности доступа это говорит о плохом дизайне
>> И еще с моей личной точки зрения писать большие проекты на функциональном языке гораздо сложнее и этот процесс больше напрягает голову, чем программирование на старом добром императивном языке.
а я сейчас пишу серверную часть на Erlang для вебсервиса — никакого напряга, про PHP забыл, как про страшный сон
дядя Петя собрал кластер из многопроцессорных тачек, набросал пару строк на Erlang для решения той же задачи — и грызет семки
это я шучу, разумеется
>> Но на практике нет свободно доступных компиляторов для функциональных языков, которые генерировали бы код сопоставимый по быстродействию с "C"
есть, компиляторы семейства ML — сопоставимы по эффективности генерируемого кода с C
>> Далее, большинство функциональных языков явным или неявным образом завязаны на распределение памяти со сборкой мусора
в функциональных языках возможен ескейп-анализ кода для замены heap allocations на stack allocations, чтобы не пришлось на каждый чих выделять объект на хипе
вообще исходя из моей практики — если у вас производительность упирается в работу кэша из-за нелокальности доступа это говорит о плохом дизайне
>> И еще с моей личной точки зрения писать большие проекты на функциональном языке гораздо сложнее и этот процесс больше напрягает голову, чем программирование на старом добром императивном языке.
а я сейчас пишу серверную часть на Erlang для вебсервиса — никакого напряга, про PHP забыл, как про страшный сон
Вообще кому как больше нравиться. С моей личной точки зрения больший интерес представляют языки с lazy evaluation, так как они привносят что-то реально новое, по сравнению с обычными императивными языками. А так получается больше игра с формой записи.
Если для Erlang будут сделаны компиляторы, которые на алгоритмах обработки структур данных (матриц, векторов, списков, деревьев, хешей и т.п., а не просто строк с урлами) дадут большее быстродействие, чем дают компиляторы "C" - я предпочту писать программы на Erlang. :) Имею ввиду большее быстродействие на одном процессоре, так как оно показывает качество кода, выдаваемого компилятором. Ведь распараллелить задачу на много ядер через использование передачи сообщений не сложно, и используется эта техника на практике уже больше 10 лет на моей памяти.
Автоматически векторизирующие и распараллеливающие компиляторы для императивных языков (включая "C") так же развиваются уже не один десяток лет и сейчас такие возможности предоставляют обычные mainstream компиляторы.
Что касается PHP, то тут вообще не о чем споить, IMHO. PHP - это скриптовый язык, видно, что изначально он предназначался для внесения несложной динамики в сайты маленьких проектов, магазинов и т.п. Но за неимением чего-то принципиально лучшего (другие классические интерпретируемые скриптовые языки не в счет) PHP стали использовать на всех этапах от создания простого прототипа, до продукта и почти повсеместно, включая мега-проекты, отчего он и распространился. Но не за счет своих преимуществ как языка программирования.
Если для Erlang будут сделаны компиляторы, которые на алгоритмах обработки структур данных (матриц, векторов, списков, деревьев, хешей и т.п., а не просто строк с урлами) дадут большее быстродействие, чем дают компиляторы "C" - я предпочту писать программы на Erlang. :) Имею ввиду большее быстродействие на одном процессоре, так как оно показывает качество кода, выдаваемого компилятором. Ведь распараллелить задачу на много ядер через использование передачи сообщений не сложно, и используется эта техника на практике уже больше 10 лет на моей памяти.
Автоматически векторизирующие и распараллеливающие компиляторы для императивных языков (включая "C") так же развиваются уже не один десяток лет и сейчас такие возможности предоставляют обычные mainstream компиляторы.
Что касается PHP, то тут вообще не о чем споить, IMHO. PHP - это скриптовый язык, видно, что изначально он предназначался для внесения несложной динамики в сайты маленьких проектов, магазинов и т.п. Но за неимением чего-то принципиально лучшего (другие классические интерпретируемые скриптовые языки не в счет) PHP стали использовать на всех этапах от создания простого прототипа, до продукта и почти повсеместно, включая мега-проекты, отчего он и распространился. Но не за счет своих преимуществ как языка программирования.
>> С моей личной точки зрения больший интерес представляют языки с lazy evaluation
да, ленивая семантика с каррингом дает просто невообразимую выразительную мощь
плохо лишь исполнение — компиляторы не умеют адекватно превращать ленивость в энергичность, поскольку для этого требуется анализ производительности кода — в общем случае это неразрешимо
в таком анализе может помочь он-лайн профилирование (т.е. сбор статистики с реально работающего кода), но, AFAIK, ни один компилятор Haskell этого не умеет
поэтому чтобы написать производительную программу на Haskell приходится везде вручную расставлять хинты для энергичного исполнения — код превращается в говно из-за мельтешащих везде хинтов :((
да, ленивая семантика с каррингом дает просто невообразимую выразительную мощь
плохо лишь исполнение — компиляторы не умеют адекватно превращать ленивость в энергичность, поскольку для этого требуется анализ производительности кода — в общем случае это неразрешимо
в таком анализе может помочь он-лайн профилирование (т.е. сбор статистики с реально работающего кода), но, AFAIK, ни один компилятор Haskell этого не умеет
поэтому чтобы написать производительную программу на Haskell приходится везде вручную расставлять хинты для энергичного исполнения — код превращается в говно из-за мельтешащих везде хинтов :((
Все-таки не понятно, почему вы считаете, что функциональные языки - это то, что придет на смену объектно ориентированным. Потому что появится 80-ядерные процессоры и на таких языках будет быстрее считать ? Если бы все определяла скорость приложения, то в эпоху 1-процессорных ЭВМ все бы писали на ассемблере. А ведь не пишут даже на С, который значительно быстрее С++. Премущество ООП в простоте создания и сопровождения бизнес-приложений. Разработчики создают абстрактные объекты, которые выполняют "физические" действия. Например, объект расходный кассовый ордер создать, заполнить, сохранить, распечатать. Важно то, что архитектуру можно расписать, не думая пока о том, как это будет делаться. Вообще я заметил, что многие высококлассные web-разработчики в силу своей специфики не совсем понимают, в чем суть ООП. Дадите кармы - обещаю написать хабратопик, что дает объектно-ориентированный подход, например в PHP :)
>> А ведь не пишут даже на С, который значительно быстрее С++.
эм. а вот каким местом C "быстрее" C++?
может, вы еще и считаете, что C++ это "ООП"-язык, а C, типа, нет?
>> Дадите кармы - обещаю написать хабратопик, что дает объектно-ориентированный подход, например в PHP :)
не дам, сначала вам надо осознать, что ООП ортогонально функциональным языкам, да и каким-либо языкам вообще
>> что функциональные языки - это то, что придет на смену объектно ориентированным
"объекто-ориентированные" языки — это миф
собственно, Армстронг в статье с большой-пребольшой иронией написал "эрланг - не объекто-ориентированный язык"
эм. а вот каким местом C "быстрее" C++?
может, вы еще и считаете, что C++ это "ООП"-язык, а C, типа, нет?
>> Дадите кармы - обещаю написать хабратопик, что дает объектно-ориентированный подход, например в PHP :)
не дам, сначала вам надо осознать, что ООП ортогонально функциональным языкам, да и каким-либо языкам вообще
>> что функциональные языки - это то, что придет на смену объектно ориентированным
"объекто-ориентированные" языки — это миф
собственно, Армстронг в статье с большой-пребольшой иронией написал "эрланг - не объекто-ориентированный язык"
(1) Си быстрее БЕЗапелляционно. Как разработчик ПО для промышленных контроллеров, это гарантирую. Код на Си практически линейно пропорционален коду на ассемблере по размеру. Код на С++ медленнее по очень простой причине - полиморфизм требует во время исполнения контекстного выбора вызываемой подпрограммы, поскольку сделать этот выбор на этапе компилирования невозможно. Поэтому каждый вызов полиморфного метода - это маленькая задержка.
(2) Си-не объектный язык. Читаем в хотя бы в википедии: "C is a general-purpose, block structured, procedural, imperative computer programming language developed in 1972 by Dennis Ritchie"
(3) вот и отлично что ортогональны, и согласен что ортогональны! Но это как раз и означает, что функциональные языки не придут на смену объектно-ориентированным - у каждого свое назначение. "Мамы разные нужны - мамы разные важны". Функциональным языкам лет не меньше, чем ООП. Еще лет 10 назад я купил книгу про Пролог и программы на нем писал, потому что говорили, что вот, сейчас Lisp и Prolog всех вытеснят, и до искуственного интеллекта рукой подать. Теперь стали говорить, что еще надо 50 лет.
(4) если обратиться к субъективному идеализму, то миф - вообще все, в том числе сам Армстронг. Никто не докажет, что он (Армстронг) существует объективно.
(2) Си-не объектный язык. Читаем в хотя бы в википедии: "C is a general-purpose, block structured, procedural, imperative computer programming language developed in 1972 by Dennis Ritchie"
(3) вот и отлично что ортогональны, и согласен что ортогональны! Но это как раз и означает, что функциональные языки не придут на смену объектно-ориентированным - у каждого свое назначение. "Мамы разные нужны - мамы разные важны". Функциональным языкам лет не меньше, чем ООП. Еще лет 10 назад я купил книгу про Пролог и программы на нем писал, потому что говорили, что вот, сейчас Lisp и Prolog всех вытеснят, и до искуственного интеллекта рукой подать. Теперь стали говорить, что еще надо 50 лет.
(4) если обратиться к субъективному идеализму, то миф - вообще все, в том числе сам Армстронг. Никто не докажет, что он (Армстронг) существует объективно.
>> Код на С++ медленнее по очень простой причине - полиморфизм требует во время исполнения контекстного выбора вызываемой подпрограммы
вас кто-то заставляет использовать полиморфизм?
вы ведь в курсе, наверное, что C — это подмножество C++ (ну если не рассматривать форкнутый C99)
мне очень интересно, как язык может быть "быстрее"
>> потому что говорили, что вот, сейчас Lisp и Prolog всех вытеснят, и до искуственного интеллекта рукой подать
да и языки ни при чём тут по большому счёту были тогда.. просто был какой-то хайп по поводу моделирования знаний и логики через rule engines, казалось, что вот-вот — и будет ИИ
вас кто-то заставляет использовать полиморфизм?
вы ведь в курсе, наверное, что C — это подмножество C++ (ну если не рассматривать форкнутый C99)
мне очень интересно, как язык может быть "быстрее"
>> потому что говорили, что вот, сейчас Lisp и Prolog всех вытеснят, и до искуственного интеллекта рукой подать
да и языки ни при чём тут по большому счёту были тогда.. просто был какой-то хайп по поводу моделирования знаний и логики через rule engines, казалось, что вот-вот — и будет ИИ
(1-2) С - не подмножество C++, так как в С++ неудачные операции выделения памяти вызывают исключение, а не возвращение NULL в указателе (хотя бы поэтому) Если не полиморфизм - то зачем использовать С++ ? ну разве чтобы вместо писать или чтобы декларации переменных можно было делать внутри функции...
(3) Быстрее здесь в узком смысле - программа быстрее, если она закончила равную работу за меньшее количество времени (например, сгенерировала быстрее контнект для отправки удаленному пользователю) Либо
за равное время сделал больше работы (сгенерировала контенты большему количеству удаленных пользователей)
(4) Разные виды языков для эволюции - это просто замечательно. Обратимся от войны к созиданию. Игра в пинг-понг - это хорошо, но есть практический вопрос, который уже частично обсуждался тут - представим есть касса продажи авиабилетов. Пользователи их покупают, указывая в формах номер места, на котором они предпочитали бы лететь. Компьютер в первую очередь должен попробовать продать пользователю именно то место, которое тот попросил, иначе предложить другое. Пользователи хотели бы посмотреть место, зарезервированное компьютером, прежде чем купить. Как это реализовать, используя ассинхронные сообщения и не имея общей памяти - какой шаблон программирования для этого использовать ? Умышленно избегал слов "блокировка таблицы на чтение, блокировка таблицы на запись" - наверное, в функциональных языках своя терминология ?
(3) Быстрее здесь в узком смысле - программа быстрее, если она закончила равную работу за меньшее количество времени (например, сгенерировала быстрее контнект для отправки удаленному пользователю) Либо
за равное время сделал больше работы (сгенерировала контенты большему количеству удаленных пользователей)
(4) Разные виды языков для эволюции - это просто замечательно. Обратимся от войны к созиданию. Игра в пинг-понг - это хорошо, но есть практический вопрос, который уже частично обсуждался тут - представим есть касса продажи авиабилетов. Пользователи их покупают, указывая в формах номер места, на котором они предпочитали бы лететь. Компьютер в первую очередь должен попробовать продать пользователю именно то место, которое тот попросил, иначе предложить другое. Пользователи хотели бы посмотреть место, зарезервированное компьютером, прежде чем купить. Как это реализовать, используя ассинхронные сообщения и не имея общей памяти - какой шаблон программирования для этого использовать ? Умышленно избегал слов "блокировка таблицы на чтение, блокировка таблицы на запись" - наверное, в функциональных языках своя терминология ?
>> С - не подмножество C++, так как в С++ неудачные операции выделения памяти вызывают исключение, а не возвращение NULL в указателе
с каких пор malloc в C++ начал бросать исключения?
>> Как это реализовать, используя ассинхронные сообщения и не имея общей памяти
общая память в данном случае есть, просто чтение и запись в/из неё — транзакционные, транзакция — это и есть посылка сообщения
обычно в Erlang для таких задач используют распределенную БД mnesia (тесно интегрированую в Erlang)
с каких пор malloc в C++ начал бросать исключения?
>> Как это реализовать, используя ассинхронные сообщения и не имея общей памяти
общая память в данном случае есть, просто чтение и запись в/из неё — транзакционные, транзакция — это и есть посылка сообщения
обычно в Erlang для таких задач используют распределенную БД mnesia (тесно интегрированую в Erlang)
(1) C++ может и так(NULL) и так(исключение). Например, в микрософтовской реализации это переключается функцией _set_new_mode(int mode).
(2) Да, я тоже себе так и представил, что посылка ассинхронного сообщения - это и есть транзакция. Проблема в другом. Представим, что я - процесс Эрланг. И я хочу зарезервировать место в самолете. Тогда я пишу письма всем (ВСЕМ!) другим процессам: "Дорогие братья и сестры. Я хочу зарезервировать место 345. С получением этого письма, 1) прекратите попытки резервировать место 345. 2) немедленно сообщите мне подтверждение получения письма, потому что если ХОТЯ БЫ ОДИН из вас это не сделает, я не смогу его зарезервировать.
(3) Я вам расскажу как работают РИБ на практике. Мои коллеги немцы пишут мне "Спецификация с которой ты должен работать, уже давно лежит в базе данных. Мы положили ее туда 45 минут назад!". Я уныло нажимаю "обновить". У меня нет спецификации. Где ж она ? Она "едет" на наш узел, и только злодей-админ что-то бормочет про ширину канала обмена. Как это поется "доктор едет-едет сквозь снежную равнину". Узкое место РИБ - обмен данными. Это где-то выше тоже обсуждалось.
(2) Да, я тоже себе так и представил, что посылка ассинхронного сообщения - это и есть транзакция. Проблема в другом. Представим, что я - процесс Эрланг. И я хочу зарезервировать место в самолете. Тогда я пишу письма всем (ВСЕМ!) другим процессам: "Дорогие братья и сестры. Я хочу зарезервировать место 345. С получением этого письма, 1) прекратите попытки резервировать место 345. 2) немедленно сообщите мне подтверждение получения письма, потому что если ХОТЯ БЫ ОДИН из вас это не сделает, я не смогу его зарезервировать.
(3) Я вам расскажу как работают РИБ на практике. Мои коллеги немцы пишут мне "Спецификация с которой ты должен работать, уже давно лежит в базе данных. Мы положили ее туда 45 минут назад!". Я уныло нажимаю "обновить". У меня нет спецификации. Где ж она ? Она "едет" на наш узел, и только злодей-админ что-то бормочет про ширину канала обмена. Как это поется "доктор едет-едет сквозь снежную равнину". Узкое место РИБ - обмен данными. Это где-то выше тоже обсуждалось.
цитата из документации к malloc в майкрософтской реализации:
By default, malloc does not call the new handler routine on failure to allocate memory
это значит, что семантически — malloc в C++ не отличается от malloc в C
Тогда я пишу письма всем (ВСЕМ!) другим процессам
ну если вы хотите в realtime отслеживать доступность всех мест в самолёте со всех терминалов — то, да, тут сервер будет слать сообщения клиентам об изменениях
Мы положили ее туда 45 минут назад!". Я уныло нажимаю "обновить"
мы друг друга не поняли
распределенные БД вроде mnesia обычно используются для ускорения доступа и отказоустойчивости — в составе высокопроизводительного кластера, там транзакция никак не может идти 45 минут
By default, malloc does not call the new handler routine on failure to allocate memory
это значит, что семантически — malloc в C++ не отличается от malloc в C
Тогда я пишу письма всем (ВСЕМ!) другим процессам
ну если вы хотите в realtime отслеживать доступность всех мест в самолёте со всех терминалов — то, да, тут сервер будет слать сообщения клиентам об изменениях
Мы положили ее туда 45 минут назад!". Я уныло нажимаю "обновить"
мы друг друга не поняли
распределенные БД вроде mnesia обычно используются для ускорения доступа и отказоустойчивости — в составе высокопроизводительного кластера, там транзакция никак не может идти 45 минут
>> Быстрее здесь в узком смысле - программа быстрее
вот и называйте вещи своими именами — программа быстрее, не язык
правильно будет так: "программа на C++, использующая полиморфизм будет медленнее, чем программа на C, не использующая полиморфизм"
вот только это несколько странное утверждение, поскольку, если полиморфизм нужен — то вы реализуете его и в C (через явную косвенность — указатели на функции), и ничем быстрее, чем в C++ это не будет
вот и называйте вещи своими именами — программа быстрее, не язык
правильно будет так: "программа на C++, использующая полиморфизм будет медленнее, чем программа на C, не использующая полиморфизм"
вот только это несколько странное утверждение, поскольку, если полиморфизм нужен — то вы реализуете его и в C (через явную косвенность — указатели на функции), и ничем быстрее, чем в C++ это не будет
Когда-то я тоже считал, что в Си что-то скрывается, что позволяет на ней писать более быстрые приложения :) Со временем осознал эту глупость и понял что на Си очень часто получается всё с точностью да наоборот, особенно когда нужен полиморфизм и пытаешься его реализовать на Си, то получается: либо делаешь нормально и это оборачивается в кучу макросов, либо кушаешь больше памяти и указатели на функции всё равно находятся за пределами кэш лайна с нужным объектом, что не даёт прироста производительности.. итд :)
У меня этот образ сверхпроизводительного Си появился под давлением Российского линуксового сообщества и в том стаде ещё много кто остался, кто будет с радостью кричать о том что Си почему-то быстрее ++ :)
У меня этот образ сверхпроизводительного Си появился под давлением Российского линуксового сообщества и в том стаде ещё много кто остался, кто будет с радостью кричать о том что Си почему-то быстрее ++ :)
что ж вы тут заладили с проблемой формулировок (оба). Всем понятно что на чистом Си (тут даже не полиформизм лепту вносит, а stdlib) всё работает намного шустрее. И опять же всем понятно что с помощью компиллятора С++ можно скопмилировать чистый Си. Разница - только в способе написания.
Я даже и не знаю как правильнее это назвать - "программа быстрее", "язык быстрее" или "конструкции языка" быстрее - какая разница? Если вы пишете на плюсах, то, скорее всего, со строками работаете через String. Если на си - то через операции с памятью. Разница в скорости будет огромна.
Если уж сравнивать Си и C++, то нужно сравнить две гипотетические программы где Си использует всё что может, и С++ использует ВСЁ (т.е. со строками раобтать именно через String). Если так сравнивать - си конечно быстрее, до тех пор пока не начинаешь имитировать объекты в плюсах (ну, или когда в си нужно хранить строки с нулевыми байтами) =)
Я даже и не знаю как правильнее это назвать - "программа быстрее", "язык быстрее" или "конструкции языка" быстрее - какая разница? Если вы пишете на плюсах, то, скорее всего, со строками работаете через String. Если на си - то через операции с памятью. Разница в скорости будет огромна.
Если уж сравнивать Си и C++, то нужно сравнить две гипотетические программы где Си использует всё что может, и С++ использует ВСЁ (т.е. со строками раобтать именно через String). Если так сравнивать - си конечно быстрее, до тех пор пока не начинаешь имитировать объекты в плюсах (ну, или когда в си нужно хранить строки с нулевыми байтами) =)
а если я со строками я работаю через строковый класс, который работает, как обертка над stdlib-функциями? :)
да и с каких это пор работа со строками стала в программах узким местом??
очевидно, что если вы работаете с мегабайтами и гигабайтами текста, то не будете использовать сомнительные абстракции вроде std::string, а в остальном это не является узким местом
да и с каких это пор работа со строками стала в программах узким местом??
очевидно, что если вы работаете с мегабайтами и гигабайтами текста, то не будете использовать сомнительные абстракции вроде std::string, а в остальном это не является узким местом
не передёргивайте
на си всегда следишь за тем, когда что-то в память записываешь и стараешься это как можно меньше дергать. Вместо копирования кусков данных - ссылаешься на начало и конец данных в памяти.
На плюсах обычно люди вообще не думают об этом.
Отсюда и складывается общая разница в скорости. И то что очевидно вам, вовсе не значит что очевидно всем. С++ стиль работы со строками это именно std::string.
Да и работа со строками и с данными - это всё таки очень частая задача, разве нет? Я вот частенько писал http-сервера, так там вообще после того как запрос в память попадает - всё время работы над ним (парсинг заголовков и тому подобный хлам) - эти байтики на тех же местах памяти и лежали. Это была версия сервера номер тысяча =). Первые варианты на плюсах были намнооооого медлительнее.
на си всегда следишь за тем, когда что-то в память записываешь и стараешься это как можно меньше дергать. Вместо копирования кусков данных - ссылаешься на начало и конец данных в памяти.
На плюсах обычно люди вообще не думают об этом.
Отсюда и складывается общая разница в скорости. И то что очевидно вам, вовсе не значит что очевидно всем. С++ стиль работы со строками это именно std::string.
Да и работа со строками и с данными - это всё таки очень частая задача, разве нет? Я вот частенько писал http-сервера, так там вообще после того как запрос в память попадает - всё время работы над ним (парсинг заголовков и тому подобный хлам) - эти байтики на тех же местах памяти и лежали. Это была версия сервера номер тысяча =). Первые варианты на плюсах были намнооооого медлительнее.
На плюсах обычно люди вообще не думают об этом.
Человек, который не думает об этом в плюсах, легко попадёт в ситуацию маляра Шлемиэля с zero-terminated строками в Си.
Да, плюсовые абстракции менее прозрачны в плане производительности. Но не надо переносить все проблемы на язык. Допилить C++ до скорости Си можно почти всегда. Использовать в Си абстракции с таким же удобством, как в C++, практически невозможно. К примеру, можно попробовать повторить Blitz++.
я имел ввиду - сознательно не думают, а не "не знают" =).
вы поймите, я же не доказываю того что плюсы дерьмо. Или наоборот =).
если есть голова на плечах, и ты ТОЧНО знаешь размер строки которую нужно записать в память, ты просто не будешь постоянно (только в данном конкретном случае) следить за длиной строки как делает stdlib. Равно как и не будешь искать в памяти нулевого байта как конца строки. Ты уже будешь знать. И в данном случае сможешь сделать совсем крохотное ускорение.
Плюсы почти всегда можно допилить до си. Это да. Как минимум до такого уровня чтобы разница была не существенна. Вот только фактически много вещей будет написана на си при этом =).
вы поймите, я же не доказываю того что плюсы дерьмо. Или наоборот =).
если есть голова на плечах, и ты ТОЧНО знаешь размер строки которую нужно записать в память, ты просто не будешь постоянно (только в данном конкретном случае) следить за длиной строки как делает stdlib. Равно как и не будешь искать в памяти нулевого байта как конца строки. Ты уже будешь знать. И в данном случае сможешь сделать совсем крохотное ускорение.
Плюсы почти всегда можно допилить до си. Это да. Как минимум до такого уровня чтобы разница была не существенна. Вот только фактически много вещей будет написана на си при этом =).
А давайте сразимся ? Си против Эрланга. Скажем, на примене задачи поиска простых чисел методом решета Эратосфена. Простая задачка. И в ней есть место параллелизму. Например, на 4х-ядерном Intel. Принимаете ?
>> Принимаете ?
даже и не собираюсь выяснять что-то на сферических конях в вакууме
и ежу ясно, что код на C получится эффективнее, т.к. с ним вы практически напрямую программируете железо, а с Erlang контролем над железа у вас ноль
даже и не собираюсь выяснять что-то на сферических конях в вакууме
и ежу ясно, что код на C получится эффективнее, т.к. с ним вы практически напрямую программируете железо, а с Erlang контролем над железа у вас ноль
Угу. Инстинкт самосохранения щё имеется. Это правильно. Это вещь осязаемая. Не какая-то там мифическая карма, настёбаная переводом академических чайников не продавших ни строчки собственного кода, но гораздых долго и пространно рассуждать о теоретических достоинствах академических языков. И не понимающих что такое ООП и как оно соотносится с функциональным программированием, которое нарисовалось лет на 10-15 раньше чем Смолток. Да и никак не противостоит этой методологии.
Просто отдельная интересная вещь, логически удобная для некоторого класса задач. Нульдивайс правильно всё пишет. :-)
Просто отдельная интересная вещь, логически удобная для некоторого класса задач. Нульдивайс правильно всё пишет. :-)
>> Нульдивайс правильно всё пишет. :-)
угу, особенно про "С быстрее C++"
>>не продавших ни строчки собственного кода, но гораздых долго и пространно рассуждать о теоретических достоинствах академических языков
just FYI, эти "академические чайники" — разработчики Haskell — работают в Microsoft и делают для вас сегодня C# и VisualBasic
не загоняйтесь
>> Просто отдельная интересная вещь, логически удобная для некоторого класса задач.
.. как и C, и любой другой язык и технология, упомянутые на этой странице хабра
вы только что сказали тавтологию — к чему это?
угу, особенно про "С быстрее C++"
>>не продавших ни строчки собственного кода, но гораздых долго и пространно рассуждать о теоретических достоинствах академических языков
just FYI, эти "академические чайники" — разработчики Haskell — работают в Microsoft и делают для вас сегодня C# и VisualBasic
не загоняйтесь
>> Просто отдельная интересная вещь, логически удобная для некоторого класса задач.
.. как и C, и любой другой язык и технология, упомянутые на этой странице хабра
вы только что сказали тавтологию — к чему это?
1. Да. C заметно быстрее чем C++, если в последнем использовать ООП возможности. Удивительно, что вы этого не понимаете. ООП даёт сильный абстрактный уровень, за который приходится расплачиваться эффективностью. Если его не трогать, то C от C++ не отличается.
2. Вот именно. Делают эффективные языки, с учётом всех физически присутвующих компромиссов. Видимо они не идеалисты.
3. Никакой тавталогии. Класс задач для C++ и С заметно более широк. Не привносите умных слов без необходимости. Тавталогия там какая-то... :-)
2. Вот именно. Делают эффективные языки, с учётом всех физически присутвующих компромиссов. Видимо они не идеалисты.
3. Никакой тавталогии. Класс задач для C++ и С заметно более широк. Не привносите умных слов без необходимости. Тавталогия там какая-то... :-)
>> Да. C заметно быстрее чем C++, если в последнем использовать ООП возможности.
какие такие "ООП возможности"? давайте не будем пространно рассуждать про возможности, а поговорим о конкретных вещах, которые якобы делают C++ медленнее, чем C
ООП возможности — это неявная передача контекста this в функцию? так это ничем не отличается от простой передачи аргумента
это, может быть, виртуальные функции? то же самое делается и в C повсеместно — указателями на функции
а вдруг, это наследование? так нет же — наследование это просто аггрегация реализации
что-то не видать, где это "C заметно быстрее чем C++"
>> Класс задач для C++ и С заметно более широк.
это и не оспаривалось
процитирую вас еще раз: для некоторого класса задач
тавтология
>> Вот именно. Делают эффективные языки, с учётом всех физически присутвующих компромиссов.
опять тавтология
не проще ли прямо сказать: "да, я был неправ, это не неудачники, не продавшие ни одной строчки кода, могущие лишь пространно рассуждать", ы?
>> Не привносите умных слов без необходимости. Тавталогия там какая-то... :-)
если вы не понимаете, что такое тавтология, то незачем демонстрировать всему миру собственную безграмотность
какие такие "ООП возможности"? давайте не будем пространно рассуждать про возможности, а поговорим о конкретных вещах, которые якобы делают C++ медленнее, чем C
ООП возможности — это неявная передача контекста this в функцию? так это ничем не отличается от простой передачи аргумента
это, может быть, виртуальные функции? то же самое делается и в C повсеместно — указателями на функции
а вдруг, это наследование? так нет же — наследование это просто аггрегация реализации
что-то не видать, где это "C заметно быстрее чем C++"
>> Класс задач для C++ и С заметно более широк.
это и не оспаривалось
процитирую вас еще раз: для некоторого класса задач
тавтология
>> Вот именно. Делают эффективные языки, с учётом всех физически присутвующих компромиссов.
опять тавтология
не проще ли прямо сказать: "да, я был неправ, это не неудачники, не продавшие ни одной строчки кода, могущие лишь пространно рассуждать", ы?
>> Не привносите умных слов без необходимости. Тавталогия там какая-то... :-)
если вы не понимаете, что такое тавтология, то незачем демонстрировать всему миру собственную безграмотность
хватит кричать.
напишите программку А в которой используете класс String и libc++. И программку Б в которой сделаете то же самое через прямые операции с памятью.
Кол-во тактов процессора будет отличаться раз в 300. Не 1 или 2, а именно 300.
напишите программку А в которой используете класс String и libc++. И программку Б в которой сделаете то же самое через прямые операции с памятью.
Кол-во тактов процессора будет отличаться раз в 300. Не 1 или 2, а именно 300.
Дайте, пожалуйста, примерный алгоритм работы со строками для бенчмарка, в котором я смогу увидеть отставание C++ от Си на порядок. Скажем, при использовании gcc 4 на linux i386.
Серьёзно, хочу реализовать и увидеть своими глазами.
Серьёзно, хочу реализовать и увидеть своими глазами.
оО
вы что не верите?
ну сделайте что-нибудь, полуполезное. Например возьмите штук 100 строк. Запихните в массив, потом прошвырнытесь по нему, поискав строку с вхождением какого-нибудь слова. Соберите из получившихся одну большую строку. И выплюньте.
а) С++. Всё зашвыриваем в String-и, и поиск и тп хрень - всё через них
б) на Си чуть проблематичнее =). Искать слова - перебором символов из памяти.
Я это делал стопроцентно. Не прямо такую задачку, но String и прочее из stdc++ с сишными алгоритмами сравнивал. Правда сто лет назад.
Если вам не по силам все енто самому написать - могу ближе к вечеру сдуть пыль с Си =). Даже самому интересно стало - хочу четкое количество тактов посмотреть, проводимое в методах String.
вы что не верите?
ну сделайте что-нибудь, полуполезное. Например возьмите штук 100 строк. Запихните в массив, потом прошвырнытесь по нему, поискав строку с вхождением какого-нибудь слова. Соберите из получившихся одну большую строку. И выплюньте.
а) С++. Всё зашвыриваем в String-и, и поиск и тп хрень - всё через них
б) на Си чуть проблематичнее =). Искать слова - перебором символов из памяти.
Я это делал стопроцентно. Не прямо такую задачку, но String и прочее из stdc++ с сишными алгоритмами сравнивал. Правда сто лет назад.
Если вам не по силам все енто самому написать - могу ближе к вечеру сдуть пыль с Си =). Даже самому интересно стало - хочу четкое количество тактов посмотреть, проводимое в методах String.
оО
вы что не верите?
Ни на йоту. И, как мы сейчас увидим, обоснованно. Я отлично себе представляю, что происходит в недрах того и другого решения.
Строки будем читать из файла и, чтобы ввод-вывод особо не влиял на общее время, прокрутим большой цикл с основным алгоритмом.
Входной файл сгенерирован с помощью вот такого скриптика на питоне: http://pastebin.com/m49c69fe
Искать будем строку "abc".
$ ./gen_data.py > data
$ wc data
100000 100000 5163077 data
$ grep abc data | wc
254 254 16998
Исходник на C++: http://pastebin.com/m66629e94
На Си: http://pastebin.com/m6c443a79
В варианте на Си я не стал реализовывать нормальный построчный ввод и вообще не заморачивался сколько-нибудь обработкой ошибок. Для наших целей сойдёт.
string::find использует самый элементарный алгоритм сравнения, strstr в libc тоже (исходник).GCC 4.1.2, Athlon 64 3200+. Результаты воспроизводимы со стандартным отклонением около 0,2 сек.
$ g++ -O3 strings.cpp -o strings_cpp
$ gcc -O3 strings.c -o strings_c
$ time ./strings_c < data > /dev/null
real 0m2.419s
user 0m2.348s
sys 0m0.060s
$ time ./strings_cpp < data > /dev/null
real 0m5.682s
user 0m5.512s
sys 0m0.088s
Разница в 2 раза. А вы нам 300 обещали. А я хотел на порядок, то бишь раз в 10.
Берётесь ускорить хотя бы раз в пять? При условии, что если
strstr меняется на другой алгоритм, например Бойера—Мура, то код на C++ переписывается с ним же.давайте я вечерком гляну.
сейчас же скажу
а) кол-во тактов не пропорционально времени выполнения (а о времени выполнения я ни в одном комментарии и не говорил).
б) прогоните через cachegrind и покажите чего там буит (если есть время конечно, вечером я это и сам сделаю)
в) двухкратное превышение в скорости - это уже затыкает ребят наверху кто о плюсах слишком лестно высказывался (не вы)
д) в пять раз очень вряд ли - но вот ускорить, хороший урок =) Попробую.
сейчас же скажу
а) кол-во тактов не пропорционально времени выполнения (а о времени выполнения я ни в одном комментарии и не говорил).
б) прогоните через cachegrind и покажите чего там буит (если есть время конечно, вечером я это и сам сделаю)
в) двухкратное превышение в скорости - это уже затыкает ребят наверху кто о плюсах слишком лестно высказывался (не вы)
д) в пять раз очень вряд ли - но вот ускорить, хороший урок =) Попробую.
>> двухкратное превышение в скорости - это уже затыкает ребят наверху кто о плюсах слишком лестно высказывался (не вы)
забавно вы меряете "производительность языка" операциями со строками, сравнивая написанный вручную код и код из библиотеки STL, написанный непонятно кем и непонятно как
заворачиваете ваши C функции для работы со строками в примитивный класс, запрещаете неявное копирование — и вуаля, сгенерированый C++ компилятором x86 ничем не будет отличаться от оного в C
давайте будем объективными, и выясним-таки, какие именно "ООП возможности" делают C++ медленнее, чем C — и, главное, почему
забавно вы меряете "производительность языка" операциями со строками, сравнивая написанный вручную код и код из библиотеки STL, написанный непонятно кем и непонятно как
заворачиваете ваши C функции для работы со строками в примитивный класс, запрещаете неявное копирование — и вуаля, сгенерированый C++ компилятором x86 ничем не будет отличаться от оного в C
давайте будем объективными, и выясним-таки, какие именно "ООП возможности" делают C++ медленнее, чем C — и, главное, почему
давайте будем слушать друг друга =). Я про "ООП возможности" и их влияние и не говорил - слишком тяжело это объективно сравнить. А вы меня путаете с кем-то другим.
Я так же и не говорил что на си нужно заворачивать свой функционал куда-то в функции. Как раз экономия 1 вызова функции там где она вызывается миллионы раз и делает своё дело, хоть и писать это приходится тысячу раз.
Я так же и не говорил что на си нужно заворачивать свой функционал куда-то в функции. Как раз экономия 1 вызова функции там где она вызывается миллионы раз и делает своё дело, хоть и писать это приходится тысячу раз.
кол-во тактов не пропорционально времени выполнения (а о времени выполнения я ни в одном комментарии и не говорил).
Не пропорционально, но всё же коррелирует. И потом, нам ведь в конечном счёте интересно именно время выполнения, а уж как мучался процессор, добиваясь его, дело десятое.
cachegrind показывает интересные вещи: http://pastebin.com/m71c8adff — разница в количестве обращений к памяти разительная, правда. Пойду поковыряю ассемблерный листинг. Ещё бы с VTune пройтись...
в) двухкратное превышение в скорости - это уже затыкает ребят наверху кто о плюсах слишком лестно высказывался (не вы)
Однако, в Си мне пришлось написать собственную реализацию динамически расширяющейся строки, с весьма сомнительным удобством использования.
Что будет, скажем, при использовании Intel C++ с STLPort — ещё неизвестно. Что будет, если в обоих вариантах использовать алгоритм БМ — что все равно придётся сделать, если скорость критична — тоже вопрос.
да, вот про эту разницу кешгринда я и говорил. VTune я тоже прогонял, но мельком и сейчас не вспомню что там было толком.
То что в си это всё сложнее писать - это факт, который не оспариваем-с =).
Я правда вообще без всяких обёрток делал. Неудобно - да. Можно легко накосячить случайно и заполучить чудовищно коварный баг - да. Но быстрее.
Моё мнение (в целом не меняющееся) если писать всё на си, иногда запариваясь сильно (там где это ценно), иногда не очень - то в целом программа будет быстрее чем на плюсах. Другое дело что иногда вообще запариваться не хочется в совсем не критичных к скорости выполнения участках - тут бы возможности плюсов были бы очень даже кстати. Вот так и получается что пишем на плюсах, но часто опускаясь в си. Я теперь и вовсе часто поднимаюсь в питон =). Благо, цепляется он к си на раз-два.
То что в си это всё сложнее писать - это факт, который не оспариваем-с =).
Я правда вообще без всяких обёрток делал. Неудобно - да. Можно легко накосячить случайно и заполучить чудовищно коварный баг - да. Но быстрее.
Моё мнение (в целом не меняющееся) если писать всё на си, иногда запариваясь сильно (там где это ценно), иногда не очень - то в целом программа будет быстрее чем на плюсах. Другое дело что иногда вообще запариваться не хочется в совсем не критичных к скорости выполнения участках - тут бы возможности плюсов были бы очень даже кстати. Вот так и получается что пишем на плюсах, но часто опускаясь в си. Я теперь и вовсе часто поднимаюсь в питон =). Благо, цепляется он к си на раз-два.
Так ведь в том-то и дело, что можно «писать на Си внутри C++», прыгая с одного уровня абстракции на другой и, что ещё важнее, оборачивая байтодробительные примитивы в нечто удобное.
C++, не потеряв ни одной из возможностей низкоуровневой оптимизации Си, приобрёл новые (классика: std::sort vs qsort и прочее с шаблонами). О чём спор? :-)
А к C++ с Boost.Python — и вовсе на раз ;-)
C++, не потеряв ни одной из возможностей низкоуровневой оптимизации Си, приобрёл новые (классика: std::sort vs qsort и прочее с шаблонами). О чём спор? :-)
Я теперь и вовсе часто поднимаюсь в питон =). Благо, цепляется он к си на раз-два.
А к C++ с Boost.Python — и вовсе на раз ;-)
да не спор это. Просто разговариваем, я вот с умилением вспоминаю старые добрые времена когда над си с линейками сидел =).
Подытожив, скажу - когда опускаетесь в плюсах в си для оптимизации - вы ведь отдельные штуки уже на "си" пишете, а не на "плюсах"? =) Стало быть в си вы опускаетесь как раз чтобы побыстрее всё сделать =).
Как язык C++ - хорош, разве что в критичных к скорости выполнения местах игнорировать возможности Си - явно не стоит. Вот и всё.
Peace! )
Подытожив, скажу - когда опускаетесь в плюсах в си для оптимизации - вы ведь отдельные штуки уже на "си" пишете, а не на "плюсах"? =) Стало быть в си вы опускаетесь как раз чтобы побыстрее всё сделать =).
Как язык C++ - хорош, разве что в критичных к скорости выполнения местах игнорировать возможности Си - явно не стоит. Вот и всё.
Peace! )
Хм. А может просто написать нормальную strstr? :) И обязательно ли копировать найденные строки? Вроде, можно же просто указатели хранить на найденное.
По условию слить в одну надо было. Иначе всё упирается исключительно в алгоритм поиска подстрок, а хотелось и выделение памяти погонять.
Забавно, что вам карму повышают. Ваш дилентатизм настолько беспробуден, что только полный чайник в языках программирования будет вас плюсовать. Вы ходячее мерило количества дилетантов на Хабре. :-)
Знаете, веселее был бы бенчмарк не на одном 4-хядернике, а на, скажем, 20 таковых в кластере. Или даже не в кластере, а просто в локалке. Ну и, разумеется, крайне интересно было бы бы посмотреть на С-реализацию под это все оптимизированную.
вы ещё скажите, что архитектура машин в кластере будет разной =)
тем не менее - тот же dnetc - вон вам кластер из миллиона машин и работает =). Я правда не уверен что можно раскопать исходники серверной части. Но зато в клиентской там даже асм присутсвует =))
Проблема только в алгоритме. Ну и ещё в том что не каждую задачу можно распараллелить. Например кодирование видео - не так уж просто разбить на кластер, ибо там кодирование каждого блока (обычно 16x16) связано с каждым соседним и ещё и все блоки в каждом кадре связаны между собой (косвенно). Ещё и кадры ссылаются друг на друга на 10-12 в каждую сторону (x264). Попробуйте расспараллелить такое =). 2-3 потока сейчас и то даются огого какой ценой (качество кодирования ХУЖЕ). Даже если взять ролик 60 минут, разбить его на два по 30мин, скдоировать на разных машинках, а потом склеить - качество будет снова хуже =). Особенно если динамика сцен в начале и в конце сильно разная.
Кстати по сабжу. Проблемы все же решать по мере поступления. Думаю если интел слепит 32-ядерник. И если это полезет на десктоп - уж явно будет придумана какая-либо технология для виртуализации всей этой многоядерной мощи на низком уровне. Им ведь вовсе не обязательно инструкции выполнять всегда на одном кристалле - кеш L2 с инструкциями-то общий.
Ибо то же кодирование разбить на 32 потока - это ж ппц. Это ВОЗМОЖНО, если потоки будут как сумасшедшие друг с другом общаться. Но выигрыш в скорости будет крайне сомнителен, имхо. Ситуация будет как с GIL в питоне. Все орут - а если отключить, то все становится в 2 раза медленнее =)
тем не менее - тот же dnetc - вон вам кластер из миллиона машин и работает =). Я правда не уверен что можно раскопать исходники серверной части. Но зато в клиентской там даже асм присутсвует =))
Проблема только в алгоритме. Ну и ещё в том что не каждую задачу можно распараллелить. Например кодирование видео - не так уж просто разбить на кластер, ибо там кодирование каждого блока (обычно 16x16) связано с каждым соседним и ещё и все блоки в каждом кадре связаны между собой (косвенно). Ещё и кадры ссылаются друг на друга на 10-12 в каждую сторону (x264). Попробуйте расспараллелить такое =). 2-3 потока сейчас и то даются огого какой ценой (качество кодирования ХУЖЕ). Даже если взять ролик 60 минут, разбить его на два по 30мин, скдоировать на разных машинках, а потом склеить - качество будет снова хуже =). Особенно если динамика сцен в начале и в конце сильно разная.
Кстати по сабжу. Проблемы все же решать по мере поступления. Думаю если интел слепит 32-ядерник. И если это полезет на десктоп - уж явно будет придумана какая-либо технология для виртуализации всей этой многоядерной мощи на низком уровне. Им ведь вовсе не обязательно инструкции выполнять всегда на одном кристалле - кеш L2 с инструкциями-то общий.
Ибо то же кодирование разбить на 32 потока - это ж ппц. Это ВОЗМОЖНО, если потоки будут как сумасшедшие друг с другом общаться. Но выигрыш в скорости будет крайне сомнителен, имхо. Ситуация будет как с GIL в питоне. Все орут - а если отключить, то все становится в 2 раза медленнее =)
Ну. Intel же не зря затеваем микротрэдинг. Чтобы было без явных коммуникаций и прочего. Это хорошо ложиться на общую память и огромные кэши.
Микротрединг - это когда у вас куча ниток, но они все переключаются аппаратно. При этом нитка может переползать из очереди одного ядра в очередь другог (просто соответсвующая ссылка вставляется в нужную очередь).
В такой парадигме всё превращается в программирование на уровне fork/join, только на уровне очень коротких подзадач (хотя, не обязательно, но можно). Вполне возможно, что на такой архитектуре и кодеки будут нормально работать.
Кстати, а что там насчёт HDTV и Cell? Sony хвалилась, что Cell может много HDTV делать одновременно. И вроде как этот процессор даже не машина с общей памятью.
Микротрединг - это когда у вас куча ниток, но они все переключаются аппаратно. При этом нитка может переползать из очереди одного ядра в очередь другог (просто соответсвующая ссылка вставляется в нужную очередь).
В такой парадигме всё превращается в программирование на уровне fork/join, только на уровне очень коротких подзадач (хотя, не обязательно, но можно). Вполне возможно, что на такой архитектуре и кодеки будут нормально работать.
Кстати, а что там насчёт HDTV и Cell? Sony хвалилась, что Cell может много HDTV делать одновременно. И вроде как этот процессор даже не машина с общей памятью.
говоря x264 я и имел ввиду hdvideo, хотя толком разницы нету. Cell - ну фиг знает, чего о нём болтать если пока достать нереально =). Может и круто, а может и не очень. Дури в нём много, но она вся "тупая".
Да и сонька хвасталась, что cell может _проигрывать_ много hdtv одновременно. Если конечно мне не изменяет память =). Интересно а сколько hd1080p потяент core2quad?
Да и сонька хвасталась, что cell может _проигрывать_ много hdtv одновременно. Если конечно мне не изменяет память =). Интересно а сколько hd1080p потяент core2quad?
Мы, кстати, не учли в рассуждениях то, что работу с hdtv можно поставить на конвейер. Хотя бы примитивно так: процессор обрабатывает половину кадра, передаёт кадр другому процессору, который завершает обработку. А сам начинает обрабатывать следующий кадр. В итоге пропускная способность будет в два раза выше. Старый добрый Генри Форд.
в эту сторону всё и пойдет.
однако это технически не так уж просто осуществить, ибо для того чтобы слепить 1 кадр, нужно иметь информацию мало того что о всём кадре в целом, так ещё и о 8 кадрах вперёд и назад (не говоря уже о общем битрейте всей ленты, но это фигня). Так вот и получается что эти конвееры должны будут между собой перекидывать СТОЛЬ большое количество информации, что становятся неэффективными.
Причём загвоздка не просто в том что кадру нужно знать какие будут следующие и какие были предыдущие - кадр ссылается на информацию в прошлых и следующих. А значит если кодируется кадр номер 15, потом доходим до 20-го, то впринципе может быть необходимость кадр номер 15 после этого изменить =).
Короче кодирование - это жопа ещё та. Легко разбить на потоки примитивное - mpeg2 или divx3, divx4 (mpeg4) уже сложнее, а вот с x264 совсем тухлятина =).
Кстати именно по этой же причине всё это безобразие распоковать - тоже тяжело, чтобы показать всего лишь 1 кадр, нужно его слепить из горы ссылок сзади/спереди. И именно поэтому x264 для проигрывания требует куда больше ресурсов.
однако это технически не так уж просто осуществить, ибо для того чтобы слепить 1 кадр, нужно иметь информацию мало того что о всём кадре в целом, так ещё и о 8 кадрах вперёд и назад (не говоря уже о общем битрейте всей ленты, но это фигня). Так вот и получается что эти конвееры должны будут между собой перекидывать СТОЛЬ большое количество информации, что становятся неэффективными.
Причём загвоздка не просто в том что кадру нужно знать какие будут следующие и какие были предыдущие - кадр ссылается на информацию в прошлых и следующих. А значит если кодируется кадр номер 15, потом доходим до 20-го, то впринципе может быть необходимость кадр номер 15 после этого изменить =).
Короче кодирование - это жопа ещё та. Легко разбить на потоки примитивное - mpeg2 или divx3, divx4 (mpeg4) уже сложнее, а вот с x264 совсем тухлятина =).
Кстати именно по этой же причине всё это безобразие распоковать - тоже тяжело, чтобы показать всего лишь 1 кадр, нужно его слепить из горы ссылок сзади/спереди. И именно поэтому x264 для проигрывания требует куда больше ресурсов.
Параллельные программы спокойно пишутся на Си/Си++. Да, с первого взгляда, не так удобно... но если написать хороший инструментарий: библиотеки, тулы и т.п. становится вполне удобно и не теряем контроль над оптимальностью генерируемого кода.
Насчёт общей памяти и распределённой памяти: не понятно как здесь увязано преимущество erlang над другими языками... Все дело в архитектуре ВС, уровне знаний инженеров и программистов.
На самом деле мультиядерные процессоры, которые сейчас разрабатываются в лабораториях по организации не отличаются от кластерных ВС, потому что по-другому сделать нельзя - проблема тонкого горлышка памяти... Поэтому все наработки ПО для кластеров будут использоваться в новых ВС на базе многоядерных процессоров. Кто разрабатывал системы для кластеров знает какие языки там используются.
Насчёт общей памяти и распределённой памяти: не понятно как здесь увязано преимущество erlang над другими языками... Все дело в архитектуре ВС, уровне знаний инженеров и программистов.
На самом деле мультиядерные процессоры, которые сейчас разрабатываются в лабораториях по организации не отличаются от кластерных ВС, потому что по-другому сделать нельзя - проблема тонкого горлышка памяти... Поэтому все наработки ПО для кластеров будут использоваться в новых ВС на базе многоядерных процессоров. Кто разрабатывал системы для кластеров знает какие языки там используются.
Сообщения рулят, и благодаря их использованию рулит эпловский Objective C
Интересно.
Сначало смутило что "разработанный Ericsson" но оказывается Open-source (http://erlang.org/about.html).
И кстати:
"Среди любителей Erlang-а бытует мнение, что Erlang расшифровывается как ERicsson LANGuage. На самом деле язык назван в честь Агнера Крарупа Эрланга, датского математика, который работал в области телекоммуникаций. Так, единица измерения телекоммуникационного траффика также называется «Erlang»." (http://rsdn.ru/article/erlang/GettingSta…)
Попробовал. Впечатлило с какой скоростью вычислился тот-же факториал от 40000 :) (Просто первое что пришло в голову.)
Интересно написать "оказоустойчивый" веб-сервер. :)
что впрочем уже делается (http://erlang.dmitriid.com/wiki/index.ph… )
Сначало смутило что "разработанный Ericsson" но оказывается Open-source (http://erlang.org/about.html).
И кстати:
"Среди любителей Erlang-а бытует мнение, что Erlang расшифровывается как ERicsson LANGuage. На самом деле язык назван в честь Агнера Крарупа Эрланга, датского математика, который работал в области телекоммуникаций. Так, единица измерения телекоммуникационного траффика также называется «Erlang»." (http://rsdn.ru/article/erlang/GettingSta…)
Попробовал. Впечатлило с какой скоростью вычислился тот-же факториал от 40000 :) (Просто первое что пришло в голову.)
Интересно написать "оказоустойчивый" веб-сервер. :)
что впрочем уже делается (http://erlang.dmitriid.com/wiki/index.ph… )
Впечатлило с какой скоростью вычислился тот-же факториал от 40000 :)
Длинная арифметика в Эрланге ничего особенного из себя не представляет, на уровне Питона, даже помедленнее.
Интересно написать "оказоустойчивый" веб-сервер. :)
что впрочем уже делается
Только вы не туда смотрели. gen_server — это один из паттернов Erlang/OTP для изоляции «чистого» кода от межпроцессного взаимодействия.
А веб-сервер на Эрланге написан, и не один. Самый известный, продвинутый и стабильный — yaws.
> Как программисты решают эти проблемы? Они молятся. На одноядерном процессоре их программы могут «просто работать», но на многоядерном — всё падает.
Вот это изречение - ПОЛНЫЙ БРЕД! ))))))))))))))))))))))))))))))))))))))
Вот это изречение - ПОЛНЫЙ БРЕД! ))))))))))))))))))))))))))))))))))))))
вы демонстрируете собственную некомпетентность
вам знакомы термины race condition, deadlock?
вам знакомы термины race condition, deadlock?
Ну поверь я уж знаю что это такое. А вот многие тут походу и в том числе вы думаете что дедлок это как цунами, приходит внезапно и его никак не избежать. Могу вас заверить что это вовсе не так, читайте многопотоковое программирование и вы без труда избавитесь от блокировок. И так же если вы думаете что программы написанные на ErLang якобы не используют никакую память то это тоже больше заблуждение и Ваша не компетентность.
>> читайте многопотоковое программирование
я не очень понимаю, что вы имели ввиду
>> что дедлок это как цунами, приходит внезапно и его никак не избежать
я очень рад, что вы лично постигли дзен lock-free concurrency
реальность такова, что большое количество многопоточных программ, не тестировавшихся на многопроцессорной конфигурации подвержены ранее не проявлявшимся ошибкам синхронизации
>> И так же если вы думаете что программы написанные на ErLang якобы не используют никакую память
в Erlang я работаю с более высокоуровневыми абстракциями, чем «память»
а что там используется для реализации — мне по барабану, до тех пор, пока гарантируется описанное в документации поведение
я не очень понимаю, что вы имели ввиду
>> что дедлок это как цунами, приходит внезапно и его никак не избежать
я очень рад, что вы лично постигли дзен lock-free concurrency
реальность такова, что большое количество многопоточных программ, не тестировавшихся на многопроцессорной конфигурации подвержены ранее не проявлявшимся ошибкам синхронизации
>> И так же если вы думаете что программы написанные на ErLang якобы не используют никакую память
в Erlang я работаю с более высокоуровневыми абстракциями, чем «память»
а что там используется для реализации — мне по барабану, до тех пор, пока гарантируется описанное в документации поведение
скажите мне пожалуйста, а MS Singularity не на то же самое замахивается?
(отсутствие шаред памяти, обмен сообщениями между тредами?)
(отсутствие шаред памяти, обмен сообщениями между тредами?)
Как только сделают erlang машину которая может распределять процессы по мелким ядрам графических карт (ну там GeForce) то популярность ерланга удвоится!
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
What's all this fuss about Erlang?