| 1.1, Аноним (-), 12:10, 20/05/2015 [ответить] [﹢﹢﹢] [ · · · ]
| +12 +/– |
> Интересно, что несмотря на то, что код написан на ассемблере, проведённые
> пользователями тесты производительности показывают существенное отставание
> по скорости обработки запросов от современных http-серверов, написанных
> на языке Си.
Прям чудеса...
| | |
| |
| 2.10, Crazy Alex (ok), 12:21, 20/05/2015 [^] [^^] [^^^] [ответить]
| +18 +/– |
 Попытки тривиально реализовать сложные вещи всегда примерно так и кончаются.
| | |
| |
| 3.55, ram_scan (?), 15:20, 20/05/2015 [^] [^^] [^^^] [ответить]
| +5 +/– | |
Он просто синхронный и потоковый. Почти как в книжке "пишем свой хттп сервер за полтора часа для чайников". Единственное что сделано чуть сложнее - он не на каждый коннект тред рожает, а держит пул засуспенженых ниток под это дело.
Если его переписать под асинхронный ввод-вывод и запускать в количество потоков == количеству ядер минус одно, то он будет летать так что уши закладывать будет.
| | |
| |
| 4.57, Crazy Alex (ok), 15:39, 20/05/2015 [^] [^^] [^^^] [ответить]
| +3 +/– |
Ну я примерно об этом и говорил. Только чем больше навернёте сложность реализации - тем более проблемно будет всё это на ассемблере ваять.
| | |
| |
| |
| 6.102, Crazy Alex (ok), 02:59, 21/05/2015 [^] [^^] [^^^] [ответить]
| +/– |
Ваять - тоже не слишком радостно, но поддержка, разумеется, подразумевалась - иначе кому такое чудо вообще нужно, без поддержки? Разве что как курсовик...
| | |
|
| 5.59, ram_scan (?), 15:45, 20/05/2015 [^] [^^] [^^^] [ответить]
| +2 +/– | |
Да на самом деле будет практически так-же. Даже по обьему кода выйдет стока-же. Просто мыслить в коллбэчной модели асинхронного приложения надо привыкать, а мозги наизнанку выворачивать лениво, проще параллельно и перпендикулярно накодерасить.
Кстати кажет он производительность чуть меньшую чем у апачи который сделан ровно через то же самое место.
| | |
| |
| 6.129, Аноним (-), 18:17, 21/05/2015 [^] [^^] [^^^] [ответить]
| +1 +/– | |
> мозги наизнанку выворачивать лениво, проще параллельно и перпендикулярно накодерасить.
Если ассемблерщик не может в event-driven - это нуб и олух, а не ассемблерщик.
Так, на подумать: а ничего что прерывания и исключения - это всего лишь этакая хардварная реализация callback-ов? И если ассемблерщик это не умеет - это какой-то очень хреновый и мягкотелый ассемблерщик :)
| | |
| 6.148, myc (?), 13:52, 22/05/2015 [^] [^^] [^^^] [ответить]
| +/– |
Программирование на epoll/kqueue/poll/select + неблокирующий read/write и коллбэчная модель это ортогональные штуки.
Можно из без коллбэков, но с ними удобнее.
| | |
|
|
| 4.150, Аноним (-), 15:49, 22/05/2015 [^] [^^] [^^^] [ответить]
| +1 +/– |
Напомнило творчество одного деятеля, который "для производительности" написал веб-приложение на С ... работающее через CGI. Сильно удивлялся, когда я переписал это дело на богомерзком похапе и получил в 40 раз больше RPS :)
| | |
|
| 3.99, Анончег (?), 01:09, 21/05/2015 [^] [^^] [^^^] [ответить]
| +8 +/– | |
> Из запланированных на ближайшее будущее возможностей отмечается формирование индекса содержимого директорий и поддержка заголовка HEAD.
Зря они это надумали, бинарник ведь раздует килобайт эдак до воьсми с половиной, и куда они потом с этой махиной.
| | |
| |
| 4.109, cmp (ok), 05:02, 21/05/2015 [^] [^^] [^^^] [ответить]
| +/– |
 для amd64 не страшно, если бы под arm делали, а так, пускай))
| | |
|
|
| 2.18, iPony (?), 12:48, 20/05/2015 [^] [^^] [^^^] [ответить]
| +/– |
Логично. Ассемблер же не волшебная палочка. Хорошо написанный код на СИ в общем случае не улучшишь с помощью ассемблера.
| | |
| |
| |
| |
| 5.107, bircoph (ok), 04:57, 21/05/2015 [^] [^^] [^^^] [ответить]
| –3 +/– |
 >> SIMD? Нет, не слашал, да?
