корень зла (программистское)

[avva]

Любопытная попытка написать супер-оптимизированный HTTP request/response parser. Намерения самые добрые, но... мне кажется, в этом небольшом модуле я смог бы набрать материала на часовую лекцию о том, когда не надо оптимизировать и как не надо.

Даже проглядев его вскользь, я вижу несколько мест, где на первый взгляд очень эффективный подход на самом деле даст относительно медленный код, который легко можно улучшить; а также заодно и место, где есть потенциальный buffer overflow. Утверждение автора, что его модуль "...is nearly optimal in its use of CPU instructions", конечно, слишком оптимистично. Но главное - почти наверняка выбранная модель общения с клиентом, через колбэки, на практике приведет к большим потерям времени и эффективности, чем столь тщательно сынженированные ручные подгонки под названия HTTP-методов, или отсутствие malloc()-ов.

Меж тем проект, ради которого это затеяно, Node.js (быстрый V8-джаваскрипт на сервере), весьма интересен.

Comments

[meshko.livejournal.com]

Я не понимаю:

1) зачем вообще оптимизировать http parser. Неужели это составляют хоть сколько-нибудь значимую часть нагрузки на веб сервер?
2) зачем JavaScript на сервере?

[nine_k]

(2) чем javascript + JIT хуже Java + JIT в плане производительности? :)

[meshko.livejournal.com]

Очень может быть, что ничем, но вопрос скорее в том, чем JS+JIT (а в V8 JIT?) *лучше* чем Java/Python/PHP/RoR/ASP.NET

[nine_k]

JS 1.5 — язык довольно выразительный, всяко не слабее PHP и сравнимо с питоном (хотя не дотягивая до). Так что все козыри типа "быстрой разработки" и "мультипарадигмальности" у него есть. Java очень многословна и тяжела, asp.net тоже (но ещё и jit у CLR много хуже); "быстренько написать прототип" на них очень трудно, а на JS вполне вообразимо.

[avva.livejournal.com]

1) очень правильный вопрос. essentially не надо. См. заголовок моей записи (отрывок цитаты из Кнута).

2) JS, в общем, хороший и мощный динамический язык, если правильно на него смотреть (см. Крофорд итд.). Под V8 он к тому же еще и очень быстрый, и наверное (говорю это от фонаря - сам не проверял!) вполне может поспорить по скорости, скажем, с Питоном или ПХП. А вместе с event-driven IO, который добавляет этот самый Node.js, он становится сравним с продвинутыми фреймворками на динамических языках, типа Twisted.

Так что писать на нем сайты - возможность как минимум интересная; хотя, конечно, несравнимо более бедные библиотеки, это да. С другой стороны, "все" уже знают Джаваскрипт.

[meshko.livejournal.com]

Мне показалось, что Вам не понравилось как именно он оптимизирует, а не сам факт.
Мне в нашей индустрии очень не нравится то, что нет даже намека на консенсус о том, как нужно делать какие-то простейшие стандартные вещи. Что может быть стандартней, чем написать веб апп? А вот поди ж ты пойми, как это сейчас правильно делать. Есть 10 разных фреймворков на 5 разных языках, все тянут в свою сторону, а воз и ныне там. Каждый год один-два фреймворка исчезают, один-два появляются, и даже нет ощущения, что новые учатся на ошибках старых, скорее просто пробуют что-нибудь новенькое. Сделаем фреймворк на Яваскрипте, потом ещё один на Го, потом ещё че-нибудь придумаем.
"Все" знают Яваскрипт -- не согласен, все знают DOM+JavaScript, это мало поможет в написании серверных приложений.

[avva.livejournal.com]

И то и другое не понравилось ("когда и где"), просто в подробности я вдавался больше по второму пункту. Я ему подробно объяснил, почему это вообще не надо, в личном письме (вежливо :)).

Я скорее соглашусь с вами в пределах одного языка (скажем, на питоне этих фреймворков действительно как собак нерезаных, неприятно), но не между языками.

[stas]

Я так думаю, что "все" знают Джаваскрипт, который нужен, чтобы кнопочки в браузере передвигать. А, скажем, как по-настоящему устроен ОО на Джаваскрипте, знают уже далеко не "все".

[avva.livejournal.com]

Но на то и есть добрый дедушка наш Крофорд.

[meshko.livejournal.com]

Совершенно верно. Мной пару лет назад заткнули дыру в проекте с средних размеров веб приложением. Я там сделал несколько довольно больших кусков на Джаваскрипте. Пару раз казалось, что надо сделать ОО, но я решил, что я лучше все засуну в несколько вложенных списков и назову это функиональным программированием. Так что все обошлось -- проект доделал, Джаваскрипт не выучил.

