А на самом деле?
А на самом деле всё, мягко говоря, не совсем так. Erlang получил поддержку симметричных мультипроцессорных систем в 2006 году, в Haskell ещё только ведутся над нею работы. И в результате картина получается весьма забавной.
source
А именно, на простой типовой задаче (реализация базового http-сервера) Python буквально разрывает Erlang и Haskell в клочья.
C, Erlang, Java and Go Web Server performance test
4 комментария:
За ссылочку два раза спасибо: первый раз -- за сравнение Erlang/Haskell с Python-ом. Второй раз -- за ролик с паровозом-самолетом
Неожиданно.
Но понабегут же (надеюсь не сюда) и будут рассказывать как у Erlang хорошо с GC, с надёжностью, как хорошо с многопоточностью и с многомашинностью, будут приводить высоконагруженные примеры: чат Фейсбука, телекомы.
К слову, пример высоких нагрузок вроде есть и со стороны Python - по давно распространившимся слухам сервер EVE Online написан на Stackless Python.
Я, честно говоря, плохо разбираюсь в теме, но (в духе чисто потрепаться) идейно Erlang (да и Stackless Python) со своими дешёвыми псевдопотококами кажутся ближе к высоконагруженным большим системам. Это совсем не значит, что одни языки-круты, а другие нет. Просто где-то что-то на усилиях программистов можно сэкономить. Ну, а время покажет. Если всех слушать, то, конечно, никогда ничего не напишешь :), так что...
сравнение Erlang/Haskell с Python-ом
А если с тем что выполняется в нативном коде...
Читал где-то Россум при проектировании держал в уме - "конструкции языка должны эффективно выполняться интерпретатором. ... интерпретатор должен быть простой, а просто вот этот синтаксис не получится, значит нафик..."
В отличие от Matz'а который выбирал лучшее из perl'а и Smalltalk, и чтобы ЯП был красив концептуально и высокого уровня.
Но понабегут же (надеюсь не сюда)
Сюда да, не набегут :) Но, думаю новость им сообщат и в блогах появится апологетика в дополнение: тестовый код написан неэффективно, вот если бы вот так ...
Хотя вот ведущие Radio-T питонщики(Umputun только на java). И бывает не только о телефонах и инет-фичах мнением делятся. В одной из передач было - "попробовал я этот CouchDB. Такое ощущение... что все в ней заморожено и отморожено. В каждом месте, начиная с обработки коннектов, и заканчивая работой с диском. Вот MongoDB - няшечка!"
Это совсем не значит, что одни языки-круты, а другие нет.
Это тест не языков. А реализаций. Адепты ФП просто утверждают что реализация движка, компилятора для ФЯ - автоматически приводит к хорошей многопоточности и масштабируемости приложения написанном на ФЯ. И программисту думать об этом никак не нужно.
со своими дешёвыми псевдопотококами кажутся ближе к высоконагруженным большим системам
То что встречалось - вручную на С и С++ лучше получается. Или в JVM. Думается в CLR .NET - тоже с высокой нагрузкой получше будет чем в Erlang.
Другое дело - что время разработки конечного приложения - выше. И хуже с динамической заменой кода. И, вроде бы, на ФЯ код меньше требует отладки.
уточнение от Dema с java@conference.jabber.ru
В графике ... мерялись яблоки с апельсинами :) lightweight thread'ы и epoll
по той же ссылке Don Stewart написал:
On my machine, your Python epoll version achives 10.1 k req/sec, while the Haskell epoll version above achives 15k req/sec.
I get the same results for Haskell epoll and Python epoll with –num-cons=40000,
* Haskell epoll, Request rate: 14683.7 req/s
* Python epoll, Request rate: 10103.3 req/s"
... там python - запускалка epoll.
Отправить комментарий