> Да! Оно улучшит веб-сервер. Кардинально.
Без шуток, улучшит, кардинально. То же копирование памяти.
Просто нужно параллелизировать алгоритмы и данные. Это не всегда просто, чаще всего очень даже сложно, но выполнимо.
| | |
|
| 4.26, Аноним (-), 13:25, 20/05/2015 [^] [^^] [^^^] [ответить]
| +8 +/– | |
> SIMD? Нет, не слашал, да?
Вы не поверите, но современные компиляторы о нем тоже слышали.
| | |
| |
| |
| 6.49, Анонимоус (?), 14:37, 20/05/2015 [^] [^^] [^^^] [ответить]
| +/– |
Вообще и этим должен заниматься компилятор, если специально поставить такую задачу
| | |
| |
| 7.51, Mihail Zenkov (ok), 14:40, 20/05/2015 [^] [^^] [^^^] [ответить]
| –2 +/– |
 Я имею виду разместить весь код приложения, как это делает memtest. На C это мало реально, ввиду раздутости библиотек.
| | |
| |
| 8.85, Аноним (-), 20:46, 20/05/2015 [^] [^^] [^^^] [ответить] | +2 +/– | Вот те раз, а мужики с -nostdlib то и не в курсе В смысле, на си можно собрать ... текст свёрнут, показать | | |
|
| 7.125, z (??), 14:50, 21/05/2015 [^] [^^] [^^^] [ответить]
| +/– |
Он этим занимается аж в 0.1% случаев, о таких вещах как cache pollution-aware вообще молчу
| | |
|
|
| 5.105, bircoph (ok), 04:53, 21/05/2015 [^] [^^] [^^^] [ответить]
| +1 +/– | |
Сразу видно, что пишет человек с SIMD серьёзно не работавший.
Компиляторы, конечно, SIMD стараются применять, но отстают в успехе в разы, даже и использованием intrinsic функций. Главная проблема в том, что компилятору далеко не всегда возможно определить, где можно векторизовать код без потери в точности или скорости с учётом стоимости переключения контекста процессора между int и float.
| | |
| |
| 6.116, Аноним (-), 09:34, 21/05/2015 [^] [^^] [^^^] [ответить]
| +1 +/– | |
>переключения контекста процессора между int и float
Наверное, я отстал от жизни. Обработка типов int и float уже выполняются в разных процессах?
| | |
| |
| 7.127, bircoph (ok), 16:26, 21/05/2015 [^] [^^] [^^^] [ответить]
| –2 +/– | |
> Наверное, я отстал от жизни. Обработка типов int и float уже выполняются в разных процессах?
Не "отстал", а никогда в неё и не входил. С момента появления FPU переключение между контекстом целочисленных операций и операций с плавающей запятой было и является весьма дорогим:
https://en.wikipedia.org/wiki/Context_switch#Performance
Между прочим, это главная причина того, что ядро целиком и полностью целочисленное (если нужны вещественные числа, используется fixed-point арифметика, а она реализована на целых числах), за исключением нескольких особых случаев:
http://yarchive.net/comp/linux/kernel_fp.html
| | |
| |
| 8.147, Аноним (-), 13:45, 22/05/2015 [^] [^^] [^^^] [ответить] | +1 +/– | Уважаемый, вы упоролись Пенальти за переход между целочисленным режимом и FP бы... текст свёрнут, показать | | |
|
|
|
|
| 4.80, Нанобот (ok), 20:03, 20/05/2015 [^] [^^] [^^^] [ответить]
| +/– |
 >SIMD? Нет, не слашал, да?
