[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: как мне проинсталлировать flash player на x88_64?



Eugene V. Lyubimkin -> debian-russian@lists.debian.org  @ Mon, 04 Aug 2008 15:54:11 +0300:

 >>  >>  EVL> Все программы при компиляции на amd64 могут пользоваться
 >>  >>  EVL> дополнительными 8 регистрами. Нет?
 >>  >> 
 >>  >> Да.  Скольким программам это действительно нужно?  Сколько времени
 >>  >> работают эти программы?
 >>  EVL> Любым. Ассемблером x86 баловался? Регистров мало, их не хватает
 >>  EVL> очень часто. Обычно свободно 2-4 регистра. А так - 10-12. Разница
 >>  EVL> ощутимая.
 >> 
 >> Внимание, вопрос.  Сколько времени работают эти программы?
 EVL> Эээ... это такой риторический вопрос, что ли? больше одного такта,
 EVL> вестимо, так что поддаются "регистровой" оптимизации.

Я имею в виду, что случится от того, что они, _может быть_, начнут
работать на 10% медленнее.  Сколько времени _твоей_ жизни на это уйдет?
А на попытку посмотреть флешку на сайте?  (А это сайт, скажем, нокии, и
там на этой флешке, скажем, навигация сделана, а вовсе даже не только
реклама.)

 >> Верно.  Запусти top и посмотри на строчку CPU.  У меня там сейчас 99%
 >> idle.  Вот на этот "бинарник" и проведи тест.
 EVL> /usr/bin/X. Как предлагаешь тест проводить?

Я сказал "на строчку CPU", а не "на верхнюю строчку списка процессов".

 EVL> Знаешь, у меня 99% idle - довольно-таки редкая ситуация. Firefox, g++,
 EVL> icedove, иксы хотя бы.

У тебя там компиляция по циклу, что ли?  Или как раз свопинг?

 >>  >> mplayer в этом списке тоже выглядит довольно смешно.  Ты себе
 >>  >> представляешь, как выглядит кино, проигрываемое на 10% быстрее?
 >>  EVL> Мне тоже было смешно, когда прислали киношку 1900x1050 (точно не
 >>  EVL> помню последние цифры) в каком-то виндовом формате (не
 >>  EVL> распараллеливается на два проца). Фиг я её смог посмотреть даже
 >>  EVL> при framedrop. Пришлось около часа конвертить это дело
 >>  EVL> mencoder'ом, да и после конвертации жралось 50-80% процессора при
 >>  EVL> просмотре.
 >> 
 >> Вот сравнительный тест mplayer'ом на этой перекодированной киношке (нет,
 >> не сколько процессора жрет - а успевает или нет) был бы аргументом...
 EVL> По закону подлости может найтись киношка, которую 64-битный мплеер
 EVL> сможет переварить вчистую, а 32-битный - хуже, или с дропами, или
 EVL> вдруг совсем не потянет (кодек фиговый, допустим).

Вот "может найтись" - не аргумент.  Если на практике нашлась, да еще
просмотра стоила - это аргумент, да.

 EVL> Я предпочитаю вытягивать всё из своей аппаратуры - для этого я её
 EVL> и брал.

Вот и я про что...  Тратим свою жизнь на то, чтобы вытянуть из
аппаратуры всё.  А на хрена?

 >>  >> Была бы это СТРАШНАЯ ЧИСЛОДРОБИЛКА с ДОФИГИЩА ПАМЯТИ - да, верю,
 >>  >> 64-битная система там была бы полезна.
 >>  EVL> У меня не так мало времени занимают процессы компиляции. Это не
 >>  EVL> числодробилка, но CPU жрёт только так.
 >> 
 >> И таки в 64 битах заметно быстрее?  И каков расход памяти на компиляцию
 >> там и там?  А то тут tradeoff не очевиден.  С одной стороны, там и
 >> регистры должны ролять в полный рост, с другой - память покушать gcc
 >> тоже очень любит, причем мелкими кусочками...
 EVL> До свопа gcc ещё не добирался ни разу (да, openoffice.org я не
 EVL> компилирую, и kde тоже), а вот отожрать 100% CPU на десятки минут
 EVL> на "среднячков" - пожалуйста.

Эк у тебя там страшно...  У меня бывает десятки минут, да, но работать
за машиной это совершенно не мешает...

-- 
Artem Chuprina
RFC2822: <ran{}ran.pp.ru> Jabber: ran@jabber.ran.pp.ru

Пользователь юникса перестаёт быть пользователем юникса если после его
пользования пользованный юникс перестаёт быть юниксом. (с)


Reply to: