Re[3]: Об эффективности программ
От: GlebZ Россия  
Дата: 06.10.05 09:01
Оценка: 2 (2) +2
Здравствуйте, Pavel Dvorkin, Вы писали:

PD>Нет, оверлей — это нечто иное. Я этим на СМ-4 и ЕС-1022 занимался, это вполне легальное действие, даже ассемблер не требуется. А самоубийство только на ассемблере делалось, даже ИМХО не на ассемблере тогда, а просто в кодах.

Да уж. Я тогда маленький был. Слышал о монстрах которые для того чтобы понять программу переписывали с ассемблера на коды.

PD>Чудно. А могу я эти сервисы безболезненно удалить, и освободить Мбайт так 50-60 ? Немного — получится, а остальные, увы, обязательны для системы. А мне, в общем, все равно, как это называется, ядро или сервисы, лишь бы занимали они поменьше.

Тут конечно фигня творится. Когда новую функциональность с исправлением ошибок смешивают. Но отрицать то, что увеличение функциональности сервиспаками и требования к памяти строго пропорциональны, нельзя. Таже NT4 — с последними сервис паками мег 100 занимает оперативы. Если отрубать ненужное, то можно и сильно сократить. Вопрос только в том, что инструментов недостаточно.

GZ>>Если пользователь будет одновременно работать с моей программой, с 10 вордами, 50 акцессами, и 30 экселами одновременно, то у него моя программа будет тормозить. Скажи мне, это я в этом не виноват?


PD>А какое это имеет отношение к тому, о чем я говорил ? Если машина загружена сверх ее реальных возможностей — конечно, ты не виноват. А вот если реальные возможности машины позволяют загрузить 10 копий твоей программы (без вордов и эксцелов), будь она эффективно написана, а она написана так, что и 3 копии тормозят — виноват ты.

Я бы не стал так говорить. Можно просто программы классифицировать:
1. Резидентные программы на машинах пользователей. Они действительно должны быть компактными, не должны забирать много ресурсов компа, и не мешать пользователю выполнять его основную работу.
2. Резидентные серверные программы. Строго наоборот. Они должны адаптировать полностью ресурсы компьютера ради своей эффективности. И никак иначе.
3. Пользовательские программы. Наверно этот класс программ ты и имел ввиду. Вот именно это и есть путь для компромиса. И компромисс между функциональностью и ресурсами. Если функциональность нужная, и она требует достаточно ресурсов, то пользователь не будет возражать, по опыту знаю. Если в требованиях к программе не записано что попутно должны генерится сцены 3D Studio Max, то ему несложно будет выгрузить ее, или понять о том, что это была именно его ошибка. Но вот если функциональность ненужная, а требует достаточно ресурсов, то здесь и я сильно возмущаюсь(а такое на каждом шагу ). Но существует еще вопрос, что значит избыточность ресурсов? Если моя программа занимает на N мегабайт больше, и при этом я уверен что количество ошибок(которые есть будут и полностью их поубивать нельзя) значительно меньше, то я займу эти N мегабайт. В принципе, это и есть некоторая цель Net Framework. Пользовательские компьютеры сейчас избыточны. У них значительно больше памяти чем нужно, и процессоры значительно быстрее чем нужно для большинство задач. Но адаптируя избыточные ресурсы компьютера к цели уменьшить количество ошибок программ, я делаю больше для пользователя, чем таже программа — хоть и маленькая но ненадежная.

PD>Ты можешь сформулировать когда программу можно считать избыточной?


PD>Попробую.

PD>Программа избыточна, когда она
PD>1. Использует памяти больше, чем требуется.
PD>2. Загружает процессор больше, чем требуется.
PD>3. Хранит на диске файлы большего размера, чем требуется.

PD>А требуется — по характеру задачи.

Все это ресурсы избыточны для повседневной работы. Мне не жалко 20 мегабайт — если у меня их 500. Если у меня есть вариант, что адаптировав эту избыточность я повышену эффективность даже не программы. а разработки, я ею воспользуюсь.

PD>>>Или вот другой пример — с умножением матриц

GZ>>Вроде дошли до того, что здесь кэш процессора играет слишком большую роль.

PD>Дошли до того, что здесь виной перегрузка в кэше оверхеда на класс массив.Но по мне хоть кэш, хоть процессор, хоть винчестер, хоть дух святой. Не желаю я причин знать , а просто факт констатирую — машина это может в несколько раз быстрее делать, значит и должна делать!

Для данной конкретной задачи, это корректное замечание. Net — не очень подходит под числодробилки. Правда это можно сделать за пределами Net.

GZ>>Это взгляд со стороны. Разработчики все понимают. Но понимают и другое. Здесь уже несколько раз обсуждалось. Ошибиться в том, что ты неправильно определил место торможения, потратил много времени и сил на работу которая не нужна, значительно хуже. Поэтому лучше сначало сделать, а потом заниматься выявлением узких мест. А также оптимизацией памяти, если ее оказалось недостаточно.