вот и разработчики не слышали. или слышали, но у них не хватило наркоты, чтобы придумать, как это можно использовать для обработки http-трафика
| | |
| |
| 5.106, bircoph (ok), 04:54, 21/05/2015 [^] [^^] [^^^] [ответить]
| –1 +/– |
>>SIMD? Нет, не слашал, да?
> вот и разработчики не слышали. или слышали, но у них не хватило
> наркоты, чтобы придумать, как это можно использовать для обработки http-трафика
Зачем наркота? Тот же SSE давно используется в столь далёких от паралельных вычислений вещах, как memcpy, см. код glibc.
| | |
|
|
| 3.24, Аноним (-), 13:23, 20/05/2015 [^] [^^] [^^^] [ответить]
| +3 +/– | |
> Хорошо написанный код на СИ в общем случае не улучшишь с помощью ассемблера.
То-то все кодеки, либы шифрования, turbojpeg и прочие - вставки на асме пишут для ускорения.
Потому что как там сгенерит код сишный компилер - бабушка надвое сказала. И когда он вывалит какое-то жуткое месиво в тугом цикле, "потому что кодогенератор так решил" - знаешь, кодек с асмовыми вставками, где этот цикл вылизан покомандно живым человеком - может оказаться в 2-3 раза быстрее. Просто потому что в тугом цикле - в 2 раза меньше команд. Человек то в отличие от компилера может и подраспереться в одной локальной местности, оптимизнув по максимуму. Но писать мег кода на асме - бесполезно :). Можно запросто продуть компилятору в оптимизации использования регистров и проч.
| | |
| |
| |
| 5.29, михаил (?), 13:27, 20/05/2015 [^] [^^] [^^^] [ответить]
| –2 +/– | |
> http://www.opennet.ru/opennews/art.shtml?num=36551
Большая часть ассемблерных вставок малозначительна и не создаёт должного увеличения производительности. Часто разработчики пытаются использовать тривиальный код с надеждой увеличить скорость выполнения тех или иных действий, но при этом общий эффект подавляется другими узкими местами.
| | |
| |
| 6.83, Аноним (-), 20:43, 20/05/2015 [^] [^^] [^^^] [ответить] | +/– | Это тот случай когда мал золотник, да дорог Нет смысла ускорять код в который... большой текст свёрнут, показать | | |
|
|
| 4.37, Andrey Mitrofanov (?), 13:49, 20/05/2015 [^] [^^] [^^^] [ответить]
| +2 +/– |
> То-то все кодеки, либы шифрования, turbojpeg и прочие - вставки на асме
> пишут для ускорения.
Как видим, весь код на асме пишут для замедления.
| | |
| |
| 5.56, ram_scan (?), 15:24, 20/05/2015 [^] [^^] [^^^] [ответить]
| –2 +/– | |
> Как видим, весь код на асме пишут для замедления.
Он медленный не из-за того что на асме а из-за того что синхронный и большую часть времени катает вату в ожидании завершения операции ввода-вывода и стоит на семафорах.
Если его на сях переписать будет еще тупее по производительности.
| | |
| |
| 6.88, Andrey Mitrofanov (?), 20:50, 20/05/2015 [^] [^^] [^^^] [ответить]
| +1 +/– |
>> Как видим, весь код на асме пишут для замедления.
>что они - тормозная блоатварь.
Про блоат это ты принёс. Беспокоит размер? Сравнивал 10DVD любой из 10 архитектур Debian-а со своими ассемберными пипирками и аж задохнулся?? Твои страдания >>>-все-видят->
> Сотни батхерта обеспечены :) | | |
| |
| 7.94, Аноним (-), 21:02, 20/05/2015 [^] [^^] [^^^] [ответить]
| –2 +/– | |
> Про блоат это ты принёс.
Я всего лишь придумал как оптимизировать наброс. Троллить ассемблерщиков неоптимальными набросами - не пройдет. Они во всем оптимизацию любят.
| | |
|
|
|
| 4.78, Омномним (?), 18:31, 20/05/2015 [^] [^^] [^^^] [ответить]
| +/– |
Кодеки, шифрование, обработка изображений - это "числодробилки". Ассемблерные вставки там - это чёрные ящики, получающие буфер с данными на входе и выдающие буфер на выходе, это функции-аутисты, проделывающие большой объем вычислений, никак не общаясь с окружением.
А что такое http-сервер? Это жонглирование буферами памяти между вызовами API-шных функций работы с сетью и диском. Ну, парсер строк заголовков еще можно написать на асме, если уж руки чешутся. Но весь червер на асме это чистое рукоблудие.
| | |
| |
| 5.86, Аноним (-), 20:48, 20/05/2015 [^] [^^] [^^^] [ответить]
| +/– |
Ух ты, я вызвал приступы капитанинга. Любо-дорого смотреть, Капитаны на опеннете сегодня качественные :)
| | |
|
| 4.108, bircoph (ok), 04:59, 21/05/2015 [^] [^^] [^^^] [ответить] | –3 +/– | gt оверквотинг удален С использованием векторных инструкций не в 2-3 раза, а в... большой текст свёрнут, показать | | |
|
|
| 2.32, Kroz (??), 13:36, 20/05/2015 [^] [^^] [^^^] [ответить]
| +1 +/– | |
> Прям чудеса
Ожидаемо. Просто алгоритмы оптимизации кода в компиляторах достаточно развиты. Одна моя подделка с -O2 работала раза в 4 быстрее по сравнению с -O0.
Относительно проекта впечатления противоречивые, но склоняюсь к позитиву. С одной стороны "Зачем?", а с другой - может наконец-то девелоперы начнут ртбращать внимание а ресурсы, которые потребляет их программы, а то софт с учётом апгрейда железа тормозит точно также, как и 15лет назад.
| | |
| |
| 3.35, Crazy Alex (ok), 13:47, 20/05/2015 [^] [^^] [^^^] [ответить]
| +/– | |
Да при чём здесь оптимизации. Просто на ассемблере несколько задолбаешься делать сложную высокоуровневую логику, нужную для эффективной реализации чего-то большого. Если ты не Кнут, конечно. А то, что высокоуровневые оптимизации дают на порядки больший эффект, чем вылизывание инструкций - не секрет ни разу.
Лишнее подтверждение этому - объём бинарника. 6к - даже для ассемблера не ахти что, тем более на x86_64. То есть там наверняка всё внутри реализовано самым тривиальным образом.
| | |
| |
| 4.65, BratSinot (ok), 16:13, 20/05/2015 [^] [^^] [^^^] [ответить]
| –1 +/– |
 > Лишнее подтверждение этому - объём бинарника. 6к - даже для ассемблера не ахти что
