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

[avva]

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

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

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

Comments

[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...