[http://users.livejournal.com/_winnie/]

V8 в 30 раз медленней C/Java/C++/C#/подставьте сюда статически типизированый язык.
CPython в 1000 раз медленней C/Java/C++/C#/...

Java/С# подразумеваются без ООП. Когда начинается ООП и "коллекции", то невозможность заводить переменные на стеке или как подобъекты делают всё плохо.

Python подразумевается без операций со строками. Когда мы начинаем работать со строками, то всё очень хорошо, так как они уже написаны и оптимизированы на C.

JavaScript мне показался очень неприятным языком - с массивами работать неприятно. Надо или использовать старые сишные for-циклы, или мириться с ограниченным набором методов массивов типа .map. Ещё эти массивы мягко говоря неустойчивы к ошибкам, дефолтный undefined вместо ranger error.

[cmm.livejournal.com]

V8 в 30 раз медленней C/Java/C++/C#/подставьте сюда статически типизированый язык.

цифры в студию или Вы глюпый попугай.

[http://users.livejournal.com/_winnie/]

Тестируется на user-defined классе представляющем двумерную точку/комплексное число, преобразование Фурье. Намеренно выбрано представление в виде класса, а не в виде "сырых" float/double, что бы посмотреть как транслятор справляется с простыми абстракциями.

http://www.everfall.com/paste/id.php?qwqfd6ztdzbv - JavaScript.
http://www.everfall.com/paste/id.php?9picufx8zkno - C++

Оба куска кода должны выводить 17, посчитаное сложным образом.

/cygdrive/c/tmp/del/google_v8/v8-read-only$time ./mytest.exe z.js
17
real    1m2.702s
user    0m0.031s
sys     0m0.000s
/cygdrive/c/tmp/del/google_v8/v8-read-only$time ./x.exe
17
real    0m2.250s
user    0m0.015s
sys     0m0.000s

[cmm.livejournal.com]

(однако, этот коммент не пришёл по почте.  проклинаю СУП, шля всяческие лучи!)

энивей, не вполне понятно что именно Вы в результате проверили: то ли качество оптимизации вычислений с плавающей точкой (gcc там реально жжот, надо отметить, причём, если я правильно понимаю, на уровне peephole optimization — никакие типы к тому этапу трансляции по-любому уже не при делах), то ли качество аллокатора (мусора Ваш жабоскриптовый вариант генерит, вполне очевидно, метрические гигабайты в секунду), то ли скорость диспатча в их какбэ объектно-ориентированной парадигме (которую я вообще слабо понимаю, но которая врядли позволяет реально быструю реализацию как в принципе, хотя конечно фиг знает).

жабоскрипт вообще и v8 в частности я знаю соответственно хреново и никак, так что я перевёл Ваш цеплюсплюс на common lisp и натравил на него sbcl.  после добавления пары оптимизационных деклараций и некоторого жульничества (с целью перестать проводить всю жизнь в GC) получил время работы всего в 3 раза медленнее C++, так что вот.  можно наверное ещё разогнать, хотя судя по тому что показывает дизассемблер особо некуда -- разве что какая-нибудь умная добрая душа наваяет для sbcl пацанский peephole optimizer...

[gianthare.livejournal.com]

Ну, если он получает много malformed requests ...

[msh.livejournal.com]

Так не делают нынче сайтов на PHP, Java или Python. Это PHP + JS, Python + JS, Java + JS. Почему бы не сделать сразу JS + JS, все равно без него никуда

Из смешных приложений JS на сервере я тесно общался с VoiceXML. Там авторы хотели сделать, чтобы все выглядило типа как HTML (простим им, в середине 90-х многие были очарованы), но поскольку никакого броузера там нет, то парсить и исполнять JS приходилось на том же самом сервере

[netch]

> 1) зачем вообще оптимизировать http parser. Неужели это составляют хоть сколько-нибудь значимую часть нагрузки на веб сервер?

Ну вообще-то - да, составляет. Даже простой accept filter в ядре уже показывал десятки процентов прироста производительности для сервера _статики_.

Впрочем, я лично с HTTP в этом плане не работал, работал с SIP, у которого синтаксис сделан в тех же принципах и методах как HTTP, но ещё больше грамматизирован. Так вот - его парсинг представляет собой область, в которой можно достичь как высокой эффективности, так и наоборот - кошмарных тормозов на ровном месте. С тех пор я систематически посылаю лучи диареи народу из IETF.;(

[meshko.livejournal.com]

Поработайте с H.323 и начинайте посылать лучи любви в IETF?

[netch]

Это слишком сложный вопрос, чтобы можно было ответить с ходу. Но в случае SIP есть масса моментов, которые можно было бы решить значительно проще совершенно без ущерба для результата и сохраняя при этом преимущество над H.323 в простоте и понятности. И именно в этих местах больше всего граблей.;(