| zubastiy |
|
|
Темы:
136
Сообщения:
548
Участник с: 18 сентября 2009
|
собрал “облегченный” mplayer из репов mplayer занимает в памяти 64 мб собранный с минимальным колвом флаго (до кучи выкинул и vdpau) - 60 мб потребление проца - одинаково в обоих вариантах. … может ffmpeg до кучи пересобрать? ) |
| kernelpanic |
|
|
Темы:
17
Сообщения:
452
Участник с: 14 марта 2009
|
zubastiyСам думай,у меня его вообще нет. В бытность использования totem-xine я собирал FFmpeg но давно это было. |
| zubastiy |
|
|
Темы:
136
Сообщения:
548
Участник с: 18 сентября 2009
|
kernel_paniczubastiyСам думай,у меня его вообще нет. В бытность использования totem-xine я собирал FFmpeg но давно это было. была почему то уверенность, что mplayer его использует. sudo pacman -R ffmpeg checking dependencies… error: failed to prepare transaction (could not satisfy dependencies) :: mpd: requires ffmpeg>=20100108 :: transcode: requires ffmpeg>=20100108 :: winff: requires ffmpeg похоже что mplayer не использует ffmpeg пересобрал mplayer на нетбуке (проц VIA NANO u2250)с флагами -march=native -mtune=native -O2 (до этого компилил на ББ с явным указанием архитектуры и прочих параметров) тестировал на воспроизведении одного и того же фрагмента файла 720р, сравнивал загрузку CPU в виду слабого проца и отсутствия аппаратной поддержки видео каждый CPU score на счету - больше 15 процентов времени CPU idle - 0% ) версия 286 vs 325 (из репов) - в местах интенсивного экшена версия 352 потребляла на 1-1.5 процента меньше проца, 5-7% времени CPU idle - 0% версия 325 (из репов) vs 325 (-march=native -mtune=native -O2) в местах интенсивного экшена версия оптимизированная версия потребляла на 1-1.3 процента меньше проца, 1-2% времени CPU idle - 0% в одном самом насыщенном по смене кадров отрезке CPU idle держалось 0.3% - 0.7% собрал с -march=native -mtune=native -Os (хоть и пишут, что такое актуально только для совсем маленьких кешей L2, но было интересно) в целом пакет с оптимизацией Os хуже по производительности на процент-полтора чем пакет из репов, но в одной сцене где все остальные варианты сброки гарантированно сжирали проц - CPU idle был 1.5 процента. собрал с -march=native -mtune=native -O3 лучший по производительности вариант в тяжелых условиях. в самых сложных сценах CPU idle держалось 1.3% - 3.0% но в одной сцене (где у остальных сборок CPU idle 8-9) CPU idle две-три секунды - 0% в целом проц в варианте сборки -march=native -mtune=native -O3 загружен больше, но меньше случаев когда CPU idle равно 0. как то так. |
| kernelpanic |
|
|
Темы:
17
Сообщения:
452
Участник с: 14 марта 2009
|
В сборке с “-O3” тормоза в одной сцене могли просто совпасть например с обновлением журнала ФС,либо еще с чем то. Если на протяжении всего тестируемого отрезка на сборке с O3 cpu idle был 3-8% а на других почти всегда 0% то ИМХО лучше собирать с O3, если не появятся другие глюки. Я обычно после сборки тестирую пакет около недели и если все нормально закидываю пакет и ебилд к нему в папку “stable” |
| zubastiy |
|
|
Темы:
136
Сообщения:
548
Участник с: 18 сентября 2009
|
kernel_panicПерепроверял результат. Именно в опеределенной сцене (полная перерисовка, при этом предыдущий кадр был в темных тонах, в следующем преобладает белый цвет) был провал в производительности. внешнее влияние, думаю, можно исключить. как ни странно О3 сборка в среднем потребляля больше проца, но при этом было меньше ситуаций где mplayer был бы вынужден дропать фреймы похоже, что тестировать оптимизированные приложения нужно на низко частотных проца, ибо на быстрощелкающих 0.1-0.2 процента прироста можно и не заметить ) UPD Докладаюсь. Пересобрал X (в отличии от варианта предложенного в старттопике пришлось включить vgahw - так требует видеодрайвер) тестировал пересобранный mplayer + тот же 720p O2 O3 Os - разницы не увидел на проце разницы в колве потребляемой оперативки - не увидел (при старте вариант из репов и пересобранный весят 16 мб .. наверное потому что Xorg конф у меня и так не богат на модули) по сравнению с предыдущей минорной версией из репов (не помню версию) - обновленный xorg и пересобранный менее процессороемкие. разница между вариантом из репов и пересобранным смотрел потребление проца X, показания CPU idle укладываются в различия между старыми и новыми показателями. в среднем вариант из репов занимает меньше процессороного времени, уж даже и не знаю по какой причине (0.1-0.2 процента, тестил трижды). правда в самом проблемном эпизоде где весь проц сожран, оптимизированный вариант выдал меньшее потребление проца чем вариант из репов, на 0.1 процента. возможно погрешность измерения. для себя пока не вижу смысла пересобирать xorg цпу жрет точно так же, оперативку - точно так же. если у кого есть другие мысли и результаты - просьба высказаться. |