Comments 93
Спасибо, очень интересно!
ты наверное думал: «А я вот сразу через 9 минут после публикации поста напишу очень информативное сообщение 'Спасибо, очень интересно! ' и меня все дико заплюсуют»???
Вовсе нет. А на что рассчитывал ты?
очень хотелось бы увидеть более развернутую информацию
Приятно, когда в мире есть долбанутые в хорошем смысле люди :)
Хотелось бы посмотреть на YAWS
а что именно хотелось бы посмотреть?
Сравнение с ним. Потому что если заговорили про высокопроизводительные динамические веб-сервера на функциональных языках, то обязательно надо вспомнить и про yaws и про erlyweb в целом. Т.к. он более чем подходит для сравнения с сервером на lisp.
А вот остальные участники сравнения вызывают некоторые вопросы:
PHP — это язык, а не сервер
Mongrel — написан ОО-языке
Varnish — в большей степени веб-акселератор, чем веб-сервер
Lisp — сравниваем не со «своей лигой».
То есть картинка вызывает очень много вопросов.
А вот остальные участники сравнения вызывают некоторые вопросы:
PHP — это язык, а не сервер
Mongrel — написан ОО-языке
Varnish — в большей степени веб-акселератор, чем веб-сервер
Lisp — сравниваем не со «своей лигой».
То есть картинка вызывает очень много вопросов.
Кстати да, хотелось бы увидеть результаты относительно YAWS. Насколько я знаю, он выдерживает до 80к конкуретных соединений без тормозов.
Тем более написан он на 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ки ищутся без проблем.
Lisp — мультипарадигменный язык.
Как и любой современный язык, впрочем :)
Там в том же диспатчере активно юзается ФП.
Техники функционального программирования оказываются жутко полезными для массивно-параллельных программ. Например, функциональные структуры данных, позволяющие писать эффективные алгоритмы без блокировок (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 со всеми вытекающими.
Sign up to leave a comment.
Самый быстрый мини веб-сервер