Это как-бы мало, у остальных они за собой еще libc / stdc++ потянут, а тут только ядро нужно.
| | |
| |
| 5.68, Crazy Alex (ok), 16:48, 20/05/2015 [^] [^^] [^^^] [ответить]
| +/– |
Это не просто мало - это катастрофически мало для того, чтобы реализовать приличные структуры данных и алгоритмику
| | |
|
|
| 3.74, rshadow (ok), 17:46, 20/05/2015 [^] [^^] [^^^] [ответить]
| +2 +/– |
 > а то софт с учётом апгрейда железа тормозит точно также, как и 15лет назад
Это все сказки. Вы просто не замечаете возросших потребностей. Один графический тулкит с тенями, анимациями нажатий и т.д. чего стоит.
Что 15 лет назад по большей части никто не оптимизировал, что сейчас. Ситуация одинаковая.
| | |
|
| 2.54, Аноним (-), 15:16, 20/05/2015 [^] [^^] [^^^] [ответить]
| +/– |
чудеса будут, если он проживет столько, сколько апач например и все равно будет сливать по скорости. в данный момент сравнение некорректно
| | |
|
| 1.3, Legacy (ok), 12:11, 20/05/2015 [ответить] [﹢﹢﹢] [ · · · ]
| +5 +/– |
 Сейчас начнется очередной виток срача, в последнее время популярного на опеннете: "на чем писать сервер". В тред приглашаются специалисты младшего школьного отделения.
| | |
| |
| |
| 3.47, jOKer (ok), 14:31, 20/05/2015 [^] [^^] [^^^] [ответить]
| +1 +/– |
 CherryPy? Не, не слышал!
Tornado? Не, тоже не знаю!
Twisted? Не, тоже как-то не случилось обратить внимание...
Ну может хоть uWSGI или, прикола ради, Waitress WSGI Server? Что тоже нет?! В школу!!! Немедленно!
| | |
| |
| |
| |
| 6.72, Аноним (-), 17:26, 20/05/2015 [^] [^^] [^^^] [ответить]
| +1 +/– | |
> Хотя тот же Торнадо и сам неплохо с этим справляется
И как он на 50000-100000 коннектов?
| | |
| |
| 7.75, jOKer (ok), 17:50, 20/05/2015 [^] [^^] [^^^] [ответить]
| +/– |
Фиг знает. Я же писал постом выше, что использую как раз nginx+gunicorn.
Но люди отзываются о торнадо под нагрузкой не плохо. Хотя куда лучше отзывы о твистид. Вот, кста, интересное обсуждение, если интересуетесь http://profyclub.ru/docs/124
| | |
|
|
| 5.73, Legacy (ok), 17:46, 20/05/2015 [^] [^^] [^^^] [ответить]
| –1 +/– | |
>> И все их ставят за nginx-ом
Балансер/раздатчик статики - еще не веб-сервер. Но в школах этого не читают, увы.
| | |
| |
| 6.103, Crazy Alex (ok), 03:10, 21/05/2015 [^] [^^] [^^^] [ответить]
| +/– |
Но то, что он балансирует, и подавно не обязано быть веб-сервером - к примеру, это может быть какой-нибудь WSGI-бакэнд, или масса всего прочего, что реализовано для того же нгинкса, вплоть до прямой работы с базами данных. Можно, разумеется, спорить о терминах, но, как мне кажется, логичнее будет всё же сойтись на том, что приложение, отдающее свой контент, в том числе статический (в противовес проксированию чужого) по HTTP-протоколу, веб-сервером всё же является.
| | |
| |
| 7.104, jOKer (ok), 04:44, 21/05/2015 [^] [^^] [^^^] [ответить]
| –1 +/– | |
>WSGI-бакэнд
ИМХО, в данном случае, WSGI-бакэнд как раз и есть веб-сервер, поскольку имено он генерирует динамический контент, создает html-страницы. А вот балансировщик, даром что именно он возвращает их, веб-сервером можно назвать с большой натяжкой. Уж скорее кэширующим прокси-сервером. Да собственно, nginx, именно так (в том числе) себя и позиционирует. Официально: "обратный прокси-сервер". Конечно, он еще и полноценный веб-сервер, но для питоновых веб-приложений, его полноценность, в плане веб-сервера, глубоко до лампочки, - ибо не востребована.
| | |
| |
| |
| 9.124, Legacy (ok), 13:32, 21/05/2015 [^] [^^] [^^^] [ответить] | –3 +/– | Nginx - проксифронтенд Все что за ним стоит - бэкенд Не надо придумывать ненуж... текст свёрнут, показать | | |
| |
| 10.149, angra (ok), 14:52, 22/05/2015 [^] [^^] [^^^] [ответить] | –1 +/– |  Понятие frontend backend ортогонально к понятию web http server Если nginx общ... текст свёрнут, показать | | |
|
|
|
|
|
|
|
|
|
| |
| 2.7, Аноним (-), 12:17, 20/05/2015 [^] [^^] [^^^] [ответить]
| +2 +/– |
на сях сверхмудрый оптимизатор хорошо оптимизирует код, тогда как тут вся оптимизация лежит на программистах.
| | |
| |
| 3.9, Аноним (-), 12:20, 20/05/2015 [^] [^^] [^^^] [ответить]
| +2 +/– |
разница большая: системный вызов, например, из дерева работать скорее всего не будет.
| | |
| |
| 4.90, Аноним (-), 20:52, 20/05/2015 [^] [^^] [^^^] [ответить]
| +/– | |
> разница большая: системный вызов, например, из дерева работать скорее всего не будет.
Можно запилить RPC-интерфейс. Тогда будет!
| | |
|
| 3.13, YetAnotherOnanym (ok), 12:25, 20/05/2015 [^] [^^] [^^^] [ответить]
| –1 +/– |
 > а какая разница из чего делать системый вызов?
