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

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

PD> И действительно, как было не признать! Пока программа небольшая и в память
PD>помещается — ладно, живите и радуйтесь! Ну а как побольше стала ? Тут-то и
PD>придется признать свое бессилие. А гуру, им что, всегда что-нибудь придумают.
PD>Кто-нибудь из нынешнего поколения слышал про "самоубийство программ" ? Нет, это
PD>не стирание EXE-файла во время его работы. Это когда программа во время своей
PD>работы использует память, занятую своими командами (которые уже отработали и
PD>больше не потребуются) под свои данные.
У меня это называлось overlay.

PD> В общем, если говорить серьезнее, эффективность у нас была всегда на
PD>первом плане. Не как-нибудь написать, а наиболее эффективным способом,
PD>не любой алгоритм использовать, а лучший для этого случая. На этом мы
PD>прочно стояли.
Эффективность бывает разной. Можно написать программу, которая будет выполняться в 100 раз быстрее, но и содержать в 100 раз больше ошибок. И отладить эти ошибки будет практически невозможно. Поэтому эффективность — это не только скорость и потребление ресурсов.

PD> Чудо называлось Turbo Pascal 1.0. Сказать, что он меня поразил — не то
PD>слово. И не меня только. Все, кто до этого Ямаху не видел (а их в Омск
PD>очень немного попало тогда) и кому я о нем говорил, отвечали мне одинаково-
PD>такого не может быть!
Ага, и встроенный бейсик в Ямахе тоже был.

PD> А потом компьютеры, хоть и не меньше и не больше по размерам стали, начали
PD>резко увеличивать свою память и быстродействие. Сейчас любят вспоминать
PD>пророчество Б.Гейтса — дескать, 256 Кбайт всем хватит.
Вообще-то Билли говорил о 640.

PD> Вот тут первые шаги в сторону пренебрежения оптимальностью уже и начались.
PD>Действительно, на машине 600 Кбайт свободно, машина однопрограммная,
PD>конкурентов нет, зачем мне пытаться программу в 100 Кбайт уложить ,если можно
PD>все 500 спокойно использовать. Впрочем, память памятью, а есть еще и
PD>быстродействие. Оно было еще очень маленьким, так что хотя бы в этом
PD>плане писать все же приходилось эффективно, выжимать из машины все, что можно.
PD>Так что писать старались все же эффективно, хотя десятком, а то и сотней
PD>лишних Кбайт уже не мелочились.
Ну да. Только памяти никогда не хватало. И задачи, которые надо было реализовать, становились все больше и функциональнее. И потом все эти перегрузки памяти из extented в expanded. Все ради эффективности программы. Но самое главное, можно было быть уверенным за 400 килобайт нормальной памяти, и что тебе никто в соседнем процессе мешать не будет. Если было больше 400, то у многих клиентов программы отваливались. Для запуска некоторых программ, приходилось здорово подредактировать config.sys и autoexec.bat. Так что абсолютного счастья тогда не было.

PD> Дудки вам, а не 640 Кбайт. В 640 Кбайт сейчас умеют только "Hello,
PD>World" укладывать! Пока несколько десятков Мбайт не будет, и не подходите.
Ты Турбо-Vision пользовался? Достаточно эффективная библиотека, с очень большими возможностями. Но из-за того, что возможностей много то занимала много обычной и самой дорогой conversional memory. Поэтому, либо пиши все ручками (это будет эффективно по скорости и памяти), либо используй библиотеку и борись за память. А потом проблемы ушли. Может это и к лучшему?
Я тоже горячился когда оказалось что exe файл для Delphi был больше мега(сейчас не помню, но для тех времен очень много). Но то, что я мог мышью быстро собрать приложение и получить за него деньги перевешивало. Как программисту который уважает свое творчество, это плохо. А вот для человека который пытается на хлеб масло намазать, чрезвычайно хорошо.

