fxd: кодирование можно реализовать с помощью NVidia (c) CUDA(tm) - http://ru.wikipedia.org/wiki/CUDA

r0mik (31.12.2009 18:29:25)

Re: Кодируете видео? С BFS вы сэкономите время!

Плюсую. Сам ощутил превосходство BFS недели три назад. Те кто жмут с x264 на .31 ведре ощутят ещё сильнее, ибо там в CFS была регрессия, ЕМНИП.

shahid (31.12.2009 18:32:04)

Re: Кодируете видео? С BFS вы сэкономите время!

Поставил zen-ядро из AUR, врубив в конфиге по дефолту BFS и BFQ. Заметил, что после обычного .31 ядра x264 стал жать быстрее. Тормоза при io исчезли полностью. Рекомендую.

shahid (31.12.2009 18:37:25)

Re: Кодируете видео? С BFS вы сэкономите время!

OpenCL, ибо переносимее.

shahid (31.12.2009 18:43:07)

> OpenCL, ибо переносимее.

эмм... ну да, то есть побоку - главное что не vdpau, который только для просмотра))

r0mik (31.12.2009 18:45:47)

работает. собирал kernel26-ck немного правил конфиг, HIGHMEM64G=y НУ и хедеры не установились, в ауре уже обсудили.

>При всем уважении, выигрыш какой-то очень маленький.
Если только за счёт планировщика - то огромный.

grim (31.12.2009 18:57:53)

Да я вкурсе, что у CUDA и VDPAU -- разные области применения. И vdpau в данном случае я имел в виду, именно как технологию вывода (декомпрессию, decoding).

Что касается технологии CUDA, то реализация оной врядли когда-нибудь будет распространена среди опенсурса, кроме как в виде патчей (см. aircrack) или проектов созданных для обоснования того, что это действительно работает (см. pyrit). Вышесказанное выше -- моё имхо, сам я за opencl, но к сожалению, мои познания не позваляют мне рассуждать о степени готовности к применению первого или второго, хотя и первое и второе давно уже так или иначе реализуются, да.

>В одном арче нет проблем с кодеками, что-ли? Читаю тут комменты про несчастных убунтоидов, мандроводов и прочих любителей известных дистров, и недоумеваю - у меня все из коробки ставится в съедобном виде.
в gentoo нет и не было.

prizident (31.12.2009 19:03:35)

> В одном арче нет проблем с кодеками, что-ли? Читаю тут комменты про несчастных убунтоидов, мандроводов и прочих любителей известных дистров, и недоумеваю - у меня все из коробки ставится в съедобном вид

в убунте тоже все отлично. по крайней мере с проблемами не сталкивался еще.

isden (31.12.2009 19:05:30)

Текс, нужно будет собрать.
В новый год с новым планировщиком =)

JN (31.12.2009 19:12:40)

захотелось еще раз проверить этот BFS..
кодировать видео не пробовал, потому как не интересно мне это.
при работе в одном только ФФ создается такое впечатление, будто на фоне ворочается еще что-то тяжелое и неповоротливое... скролл какой-то тормозной, бОльшие тормоза при открытии новых и тяжелых табов...
с не совсем десктопной точки зрения - cacti локальный на самой "жирной" странице (18 графиков) раньше отрисовывал их не более секунды (графики не кешируются, то есть пересоздаются при каждом рефреше), а теперь секунды 2-3, а то и 4...
c2d t7500, 2gb, 2.6.32-zen3

мне лично и даром не нужна такая "чудо-производительность"((

r0mik (31.12.2009 19:18:30)

>Те кто жмут с x264 на .31 ведре ощутят ещё сильнее, ибо там в CFS была регрессия, ЕМНИП.

Не совсем так, регрессия была гораздо раньше:
http://ck.kolivas.org/patches/bfs/old/epicmakej4.png

14% отставания в одном из тестов -- невысокая плата за универсальность и переносимость. Это при том, что во многих других планировщики ведут себя на равных.

ttnl (31.12.2009 20:10:40)

http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=f...

феерично!

psv1967 (31.12.2009 20:18:54)

>14% отставания в одном из тестов -- невысокая плата за универсальность и переносимость. Это при том, что во многих других планировщики ведут себя на равных

пральна, лишний нагрев/выбросы атмосфере не помешают

frame (31.12.2009 20:43:44)

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

ttnl (31.12.2009 21:00:07)

>Ты когда-нибудь пробовал заниматься поддержкой ядра?

т.е. усилия важнее результата? тогда неудивительно, что код анестезиолога работает лучше программистов, мучающихся за деньги :D

frame (31.12.2009 21:22:15)

Важен как раз результат. Лучше хорошо поддерживать 1млн. строк кода, чем плохо 2млн. кода

ttnl (31.12.2009 21:26:07)

>Важен как раз результат. Лучше хорошо поддерживать 1млн. строк кода, чем плохо 2млн. кода

Если учесть, что код BFS меньше CFS - то таки да! :-D

frame (31.12.2009 21:27:47)

> http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=f...

> феерично!

Что ты этим хотел сказать?

Led (31.12.2009 21:28:35)

Ещё надо учесть, что BFS плохо работает с NUMA и заточен под нужды десктопа. Поэтому CFS выкинуть не удасться.

ttnl (31.12.2009 21:36:23)

>Ещё надо учесть, что BFS плохо работает с NUMA и заточен под нужды десктопа.

Сколько компьютеров работает в NUMA? Сколько компьютеров работает как десктопы?

>Поэтому CFS выкинуть не удасться.

тормозить систему 99%-м ради 1% это безусловно оправданно, для производителей железа :-)

frame (31.12.2009 21:54:48)

И докажи теперь, что линукс не УГ на десктопе

frame (31.12.2009 21:55:29)

>тормозить систему 99%-м ради 1%

Я не уверен, что на десктопе Linux распространён больше, чем среди серверов...

KRoN73 (31.12.2009 22:01:00)

>заметный отрыв на 3-х потоках - это просто я не знаю как надо называть. Ну сразу же понятно, что у них параллельно была куча задач запущена, да и тест при каждом наборе значений параметров (качество, число потоков) выполнялся один раз - убейте себя!

moradan (31.12.2009 22:10:48)

Ъ? что непонятного по ссылке?

"Полезный совет" полезно сопровождаеть что конкретно писать в настройки...

Впрочем то что советуют по моей ссылке похоже самое рациональное.

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

Или что? Этого демона на питоне запускать который "по обстановке" настройки меняет? Это "менять настройки планировщика"?

Ну какие сокровенные настройки благородный дон использует у себя на десктопе?

psv1967 (31.12.2009 22:18:17)

>"Полезный совет" полезно сопровождаеть что конкретно писать в настройки... >Впрочем то что советуют по моей ссылке похоже самое рациональное.

>Вся остальная чухня что можно запихать в настройки, только ухудшает поведение планировщика по умолчанию.

Дурачёк:)

>Ну какие сокровенные настройки благородный дон использует у себя на десктопе?

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

Led (31.12.2009 22:23:34)

Садись. Два.

-"Не мало ли 7%"? -"7% - это немало."

impfp (31.12.2009 22:34:27)

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

ttnl (31.12.2009 22:36:16)

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

psv1967 (31.12.2009 22:41:24)

> Кэспер Сэндберг

Он датчанин, соответственно правильнее произносить как Каспер Сандберг.

> скролл в браузере был сравнительно плавным, а теперь он рывками

Дай-ка догадаюсь. Браузер - FireFox? Он с любым шедулером, о том, что такое плавная прокрутка, не знает.

xintrea (31.12.2009 23:19:12)

>> Ну какие сокровенные настройки благородный дон использует у себя на десктопе?

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

А что, обработка движения мышки и нажатий клавиш клавиатуры уже стали многотредовыми задачами? С BFS они как-бы неслабо улучшаются. Вы не знаете, почему?

xintrea (31.12.2009 23:22:18)

> Браузер - FireFox? Он с любым шедулером, о том, что такое плавная прокрутка, не знает.

а у меня вся работает, FF 3.7, nvidia 195.30.

isden (31.12.2009 23:22:42)

> А у меня, вот, система на глаз стала менее поворотливой. Но тут трудно сказать, что больше повлияло - BFS, обновлённый xorg (1.7.3.901-r1) или новая mesa..

!???$%^*&@!!!111

xintrea (31.12.2009 23:25:27)

>А что, обработка движения мышки и нажатий клавиш клавиатуры уже стали многотредовыми задачами? С BFS они как-бы неслабо улучшаются. Вы не знаете, почему?

Не знаю. А с чего ты, трольчёнок, взял, что BFS хорош для многотредовых вычислительных задач? Он для этого никогда и не позиционировался.

Led (01.01.2010 0:47:21)

Это верно, однако в корне неверно и просто очень нехорошо, когда линукс лишь серверами и представлен

frame (01.01.2010 0:51:13)

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

Однако _один_ анестезиолог смог? Смог. И оно таки работает, и работает получше того нагромождения, которое сейчас по умолчанию. Не нужно оправдывать плохой код лишь тем, что он написан "авторитетным" человеком.

frame (01.01.2010 0:54:18)

>Я пробовал в 6 потоков запускать пережатие из wave в ogg. Суммарно около 7 гигов файлов... С BFS это заняло на ~7% меньше, емнип.

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

tommy (01.01.2010 2:51:36)

>>Я пробовал в 6 потоков запускать пережатие из wave в ogg. Суммарно около 7 гигов файлов... С BFS это заняло на ~7% меньше, емнип.

>при этом проигрывание музыки останоновилось сразу а пеердвижения мыши чуть позже?

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

wyldrodney (01.01.2010 9:00:04)

>при работе в одном только ФФ создается такое впечатление, будто на фоне ворочается еще что-то тяжелое и неповоротливое...

В firefox свой планировщик стоит встроеный. Здесь bfs не при делах.

Robotron (01.01.2010 11:38:23)

>Не совсем так, регрессия была гораздо раньше:

Регрессию исправили только к ядру версии 2.6.32, в 2.6.31.8 почти исправили. Читай lkml.org, там по этой теме большая дискуссия была.

Robotron (01.01.2010 11:40:09)

>Ещё надо учесть, что BFS плохо работает с NUMA и заточен под нужды десктопа. Поэтому CFS выкинуть не удасться.

BFS вообще на использование NUMA не ориентирован, Коливас об этом чётко в факе пишет. Про выкинуть CFS никто не говорит в принципе, речь идёт о том что на десктопе с количеством ядер до 6-8, BFS более производителен.

Robotron (01.01.2010 11:44:39)

> В firefox свой планировщик стоит встроеный. Здесь bfs не при делах.

Ога, свой планировщик. Наверное даже RT, а ведро линукса он пускает как процесс.

>Ога, свой планировщик. Наверное даже RT, а ведро линукса он пускает как процесс.

Про XUL Runtime Environment очевидно не слышал. Школота, такая школота.

Robotron (01.01.2010 13:56:36)

>Про XUL Runtime Environment очевидно не слышал

А как XUL Runtime Environment рулит таймслайсами иксов, компиза, подсистем кеширования, звука? А в sqlite-либы XUL тоже лезет своими жирными лапками? А ресурсы Pidgin'у или Quod Libet'у тоже он выделяет?

KRoN73 (01.01.2010 17:15:27)

>А как XUL Runtime Environment рулит таймслайсами иксов

Иксы сами по себе не тормозят.

>компиза

не использую, ничего сказать не могу

>подсистем кеширования, звука

Здесь нет bottleneck, эти системы имеют хорошую производительность.

И сразу возник вопрос, как давно firefox стал приложением для прослушивания звука? Если же firefox не для работы со звуком то может не будете писать про системы которые если и имеют отношение в броузеру то очень косвенное?!

>А в sqlite-либы XUL тоже лезет своими жирными лапками?

Мистер, если считаете, что проблема в sqlite приведите способ оптимизации sqlite чтобы firefox не тормозил.

От себя скромно замечу, что на оттюнингованной ext4, оттюнингованным cfq и с bfs тормоза firefox продолжаются, хотя и стали чуть меньше.

>А ресурсы Pidgin'у или Quod Libet'у тоже он выделяет?

Бред какой-то написан. Какое отношение pidgin и эта Quod Libet имеют в firefox?

Robotron (01.01.2010 17:30:05)

>Бред какой-то написан

Бред в Вашей голове. Вы не понимаете, что такое планировщик процессов и какую роль он играет в многозадачной ОС. Ваше заявление из категории «у моего телефона встроенный аккумулятор, поэтому электроснабжение моей квартире не нужно».

KRoN73 (01.01.2010 17:31:54)

>Бред в Вашей голове. Вы не понимаете, что такое планировщик процессов и какую роль он играет в многозадачной ОС.

Давай так, ты не будешь без апелляционно тут заявлять, а я не буду говорить куда тебе идти. Про планировщик ядра Linux CFS и вообще про устройство ядра Linux знаю побольше твоего.

Robotron (01.01.2010 17:39:56)