@alizar26 мая 2009 в 14:11

Самый быстрый мини веб-сервер

1 мин

Lisp *

+52

Комментарии 93

@Magnifico 26 мая 2009 в 14:20

Спасибо, очень интересно!

@MaoDzeDun 26 мая 2009 в 15:04

ты наверное думал: «А я вот сразу через 9 минут после публикации поста напишу очень информативное сообщение 'Спасибо, очень интересно! ' и меня все дико заплюсуют»???

@Magnifico 26 мая 2009 в 15:23

Вовсе нет. А на что рассчитывал ты?

@MaoDzeDun 26 мая 2009 в 15:36

просто пытался показать, что довольно глупо писать малоинформативные комментарии, но судя по кол-ву минусов на мой коммент понимаю, что неадекват и тупость на хабре множатся
минусуйте!

@Magnifico 26 мая 2009 в 15:46

Для некоторых лучший способ написать что-то осмысленное — это сесть жопой на клавиатуру

@Tagire 26 мая 2009 в 15:52

Какой странной формы у вас задница.

@Magnifico 26 мая 2009 в 15:56

Этот тролль тебе не по зубам, мой мальчик

@Tagire 26 мая 2009 в 15:58

Папа?

@Magnifico 26 мая 2009 в 16:06

Твой папа — тролль? То-то я гляжу, у тебя хорошие задатки.

@oopsididagainster 26 мая 2009 в 17:09

Классная ветка.
Продолжаем.

@akho 26 мая 2009 в 17:12

тред зла

@FanKiLL 26 мая 2009 в 18:02

Cast.Popcorn()

@DMS 26 мая 2009 в 20:27

а нечего было имаджборды закрывать ;)

@akho 27 мая 2009 в 05:59

Я не закрывал!

@NikitaG 27 мая 2009 в 07:27

даешь habra2ch.ru!!!

@cachealot 26 мая 2009 в 14:38

очень хотелось бы увидеть более развернутую информацию

@Sveer 26 мая 2009 в 14:46

Так в посте ссылка на исходники есть да и в презе метод тестирования производительности описан.
Правда метод этот уж больно синтетический, IMHO :)

НЛО прилетело и опубликовало эту надпись здесь

@Sveer 26 мая 2009 в 14:42

Приятно, когда в мире есть долбанутые в хорошем смысле люди :)

@el777 26 мая 2009 в 14:42

Хотелось бы посмотреть на YAWS

@multik 26 мая 2009 в 14:44

а что именно хотелось бы посмотреть?

@el777 26 мая 2009 в 15:01

Сравнение с ним. Потому что если заговорили про высокопроизводительные динамические веб-сервера на функциональных языках, то обязательно надо вспомнить и про yaws и про erlyweb в целом. Т.к. он более чем подходит для сравнения с сервером на lisp.
А вот остальные участники сравнения вызывают некоторые вопросы:
PHP — это язык, а не сервер
Mongrel — написан ОО-языке
Varnish — в большей степени веб-акселератор, чем веб-сервер
Lisp — сравниваем не со «своей лигой».

То есть картинка вызывает очень много вопросов.

НЛО прилетело и опубликовало эту надпись здесь

@ren 27 мая 2009 в 00:35

hunchentoot еще

@ksurent 26 мая 2009 в 14:46

Кстати да, хотелось бы увидеть результаты относительно YAWS. Насколько я знаю, он выдерживает до 80к конкуретных соединений без тормозов.

@ksurent 26 мая 2009 в 14:47

Тем более написан он на Erlang, языке, который чуть более, чем полностью оптимизирован для таких вещей

НЛО прилетело и опубликовало эту надпись здесь

@alekciy 26 мая 2009 в 19:05

А где не бывает побочных эффектов то?

НЛО прилетело и опубликовало эту надпись здесь

@alekciy 27 мая 2009 в 20:10

Имхо, отличный прием.

@lrrr 26 мая 2009 в 14:53

80к показывал довольно мутный бенчмарк — в том смысле, что метод измерений был почти не описан, был только график.

На моем дохлом нотебуке реально получалось до 10К.

Впрочем, это мало что говорит о *скорости обработки*, про которую идет речь в сабже.

@ksurent 26 мая 2009 в 15:10

10k тоже неплохо, особенно учитывая что у вас «дохлый нотебук»)
А если для динамического контента использовать erlang-web или erlydtl, которые хранят шаблоны в скомпилированном виде (и имеют более сносный синтаксис), то думаю скорость обработки окажется тоже на уровне.
Но это, конечно, все мои догадки. Поэтому и написал, что интересно было бы увидеть бенч в сравнении с YAWS.

@alekciy 26 мая 2009 в 19:06

Так и этот бенк не мене мутен. Я бы даже сказал еще мутнее мутного.

@bagyr 27 мая 2009 в 09:12

Сильно зависит то виртуальной машины. HiPE дает прирост производительности примерно в 2.5 раза по сравнению с дефолтным BEAM'ом.

@lrrr 27 мая 2009 в 16:36

На какой задаче? Я сам не мерил, но неоднократно видел отзывы что в некоторых случаях прирост вплоть до отрицательного получается.

@bagyr 28 мая 2009 в 13:09

Если верить товарищам из Упсалы (статью с ходу найти не смог), то практически на всех, в т.ч. и на Yaws. На моем собственном недопроксисервере изменение вида компиляции дало ~-35% по времени обработки одного запроса, хотя количество процессов/соединений не пытался выкрутить на максимум.

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

Потестить бы эту штуку под солярисом, да на спарке, тогда было бы больше пищи для размышлений.

@hooz 26 мая 2009 в 14:57

а вот это действительно интересно!

@Deepwalker 26 мая 2009 в 17:33

Наверное, количество соединений всё-таки зависит от железа?

@ksurent 26 мая 2009 в 18:25

И от него тоже. А я где-то сказал обратное?

@Deepwalker 27 мая 2009 в 17:42

Ну вы назвали некую сферическую цифру в вакууме. Какое железо требуется для 80000 соединений — не ясно.

@grokinn 26 мая 2009 в 14:47

а xml-rpc к нему можно прикрутить?

@coldFlame 26 мая 2009 в 14:48

Интересно, а почему в сравнении Mongrel, а не Passenger

@Somebody32 26 мая 2009 в 15:22

Тут котлеты и мухи: Mongrel — сервер, Passenger — модуль под апач.
Тогда уж правильнее спросить почему нет Апача, но ответ ясен: потому что написан на С.

@coldFlame 26 мая 2009 в 19:08

так и PHP — модуль под апач

@JustLuckyGuy 26 мая 2009 в 19:28

PHP — это язык. Мод апача — mod_php

@coldFlame 26 мая 2009 в 21:05

Не придирайтесь к словам. Модуль Passengera тоже называется mod_passenger

@nerezus 26 мая 2009 в 19:39

Ну так и тест то с явно выраженным синтетическим вкусом ;)

@InneR 26 мая 2009 в 14:49

Странный топик. Непонятно что сравнивается на графике: Mongrel (веб-сервер) с PHP и Lisp — языками программирования (причем они тут?) и с Varnish — веб-акселератором на C.
Кстати, судя по графику, С таки победил, что делает заголовок совсем уж бредовым, простите…

@InneR 26 мая 2009 в 14:51

Кстати, john.freml.in/ — блог автора сабжа, работающий на этом самом Типиди2 грузился у меня несколько минут

@lrrr 26 мая 2009 в 14:56

Он наверное как раз сейчас новые тесты там гоняет :)

@khayrov 26 мая 2009 в 15:21

Зачем тесты, когда слешдот есть :-)

@kurokikaze 26 мая 2009 в 15:44

Если маленький личный блог так выдерживает слэшдоттинг, к веб-серверу таки стоит присмотреться :)

@Tagire 26 мая 2009 в 15:28

Если скачать пдфку то там более подробная информация.
В Php использовался lighttpd и fastcgi, с отключенным логом и без кэширования опкода.
В лиспе использовался его сервер.
Vanish рассматривался в качестве примера статического сервера, не выдающего динамический контент.

@Sveer 26 мая 2009 в 14:51

Да. Еще напугал язык разметки для динамического контента:

( with-site (: page-body-start
( lambda ( title )
( declare ( ignore-title) )
`(<div: class " heade r "
(<h1
(<A: href ( page-l ink "/tlug")
…

Конечно ко всему можно привыкнуть, но я уже вижу как я в этом буду ошибки искать :)

@AndreyTS 26 мая 2009 в 16:42

И там оч самокритичный вывод (в конце PDFa):

== Conclusion ==

This project was a huge waste of time!

Аццкий чел, однако:)

@dmitry_vk 26 мая 2009 в 16:56

Вполне обычный DSL для генерации кода вывода HTML-кода, ничего необычного в нем нет:) Кстати, этот DSL сам умеет при компиляции искать ошибки.

@nikitad 26 мая 2009 в 19:35

Кстати — на тему DSL имею подборку научных работ:

Ward, M. P. Language oriented programming: Tech. rep. / M. P. Ward: Science Labs, 2003.

V. S. Lugovsky. Using a hierarchy of Domain Specific Languages in complex software systems design: Tech. rep. / V. S. Lugovsky: Lawrence Berkeley National Laboratory, 2008.

Spinellis, Diomidis. Notable design patterns for domain-specific languages: Tech. rep. / D. Spinellis: University of the Aegean, 2000

M. Mernik. When and how to develop domain-specific languages: Tech. rep. / M. Mernik, J. Heering, A.M. Sloane: National Research Institute for Mathematics and Computer Science, 2003.

В гугле PDFки ищутся без проблем.

@savant 27 мая 2009 в 08:44

> V. S. Lugovsky
хм, на лоре скормлю, должно быть интересно

@nikitad 27 мая 2009 в 11:37

Кинь линк, понаблюдаю.

НЛО прилетело и опубликовало эту надпись здесь

@Tagire 26 мая 2009 в 15:23

Lisp — мультипарадигменный язык.

@rg_software 26 мая 2009 в 15:55

Как и любой современный язык, впрочем :)

@Tagire 26 мая 2009 в 15:59

Ну просто лисп еще мультипарадигменней чем многие языки. Он не просто позволяет использовать парадигмы которые уже давно известны и новые, он позволяет использовать парадигмы, которые еще даже не изобретены)

@madnut 26 мая 2009 в 16:02

Lisp о***нно современный язык.

@kurokikaze 26 мая 2009 в 18:28

Lisp современен всегда ;)

НЛО прилетело и опубликовало эту надпись здесь

@Tagire 26 мая 2009 в 18:52

Там в том же диспатчере активно юзается ФП.

@dmitry_vk 26 мая 2009 в 19:26

Техники функционального программирования оказываются жутко полезными для массивно-параллельных программ. Например, функциональные структуры данных, позволяющие писать эффективные алгоритмы без блокировок (lock-free) или копирования данных (zero-copy). Так как эти вещи пришли из ФП, то оно тут при чем:)

НЛО прилетело и опубликовало эту надпись здесь

@dmitry_vk 27 мая 2009 в 03:44

Проблему не решает, но дает подсказки относительно того, как решать.

@nikitad 26 мая 2009 в 19:07

Причем, ни к каким парадигмам сам Лисп не принуждает, ему это в плюс — можно иметь профит со всех, какие целесообразно использовать при грамотном применении.
А уж Language oriented programming на нем реально кошерный получается…

@nikitad 26 мая 2009 в 19:13

! Стилистическая ошибка, читать так:
при грамотном применении можно иметь профит со всех, какие целесообразно использовать [в проекте]

@vseloved 26 мая 2009 в 16:02

По большей скорости программ, написанных на ФЯ, чем на С (и почему это возможно), недавно пробегала хорошая статья с длинным и обстоятельным обсуждением: scienceblogs.com/goodmath/2006/11/the_c_is_efficient_language_fa.php
Вкратце ответ: использование арифметики указателей во многих случаях не позволяет компилятору задействовать агресивную оптимизацию, потому что очень трудно определить области кода, в которых какие-то области памяти перестают быть использованы.

А в comp.lang.lisp тоже было хорошее обсуждение на тему реализации генетических алгоритмов на Common Lisp, которая в 26 раз быстрее Java реализации («The Java program turns out to be much slower than the Lisp
program. I was expecting it to be faster. To be precise, SBCL was 26 times faster than Java (SBCL: 16 minutes; Java: 7 hours)»). Вывод там был такой: в других языках для сложных задач часто приходится писать интерпретаторы, в то время как Lisp-среда за счет макросов позволяет работать с скомпилированным кодом для той же проблемы.
groups.google.com/group/comp.lang.lisp/browse_frm/thread/b25de73bbe5eb9ba#

@mx2000 26 мая 2009 в 16:35

Ну так это вполне очевидно — разработчики любой более-менее серьезной системы в какой-то момент сталкиваются с необходимостью реализации DSL, для чего им приходится сначала «изобрести Lisp». Правда иногда вместо Лиспа получается PHP. ;-)

@magicdream 26 мая 2009 в 18:29

Крутые ссылки. Большое спасибо!

@Zibx 26 мая 2009 в 18:33

Суть первой ссылки: «Си хреново параллелится, потому что боится, что при работе в цикле с массивами окажется, что тот которому присваивают и тот который присваивают оказываются в одной области памяти, так как есть страшные указатели. А вот Ocalm не боится». Боже, зачем я это прочитал.

@dmitry_vk 26 мая 2009 в 19:23

Циклы с массивами — это только частный случай. В C или C++ проблему разрешения aliasing'а очень сложно (практически невозможно) решать (aliasing — это эффект, когда изменение чего-то одного затрагивает что-то другое, т.е. есть два имени (alias'а) у одной и той же ячейки памяти). В чистом ФП проблемы алиасинга в принципе не существует (так как значения не меняются), что создают определенные хорошие вещи для компилятора.
Разрешение алиасинга нужно для многих оптимизаций, в том числе для вытаскивания константных выражений за пределы цикла.

@akzhan 27 мая 2009 в 05:35

Если я не ошибаюсь (давно с этим работал), в Intel C++ есть специальное ключевое слово, информирующее компилятор о том, что параметры не являются алиасами.

Если память не изменяет, это ключевое слово restrict из стандарта ANSI C99.

www.cellperformance.com/mike_acton/2006/05/demystifying_the_restrict_keyw.html

НЛО прилетело и опубликовало эту надпись здесь

@nikitad 26 мая 2009 в 19:25

Вообще, понятие «быстрый язык» странное — за все оптимизации отвечает компилятор, которые со временем совершенствуются. Достаточно на тот же SBCL посмотреть — сейчас он по скорости генерируемого кода почти не уступает g++. Коммерческие, по слухам, вовсю конкурируют с чистым Си, причем как по потреблению памяти, так и по скорости объектного кода.

@dmitry_vk 26 мая 2009 в 19:28

Где-то читал, что CMUCL/SBCL чуть ли не самые быстрые из всех лиспов, включая коммерческие (в исследования по компиляторам в CMU было вложено много DARPA'вских денег, поэтому над CMUCL усердно трудились).