Почему программы тормозят?

P.S. Кривая архитектура, алгоритмы и пр. ошибки проектирования не интересуют.

Ты знаешь, а вот это как-раз основное.

Допустим, наша программа идеально спроектирована, алгоритмы - огонь (прям как ядро linux :). Но она все-равно тормозит. Хотя бы на слабых компах. В чем тогда искать причину «тормозов»?

профайлером пройтись.

Главная причина: Любовь программистам к интерпретируемым языкам типа python'а.

Сейчас в тренде обвинять intel и amd в том что они ничего не понимают в процессорах, делают тормозную подсистему памяти и неэффективно расходуют транзисторный бюджет увеличивая кэши. Типа вместо увеличения кэшей надо уменьшать задержки при работе с памятью и ставить больше контроллеров (memory-level parallelism).

Короче, во всём виноваты процессоры.

программа идеально спроектирована

все-равно тормозит

ну ты понел :)

Логично. Но чтобы сделать правильные выводы, нужно разбираться в особенностях, конретных причинах тормознутости, как минимум что-нибудь из списка в этом посте. А м.б. что-нибудь еще.

Вы лучше скажите мне, как можно было так умудриться написать демон dropbox, чтобы он жрал 64 Мб памяти?

жрал 64 Мб

Про 640M ещё можно было б сказать, а так сам понимаешь.

Как по мне, 64 Мб для сраного демона это уже чересчур.

Вы лучше скажите мне, как можно было так умудриться написать демон dropbox, чтобы он жрал 64 Мб памяти?

Вероятно они используют какой-нибудь пул (памяти (а-ля свой аллокатор) / потоков / буфферов i/o). Это вариант из серии преждевременная оптимизация, readahead и пр.

Что значит тормозят? Примеры в студию.

В чем тогда искать причину «тормозов»?

В других программах и компонентах

Программы не тормозят. Просто наше восприятие слишком быстрое.

потому что медленно выполняются :)

Всё очень просто.

Если программа идеально спроектирована, она не тормозит. А если тормозит, значит неидеально спроектирована :) Ну и еще есть зависимость от ядра, библиотек и других компонентов, которые сами по себе могут быть не идеальны.

Вы лучше скажите мне, как можно было так умудриться написать демон dropbox, чтобы он жрал 64 Мб памяти?

Он на питоне написан, если что.

Он на питоне написан, если что.

Так вот же причина. Питон во всем виноват.

Вы всё портите! :)
Развеяли весь саспенс.

Говноко... а, ну ладно.

Есть тупо очень большие задачи. Числодробилки всякие, рендеринг.

Что значит тормозят? Примеры в студию

шindoшs или KDE, например

вы льстите своему восприятию :) Развертка 25 кадров - и уже сказки про зомбей. Для кошек, к примеру, обычная кадровая развертка - набор фотографий. Т.е. по скорости реакции человеки проектно сливают хищникам или... мухам, например.

Остальное - проблема узких мест и переходных процессов, бухгалтерская торговля между ТТХ железяк, их практической окупаемостью и жабой пользователя :) Вспоминается камаз болванок - скорость передачи данных огого, но подготовка к такой передаче - запретительно дорогая с практической точки зрения (практическая ценность тоже нулевая, если вы не продавец «контента на носителях»). Топовое железо на каждый божий день для 95% все равно что ежедневно стоять в пробке на гоночном автомобиле («а негламурный интерфейс не продается» (с), а гламурный - хочет топовое железо из «официального списка» вендора :)) или иметь «высокотехнологичный преобразователь» электроэнергии в тепловую и гордиться скоростью начальной загрузки - при никаком соответствии системы в целом реальным задачам.

Программы тормозят потому что у них течёт память. Установи openSUSE 10.2, обнови ядро до 2.6.32 или 3.8, обнови браузер с getfirefox.com. Посмотри сколько памяти ест работающая система! На твоём компе 99% памяти будет свободно в такой системе. Тормоза пропадут чудесным образом!

шindoшs

На винфак, ибо если бы она реально тормозила ее бы не покупали миллионы. AAA-игрушки с топовой графикой почти близкой к реальности не торомозят на «тормозной» ОС.

KDE

А что именно не устраивает? Да, с визуальными эффектами дела у них не очень. А в остальном все довольно быстро работает.

Если делать вброс про тормоза, то я бы первым делом упомянул бы флеш и js-движки.

как можно было так умудриться написать демон dropbox, чтобы он жрал 64 Мб памяти?

malloc(64 * 1024 * 1024);

Делов то...

when malloc() returns non-NULL there is no guarantee that the memory really is available. This is a really bad bug.

GC. Попытка обработать поток данных больше, чем позволяет железо.

Во многих случаях виновато дисковое IO. Так получилось, что работаю сейчас на виндовой машинке с SSD — за минуту загрузится, запустит вижак и соберет проект. Дома на ноуте с HDD что винда, что Gentoo за минуту максимум до login screen доберутся