PD> Другой пример — сама Windows. Я прекрасно понимаю, что Windows NT 4 и
PD>Windows XP — не совсем одно и то же. Но та на 8 Мбайтах работала, а эта от
PD>128 нос воротит, подавай ей 256.
NT 4.0 на 8 мегабайтах не работала, а обслуживала саму себя. И то, если сервис паки не ставить.
PD>А ядро, вообще говоря, претерпело не такие уж большие изменения.
Так оно места то много не занимает. Оно действительно эффективно. А вот если говорить о сопутсвующих процессах, типа сервисов и т.д., или тех же картинок, то это и есть увеличение. С установкой сервис паков и добавления функциональности, ситуация выравнивается.
Хотя согласен, многое можно было-бы сделать пооптимальнее.

PD>программа занимала 8 Мбайт, если можно взять 64 ? Даже, пожалуй, наоборот-
PD>увидят, что твоя программа меньше памяти занимает, чем у конкурента — ну
PD>и решат, что та более крутая
Дудки, такого не было. Программа должна либо работать, либо не работать и тормозить. Это и есть показатель эффективности был, есть и будет.

PD> Я не против удобства и простоты. Я за. А вот что такое "достаточной" —
PD>извольте объяснить. Если машина однопрограммная — тогда, конечно, достаточно —
PD>если помещается в память и достаточно быстро работает. А в многопрограммной
PD>коммунальной квартире стоит еще и о других подумать. Потому как память хоть и
PD>большая, но не резиновая. И процессор пока что только один, как правило.
Если пользователь будет одновременно работать с моей программой, с 10 вордами, 50 акцессами, и 30 экселами одновременно, то у него моя программа будет тормозить. Скажи мне, это я в этом не виноват? Ты можешь сформулировать когда программу можно считать избыточной?

PD>Или вот другой пример — с умножением матриц
Вроде дошли до того, что здесь кэш процессора играет слишком большую роль.

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

