Re: как мне проинсталлировать flash player на x88_64?
Eugene V. Lyubimkin -> debian-russian@lists.debian.org @ Mon, 04 Aug 2008 19:15:16 +0300:
>> >> >> Внимание, вопрос. Сколько времени работают эти программы?
>> >> EVL> Эээ... это такой риторический вопрос, что ли? больше
>> >> EVL> одного такта, вестимо, так что поддаются "регистровой"
>> >> EVL> оптимизации.
>> >>
>> >> Я имею в виду, что случится от того, что они, _может быть_,
>> >> начнут работать на 10% медленнее. Сколько времени _твоей_ жизни
>> >> на это уйдет? А на попытку посмотреть флешку на сайте? (А это
>> >> сайт, скажем, нокии, и там на этой флешке, скажем, навигация
>> >> сделана, а вовсе даже не только реклама.)
>> EVL> Да. Может, начнут, а может, и начнут. А в противном случае
>> EVL> точно не начнут :)
>>
>> Нет. Поскольку будут жрать больше памяти.
EVL> Память vs скорость - tradeoff.
Прожорливость по памяти может привести к падению скорости. Или эта, к
счетам за электричество :-)
>> >> >> Верно. Запусти top и посмотри на строчку CPU. У меня там
>> >> >> сейчас 99% idle. Вот на этот "бинарник" и проведи тест.
>> >> EVL> /usr/bin/X. Как предлагаешь тест проводить?
>> >>
>> >> Я сказал "на строчку CPU", а не "на верхнюю строчку списка
>> >> процессов".
>> EVL> А я по CPU и сказал. Оно 10-50% жрёт.
>>
>> Нифига себе... Это у него, часом, не от кривой 64-битности? Или
>> это от гнома какого? У меня X.org жрет 0.3% CPU.
EVL> Это у него от кривой по самое не хочу ATI-шной видеокарточки
EVL> x200. На интеле всё чики-пики было.
И этот человек говорит про выжимание из железа всего...
>> >> >> >> mplayer в этом списке тоже выглядит довольно смешно. Ты
>> >> >> >> себе представляешь, как выглядит кино, проигрываемое на
>> >> >> >> 10% быстрее?
>> >> >> EVL> Мне тоже было смешно, когда прислали киношку 1900x1050
>> >> >> EVL> (точно не помню последние цифры) в каком-то виндовом
>> >> >> EVL> формате (не распараллеливается на два проца). Фиг я её
>> >> >> EVL> смог посмотреть даже при framedrop. Пришлось около
>> >> >> EVL> часа конвертить это дело mencoder'ом, да и после
>> >> >> EVL> конвертации жралось 50-80% процессора при просмотре.
>> >> >>
>> >> >> Вот сравнительный тест mplayer'ом на этой перекодированной
>> >> >> киношке (нет, не сколько процессора жрет - а успевает или
>> >> >> нет) был бы аргументом...
>> >> EVL> По закону подлости может найтись киношка, которую
>> >> EVL> 64-битный мплеер сможет переварить вчистую, а 32-битный -
>> >> EVL> хуже, или с дропами, или вдруг совсем не потянет (кодек
>> >> EVL> фиговый, допустим).
>> >>
>> >> Вот "может найтись" - не аргумент. Если на практике нашлась, да
>> >> еще просмотра стоила - это аргумент, да.
>> EVL> Я предпочитаю смотреть на шаг вперёд и учитывать вероятности
>> EVL> :)
>>
>> Результат, судя по вышеприведенной фразе про 10-50% CPU на X, прямо
>> скажем, странен... Ты подумай, может, ты как-то неправильно учитываешь
>> вероятности?
EVL> Ответ про иксы выше.
Так в свете этого ответа мой вопрос про вероятности тем более
актуален...
>> EVL> *вспоминает, как в 4 часа ночи дожидался последней компиляции
>> EVL> fbreader'a* Если это в процессе других дел - да, не спорю. Но,
>> EVL> бывает, что это единственное дело, которое нужно завершить
>> EVL> побыстрее и идти по делам/баиньки.
>>
>> А. Я в таких случаях иду баиньки не дожидаясь. Оно железное, с ним
>> ничего не случится до утра.
EVL> А вот с человеком, который ждёт аплоад, может и случится :)
Так опять же, у меня быстрее соберется. Потому что карточка хоть и ATI,
но не кривая, и процессор может спокойно заняться компиляцией... ЧЯДНТ?
--
Artem Chuprina
RFC2822: <ran{}ran.pp.ru> Jabber: ran@jabber.ran.pp.ru
There's no sense in being precise, when you don't even know what
you're talking about.
-- John von Neumann
Reply to: