Сейчас -- да

Нутак если надо парсить протокол то это не выполняется

а что там за сложности?

Сейчас -- да

ну то есть по делу ты ничего сказать не можешь

сокет в асинхронном режиме генерирует два типа событий - готовность на чтение и готовность на запись

this ^

и неважно, что на входе

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

ну, на самом деле там чуть интереснее.

камушки емнип нынче умеют парсить протокол на linerate не напрягаясь

писаться будет только тогда, когда сокет готов

ну, на самом деле там чуть интереснее.

ну, я упрощаю

поэтому причины фейспалма и не вижу

камушки емнип нынче умеют парсить протокол на linerate не напрягаясь

это если протокол не придумали дебилы.

оно так и работает

как я написал

это если протокол не придумали дебилы.

я про http1

на сетевом он работает

вот это.

а что, есть ещё какие-то протоколы? ?

я про http1

так там ещё сверху могут навернуть. тот же гребаный multipart-formdata

вот это.

то есть нельзя epoll на udp-сокет? почему вдруг?

на запись асинхронную

швыряем данные из кучи источников в сокет асинхронно, а отправляются датаграммы по мере возможности

то есть нельзя epoll на udp-сокет? почему вдруг?

нет. речь о том, что epoll не обязательно на сокет.

нет. речь о том, что epoll не обязательно на сокет.

а, так это-то очевидно, я применительно к сети говорил

я просто думал, что это очевидный факт и его не надо писать :)

вообще, кардинально ситуацию с производительностью может исправить переделка апи между ядром и юзерлендом.

но на это мало кто пойдёт.

Почему же. Пытаются libaio

Почему же. Пытаются libaio

это не то =(

вообще, кардинально ситуацию с производительностью может исправить переделка апи между ядром и юзерлендом.

а скажи ещё раз "кардинально". так редко вижу это.

это не то =(

А что ты имеешь в виду ?

вообще, кардинально ситуацию с производительностью может исправить переделка апи между ядром и юзерлендом.

а что ты думаешь про SDN и OpenFlow?

Vmsplice ?

вообщем, нам надо иметь возможность в epoll добавить пачку fd с соответствующими масками.

там как раз на уровне модуля ядра логика реализована

ну и из epoll получать пачку сразу

вообщем, нам надо иметь возможность в epoll добавить пачку fd с соответствующими масками.

Нахуа. Маски можно не менять вобще. Для этого есть epollet

а, вру. сейчас epoll_wait возвращает пачку событий.

а, вру. сейчас epoll_wait возвращает пачку событий.

Всегда так было

Нахуа. Маски можно не менять вобще. Для этого есть epollet

ну так ты всегда читаешь из сокета? ))

Ты не понял. Единожды сообщив что в сокете есть данные -- ядро не будет больше теребонькать пока я не вычитаю всё

Грубо

Ты не понял. Единожды сообщив что в сокете есть данные -- ядро не будет больше теребонькать пока я не вычитаю всё

это зависит от уровня чтения

Это EPOLLET

есть edge-triggered, есть level-triggered

Ты не понял. Единожды сообщив что в сокете есть данные -- ядро не будет больше теребонькать пока я не вычитаю всё

эээ... а если придут новые данные?

есть edge-triggered, есть level-triggered

он про lt

эээ... а если придут новые данные?

Всеравно не будет. Прочитай плиз про еполлет

тьфу, про ET

тьфу, про ET

ну я понял, просто указал, что это не единственный вариант :)

Всеравно не будет. Прочитай плиз про еполлет

ну, это часть проблемы. ещё надо расширить writev/readv до нескольких fd

ну, это часть проблемы. ещё надо расширить writev/readv до нескольких fd

еще скажи - реализовать это как векторную операцию на чипе сетевухи :)

ну, это часть проблемы. ещё надо расширить writev/readv до нескольких fd

О. Эт тема. Для удп сдлали sendmmsg и это сильно улучшило дела

О. Эт тема. Для удп сдлали sendmmsg и это сильно улучшило дела

угу. тот же батчинг, что во всяких dpdk/netmap

ну, это часть проблемы. ещё надо расширить writev/readv до нескольких fd

И да. Такой интерфейс по сути называется нетлинксокет. Где вместо сисколлов шлешь данные со структурами типа джсон по смыслу.

И там есть memory-mapped io. Сечешь о чем это я ?

эээ

пойду почитаю )

Сейчас нетлинксокет используется для всякой хери

Почему б не всунуть туда вызов сисколлов какгбы -- не знаю

пойду почитаю )

Например работа с таблицей маршрутов идет через нетлинксокет

Почему б не всунуть туда вызов сисколлов какгбы -- не знаю

то есть чтобы epoll возвращал тебе сразу вектор событий и писать ты тоже мог вектор?

Например работа с таблицей маршрутов идет через нетлинксокет

это я знаю.

то есть чтобы epoll возвращал тебе сразу вектор событий и писать ты тоже мог вектор?

Да. Наверно. Смысл в чем. Сисколлы ограничены в количестве передавамых параметров. Когда не влезает -- начинают придумывать структуры и массивы типа poll.

А в нетлинксокете все уже придумано в плане структур

дело даже не в этом

а в количестве операций, которые можно сделать за 1 сисколл

а в количестве операций, которые можно сделать за 1 сисколл

Именно.

а в количестве операций, которые можно сделать за 1 сисколл

+

В нетлинксокете ты сам волен придумывать структуру

Там есть массивы и вложенности

Аля джсон

Тока все бинарное понятно

другое дело, если этот векторный сисколл будет выполняться дольше, чем n обычных - будет фигня

Говорят, парсинг этой. Труктуры адски быстрый. Пожтому не должно. И будет таки выгода от пачечности

У меня на гитхабе есть nltrace он позволяет трейсить проги не написанные через libnl3. Очень ограничено конечно. Но уже коечто

Давно писал. Не забрасывайте какашками

Но оно работает

ну, про библиотеки я говорю в рамках своей сферы деятельности - в го для нее просто нет ничего

Ну так ты понимаешь что фраза "под го нет библиотек" и "под го нет библиотек для дата анализа" это две разных фразы и подмена понятий это не есть хорошо?

Ну так ты понимаешь что фраза "под го нет библиотек" и "под го нет библиотек для дата анализа" это две разных фразы и подмена понятий это не есть хорошо?

так я и писал мое субъективное мнение, почему мне не нравится го и почему я сейчас не буду его использовать

кому-то он может нравится и решать его задачу - на здоровье

Да ну уж ладно. А у кого быстрее ? И полностью по рфц при том ?

у h2o picohttpparser - либа на сях, оптимизации на асме, быстрее чем у nginx + есть еще патчи задействующие avx2

более того, ты не поверишь, но я выше в чате защищал го

у h2o picohttpparser - либа на сях, оптимизации на асме, быстрее чем у nginx + есть еще патчи задействующие avx2

Ого. У нгинкса просто конченный автомат написан руками

Хм. А нодеджсники взяли парсер именно у нгинкса, емнип

Но им же и для малинки надо.

у h2o picohttpparser - либа на сях, оптимизации на асме, быстрее чем у nginx + есть еще патчи задействующие avx2

там ещё им кто-то патчи засылал, дающие ускорение где-то в 1.5 раза

у picohttpparser одна проблема, как я вижу - его вряд ли возьмут в ядро какого-либо языка

потому что он заточен под конкретные платформы и архитектуры проца

разве нет?

там хитрые SSE-инструкции он раскладывает

А там нет чтоли с выключенными оптимизациями ?

Тоесть на голом си

нинаю

но вообще в этом и суть

Темпестники написали сами. Тоже с авэикс

он использует магию современных инструкций, чтобы быстро все обрабатывать

там ещё им кто-то патчи засылал, дающие ускорение где-то в 1.5 раза

как раз на avx2 клаудфлейр куски переписывали, но они там посрались с автором по поводу идеоматичности их кода

https://github.com/h2o/picohttpparser/pull/10

А там нет чтоли с выключенными оптимизациями ?

есть

И с ними хуже или лучше нгинкса ?