linux-pf vs performance

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

Вопрос: это нормально или у меня какая-то аномалия?

Это нормально.

Почему ты ожидал повышения производительности по UBENCH? Патчсет не про это, а про «отзывчивость», что-то там с гибернацией и прочим. Посмотри состав патчсета.

А производительность на халяву одинаково для всех получить действительно не выйдет, анонимус выше верно сказал.

А у меня 18 см.

linux-zen и linuz-pf ориентированы изначально на быструю отзывчивость системы, никак не на скорость её.

Кратко и ясно, за счёт снижения throughput скорости работы с дисками, увеличивается отзывчивость системы.

Лишь один 18 см? Должно быть - две штуки.

Больше, чем нужно — не нужно.

Бэкап, дублирование.

Без фотографии с линейкой на фоне лора не засчитывается. :)

Может, тебе ещё чтобы макбук в руках был?

как у doubledickdude?

Не в руках, его же вертеть надо.

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

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

Чем меньше частота переключения - тем больше времени отдается процессу, соответственно он быстрее успеет навыполнять.

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

А если хочешь добиться производительности в бенчмарках - компиль собственное ядро под свою архитектуру, убирай оттуда все лишнее, и выставляй таймер на 100 Hz.

таймер на 100 Hz

Это плюсую, из всего что проверял единственное давало прирост отличимый от погрешности.

Дык потому что ты правильно измеряешь производительность.

А вообще в никсах с этим туговато, и не в последнюю очередь это вина следования KISS'у. Один процесс выполнит 100 задач быстрее, чем 100 процессов одну задачу. Это особо заметно, когда у тебя низкопроизводительное железо, например MIPS-проц в IP-камере.

А если хочешь добиться производительности в бенчмарках - компиль собственное ядро под свою архитектуру, убирай оттуда все лишнее, и выставляй таймер на 100 Hz.

Ога, лишние пару попугаев. Тогда уж в сторону cgroups смотреть. Хотя, мне проще под компиляцию включать другой планировщик, в остальных случаях я предпочитаю плавность системы

Всем здрасте. У меня arch

Сочувствую, но это лечится.

А вообще в никсах с этим туговато, и не в последнюю очередь это вина следования KISS'у.

Всё же спорный момент. Как я понимаю, 100 идеально вылизанных программ всё же должны отработать быстрее, как минимум за счёт более отлаженного кода и экономии тактов.
В конце концов две параллельные задачи - два параллельных процесса, которые могут работать на разных ядрах, в то время, когда не все программы умеют многоядерность.
А вот переключение между программами и обмен данными - интересный момент.

Вероятно, тормоза на старых ПК не из-за KISS, а из-за раздутого ядра и софта? К примеру остро ощущалось падение производительности при переходе с Debian 6 на Debian 7.

Поправьте, где не прав. Не силён в этой области.

Ну...Вы немножко в неравные условия поставили эти две чаши весов. 100 идеально вылизанных программ не должны отработать быстрее чем 1 идеально вылизанная. Время на запуск, все дела. Кстати экономии тактов не будет, поскольку на подготовку запуска другой программы - они тоже нужны, равно как и создание окружения.

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

В linux-pf еще есть смысл?

google://в+чём+смысл+жизни

Что ты хочешь, чтобы я тебе ответил?

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

Вот это я и хотел узнать. Спасибо.

Но ведь именно благодаря KISS мы сегодня имеем ОС *NIX такими, какие они есть. Имеем мощнейшую консоль!
Я вас правильно понимаю, что более удачная идея всё скидывать в либы и вызывать функции для выполнения задач, чем плодить программы и вызывать их? При этом остаётся возможность централизованно вылизывать код либ, повышая эффективность сразу всех программ, использующих эту функцию.

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

ЛОР познавательный...

Вот что-что, а такого я не ожидал...

Если вы под мощнейшей консолью подразумеваете не принцип работы терминала, а набор утилит, то с вами не соглашусь. На 90% их все, заменяет один единственный busybox, и KISS становится не нужен :)

Разделение программы не плохо, а даже отлично. Я рад что многие программы делятся на маленьких функциональных демонов, и ГУИ к ним. Благодаря этому, программы можно запускать на слабых устройствах, и они будут кое-как работать, а можно даже управлять ими с других.

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

И да, чем меньше вызовов - тем лучше. Это очень хорошо можно понять, когда сталкиваешься с программированием на убогих девайсах :)