URL: https://www.opennet.me/cgi-bin/openforum/vsluhboard.cgi
Форум: vsluhforumID3
Нить номер: 102654
[ Назад ]

Исходное сообщение
"asmttpd - http-сервер на ассемблере[BR]"

Отправлено opennews , 20-Май-15 12:10 
В рамках проекта asmttpd (https://github.com/nemasu/asmttpd) развивается реализация http-сервера для Linux, написанная целиком на ассемблере для архитектуры AMD64. Сервер является самодостаточным и не требует наличия внешних библиотек. Исполняемый файл занимает всего 6 Кб. Код распространяется под лицензией GPLv2.

Поддерживается обработка запросов в многопоточном режиме, отдача статических файлов  из указанной директории, обработка кодов возврата (200, 206, 404, 400, 413, 416) и выдача корректного заголовка  "Content-type" для файлов xml, html, xhtml, gif, png, jpeg, css, js. Из запланированных на ближайшее будущее возможностей отмечается формирование индекса содержимого директорий и поддержка заголовка HEAD. Интересно, что несмотря на то, что код написан на ассемблере, проведённые (https://news.ycombinator.com/item?id=9571827) пользователями тесты производительности показывают существенное отставание по скорости обработки запросов от современных http-серверов, написанных на языке Си.


URL: https://news.ycombinator.com/item?id=9571827
Новость: http://www.opennet.me/opennews/art.shtml?num=42267


Содержание

Сообщения в этом обсуждении
"asmttpd - http-сервер на ассемблере"
Отправлено Аноним , 20-Май-15 12:10 
> Интересно, что несмотря на то, что код написан на ассемблере, проведённые
> пользователями тесты производительности показывают существенное отставание
> по скорости обработки запросов от современных http-серверов, написанных
> на языке Си.

Прям чудеса...


"asmttpd - http-сервер на ассемблере"
Отправлено Crazy Alex , 20-Май-15 12:21 
Попытки тривиально реализовать сложные вещи всегда примерно так и кончаются.

"asmttpd - http-сервер на ассемблере"
Отправлено ram_scan , 20-Май-15 15:20 
Он просто синхронный и потоковый. Почти как в книжке "пишем свой хттп сервер за полтора часа для чайников". Единственное что сделано чуть сложнее - он не на каждый коннект тред рожает, а держит пул засуспенженых ниток под это дело.

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


"asmttpd - http-сервер на ассемблере"
Отправлено Crazy Alex , 20-Май-15 15:39 
Ну я примерно об этом и говорил. Только чем больше навернёте сложность реализации - тем более проблемно будет всё это на ассемблере ваять.

"asmttpd - http-сервер на ассемблере"
Отправлено Аноним , 20-Май-15 15:44 
ваять не сложно, поддерживать нереально потом )

"asmttpd - http-сервер на ассемблере"
Отправлено Crazy Alex , 21-Май-15 02:59 
Ваять - тоже не слишком радостно, но поддержка, разумеется, подразумевалась - иначе кому такое чудо вообще нужно, без поддержки? Разве что как курсовик...

"asmttpd - http-сервер на ассемблере"
Отправлено ram_scan , 20-Май-15 15:45 
Да на самом деле будет практически так-же. Даже по обьему кода выйдет стока-же. Просто мыслить в коллбэчной модели асинхронного приложения надо привыкать, а мозги наизнанку выворачивать лениво, проще параллельно и перпендикулярно накодерасить.

Кстати кажет он производительность чуть меньшую чем у апачи который сделан ровно через то же самое место.


"asmttpd - http-сервер на ассемблере"
Отправлено Аноним , 21-Май-15 18:17 
> мозги наизнанку выворачивать лениво, проще параллельно и перпендикулярно накодерасить.

Если ассемблерщик не может в event-driven - это нуб и олух, а не ассемблерщик.

Так, на подумать: а ничего что прерывания и исключения - это всего лишь этакая хардварная реализация callback-ов? И если ассемблерщик это не умеет - это какой-то очень хреновый и мягкотелый ассемблерщик :)


"asmttpd - http-сервер на ассемблере"
Отправлено myc , 22-Май-15 13:52 
Программирование на epoll/kqueue/poll/select + неблокирующий read/write и коллбэчная модель это ортогональные штуки.
Можно из без коллбэков, но с ними удобнее.

"asmttpd - http-сервер на ассемблере"
Отправлено Аноним , 22-Май-15 15:49 
Напомнило творчество одного деятеля, который "для производительности" написал веб-приложение на С ... работающее через CGI. Сильно удивлялся, когда я переписал это дело на богомерзком похапе и получил в 40 раз больше RPS :)

"asmttpd - http-сервер на ассемблере"
Отправлено Анончег , 21-Май-15 01:09 
> Из запланированных на ближайшее будущее возможностей отмечается формирование индекса содержимого директорий и поддержка заголовка HEAD.

Зря они это надумали, бинарник ведь раздует килобайт эдак до воьсми с половиной, и куда они потом с этой махиной.


"asmttpd - http-сервер на ассемблере"
Отправлено cmp , 21-Май-15 05:02 
для amd64 не страшно, если бы под arm делали, а так, пускай))

"asmttpd - http-сервер на ассемблере"
Отправлено iPony , 20-Май-15 12:48 
Логично. Ассемблер же не волшебная палочка. Хорошо написанный код на СИ в общем случае не улучшишь с помощью ассемблера.

"asmttpd - http-сервер на ассемблере"
Отправлено bircoph , 20-Май-15 12:55 
SIMD? Нет, не слашал, да?

"asmttpd - http-сервер на ассемблере"
Отправлено Andrey Mitrofanov , 20-Май-15 13:09 
> SIMD? Нет, не слашал, да?

Да! Оно улучшит веб-сервер. Кардинально.

ps. Не сЛОШал.


"asmttpd - http-сервер на ассемблере"
Отправлено bircoph , 21-Май-15 04:57 
>> SIMD? Нет, не слашал, да?
> Да! Оно улучшит веб-сервер. Кардинально.

Без шуток, улучшит, кардинально. То же копирование памяти.
Просто нужно параллелизировать алгоритмы и данные. Это не всегда просто, чаще всего очень даже сложно, но выполнимо.


"asmttpd - http-сервер на ассемблере"
Отправлено Аноним , 20-Май-15 13:25 
> SIMD? Нет, не слашал, да?

Вы не поверите, но современные компиляторы о нем тоже слышали.


"asmttpd - http-сервер на ассемблере"
Отправлено Mihail Zenkov , 20-Май-15 14:05 
Но на asm'е больше шансов подогнать код так, что бы он уместился в L1-кеш процессора.

