КПД (Коэффициент полезного действия) — это отношение полезной работы к затраченной энергии. КПД является безразмерной величиной и часто измеряется в процентах.
В принципе, в программировании тоже можно определить КПД. Как с точки зрения энергетической, так и с точки зрения алгоритмической. Процессор работает, потребляет энергию. Доля энергии, затрачиваемой на программу вполне легко определяется. Для простоты оценки можно считать количество тактов процессора, затрачиваемых на выполнение программы. Что касается полезной работы, это сложнее, но оценка тоже возможна. Для оценки порядка величины можно взять теоретическое минимальное количество инструкций, необходимое для выполнения программы. Допустим, наша задача - повернуть изображение, записанное в формате jpeg. Значит его надо декодировать, повернуть битмап, закодировать обратно. Для каждого шага известна оценка количества операций. Количество тактов даст полезную работу. В реальной программе операций будет больше, что и даст КПД, меньшее 100%.
В около-программной науке (не путать с около-научным программированием) чаще считают другие параметры. Раньше, когда стояли в очередь "на счёт", больше беспокоились процентами загрузки процессора. Потом стали считать транзакции в секунду, мегабайты throughput и миллисекунды latency. Не отрицая этих важных параметров, КПД мне нравится тем, что является некоторым показателем эффективности, а следовательно и качества общей архитектуры программы.
Иногда возможны трюки, которые поднимают КПД на порядки, заставляя пересмотреть теоретический минимум. Например в вышеприведённом примере, поворот на 90 и 180% можно сделать очень быстро, без раскодировки и интерполяции, переставив данные непосредственно в сжатом jpeg-файле.
Чаще, однако встречаются примеры, когда КПД на много порядков ниже, чем нужно. Что интересно, это может никого и не беспокоить. Работает и ладно. Всё равно, процессор не может стоять и будет крутить idle loop. Но, в принципе, idle loop лучше. В этом режиме он экономит батарею ноутбука, позволяет крутиться другим задачам на сервере, а процессор телефона переходит в мало-потребляющий режим. Кроме того, программы с большим КПД просто лучше продуманы. Такое КПД - качество дизана программы.
В качестве примера приведу Exchange со списками рассылки. Оказывается, что в современном Exchange нет single-instance-storage. Посланное сообщение и все его приложенные файлы просто копируются в inbox каждого реципиента. Это уменьшает зависимость данных, позволяет разделить inbox-ы по разным серверам и всё такое. Казалось бы, всё логично.
Смотрю на свой корпоративный inbox средних размеров. В нём несколько тысяч сообщений. Во всех - несколько реципиентов. Большая часть получена по ссылкам рассылки, где в каждой группе - сотни и тысячи человек. Каждое такое сообщение копируется в тысячу inbox-ов. Ответ на него тоже так же копируется, причём, традиционно, текст включает сам вопрос и предыдущее обсуждение. И всё это в сложных кодировках, в HTML, который упакован в MIME, который пересылается в XML, через HTTPS, используя .NET Web-сервисы.
Простое и типичное форумное сообщение "+1", которое с точки зрения полезной работы, "как два байта переслать", превращается в гигабайты дисковой памяти и дальше, в соотвествующий сетевой трафик и фантастические компьютерные стойки, которые непрерывно что-то друг с другом синхронизируют, а затем всё это ещё и с моим компьютером.
Но и это ещё не всё. Обычно каждый пользователь настраивает правила так, чтобы списки рассылки попадали в свои отдельные папки. А затем новый Outlook в Conversation View сжимает всё обсуждение до своего логического минимума, показывая в нём ту самую единственную строчку: "+1".
Даже затрудняюсь оценить, какой у этого дизайна КПД. Какие-то бесконечно малые числа. Удивительно, что это вообще может работать на современной технике. Но как я могу осуждать архитекторов за это, если пси функция движущейся частицы тоже расширяется на всю вселенную, чтобы потом свернуться в нужную точку? Почти как в Exchange.
10 comments:
Очень перспективный путь понижения КПД - выполнять долгие операции заранее на основании предсказания действий пользователя
Скорее наоборот, это уменьшит КПД, поскольку будут выполнены лишние команды, которые юзер не просил, а в лучшем случае количество команд не изменится. Это способно уменьшить время отклика, не не повысить КПД.
Я так и написал - "путь понижения КПД" :) Причём на порядок. Но т.к. пользователь будет доволен уменьшением отклика, то так и сделают - куда же последствия закона Мура девать. А ещё включат персональный коммуникатор пользователя в общий кластер и получат возможность ещё на порядок уменьшить КПД, увеличив суммарный объём интенсивно "работающей" фигни.
клоакстер
А ничего, что этот самый закон Мура выполняется всё больше за счёт автоматического распараллеливания выполнения потока команд? А эта параллельность основана именно на предсказании на несколько шагов вперёд.
Насчёт в принципе полезности оптимизации КПД: он действительно пользователей не волнует. Миром правит TCO с поправкой на маркетинг. А КПД - это такая внутренняя техническая характеристика, которая может подсказать инженеру резервы развития. Не более.
Даже если просто вспомнить базовый курс по системам массового обслуживания, то КПД и там не священная корова. Как показывают расчёты, если хочешь, чтобы система работала без больших задержек, то в среднем она будет загружена не более, чем на 70-80%. А если грузить на все 100, то получатся местные ЖД кассы: 3 минуты выписка билета, перед этим в среднем час в живой очереди.
Я вовсе не призываю добиваться 100%. Главное, чтобы порядок величины был разумный, в зависимости от задачи. 0.1% - может быть вполне нормально для приложения. Но 10% для видеокодека - маловато.
Именно, что зависит от задачи. У видеоплеера на флэше КПД никакой. Но это опять же волнует только маргиналов.
Вот потому в iPad и нет флеша. Острая тема. Сейчас десктопы отступают под натиском планшетов, телефонов и ноутбуков. А у них работа от батареи - первое дело.
То, что в iPad нет флэша - это не более, чем ухудшение потребительских характеристик самого iPad. Не суть важно по религиозным или ещё по каким соображениям. Сам по себе плеер в неактивном состоянии батарею не кушает, так что пользователю всего лишь ухудшили выбор, на что ему оную батарею тратить.
Кушает, если открыть и оставить браузер с флеш-баннерами. У меня такая штука на Nokia N800 периодически происходит, если я забыл выключить плагин. На iPad даже приятно, что нет этой заботы.
Post a Comment