1

На моем нетбуке с Интел Атом mpd кушает 10-15% процессорного времени воспроизводя mp3. Пробовал собирать разными компиляторами, включая интеловский с разными СFLAGS с разными бэкэндами. Разумеется, бэкэнды (ffmpeg, libmad etc.) тоже пересобирал. Меньше 10% эта цифра не опускалась. Кстати, gcc-4.5, который должен поддерживать атомы показал самую худшую производительность при прочих равных условиях, но возможно стоит покурить насчет СFLAGS. При этом, казалось бы, тяжелый Amarok на движке xine ест всего 3-7% процессора. В чем может быть дело? mpd нельзя собрать с поддержкой xine, поэтому не могу сравнить, может это xine так эффективен? И раз уж на то пошло, то предложите плеер для аудио и для видео, такие, чтобы не шибко нагружали процессор.

Йа тьомный эльф

2

Для аудио использую deadbeaf. Он всего 6% процессора ест.
Для видео SMPlayer (а когда подглючивает, то и чистый mplayer можно).

3

Самый, консольный mplayer.

4

Видео - mplayer, аудио - mpd. Mplayer тоже можно использовать для аудио, но mpd все ж кошернее.

Gentoo amd64 + kde4 desu!

5

neko259, прочтите пост внимательнее, а потом вопрос =)

6

Н-да, спасибо, elve, как я уже говорил, mpd на удивление сильно грузит мой процессор. Если кто-нибудь подскажет, как это побороть или, хотя бы, в чем может быть причина этого буду несказанно рад, ибо на десктопе юзаю mpd и привык к нему. Я полагаю, причина все же в бэкэнде mpd, ведь он не сам декодирует звук, а использует сторонние библиотеки. Так, для декодирования mp3 он может использовать libmad, который сразу отпадает, поскольку эта библиотека написана с использованием только целочисленной арифметики, а SSE инструкции, которые держит Atom грех не использовать, т.к. это немалый выйгрыш в производительности. Но вот отчего же ffmpeg так сильно грузит процессор, я не понимаю.
Вообще, я выяснил, что наиболее выгодно использовать  mpg123, но его интерфейс, точнее полное отсутсвие последнего делают его не вполне юзабельным... собираю deadbeaf.

Йа тьомный эльф

7

bobr, а если закрыть "морду" после запуска? Все равно грузит?

8

Да, все равно грузит. Как "морду" для mpd использую ncmpcpp. То-есть вряд-ли она грузит процессор.

Йа тьомный эльф

9

deadbeef на моем нетбуке загружает процессор на 11%. Насколько я понял, он тоже использует libmad, как и mpd. Подумываю о том, чтобы написать плеер с использованием libmpg123. Уже набросал модуль для Python, правда пока очень ограниченный.

Йа тьомный эльф

10

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

11 (19.08.2010 15:01:28 отредактировано Teocally)

У меня практически все плейеры аудио дают не менее 15% загрузки.
Пытался пробовать когда-то mpd в связке с ещё чем-то - не пошло.
В упор не видело муз. коллекцию на жёстком  ac

"Теория и практика иногда сталкиваются. Когда это случается, теория проигрывает. Всегда." (с) Линус Торвальдс

12

$ ps uax |grep "auda"
doc       3204  5.8  3.5  59264  8824 ?        Sl   13:24   8:52 audacious
doc       4452  0.0  0.3   2416   880 pts/0    S+   15:56   0:00 grep --color auda
$ uname -a
Linux bx 2.6.29.6-smp #2 SMP Mon Aug 17 00:52:54 CDT 2009 i686 Pentium III (Coppermine) GenuineIntel GNU/Linux

вопрос закрыт? руки.sys?

Карусель разнесло по цепочке за час
Всех известий — конец
Да, весна началась!
(всё к лицу подлецу, как родному отцу, не рассказывай, батя, и так всё пройдёт)

13

drBatty пишет:

вопрос закрыт? руки.sys?

Может всё-таки поаккуратнее в высказываниях?  oO
Системы у всех разные, железо тоже...  :rolleyes:

"Теория и практика иногда сталкиваются. Когда это случается, теория проигрывает. Всегда." (с) Линус Торвальдс

14

Думаю вам следует обратить внимание на мой пост выше сначала!

15

enslaver пишет:

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

Думаю, вы неправы, в таком утверждении, или не вполне правы. Как насчет mpd? Он тоже от ДЕ зависит? Кроме того, декодирование mp3 - куда более ресурсоемкий процесс, чем отображение GUI. Так, что библиотеки, на к-рых ДЕ работает - если не последний, то один из последних факторов, над которыми стоит задумываться.

Йа тьомный эльф

16

root@asus:~# ps aux | grep [d]ead
1000      2089  5.8  5.7 170716 21860 tty1     SLl  16:01   0:06 /usr/bin/deadbeef
root@asus:~#

root@asus:~# grep "model name" /proc/cpuinfo
model name    : Intel(R) Celeron(R) M CPU        420  @ 1.60GHz
root@asus:~#

это простите даже не Атом.
bobr, ваши измышления насчёт каких-то целочисленных вычислений не верны изначально.
всё дело в кривой оптимизации.