"asmttpd - http-сервер на ассемблере"
Отправлено Анонимоус , 20-Май-15 14:37 
Вообще и этим должен заниматься компилятор, если специально поставить такую задачу

"asmttpd - http-сервер на ассемблере"
Отправлено Mihail Zenkov , 20-Май-15 14:40 
Я имею виду разместить весь код приложения, как это делает memtest. На C это мало реально, ввиду раздутости библиотек.

"asmttpd - http-сервер на ассемблере"
Отправлено Аноним , 20-Май-15 20:46 
> C это мало реально, ввиду раздутости библиотек.

Вот те раз, а мужики с -nostdlib то и не в курсе. В смысле, на си можно собрать даже boot loader какой-нибудь, где printf делать еще некуда, файловой системы - нет как класса, и вообще, есть только проц да кучка служебных регистров.

И си это вроде как единственный язык где можно "почти как на асме" но - без выписывания всех ассемблерных команд самолично.


"asmttpd - http-сервер на ассемблере"
Отправлено Mihail Zenkov , 20-Май-15 23:16 
Да можно, я сам пишу на С под AVR. И на C++ можно, но реальность увы гораздо суровее. Посмотрите здесь обсуждение Qt-5.5 - программистов на C++ не волнуют не то что килобайты, но и мегабайты.

"asmttpd - http-сервер на ассемблере"
Отправлено Анончег , 21-Май-15 01:13 
> Да можно, я сам пишу на С под AVR. И на C++
> можно, но реальность увы гораздо суровее. Посмотрите здесь обсуждение Qt-5.5 -
> программистов на C++ не волнуют не то что килобайты, но и
> мегабайты.

Загляни в новость про жабу, там и единиц измерения-то таких не знают, там с гигабайта всё только начинается.


"asmttpd - http-сервер на ассемблере"
Отправлено Canis Dirus Leidy , 21-Май-15 08:18 
>Да можно, я сам пишу на С под AVR. И на C++ можно, но реальность увы гораздо суровее. Посмотрите здесь обсуждение Qt-5.5

Я сам вожу грузы на „Газели“, но реальность увы горзадо суровее. Посмотрите здесь обсуждение „Белаза-75710”…


"asmttpd - http-сервер на ассемблере"
Отправлено Mihail Zenkov , 21-Май-15 12:43 
> Я сам вожу грузы на „Газели“, но реальность увы горзадо суровее. Посмотрите
> здесь обсуждение „Белаза-75710”…

Вот в теме про Qt-5.5 и предлагают использовать Белаз для перевозки одного мешка цемента ...


"asmttpd - http-сервер на ассемблере"
Отправлено Аноним , 21-Май-15 18:28 
> Вот в теме про Qt-5.5 и предлагают использовать Белаз для перевозки одного
> мешка цемента ...

А вы (ну так, глядя на ваши девайсы на тиньках) обычно это делаете так:
- Знаете, парни, все эти ваши газели и тем более белазы - сложные и ненадежные! Вон там сколько всего сломаться может, а запчасти стоят дофига, все дела.
- Что вы предлагаете?
- Ну нам вроде весь мешок прямо сейчас не требуется. Прямо сейчас надо только вон ту дырку заложить. Ведра хватит! Ведро - надежное и дешевое, газели и белазы пролетают!
(проходит полдня корячений с тасканием тяжелого ведра через полгорода)
- Ну вот, все дырка заложена. Задача решена!
- Погодите, но тут еще две дырки?
- А следующую дырку мы как-нибудь потом заложим. Сейчас что-то задолбались.


"asmttpd - http-сервер на ассемблере"
Отправлено Mihail Zenkov , 21-Май-15 21:26 
> А вы (ну так, глядя на ваши девайсы на тиньках) обычно это
> делаете так:

Не понял, к чему ваши аналогии?

Приведенные мной примеры на attiny13 работают не первый год, их работой я доволен. Работают они все на 1.2MHz, сама же attiny13 может работать до 20MHz.


"asmttpd - http-сервер на ассемблере"
Отправлено Аноним , 21-Май-15 09:40 
Ну так Qt любой версии, как бы, не ориентирована на 8-битные AVR совсем. Даже на STM32 без подключения внешней памяти не впихнуть.


"asmttpd - http-сервер на ассемблере"
Отправлено annnnnnnn , 21-Май-15 10:37 
Реальность такова, что плюсовый код на порядок лучше оптимизирует.
Из последнего - это замена memset и memcpy на std::fill и std::copy.
В сишном варианте проверки выравнивания и размеров копирования выполняются в рантайме - в плюсовом - на этапе компиляции.

"asmttpd - http-сервер на ассемблере"
Отправлено Аноним , 21-Май-15 18:32 
> Реальность такова, что плюсовый код на порядок лучше оптимизирует.

Лол. Может вы еще и с ассемблерными листингами и замерами производительности все это покажете, чтобы не быть голословным? :)


"asmttpd - http-сервер на ассемблере"
Отправлено annnnnnnn , 22-Май-15 10:27 
800045a:    bf00          nop
800045c:    4a10          ldr    r2, [pc, #64]    ; (80004a0 <main+0x48>)
800045e:    2116          movs    r1, #22
8000460:    f5a2 5380     sub.w    r3, r2, #4096    ; 0x1000
8000464:    f843 1b04     str.w    r1, [r3], #4
8000468:    4293          cmp    r3, r2
800046a:    d1fb          bne.n    8000464 <main+0xc>
800046c:    bf00          nop

Между nop - это std::fill, например.


"asmttpd - http-сервер на ассемблере"
Отправлено XoRe , 22-Май-15 00:23 
> Реальность такова, что плюсовый код на порядок лучше оптимизирует.

Что, простите?

> Из последнего - это замена memset и memcpy на std::fill и std::copy.

Может у вас и <<, >> быстрее, чем read, write?


"asmttpd - http-сервер на ассемблере"
Отправлено Влад , 21-Май-15 18:40 
Ну и как тебе писать сложный алгоритм на ассемблере и на C под avr?

"asmttpd - http-сервер на ассемблере"
Отправлено Mihail Zenkov , 21-Май-15 21:36 
> Ну и как тебе писать сложный алгоритм на ассемблере и на C
> под avr?

http://www.opennet.me/openforum/vsluhforumID3/102654.html#67



"asmttpd - http-сервер на ассемблере"
Отправлено z , 21-Май-15 14:50 
Он этим занимается аж в 0.1% случаев, о таких вещах как cache pollution-aware вообще молчу

"asmttpd - http-сервер на ассемблере"
Отправлено bircoph , 21-Май-15 04:53 
Сразу видно, что пишет человек с SIMD серьёзно не работавший.

Компиляторы, конечно, SIMD стараются применять, но отстают в успехе в разы, даже и использованием intrinsic функций. Главная проблема в том, что компилятору далеко не всегда возможно определить, где можно векторизовать код без потери в точности или скорости с учётом стоимости переключения контекста процессора между int и float.


"asmttpd - http-сервер на ассемблере"
Отправлено Аноним , 21-Май-15 09:34 
>переключения контекста процессора между int и float

Наверное, я отстал от жизни. Обработка типов int и float уже выполняются в разных процессах?


"asmttpd - http-сервер на ассемблере"
Отправлено bircoph , 21-Май-15 16:26 
> Наверное, я отстал от жизни. Обработка типов int и float уже выполняются в разных процессах?

Не "отстал", а никогда в неё и не входил. С момента появления FPU переключение между контекстом целочисленных операций и операций с плавающей запятой было и является весьма дорогим:
https://en.wikipedia.org/wiki/Context_switch#Performance

Между прочим, это главная причина того, что ядро целиком и полностью целочисленное (если нужны вещественные числа, используется fixed-point арифметика, а она реализована на целых числах), за исключением нескольких особых случаев:
http://yarchive.net/comp/linux/kernel_fp.html


"asmttpd - http-сервер на ассемблере"
Отправлено Аноним , 22-Май-15 13:45 
> Не "отстал", а никогда в неё и не входил. С момента появления FPU переключение между контекстом целочисленных операций и операций с плавающей запятой было и является весьма дорогим

Уважаемый, вы упоролись. Пенальти за переход между целочисленным режимом и FP был во времена MMX, когда для целочисленных значений использовались регистры FPU. С тех пор, как появились SSE/SSE2, про MMX и, собственно, сам FPU все забыли как про страшный сон.

Переключение контекста - это вообще из области многопоточности/многозадачности.


"asmttpd - http-сервер на ассемблере"
Отправлено Mihail Zenkov , 22-Май-15 17:43 
> Уважаемый, вы упоролись. Пенальти за переход между целочисленным режимом и FP был
> во времена MMX, когда для целочисленных значений использовались регистры FPU. С
> тех пор, как появились SSE/SSE2, про MMX и, собственно, сам FPU
> все забыли как про страшный сон.

Не все - gcc по-умолчанию использует сопроцессор для 32 битных систем. Есть у него и хитрый режим sse+387 - что удваивает количество регистров.

> Переключение контекста - это вообще из области многопоточности/многозадачности.

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


"asmttpd - http-сервер на ассемблере"
Отправлено Аноним , 22-Май-15 18:02 
> Не все - gcc по-умолчанию использует сопроцессор для 32 битных систем. Есть у него и хитрый режим sse+387 - что удваивает количество регистров.

Уже нет. Начиная с 4.9 SSE используется по умолчанию и для 32-битных приложений.

https://gcc.gnu.org/gcc-4.9/changes.html

Разве что вы собираете код для CPU без SSE или целенаправленно хотите использовать FPU ради повышенной точности.

> Насколько я понимаю, речь идет о том, что при переключении потока/задачи придется регистры сопроцессор сохранять/восстанавливать.

Вот это действительно имеет место. Но не надо путать теплое с мягким - на этапе исполнения кода никаких "переключений контекста" нет.


"asmttpd - http-сервер на ассемблере"
Отправлено Mihail Zenkov , 22-Май-15 18:27 
> Уже нет. Начиная с 4.9 SSE используется по умолчанию и для 32-битных
> приложений.
> https://gcc.gnu.org/gcc-4.9/changes.html

Не нашел. man gcc (4.9.2) утверждает обратное. Если вы про -ffast-math, то даже я, любитель собрать систему с -O3, использую -ffast-math только при экспериментах, да и то на отдельных пакетах - слишком много от этой опции проблем.


"asmttpd - http-сервер на ассемблере"
Отправлено Нанобот , 20-Май-15 20:03 
>SIMD? Нет, не слашал, да?

вот и разработчики не слышали. или слышали, но у них не хватило наркоты, чтобы придумать, как это можно использовать для обработки http-трафика


"asmttpd - http-сервер на ассемблере"
Отправлено bircoph , 21-Май-15 04:54 
>>SIMD? Нет, не слашал, да?
> вот и разработчики не слышали. или слышали, но у них не хватило
> наркоты, чтобы придумать, как это можно использовать для обработки http-трафика

Зачем наркота? Тот же SSE давно используется в столь далёких от паралельных вычислений вещах, как memcpy, см. код glibc.


"asmttpd - http-сервер на ассемблере"
Отправлено Аноним , 20-Май-15 13:23 
> Хорошо написанный код на СИ в общем случае не улучшишь с помощью ассемблера.

То-то все кодеки, либы шифрования, turbojpeg и прочие - вставки на асме пишут для ускорения.

Потому что как там сгенерит код сишный компилер - бабушка надвое сказала. И когда он вывалит какое-то жуткое месиво в тугом цикле, "потому что кодогенератор так решил" - знаешь, кодек с асмовыми вставками, где этот цикл вылизан покомандно живым человеком - может оказаться в 2-3 раза быстрее. Просто потому что в тугом цикле - в 2 раза меньше команд. Человек то в отличие от компилера может и подраспереться в одной локальной местности, оптимизнув по максимуму. Но писать мег кода на асме - бесполезно :). Можно запросто продуть компилятору в оптимизации использования регистров и проч.


"asmttpd - http-сервер на ассемблере"
Отправлено михаил , 20-Май-15 13:27 
http://www.opennet.me/opennews/art.shtml?num=36551

"asmttpd - http-сервер на ассемблере"
Отправлено михаил , 20-Май-15 13:27 
> http://www.opennet.me/opennews/art.shtml?num=36551

Большая часть ассемблерных вставок малозначительна и не создаёт должного увеличения производительности. Часто разработчики пытаются использовать тривиальный код с надеждой увеличить скорость выполнения тех или иных действий, но при этом общий эффект подавляется другими узкими местами.


"asmttpd - http-сервер на ассемблере"
Отправлено Аноним , 20-Май-15 20:43 
>  Большая часть ассемблерных вставок малозначительна

Это тот случай когда "мал золотник, да дорог". Нет смысла ускорять код в который ничего особо и не упиралось, поэтому переписать всю ОС или программу на асм как колибри или менуэт - довольно глупо.

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

> и не создаёт должного увеличения производительности.

А я вот мерял как-то чисто сишные версии vs C+asm вставки в случае кодека - разница была очень даже. И я бы не хотел пользоваться чисто сишной версией кодека при доступности asm-optimized, разница может быть в пару раз запросто. А это меньше шума от вентиля на мощном проце, а на слабом - больше разрешение которое прожуется без выпадения кадров.

> другими узкими местами.

Вот в кодеках например асмовые вставки сделаны в самых горячих местах. Что и ускоряет все буквально в разы. Ну разумеется всякий glue code вызываемый сильно иногда - никто в здравом уме на асме писать не будет, потому что эффекта около ноля, а возни много.


"asmttpd - http-сервер на ассемблере"
Отправлено Andrey Mitrofanov , 20-Май-15 13:49 
> То-то все кодеки, либы шифрования, turbojpeg и прочие - вставки на асме
> пишут для ускорения.

Как видим, весь код на асме пишут для замедления.


"asmttpd - http-сервер на ассемблере"
Отправлено ram_scan , 20-Май-15 15:24 
> Как видим, весь код на асме пишут для замедления.

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

Если его на сях переписать будет еще тупее по производительности.



"asmttpd - http-сервер на ассемблере"
Отправлено Andrey Mitrofanov , 20-Май-15 20:50 
>> Как видим, весь код на асме пишут для замедления.
>что они - тормозная блоатварь.

Про блоат это ты принёс. Беспокоит размер? Сравнивал 10DVD любой из 10 архитектур Debian-а со своими ассемберными пипирками и аж задохнулся?? Твои страдания >>>-все-видят->

> Сотни батхерта обеспечены :)


"asmttpd - http-сервер на ассемблере"
Отправлено Аноним , 20-Май-15 21:02 
> Про блоат это ты принёс.

Я всего лишь придумал как оптимизировать наброс. Троллить ассемблерщиков неоптимальными набросами - не пройдет. Они во всем оптимизацию любят.


"asmttpd - http-сервер на ассемблере"
Отправлено iPony , 20-Май-15 14:39 
Да, так я и написал "в общем случае".

"asmttpd - http-сервер на ассемблере"
Отправлено Омномним , 20-Май-15 18:31 
Кодеки, шифрование, обработка изображений - это "числодробилки". Ассемблерные вставки там - это чёрные ящики, получающие буфер с данными на входе и выдающие буфер на выходе, это функции-аутисты, проделывающие большой объем вычислений, никак не общаясь с окружением.
А что такое http-сервер? Это жонглирование буферами памяти между вызовами API-шных функций работы с сетью и диском. Ну, парсер строк заголовков еще можно написать на асме, если уж руки чешутся. Но весь червер на асме это чистое рукоблудие.

"asmttpd - http-сервер на ассемблере"
Отправлено Аноним , 20-Май-15 20:48 
Ух ты, я вызвал приступы капитанинга. Любо-дорого смотреть, Капитаны на опеннете сегодня качественные :)

"asmttpd - http-сервер на ассемблере"
Отправлено bircoph , 21-Май-15 04:59 
>[оверквотинг удален]
> пишут для ускорения.
> Потому что как там сгенерит код сишный компилер - бабушка надвое сказала.
> И когда он вывалит какое-то жуткое месиво в тугом цикле, "потому
> что кодогенератор так решил" - знаешь, кодек с асмовыми вставками, где
> этот цикл вылизан покомандно живым человеком - может оказаться в 2-3
> раза быстрее. Просто потому что в тугом цикле - в 2
> раза меньше команд. Человек то в отличие от компилера может и
> подраспереться в одной локальной местности, оптимизнув по максимуму. Но писать мег
> кода на асме - бесполезно :). Можно запросто продуть компилятору в
> оптимизации использования регистров и проч.

С использованием векторных инструкций не в 2-3 раза, а в 20-30 раз (для конкретного цикла или небольшого куска кода), что в целом даёт 2-5 раз уже для всей программы.


"asmttpd - http-сервер на ассемблере"
Отправлено Kroz , 20-Май-15 13:36 
> Прям чудеса

Ожидаемо. Просто алгоритмы оптимизации кода в компиляторах достаточно развиты. Одна моя подделка с -O2 работала раза в 4 быстрее по сравнению с -O0.

Относительно проекта впечатления противоречивые, но склоняюсь к позитиву. С одной стороны "Зачем?", а с другой - может наконец-то девелоперы начнут ртбращать внимание а ресурсы, которые потребляет их программы, а то софт с учётом апгрейда железа тормозит точно также, как и 15лет назад.


"asmttpd - http-сервер на ассемблере"
Отправлено Crazy Alex , 20-Май-15 13:47 
Да при чём здесь оптимизации. Просто на ассемблере несколько задолбаешься делать сложную высокоуровневую логику, нужную для эффективной реализации чего-то большого. Если ты не Кнут, конечно. А то, что высокоуровневые оптимизации дают на порядки больший эффект, чем вылизывание инструкций - не секрет ни разу.

Лишнее подтверждение этому - объём бинарника. 6к - даже для ассемблера не ахти что, тем более на x86_64. То есть там наверняка всё внутри реализовано самым тривиальным образом.


"asmttpd - http-сервер на ассемблере"
Отправлено BratSinot , 20-Май-15 16:13 
> Лишнее подтверждение этому - объём бинарника. 6к - даже для ассемблера не ахти что

Это как-бы мало, у остальных они за собой еще libc / stdc++ потянут, а тут только ядро нужно.


"asmttpd - http-сервер на ассемблере"
Отправлено Crazy Alex , 20-Май-15 16:48 
Это не просто мало - это катастрофически мало для того, чтобы реализовать приличные структуры данных и алгоритмику

"asmttpd - http-сервер на ассемблере"
Отправлено rshadow , 20-Май-15 17:46 
> а то софт с учётом апгрейда железа тормозит точно также, как и 15лет назад

Это все сказки. Вы просто не замечаете возросших потребностей. Один графический тулкит с тенями, анимациями нажатий и т.д. чего стоит.
Что 15 лет назад по большей части никто не оптимизировал, что сейчас. Ситуация одинаковая.


"asmttpd - http-сервер на ассемблере"
Отправлено Аноним , 20-Май-15 13:57 
Никто не уловил сарказм?

"asmttpd - http-сервер на ассемблере"
Отправлено Аноним , 20-Май-15 15:16 
чудеса будут, если он проживет столько, сколько апач например и все равно будет сливать по скорости. в данный момент сравнение некорректно

"asmttpd - http-сервер на ассемблере"
Отправлено Legacy , 20-Май-15 12:11 
Сейчас начнется очередной виток срача, в последнее время популярного на опеннете: "на чем писать сервер". В тред приглашаются специалисты младшего школьного отделения.

"asmttpd - http-сервер на ассемблере"
Отправлено Аноним , 20-Май-15 12:42 
На go, очевидно же. Модно-молодёжно, ибо ваистену! :-)

"asmttpd - http-сервер на ассемблере"
Отправлено Аноним , 20-Май-15 13:58 
На пИтОнЕ.

"asmttpd - http-сервер на ассемблере"
Отправлено jOKer , 20-Май-15 14:31 
CherryPy? Не, не слышал!
Tornado? Не, тоже не знаю!
Twisted? Не, тоже как-то не случилось обратить внимание...

Ну может хоть uWSGI или, прикола ради, Waitress WSGI Server? Что тоже нет?! В школу!!! Немедленно!


"asmttpd - http-сервер на ассемблере"
Отправлено Andrey Mitrofanov , 20-Май-15 15:05 
> CherryPy?
> Tornado?
> Twisted?

И все их ставят за nginx-ом, написанном на... ?

>В школу!!! Немедленно!


"asmttpd - http-сервер на ассемблере"
Отправлено jOKer , 20-Май-15 16:12 
Вопрос спорный. Разгребать статику можно конечно и nginx. Я кстати, именно его и использую в связке с gunicorn. Хотя тот же Торнадо и сам неплохо с этим справляется http://www.tornadoweb.org/en/branch2.1/overview.html#static-... и вовсе не требует каких-то там фронт-эндов "написанных на... ?"

PS Эх... школа... я, кстати, с удовольствием туда бы вернулся на годик-два. Золотое было время!


"asmttpd - http-сервер на ассемблере"
Отправлено Аноним , 20-Май-15 17:26 
> Хотя тот же Торнадо и сам неплохо с этим справляется

И как он на 50000-100000 коннектов?


"asmttpd - http-сервер на ассемблере"
Отправлено jOKer , 20-Май-15 17:50 
Фиг знает. Я же писал постом выше, что использую как раз nginx+gunicorn.
Но люди отзываются о торнадо под нагрузкой не плохо. Хотя куда лучше отзывы о твистид. Вот, кста, интересное обсуждение, если интересуетесь http://profyclub.ru/docs/124

"asmttpd - http-сервер на ассемблере"
Отправлено Legacy , 20-Май-15 17:46 
>> И все их ставят за nginx-ом

Балансер/раздатчик статики - еще не веб-сервер. Но в школах этого не читают, увы.


"asmttpd - http-сервер на ассемблере"
Отправлено Crazy Alex , 21-Май-15 03:10 
Но то, что он балансирует, и подавно не обязано быть веб-сервером - к примеру, это может быть какой-нибудь WSGI-бакэнд, или масса всего прочего, что реализовано для того же нгинкса, вплоть до прямой работы с базами данных. Можно, разумеется, спорить о терминах, но, как мне кажется, логичнее будет всё же сойтись на том, что приложение, отдающее свой контент, в том числе статический  (в противовес проксированию чужого) по HTTP-протоколу, веб-сервером всё же является.

"asmttpd - http-сервер на ассемблере"
Отправлено jOKer , 21-Май-15 04:44 
>WSGI-бакэнд

ИМХО, в данном случае, WSGI-бакэнд как раз и есть веб-сервер, поскольку имено он генерирует динамический контент, создает html-страницы. А вот балансировщик, даром что именно он возвращает их, веб-сервером можно назвать с большой натяжкой. Уж скорее кэширующим прокси-сервером. Да собственно, nginx, именно так (в том числе) себя и позиционирует. Официально: "обратный прокси-сервер". Конечно, он еще и полноценный веб-сервер, но для питоновых веб-приложений, его полноценность, в плане веб-сервера, глубоко до лампочки, - ибо не востребована.


"asmttpd - http-сервер на ассемблере"
Отправлено Аноним , 21-Май-15 08:46 
WSGI — это явный сервер приложений.
Веб-сервер — это то, что разговаривает по HTTP.
Nginx - веб-сервер.
Апач - веб-сервер со встроенными (в виде, например, PHP module) серверами приложений.

"asmttpd - http-сервер на ассемблере"
Отправлено Legacy , 21-Май-15 13:32 
Nginx - проксифронтенд. Все что за ним стоит - бэкенд. Не надо придумывать ненужные сущности.

"asmttpd - http-сервер на ассемблере"
Отправлено angra , 22-Май-15 14:52 
Понятие frontend/backend ортогонально к понятию web/http server.
Если nginx общается с бекендом по fcgi или uwsgi, то бекенд уже не может претендовать на звание вебсервера.

"asmttpd - http-сервер на ассемблере"
Отправлено Legacy , 22-Май-15 16:45 
А если проксирует/балансирует запросы, например, к nodejs?

"asmttpd - http-сервер на ассемблере"
Отправлено Аноним , 20-Май-15 12:12 
Мал и самодостаточен - удобен для руткитов с ботнетами.

"asmttpd - http-сервер на ассемблере"
Отправлено YetAnotherOnanym , 20-Май-15 12:12 
Хмм... А если бы не из директории, а из памяти, как бы тогда он был рядом с серверами на C?

"asmttpd - http-сервер на ассемблере"
Отправлено Аноним , 20-Май-15 12:17 
на сях сверхмудрый оптимизатор хорошо оптимизирует код, тогда как тут вся оптимизация лежит на программистах.

"asmttpd - http-сервер на ассемблере"
Отправлено Аноним , 20-Май-15 12:18 
а какая разница из чего делать системый вызов?

"asmttpd - http-сервер на ассемблере"
Отправлено Аноним , 20-Май-15 12:20 
разница большая: системный вызов, например, из дерева работать скорее всего не будет.

"asmttpd - http-сервер на ассемблере"
Отправлено Аноним , 20-Май-15 20:52 
> разница большая: системный вызов, например, из дерева работать скорее всего не будет.

Можно запилить RPC-интерфейс. Тогда будет!


"asmttpd - http-сервер на ассемблере"
Отправлено YetAnotherOnanym , 20-Май-15 12:25 
> а какая разница из чего делать системый вызов?

Ну, может быть там работа с ФС рудиментарная, и причина тормозов в этом. А из памяти - тупо взял и выстрелил, и всё.


"asmttpd - http-сервер на ассемблере"
Отправлено braveduck , 20-Май-15 12:22 
про файловые кеш на уровне ОС не слышали?
оно и так раздается из памяти, скорей всего, после первых запросов.

