Комментарии 93
Спасибо, очень интересно!
ты наверное думал: «А я вот сразу через 9 минут после публикации поста напишу очень информативное сообщение 'Спасибо, очень интересно! ' и меня все дико заплюсуют»???
Вовсе нет. А на что рассчитывал ты?
очень хотелось бы увидеть более развернутую информацию
НЛО прилетело и опубликовало эту надпись здесь
Приятно, когда в мире есть долбанутые в хорошем смысле люди :)
Хотелось бы посмотреть на YAWS
а что именно хотелось бы посмотреть?
Сравнение с ним. Потому что если заговорили про высокопроизводительные динамические веб-сервера на функциональных языках, то обязательно надо вспомнить и про yaws и про erlyweb в целом. Т.к. он более чем подходит для сравнения с сервером на lisp.
А вот остальные участники сравнения вызывают некоторые вопросы:
PHP — это язык, а не сервер
Mongrel — написан ОО-языке
Varnish — в большей степени веб-акселератор, чем веб-сервер
Lisp — сравниваем не со «своей лигой».
То есть картинка вызывает очень много вопросов.
А вот остальные участники сравнения вызывают некоторые вопросы:
PHP — это язык, а не сервер
Mongrel — написан ОО-языке
Varnish — в большей степени веб-акселератор, чем веб-сервер
Lisp — сравниваем не со «своей лигой».
То есть картинка вызывает очень много вопросов.
Кстати да, хотелось бы увидеть результаты относительно YAWS. Насколько я знаю, он выдерживает до 80к конкуретных соединений без тормозов.
Тем более написан он на Erlang, языке, который чуть более, чем полностью оптимизирован для таких вещей
> чем полностью оптимизирован для таких вещей
Как оказалось не совсем, все таки сайд-эффекты имеют место быть
Как оказалось не совсем, все таки сайд-эффекты имеют место быть
А где не бывает побочных эффектов то?
В чистых функциональных языках (на то они и чистые). Например Haskell. Там побочнве эффекты приходиться имитировать :). При последовательном программирования практически панацея, но при конкурентном программирования вcе равно есть сложности. А вот насчет Erlang — очень странно что любят рекламировать его функциональные корни, посылка сообщений например к фп мало отношения имеет, хотя это один из основных приёмов там.
80к показывал довольно мутный бенчмарк — в том смысле, что метод измерений был почти не описан, был только график.
На моем дохлом нотебуке реально получалось до 10К.
Впрочем, это мало что говорит о *скорости обработки*, про которую идет речь в сабже.
На моем дохлом нотебуке реально получалось до 10К.
Впрочем, это мало что говорит о *скорости обработки*, про которую идет речь в сабже.
10k тоже неплохо, особенно учитывая что у вас «дохлый нотебук»)
А если для динамического контента использовать erlang-web или erlydtl, которые хранят шаблоны в скомпилированном виде (и имеют более сносный синтаксис), то думаю скорость обработки окажется тоже на уровне.
Но это, конечно, все мои догадки. Поэтому и написал, что интересно было бы увидеть бенч в сравнении с YAWS.
А если для динамического контента использовать erlang-web или erlydtl, которые хранят шаблоны в скомпилированном виде (и имеют более сносный синтаксис), то думаю скорость обработки окажется тоже на уровне.
Но это, конечно, все мои догадки. Поэтому и написал, что интересно было бы увидеть бенч в сравнении с YAWS.
Так и этот бенк не мене мутен. Я бы даже сказал еще мутнее мутного.
Сильно зависит то виртуальной машины. HiPE дает прирост производительности примерно в 2.5 раза по сравнению с дефолтным BEAM'ом.
На какой задаче? Я сам не мерил, но неоднократно видел отзывы что в некоторых случаях прирост вплоть до отрицательного получается.
Если верить товарищам из Упсалы (статью с ходу найти не смог), то практически на всех, в т.ч. и на Yaws. На моем собственном недопроксисервере изменение вида компиляции дало ~-35% по времени обработки одного запроса, хотя количество процессов/соединений не пытался выкрутить на максимум.
Есть вариант, что при большом количестве процессов, ботлнек окажется где-то в ядре системы, а не в виртуальной машине, тогда да, нативный код в лучшем случае не поможет.
Потестить бы эту штуку под солярисом, да на спарке, тогда было бы больше пищи для размышлений.
Есть вариант, что при большом количестве процессов, ботлнек окажется где-то в ядре системы, а не в виртуальной машине, тогда да, нативный код в лучшем случае не поможет.
Потестить бы эту штуку под солярисом, да на спарке, тогда было бы больше пищи для размышлений.
а вот это действительно интересно!
Наверное, количество соединений всё-таки зависит от железа?
а xml-rpc к нему можно прикрутить?
Интересно, а почему в сравнении Mongrel, а не Passenger
Странный топик. Непонятно что сравнивается на графике: Mongrel (веб-сервер) с PHP и Lisp — языками программирования (причем они тут?) и с Varnish — веб-акселератором на C.
Кстати, судя по графику, С таки победил, что делает заголовок совсем уж бредовым, простите…
Кстати, судя по графику, С таки победил, что делает заголовок совсем уж бредовым, простите…
Кстати, john.freml.in/ — блог автора сабжа, работающий на этом самом Типиди2 грузился у меня несколько минут
Если скачать пдфку то там более подробная информация.
В Php использовался lighttpd и fastcgi, с отключенным логом и без кэширования опкода.
В лиспе использовался его сервер.
Vanish рассматривался в качестве примера статического сервера, не выдающего динамический контент.
В Php использовался lighttpd и fastcgi, с отключенным логом и без кэширования опкода.
В лиспе использовался его сервер.
Vanish рассматривался в качестве примера статического сервера, не выдающего динамический контент.
Да. Еще напугал язык разметки для динамического контента:
( with-site (: page-body-start
( lambda ( title )
( declare ( ignore-title) )
`(<div: class " heade r "
(<h1
(<A: href ( page-l ink "/tlug")
…
Конечно ко всему можно привыкнуть, но я уже вижу как я в этом буду ошибки искать :)
( with-site (: page-body-start
( lambda ( title )
( declare ( ignore-title) )
`(<div: class " heade r "
(<h1
(<A: href ( page-l ink "/tlug")
…
Конечно ко всему можно привыкнуть, но я уже вижу как я в этом буду ошибки искать :)
И там оч самокритичный вывод (в конце PDFa):
== Conclusion ==
This project was a huge waste of time!
Аццкий чел, однако:)
== Conclusion ==
This project was a huge waste of time!
Аццкий чел, однако:)
Вполне обычный DSL для генерации кода вывода HTML-кода, ничего необычного в нем нет:) Кстати, этот DSL сам умеет при компиляции искать ошибки.
Кстати — на тему 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ки ищутся без проблем.
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ки ищутся без проблем.
> функциональные языки могут превзойти C
Похоже на троллинг, там Common Lisp, беглый взгляд показал, что там есть присваивания, так что ничего там особо функционального нету. Императивненько.
Похоже на троллинг, там Common Lisp, беглый взгляд показал, что там есть присваивания, так что ничего там особо функционального нету. Императивненько.
Lisp — мультипарадигменный язык.
Как и любой современный язык, впрочем :)
Ну я пишу немного на scheme, так что в курсе что такое лисп. В том коде куча макросов, т.е. это скорее DSL, но причем здесь таки ФП?
Там в том же диспатчере активно юзается ФП.
Техники функционального программирования оказываются жутко полезными для массивно-параллельных программ. Например, функциональные структуры данных, позволяющие писать эффективные алгоритмы без блокировок (lock-free) или копирования данных (zero-copy). Так как эти вещи пришли из ФП, то оно тут при чем:)
Причем, ни к каким парадигмам сам Лисп не принуждает, ему это в плюс — можно иметь профит со всех, какие целесообразно использовать при грамотном применении.
А уж Language oriented programming на нем реально кошерный получается…
А уж Language oriented programming на нем реально кошерный получается…
По большей скорости программ, написанных на ФЯ, чем на С (и почему это возможно), недавно пробегала хорошая статья с длинным и обстоятельным обсуждением: 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#
Вкратце ответ: использование арифметики указателей во многих случаях не позволяет компилятору задействовать агресивную оптимизацию, потому что очень трудно определить области кода, в которых какие-то области памяти перестают быть использованы.
А в 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#
Ну так это вполне очевидно — разработчики любой более-менее серьезной системы в какой-то момент сталкиваются с необходимостью реализации DSL, для чего им приходится сначала «изобрести Lisp». Правда иногда вместо Лиспа получается PHP. ;-)
Крутые ссылки. Большое спасибо!
Суть первой ссылки: «Си хреново параллелится, потому что боится, что при работе в цикле с массивами окажется, что тот которому присваивают и тот который присваивают оказываются в одной области памяти, так как есть страшные указатели. А вот Ocalm не боится». Боже, зачем я это прочитал.
Циклы с массивами — это только частный случай. В C или C++ проблему разрешения aliasing'а очень сложно (практически невозможно) решать (aliasing — это эффект, когда изменение чего-то одного затрагивает что-то другое, т.е. есть два имени (alias'а) у одной и той же ячейки памяти). В чистом ФП проблемы алиасинга в принципе не существует (так как значения не меняются), что создают определенные хорошие вещи для компилятора.
Разрешение алиасинга нужно для многих оптимизаций, в том числе для вытаскивания константных выражений за пределы цикла.
Разрешение алиасинга нужно для многих оптимизаций, в том числе для вытаскивания константных выражений за пределы цикла.
Если я не ошибаюсь (давно с этим работал), в Intel C++ есть специальное ключевое слово, информирующее компилятор о том, что параметры не являются алиасами.
Если память не изменяет, это ключевое слово restrict из стандарта ANSI C99.
www.cellperformance.com/mike_acton/2006/05/demystifying_the_restrict_keyw.html
Если память не изменяет, это ключевое слово restrict из стандарта ANSI C99.
www.cellperformance.com/mike_acton/2006/05/demystifying_the_restrict_keyw.html
НЛО прилетело и опубликовало эту надпись здесь
Вообще, понятие «быстрый язык» странное — за все оптимизации отвечает компилятор, которые со временем совершенствуются. Достаточно на тот же SBCL посмотреть — сейчас он по скорости генерируемого кода почти не уступает g++. Коммерческие, по слухам, вовсю конкурируют с чистым Си, причем как по потреблению памяти, так и по скорости объектного кода.
Обожаю программы на лиспе
> LISP, втором по древности языке программирования высокого уровня.
Под первым имеется ввиду лямбда исчисление?
Под первым имеется ввиду лямбда исчисление?
Будем ждать сервер на турбопоскале
имхо самый «быстрый» мини веб-сервер это:
while true; do nc -l 8080 < index.html; done
:)
while true; do nc -l 8080 < index.html; done
:)
MochiWeb, YAWS, не? Зрелые и реально используемые продукты. К тому же на Erlang со всеми вытекающими.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Самый быстрый мини веб-сервер