PD>Ничего у вас не получится. Потому что эти узкие места вы, может, и найдете, а вот общий уровень все равно с оверхедом будет. Там Мбайт, здесь Мбайт — в итоге 100 Мбайт и виновных нет.

Нет. Не том и дело.
1. Если ты получил понятную программу, достаточно маленьку по исходным кодам, которую прочитает любой ребенок, и которая представляет вверх искуства программирования на ООП, это совсем не значит что она есть эффективна в плане использования памяти и процессора. Даже сказал бы наоборот. Но вот то, что в ней ошибки локализованы, сопровождать ее легко — это факт. После этого ее доводят до требуемого уровня производительности. Это делается легко, поскольку дизайн программы легко сопровождаем. Но это приводит к усложнению дизайна программ. А иногда и архитектуры.
2. Если ты начал предполагать в процессе построения программы, что вот здесь есть узкое место, которое написать оптимально, то
Во — первых, ты можешь ошибиться, это происходит часто, особенно на уровне конкретного программиста большого проекта. Например предположил что здесь надо бы переписать чтобы использовалось значительно меньше тактов процессора, но оказалось что сюда программа зайдет только один раз. И нагрузка на проц, в данный момент никого не волнует. Или когда компилятор делает оптимизацию за программиста, но он об этом не представляет, и тратит даром время при этом мешая компилятору. Это хорошо проявилось например в разности времени здесь
Автор: Serginio1
Дата: 29.09.05
. Оптимизация вполне корректна со стороны программиста, только компилятор уже это сделал.
Во — вторых, ты увеличиваешь сложность дизайна тогда когда он наиболее важен. В результате, при добавлении функциональности увеличивается количество ошибок. IMHO Это более тяжко чем неэффективное использование ресурсов.

Вобщем, мое мнение, что оптимизация программ по используемым ресурсам, должны проходить в 3 плоскостях:
1. При построении архитектуры. Мы еще видим все проблемы в комплексе, и наиболее крупные можем сразу решить.
2. Алгоритмическая оптимизация. Неэффективный алгоритм на порядки хуже неоптимизированного кода.
3. Оптимизация готового продукта под конкретные требования пользователя. Свое мнение я уже описал.

PD>А у ICQ вообще когда-нибудь не-беты были ? У меня что-то впечатление такое, что она только из бет и состоит

Нет, еще альфы. По моему — релизы там не бесплатные. Хотя могу ошибаться.

GZ>>Будет. Важно даже не то, что в бумажках написано. Важно доволен ли пользователь программы.


PD>Пользователь доволен. Вполне. И если он у тебя один — решай с ним все проблемы. А вот когда речь о продуктах, используемых в миллионах копий идет — тут задавать вопрос, доволен ли пользователь — все равно, что спрашивать, оуениваете ли вы положительно работу ГосДумы . Отдельно одной программой доволен, другой — доволен, третьей доволен, все вместе запустишь — недоволен. Жалуйтесь кому хотите, хоть господу богу.

Пользуйся альтернативами Я понимаю что в случае крупных монополистов — такое плохо проходит. Слишком высока сложность программ. Но нельзя так говорить о всей отрасли. Пользуются же мирандой вместо аськи.


PD>Бывает и такое. Как в известном анекдоте, как ни собираю, а пулемет получается. Но почему аналогия неуместна — не понял.

Потому что важно чтобы летал, а не с той скоростью которую пользователь не заказывал. В старое время бесшабашных программистов одиночек, они могли плавать, и даже нырять. Но летать не получалось. Сам такие программы писал, грешен.
Так что главное достигнуть цели. Если цель не достигнута, то уже ничего не важно.


GZ>>А на 512 легко. Но вопрос в другом. Если ты пишешь компилятор паскаля, то можно и в мег запихнуться. Но если ты будешь писать сервер приложений, и уместился в мег, то тебя в первую очередь должны выгнать. И я буду первым бежать и махать поганой метлой. Если тебе дали компьютер, с гигабайтом памяти, и с несколькими процессорами, то повышай эффективность используя все что тебе дали. Делай большие кэши, пользуй несколько потоков.


PD>Если я это сделаю, и все же уложусь в мег, ты меня все равно выгонишь ? Если я вместо буфера в несколько мег, в котроый все читается, использую MMF, в котором доступ будет только к тому, что реально требуется — тоже выгонишь ?

Да. Я вполне представляю весь процесс сооружения такой программы. Если ты потратил время на то, чтобы адаптировать решение на меньшие ресурсы, когда я знаю что ресурсы заказчика(или предполагаемого заказчика) значительно больше, то безусловно. Ты проделал работу, которая никому не нужна. Мало того, ты усложнил сопровождение программы. Для программ класса серверов приложений — я не вижу исключений из этого правила.

С уважением, Gleb.
 
Подождите ...
Wait...
Пока на собственное сообщение не было ответов, его можно удалить.