Ну, может быть там работа с ФС рудиментарная, и причина тормозов в этом. А из памяти - тупо взял и выстрелил, и всё.
| | |
|
| 2.11, braveduck (ok), 12:22, 20/05/2015 [^] [^^] [^^^] [ответить]
| +4 +/– |
 про файловые кеш на уровне ОС не слышали?
оно и так раздается из памяти, скорей всего, после первых запросов.
| | |
| |
| 3.43, YetAnotherOnanym (ok), 14:05, 20/05/2015 [^] [^^] [^^^] [ответить]
| –2 +/– |
Умничка. Слышал про файловый кэш на уровне ОС. А теперь следи за руками. Сервер парсит URL и маппит его в путь к файлу. После этого он просит его у ОС как файл. Должен быть готов обработать любой ответ. Нет - отдать 404, давно лежит - отдать 304, и т.д. ОС смотрит, не в кэше ли этот файл, если в кэше - отдаёт его (а это, между прочим, передача данных от ядра к пользовательскому процессу).
Если же объекты лежат в памяти самого процеса, от маппит URL в адрес, находит в своих данных его размер, время изменения и т.д., и если надо отдать - отдаёт из своей памяти.
| | |
| |
| 4.45, Andrey Mitrofanov (?), 14:27, 20/05/2015 [^] [^^] [^^^] [ответить]
| +2 +/– |
> Если же объекты лежат в памяти самого процеса, от маппит URL в
> адрес, находит в своих данных его размер, время изменения и т.д.,
Вот оно!! Надо "объекты" тож на асме писать! </это же всё решает!></и проблему php тоже>
> и если надо отдать - отдаёт из своей памяти. | | |
| 4.139, YetAnotherOnanym (ok), 20:10, 21/05/2015 [^] [^^] [^^^] [ответить]
| –2 +/– |
Хе, какой-то уязвлённый школьник минусов накидал, а возразить по делу (sendfile(2), например) эрудиции не хватило.
| | |
|
|
|
| |
| 2.21, _KUL (ok), 13:06, 20/05/2015 [^] [^^] [^^^] [ответить]
| +1 +/– |
 Может быть, потому что не только от языка и его уровня зависит, но и от кривости извилин программиста?
