Какие есть живые opensource проекты где экономят наносекунды в юзерспейсе?

DPDK

Толсто.

все, которые написаны не на питоне? а, нет, тут речь не о минутах.

любые, где не экономят ОЗУ, то есть, 99,9% проектов.

Мощность современных процессров позволяет писать на интерпретируемом и не думать об этом. А тяжёлые задачи (те что на минуты/часы) менее тяжёлыми от переписывания на си не станут, экономия будет маргинальной.

Мощность современных процессров позволяет писать на интерпретируемом и не думать об этом.

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

сколько данных на единицу времени способен переварить твой костыль? в 10-40 раз меньше, чем аналог на С/С++? а в чем плюсы такого подхода для бизнеса? в том, что нужно тратить в 10-40 раз больше средств на железо? а зарплата у средней веб-мартышки сильно меньше, чем у крестовика? зачем ты нужен вообще, в чем твоя польза?

Решение далеко не всех задач упирается в эффективность байтоёбства. При этом стоимость разработки растёт экспоненциально, как и время на неё необходимое. И это мы ещё не считали трудность нахождения нормальных кадров (и их стоимость).

Увы, встречаются такие дегенераты, которые считают пхытончик и прочую маргинальщину не хуже нормальных ЯП. А нормальных ЯП немного. Точнее, он один - С!

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

Какие ЯП ты подразумеваешь? На каком языке можно экономить наносекунды да еще и юзерспейс писать? А главное для чего?

Ffmpeg и mesa первыми приходят на ум.

Где там экономят наносекунды?

Есть 3 вида оптимизации: do less, do less often, do faster.

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

hft фремворки на гитлабе полно

Смотри проекты suckless.org

Ну например те же sbe парсеры считают, правда сотни наносекунд, ну всё что до десятков us - наверное пойдёт.

Можно ссылку на один, что бы ключевые слова для поиска понять?

Не везде можно do less. Есть совершенно деревянные области, в основном всякие шлюзы под 50G железо, кирнел бипасы, вычисления на gpu(тут уже спорно) и т.п. Вопрос, чего из этого живьём в опенсурсе есть, кроме dpdk и pf_ring.

Сразу после ссылок на бенчмарки, где эти самые наносекунды кто-то, зачем то, считает на фоне ui i/o и дефолтного планировщика.

О! Кодеки же, точно, спасибо :)

кирнел бипасы

Что это?

Это и всякие корутины с планировщиками в юзерспейсе, которыми яндексоиды на каждой конфе нудят.

кроме dpdk и pf_ring

https://github.com/luigirizzo/netmap

Эти слова читаются «кернел байпасс».

Май инглиш из вери и бед.

А ты участник или сочувствующий? Есть у них какие то бенчмарки и инструкции по профилированию?

Кстати, компиляторы (C, C++)

А точно? Там вроде всё в дисковое i/o упирается и пока ждёшь на чём то в духе select, по идее можно кучу дел провернуть?

Ты головой не ударился? При компиляции диска никто не ждёт, особенно если проект большой. Ну нет, я понимаю, что какой - нибудь ойдевять будет ждать диска на 5400 рпм. Но в остальном всё совсем не так.

Если в один поток, то наверное, а если это не конпиляние в вакууме, то почему-то рамдиск даёт прирост в скорости сборки до 50%. Хотя, возможно тут дело скорее в линковщике.

В любом случае, было бы интересно на бенчмарки посмотреть, если они есть конечно.

ffmpeg должен экономить по идее.

Я в своей Gentoo не вижу вообще причин использовать RAM-диск. Может потому, что я использую pipe? Основная проблема возникает при линковке, и на время компиляции (в случае с особенно большими проектами) ну не то, чтобы сильно влияет. Хотя нет. Наверное, всё же зависит от компилируемого софта и мощности тех или иных компонентов в компиляющей тачке?

на бенчмарки посмотреть

Как ты себе представляешь? У кого-то атом с ССД, у кого-то гиперпень ещё на древнем IDE, у кого-то двухпроцессорный сервер на Xeon E5, кто-то вообще сидит на EPYC с NVMe...

Какая разница, смотришь результат A на заданном освобождённом ядре, профилируешь, оптимизируешь, смотришь результат B. Для этой железки стало лучше? Стало - коммитишь, дальше на CI или в ручную на референсном железе проверяются результаты и билд либо проходит либо нет.

Ну это в идеальном мире, который не факт что может себе позволить средней руки опенсурс.

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

А что они делают?

Кодируют/декодируют видео. Там большая нагрузка на проц => всякий дикий изврат + асм вставки.

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

Учи матчасть. Под конкретную железку оптимизирует компилятор, а не твои кривые руки и ассемблерные вставки. Твоя задача - оптимизация алгоритмов, т.е. do less. Если ты где-то пишешь приложение под конкретную железку - тут можешь, конечно, взяться за асм и не доверять компилятору. В остальных случаях вся оптимизация под железо - уменьшение размера машинного кода и оптимизация алгоритмов, другого как бы и нет.

Я как раз спрашиваю про юзерспейс, о чём и написал в заголовке топика :)

ОП спрашивает вообще какую-то дичь.

Я бы сказал это относится скорее не к проекту, а разработчику. Умеет - улучшает понемногу. Будь то bash, GCC, GHC или ядро.

Да да, особенно это относится к коду общего назначения, где просто так даже avx не заюзаешь, что бы ретроградов не обидеть которые сидят на чём-то окромя генты.

Если ты имеешь относительный прирост на одной x86 машине, то есть немалая вероятность, что ты получишь такой же или лучше прирост на другой. Я и не говорил про оптимизацию под конкретную железку, только про то, что перед принятием кода в мастер надо прогнать бенчмарки на референсном железе что бы не было регрессии уровня у автора патча стало быстрее, зато в 99% типовых случаев стало медленнее.

Хорошо. Оптимизировал ты свой софт под i686. Что дальше?
Либо занимаешься дистрибуцией _разных_ бинарников под _разные_ архитектуры (я щас тока про x86) либо забиваешь на это. Максимум ты можешь затребовать наличие каких-то инструкций у процессоров и отсечь остальные. А всякие задроты с гентой и слакой соберут софт сами так, как им надо.

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

или лучше

или хуже, хехе

avx не заюзаешь

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

Хорошо. Как ты будешь наносекунды в моем юзерспейсе экономить? Кроме как do less? В чём вопрос то? Примеры оптимизации do less? Так это исключительно эффективность алгоритма и в некоторых случаях «умность» компилятора. Т.е. вопрос вообще как бы странен сам по себе. Тебе нужны максимально эффективные вариации алгоритмов? Каких алгоритмов?

Кто же спорит, что можно. Беседа о том, что если горячей оказалась ассемблерная вставка это всё равно не показатель, что переписать надо конкретно этот код, как и, что там нужно так низко пасть.

Мне нужно ПО в котором необходимы оптимизации указанного уровня т.к. это напрямую повышает качество этого ПО, требуемое пользователем. Т.е. чем быстрее отработал горячий участок кода в юзерспейсе, тем лучше работает ПО. I/O с лэйтенси выше десятков us понятно идёт лесом. Люди которые поняли о чём я - накидали вариантов, похожих на правду. Почему компилятор похож на правду - потому что, там i/o в памяти происходит. Почему dpdk и иже с ними подходит - потому то их используют с 10G+ железками, в том числе и с IB, там порядка 1-10us лейтенси на пакет притом в 99.5% случаев. Почему подходят mesa и ffmpeg надо ещё понять, но по идее должны подходить по той же причине, что и компиляторы.

А тебе видимо хочется просто подискутировать но ты не в теме, поэтому пытаешься загнать какую то свою тему :)

Т.е. чем быстрее отработал горячий участок кода в юзерспейсе, тем лучше работает ПО.

Что-то я не могу вспомнить ничего кроме hiload решений которым такое требуется. Можешь хоть намекнуть что за софт.

Если не этот код, то у тебя остаются do less often и do less. По-моему тебя в оп в кучу проекты экономящие переключения контекста и сбросы кешей и те, что утилизируют алгоритмические хаки (платформозависимые как правило). Возможно ты ищешь LWKT — это как раз про экономию времени. И кажется в оп у тебя костылики для NPTL и попытки решать проблемы зелёными тредами — в таком случае сюда же можно и icedtea.

Э-dick опять бояры перебрал …

Ну я наблюдал такие упражнения в парсерах бинарных протоколов типа FAST или SBE, да хотя бы тот же protobuf.