Здравствуйте, Pavel Dvorkin, Вы писали:

GZ>>2. Резидентные серверные программы. Строго наоборот. Они должны адаптировать полностью ресурсы компьютера ради своей эффективности. И никак иначе.

PD>+-. И да, и нет. Потму как этих серверных программ на машине может быть несколько, и лучше бы им не брать все ресурсы компьютера, а то придется по серверу на каждую программу иметь.
Тут я забыл указать некоторый термин. А именно масштабируемость. Как-то повелось, что каждый смотрит на этот термин со своей колокольни, но рискну дать определение. Масштабируемость — способность увеличивать КПД программы в зависимости от аппаратных средств. То есть, вместо того, чтобы переписывать программу когда не стало хватать пропускной способности, заказчику достаточно купить дополнительную память, или дополнительный процессор, или дополнительный компьютер для кластеризации приложения. У масштабируемых решений практически всегда присутсвует одно свойство. Оно всегда медленнее их немасштабируемых аналогов. Если один или два пользователя, то немасштабируемое приложение масштабируемое порвет как грелку. Но масштабируемость это не просто лейбл. Это действительно очень полезное средство для пользователя. Хреново когда придется переписывать программу, или заказывать другую. И дело не только в деньгах. Дело еще в обучении пользователей для нового продукта, проходить весь цикл установки и настройки. Поэтому использование аппаратных средств — важное свойство серверов приложений.
Архитектор обязан следить за масштабируемостью серверов. Вот если он не следит, то это значит недоучка. Ну а недоучки — это тема других топиков.

PD>Если я напишу это же без FrameWork, алгоритм будет тот же, эффективность выше и памяти меньше, то это будет лучше.
В данном случае да. Но можно сделать и так, в случае большого объема приложения, написать основную программу на Net Framework, а наиболее криминальные алгоритмы написать на unmanaged C++(благо он лучше умеет использовать и управлять ресурсами компьютеров).

PD>А то, что на FrameWork ошибок будет меньше — не уверен. Не все сводится к мемори ликам и некорректным индексам.
Да. И это правда. Не все сводится к мемори ликам. Компонентность тоже провоцирует не делать ошибок. А если приложение большое и многофункционально, то недооценивать компонентность нельзя.
Кроме того, тут стоит говорить не только о Framework, но вообще о языках высокого уровня. Не секрет, что язык высокого уровня генерит избыточный код и избыточно использует память. И чем выше язык, тем труднее поддается оптимизация кода компилятором. В принципе, если взять тот-же STL, то говорить о том, что он по скорости 1 в 1 с кодом написанным вручную на С не приходится. А string вообще кошмар, но зато жутко удобный. И только великолепие и сложность компилятора более менее выравнивает ситуацию.

PD>От ошибок алгоритма меня никакой FrameWork не защащает. Складывать килограммы с метрами (вместо того, чтобы умножать) и там вполне можно, .
От этого никто не сможет защитить. Особенно от непроффесионализма. Но тут никто не властен.


>>Пользовательские компьютеры сейчас избыточны. У них значительно больше памяти чем нужно, и процессоры значительно быстрее чем нужно для большинство задач.

PD>Я бы эту фразу перевернул.
PD>Большинство программ таково, что они используют значительно больше памяти и процессорного времени, чем им в действительности нужно. Поэтому программ, которые могли бы при оптимальной эффективности использовать память и процессор, не существует (почти), так как при нынешнем стиле написания программ им нужны намного большие ресурсы, которых пока нет.
Фразы не эквивалентны.
Вообще я бы сформулировал свое мнение так. Функицональность возрастает, и аппаратная часть адаптируется под нее. Или наоборот, аппаратная часть возрастает, и функциональность адаптируется под нее. Не важно какая из них верна.

GZ>>Все это ресурсы избыточны для повседневной работы. Мне не жалко 20 мегабайт — если у меня их 500.

PD>Во-во. Тебе надо 20, а берешь 40. Мне надо 50 — беру 80. Ему надо 100 — берет 150. А этому надо еще 100 — пошел вон, памяти больше нет.
А это уже прямой путь в леса богатые дичью. Поверь мне, везде где я работал всегда думали о компьютерах пользователей. Иначе прогоришь.

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

PD>Да, увы, это так. Ты сделаешь быстрее, не спорю. И сэкономишь несколько К$ на своей зарплате. А в итоге 100,000 пользователей потратят несколько сотен тысяч $ на память, которую твоя программа заняла и не использует.
Обычно если заняла, то использует Если не использует — то это ошибка. Если избыточно использует — ошибка алгоритма.
Пользователей больше занимает полезность программы.

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

PD>Да ведь нам говорят, что .Net — генеральная линия развития, а те, кому она не нравится — неандертальцы. Вот и мне сегодня заказчик сообщил, что планирует нечто на .Net. Пока не знаю что. И не убедишь его, что это , м.б. не лучшее решение.
Ты сам аргументировать не можешь. Если это сложная программа с множеством взаимосвязей и сложной архитектурой, то да. Это будет хороший выбор. Аналог в виде Java — не сильно отличается.

PD>"У нас никогда нет времени на то, чтобы сделать все как следует, но всегда есть время на переделки"
В сложной программе с множеством модулей, взаимосвязей и народа который все это пытается связать — сразу сделать как следует невозможно. Также как написать программу без багов, это должна быть очень простая задача.

PD>Ну и заявление! Дизайн понятен, сопровождение легко, след-но, оптимизировать будет несложно! А то, что для оптимального решения задачи, возможно, надо не в деталях оптимизировать, а все решение пересмотреть и весь дизайн переделать — это ты не допускаешь ? Совсем другим способом ее решать!
Это — ошибка архитектуры. Тяжелая ошибка. Ее боятся. К ней надо по правильному подходить, либо работать методиками которая не подразумевает первоначальное построение архитектуры(типа XP). Все ХР и построено на том, что функционал достраивается, а следовательно нужен понятный и сопровождаемый дизайн. Ради этого рефакторят. И основным свойством кода является не эффективность в плане выполнения, а именно сопровождаемость. Эффективность в плане выполнения — выравнивают потом. Там вообще не знают и не хотят знать, войдет ли или не войдет данная функциональность в том виде в котором она разрабатывалась на начальном этапе.

GZ>>Во — вторых, ты увеличиваешь сложность дизайна тогда когда он наиболее важен. В результате, при добавлении функциональности увеличивается количество ошибок. IMHO Это более тяжко чем неэффективное использование ресурсов.
PD>ИМХО это лечится рано или поздно, а первое — не всегда.
Как раз ошибки вылечить на порядок сложнее. А иногда и невозможно. В непонятном коде значительно сложней найти и локализовать ошибку. Иногда этот код легче переписать чем исправить(такое встречалось), или добавить функциональность. В простом, понятном коде, в котором функицональности все выделены в раздельные сущности, переписать что-то легко. Благо понятно что делаешь.

PD>Да, а вместо Net Framework что предложишь ?
Java. Нельзя от печки требовать, чтобы она стала сново кирпичем. Так и нельзя от net или лиспа, чтобы они управляли ресурсами компьютера также эффективно как это делает более низкоуровневый собрат С++.

PD>Вместо MS Office ?
Тут согласен. Я это и не скрывал.

PD>Опять -таки — все верно, если у тебя единственный заказчик. Ему хоть на 2Gb пиши, если у него их 4. Но я-то о других случаях говорю.
Да хоть тысячи. Перед построением программы, всегда строится примерная картина для кого эта программа предназначена, и что у него есть.

С уважением, Gleb.