понедельник, 18 января 2010 г.

Не летит?

... есть понятие - язык программирования Erlang. И оно очень быстро стало символом, означающим масштабные мультипроцессорные системы, а также мощь и всякие выгоды их программирования. Не меньшими темпами загоняется в подобные символы и Haskell - блогеры передразнивают друг друга, слыша красивые слова, в сети поднимается шум.

А на самом деле?

А на самом деле всё, мягко говоря, не совсем так. Erlang получил поддержку симметричных мультипроцессорных систем в 2006 году, в Haskell ещё только ведутся над нею работы. И в результате картина получается весьма забавной.

source

А именно, на простой типовой задаче (реализация базового http-сервера) Python буквально разрывает Erlang и Haskell в клочья.


C, Erlang, Java and Go Web Server performance test

4 комментария:

eao197 комментирует...

За ссылочку два раза спасибо: первый раз -- за сравнение Erlang/Haskell с Python-ом. Второй раз -- за ролик с паровозом-самолетом

Alexander P. комментирует...

Неожиданно.
Но понабегут же (надеюсь не сюда) и будут рассказывать как у Erlang хорошо с GC, с надёжностью, как хорошо с многопоточностью и с многомашинностью, будут приводить высоконагруженные примеры: чат Фейсбука, телекомы.

К слову, пример высоких нагрузок вроде есть и со стороны Python - по давно распространившимся слухам сервер EVE Online написан на Stackless Python.

Я, честно говоря, плохо разбираюсь в теме, но (в духе чисто потрепаться) идейно Erlang (да и Stackless Python) со своими дешёвыми псевдопотококами кажутся ближе к высоконагруженным большим системам. Это совсем не значит, что одни языки-круты, а другие нет. Просто где-то что-то на усилиях программистов можно сэкономить. Ну, а время покажет. Если всех слушать, то, конечно, никогда ничего не напишешь :), так что...

Skynin комментирует...

сравнение Erlang/Haskell с Python-ом
А если с тем что выполняется в нативном коде...

Читал где-то Россум при проектировании держал в уме - "конструкции языка должны эффективно выполняться интерпретатором. ... интерпретатор должен быть простой, а просто вот этот синтаксис не получится, значит нафик..."
В отличие от Matz'а который выбирал лучшее из perl'а и Smalltalk, и чтобы ЯП был красив концептуально и высокого уровня.

Но понабегут же (надеюсь не сюда)
Сюда да, не набегут :) Но, думаю новость им сообщат и в блогах появится апологетика в дополнение: тестовый код написан неэффективно, вот если бы вот так ...

Хотя вот ведущие Radio-T питонщики(Umputun только на java). И бывает не только о телефонах и инет-фичах мнением делятся. В одной из передач было - "попробовал я этот CouchDB. Такое ощущение... что все в ней заморожено и отморожено. В каждом месте, начиная с обработки коннектов, и заканчивая работой с диском. Вот MongoDB - няшечка!"

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

со своими дешёвыми псевдопотококами кажутся ближе к высоконагруженным большим системам
То что встречалось - вручную на С и С++ лучше получается. Или в JVM. Думается в CLR .NET - тоже с высокой нагрузкой получше будет чем в Erlang.
Другое дело - что время разработки конечного приложения - выше. И хуже с динамической заменой кода. И, вроде бы, на ФЯ код меньше требует отладки.

Skynin комментирует...

уточнение от 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.