"asmttpd - http-сервер на ассемблере"
Отправлено YetAnotherOnanym , 20-Май-15 14:05 
Умничка. Слышал про файловый кэш на уровне ОС. А теперь следи за руками. Сервер парсит URL и маппит его в путь к файлу. После этого он просит его у ОС как файл. Должен быть готов обработать любой ответ. Нет - отдать 404, давно лежит - отдать 304, и т.д. ОС смотрит, не в кэше ли этот файл, если в кэше - отдаёт его (а это, между прочим, передача данных от ядра к пользовательскому процессу).
Если же объекты лежат в памяти самого процеса, от маппит URL в адрес, находит в своих данных его размер, время изменения и т.д., и если надо отдать - отдаёт из своей памяти.

"asmttpd - http-сервер на ассемблере"
Отправлено Andrey Mitrofanov , 20-Май-15 14:27 
> Если же объекты лежат в памяти самого процеса, от маппит URL в
> адрес, находит в своих данных его размер, время изменения и т.д.,

Вот оно!! Надо "объекты" тож на асме писать! </это же всё решает!></и проблему php тоже>

> и если надо отдать - отдаёт из своей памяти.


"asmttpd - http-сервер на ассемблере"
Отправлено YetAnotherOnanym , 21-Май-15 20:10 
Хе, какой-то уязвлённый школьник минусов накидал, а возразить по делу (sendfile(2), например) эрудиции не хватило.

"asmttpd - http-сервер на ассемблере"
Отправлено Аноним , 20-Май-15 12:13 
Почему не GPL3?

"asmttpd - http-сервер на ассемблере"
Отправлено Аноним , 20-Май-15 12:23 
потому что GPLv2
=D

"asmttpd - http-сервер на ассемблере"
Отправлено Аноним , 20-Май-15 12:42 
Ну уж хотя бы не БЗДы

"asmttpd - http-сервер на ассемблере"
Отправлено Нанобот , 20-Май-15 20:08 
> Почему не GPL3?

гладиолус


"asmttpd - http-сервер на ассемблере"
Отправлено Аноннн , 20-Май-15 12:32 
На ассемблере и медленно!? Кощунство!!!

"asmttpd - http-сервер на ассемблере"
Отправлено _KUL , 20-Май-15 13:06 
Может быть, потому что не только от языка и его уровня зависит, но и от кривости извилин программиста?

"asmttpd - http-сервер на ассемблере"
Отправлено Andrey Mitrofanov , 20-Май-15 13:19 
> Может быть, потому что не только от языка и его уровня зависит,
> но и от кривости извилин программиста?

Именно поэтому. Эти их такты на гигагерцах не имеют никакого значения при миллисекундных порядках раундтрипов/коннектов. И даже при микросекундных на эзернетах.

Впрочем, мы, конечно, сочувствуем столь сложному и трудному способу получения удовольствия. За отсутствием другого результата.

//Прошлый, раз у выноси^H^H^H^Hрезателей драйвера сетевой и стека tcp в веб-сервер, было хоть удовольствие от B)перформанса.


"asmttpd - http-сервер на ассемблере"
Отправлено Mihail Zenkov , 20-Май-15 13:39 
> Именно поэтому. Эти их такты на гигагерцах не имеют никакого значения при миллисекундных порядках раундтрипов/коннектов. И даже при микросекундных на эзернетах.

Энергоэффективность? Представьте маломощный arm, полностью автономный - работающий от солнечных батарей, не требующих затрат на теплоотведение из серверной.


"asmttpd - http-сервер на ассемблере"
Отправлено Crazy Alex , 20-Май-15 13:48 
Оно бы да, но писано-то под x86_64

"asmttpd - http-сервер на ассемблере"
Отправлено Mihail Zenkov , 20-Май-15 13:53 
> Оно бы да, но писано-то под x86_64

Это я в теории, про светлое будущее :)

На x86_64 потребление питания и тепловыделение тоже весьма зависит от нагрузки. Вдобавок появляться возможность сделать underclocking+undervolting и существенно улучшить энергоэффективность.  


"asmttpd - http-сервер на ассемблере"
Отправлено Crazy Alex , 20-Май-15 15:50 
Ну, я никогда не был сторонником особой оптимизации по энергоэффективности на стационарных машинах или делания чего-то тяжелого на мобильных устройствах - от смартфона до ноутбука. Первое и последнее, что вспоминается в плане реальной нужды увеличивать энергоэффективность на стационарах - майнинг. Да и не думаю я, что сколь угодно крутой веб-сервер, писанный на асемблере, даст такие уж сильные отличия по энергопотребению целой машины в сравнении с сишным сервером. И даже если даст - наверняка практически то же будет достижимо парой ассемблерных вставок в сишный код. А вот писать эффективную высокоуровневую логику на ассемблере - занятие довольно-таки дурное, вот на ней ассемблерный сервер и просядет.

"asmttpd - http-сервер на ассемблере"
Отправлено Mihail Zenkov , 20-Май-15 16:41 
Я придерживаюсь такого же мнения - C код + ассемблерные вставки в особо критичных местах не будет существенно проигрывать чистому ассемблеру. А если учесть сложность поддержки и развития ассемблерного кода и практически нулевую переносимость ...

Другое дело что, люди выбирающие ассемблер стремятся к максимальной эффективности (cpu/ram) ПО, а не к скорости разработки, как это часто происходит при выборе более высокоуровненных языков.


"asmttpd - http-сервер на ассемблере"
Отправлено клоун , 20-Май-15 17:24 
Разница в одинаково написанном коде не превышает 5%.

Другое дело, что каждый язык приучает к своему стилю.

Напр. базовое: есть массив структура {артикул - сумма}, нужно быстро находить сумму по артикулу и рассчитывать общую сумму. В Си это делается созданием структуру и циклу по ней, но это неоптимально, т.к. в кэш попадают ненужные данные. Гораздо быстрее хранить два массива отдельно. Это ненаглядно и не Си-стайл, зато эффективно.


"asmttpd - http-сервер на ассемблере"
Отправлено Аноним , 21-Май-15 18:36 
> и не Си-стайл, зато эффективно.

А какой у си стайл? На нем все пишут по разному, от этакого "почти ассемблера" до "фигасе, они сделали ООП на си!"


"asmttpd - http-сервер на ассемблере"
Отправлено Аноним , 20-Май-15 12:40 
На AMD64 написанный и на плюсах будет нехило работать, и даже на питоне. И проблема экономии памяти до единиц Кб там, как бы, не актуальна.
Такое для архитектуры Cortex-M3 больше пригодилось бы.