| | |
| |
| 3.23, Andrey Mitrofanov (?), 13:19, 20/05/2015 [^] [^^] [^^^] [ответить]
| +4 +/– |
> Может быть, потому что не только от языка и его уровня зависит,
> но и от кривости извилин программиста?
Именно поэтому. Эти их такты на гигагерцах не имеют никакого значения при миллисекундных порядках раундтрипов/коннектов. И даже при микросекундных на эзернетах.
Впрочем, мы, конечно, сочувствуем столь сложному и трудному способу получения удовольствия. За отсутствием другого результата.
//Прошлый, раз у выноси^H^H^H^Hрезателей драйвера сетевой и стека tcp в веб-сервер, было хоть удовольствие от B)перформанса.
| | |
| |
| 4.33, Mihail Zenkov (ok), 13:39, 20/05/2015 [^] [^^] [^^^] [ответить]
| –2 +/– | |
> Именно поэтому. Эти их такты на гигагерцах не имеют никакого значения при миллисекундных порядках раундтрипов/коннектов. И даже при микросекундных на эзернетах.
Энергоэффективность? Представьте маломощный arm, полностью автономный - работающий от солнечных батарей, не требующих затрат на теплоотведение из серверной.
| | |
| |
| |
| 6.38, Mihail Zenkov (ok), 13:53, 20/05/2015 [^] [^^] [^^^] [ответить]
| –2 +/– | |
> Оно бы да, но писано-то под x86_64
Это я в теории, про светлое будущее :)
На x86_64 потребление питания и тепловыделение тоже весьма зависит от нагрузки. Вдобавок появляться возможность сделать underclocking+undervolting и существенно улучшить энергоэффективность.
| | |
| |
| 7.60, Crazy Alex (ok), 15:50, 20/05/2015 [^] [^^] [^^^] [ответить]
| +/– |
Ну, я никогда не был сторонником особой оптимизации по энергоэффективности на стационарных машинах или делания чего-то тяжелого на мобильных устройствах - от смартфона до ноутбука. Первое и последнее, что вспоминается в плане реальной нужды увеличивать энергоэффективность на стационарах - майнинг. Да и не думаю я, что сколь угодно крутой веб-сервер, писанный на асемблере, даст такие уж сильные отличия по энергопотребению целой машины в сравнении с сишным сервером. И даже если даст - наверняка практически то же будет достижимо парой ассемблерных вставок в сишный код. А вот писать эффективную высокоуровневую логику на ассемблере - занятие довольно-таки дурное, вот на ней ассемблерный сервер и просядет.
| | |
| |
| |
| 9.71, клоун (?), 17:24, 20/05/2015 [^] [^^] [^^^] [ответить] | +/– | Разница в одинаково написанном коде не превышает 5 Другое дело, что каждый язы... текст свёрнут, показать | | |
|
|
|
|
|
|
|
|
| 1.15, Аноним (-), 12:40, 20/05/2015 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
На AMD64 написанный и на плюсах будет нехило работать, и даже на питоне. И проблема экономии памяти до единиц Кб там, как бы, не актуальна.
Такое для архитектуры Cortex-M3 больше пригодилось бы.
| | |
| |
| 2.20, Anonymous528 (?), 12:56, 20/05/2015 [^] [^^] [^^^] [ответить]
| +/– | |
>Такое для архитектуры Cortex-M3 больше пригодилось бы.
Ну вообще да, на всяких малых и особо малых устройства он само то.
Вангую что ребята из Калибри захотят его себе портировать.
| | |
| 2.25, Аноним (-), 13:25, 20/05/2015 [^] [^^] [^^^] [ответить]
| +/– | |
> На AMD64 написанный и на плюсах будет нехило работать, и даже на питоне.
Ога, пока рядом не запустят нжинкс и не проведут бенчмарк :)
| | |
| |
| 3.76, Legacy (ok), 17:53, 20/05/2015 [^] [^^] [^^^] [ответить]
| +/– | |
И что произойдет? Одна из первых ссылок в гуге по запросу "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."
Надо пойти поискать посвежее сравнения.
| | |
| |
| |
| 5.82, Нанобот (ok), 20:12, 20/05/2015 [^] [^^] [^^^] [ответить]
| +2 +/– | |
> Это не бенчмарк, а хрень собачья.
Свидетели Пресвятого Nginx'а обвиняют собеседника в ереси
| | |
| |
| 6.91, Аноним (-), 20:55, 20/05/2015 [^] [^^] [^^^] [ответить]
| –1 +/– | |
> Свидетели Пресвятого Nginx'а обвиняют собеседника в ереси
В неумении делать бенчи или того хуже запредельном уровне подтасовок. Засилье нжинкса в top busiest sites как бы намекает. А если бы все было как там написано, без подвохов - те ...цать процентов рынка давно были бы у node.js :P
| | |
| |
| 7.96, Legacy (ok), 22:30, 20/05/2015 [^] [^^] [^^^] [ответить]
| +/– | |
>> Засилье нжинкса в top busiest sites как бы намекает
что он отличный балансер, но бакенд за ним все равно на других языках. Что тоже как бы намекает.
| | |
|
|
|
|
|
| |
| 3.62, Аноним (-), 15:54, 20/05/2015 [^] [^^] [^^^] [ответить]
| +/– | |
> Хотя, может и Minuet'чикам тоже понравится.
А нельзя было написать "пользователям/разрабам MenuetOS"?
А то при чтении " Minuet'чикам" буква u как то теряется и пропадает ;)
| | |
| |
| 4.92, Аноним (-), 20:56, 20/05/2015 [^] [^^] [^^^] [ответить]
| +/– | |
> А то при чтении " Minuet'чикам" буква u как то теряется и пропадает ;)
Зато так суть отражается даже точнее :)
| | |
|
|
|
| |
| |
| 3.93, Аноним (-), 20:57, 20/05/2015 [^] [^^] [^^^] [ответить]
| +/– | |
> написано GAWK-е же. Уже. </переписался>
Есть еще на шеллскриптах.
| | |
| |
| 4.117, Andrey Mitrofanov (?), 09:38, 21/05/2015 [^] [^^] [^^^] [ответить]
| +/– |
>> написано GAWK-е же. Уже. </переписался>
> Есть еще на шеллскриптах.
М-м-м, кстати да. Надо искать язык, на котором веб-сервера *нет* и его всё ещё надо написать.
BF #1, ...
| | |
| |
| 5.122, PnDx (ok), 12:41, 21/05/2015 [^] [^^] [^^^] [ответить]
| +/– |
 Любой, практически, спец. назначения. Из того, с чем как-то сталкивался:
COBOL и производные
FORTRAN
PL/M-образные или на чём там сейчас ПЛИСы программируют (поправьте, кто в теме). Хота, возможно, кто-то уже осилил httpd в виде хардварной закладочки.
LISP, вероятно
| | |
|
|
|
|
| 1.46, Kodir (ok), 14:29, 20/05/2015 [ответить] [﹢﹢﹢] [ · · · ]
| –2 +/– |
 > тесты производительности показывают существенное отставание
Да не вопрос! Неужто из асма нельзя задействовать весь тот спектр костылей, что сделали на Сях?? Всякие неблокирующие сокеты, мемкэши, упреждающая выборка ресурсов...
Но я всё равно не одобряю АСМ - как его ни комментируй, как ни оптимизируй, всё-равно код словесно будет раздут - сопровождение такой портянки будет нереальным, а это уже существенный минус для популяризации сервера. Да и в самом веб-сервере существенное время тратится далеко не на принятие соединения, а на ДВИЖОК страницы.
| | |
| |
| 2.61, Аноним (-), 15:52, 20/05/2015 [^] [^^] [^^^] [ответить]
| +2 +/– | |
> Да не вопрос! Неужто из асма нельзя задействовать весь тот спектр костылей,
Можно, только нужны и соответсвующие знания кроме книжки "ассемблер для чайников", таблички там интыловские и т.д. ;)
Т.е. просто "питон тормозит, мы напишем на си, на си тормозит, перепишем на асме! Теперь должно летать по определению!!" не прокатывало еще эдак лет десять назад.
Я конечно могу и ошибаться, ибо глянул по быстрому - но нигде не заметил выравнивания в памяти сонстант и буферов - а это уже, как бы, показатель.
| | |
| 2.63, Crazy Alex (ok), 15:55, 20/05/2015 [^] [^^] [^^^] [ответить]
| +/– |
Ну вот ты сам и ответил, почему нельзя задействовать - потому что эту адову простыню мало кто сможет написать/сопровождать.
| | |
|
| 1.52, Аноним (-), 15:03, 20/05/2015 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
Сейчас стало модно доказывать корректность программ, например с помощью Coq proof assistant. Код маленький, можно попытаться доказать. Для Coq кто-то уже написал ассемблерный модуль (вот только не помню amd64 или i386).
| | |
| 1.66, BratSinot (ok), 16:16, 20/05/2015 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
А вообще странные, в одном и том-же коде, разница в пару строчек:
> mov al, 0x0
<...>
> xor rdx, rdx ; zero other half
Насколько я помню xor есть для ?l / ?h регистров.
| | |
| |
| 2.70, клоун (?), 17:18, 20/05/2015 [^] [^^] [^^^] [ответить]
| –1 +/– | |
xor работает для любых регистров.
mov al,0 меньше по размеру.
| | |
| |
| |
| 4.126, z (??), 14:55, 21/05/2015 [^] [^^] [^^^] [ответить]
| –2 +/– | |
> но по времени выполнения mov дольше, чем xor
учим матчасть: mov reg,const обрывает для планировщика (не слишком новых cpu) зависимость от предыдущего значения reg, что увеличивает глубину внеочередного исполнения, т.е. скорость
| | |
|
|
|
| |
| |
| |
| 4.136, Аноним (-), 18:40, 21/05/2015 [^] [^^] [^^^] [ответить]
| +/– | |
> Конпелятор ЯВУ, чего там.
Можно просто яву. Которая жаба. Если JVM переписать на ассемблере - "ява не тормозит" приобретет новое звучание :)
| | |
|
|
|
| 1.100, Аноним (-), 01:12, 21/05/2015 [ответить] [﹢﹢﹢] [ · · · ]
| +1 +/– |
Зачем? Изначально и намеренно непортабельное, очевидно нерасширяемое, скорее всего небезопасное и возможно более медленное чем аналоги на C/C++ убожество.
| | |
| 1.110, Аноним (-), 05:51, 21/05/2015 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
Предлагаю поделить все open source проекты на общепризнанные категории, дабы не терять время на откровенный треш. Прямо на кодохостинги встроить текущие показатели с историей и ещё сайтик сделать, общая база.
Если в базе проекта нет, значит это вообще недопиленный мусор, брошенный на первых стадиях разработки, чего тоже навалом.
| | |
| |
| 2.111, бедный буратино (ok), 06:45, 21/05/2015 [^] [^^] [^^^] [ответить]
| +/– |
 см. в репозиториях