Дома на ноуте с HDD что винда, что Gentoo за минуту максимум до login screen доберутся

У тебя какие-то неправильные системы.
Восьмерка на hdd грузится секунд 30, гента у меня на ноуте за ~15. slitaz вообще за 7-9 ухитряется. На харде в 5400.

Во всём виноваты одни только авторы «кривых, глючных, тормозных недоязычков» с «убогим, устаревшим, черезжопным синтаксисом». Давно же уже всё выяснили.

Хотя бы на слабых компах. В чем тогда искать причину «тормозов»?

(прям как ядро linux :)

Ты знаешь под каким номером смотреть баг ;-)

Допустим, наша программа идеально спроектирована, алгоритмы - огонь (прям как ядро linux :). Но она все-равно тормозит. Хотя бы на слабых компах. В чем тогда искать причину «тормозов»?

Причина тормозов в ваших допущениях (или уверованиях), что программа спроектирована идеально.

Давно же уже всё выяснили.

Что причина в /dev/hands out of /dev/arse? ;-)

Как по мне, 64 Мб для сраного демона это уже чересчур.

Держит базу хешей файлов под его присмотром?

В случае с гентой, подозреваю, виноваты кеды, потому что всякие liveusb типа минта вроде побыстрее грузятся

Да. Что иногда /dev/hands — это фактически симлинк на /dev/arse. :)

Он на питоне написан, если что.

Судя по ~/.dropbox-dist/ на питоне там только обертка.

На винфак, ибо если бы она реально тормозила ее бы не покупали миллионы.

Бред. Ее покупают благодаря маркетологам начала 90х.

AAA-игрушки с топовой графикой почти близкой к реальности не торомозят на «тормозной» ОС.

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

Каждый класс программ тормозит по-своему. Десктопные программы обычно имеют кучу проблем с неудачно сделанной асинхронностью.

Главная причина: Любовь программистам к интерпретируемым языкам типа python'а.

Это серверные программисты, у других к питону обычно нелюбовь.

• Программа выполняется на виртуальной машине или интерпретаторе.

when malloc() returns non-NULL there is no guarantee that the memory really is available. This is a really bad bug.

Поскольку такое поведение для Linux описано в man, то это не может являться багом. Можете назвать это фичей, поведением, но не багом.

Вы лучше скажите мне, как можно было так умудриться написать демон dropbox, чтобы он жрал 64 Мб памяти?

Так ведь python. Сегодня на хабрахабре была статья, подробно объясняющая, почему языки со сборкой мусора хотят себе в 5 раз больше памяти, чем просит программист — и начинают тормозить, если им дают меньше.

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

от ОС зависит ещё взаимодействие с видеокартой, драйверы и их интерфейсы в ядре, если они тормозят, то и игрушка будет тормозить

ну и ещё в играх часто тормозит загрузка уровней, но тут в первую очередь всё в криворукость разработчиков упирается, а не в ограничения ОС

Ось запускалка для игрушек. Дальше ось практически не нужна.

Все, дальше можете ничего не говорить. Про DirectX вы не слышали. Кстати, а зачем его впиливают насильно в gallium и wine вы тоже не знаете. Что делает собственно DirectX вы тоже не знаете. И то, что OpenGL делает тоже. Еще скажите, что все игрушки пишутся байткодом и все выше сказанное не имеет никакого значения. Ось лишь напрямую транслирует команды в процессор, видяху и ... вообще не приделах!

от ОС зависит ещё взаимодействие с видеокартой, драйверы и их интерфейсы в ядре, если они тормозят, то и игрушка будет тормозить

Только до момента получения интерфейса к железу. Потом ось уже не нужна.

Если дебил-программист постоянно дергает ось для каких-либо операций, то он дебил-программист. Но как у него получилось написать игру класса трайпл-эй?

ну и ещё в играх часто тормозит загрузка уровней, но тут в первую очередь всё в криворукость разработчиков упирается, а не в ограничения ОС

О чем и речь. Написать менеджер ресурсов, который загрузит блоб в память и будет без дополнительной конвертации отдавать ресурсы не такая уж и сложная задача.

Вы просто малолетний дурачок, который думает, что знает, о чем спорит.

Только до момента получения интерфейса к железу. Потом ось уже не нужна.

не всё так просто, при отрисовке каждого кадра какой-то кусок кода, принадлежащий ОС, обязательно вызывается, а не только код программы крутится

О чем и речь. Написать менеджер ресурсов, который загрузит блоб в память и будет без дополнительной конвертации отдавать ресурсы не такая уж и сложная задача.

все нужные ресурсы в память могут и не поместиться, тем более что игроделы не спешат осваивать 64 битные платформы

Если дебил-программист постоянно дергает ось для каких-либо операций, то он дебил-программист.

Либо он никакой не дебил и нужные ему операции из его предметной области прекрасно отображаются на API системы.