Когда-то я тоже считал, что в Си что-то скрывается, что позволяет на ней писать более быстрые приложения :) Со временем осознал эту глупость и понял что на Си очень часто получается всё с точностью да наоборот, особенно когда нужен полиморфизм и пытаешься его реализовать на Си, то получается: либо делаешь нормально и это оборачивается в кучу макросов, либо кушаешь больше памяти и указатели на функции всё равно находятся за пределами кэш лайна с нужным объектом, что не даёт прироста производительности.. итд :)
У меня этот образ сверхпроизводительного Си появился под давлением Российского линуксового сообщества и в том стаде ещё много кто остался, кто будет с радостью кричать о том что Си почему-то быстрее ++ :)
>И всё прекрасно понимают, что быстрее чем в N Раз на N потоках не сделать. Так что не нужно там ничего пложить тысячами и миллионами.
Создание процессов не для увеличения производительности, это идеология, где каждый объект в этом параллельном миру должен быть независимым процессом, к которому можно обращаться только с помощью сообщений.
И для создания крупного приложения в любом случае придётся плодить миллионы процессов, иначе его не написать.
Зависит от того как будешь писать на ергланге и на Си, можно и на ерланге писать немасштабируемый софт. Да, изначально на ерланге проще, но это всё относительно и зависит от опыта. Ну кроме поиска ошибок, отладки, и хот-апдейтов которые ерланг предоставляет изкаропки, этого у ерланга не отнять :)
Сколько процессов будет параллельно работать зависит от кол-ва ядер, процессоров, нодов в сети и как вы всё это настроите :)
Да, будут тратить, будут работать медленее до того как начнут массово появляться железяки с большим кол-вом ядер. И тут уже встанет вопрос - а на чём проще разрабатывать приложения под такие мощности, в случае с ерлангом - это уже готовое и проверенное решение с которым легко научиться работать.
не завязаны.
Уже плохо помню как всё там сделано, но насколько мне не изменяет память - то их преемптив переключение между процессами(ерланга) происходит с помощью простого счётчика вызова встроенных функций(не помню как они зовутся). А процесс - это маленькая структурка с входящей очередью сообщений, линками на другие процессы(чтобы оповещать при смерти итп) и ещё всякие мелочи.
Человеку без практического опыта написания сложных распределёных систем, существенно проще писать на ерланге, чем на ++ или Java. Единственная сложность с которой я столкнулся - это когда работаешь со специфичными данными и понимаешь что нецелесообразно их хранить в ets. Хотя не знаю что там сейчас, уже несколько лет не слежу за изменениями.
А сравнение с объектными языками - это как минимум говорит о том, что вы не написали ниодного приложения на языке подобном ерлангу. Может тогда бы вас осенило, что объектность там ни к чему.
Никак не могу уловить связи между аллокаторами и C/C++. Я например использую свои аллокаторы, у которых посложнее апи чем стандартные malloc/free, что позволяет мне играться с обрезанием указателей на 64битных до 32бит/использование hugepages и прочие вкусности, которых нет ни в hoard, ни в ptmalloc.
И что за мифическая "обычно сборка мусора для SMP" :) Как сделаешь - так и будет собираться мусор, способов уйма и никак не связана с языком программирования.
>сильно сомневаюсь что код написанный на ассемблере будет быстрее кода современного компилятора
сомневаетесь, потомучто сами не способны? или это где-то кем-то было доказано?
Поэтому у Сишников есть макросы для сортировки, и других алгоритмов :)
Но Си++ и правда не может быть медленнее.
После первого highload сервера на эрланге, не связанного с телекоммуникацией, желание напрочь отпало :) но скорость разработки... я даже от себя не ожидал, что можно так быстро на эрланге решать задачи.
У меня этот образ сверхпроизводительного Си появился под давлением Российского линуксового сообщества и в том стаде ещё много кто остался, кто будет с радостью кричать о том что Си почему-то быстрее ++ :)
нажми меня
проблема с UI?! см. Wings3d
>но еще из-за вывода на экран
с этим как раз не будет никаких проблем :)
Создание процессов не для увеличения производительности, это идеология, где каждый объект в этом параллельном миру должен быть независимым процессом, к которому можно обращаться только с помощью сообщений.
И для создания крупного приложения в любом случае придётся плодить миллионы процессов, иначе его не написать.
Да, будут тратить, будут работать медленее до того как начнут массово появляться железяки с большим кол-вом ядер. И тут уже встанет вопрос - а на чём проще разрабатывать приложения под такие мощности, в случае с ерлангом - это уже готовое и проверенное решение с которым легко научиться работать.
могут, ets :)
Уже плохо помню как всё там сделано, но насколько мне не изменяет память - то их преемптив переключение между процессами(ерланга) происходит с помощью простого счётчика вызова встроенных функций(не помню как они зовутся). А процесс - это маленькая структурка с входящей очередью сообщений, линками на другие процессы(чтобы оповещать при смерти итп) и ещё всякие мелочи.
А сравнение с объектными языками - это как минимум говорит о том, что вы не написали ниодного приложения на языке подобном ерлангу. Может тогда бы вас осенило, что объектность там ни к чему.
И что за мифическая "обычно сборка мусора для SMP" :) Как сделаешь - так и будет собираться мусор, способов уйма и никак не связана с языком программирования.
не, всё ещё актуально в специфичных узких местах :) как было сказано "используя местами ASM"
>плюс многоядерность
Компилятор распараллеливает ?! :)
>сильно сомневаюсь что код написанный на ассемблере будет быстрее кода современного компилятора
сомневаетесь, потомучто сами не способны? или это где-то кем-то было доказано?
Но Си++ и правда не может быть медленнее.
После первого highload сервера на эрланге, не связанного с телекоммуникацией, желание напрочь отпало :) но скорость разработки... я даже от себя не ожидал, что можно так быстро на эрланге решать задачи.