LINUX.ORG.RU

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

 ,


1

1

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

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

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


Последнее исправление: onhydro (всего исправлений: 3)

Толсто.

anonymous
()

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

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

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

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

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

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

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

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

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

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

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

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

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

anonymous
()

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

Deleted
()

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Deleted
()

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

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

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

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

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

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

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

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

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

или лучше

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

avx не заюзаешь

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

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

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

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

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

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

Мне нужно ПО в котором необходимы оптимизации указанного уровня т.к. это напрямую повышает качество этого ПО, требуемое пользователем. Т.е. чем быстрее отработал горячий участок кода в юзерспейсе, тем лучше работает ПО. 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
()
Ответ на: комментарий от timdorohin

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

onhydro
() автор топика
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.