В рамках проекта 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
Новость: https://www.opennet.ru/opennews/art.shtml?num=42267
> Интересно, что несмотря на то, что код написан на ассемблере, проведённые
> пользователями тесты производительности показывают существенное отставание
> по скорости обработки запросов от современных http-серверов, написанных
> на языке Си.Прям чудеса...
Попытки тривиально реализовать сложные вещи всегда примерно так и кончаются.
Он просто синхронный и потоковый. Почти как в книжке "пишем свой хттп сервер за полтора часа для чайников". Единственное что сделано чуть сложнее - он не на каждый коннект тред рожает, а держит пул засуспенженых ниток под это дело.Если его переписать под асинхронный ввод-вывод и запускать в количество потоков == количеству ядер минус одно, то он будет летать так что уши закладывать будет.
Ну я примерно об этом и говорил. Только чем больше навернёте сложность реализации - тем более проблемно будет всё это на ассемблере ваять.
ваять не сложно, поддерживать нереально потом )
Ваять - тоже не слишком радостно, но поддержка, разумеется, подразумевалась - иначе кому такое чудо вообще нужно, без поддержки? Разве что как курсовик...
Да на самом деле будет практически так-же. Даже по обьему кода выйдет стока-же. Просто мыслить в коллбэчной модели асинхронного приложения надо привыкать, а мозги наизнанку выворачивать лениво, проще параллельно и перпендикулярно накодерасить.Кстати кажет он производительность чуть меньшую чем у апачи который сделан ровно через то же самое место.
> мозги наизнанку выворачивать лениво, проще параллельно и перпендикулярно накодерасить.Если ассемблерщик не может в event-driven - это нуб и олух, а не ассемблерщик.
Так, на подумать: а ничего что прерывания и исключения - это всего лишь этакая хардварная реализация callback-ов? И если ассемблерщик это не умеет - это какой-то очень хреновый и мягкотелый ассемблерщик :)
Программирование на epoll/kqueue/poll/select + неблокирующий read/write и коллбэчная модель это ортогональные штуки.
Можно из без коллбэков, но с ними удобнее.
Напомнило творчество одного деятеля, который "для производительности" написал веб-приложение на С ... работающее через CGI. Сильно удивлялся, когда я переписал это дело на богомерзком похапе и получил в 40 раз больше RPS :)
> Из запланированных на ближайшее будущее возможностей отмечается формирование индекса содержимого директорий и поддержка заголовка HEAD.Зря они это надумали, бинарник ведь раздует килобайт эдак до воьсми с половиной, и куда они потом с этой махиной.
для amd64 не страшно, если бы под arm делали, а так, пускай))
Логично. Ассемблер же не волшебная палочка. Хорошо написанный код на СИ в общем случае не улучшишь с помощью ассемблера.
SIMD? Нет, не слашал, да?
> SIMD? Нет, не слашал, да?Да! Оно улучшит веб-сервер. Кардинально.
ps. Не сЛОШал.
>> SIMD? Нет, не слашал, да?
> Да! Оно улучшит веб-сервер. Кардинально.Без шуток, улучшит, кардинально. То же копирование памяти.
Просто нужно параллелизировать алгоритмы и данные. Это не всегда просто, чаще всего очень даже сложно, но выполнимо.
> SIMD? Нет, не слашал, да?Вы не поверите, но современные компиляторы о нем тоже слышали.
Но на asm'е больше шансов подогнать код так, что бы он уместился в L1-кеш процессора.
Вообще и этим должен заниматься компилятор, если специально поставить такую задачу
Я имею виду разместить весь код приложения, как это делает memtest. На C это мало реально, ввиду раздутости библиотек.
> C это мало реально, ввиду раздутости библиотек.Вот те раз, а мужики с -nostdlib то и не в курсе. В смысле, на си можно собрать даже boot loader какой-нибудь, где printf делать еще некуда, файловой системы - нет как класса, и вообще, есть только проц да кучка служебных регистров.
И си это вроде как единственный язык где можно "почти как на асме" но - без выписывания всех ассемблерных команд самолично.
Да можно, я сам пишу на С под AVR. И на C++ можно, но реальность увы гораздо суровее. Посмотрите здесь обсуждение Qt-5.5 - программистов на C++ не волнуют не то что килобайты, но и мегабайты.
> Да можно, я сам пишу на С под AVR. И на C++
> можно, но реальность увы гораздо суровее. Посмотрите здесь обсуждение Qt-5.5 -
> программистов на C++ не волнуют не то что килобайты, но и
> мегабайты.Загляни в новость про жабу, там и единиц измерения-то таких не знают, там с гигабайта всё только начинается.
>Да можно, я сам пишу на С под AVR. И на C++ можно, но реальность увы гораздо суровее. Посмотрите здесь обсуждение Qt-5.5Я сам вожу грузы на „Газели“, но реальность увы горзадо суровее. Посмотрите здесь обсуждение „Белаза-75710”…
> Я сам вожу грузы на „Газели“, но реальность увы горзадо суровее. Посмотрите
> здесь обсуждение „Белаза-75710”…Вот в теме про Qt-5.5 и предлагают использовать Белаз для перевозки одного мешка цемента ...
> Вот в теме про Qt-5.5 и предлагают использовать Белаз для перевозки одного
> мешка цемента ...А вы (ну так, глядя на ваши девайсы на тиньках) обычно это делаете так:
- Знаете, парни, все эти ваши газели и тем более белазы - сложные и ненадежные! Вон там сколько всего сломаться может, а запчасти стоят дофига, все дела.
- Что вы предлагаете?
- Ну нам вроде весь мешок прямо сейчас не требуется. Прямо сейчас надо только вон ту дырку заложить. Ведра хватит! Ведро - надежное и дешевое, газели и белазы пролетают!
(проходит полдня корячений с тасканием тяжелого ведра через полгорода)
- Ну вот, все дырка заложена. Задача решена!
- Погодите, но тут еще две дырки?
- А следующую дырку мы как-нибудь потом заложим. Сейчас что-то задолбались.
> А вы (ну так, глядя на ваши девайсы на тиньках) обычно это
> делаете так:Не понял, к чему ваши аналогии?
Приведенные мной примеры на attiny13 работают не первый год, их работой я доволен. Работают они все на 1.2MHz, сама же attiny13 может работать до 20MHz.
Ну так Qt любой версии, как бы, не ориентирована на 8-битные AVR совсем. Даже на STM32 без подключения внешней памяти не впихнуть.
Реальность такова, что плюсовый код на порядок лучше оптимизирует.
Из последнего - это замена memset и memcpy на std::fill и std::copy.
В сишном варианте проверки выравнивания и размеров копирования выполняются в рантайме - в плюсовом - на этапе компиляции.
> Реальность такова, что плюсовый код на порядок лучше оптимизирует.Лол. Может вы еще и с ассемблерными листингами и замерами производительности все это покажете, чтобы не быть голословным? :)
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, например.
> Реальность такова, что плюсовый код на порядок лучше оптимизирует.Что, простите?
> Из последнего - это замена memset и memcpy на std::fill и std::copy.
Может у вас и <<, >> быстрее, чем read, write?
Ну и как тебе писать сложный алгоритм на ассемблере и на C под avr?
> Ну и как тебе писать сложный алгоритм на ассемблере и на C
> под avr?https://www.opennet.ru/openforum/vsluhforumID3/102654.html#67
Он этим занимается аж в 0.1% случаев, о таких вещах как cache pollution-aware вообще молчу
Сразу видно, что пишет человек с SIMD серьёзно не работавший.Компиляторы, конечно, SIMD стараются применять, но отстают в успехе в разы, даже и использованием intrinsic функций. Главная проблема в том, что компилятору далеко не всегда возможно определить, где можно векторизовать код без потери в точности или скорости с учётом стоимости переключения контекста процессора между int и float.
>переключения контекста процессора между int и floatНаверное, я отстал от жизни. Обработка типов int и float уже выполняются в разных процессах?
> Наверное, я отстал от жизни. Обработка типов int и float уже выполняются в разных процессах?Не "отстал", а никогда в неё и не входил. С момента появления FPU переключение между контекстом целочисленных операций и операций с плавающей запятой было и является весьма дорогим:
https://en.wikipedia.org/wiki/Context_switch#PerformanceМежду прочим, это главная причина того, что ядро целиком и полностью целочисленное (если нужны вещественные числа, используется fixed-point арифметика, а она реализована на целых числах), за исключением нескольких особых случаев:
http://yarchive.net/comp/linux/kernel_fp.html
> Не "отстал", а никогда в неё и не входил. С момента появления FPU переключение между контекстом целочисленных операций и операций с плавающей запятой было и является весьма дорогимУважаемый, вы упоролись. Пенальти за переход между целочисленным режимом и FP был во времена MMX, когда для целочисленных значений использовались регистры FPU. С тех пор, как появились SSE/SSE2, про MMX и, собственно, сам FPU все забыли как про страшный сон.
Переключение контекста - это вообще из области многопоточности/многозадачности.
> Уважаемый, вы упоролись. Пенальти за переход между целочисленным режимом и FP был
> во времена MMX, когда для целочисленных значений использовались регистры FPU. С
> тех пор, как появились SSE/SSE2, про MMX и, собственно, сам FPU
> все забыли как про страшный сон.Не все - gcc по-умолчанию использует сопроцессор для 32 битных систем. Есть у него и хитрый режим sse+387 - что удваивает количество регистров.
> Переключение контекста - это вообще из области многопоточности/многозадачности.
Насколько я понимаю, речь идет о том, что при переключении потока/задачи придется регистры сопроцессор сохранять/восстанавливать.
> Не все - gcc по-умолчанию использует сопроцессор для 32 битных систем. Есть у него и хитрый режим sse+387 - что удваивает количество регистров.Уже нет. Начиная с 4.9 SSE используется по умолчанию и для 32-битных приложений.
https://gcc.gnu.org/gcc-4.9/changes.html
Разве что вы собираете код для CPU без SSE или целенаправленно хотите использовать FPU ради повышенной точности.
> Насколько я понимаю, речь идет о том, что при переключении потока/задачи придется регистры сопроцессор сохранять/восстанавливать.
Вот это действительно имеет место. Но не надо путать теплое с мягким - на этапе исполнения кода никаких "переключений контекста" нет.
> Уже нет. Начиная с 4.9 SSE используется по умолчанию и для 32-битных
> приложений.
> https://gcc.gnu.org/gcc-4.9/changes.htmlНе нашел. man gcc (4.9.2) утверждает обратное. Если вы про -ffast-math, то даже я, любитель собрать систему с -O3, использую -ffast-math только при экспериментах, да и то на отдельных пакетах - слишком много от этой опции проблем.
>SIMD? Нет, не слашал, да?вот и разработчики не слышали. или слышали, но у них не хватило наркоты, чтобы придумать, как это можно использовать для обработки http-трафика
>>SIMD? Нет, не слашал, да?
> вот и разработчики не слышали. или слышали, но у них не хватило
> наркоты, чтобы придумать, как это можно использовать для обработки http-трафикаЗачем наркота? Тот же SSE давно используется в столь далёких от паралельных вычислений вещах, как memcpy, см. код glibc.
> Хорошо написанный код на СИ в общем случае не улучшишь с помощью ассемблера.То-то все кодеки, либы шифрования, turbojpeg и прочие - вставки на асме пишут для ускорения.
Потому что как там сгенерит код сишный компилер - бабушка надвое сказала. И когда он вывалит какое-то жуткое месиво в тугом цикле, "потому что кодогенератор так решил" - знаешь, кодек с асмовыми вставками, где этот цикл вылизан покомандно живым человеком - может оказаться в 2-3 раза быстрее. Просто потому что в тугом цикле - в 2 раза меньше команд. Человек то в отличие от компилера может и подраспереться в одной локальной местности, оптимизнув по максимуму. Но писать мег кода на асме - бесполезно :). Можно запросто продуть компилятору в оптимизации использования регистров и проч.
https://www.opennet.ru/opennews/art.shtml?num=36551
> https://www.opennet.ru/opennews/art.shtml?num=36551Большая часть ассемблерных вставок малозначительна и не создаёт должного увеличения производительности. Часто разработчики пытаются использовать тривиальный код с надеждой увеличить скорость выполнения тех или иных действий, но при этом общий эффект подавляется другими узкими местами.
> Большая часть ассемблерных вставок малозначительнаЭто тот случай когда "мал золотник, да дорог". Нет смысла ускорять код в который ничего особо и не упиралось, поэтому переписать всю ОС или программу на асм как колибри или менуэт - довольно глупо.
А вот самые горячие циклы - на асме получаются быстрее, и это определяет всю производительность программы в местах где это критично. Что важно для кодеков, криптографии и прочая.
> и не создаёт должного увеличения производительности.
А я вот мерял как-то чисто сишные версии vs C+asm вставки в случае кодека - разница была очень даже. И я бы не хотел пользоваться чисто сишной версией кодека при доступности asm-optimized, разница может быть в пару раз запросто. А это меньше шума от вентиля на мощном проце, а на слабом - больше разрешение которое прожуется без выпадения кадров.
> другими узкими местами.
Вот в кодеках например асмовые вставки сделаны в самых горячих местах. Что и ускоряет все буквально в разы. Ну разумеется всякий glue code вызываемый сильно иногда - никто в здравом уме на асме писать не будет, потому что эффекта около ноля, а возни много.
> То-то все кодеки, либы шифрования, turbojpeg и прочие - вставки на асме
> пишут для ускорения.Как видим, весь код на асме пишут для замедления.
> Как видим, весь код на асме пишут для замедления.Он медленный не из-за того что на асме а из-за того что синхронный и большую часть времени катает вату в ожидании завершения операции ввода-вывода и стоит на семафорах.
Если его на сях переписать будет еще тупее по производительности.
>> Как видим, весь код на асме пишут для замедления.
>что они - тормозная блоатварь.Про блоат это ты принёс. Беспокоит размер? Сравнивал 10DVD любой из 10 архитектур Debian-а со своими ассемберными пипирками и аж задохнулся?? Твои страдания >>>-все-видят->
> Сотни батхерта обеспечены :)
> Про блоат это ты принёс.Я всего лишь придумал как оптимизировать наброс. Троллить ассемблерщиков неоптимальными набросами - не пройдет. Они во всем оптимизацию любят.
Да, так я и написал "в общем случае".
Кодеки, шифрование, обработка изображений - это "числодробилки". Ассемблерные вставки там - это чёрные ящики, получающие буфер с данными на входе и выдающие буфер на выходе, это функции-аутисты, проделывающие большой объем вычислений, никак не общаясь с окружением.
А что такое http-сервер? Это жонглирование буферами памяти между вызовами API-шных функций работы с сетью и диском. Ну, парсер строк заголовков еще можно написать на асме, если уж руки чешутся. Но весь червер на асме это чистое рукоблудие.
Ух ты, я вызвал приступы капитанинга. Любо-дорого смотреть, Капитаны на опеннете сегодня качественные :)
>[оверквотинг удален]
> пишут для ускорения.
> Потому что как там сгенерит код сишный компилер - бабушка надвое сказала.
> И когда он вывалит какое-то жуткое месиво в тугом цикле, "потому
> что кодогенератор так решил" - знаешь, кодек с асмовыми вставками, где
> этот цикл вылизан покомандно живым человеком - может оказаться в 2-3
> раза быстрее. Просто потому что в тугом цикле - в 2
> раза меньше команд. Человек то в отличие от компилера может и
> подраспереться в одной локальной местности, оптимизнув по максимуму. Но писать мег
> кода на асме - бесполезно :). Можно запросто продуть компилятору в
> оптимизации использования регистров и проч.С использованием векторных инструкций не в 2-3 раза, а в 20-30 раз (для конкретного цикла или небольшого куска кода), что в целом даёт 2-5 раз уже для всей программы.
> Прям чудесаОжидаемо. Просто алгоритмы оптимизации кода в компиляторах достаточно развиты. Одна моя подделка с -O2 работала раза в 4 быстрее по сравнению с -O0.
Относительно проекта впечатления противоречивые, но склоняюсь к позитиву. С одной стороны "Зачем?", а с другой - может наконец-то девелоперы начнут ртбращать внимание а ресурсы, которые потребляет их программы, а то софт с учётом апгрейда железа тормозит точно также, как и 15лет назад.
Да при чём здесь оптимизации. Просто на ассемблере несколько задолбаешься делать сложную высокоуровневую логику, нужную для эффективной реализации чего-то большого. Если ты не Кнут, конечно. А то, что высокоуровневые оптимизации дают на порядки больший эффект, чем вылизывание инструкций - не секрет ни разу.Лишнее подтверждение этому - объём бинарника. 6к - даже для ассемблера не ахти что, тем более на x86_64. То есть там наверняка всё внутри реализовано самым тривиальным образом.
> Лишнее подтверждение этому - объём бинарника. 6к - даже для ассемблера не ахти чтоЭто как-бы мало, у остальных они за собой еще libc / stdc++ потянут, а тут только ядро нужно.
Это не просто мало - это катастрофически мало для того, чтобы реализовать приличные структуры данных и алгоритмику
> а то софт с учётом апгрейда железа тормозит точно также, как и 15лет назадЭто все сказки. Вы просто не замечаете возросших потребностей. Один графический тулкит с тенями, анимациями нажатий и т.д. чего стоит.
Что 15 лет назад по большей части никто не оптимизировал, что сейчас. Ситуация одинаковая.
Никто не уловил сарказм?
чудеса будут, если он проживет столько, сколько апач например и все равно будет сливать по скорости. в данный момент сравнение некорректно
Сейчас начнется очередной виток срача, в последнее время популярного на опеннете: "на чем писать сервер". В тред приглашаются специалисты младшего школьного отделения.
На go, очевидно же. Модно-молодёжно, ибо ваистену! :-)
На пИтОнЕ.
CherryPy? Не, не слышал!
Tornado? Не, тоже не знаю!
Twisted? Не, тоже как-то не случилось обратить внимание...Ну может хоть uWSGI или, прикола ради, Waitress WSGI Server? Что тоже нет?! В школу!!! Немедленно!
> CherryPy?
> Tornado?
> Twisted?И все их ставят за nginx-ом, написанном на... ?
>В школу!!! Немедленно!
Вопрос спорный. Разгребать статику можно конечно и nginx. Я кстати, именно его и использую в связке с gunicorn. Хотя тот же Торнадо и сам неплохо с этим справляется http://www.tornadoweb.org/en/branch2.1/overview.html#static-... и вовсе не требует каких-то там фронт-эндов "написанных на... ?"PS Эх... школа... я, кстати, с удовольствием туда бы вернулся на годик-два. Золотое было время!
> Хотя тот же Торнадо и сам неплохо с этим справляетсяИ как он на 50000-100000 коннектов?
Фиг знает. Я же писал постом выше, что использую как раз nginx+gunicorn.
Но люди отзываются о торнадо под нагрузкой не плохо. Хотя куда лучше отзывы о твистид. Вот, кста, интересное обсуждение, если интересуетесь http://profyclub.ru/docs/124
>> И все их ставят за nginx-омБалансер/раздатчик статики - еще не веб-сервер. Но в школах этого не читают, увы.
Но то, что он балансирует, и подавно не обязано быть веб-сервером - к примеру, это может быть какой-нибудь WSGI-бакэнд, или масса всего прочего, что реализовано для того же нгинкса, вплоть до прямой работы с базами данных. Можно, разумеется, спорить о терминах, но, как мне кажется, логичнее будет всё же сойтись на том, что приложение, отдающее свой контент, в том числе статический (в противовес проксированию чужого) по HTTP-протоколу, веб-сервером всё же является.
>WSGI-бакэндИМХО, в данном случае, WSGI-бакэнд как раз и есть веб-сервер, поскольку имено он генерирует динамический контент, создает html-страницы. А вот балансировщик, даром что именно он возвращает их, веб-сервером можно назвать с большой натяжкой. Уж скорее кэширующим прокси-сервером. Да собственно, nginx, именно так (в том числе) себя и позиционирует. Официально: "обратный прокси-сервер". Конечно, он еще и полноценный веб-сервер, но для питоновых веб-приложений, его полноценность, в плане веб-сервера, глубоко до лампочки, - ибо не востребована.
WSGI — это явный сервер приложений.
Веб-сервер — это то, что разговаривает по HTTP.
Nginx - веб-сервер.
Апач - веб-сервер со встроенными (в виде, например, PHP module) серверами приложений.
Nginx - проксифронтенд. Все что за ним стоит - бэкенд. Не надо придумывать ненужные сущности.
Понятие frontend/backend ортогонально к понятию web/http server.
Если nginx общается с бекендом по fcgi или uwsgi, то бекенд уже не может претендовать на звание вебсервера.
А если проксирует/балансирует запросы, например, к nodejs?
Мал и самодостаточен - удобен для руткитов с ботнетами.
Хмм... А если бы не из директории, а из памяти, как бы тогда он был рядом с серверами на C?
на сях сверхмудрый оптимизатор хорошо оптимизирует код, тогда как тут вся оптимизация лежит на программистах.
а какая разница из чего делать системый вызов?
разница большая: системный вызов, например, из дерева работать скорее всего не будет.
> разница большая: системный вызов, например, из дерева работать скорее всего не будет.Можно запилить RPC-интерфейс. Тогда будет!
> а какая разница из чего делать системый вызов?Ну, может быть там работа с ФС рудиментарная, и причина тормозов в этом. А из памяти - тупо взял и выстрелил, и всё.
про файловые кеш на уровне ОС не слышали?
оно и так раздается из памяти, скорей всего, после первых запросов.
Умничка. Слышал про файловый кэш на уровне ОС. А теперь следи за руками. Сервер парсит URL и маппит его в путь к файлу. После этого он просит его у ОС как файл. Должен быть готов обработать любой ответ. Нет - отдать 404, давно лежит - отдать 304, и т.д. ОС смотрит, не в кэше ли этот файл, если в кэше - отдаёт его (а это, между прочим, передача данных от ядра к пользовательскому процессу).
Если же объекты лежат в памяти самого процеса, от маппит URL в адрес, находит в своих данных его размер, время изменения и т.д., и если надо отдать - отдаёт из своей памяти.
> Если же объекты лежат в памяти самого процеса, от маппит URL в
> адрес, находит в своих данных его размер, время изменения и т.д.,Вот оно!! Надо "объекты" тож на асме писать! </это же всё решает!></и проблему php тоже>
> и если надо отдать - отдаёт из своей памяти.
Хе, какой-то уязвлённый школьник минусов накидал, а возразить по делу (sendfile(2), например) эрудиции не хватило.
Почему не GPL3?
потому что GPLv2
=D
Ну уж хотя бы не БЗДы
> Почему не GPL3?гладиолус
На ассемблере и медленно!? Кощунство!!!
Может быть, потому что не только от языка и его уровня зависит, но и от кривости извилин программиста?
> Может быть, потому что не только от языка и его уровня зависит,
> но и от кривости извилин программиста?Именно поэтому. Эти их такты на гигагерцах не имеют никакого значения при миллисекундных порядках раундтрипов/коннектов. И даже при микросекундных на эзернетах.
Впрочем, мы, конечно, сочувствуем столь сложному и трудному способу получения удовольствия. За отсутствием другого результата.
//Прошлый, раз у выноси^H^H^H^Hрезателей драйвера сетевой и стека tcp в веб-сервер, было хоть удовольствие от B)перформанса.
> Именно поэтому. Эти их такты на гигагерцах не имеют никакого значения при миллисекундных порядках раундтрипов/коннектов. И даже при микросекундных на эзернетах.Энергоэффективность? Представьте маломощный arm, полностью автономный - работающий от солнечных батарей, не требующих затрат на теплоотведение из серверной.
Оно бы да, но писано-то под x86_64
> Оно бы да, но писано-то под x86_64Это я в теории, про светлое будущее :)
На x86_64 потребление питания и тепловыделение тоже весьма зависит от нагрузки. Вдобавок появляться возможность сделать underclocking+undervolting и существенно улучшить энергоэффективность.
Ну, я никогда не был сторонником особой оптимизации по энергоэффективности на стационарных машинах или делания чего-то тяжелого на мобильных устройствах - от смартфона до ноутбука. Первое и последнее, что вспоминается в плане реальной нужды увеличивать энергоэффективность на стационарах - майнинг. Да и не думаю я, что сколь угодно крутой веб-сервер, писанный на асемблере, даст такие уж сильные отличия по энергопотребению целой машины в сравнении с сишным сервером. И даже если даст - наверняка практически то же будет достижимо парой ассемблерных вставок в сишный код. А вот писать эффективную высокоуровневую логику на ассемблере - занятие довольно-таки дурное, вот на ней ассемблерный сервер и просядет.
Я придерживаюсь такого же мнения - C код + ассемблерные вставки в особо критичных местах не будет существенно проигрывать чистому ассемблеру. А если учесть сложность поддержки и развития ассемблерного кода и практически нулевую переносимость ...Другое дело что, люди выбирающие ассемблер стремятся к максимальной эффективности (cpu/ram) ПО, а не к скорости разработки, как это часто происходит при выборе более высокоуровненных языков.
Разница в одинаково написанном коде не превышает 5%.Другое дело, что каждый язык приучает к своему стилю.
Напр. базовое: есть массив структура {артикул - сумма}, нужно быстро находить сумму по артикулу и рассчитывать общую сумму. В Си это делается созданием структуру и циклу по ней, но это неоптимально, т.к. в кэш попадают ненужные данные. Гораздо быстрее хранить два массива отдельно. Это ненаглядно и не Си-стайл, зато эффективно.
> и не Си-стайл, зато эффективно.А какой у си стайл? На нем все пишут по разному, от этакого "почти ассемблера" до "фигасе, они сделали ООП на си!"
На AMD64 написанный и на плюсах будет нехило работать, и даже на питоне. И проблема экономии памяти до единиц Кб там, как бы, не актуальна.
Такое для архитектуры Cortex-M3 больше пригодилось бы.
>Такое для архитектуры Cortex-M3 больше пригодилось бы.Ну вообще да, на всяких малых и особо малых устройства он само то.
Вангую что ребята из Калибри захотят его себе портировать.
> На AMD64 написанный и на плюсах будет нехило работать, и даже на питоне.Ога, пока рядом не запустят нжинкс и не проведут бенчмарк :)
И что произойдет? Одна из первых ссылок в гуге по запросу "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."
Надо пойти поискать посвежее сравнения.
Это не бенчмарк, а хрень собачья.
> Это не бенчмарк, а хрень собачья.Свидетели Пресвятого Nginx'а обвиняют собеседника в ереси
> Свидетели Пресвятого Nginx'а обвиняют собеседника в ересиВ неумении делать бенчи или того хуже запредельном уровне подтасовок. Засилье нжинкса в top busiest sites как бы намекает. А если бы все было как там написано, без подвохов - те ...цать процентов рынка давно были бы у node.js :P
>> Засилье нжинкса в top busiest sites как бы намекаетчто он отличный балансер, но бакенд за ним все равно на других языках. Что тоже как бы намекает.
> что он отличный балансер, но бакенд за ним все равно на других
> языках. Что тоже как бы намекает.Капитан Очевидность намекает что по минимуму веб сервер может вообще не уметь динамику, но веб-сервером он от этого быть не перестанет :). Он перестанет быть сервером приложений, но это уже несколько другое.
Хотя, может и Minuet'чикам тоже понравится.
> Хотя, может и Minuet'чикам тоже понравится.А нельзя было написать "пользователям/разрабам MenuetOS"?
А то при чтении " Minuet'чикам" буква u как то теряется и пропадает ;)
> А то при чтении " Minuet'чикам" буква u как то теряется и пропадает ;)Зато так суть отражается даже точнее :)
вебсервер надо писать на php
phpttpd
На брайнфаке надо еще для полноты картины.
> На брайнфаке надо еще для полноты картины.На http://www.gnu.org/software/gawk/manual/gawkinet/html_node/S... написано GAWK-е же. Уже. </переписался>
> написано GAWK-е же. Уже. </переписался>Есть еще на шеллскриптах.
>> написано GAWK-е же. Уже. </переписался>
> Есть еще на шеллскриптах.М-м-м, кстати да. Надо искать язык, на котором веб-сервера *нет* и его всё ещё надо написать.
BF #1, ...
Любой, практически, спец. назначения. Из того, с чем как-то сталкивался:
COBOL и производные
FORTRAN
PL/M-образные или на чём там сейчас ПЛИСы программируют (поправьте, кто в теме). Хота, возможно, кто-то уже осилил httpd в виде хардварной закладочки.LISP, вероятно
> тесты производительности показывают существенное отставаниеДа не вопрос! Неужто из асма нельзя задействовать весь тот спектр костылей, что сделали на Сях?? Всякие неблокирующие сокеты, мемкэши, упреждающая выборка ресурсов...
Но я всё равно не одобряю АСМ - как его ни комментируй, как ни оптимизируй, всё-равно код словесно будет раздут - сопровождение такой портянки будет нереальным, а это уже существенный минус для популяризации сервера. Да и в самом веб-сервере существенное время тратится далеко не на принятие соединения, а на ДВИЖОК страницы.
> Да не вопрос! Неужто из асма нельзя задействовать весь тот спектр костылей,Можно, только нужны и соответсвующие знания кроме книжки "ассемблер для чайников", таблички там интыловские и т.д. ;)
Т.е. просто "питон тормозит, мы напишем на си, на си тормозит, перепишем на асме! Теперь должно летать по определению!!" не прокатывало еще эдак лет десять назад.Я конечно могу и ошибаться, ибо глянул по быстрому - но нигде не заметил выравнивания в памяти сонстант и буферов - а это уже, как бы, показатель.
Ну вот ты сам и ответил, почему нельзя задействовать - потому что эту адову простыню мало кто сможет написать/сопровождать.
Сейчас стало модно доказывать корректность программ, например с помощью Coq proof assistant. Код маленький, можно попытаться доказать. Для Coq кто-то уже написал ассемблерный модуль (вот только не помню amd64 или i386).
А вообще странные, в одном и том-же коде, разница в пару строчек:
> mov al, 0x0<...>
> xor rdx, rdx ; zero other halfНасколько я помню xor есть для ?l / ?h регистров.
xor работает для любых регистров.mov al,0 меньше по размеру.
но по времени выполнения mov дольше, чем xor
> но по времени выполнения mov дольше, чем xorучим матчасть: mov reg,const обрывает для планировщика (не слишком новых cpu) зависимость от предыдущего значения reg, что увеличивает глубину внеочередного исполнения, т.е. скорость
Даёшь CMS на асме!
Лучше сразу ERP
> Лучше сразу ERPКонпелятор ЯВУ, чего там.
> Конпелятор ЯВУ, чего там.Можно просто яву. Которая жаба. Если JVM переписать на ассемблере - "ява не тормозит" приобретет новое звучание :)
Через миллион лет дойдёт до уровня сегодняшнего Апача.
Зачем? Изначально и намеренно непортабельное, очевидно нерасширяемое, скорее всего небезопасное и возможно более медленное чем аналоги на C/C++ убожество.
Предлагаю поделить все open source проекты на общепризнанные категории, дабы не терять время на откровенный треш. Прямо на кодохостинги встроить текущие показатели с историей и ещё сайтик сделать, общая база.
Если в базе проекта нет, значит это вообще недопиленный мусор, брошенный на первых стадиях разработки, чего тоже навалом.
см. в репозиторияхесли есть во всех репозиториях - значит, крутая вещь. если в репозиториях некоторых дистров - значит, достойная. :)
> см. в репозиториях
> если есть во всех репозиториях - значит, крутая вещь. если в репозиториях
> некоторых дистров - значит, достойная. :)впрочем, лично я кроме репозиториев, ничем не пользуюсь (за очень крайне редкими исключениями). поэтому, нет в Debian и OpenBSD = для меня не существует :)
> поэтому, нет в Debian и OpenBSD = для меня не существует :)И эти люди запрещают нам ковыряться в носу и что-то там лечат про стереотипность...
>> поэтому, нет в Debian и OpenBSD = для меня не существует :)
> И эти люди запрещают нам ковыряться в носу и что-то там лечат
> про стереотипность...тебе кто-то запрещает ковыряться в носу?
и причём тут стереотипность?
Я люблю ассемблер!
я тя тоже люблю, друх
Что там оптимизировать можно вообще? Всё, что делают веб-сервера работая со статикой, это переадресуют url из запроса в функцию ядра open. Данные из файла в сокет пишет уже ядро. Может уже и шифрованные потоки так отправляют, по крайней мере блочная криптография в ядре уже есть.
> это переадресуют url из запроса в функцию ядра open.Ну тогда уж sendfile() - более интересная "функция" ядра :).
> по крайней мере блочная криптография в ядре уже есть.
Да и не только блочная. Ядро нынче умеет всякие там подписи модулей при загрузке проверять, например, если это надо.
Угораздило же меня глянуть код. КАЖДАЯ функция, включая системные вызовы обёрнута в пару макросов stackpush stackpop -_-. И почему это gcc не догадывается так делать? Вообще без нужды верхнюю часть регистра не трогает, ведь 8 64-битных Push нам совсем ничего не стоят.Кстати вычисление 'Content-Type' из расширения и сравнение заголовков производится прямым перебором. Естественно о не чувствительности заголовков к регистру никто не подумал. В общем код сильно хуже того, что можно получить даже из gcc -O1. Уж не говоря об архитектурных ошибках.
> обработка кодов возврата (200, 206, 404, 400, 413, 416)Т.е. 304 оно не умеет.
Хотя в принципе, там сложная логика - нужно анализировать метаданные файла и заголовки запроса клиента.
Но без этого его даже для фофана не стоит использовать.> выдача корректного заголовка "Content-type" для файлов xml, html, xhtml, gif, png, jpeg, css, js
Т.е., как в nginx, вынести в отдельный файл mime.types они не захотели.
Вообще, как здесь уже заметили, пока это отличный вариант для руткитов и бекдоров.