Artem Chuprina wrote:
> Eugene V. Lyubimkin -> debian-russian@lists.debian.org @ Mon, 04 Aug 2008 15:54:11 +0300:
> >> Внимание, вопрос. Сколько времени работают эти программы?
> EVL> Эээ... это такой риторический вопрос, что ли? больше одного такта,
> EVL> вестимо, так что поддаются "регистровой" оптимизации.
>
> Я имею в виду, что случится от того, что они, _может быть_, начнут
> работать на 10% медленнее. Сколько времени _твоей_ жизни на это уйдет?
> А на попытку посмотреть флешку на сайте? (А это сайт, скажем, нокии, и
> там на этой флешке, скажем, навигация сделана, а вовсе даже не только
> реклама.)
Да. Может, начнут, а может, и начнут. А в противном случае точно не
начнут :)
> >> Верно. Запусти top и посмотри на строчку CPU. У меня там сейчас 99%
> >> idle. Вот на этот "бинарник" и проведи тест.
> EVL> /usr/bin/X. Как предлагаешь тест проводить?
>
> Я сказал "на строчку CPU", а не "на верхнюю строчку списка процессов".
А я по CPU и сказал. Оно 10-50% жрёт.
> EVL> Знаешь, у меня 99% idle - довольно-таки редкая ситуация. Firefox, g++,
> EVL> icedove, иксы хотя бы.
>
> У тебя там компиляция по циклу, что ли? Или как раз свопинг?
Свопинг процессора особо не волнует. Да, бывало, что и компиляция по
циклу. Поправить debian/rules или наложить следующий вариант патча и
вперёд - весь пакет собирать. И так дюжину раз.
> >> >> 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> на "среднячков" - пожалуйста.
>
> Эк у тебя там страшно... У меня бывает десятки минут, да, но работать
> за машиной это совершенно не мешает...
*вспоминает, как в 4 часа ночи дожидался последней компиляции
fbreader'a* Если это в процессе других дел - да, не спорю. Но, бывает,
что это единственное дело, которое нужно завершить побыстрее и идти по
делам/баиньки.
--
Eugene V. Lyubimkin aka JackYF
Attachment:
signature.asc
Description: OpenPGP digital signature