LINUX.ORG.RU

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

 ,


1

1

Ну ещё не embeded что бы.

Пока набралось:

  • kernel bypass dpdk, pf_ring, netmap
  • Кодеки ffmpeg
  • Возможно, компиляторы для c и c++
  • Программное ускорение графики mesa
  • Реализации green threads и прочие способы отжать управление у системного планировщика (реализации LWKT, NPTL)

Ответ на: комментарий от anonymous

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

anonymous ()
Ответ на: комментарий от anonymous

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

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

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

anonymous ()
Ответ на: комментарий от anonymous

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

anonymous ()
Ответ на: комментарий от anonymous

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

anonymous ()
Ответ на: комментарий от anonymous

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

anonymous ()
Ответ на: комментарий от beastie

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

onhydro ()
Ответ на: комментарий от onhydro

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

Woolf ()
Ответ на: комментарий от Woolf

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

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

onhydro ()
Ответ на: комментарий от onhydro

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

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

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

Woolf ()
Ответ на: комментарий от Woolf

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

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

onhydro ()
Ответ на: комментарий от crutch_master

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

anonymous ()
Ответ на: комментарий от onhydro

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

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

Woolf ()

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

anonymous ()
Ответ на: комментарий от Woolf

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

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

onhydro ()
Ответ на: комментарий от onhydro

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

Woolf ()
Ответ на: комментарий от onhydro

или лучше

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

avx не заюзаешь

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

anonymous ()
Ответ на: комментарий от onhydro

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

Woolf ()
Ответ на: комментарий от anonymous

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

onhydro ()
Ответ на: комментарий от Woolf

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

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

onhydro ()
Ответ на: комментарий от onhydro

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

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

timdorohin ★★★ ()
Ответ на: комментарий от onhydro

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

anonymous ()