"asmttpd - http-сервер на ассемблере"
Отправлено Anonymous528 , 20-Май-15 12:56 
>Такое для архитектуры Cortex-M3 больше пригодилось бы.

Ну вообще да, на всяких малых и особо малых устройства он само то.
Вангую что ребята из Калибри захотят его себе портировать.


"asmttpd - http-сервер на ассемблере"
Отправлено Аноним , 20-Май-15 13:25 
> На AMD64 написанный и на плюсах будет нехило работать, и даже на питоне.

Ога, пока рядом не запустят нжинкс и не проведут бенчмарк :)


"asmttpd - http-сервер на ассемблере"
Отправлено Legacy , 20-Май-15 17:53 
И что произойдет? Одна из первых ссылок в гуге по запросу "nginx performance comparison" (правда, против node.js) - http://centminmod.com/siegebenchmarks/2013/020313/

"Quite interesting to see how well node.js clustered static file server scaled almost 2x times better in terms of transactions per second compared to Nginx web server (4,250 trans/s vs 2,118 trans/s) - especially at the higher concurrency levels. Also check out average response times (0.14s vs 0.23s), longest transaction time (1.10s vs 13.95s) and transaction availability numbers all in node.js's favour."

Надо пойти поискать посвежее сравнения.


"asmttpd - http-сервер на ассемблере"
Отправлено Аноним , 20-Май-15 18:59 
Это не бенчмарк, а хрень собачья.

"asmttpd - http-сервер на ассемблере"
Отправлено Нанобот , 20-Май-15 20:12 
> Это не бенчмарк, а хрень собачья.

Свидетели Пресвятого Nginx'а обвиняют собеседника в ереси


"asmttpd - http-сервер на ассемблере"
Отправлено Аноним , 20-Май-15 20:55 
> Свидетели Пресвятого Nginx'а обвиняют собеседника в ереси

В неумении делать бенчи или того хуже запредельном уровне подтасовок. Засилье нжинкса в top busiest sites как бы намекает. А если бы все было как там написано, без подвохов - те ...цать процентов рынка давно были бы у node.js :P


"asmttpd - http-сервер на ассемблере"
Отправлено Legacy , 20-Май-15 22:30 
>> Засилье нжинкса в top busiest sites как бы намекает

что он отличный балансер, но бакенд за ним все равно на других языках. Что тоже как бы намекает.


"asmttpd - http-сервер на ассемблере"
Отправлено Аноним , 21-Май-15 18:38 
> что он отличный балансер, но бакенд за ним все равно на других
> языках. Что тоже как бы намекает.

Капитан Очевидность намекает что по минимуму веб сервер может вообще не уметь динамику, но веб-сервером он от этого быть не перестанет :). Он перестанет быть сервером приложений, но это уже несколько другое.


"asmttpd - http-сервер на ассемблере"
Отправлено Аноним , 20-Май-15 14:25 
Хотя, может и Minuet'чикам тоже понравится.

"asmttpd - http-сервер на ассемблере"
Отправлено Аноним , 20-Май-15 15:54 
> Хотя, может и Minuet'чикам тоже понравится.

А нельзя было написать "пользователям/разрабам MenuetOS"?
А то при чтении " Minuet'чикам" буква u как то теряется и пропадает ;)


"asmttpd - http-сервер на ассемблере"
Отправлено Аноним , 20-Май-15 20:56 
> А то при чтении " Minuet'чикам" буква u как то теряется и пропадает ;)

Зато так суть отражается даже точнее :)


"asmttpd - http-сервер на ассемблере"
Отправлено Аноним , 20-Май-15 13:27 
вебсервер надо писать на php
phpttpd

"asmttpd - http-сервер на ассемблере"
Отправлено Феофан , 20-Май-15 13:34 
На брайнфаке надо еще для полноты картины.

"asmttpd - http-сервер на ассемблере"
Отправлено Andrey Mitrofanov , 20-Май-15 14:01 
> На брайнфаке надо еще для полноты картины.

На http://www.gnu.org/software/gawk/manual/gawkinet/html_node/S... написано GAWK-е же. Уже. </переписался>


"asmttpd - http-сервер на ассемблере"
Отправлено Аноним , 20-Май-15 20:57 
> написано GAWK-е же. Уже. </переписался>

Есть еще на шеллскриптах.


"asmttpd - http-сервер на ассемблере"
Отправлено Andrey Mitrofanov , 21-Май-15 09:38 
>> написано GAWK-е же. Уже. </переписался>
> Есть еще на шеллскриптах.

М-м-м, кстати да. Надо искать язык, на котором веб-сервера *нет* и его всё ещё надо написать.

BF #1, ...


"asmttpd - http-сервер на ассемблере"
Отправлено PnDx , 21-Май-15 12:41 
Любой, практически, спец. назначения. Из того, с чем как-то сталкивался:
COBOL и производные
FORTRAN
PL/M-образные или на чём там сейчас ПЛИСы программируют (поправьте, кто в теме). Хота, возможно, кто-то уже осилил httpd в виде хардварной закладочки.

LISP, вероятно


"asmttpd - http-сервер на ассемблере"
Отправлено Kodir , 20-Май-15 14:29 
> тесты производительности показывают существенное отставание

Да не вопрос! Неужто из асма нельзя задействовать весь тот спектр костылей, что сделали на Сях?? Всякие неблокирующие сокеты, мемкэши, упреждающая выборка ресурсов...
Но я всё равно не одобряю АСМ - как его ни комментируй, как ни оптимизируй, всё-равно код словесно будет раздут - сопровождение такой портянки будет нереальным, а это уже существенный минус для популяризации сервера. Да и в самом веб-сервере существенное время тратится далеко не на принятие соединения, а на ДВИЖОК страницы.


"asmttpd - http-сервер на ассемблере"
Отправлено Аноним , 20-Май-15 15:52 
> Да не вопрос! Неужто из асма нельзя задействовать весь тот спектр костылей,

Можно, только нужны и соответсвующие знания кроме книжки "ассемблер для чайников", таблички там интыловские и т.д. ;)

Т.е. просто "питон тормозит, мы напишем на си, на си тормозит, перепишем на асме! Теперь должно летать по определению!!" не прокатывало еще эдак лет десять назад.

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


"asmttpd - http-сервер на ассемблере"
Отправлено Crazy Alex , 20-Май-15 15:55 
Ну вот ты сам и ответил, почему нельзя задействовать - потому что эту адову простыню мало кто сможет написать/сопровождать.