PD>Хороший, кстати, пример — ICQ. Написана она не на .Net ИМХО (давно
Жадные вы. Че вам памяти жалко?
Во первых, ICQ — это глюк официально выходящий в альфа-бета видах. Притом накрученная функциональностей, которая особо никому и не нужна.
Во-вторых, не стоит по одной-двух программах делать выводы о отрасли в целом. Во времена MSDOS, были свои глюкавые монстры.

PD>Мне тут VladD2 упрек такой кинул — дескать, писать надо , не
PD>слишком думая об эффективности, а потом узкие места можно оптимизировать.
Подпишусь.

PD>Теоретически — совершенно безупречное рассуждение. А практически — это
PD>верно, если Вы заранее какой-то целью задаетесь — по памяти не более...
PD>или по времени не медленнее ... Если нет — никто и не будет оптимизировать,
PD>потому как совершенно непонятно, что и зачем. Работает каждый модуль раз в
PD>5 дольше , чем можно было бы, памяти кушает раз в 5 больше, чем надо было
PD>бы — что тут оптимизировать? Так и должно быть, все нормально сделали!
Будет. Важно даже не то, что в бумажках написано. Важно доволен ли пользователь программы. И хорошо ли ты написал, плохо ли, — клиент всегда прав. Ты можешь выжать 100 процентов оптимизации, но клиенту будет этого мало. И нравится тебе или не нравится, считаешь ли ты это нужным, или не считаешь, ты обязан это сделать. И тут никого не волнует даже то, умеешь ли ты оптимизировать, или не умеешь. Не умеешь, с голоду помрешь.

PD>В результате получаем некую самодвижущуюся повозку размером с аэроплан,
PD>ставим на нее ракетный двигатель, запускаем — едет! Едет ведь! Со скоростью
PD>60 км/час. Ну вот это и есть настоящий аэроплан, в серию его и пусть
PD>по дорогам ездит. А когда этим разработчикам объясняешь, что аэроплан
PD>должен не ездить, а летать, и не 60, а 900 км/ч давать, а если Вы автомобиль
PD>делали, то он и при двигателе внутреннего сгорания должен эти 60 (а то и 120)
PD>давать, да и размерами должен быть раз в 20 меньше — удивляются, чего, мол,
PD>привязался! Ездят же на нем, чего тебе надо!
Аналогия неуместна. Важно насколько клиенту важно чтобы он летал. Зачастую заказывают атомную подводный крейсер, а тебе выкатят Ту155 с 5 подводными винтами. И вроде двигается быстрее чем нужно. И летает, что не заказывали. И вроде винты красивые и их больше чем нужно. Но не плавает. Ну не успели научить.

PD> Создается впечатление, что рост быстродействия процессоров несколько
PD>замедлился. Может быть, я не прав, но мне кажется, что мы подошли к некоторому
PD>пределу, и если не последует технологического прорыва, то скорость сильно расти
PD>не будет. Еще раз — может быть, я не прав. Кстати, о памяти пока в этом плане
PD>говорить не приходится.
Не согласен. Уже вверх перестали развиваться такими темпами. Зато начали развиваться вширь.(двухядерные процы)
PD> Но так или иначе — этот предел есть. Очень уж четкие физические
PD>законы здесь действуют, их не обойдешь. Раньше или позже, но бурный рост
PD>мощности ПК заменится если не стагнацией, то более или менее плавным изменением,
PD>на проценты, а не в разы.
Это только что обсуждалось в соседнем топике.

PD> Не согласны ? OK, кто из вас взялся бы написать "Turbo Pascal 1.0"
PD>образца 2005 года? Который будет работать в такой маленькой памяти — 512 Мбайт
PD>и на таком медленном процессоре с частотой всего 3 GHz ? Боюсь, что Вы
PD>потребуете для этого 16 Gb памяти и не менее 30 GHz . Вы же прекрасно знаете,
PD>какие ресурсы для чего требуются, поэтому оцените их для этой задачи и получите
PD>16 Gb и 30 GHz, А где их взять? Впрочем, нет, не потребуете. Вы даже задачу
PD>такую не поставите — Вам она и в голову не придет: Боюсь, что мы даже и не
PD>узнаем, что могло бы быть написанным, если бы это эффективно делалось...
Не забывай. Компилятор Турбо-Паскаля практически полностью написан на ассемблере. И не от хорошей жизни. А письмена на ассемблере, даже тогда считались делом излишним и слишком крутым для повседневных задач. Попробовал бы ты описать паскаль в самом паскале. Тогда бы ты точно не запихнул это в 64 кил.
А на 512 легко. Но вопрос в другом. Если ты пишешь компилятор паскаля, то можно и в мег запихнуться. Но если ты будешь писать сервер приложений, и уместился в мег, то тебя в первую очередь должны выгнать. И я буду первым бежать и махать поганой метлой. Если тебе дали компьютер, с гигабайтом памяти, и с несколькими процессорами, то повышай эффективность используя все что тебе дали. Делай большие кэши, пользуй несколько потоков.

PD> Ну и к чему автор призывает, спросите Вы ? К поголовному возврату на
PD>ассемблер
PD>и к 64 Кбайтам ? К отказу от того пути, по которому сейчас пошло развитие ?
Знаешь, мне как программисту хочется вернуться туда. Все было интересней. Компы знали как свои пять пальцев. Но вот как главу семейства — ни в коем случае.
Я живу в своем времени. Если понятия эффективности изменились, то я их принимаю. Я делаю программный продукт, а не поделку для удовлетворения собственного эго. Я могу написать Паскаль на 64 килобайта. Но не буду. Не потому что это сложно. Ничего сложного в этом нет. Нужно просто уметь выжимать 100 процентов из компилятора и архитектуры. Это просто никому не нужно. Времена 64 килобайт прошли. Сейчас стало легче жить. И это хорошо.

PD>Пишите свои программы эффективно, господа! По крайней мере настолько, насколько
PD>это возможно!
Слишком абстрактно. Надо сначало описать, что такое эффективность. Именно в нынешние дни.

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