17

system-root, очень даже может быть, поскольку это действительно только лишь мои измышления. Но меня все же больше волнует не вопрос "кто виноват?", а " что делать?".  Просто перебором испробовал все доступные компиляторы едва ли не со всеми возможными флагами. Как оптимизировать? И если можно, поподробней о этой самой кривой.

Йа тьомный эльф

18

bobr, попробуйте в chroot окружении собрать сам gcc и тот же deadbref со всеми вытекающими просто -pipe -fomit-frame-pointer и упаси боже не -O3, а -O2.
всё, три флага которых достаточно для всего на свете.

19

Попробую. Сейчас я не дома, так что о результатах через пару недель. А -march= что писать? кто-то советует core2, кто-то prescott советует. Может -march=i686  попробовать?

Йа тьомный эльф

20

bobr пишет:

А -march= что писать?

native, это же ноутбук.

21

По-моему (опять-таки, жаль не могу прямо сейчас проверить, нет этого компьютера под рукой), native  будет включать просто -march=core2

Йа тьомный эльф

22

М... Перечитал тему... Подумал... А ведь да... Что-то похожее и у меня было (только на моём третьем пне вообще заикалось). Виноват оказался новомодный микшер из KDE (ALSA вроде) - включил OSS - всё работает. Только теперь звук из двух плееров нельзя слушать одновременно. Для меня это не минус.

Т.ч. прошу прощения ac

Карусель разнесло по цепочке за час
Всех известий — конец
Да, весна началась!
(всё к лицу подлецу, как родному отцу, не рассказывай, батя, и так всё пройдёт)

23

system-root пишет:

и упаси боже не -O3

а иногда - помогает. иногда даже -Os помогает (но реже ИМХО).

Карусель разнесло по цепочке за час
Всех известий — конец
Да, весна началась!
(всё к лицу подлецу, как родному отцу, не рассказывай, батя, и так всё пройдёт)

24 (23.08.2010 01:13:13 отредактировано enslaver)

1. на счет ДЕ, не согласен, так как будут подгружаться дополнительный библиотеке, что в свою очередь увеличит нагрузку на процессор.

2. Ну если вам все же не жалко памяти, то советовал бы вам пересобрать кодек и плеер с параметром

-О

это увеличит размер но повысит производительность.

25

*  -O — базовая оптимизация. Заметно поднимает скорость исполнения программы (вплоть до повышения в два раза).
    * -O2 — стандартный уровень оптимизации. Несущественно увеличивает как размер бинарника, так и скорость исполнения (по сравнению с –O).
    * -O3 — оптимизация уровня -O2 плюс некоторые ухищрения в виде флагов -finline-functions и -frename-registers. Опять же, в отличие от предыдущего флага, не приводит к заметному повышению скорости. Но размер увеличивается ab. Некоторые программы не могут быть скомпилированы с этим флагом.
    * -Os — опять же -O2 в совокупности с флагами, уменьшающими размер.

26

Хм, товарищ enslaver, вы же не думаете, что я этого не знал? Кроме того выше мы это уже обсуждали см. 18 Насчет ДЕ еще раз упомяну mpd. Просто внимательнее прочитайте топик сначала, не люблю повторяться.

Йа тьомный эльф

27

drBatty пишет:

а иногда - помогает.

на процессорах с маленьким кешем, раздувшиеся от этого ключа программы могут вызвать падение производительности на рандомное количество процентов. а если они ещё своих друзей с жесткого диска теранят, то нагрузка в 2 раза больше на хард, и для них нужно в два раза больше оперативной памяти.
так что -O3 лучше использовать тем, у кого 2+ ядра.

bobr пишет:

По-моему (опять-таки, жаль не могу прямо сейчас проверить, нет этого компьютера под рукой), native  будет включать просто -march=core2

это зависит от gcc и от самого камня, но ничего страшного.

28

а сколько у вас alsaplayer жрет?

29

system-root пишет:

так что -O3 лучше использовать тем, у кого 2+ ядра.

угу. с "маленьким", "если-бы"... А как я на iPI, iPI-MMX, iPII, iPIII использовал? тут очень от многого зависит, это совсем не тривиальный процесс.
На самом деле, все эти О1, Оn - просто пресеты, созданные разработчиками компилятора, что-бы кодеры голову не забивали. В разных компиляторах опции работают по разному (за исключением -O0 которая вырубает всё, и -O3 которая всё врубает), можно мануал почитать, а не спорить. Или попробовать. Да, кстати, лучше не компиллить всё с одними флагами, а покрутить Makefile, и скомпиллить лишь критичные модули с -O3, а остальное с -O0, или возможно с -Os, тогда результат будет наилучшим. Примерно так подошли к делу создатели mplayer'а, и получили неплохой результат.

Карусель разнесло по цепочке за час
Всех известий — конец
Да, весна началась!
(всё к лицу подлецу, как родному отцу, не рассказывай, батя, и так всё пройдёт)

30 (23.08.2010 15:29:42 отредактировано Hvzh)

Самый экономичный плеер - купленный за пару штук в i-on'e или в Связном