если есть во всех репозиториях - значит, крутая вещь. если в репозиториях некоторых дистров - значит, достойная. :)
| | |
| |
| 3.112, бедный буратино (ok), 06:45, 21/05/2015 [^] [^^] [^^^] [ответить]
| –1 +/– |
> см. в репозиториях
> если есть во всех репозиториях - значит, крутая вещь. если в репозиториях
> некоторых дистров - значит, достойная. :)
впрочем, лично я кроме репозиториев, ничем не пользуюсь (за очень крайне редкими исключениями). поэтому, нет в Debian и OpenBSD = для меня не существует :)
| | |
| |
| 4.137, Аноним (-), 18:41, 21/05/2015 [^] [^^] [^^^] [ответить]
| +/– | |
> поэтому, нет в Debian и OpenBSD = для меня не существует :)
И эти люди запрещают нам ковыряться в носу и что-то там лечат про стереотипность...
| | |
| |
| 5.146, б.б. (?), 10:44, 22/05/2015 [^] [^^] [^^^] [ответить]
| +/– |
>> поэтому, нет в Debian и OpenBSD = для меня не существует :)
> И эти люди запрещают нам ковыряться в носу и что-то там лечат
> про стереотипность...
тебе кто-то запрещает ковыряться в носу?
и причём тут стереотипность?
| | |
|
|
|
|
| 1.130, none7 (ok), 18:18, 21/05/2015 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
 Что там оптимизировать можно вообще? Всё, что делают веб-сервера работая со статикой, это переадресуют url из запроса в функцию ядра open. Данные из файла в сокет пишет уже ядро. Может уже и шифрованные потоки так отправляют, по крайней мере блочная криптография в ядре уже есть.
| | |
| |
| 2.138, Аноним (-), 18:44, 21/05/2015 [^] [^^] [^^^] [ответить]
| +/– | |
> это переадресуют url из запроса в функцию ядра open.
Ну тогда уж sendfile() - более интересная "функция" ядра :).
> по крайней мере блочная криптография в ядре уже есть.
Да и не только блочная. Ядро нынче умеет всякие там подписи модулей при загрузке проверять, например, если это надо.
| | |
|
| 1.141, none7 (ok), 21:31, 21/05/2015 [ответить] [﹢﹢﹢] [ · · · ]
| +2 +/– | |
Угораздило же меня глянуть код. КАЖДАЯ функция, включая системные вызовы обёрнута в пару макросов stackpush stackpop -_-. И почему это gcc не догадывается так делать? Вообще без нужды верхнюю часть регистра не трогает, ведь 8 64-битных Push нам совсем ничего не стоят.
Кстати вычисление 'Content-Type' из расширения и сравнение заголовков производится прямым перебором. Естественно о не чувствительности заголовков к регистру никто не подумал. В общем код сильно хуже того, что можно получить даже из gcc -O1. Уж не говоря об архитектурных ошибках.
| | |
| 1.144, XoRe (ok), 00:29, 22/05/2015 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
 > обработка кодов возврата (200, 206, 404, 400, 413, 416)
Т.е. 304 оно не умеет.
Хотя в принципе, там сложная логика - нужно анализировать метаданные файла и заголовки запроса клиента.
Но без этого его даже для фофана не стоит использовать.
> выдача корректного заголовка "Content-type" для файлов xml, html, xhtml, gif, png, jpeg, css, js
Т.е., как в nginx, вынести в отдельный файл mime.types они не захотели.
Вообще, как здесь уже заметили, пока это отличный вариант для руткитов и бекдоров.
| | |
|