"asmttpd - http-сервер на ассемблере"
Отправлено Аноним , 20-Май-15 15:03 
Сейчас стало модно доказывать корректность программ, например с помощью Coq proof assistant. Код маленький, можно попытаться доказать. Для Coq кто-то уже написал ассемблерный модуль (вот только не помню amd64 или i386).

"asmttpd - http-сервер на ассемблере"
Отправлено BratSinot , 20-Май-15 16:16 
А вообще странные, в одном и том-же коде, разница в пару строчек:
> mov al, 0x0

<...>
> xor rdx, rdx ; zero other half

Насколько я помню xor есть для ?l / ?h регистров.


"asmttpd - http-сервер на ассемблере"
Отправлено клоун , 20-Май-15 17:18 
xor работает для любых регистров.

mov al,0 меньше по размеру.


"asmttpd - http-сервер на ассемблере"
Отправлено Ващенаглухо , 21-Май-15 08:37 
но по времени выполнения mov дольше, чем xor

"asmttpd - http-сервер на ассемблере"
Отправлено z , 21-Май-15 14:55 
> но по времени выполнения mov дольше, чем xor

учим матчасть: mov reg,const обрывает для планировщика (не слишком новых cpu) зависимость от предыдущего значения reg, что увеличивает глубину внеочередного исполнения, т.е. скорость


"asmttpd - http-сервер на ассемблере"
Отправлено Аноним , 20-Май-15 17:08 
Даёшь CMS на асме!

"asmttpd - http-сервер на ассемблере"
Отправлено Нанобот , 20-Май-15 21:35 
Лучше сразу ERP

"asmttpd - http-сервер на ассемблере"
Отправлено Andrey Mitrofanov , 21-Май-15 09:40 
> Лучше сразу ERP

Конпелятор ЯВУ, чего там.


"asmttpd - http-сервер на ассемблере"
Отправлено Аноним , 21-Май-15 18:40 
> Конпелятор ЯВУ, чего там.

Можно просто яву. Которая жаба. Если JVM переписать на ассемблере - "ява не тормозит" приобретет новое звучание :)


"asmttpd - http-сервер на ассемблере"
Отправлено Аноним , 21-Май-15 00:27 
Через миллион лет дойдёт до уровня сегодняшнего Апача.

"asmttpd - http-сервер на ассемблере"
Отправлено Аноним , 21-Май-15 01:12 
Зачем? Изначально и намеренно непортабельное, очевидно нерасширяемое, скорее всего небезопасное и возможно более медленное чем аналоги на C/C++ убожество.

"asmttpd - http-сервер на ассемблере"
Отправлено Аноним , 21-Май-15 05:51 
Предлагаю поделить все open source проекты на общепризнанные категории, дабы не терять время на откровенный треш. Прямо на кодохостинги встроить текущие показатели с историей и ещё сайтик сделать, общая база.
Если в базе проекта нет, значит это вообще недопиленный мусор, брошенный на первых стадиях разработки, чего тоже навалом.

"asmttpd - http-сервер на ассемблере"
Отправлено бедный буратино , 21-Май-15 06:45 
см. в репозиториях

если есть во всех репозиториях - значит, крутая вещь. если в репозиториях некоторых дистров - значит, достойная. :)


"asmttpd - http-сервер на ассемблере"
Отправлено бедный буратино , 21-Май-15 06:45 
> см. в репозиториях
> если есть во всех репозиториях - значит, крутая вещь. если в репозиториях
> некоторых дистров - значит, достойная. :)

впрочем, лично я кроме репозиториев, ничем не пользуюсь (за очень крайне редкими исключениями). поэтому, нет в Debian и OpenBSD = для меня не существует :)


"asmttpd - http-сервер на ассемблере"
Отправлено Аноним , 21-Май-15 18:41 
> поэтому, нет в Debian и OpenBSD = для меня не существует :)

И эти люди запрещают нам ковыряться в носу и что-то там лечат про стереотипность...


"asmttpd - http-сервер на ассемблере"
Отправлено б.б. , 22-Май-15 10:44 
>> поэтому, нет в Debian и OpenBSD = для меня не существует :)
> И эти люди запрещают нам ковыряться в носу и что-то там лечат
> про стереотипность...

тебе кто-то запрещает ковыряться в носу?

и причём тут стереотипность?


"asmttpd - http-сервер на ассемблере"
Отправлено Ydro , 21-Май-15 09:46 
Я люблю ассемблер!

"asmttpd - http-сервер на ассемблере"
Отправлено asm , 21-Май-15 17:59 
я тя тоже люблю, друх

"asmttpd - http-сервер на ассемблере"
Отправлено none7 , 21-Май-15 18:18 
Что там оптимизировать можно вообще? Всё, что делают веб-сервера работая со статикой, это переадресуют url из запроса в функцию ядра open. Данные из файла в сокет пишет уже ядро. Может уже и шифрованные потоки так отправляют, по крайней мере блочная криптография в ядре уже есть.

"asmttpd - http-сервер на ассемблере"
Отправлено Аноним , 21-Май-15 18:44 
> это переадресуют url из запроса в функцию ядра open.

Ну тогда уж sendfile() - более интересная "функция" ядра :).

> по крайней мере блочная криптография в ядре уже есть.

Да и не только блочная. Ядро нынче умеет всякие там подписи модулей при загрузке проверять, например, если это надо.


"asmttpd - http-сервер на ассемблере"
Отправлено none7 , 21-Май-15 21:31 
Угораздило же меня глянуть код. КАЖДАЯ функция, включая системные вызовы обёрнута в пару макросов stackpush stackpop -_-. И почему это gcc не догадывается так делать? Вообще без нужды верхнюю часть регистра не трогает, ведь 8 64-битных Push нам совсем ничего не стоят.

Кстати вычисление 'Content-Type' из расширения и сравнение заголовков производится прямым перебором. Естественно о не чувствительности заголовков к регистру никто не подумал. В общем код сильно хуже того, что можно получить даже из gcc -O1. Уж не говоря об архитектурных ошибках.


"asmttpd - http-сервер на ассемблере"
Отправлено XoRe , 22-Май-15 00:29 
>  обработка кодов возврата (200, 206, 404, 400, 413, 416)

Т.е. 304 оно не умеет.
Хотя в принципе, там сложная логика - нужно анализировать метаданные файла и заголовки запроса клиента.
Но без этого его даже для фофана не стоит использовать.

> выдача корректного заголовка  "Content-type" для файлов xml, html, xhtml, gif, png, jpeg, css, js

Т.е., как в nginx, вынести в отдельный файл mime.types они не захотели.
Вообще, как здесь уже заметили, пока это отличный вариант для руткитов и бекдоров.