И поверь,оптимизировать чтение из файла путем замены двух сопутствующих операторов я тоже не призываю. а вот когда некие умники начинают из файла по одному байту читать — это уже другой разговор.
Но потом решил, что слишком много написал, и эта история может оказаться интересна не только Pavl-у Dvorkin-у (его все равно этим не проймешь), а в столь глубокой подветке ее никто не заметит. Может быть эта история остановит хоть часть последователей гордых борцов за производительность бьющих себя пяткой в грудь и гордящихся своим мировозрением.
Так вот...
PD>И поверь,оптимизировать чтение из файла путем замены двух сопутствующих операторов я тоже не призываю. а вот когда некие умники начинают из файла по одному байту читать — это уже другой разговор.
От как раз на эту тему могу рассказать призабавнейшую историю из своего опыта.
Когда я только учился программировать передо мной была поставлена задача написать замену Norton Guide. Norton Guide — эта такая ДОСовская резидентная программка которую можно было активизировать поверх других текстовых ДОСовских приложений и почитать тот или иной мануал. Если не ошибаюсь к Клиперу хэлп на нем был сделан. Так вот я создал вместо него некий прообраз современного HTML-браузера, но в текстовом интерфейсе. Как и в Norton Guide, в отличии от современных браузеров, я хранил информацию в едином файле. Естественно подготавливать такой файл напрямую было невозможно. Так что на вход я получал обычные текстовые файлы размеченные специальным образом, а на выходе выдавал этот самый файл в котором запаковывалась вся информация из этих файлов.
Делал это специальный компилятор.
Писал все это дело я на С.
Первая версия этого компилятора была создана мной очень просто. Я просто читал по одному символу из входного потока, анализировал (благо грамматика была LL(1), вот только я тогда этого не знал ) его и формировал выходной поток и записывал его (уже более большими кусками) на диск в тот самый выходной файл. Потом делался второй проход в котором разрешались ссылки, но это уже детали. Главно, что в обоих проходах я как раз читал файл посимвольно.
Отлаживался я на довольно коротких файлах, так что проблем с производительностью не видел.
Конечным продуктом пользовался мой отец, который лабал на этом деле некую справочную систему по бухучету и т.п. Естественно через некоторое время отец дошел до объемов когда компилятор начал работать очень медленно. И хотя я к тому времени разработал технологию инкрементальной разработки (когда куски справочной системы отлаживаются по отдельности, а потом сливаются воедино), но все же хотелось сделать все настолько быстро насколько это было возможно.
Так вот это был первый, в моей жизни, случай оптимизации.
Как раз в это время у меня на столе появился 386 SX, аж с 4 метрами памяти на борту. Естественно я сразу же водрузил на него Windows 3.1 и выклянчил покупку С++-компилятора Семантик С++ (бывший Zortech C++, но с IDE под Windows). В поставке Семантик С++ была Win32S. Если кто не в курсе, это такой хитрый хак для 16-битного Вынь 3.1 позволяющий писать, отлаживать и выполнять почти полноценные 32-битные приложения. "Почти" потому как все вызовы 32-битного АПИ транслировались в аналогичные 16-битные вызовы, а многих функций из Вынь32 в Вынь16 попросту не было. Ну, например не было функций работы с многопоточностью. Ну, да это не важно. Возвращаемся к нашим баранам...
Почти одновременно с покупкой Семантика я докупил к машине еще 4 метра памяти и у меня ее стало аж 8 мегобайтищь! По тем временам огромная память!!! Заполучив в свое распоряжение это богатство я смекнул, что читать файлы по одному символу не эффективно!!! Вывод этот я сделал так же как Pavel Dvorkin, то есть чисто из своего чутья, которого у меня надо признать тогда было в избытке, но оно было еще круче чем чутье легендарного Pavl-а Dvorkin-а.
Так вот сделав вывод что читать по символу не эффективно я стал думать как же читать большими блоками и каков должен быть размер этих блоков. На первом проходе все было просто. Исходные файлы не превышали 32 килобайта, так что я читал их одним залпом и особых проблем не испытывал. Но вот на втором проходе я имел уже многомегабайтный файл заведомо не влезавший даже в огромнейщие 8 метров (а может это было 4, но да не важно ).
Напомню, что программировать я тогда по сути не умел. Это были первые потуги. Причем у меня не было никакой начальной базы. Зато был невероятный задор и желание свернуть горы (эх так и хочется поныть на тему какое замечательное время было тогда... ).
Так вот я принял "самое разумное решение" — я выделил буфер максимального размера и стал считывать в него (на втором проходе) часть этого самого огромного файла. Задача второго прохода (я уже ее почти не помню, но по сути...) была разрешение ссылок. Ну, на пером проходе появлялись ссылки на файлы которые читались только в последствии. Как точно я изворачивался не помню, но общий смысл был в том, что я вставлял некую заглушку которую заменял во втором проходе на конкретную ссылку.
Так вот чтобы распознать эту заглушку нужно было считывать файл последовательно и анализировать символы. Некая последовательность символов говорила, что это ссылка. Далее нужно было прочесть заглушку, найти соответствующую ей ссылку и вставить эту ссылку в выходной файл (а может в тот же, уже не помню, но не суть...).
Когда я читал символы последовательно, проблем в распознавании этой последовательности предшествующей ссылке не было. Я читал один символ... Если это был некий Х, то читал следующий, и если это был У, то было ясно, что передо мной ссылка и нужно действовать.
Похожим образом же я поступил и в буферизированной программе. Но я уже проверял подстроку а не отдельные символы. Так ведь было эффективнее! Программа получилась значительно сложнее исходной, так как приходилось подчитывать и записывать буферы, а потом проходиться по ним. За то после прогона этой версии компилятора на рабочем файле я был поражен! Она работала в разы быстрее исходной! Я был счастлив. И счастье длилось до тех пор пока отец не обнаружил, что некоторые ссылки в готовом файле по просу не работают.
Я начал искать ошибку...
Напомню, я только начинал программировать и это была моя 3-я программа в жизни (первые две — это сама резидентная программа и первая версия компилятора).
Так вот я тупо смотрел в код и не видел места с ошибкой. Через неделю потения (в прямом и переносном смысле) я таки понял в чем дело. Дело было в том, что иногда, причем очень редко, спецсимволы попадали на край блока. Казалось бы — "вот проблема?!". Но для начинающего программиста это оказалось очень не просто. Я протупил над решением еще кучу времени.
Первым моим решением было — сэмулировать getch() которым я читал данные в первом варианте компилятора. Но я тут же сделал очередное гениальное предположение в котором нисколько не сомневался. Звучало оно так — на возню с передачей символов и анализ по одному символу я убью кучу времени и моя программа станет не эффективна!
Поясню... В первой версии компилятора я проверял подстроку предшествующую заглушке посимвольно. Находя очередной символ я поднимал флаги до тех пор пока не был уверен, что передо мною именно ссылка (через много лет я узнал, что это называется ДКА, но тогда я даже подумать не мог что изобрел столь мудреную вещь ). Во-второй же версии компилятора я воспользовался преимуществом буфера и стал проверять подстроку, изученной мною к тому времени, функций strncmp()! По всем умным книжкам и моему чутью (ну, и наглец я был тогда!!! Программировал без году неделю, а уже было чутьё! Ну, да у некоторых оно не просыпается и к преклонному возрасту) использование этой могучей функции должно было существенно ускорить работу программы. Кстати, функция эта действительно быстрее чем посимвольные проверки так как она была реализована на ассемблере, а компиляторов в то время умом не отличались.
В общем, я уже не помню как я решил эту проблему, но точно помню что решил довольно эффективно (с моей тогдашней точки зрения, которая тогда была полностью аналогична сегодняшней точке зрения ну вы сами знаете кого ). Если не ошибаюсь я просто стал проверять не оканчивается ли блок на тот самый заветный символ начала гиперссылки поднимая специальный флаг который проверялся на следующем шаге итерации. Думаю, не надо объяснять, что такое решение еще больше усложнило алгоритм?! Естественно, что на такие выкрутасы начинающий упорный оптимизатор убил еще не мало времени.
Но игра стола свеч!!! Скорость была потрясающая. Все конечно относительно, но по сравнению с первой версией компилятора эта версия просто летала! Ура!!! Первая победа оптимизатора! Я был счастлив... я пел и ликовал... ровно до тех пор пока мне не рассказали про Smartdrv. Если кто не в курсе — это такой драйвер в ДОС который кэшировал доступ к жесткому диску и ускорял тем самым операции с ним.
Когда я включил смардрайв, запустил старую версию компилятора, засек время и сравнил его с временем работы нового компилятора — я был поражен. Нет, это не то слово! Я был дико ошеломлен, поражен, подавлен, удивлен и растерян!!! Я хотел плакать! Столько усилий коту под хвост. А ведь если не считать того что у нового компилятора была модная GUI-шная морда лица, то других преимуществ у него не было.
Зато код нового компилятора был ужасен! Причем ужасен на столько, что даже не опытный прграммист по сути еще не знакомый даже с принципами структурного программирования смог оценить НАСКОЛЬКО УЖАСЕН этот код!!!
Естественной реакцией было — не верю! Я где-то ошибся в измерениях!!!...
В общем, следующие три дня я провел в проверках. Ведь я мог в чем-то ошибиться.
Скажу честно — очень хотелось найти эту самую ошибку. Ну, больно не хотелось признавать тот факт, что из-за недостатка знаний, опыта, из-за своей самонадеяности и т.п. я убил море своего времени не получив ровным счетом ничего в замен. Вернее получив практически отрицательный результат.
Сейчас, то я понимаю, что время не было убито зря. Это был бесценный опыт который не раз в последствии остановил меня от опрометчивых поступков и заставил относиться к своим предположениям более скептически. Теперь я понимаю, что даже самые маловероятные вещи могут повлиять на результат, а всякое предположение может быть неверным или практически не верным. Практически не верным значит то, что, например, чтение большим буфером и отказ от посимвольного анализа должны, да нет просто обязаны, дать повышение производительности, но на сколько? Ведь это повышение может оказаться несоизмеримо с основными затратами приложения.
Так в чем еж была моя ошибка? Думаю, почти все уже поняли в чем. Я недооценил того что основное время мои компиляторы тратили на чтение (и запись) данных с диска. По сравнению с этим разница между strncmp и банальными сравнениями была мизерной. К тому же проверял я 2-3 символа и strncmp банально не мог показать своей прыти. Зато накладные расходы на вызов функции присутствовали. Правда они присутствовали и в пресловутом getch() вызываемом при считывании каждого символа. Но опять же эти затраты мизер по сравнению с чтением данных с диска.
Когда данные читались с диска действительно по байтно чтение одного символа выливалось в ужасно затратные операции вроде передвижение головок винчестера и считывание информации с дорожки. Смартдрайв же привел к тому, что все эти накладные расходы исчезли. Функция getch() в большинстве случаев просто обращалась к буферу в памяти. Это было очень быстро. Ведь в ДОС все было в одном адресном пространстве и обращение к драйверу было не более чем банальным вызовом метода. А учитывая, что драйверы писались на ассемблере и то что параметры ДОС-овских вызовов передавались через регистры процессора скорость была даже выше чем в моей программе.
С тех времен прошло уже 12 лет (если не ошибаюсь). И мне казалось что уже все знают, что посимвольное чтение из файла — это совершенно не смертельно. Но вот появляется еще один перформанс-варьер который не был столь прозорлив чтобы наступить на эти грабли 12 лет назад, и делает смелые заявления
И поверь,оптимизировать чтение из файла путем замены двух сопутствующих операторов я тоже не призываю. а вот когда некие умники начинают из файла по одному байту читать — это уже другой разговор.
VD>Но потом решил, что слишком много написал, и эта история может оказаться интересна не только Pavl-у Dvorkin-у (его все равно этим не проймешь), а в столь глубокой подветке ее никто не заметит. Может быть эта история остановит хоть часть последователей гордых борцов за производительность бьющих себя пяткой в грудь и гордящихся своим мировозрением.
Влад, это все хорошо конечно, спасибо за рассказ. Но как-то злобно очень. Типа "вы все п...сы, а я — Дартаньян". Ну почему ты так неуважительно отзываешься о Павле Дворкине? Он старше нас с тобой, между прочим. И гораздо опытнее. И то, что твое мнение не совпадает с его, ни в коем случае не значит, что ты прав, а он — нет. Выражаясь тюремной феней, ты пытаешься "зачморить" всех, кто с тобой не согласен. Не надо этого делать. Это очень некрасиво выгдлядит.
Я тоже писал резидентный help. Я его так и назвал — MaxHelp или MHelp. Занимал в памяти он 5K и работал очень шустро. Это был полноценный гипертекст, только без картинок. К нему прилагался компилятор, собирающий файлы из текстового вида. И этот компилятор тоже читал файлы по-символьно. Но через некую свою прослойку. Я очень быстро обнаружил, что fread по одной букве работает медленно. Далее я обнаружил, что вызов int21 для прямого посимвольного чтения — это еще раз в 100 медленнее. Каков выход? — читать блоками через int21, а выдавать по-байтно. Фактически, это эмуляция fread, но с гораздо меньшими накладными расходами. Буфера в 256 байт оказалось вполне достаточно. Это для компилятора. В самом резиденте надо было читать как вперед, так и назад. Ну что же, для этого делается всего-навсего двойной буфер — 512 байт и он "поддергивается" в нужные моменты функцией memmove. Все! Была обеспечена и скорость и O(1) памяти. Работало и на меговых файлах без какой-либо видимой задержки на 286/12MHz. Я потратил на отработку этой стратегии пару дней. Это является тривиальнейшей задачей. И "программизм" как таковой здесь вообще ни при чем. Здесь требуются инженерные навыки или даже просто "common sense" как говорят буржуи-пиндосы.
Так что ты хотел сказать-то этой историей? Продемонстрировать свое невежество? Думаю, что нет. Но тем не менее, у тебя это вполне получилось. Извини за резкие слова.
McSeem
Я жертва цепи несчастных случайностей. Как и все мы.
Здравствуйте, VladD2, Вы писали:
VD>Видимо. Остается только понять виноват ли в этом я или те кто читал.
Начинаем разбор полетов.
То есть, переводя на русский язык, ты сначала:
E>Когда я читал символы последовательно, проблем в распознавании этой последовательности предшествующей ссылке не было. Я читал один символ... Если это был некий Х, то читал следующий, и если это был У, то было ясно, что передо мной ссылка и нужно действовать.
Потом:
VD>
Первым моим решением было — сэмулировать getch() которым я читал данные в первом варианте компилятора. Но я тут же сделал очередное гениальное предположение в котором нисколько не сомневался. Звучало оно так — на возню с передачей символов и анализ по одному символу я убью кучу времени и моя программа станет не эффективна!
Получается противоречие. Сначала посимвольный анализ был для темя простым и логичным, а при "эмуляции getch()" он ни с того ни с сего вдруг стал плохим? Не вижу никакой логической связи. Зачем надо было отказываться от уже отработанного решения?
Далее. Ты решил анализируешь строки а не символы. Пожалуйста, имеешь право. Но тогда возможность попадания ссылки "промеж буферов" — это первое, что приходит в голову при наличии элементарных инженерных навыков (повторюсь — самых элементарных). Следующая мысль "инженерного типа" — это то, что выносить такую ситуацию в особый случай — это плохое решение, поскольку оно неоправданно усложняет логику (насколько я понял, ты на нем и остановился). Это как раз и есть та самая "оптимизация", против которой ты так яростно выступаешь — она действительно никудышная. Нормальным решением было бы сделать буфер из двух последовательных частей. Как только наш указатель в буфере вылезает за пределы первой части, она становится ненужной. Следовательно, мы имеет право скопировать вторую часть на место первой, после чего дочитать следующую порцию из файла размером в полбуфера. Все! Мы имеем полное право пользоваться строковыми фунциями с гарантией неразрывности. Логика здесь тривиальна, она не тянет ни на какой "алгоритм". И накладные расходы на копирование — мизерны. Засада может случится только в случае, если размер токена превысит размер полу-буфера, но это можно объявить ограничением на использование. Такая цепочка рассуждений является нормальным инженерным, дизайнерским и оптимизационным решением. У тебя же присутствовал какой-то бессистемный поток сознания, из которого ты сделал глобальный по жизни вывод, что оптимизация — зло. Она и есть зло, если в башке бардак.
Я вообще удивляюсь, что тебе понадобилась "неделя потения" на то, чтобы понять проблему разрыва ссылок.
Теперь о smartdrv. Ты говоришь, что испытал некий шок. Но этот шок как раз и является следствием невежества. Получается, что твоя программа зависит от smartdrv и может работать только с ним. Но ведь тот же NortonGuide прекрасно работал и без всяких smartdrv. И чего тогда твоя "программа" стоила, если она требовала некую "ускоряющую приблуду"? Типа все нормальные программы ускоряются от smartdrv в полтора-два раза на дисковых операциях, а твоя ускорялась в десять раз? Один этот факт говорит о том, что программа — отстой.
Более того, из всего этого ты сделал совершенно ложный по жизни вывод, что оптимизация непременно приводит к ухудшению дизайна. Так вот, я скажу, что это — чушь. Нормальная оптимизация только помогает и способствует хорошему дизайну. Но то, что лично ты считаешь оптимизацией, на самом деле ей не является. Это — не оптимизация. Для этого есть даже специальный термин — spaghetti-code.
McSeem
Я жертва цепи несчастных случайностей. Как и все мы.
Фуу, давненько не пересекались, но ощущения все те же, все те же. Попробуй представить себе ситуацию, что собеседник тебя все-таки прекрасно понимает, и тратит на обдумывание твоих постов гораздо больше времени, чем ты тратишь на посты собеседника (это видно невооруженным взглядом... этот вопиющий факт уже просто на грани оскорбления — настолько по диагонали читать оппонентов )
В общем, так. Свой первый пост ты предоставил в настолько разжеванном виде, и до того гипертрофированно стоят акценты в нужных местах, что основной посыл поймет даже человек, весьма далекий от программирования как такового. Давай условимся считать, что оппонент понял, просто не согласен, либо же имеет замечания/дополнения.
V>>Я с 1990-го работал на Turbo C, там можно было менять размер буфера структуры FILE (ты же ее использовал?)
VD>Я уже не помню что я использовал. Название getch и то взято на абум как одно из близких. К делу это отношения не имеет. Ты просто вообще ничего не понял из написанного. Попробуй перечитать текст не обращая внимания на технические детали.
Очевидно, настала моя очередь "разжевывать". Отвергать преимущество оптимального кода над неоптимальным пока никто не собирается. И даже ты относишься к этому делу всего лишь взвешенно, примерно как и я, как и подавляющее большинство разработчкиков с некоторым опытом. Когда речь идет об усилиях, затрачиваемых на оптимизацию, то мы всего лишь оцениваем отношение объема этих усилий к получаемому положительному эффекту (оговорюсь опять — за исключением случаев, когда на быстродействие и потребляемые ресурсы накладывается ограничение либо непосредственно в ТЗ, либо коссвено, выплывает на стадии анализа через смежные/используемые программные и аппаратные технологии)
Так вот, если уж речь идет об отношении затраченных усилий к полученному эффекту, то очевидно, что необходимо минимизировать потраченные усилия, либо отказаться от их траты, если получаемый эффект невелик. Так вот, ОЧЕНЬ ЧАСТО т.н. "оптимизация" ничего не стоит, никак не портит программу, не усложняет код и не требует полного повторного цикла тестирования. Мы давно пишем свои программы не с 0-ля, не с машинных кодов, а основываясь на весьма мощных платформах весом в миллионы строк исходников. Владение информацией об этом окружении помогает выбрать оптимальный путь решения задачи. Сам выбор оптимального пути уже является оптимизацией, даже если разработчик не потратил ни лишней минуты на это. Назовем это дело по другому: "грамотное инженерное решение".
Ты в своем посте красочно обрисовал тонны потраченных усилий, были ярки картины загубленной красоты исходников... Ты ведь "потомству в пример" это все написал, признайся? Так вот, потомство должно так же знать, что недостаточное владение инструментом может породить все эти проблемы даже при решении такой несложной задачи как буферизация ввода.
Опять же... Требования и еще раз требования... Ну почему мы всегда обсуждаем что-то абстрактно, и как тут можно понять, чьи позиции устойчивее, если контекст не задан? Более-менее воссоздать картину можно попробовать из твоих эмоциональных акцентов. Но где гарантия, что их правильно истолковали? А может быть ты тогда не совсем правильно истолковал внешние условия? Какой был процент "покрытия" этими кеш-драйверами? Предназначалась ли твоя прога и для XT? Даже для тех, у кого 256кБ? (На них эти всякие кеши не ставились принципиально никогда, но тем не менее одно время таких машин было достаточно)
VD>Посыл явно непонятен, раз ты продолжаешь рассуждать о каких-то там структурах и версиях компиляторов.
Ловко, однако не зачтено.
Диктую большими буквами: ЕСЛИ ВАМ И ПРОЕКТУ ЭТО НИЧЕГО НЕ СТОИТ, ТО ВЫБИРАЙТЕ НАИБОЛЕЕ ЭФФЕКТИВНОЕ РЕШЕНИЕ ЗАДАЧ НА ЛЮБЫХ УРОВНЯХ.
Ключевая фраза: "ничего не стоит".
Понимаешь, этот закон распространяется не только на ПО, а вообще на всю инженерию. Правда он там звучит чуть построже, без первой половины, а в конце добавляется.. ну примерно следующее: "в рамках сроков и бюджетов проектов".
Кстати, эта формула верна и для ПО, выполненного не на заказ, а предназначенного для агрессивной конкуренции.
Просто лоскутковый бизнес ПО и дефицит программистов привел к разбалованности этого "избранного" семейства инженеров и о ужас... к самому факту обсуждения таких, казалось бы, фундаментальных вещей.
Но тем не менее, факт остается фактом. Тысячи и тысячи программистов пишут одно и то же, выпускают массу продуктов очень близкой функциональности, все получают немаленькую ЗП, и вопрос минимизации затрат на разработку ПО встает в гораздо более жесткой форме — быть бизнесу или же провалиться с треском. Отсюда все эти веяния. Теперь примерно понятно, почему я там 3 поставил?
В своей жизни я уже успел написать несколько учетных систем, массу системных и т.д. и т.п. И очень многие мои коллеги так же. Кое какие продукты используются до сих пор, кое-какие скоро начнут активно использоваться (я очень надеюсь). Однако, я ни на секунду не забываю, что программист (и я в том числе) сейчас используется крайне неэффективно. Процесс раздела рынка ПО сейчас в самом разгаре, и продлиться по прогнозам еще не менее 20 лет, т.е. сейчас рулят правила джунглей. А правила не гласят — "сделай лучше всех", правила гласят: "сделай всех", или еще короче: "выживи". И вот такой вот внешний контекст оказывает весьма серьезное влияние на умы даже опытных разработчиков, да такое, что они в пылу спора уже и не помнят, где причина а где следствие обсуждаемых вещей.
Ну представь хоть на секунду, что в стремлении выпустить, например, новую Тойоту на рынок, с новыми, прямо-таки космическими внешними обводами, фирма Тойота пошла на следующие допущения:
— Весит в 2 раза больше, однако, по-прежнему шустро ездит за счет более мощного мотора
— Топлива она жрет в 2 раза больше
Такое может привидется только в кошмарном сне кокого-нибудь инженера Тойоты. В реальности, каждая следующая модель выходит со все лучшими характеристиками, ос более оптимальным весом, с большим КПД (люди, вы еще помните это слово) двигателя.
Но ведь это не удивительно, над новой моделью работаюбт сотни инженеров. А у нас, у программистов, примерно 5-15 человек делают проекты, по информационной сложности мало уступающие проекту той же Тойты. Поянтное дело, что для самого факта успешности подобных проектов жизненно необходимо максимально все упрощать и выкидывать все лишнее (и оптимальные пути разумеется тоже). А иначе как? Человеческий мозг — весьма ограниченная в своем объеме штуковина.
... Хотел еще примеров написать, но вроде и так общий (самый общий) мой посыл должен быть понятен.
А что касается конкретных выводов для молодого поколения: ребята, исходим из того что есть (собственно, это и есть формула выживания ).
То, что современное положение дел малость не нравится некоторым "динозаврам" и "птеродактилям" пусть не беспокоит. Отнестить к этому можно с долей прагматичности — по-максимуму выведывать у склонных к сентиментальности "старичков" (35-45 лет) секреты активно утрачиваемого мастерства. Возможно, вам оно когда-нибудь пригодится.
V>>Ответ в том, что иногда оптимизация достается весьма малой кровью. И как вывод: вовсе игнорировать возможность оптимизации не стоит (собственно, я настаиваю на таком подходе). Надо лишь соизмерять потраченные усилия и получаемый эффект.
VD>Дажа малая кровь в сумме может привести к смерти от обезкровлевания. Но тут важнее не это. Важнее то, что миросозерцание пропагандируемое тов. Dvorkin-ым (против этого миросозерцания и был направлен этот рассказ) приводит к тому, что люди начинают пытаться написать максимально оптимальный (с точки зрения производительности) код и вместе с водой выплескивают ребенка.
Я бы не стриг всех под одну гребенку. К счастью, в крайности бросаются не многие. А что касается текущего положения дел, то на само понятие "эффективности" молодое поколение просто забило. Влад, даже ты пишешь свои программы более менее эффективно (сужу по публикуемым кускам). Ты по другому не можешь, хоть и озвучиваешь другую точку зрения. (гы-гы, кстати). А у нового поколения — ни стыда ни совести по отношению к ресурсам аппаратуры или сети. Я двумя руками за то, чтобы все эти темы по прежнему активно обсуждались, и народ хоть имел представление о том, что оптимальность решения инженерных задач по прежнему в цене. Просто в этих ценах надо ориентироваться (не устану повторять...)
В споре рождается истина, только дураки учаться на своих ошибках и т.д. Как еще молодым научиться оценивать тот хрупкий баланс м/у потраченными усилиями и получаемым эффектом? И еще немаловажно, куда эти усилия тратить. В описанном тобой примере их стоило потратить не на кодирование, а на изучение документации.
VD>Именно это я вижу в его примерах и словах. Там явным образом прослеживается натуральная борьба с абстракциями. Ведь за них нужно латаить. Заметь у него в коде ни разу не появился ни один строковый класс. В коде сплошные сишные строки размещаемые исключительно в стеке. А ведь по его же словам приводимый им код написан на С++.
Знаешь, когда я писал лексические анализаторы, я тоже не пользовался классами строк, и тоже активно использовал стек. При определенной аккуратности лекго исключаются возможности прохода по стеку. Обяснить как?
Т.е., повторю, в отрыве от контекста доказывать свою правоту бесполезно. Лично я поддержал сам факт обсуждения этой темы. Согласен, что Дворкин немного перегибает, но, может он это делает специально, в ответ полное пренебрежение к этому вопросу у окружающего мира?
V>>Понятное дело, что чем больше осведомленность о тонкостях используемых технологий, тем больше можно сделать оптимизаций без какого-либо ущерба для продукта или потраченного времени.
VD>Нет, дело как раз не очень понятное. Кроме знаний о тонкостях реализации нужно еще иметь знания по грамотному дизайну приложений и желание этот самый грамтоный дизайн культивировать.
Вообще-то, согласно правилам инженерии, самое общее решение является самым неподходящим для конкретного случая. Однако, в ПО повторное использование ничего не стоит (т.е. разможение информации и кода ничего не стоит). И вот мы называем самые общие решения "грамотным дизайном", потому как они повторно применимы. В общем, это совсем другой вопрос — что считать грамотным. Я тоже люблю фреймворки писать.
Добавлю еще насчет грамотного дизайна. Опять все встает с ног на голову. Раньше люди решали путем анализа вполне конкретные программистские задачи. Потом обнаружили их похожесть. Потом дали имена паттернам и использовали так: спроектировал что-либо, максимально удовлетворяющее требованиям, а потом _обяснил_ разработку на языке паттернов. Т.е. язык паттернов — это всего лишь терминологическая база. А молодежь как сейчас что-то проектирует??? Вместо того, чтобы решать поставленную задачу, крутит эти паттерны как кубики Лего, путем полного перебора стараясь подобрать нечто условно отвечающее поставленной задаче. И выходят монстры, один другого страшнее. И _паттэрны_ вроде есть, и неграмотно при этом...
V>>Жаль, что ты не указал точно год, правда, если речь о 386-х и у нас, то предполагаю где-то после 92-го. Если бы ты писал свою утилиту ранее, и позиционировал ее именно для XT (c 4.7 MGh CPU) и без кеша драйва, то все твои усилия уже не выглядели бы такими уж ненужными и бесполезными. Тем более, что описанный способ буферизации не выдерживает никакой критики и вполне справедливо создал хаос в исходниках. Ты тогда еще в школе учился что-ли? Ибо студент после 1-го курса профилирующей специальности должен был просто отвязать интерфейс ввода от конкретной его реализации.
(тут ты не ответил)
VD>Я бы поверил тебе, что ты так всегда поступашь, если бы не видел твоей "тройки" вот на этом призыве
. Возможно ты и его не понял доконца, но тогда вопрос можно ставить об адекватности восприятия тобой и вещей вроде объема крови жертвуемой на оптимизации и необходимостью этих оптимизаций. (ни прими это за оскорбление, плиз)
(уффф, чтоб меня так чужие оценки беспокоили...)
В этом месте ты уже забыл, что я настаивал на выборе оптимального инженерного решения, и обращал внимание, что сам этот выбор может ничего не стоить. А оценку я поставил за художественную силу и злободневность самой темы. И за то, что не поленился человек такой большой пост откатать, и при этом вовсе не нудный. В общем, по аналогии с фигурным катанием, оценки не только за технику ставим, но еще и за артистичность.
VD>Ну, любая идея требует критического взгляда. Но хотелось бы чтобы этот взгляд был действительно критическим, а не основанным на непонимании.
Мы все тебя прекрасно понимаем, мамой клянусь!
Давайте, после артподготовки (обмена любезностями), перейдем к ближнему бою. Выкладывайте у кого что есть из актуальных примеров, когда по чьему-то мнению требвалось принимать волевое решение об затратах на оптимизацию, заодно попытаемся собрать максимум внешних ограничений/требований и оценить адекватность подобных затрат. У меня есть пара весьма актуальных примеров, если народу будет интересно, с удовольствием пообсуждаю.
[. . .] Извини, "ниасилил" я...
VD>В чем ты углядел не вежество, то?
Вот именно в этом Влад. Именно в этом. В пренебрежительном отношении: 1) к грамматике 2) ко всем собеседникам, которые с тобой не согласны 3) к грамотным инженерным решениям 4) ко времени, затраченном собеседником на написание поста. Иными словами, "падонкаффским" отношением ко всему и к своей профессии в том числе. Это и называется невежеством.
McSeem
Я жертва цепи несчастных случайностей. Как и все мы.
Здравствуйте, VladD2, Вы писали:
VD>Дискуссия развернушаяся здесь однозначно показывает, что я правильно оценил мировозрение с которым борюсь.
Дисскусия, развернувшаяся здесь, однозначно показывает, что VladD2 в состоянии единолично развернуть и активно поддержать дискуссию с множеством оппонентов, и даже безо всякой поддержки своей стороны.
Снимаю шляпу
-----------
Если бы был более внимательным к оппонентам, то заметил бы, что большинство из них стоит ближе к твоим позициям, чем к позициям неких героев, на коих ты ведешь атаку. Просто у них порой больше взвешенности и меньше безапелляционности. Высказаться однозначто "за" или однозначно "против" здесь никто не рискнет, кроме тебя. Когда же тебе говорят, что конкретное решение принимается только исходя из конкретных требований, то ты обвиняешь собеседника в том, что он не понял "основной посыл". Хотя, основной посыл только в этом и должен состоять (соответствие требованиям). Все, что ты придумаешь сверху — заведомо неверно.
Переводя обсуждение в это более формальное русло, оппонентов надо бы упрекать в недостаточной или избыточной реализации требований. Но вот повернется ли язык у кого-либо на подобное без раскрытия этих самых требований в каждом конкретном случае??? То-то и оно... И все бы давно поставили точку, прими ты именно такой взгляд на вещи. Если вначале еще было хоть как-то понятно, с чем ты споришь/воюешь, то после четкого определения оппонентами своих позиций, твоя собственная как-то стала расплываться.
? Оптимизацией нужно заниматься тогда и только тогда, когда это часть non-functional requirements. В противном случае линейкой по рукам.
Занимаюсь ли я сам оптимизацией? К сожалению, да, довольно часто и много. Чаще и больше чем хотелось бы. Порой в довольно извращённых формах, например, в виде имита. Но это всегда стрельба по площадям, а не по воробьям. Не клубнику у соседки потырить, блин, а уж если обносить, то сразу колхозное поле. И только если оно того стоит. Ускорить что-нибудь в несколько раз всегда имеет смысл, если это критично. Париться ради 5-10% — увольте.
Единственная оптимизация, даже ради 1 процента, на которую стоит постоянно тратить время и которую я считаю очень правильной и необходимой (особенно для студентов) — это оптимизация читабельности и восприятия исходного кода. И ради этого я всегда готов пожертвовать жалкими 5-ю процентами производительности. Впрочем, жертвовать практически никогда и не приходится.
... << RSDN@Home 1.2.0 alpha rev. 0>>
Если нам не помогут, то мы тоже никого не пощадим.
Re: Готовность системы к её последующим изменениям
Здравствуйте, Odi$$ey, Вы писали:
OE>а паттерны-шматтерны не способствуют разве большей прозрачности (понятности) реализации? что в конечном итоге и равно готовности к изменениям. Или как ты эту готовность обеспечиваешь?
Давай на это глянем с другой стороны. Паттерны-шматтерны и прочие ООП — это средства достижения наших целей. Именно средства. Сами же цели — это функциональность системы, удовлетворение её функциональных и нефункциональных требований. В дополнение к этим целям у меня всё чаще и чаще появляется ещё одна цель — обеспечение сопровождабельности программы. Раньше это тоже было средством, скорее всего средсвом самосохранения, но сейчас это переходит в разряд целей. Как я обеспечу достижение этих целей мне всё равно. Поэтому средствами я могу манипулировать как угодно, менять их, применять, заменять, отменять и т.п.
Наиболее частая ошибка которую я вижу и в своей практике и иногда здесь на форумах — это перевод средсв достижения целей в разряд самих целей. Т.е. большинство проблем начинает возникать когда ООП дизайн или паттерны становятся целями, а не средствами их достижения.
В общем, конечно же я всё это использую. Но если я вижу что это плохо работает, то "поступиться принципами" для меня раз плюнуть.
... << RSDN@Home 1.2.0 alpha rev. 0>>
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, vdimas, Вы писали:
V>>Я с 1990-го работал на Turbo C, там можно было менять размер буфера структуры FILE (ты же ее использовал?)
VD>Я уже не помню что я использовал. Название getch и то взято на абум как одно из близких. К делу это отношения не имеет. Ты просто вообще ничего не понял из написанного. Попробуй перечитать текст не обращая внимания на технические детали.
Доктор мой не лыком шит, он хитер и осторожен:
"Это правда, но возможен ход обратный", говорит.
Например, "Ты просто ничего не написал из понятого. Попробуй переписать текст, обращая внимание на технические детали".
PS: А впрочем, чего это я? Чем больше людей согласится с автором, тем легче мне будет с работой.
Здравствуйте, vdimas, Вы писали:
V>Без достаточной проработки самой модели и всех ее уровней с функциональной т.з. и с т.з. всевозможных ограничений, бросаться в конкретику паттернов, ИМХО, рановато.
Последнее время я всё больше и больше убеждаюсь, что все эти проработки-шмаработки, паттерны-шматтерны конечно хорошо, но находятся далеко не на первом месте. Почему-то у меня всё чаще и чаще на первое место выходит готовность системы к её последующим изменениям под новые требования. Т.е. заменить вот эту фенечку вот на такую шменечку и воткнуть между ними вот такую жменечку. Второе место занимает, кто бы мог подумать — готовность системы к изменениям после её изменения.
... << RSDN@Home 1.2.0 alpha rev. 0>>
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, VladD2, Вы писали:
VD>Верные слова, но с не верным смыслом. Для меня опимальность не сводится только к скорости. Я могу судить или об оптимальности в некоторой обаласти, или об оптимальности как совокупности факторов многие из кторых отрицательно воздействуют на другие. Но даже говоря об оптимальности производительности я не думаю, об абсолютной потимальности. По этому я и говорю, не об оптимальности, а о достаточности и приемлемости.
Тут ты уже съезжаешь с темы. Понятие "оптимальность" (лучше я буду использовать в дальнейшем "эффективность" как более подходящий термин, несмотря на то, что процесс повышения эффективности называется оптимизацией), так вот, понятие "эффективность" нельзя трактовать вольно и свободно, произвольно награждая его различными критериями. Тем более, что эти критерии могут быть прямо противоположны. Например, критерий эффективности самого ПО относительно потребляемых ресурсов и критерий эффективности процесса разработки ПО. Смешивая эти критерии в одну кучу легко получить две противоположные спорящие стороны, каждая из которых по-своему права.
Я не зря стал поднимать экономическую сторону вопроса производства ПО, ибо твой набор критериев (эффективность процесса разработки) имеет под собой именно экономическую базу, но никак не техническую.
VD>Опять же не совсем так. Кроме затрат физических есть еще другие аспекты "оптимальности". Если быстродействие будет требовать от меня использовать кривой С-подобный код примеры которого в изобилии демонстрировались отдельными поборниками производительности, то я скорее предпочту более медленный код, но и более просто читаемый/изменяемый.
Как я заметил выше относительно противоположных по характеру критериев эффективности, без расставления реальных весовых коэффициентов этим критериям для каждого конкретного случая подобные примеры и замечания не имеют цены.
Например, большинство программного кода по обработке сигналов действительно плохо читаемы/изменяемы (write only), независимо от используемого ЯП, длины и осмысленности идентификаторов. Т.е. не всегда код пишется в расчете на дальнейшее переписывание. По моему субъективному мнению (исход из собственного опыта) подобный код, гарантированно требующий сопровождения и дальнейшей модификации, обычно находится на самом верхнем прикладном уровне. И именно этот уровень в большинстве случаев оказывает наименьшее влияние на эффективность системы в целом. На мой взгляд, основа эффективности системы в большей степени зависит от общих архитектурных решений и далее от качества реализации библиотечного уровня (фреймворка), в основном тех мест, которые имеют дело с приличными объемами данных либо сложными вычислениями.
Опять же, общее архитектурное решение, разработанное с целью увеличения эффективности системы, может понизить эффективность разработки (сделать API более сложным или более чуствительным к "правильной" последовательности применения функциональности этого API)
Т.е., я настаиваю на том выводе, что баланс м/у эффективностью разработки и эффективностью целевой системы должен определяться требованиями. Возникающие ситуации, типа: "вот сделали, а вышло неэффективно, стали оптимизировать — код вышел макаронообразный" — говорит лишь о недостаточном сборе/анализе требований или отсутствии моделирования/прототипирования на начальных этапах проработки архитектуры.
VD>Оптимизация ничего не стоит очень редко. Да и говорить о таких случаях как об оптимизации не стоит.
В твоем примере она могла ничего не стоить, по сравнению со стоимостью разработки. Мы ведь этот пример обсуждали?
V>>Ты в своем посте красочно обрисовал тонны потраченных усилий, были ярки картины загубленной красоты исходников... Ты ведь "потомству в пример" это все написал, признайся? Так вот, потомство должно так же знать, что недостаточное владение инструментом может породить все эти проблемы даже при решении такой несложной задачи как буферизация ввода.
VD>Согласен. Собственно кривой код и тормоза на ровном месте это скорее не отсуствие погони за скоростью или красотой, а отсутсвие опыта или кривой опыт. Ну, возможно еще проблемы с ДНК.
Интересный модный термин, насчет проблем с ДНК. Считаю, что каждый должен заниматься своим делом. К сожалению, дефицит программистов привел в эту отрасль массу народа, для которых это занятие явно не рекомендуется. Это не говорит о "проблемной ДНК", просто люди заняты не своим делом. Возможно, в чем-то другом они дали бы всем нам фору.
VD>Однако тенденция к отказу от абстракций подчеркнуто демонстрируемая, ну, вы знаете кем, как раз демонстрирует, то что выбор некрасивых и даже совсем кривых решений очень даже может являться следствием неразумной погони за производительностью.
Согласен, что порой некоторые могут "лепить отмазки" насчет кривизны кода, пытаясь оправдать это погоней за производительностью. Более чем уверен, что реальные замеры в подобных случаях ничего не покажут.
Т.е. см. предыдущий абзац.
Оптимизация — это выбор эффективного алгоритма/протокола. И даже если он потребует в 1.5-2 раза больше кода на конкретном участке, совсем не факт, что этот код должен быть кривым и нечитаемым. Твой упор именно на кривости "неразумной оптимизации" я бы переформулировал в "невладение предметом". Такой программист с очень большой вероятностью налепит кривизны не только в обсуждаемых участках кода. Однако, для подобных случаев и существует разделение труда и иерархия технического руководства. Тим-лидер вполне может в приказном порядке назначать новичкам конкретные алгоритмы или разрабатывать API/протоколы. Т.е. при желании, все это поддается контролю (сужу по своей команде).
VD>Еще раз повторю, я в те времена намеренно отказался от "буферизации" воода и выбрал работу с "блоками памями". Это бло, можно сказать, дизайнерское решение. Безграмотное? Одназначно! Основанное на умозрительных предположениях? Безспорно. Но все же основанием для него явилось не то, что я не допер до буферизации и т.п. Основанием была погоня за производительностью.
Наглядный пример той самой "отмазки". Это просто случайность, что для конкретного твоего случая и именно почти одновременно стал широко использоваться дисковый кеш. Иначе твоя т.н. "погоня за производительностью" прямиком бы пошла в требования (те самые требования относительно конфигураций предполагаемого железа).
V>>Опять же... Требования и еще раз требования... Ну почему мы всегда обсуждаем что-то абстрактно, и как тут можно понять, чьи позиции устойчивее, если контекст не задан? Более-менее воссоздать картину можно попробовать из твоих эмоциональных акцентов. Но где гарантия, что их правильно истолковали? А может быть ты тогда не совсем правильно истолковал внешние условия? Какой был процент "покрытия" этими кеш-драйверами? Предназначалась ли твоя прога и для XT? Даже для тех, у кого 256кБ? (На них эти всякие кеши не ставились принципиально никогда, но тем не менее одно время таких машин было достаточно)
VD>Нда, беда. Мне ПОХРЕНУ проценты, килобайты, названия функий И ДАЖЕ причины приведщие к этому. Я ГОВОРИЛ О НЕВЕРНЫХ ПОСЫЛАХ... неверных стремлениях, неверных действиях.
Угу, а я о неверных выводах, которые ты тогда сделал. В твоем случае эта "неверность посылов" была лишь элементом случайности. В моей практике подобной "халявы", к сожалению, не встречалось. С буферизацией ввода/вывода я разобрался еще на 2-м курсе, а остальные проблемы были только вычислительного плана. Но в этом вопросе "халява" приходит с опозданием на пару лет или еще позднее. И то, в последние 2 года остановились на 3+ GHz. То-то стали снова подниматься подобные вопросы.
А посылы очень даже верные. Просто "техника в руках дикаря..." ну и далее по тексту. Тебе следовало сделать совсем другой вывод, а именно: "на оптимизацию стоит затрачивать усилия только в том случае, если полностью владеешь предметной областью". Потому как оптимизация — это суть выбор пути решения. Надо суметь найти как можно больше таких путей для сравнительного анализа.
Собственно, на этом можно было и закончить. Дальнейшие ответы — уточнение незначительных мелочей.
--------------------------
VD>Что килопроцентов, то исходная версия программы писалась на ХТ и там изумительно вставал Смартдрайв, ведь у них один хрен был метр памяти.
На ХТ стояли 256k, 384к, 512к, 640к (самый популярный и долгодержавшийся размер). 1M крайне редко, стал популярен начиная с AT, и действительно, неиспользуемые 384к стали отдавать под всякие смарт-драйвы и просто RAM-диски.
V>>Ловко, однако не зачтено.
VD>Ты видимо непонимашь реального положения вещей. Мне не нужно сдавать тебе зачеты.
Жаль, что я не модератор...
V>>Диктую большими буквами: ЕСЛИ ВАМ И ПРОЕКТУ ЭТО НИЧЕГО НЕ СТОИТ, ТО ВЫБИРАЙТЕ НАИБОЛЕЕ ЭФФЕКТИВНОЕ РЕШЕНИЕ ЗАДАЧ НА ЛЮБЫХ УРОВНЯХ.
VD>Ну, тогда я тоже продиктую ДУМАЙТЕ НА ДВА ШАГА ВПЕРЕД, МАТЬ ВАШУ. Не думайте о битах и байтах пока в этом не будет крайней нужды.
А тебе вообще приходилось сдавать зачеты по IT?
Когда настает крайняя нужда, то уже банально поздно. Преподаваемый в наших ВУЗах "системный подход" (и 19xx — ГОСТы как их основа) вполне точно определяли, на каком этапе выяснялась эта "крайняя нужда". Сейчас процесс RUP мне кажется весьма подходящим.
VD>Вообще я кажется понял. Разница между нами не в подходах к программированию. Разница в том что мое мировозрение испочено кроме программирования еще и экономикой с юриспруденцией. По этому для меня очевидны многие вщеи не очевидные для программистов. Видимо чистый программист принципиально не может в рассуждениях не оперировать битами. Вопрос только в степени зациклинности на них.
Ну никак не удается спустить себя с высоты твоей ораторской трибуны на землю и втолковать, что эффективность системы и эффективность разработки — это разные вещи, почти всегда диаметральные друг-другу (жаль, что не ортогональные), и нечего их смешивать в одну кучу. В предыдущем посте я сделал акцент на том, что без конкретных требований никто не в силах сделать оптимальный баланс для конкретной разработки. Но тут прилетает Влад с юридическим образованием и не напрягаясь раздает универсальные советы "космического масштаба ..." и далее как обычно по тексту. Надеюсь, что те, кто прочитал этот твой пост и что-то уже решил для себя, все-таки заглянут и сюда, несмотря на опоздание ответа.
V>>Ключевая фраза: "ничего не стоит".
VD>Да? Привести тебе примеры кода кого приводишиеся в качестве агрументов битовыжимания, чтобы ты обяснил как они могут ничего не стоить?
А зачем ты фразу от предложения отодрал? А насчет "отмазок" по поводу кривизны кода и причин этого — см. мое мнение выше.
V>>Но тем не менее, факт остается фактом. Тысячи и тысячи программистов пишут одно и то же, выпускают массу продуктов очень близкой функциональности, все получают немаленькую ЗП, и вопрос минимизации затрат на разработку ПО встает в гораздо более жесткой форме — быть бизнесу или же провалиться с треском. Отсюда все эти веяния. Теперь примерно понятно, почему я там 3 поставил?
VD>Это ты о битовыжимальной агитации? Не, не понятно. Ели бы было понятно, то я пошел бы тоже чё-нить поставил.
Это я вообще-то о смещении акцентов и причинах такого смещения. А теперь понятно?
V>>В своей жизни я уже успел написать несколько учетных систем, массу системных и т.д. и т.п. И очень многие мои коллеги так же. Кое какие продукты используются до сих пор, кое-какие скоро начнут активно использоваться (я очень надеюсь). Однако, я ни на секунду не забываю, что программист (и я в том числе) сейчас используется крайне неэффективно. Процесс раздела рынка ПО сейчас в самом разгаре, и продлиться по прогнозам еще не менее 20 лет, т.е. сейчас рулят правила джунглей. А правила не гласят — "сделай лучше всех", правила гласят: "сделай всех", или еще короче: "выживи". И вот такой вот внешний контекст оказывает весьма серьезное влияние на умы даже опытных разработчиков, да такое, что они в пылу спора уже и не помнят, где причина а где следствие обсуждаемых вещей.
VD>Понятно. У тебя экономические причины. Ты уж извини, но экомические вопросы мне мало интересны. И уж обсуждать я их стал бы не с программистами и не в темах связанных с производительностью ПО.
Эффективность разработки, на которую все время напираешь ты — это чистейший экономический/рыночный критерий. И обсуждать его надо действительно не с программистами, а с менеджерами. Ну так что... начинаем обсуждение?
VD>Вы хотите поговорить об этом? (с) VD>Я не буду обяснять почему эта налогия здесь не применима. Иначе прийдется вдаться в очень тонкие проблемы рынков и рыночных ниш. Хватватет того, что доказательство по аналогии является машейничеством.
Законы инженерии одинаковы. Рыночная ситуация может отличаться, законы — нет. Так что, аналогия считается весьма близкой. Если бы я привел тебе пример из теории бальных танцев — согласился бы на мошенничество.
V>>Такое может привидется только в кошмарном сне кокого-нибудь инженера Тойоты. В реальности, каждая следующая модель выходит со все лучшими характеристиками, ос более оптимальным весом, с большим КПД (люди, вы еще помните это слово) двигателя.
VD>Тебе не странно, что когда фирма выпускает вертолет вместо легковушки строит машину весящую болше и жрущую больше ресутсов? А не странно что лимизин представительского класса "Весит в 2 раза больше, однако, по-прежнему шустро ездит за счет более мощного мотора — Топлива она жрет в 2 раза больше"?
Нет, не странно. Странно, когда лимузин жрет в 10000 раз больше. (прикинь-ка относительные производительности современных процессоров к обсуждаемым в твоем посте). В моем примере речь шла о выпуске продуктов одного и того же класса. Сравнивать продукты разных классов бесполезно. Я УЖЕ видел достаточно самописных бух/складских систем на .Net, которые по функциональности не дотягивают даже до 1С 6.х версий, а требуют НА ПОРЯДОК больше ресурсов.
VD>Вот и мне не странно, что программа которая предоставляет мне рефактринг, хорошо работающее автодополнение при вводе, контекстную справку на каждый чих, отличный расширяемый редактор и отладчик и т.п. жрет чуть ли не в 10 раз больше времени.
Странно. Мне показалось, что для среды разработки VС++ 6.х ничего принципиально не изменилось в VC2003 (кроме компилятора, который более стандартный и более быстрый). А жрет в 3 раза больше памяти и работает заметно тормознутее.
Да кстати, почему-то Express C# жрет меньше памяти и работает заметно быстрее, чем VS2003... Может, дело было все-таки в чем-то другом?
VD>Так что кончай увликаться аналогиями, а обрати внимание на свою логику. В своих рассуждениях ты забывашь, что продукты жрущие больше ресурсов и дают больше. А те что жрут больше не давая ничего в замен по сравнению с продуктами конкурента попросу теряют потребителя и вымирают.
Если бы было именно так, то мир был бы идеален. Реально же, нехватка программистов означает лишь одно — спрос на ПО (заказное в большей степени). На заказное ПО действуют немного другие рыночные законы, к тому же сильно перекошенные его дефицитом. Поэтому ничего не вымирает, а "пропихивается" с кривостью, с потрясающими требованиями к железу и т.д.. Могу порекомендовать www.sql.ru, и в нем форумы, посвященные БД. Как раз там хватает обсуждений насчет требований к железкам, их адекватности задачам и вообще, у кого и как сейчас руки растут.
VD>А слезы по повду расходвания 10 метров из гига — это глупость и ханжество. Не нравится? Старые программы работать не перестали.
1. Не 10 а 30.
2. Лишние 30 на каждую прогу в пямяти — это уже ого.
3. Механизм маппинга области кода DLL на разные процессы не работает в управляемых средах. В среднем +1М на каждую DLL. Грубо плюс еще 5-10М.
В общем, пока вопросов больше чем ответов. Когда приличную часть вопросов закроют, тогда и понравится.
V>>Но ведь это не удивительно, над новой моделью работаюбт сотни инженеров. А у нас, у программистов, примерно 5-15 человек делают проекты, по информационной сложности мало уступающие проекту той же Тойты.
VD>Ну, что же. Тебе никто не мешает заработать денег, создать свою фирму, нанять сотню инжинеров и сделать продукт который пользователи предпочтут потому другим. Вот только на этом пути ты будешь вынужден научиться зарабатывать деньги и поймушь в чем ты был не прав.
Посмешил, спасибо. Ты прямо как в воду глядел. Фирма создана (довольно давно), набрал не сотню, а гораздо меньше... Подчиняюсь законам рынка, ессно, однако критерии эффективности проработал еще на этапе разработки архитектуры. Противоречие в чем? И почему до сих пор не понял, где был не прав?
V>> Поянтное дело, что для самого факта успешности подобных проектов жизненно необходимо максимально все упрощать и выкидывать все лишнее (и оптимальные пути разумеется тоже). А иначе как? Человеческий мозг — весьма ограниченная в своем объеме штуковина.
VD>А иначе так. Пусть все занимаются своим делом. Пусть успешность продукта на рынке предсказывают маркетологи и сложбы по взаимодействию с клиентами. Пусть проектами управляют люди знающие толк в этом деле. А программируют и проектируют ПО люди проффеисиональные в этом деле. Тогда маркетологи и т.п определять набор требуемых возможностей, менеджеры спланируют их реализацию, а программисты запрограммируют и оттестируют все в нужные сроки с нужным качеством. Тогда успешные продукты автоматически выявят более грамотные команды, а безграмотные развалятся. В общем, через рынок потребитель сам определит что ему надо.
Замечание насчет рынка и его характера сделал выше.
Мы, например, разрабатываем продукт на рынок, а не заказной. Соответственно, вопросы эффективности системы (т.е. требований к целевым железкам) у нас стоят так же остро как вопросы эффективности разработки. Скажу сразу к чему пришли: сервер на .Net, агенты на С++. И код на .Net, поверь, тоже написан не "от балды".
V>>... Хотел еще примеров написать, но вроде и так общий (самый общий) мой посыл должен быть понятен.
VD>Безусловно. Жаль, что не всем.
И я даже его знаю
VD>Вопрос который мы обсуждаем является таким, что в крайности в нем бросаются очень многие. По-моему, тут уже половина народу призналась, что их порой тянет пооптимизировать что-нить без особой на то необходиомости. Так что тут речь не о стрижке, а о выробатывании здорового эмунитета к дурным пристрастиям.
А может их тянет "пооптимизировать" ввиду потребности "зарядки для ума". А кого-то тянет в DOOMы погонять на работе. Пусть уж лучше в качестве отдыха от "кодирования" расслабляются первым способом.
Вполне представляю себе некое API, состоящее из многих аспектов и конкретных методов в нем. Оптимизация некоего одного метода в такой системе (особенно если он так и напрашивается на оптимизацию, т.к. был выполнен "по-быстрому") ничего не изменит в такой системе в худшую сторону. Другое дело, что на месте программиста, которому захотелось "поразмяться" я бы обращался к тим-лидеру с вопросом, указать "узкие" места для той самой разминки. Поверь, их хватает в каждой разработке, и адекватный тим-лидер, обладающий чуть-большей информацией о проекте, с удовольствием обсудит вопросы оптимизации требуемых мест в системе. Если в результате мы получим не хаотический, а упорядоченный по приоритетам процесс оптимизации — то я "за" двумя руками. Особенно, если программист, которому в качестве отдыха захотелось "поупражняться", доводит дело до конца.
V>> А что касается текущего положения дел, то на само понятие "эффективности" молодое поколение просто забило.
VD>Это не так.
Это из разребаемых лично куч "кода" на предыдущем месте работы. Это так.
VD>Что значит "даже"? Я пишу вмеру разумно. Иногда тоже увлекаюсь оптимизациями, а потом понимаю что валял дурака. От чего и предостерегаю других.
Что бы это не было "валянием дурака", заранее планируй и расставляй приоритеты. Пользы больше будет. Мне вообще плохо понятно, как ты упорядочиваешь свои разработки. Как-то тебя кидает из стороны в сторону, от задачи к задаче. Приятный образ жизни, согласен. Жаль, что не могу позволить себе такого.
VD>И я о том же. Но надо еще понимать, что является ошибкой.
ИМХО, далекоидущие выводы, сделаные без анализа внешних условий, будут ошибочны с большей вероятностью.
VD>Не надо. Ты потратил время зря, если конечно ты не писал его 20 лет назад. Я вот писал парсер на Шарпе и он работает очень и очень шустро. Сам понимашь, ни о каком стеке тут и речи не идет.
10 лет назад писал. И неужели потратил время зря???
Сейчас тоже написал на шарпе, и конечно уже совсем не так. Прямо при инициализации у меня строится минимальный ДКА для моего лексера из набора лексем и регулярных выражений (парсер всевозможных форматов Date/Time).
Q. Почему бы не использовать стндартные регулярные выражения?
А. Для наших задач не подходит быстродействие.
Q.
Почему на сохранил в бинарнике в ресурсах свой ДКА, а строишь каждый раз динамически при старте?
A.
1. Руки не дошли, да и спорный момент, потому как:
2. Из ресурсов всегда читается с блокировкой.
3. Бинарная ДЕ-сериализация не такая уж быстрая, как хотелось бы.
4. Цена вопроса — пара десятков ms при старте, ибо алфавит лексера небольшой у нашей задачи.
5. В результате — пока от этого никакого выигрыша.
Q. Если алфавит будет большой в будущих разработках/применениях лексера?
A.
1. Сама структура лексера будет немного изменена, дабы было удобно загружать/выгружать таблицу переходов. Сейчас состояние — это объект.
2. Либо таблица переходов будет выполнена в виде единого однотипного массива, либо сама загрузка/выгрузка будет написана вручную, без использования ср-в сериализации .Net, если решим оставить состояние в виде объекта (наиболее вероятно).
Q. Текущий приоритет задачи?
А. Крайне низкий.
Еще вопросы?
В общем, не надо держать всех за "маньяков".
V>> Лично я поддержал сам факт обсуждения этой темы. Согласен, что Дворкин немного перегибает,
VD>Будем надеяться, что тройка поставленная им за твое сообщение в том числе включает и согласие с этим вот высказыванием.
Что означает моя оценка я уже обяснил. Поддержку и раскрытие самой темы. Оценки привлекают читателей, не правда ли?
VD>Вряд ли. Я вижу за этим именно деструктивное мировозрение усиливаемое его статусом. Хотя возможно тут уже я перегибаю палку.
V>> Однако, в ПО повторное использование ничего не стоит (т.е. разможение информации и кода ничего не стоит).
VD>К сожалению, стоит. Со временем все меньше и меньше, но этого достаточно чтобы очень многие забивали на него исходя из тех же вопросов производительности. Я, кстатати, каюсь, грешен... тоже забивл и порой продолжаю забивать на повторное решение ради производительсности или чего-то еще. Только я делаю это скрипя сердцем, а очень многие с радостью в душе.
VD>Скорее грамотным решением я назову некое обобщенное решение которое в то же время позволяет хорошо адаптироваться к задаче. Ну, например, можно написать общее решение, а можно "общее решение с параметрами". Параметры повзолят настроить решение под конкретные задачи.
Параметры и пр. настраиваемость тоже чего-то стоят в плане времени. Я предпочитаю такие решения, которые в будущем без поломки архитектуры позволяют добавлять настраиваемость по мере надобности, которые потом позволят настроить под конкретное решение и т.д. (в общем, дом, который построил Джек)
Т.е. "оптимизация" архитектуры — это лишь разновидность оптимизации, которая точно так же должна быть оправдана требованиями. Например, требованием повторной применимости.
V>>Добавлю еще насчет грамотного дизайна. Опять все встает с ног на голову. Раньше люди решали путем анализа вполне конкретные программистские задачи. Потом обнаружили их похожесть. Потом дали имена паттернам и использовали так: спроектировал что-либо, максимально удовлетворяющее требованиям, а потом _обяснил_ разработку на языке паттернов. Т.е. язык паттернов — это всего лишь терминологическая база. А молодежь как сейчас что-то проектирует??? Вместо того, чтобы решать поставленную задачу, крутит эти паттерны как кубики Лего, путем полного перебора стараясь подобрать нечто условно отвечающее поставленной задаче. И выходят монстры, один другого страшнее. И _паттэрны_ вроде есть, и неграмотно при этом...
VD>Паттерны — это опыт. Слово "паттерн" появилось в программистском лексиконе очень недавно и я по началу был сильно против него. Но потом я понял, что паттерн — это опыт решения конкретной задачи который описан настолько хорошо, что им можно оперировать как сущьностью. 90% паттернов я применял по наитию и раньше. Я использовал Синглтоны и Фабрикуи классов в КОМ-е и т.п.
А так же все фасадные, бриджевые в т.ч., разумеется. Прокси и их сочетание с фасадными/бриждевыми — итераторы, как следствие и т.д. (многие паттерны описываются другими паттернами и на мой взгляд идут как следствие).
На любой стадии программирования люди используют понимание, чтобы находить и предлагать паттерны. Картостроители стремятся получить общее понимание ситуации, применяя известные паттерны там, где они применимы, и создавая новые там, где их нет.
Среди паттернов может быть, например, и такой: «Не ставь телегу впереди лошади».
Надеюсь, источник указывать не требуется?
VD>Что же я делаю глупости? Нужно как во времена когда я только учился программировать каждый раз проползать на брюхе все трудные места, и только потом распозновать паттерны и заменять некрасивые решения на них?
Где-то я уже говорил, что многие паттерны просто не нужны в языках с динамической типизацией, напр. JavaScript/VBA/SmallTalk.
Большинство из них растет из способа реализации ООП в Java/С++ (и пр. подобного направления, в Дельфи в т.ч.), где имеется требование бинарной совместимости внешних интерфейсов объектов или же основаны на тонкостях создания/защиты объектов, т.е. являются следствием этих требований. Этими ограничениями надо владеть ДО изучения паттернов, тогда-то большая часть из них и покажется "старыми знакомыми", и просто приобретут свои именна и займут место на полке классификации.
VD>Или что же тем кто родился на 10 лет позже тоже нужно обязательно проползти на брюхе все что прополз я? Эдак человечество остановилось бы в развитии и каждое следующее поколение смогло бы только чуть-чуть поодвигаться впердед и то только если верить в то, что каждое новое поколение в принципе становится умнее.
А что прополз, если не секрет?
Основные дисциплины никуда не двигаются уже давно. Справочник по вышке у меня был хрен его знает какого года. По теории компиляторов, БД, дискретке, обработке сигналов тоже и т.д.
ООП — сравнительно "новое" направление. Однако, к счастью, не содержит той информационной емкости или сложности, и является логическим продолжением структурного подхода (зиждется на нем). Всевозможные споры даже неплохих специалистов в вопросах ООП анализа (например, споры насчет иерархии квадрат<=>прямоугольник), показывает тот факт, что эта область, к тому же, слабо детерминирована.
В общем, специалист должен проползти на брюхе гораздо больше, чем перечень паттернов.
VD>Человечество идет семемильными шагами вперед исключительно благодаря тому что научилось обобщать опыт. Паттерны это и есть обобщенный опыт. Кстати, описанный мной принцип получения программ приемлемых по быстродействию тоже есть обощение опыта. Более того не моего! Это и есть те самые инженерные приципы которыеми тут многие так гордятся, если хотите.
Я чего-то не увидел формулировки принципа получания программ, приемлимых по быстродействию. Мне кажется, что лучше руководствоваться более общим принципом: сбор, анализ и воплощение требований. Другие принципы приведут или к неполной реализации требований (и плане быстродействия и требований к ресурсам аппаратуры в т.ч.), либо к реализации лишних требований (опять же, и плане быстродействия и требований к ресурсам аппаратуры в т.ч.). Вот и все.
VD>Так что молдые очень правильно делают, что используют паттерны при проектировании ПО. Тем самым они повышают свою производительность.
Люди, использующие знания в работе, всегда повышают свою производительность. Речь шла о том, как именно эти знания применять, и является ли зазубренный список паттернов знанием сам по себе в отрыве от остальных знаний.
VD>Ну, а беспокоиться нужно о том, чтобы эти молодые привильно понимали эти паттерны и умели быстро и безошибочно распозновать места где они применими (выбирать нужный паттерн).
VD>Меня не беспокоит сама оценка. Уж кому кому, а не мне чужим оценкам завидывать.
VD>Я считаю оценку выражением согласия и поддержки. И куча положительных оценок на явно, по-моему, деструктивном мнеии меня обижает и пугает. Особенно пугает когда оценки ставят не те ктого я считаю ортодоксами или фанатиками.
Не бойся и не пугайся. Пообсуждали вопрос "зачем?", давно пора было перейти к обсуждению "как?".
V>>В этом месте ты уже забыл, что я настаивал на выборе оптимального инженерного решения, и обращал внимание, что сам этот выбор может ничего не стоить. А оценку я поставил за художественную силу и злободневность самой темы. И за то, что не поленился человек такой большой пост откатать, и при этом вовсе не нудный. В общем, по аналогии с фигурным катанием, оценки не только за технику ставим, но еще и за артистичность.
VD>Я не вижу злободневности. Я вижу деструктивность. Очень жаль, что ее не видешь ты и многие друние.
Есть злободневность. Не стоит, ИМХО, обощать свой собственный опыт на всех. А то я начну спрашивать, в каких командах и с кем ты работал и перейдем на замеры длины мобильников... Пока что я считаю, что лично ты работаешь ммм... немного в нестандартных условиях.
VD>Ставить же оценки за графоманство, чем собственно и является художественная сила, то же считаю не очень разумно, так как яорум посвящен программированию и оценка будет воспринята как одобрение и поддержка основных посылов сообщения.
VD>Именно по этому меня волнуют оценки на пдообных мениях.
А если тебе заявят, что ты собираешь большинство своих оценок аналогично? ИМХО, не обязательно отзываться таким образом о постах оппонентов.
VD>Я рассуждаю просто... Если на этот форум зайдет человек мировозрение которого еще не сформировалось, то он обязательно обратит внимание на то, что множество вроде как разумных и достоиных людей поддерживают мнение о том, что нужно делать все максимально быстрым. Дальше скорее всего начнутся дейсвия которые лет через 20 могут привести к появлению еще одной волны, ну, ты понял чего.
Спасибо за заботу, что еще можно сказать на подобное проявление альтруизма... А мне с этими людьми работать, так что, я тоже гну свое
VD>Незнаю. У меня все просто. Если вижу что что-то работает медленно, то думаю как исправить и исправляю.
VD>У меня обратная проблема. Часто стараюсь сделать оптимальнее чем нужно на что убиваю кучу времени.
Здравствуйте, FR, Вы писали:
FR>Так ведь и обратный посыл который тут активно пиарится, "не оптимизируй пока не припрет" тоже неверен. Часто когда припрет оказывается уже поздно.
Все не совсем так. Лично я выступаю за очень простой набор правил:
Разработка
1. Пишем программу так чтобы было не стыдно показать ее код/дизайн другим, и чтобы этот код максимально просто поддавался бы развитию и модификации.
2. Проектируя код задумываемся над тем в каких условиях он должен работать и с какими проблемами можем столкнутся. Исходя из этого выбираем приемлемые алгоритмы и средства (библиотеки, рантаймы, компиляторы и т.п.) и другие проектные и локальные решения.
3. Когда встает выбор того или иного решения, которое может повлиять на производительность смотрим на то насколько это решение ухудшает дизайн приложения и что оно может дать с точки зрения производительности. Если дизайн не ухудшается и не усложняется реализация, то выбираем потенциально более быстрый вариант. При этом, если это не сложно, имеет смысл проверить свои предположения на практике (сделать тест). Проверяя предположение не забываем о том, что полученные результаты могут зависеть от локальных условий (например, процессора или драйвера видеокарты). Если же дизайн усложняется, то плюем на оптимизацию до того момента пока не сможем проверить влияние этого решения. Попутно записываем в список TODO требование проверить, это предположение.
4. Тестируем приложение на максимально широком списке девайсов и в максимально разнообразных условиях.
5. Если есть нарекания пользователей, начинаем заниматься оптимизациями которые могут ухудшить дизайн приложения.
Оптимизация
1. Собираем список нареканий пользователей.
2. Производим собственное тестирование с привлечением профайлеров и т.п.
3. Определяем приоритеты оптимизации и возможное ее влияние на дизайн (расширяемость и поддерживаемость) программы.
4. Эмулируем ситуацию в более простом окружении, чтобы изолировать ее от возможных побочных воздействий. Проверяем, что изолированный вариант повторяет ситуацию с тормозами. Если этот пункт не выполним (например, очень трудоемок), то стараемся создать тест, демонстрирующий проблему.
5. Выносим окончательное суждение о причине проблем.
6. Находим другое решение и думаем, как оно влияет на дизайн программы.
7. Проверяем решение на тесте.
8. Модифицируем программу пытаясь минимизировать вредное влияние оптимизации.
9. Снова тестируем чтобы убедиться что проблема устранена.
10. Если есть другие проблемы, переходим к пункту 1 этого списка и начинаем решать их.
... << RSDN@Home 1.2.0 alpha rev. 618>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, McSeem2, Вы писали:
MS>Влад, это все хорошо конечно, спасибо за рассказ. Но как-то злобно очень. Типа "вы все п...сы, а я — Дартаньян".
Хм... все п...сы, говоришь? Дартаньян, говоришь? Ну, тебе виднее. Может это и правда можно разглядеть в моих словах, если очень постараться.
Тогда к тебе встречный вопрос. А не замечал ли ты, что твои посты частенько содержут нечто очень смахивающиее на описанное тобой Дартоньянство? Ну, то поделишь (невзначай так) всех на себя динозавра и всех остальных... индусов, то побеспокошся не мешает ли клизьма оппонентам, то еще как-то заденешь. Или это по доброте душевной? Ты то ведь точно прав, а оппонент глядишь и правда не замечает что у него из уха клизма торчит.
MS> Ну почему ты так неуважительно отзываешься о Павле Дворкине?
Да, я скорее не неуважительно. Я скорее раздражительно. Возможно я тут не прав и перегибаю плаку. Однако я искренне считаю, что такая безрассудная борьба за производительность исходящая от преподавателя крайне деструктивно скажется на его учениках. Свобода слова и свобода после слова несомненно незыблема. Но это до тех пор пока речь идет о твоем личном мнении. Как только ты начинашь учить других, то твое мнение превращается в инструмент воспитания. Ведь ты отвественнен за то что будет в головах твоих учеников. И если неподготовленные головы пропаласкать вот такими залихватскими речами о производительности, то практически гарантированно можно получить людей которые просто не в состоянии будут понять, что такое грамотное проектирование, так как их учитель им обяснил, что словами о грамотном проектировании обычно прикрывают неумение и не желание писать оптимальный код. Ну, а если это еще смазать твоими рассуждениями об индусах... Кому же хочется быть поставленным в один ряд с индусами?
MS> Он старше нас с тобой, между прочим.
Бесспорно.
MS> И гораздо опытнее.
А вот это сложный вопрос. Ты опыт измеряешь по банальному возрасту? Ну, вот, например, мой отец старше всех нас. Когда-то программировал на черт знает чем, но сегодня приходит за советом ко мне, так как в современных технологиях я плаваю как рыба, а он выучил что нужно было. Но по возрасту он несомненно опытнее.
В общем, вопрос опыта — это сложный вопрос. И не нужно его использовать как плаку.
MS> И то, что твое мнение не совпадает с его, ни в коем случае не значит, что ты прав, а он — нет. Выражаясь тюремной феней, ты пытаешься "зачморить" всех, кто с тобой не согласен. Не надо этого делать. Это очень некрасиво выгдлядит.
О, мы уже для выразительности на феню перешли. Видимо это как раз чтобы "зачморить"...
Ну, да ладно оправдываться по поводу зачмарения тут бессмысленно. Лучше как нибудь собраться с силами и попытаться доходчиво объяснить свое возмущение его позицией. В конструктивном ключе, тык-сызать и без обиняков.
MS>Я тоже писал резидентный help. Я его так и назвал — MaxHelp или MHelp. Занимал в памяти он 5K и работал очень шустро. Это был полноценный гипертекст, только без картинок. К нему прилагался компилятор, собирающий файлы из текстового вида. И этот компилятор тоже читал файлы по-символьно. Но через некую свою прослойку. Я очень быстро обнаружил, что fread по одной букве работает медленно. Далее я обнаружил, что вызов int21 для прямого посимвольного чтения — это еще раз в 100 медленнее. Каков выход? — читать блоками через int21, а выдавать по-байтно. Фактически, это эмуляция fread, но с гораздо меньшими накладными расходами. Буфера в 256 байт оказалось вполне достаточно. Это для компилятора. В самом резиденте надо было читать как вперед, так и назад. Ну что же, для этого делается всего-навсего двойной буфер — 512 байт и он "поддергивается" в нужные моменты функцией memmove. Все! Была обеспечена и скорость и O(1) памяти. Работало и на меговых файлах без какой-либо видимой задержки на 286/12MHz. Я потратил на отработку этой стратегии пару дней. Это является тривиальнейшей задачей. И "программизм" как таковой здесь вообще ни при чем. Здесь требуются инженерные навыки или даже просто "common sense" как говорят буржуи-пиндосы.
Уууу... ты глянь? А кто тут только что про зачмырение говорил? Я же только упомянул откуда росли ноги компилятора о котором история, а ты выцепив из контекста слово "резидентный" и пошел заниматься вульгарной пенисометрией. Как то не укладывается это с образом народного обвинителя. Не находишь? Я вот нахожу, так что извини, но почин не поддержу.
MS>Так что ты хотел сказать-то этой историей?
Почему-то мне кажется, что как раз ты прекрасно понял, что я хотел сказать этой историей. Для хорошего программиста эти слова конечно сама собой разумеющаяся банальность. Не спорю. Но эти слова не для них. Они скорее для тех кто запуская компиляцию со страхом думает "А не получится ли маоя порграмма слишком медленная? А не нужно ли выжать еще пару бит из тройки байт?". Остальным они или еще не нужны, и или вообще не нужны.
MS> Продемонстрировать свое невежество?
Забавно... "невежество". Это вроде "Ты уже бросил пить виски по утрам?". Как не отвечай, все равно не красиво получится. Прийдется ответить вопросом на вопрос. В чем ты углядел не вежество, то?
MS> Думаю, что нет. Но тем не менее, у тебя это вполне получилось. Извини за резкие слова.
Да, что уж извеняться. Получились не плохо. Цель достигнута.
... << RSDN@Home 1.2.0 alpha rev. 618>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, FR, Вы писали:
FR>Да бывает FR>А мораль такая если работаешь с большими объемами то проверять нужно обязательно, иначе можно нарватся на то что программа грузится минуты вместо секунд. FR>feof убирать пробовал реакции ноль.
в том то и мораль истории. Если уж ты берешься за оптимизацию, то проверять нужно всё и всегда — твои предположения "это работает быстро" и "это работает медленно" могут оказаться очень далеки от действительности.
А пытаться делать "оптимизацию всего и вся", как предлагают некоторые товарищи — это бессмыслица, и результаты ее будут никудышными, как и показал "разбор полетов"
А ты знаешь? Можно подробней?
На отсутствие единого формального процесса я указал еще 2 поста назад (могу, кстати, подкинуть мысль, почему дело обстоит именно так, и заметь, не только в ОО-анализе). Однако, общая схема одинакова — анализ предметной области, построение оптимальной статической и динамической модели.
Мне казалось, что я выразился предельно ясно, а тебе, очевидно, поразвлекаться захотелось. Без достаточной проработки самой модели и всех ее уровней с функциональной т.з. и с т.з. всевозможных ограничений, бросаться в конкретику паттернов, ИМХО, рановато. Тем более, что сами паттерны GoF как раз относятся к статической части модели, на которую мы должны выходить в последнюю очередь (а не начинать с нее, исключения про библиотеки предназначенные для повторного применения обсуждать здесь не буду). Применение паттернов должно являться СЛЕДСТВИЕМ анализа (или, учитывая итеративность, можно уточнить так: следствием очередной итерации анализа), а не обогощать модель лишней/ненужной функциональностью, взятой с потолка или же заведомо рубить требования ввиду ограничений самих паттернов или применяемых связок паттернов. Можно много сказать об итеративности и возвратах в процессе анализа проектирования по мере уточнения и развития модели. Сами эти моменты крайне важны, т.к. очень часто решения раннего этапа проектирования могут вполне огранично подменяться на более поздних итерациях, зачастую упрощаться, "склеиваться", вычленяться похожие части и т.д.
А я лично наблюдал недавно процесс разработки примерно в таком духе: "Ну, тут мы прилепим это, здесь то, а вот в этом месте нечто эдакое, я тут новый ультрасовременный паттерн недавно в и-нете нарыл, очень хочу попользовать прямо здесь и сейчас". И потом вся система с большим трудом втискивается в это прокрустово ложе шапкозакидательских ничем не обоснованных решений. Буквально пару недель назад я помогал разруливать одну из (вполне ожидаемых) "сложностей", которая возникла, вот ведь незадача, уже на этапе воплощения продукта.
И вообще, если охота более конкретно порассуждать о тонкостях ОО-проектирования, ты не стесняйся, высказывайся, только уж пожалуйста, немного более предметно, ok? А то разговор с тобой какой-то односторонний получается. И что не вывод у тебя — так пальцем в небо (ты уж извини, но кому там что требовалось доказать, а главное зачем — я так и не понял ). Вероятнее всего, я кому-то на больной мозоль наступил. Если это так, то возьму свои слова обратно, если оппонент потрудится хотя бы намеком обосновать свою позицию или хотя бы обрисовать собственный интерес в этой ветке спора.
------------
Хотя, положа руку на сердце, я не отношусь к ОО-проектированию с тем религиозным трепетом, который наблюдал у некоторых оппонентов. Нет, здесь никого конкретно не имею ввиду, но на других ресурсах в форумах до смешного доходило. Мне, как электронщику-цифровику со стажем ОО-проектирование преставлется частным случаем того самого системного подхода, применяемого при разработке вычислительных систем/сетей, не более того. Да, есть свои тонкости и акценты, и цена ошибки не так высока (!!! имено ), но суть та же. И кстати, единой формальной методологии разработки вычислительных систем так же не существует. Неплохо формализован расчетный аппарат, но это опять же, лишь вспомогательный инструмент.
VD>Снимаю шляпу перед Pavl-ом Dvorkin-ым. При всем моем несогласии с его мировозрением, писать он умеет убедительнее. Даже те кто, как оказалось, скорее стоит на одних позициях со мной поддержали его зажигательные речи.
Здравствуйте, VladD2, Вы писали:
VD>В общем, разговор с тобой постоянно превращается в театр абсурда. Мне это надоело. Или отвечай на вопросы котоыре тебе задаются без подмены тем и подмены собственных суждени, или можно вообще не начинать обсуждения.
я чего-то не понял про подмену тем. Тему этой подветки начал я, ее же и продолжаю. Пока я вижу попытки сбить с темы меня путем передергивания.
VD>Итак. Попробую еще раз вернусться к обсуждению твоей фразы вызвавшей несогласие АВК (и мое): VD>знание паттернов [b]ничуть не помогает в разработке архитектуры[/b] VD>Хочу получить кратки и прямой ответ. Признашь ли ты эти слова ошибочными, или подверждаешь их правоту.
Таких настырных еще поискать. Диктую большими буквами последний раз.
И я не НЕ СОБИРАЮСЬ отказываться от своих слов, т.к. действитльно уже дважды подмечал эту ситуацию. И во всей этой ветке, вроде бы, раскрыл свое мнение уже достаточно подробно, от которого тоже не собираюсь отказываться: знание одних только паттернов не гарантирует грамотный дизайн. (про который упомянул ты, ибо вся началась подветка с моего ответа на твой пост, конкретно в нем — насчет упомянутых "знаний грамотного дизайна").
Когда AVK спросил "Аргументы?", я ему вкратце обрисовал маленький пример из виденного. Короче вот все сразу:
V>>>> Для библиотеки — это важно, да, это — самоцель. Для функциональных требований бизнес-системы — нет. Именно про этих уродцев я и говорил. И подмечал, что знание паттернов ничуть не помогает в разработке архитектуры.
AVK>>>Аргументы?
V>>Другой уровень проектирования является аргументом? Например, какой смысл применять фасадные паттерны в тех местах, относительно которых требования к функциональности еще не устаканились. Это называется ставить телегу впереди лошади.
AVK>Как это доказывает то, что "знание паттернов ничуть не помогает в разработке архитектуры"?
Могу уточнить, если кто не понял из контекста. Я утверждал, что зазубрить список паттернов недостаточно для грамотного проектирования. Более того, наблюдал примеры "тупого" применения паттернов не к месту, что и озвучил. Так с чем именно ты не согласен?
По сути, точку надо было поставить еще тогда, но куда там
--------
Если и сейчас тебе чего-то покажется мало, или ты элементарно поленишься сходить по приведенным ссылкам, то участвовать в этом, как ты правильно подметил, абсурде, я не собираюсь. Похоже, у AVK паттерны — больной мозоль. Иначе с какой стати внаглую передергивать оппонента по интересующей теме.
я все боялся озвучить эту мысль... но я имею более резкое мнение насчет изучения паттернов новичками. Не с них надо учиться проектировать, не с них. Поимев некий опыт самостоятельного нахождения решений, те, кто уже не новички, совсем по другому впитают эти паттерны, так сказать с гораздо большей пользой. Толку от того, что вместо условий задач студентам давать сразу ответы. Надо именно приучать самостоятельно решать задачи. А после приобретения некого опыта — давать наиболее часто встречающиеся случаи, чтобы в реальной практике не изобретать велосипеды, заодно снабдить терминологической базой.
Аналогично в шахматах. Есть куча известных комбинаций и заведомо известны оценки позиций фигур в этих комбинациях (и эти комбинации имеют свои названия). Однако новичкам их не преподают, их именно учать самостоятельно оценивать позиции фигур на доске. А известные комбинации... после достижения определенного уровня неплохо экономят время и помогают в общении с коллегами.
Здравствуйте, Nickolay Ch, Вы писали:
NC>Тут вообще в основном собираются люди, чтобы поубивать время, насколько я понимаю(поправьте кто-нить, если ошибаюсь). Обычно на философствования времени то не остается.
А у меня наоборот. Только на философию время и остаётся
... << RSDN@Home 1.2.0 alpha rev. 0>>
Если нам не помогут, то мы тоже никого не пощадим.
Я же вроде точку там поставил, но ты меня просто удивил.
VD>
Именно про этих уродцев я и говорил. И подмечал, что знание паттернов ничуть не помогает в разработке архитектуры.
VD>... VD>
И я не НЕ СОБИРАЮСЬ отказываться от своих слов, т.к. действитльно уже дважды подмечал эту ситуацию.
VD>... VD>
Действительно смешно было пытаться приписать мне мысль о том, что "паттерны вредны".
[...]
Вот прямо здесь и сейчас попытайся связать первое и второе предложения (мои) с третьим. Или кто-то пользуется собственной семантикой русского языка, не сверяясь с общепринятой?
V>>извините я не верно выразился
VD>Давно бы так. И не пришлось апельсины с собой всюду таскать.
Понимаешь, я тут посмотрел на всю эту дурацкую подветку и кажется понял еще один момент. В чем причина (глубинная) спора знаешь? В том что ты и еще кое-кто, весьма легко и просто можете предположить, что собеседник идиот, или на худой конец вы готовы согласиться (и то после долгих уговоров), что у собеседника было временное помутнение сознания. Т.е. не было попытки понять собеседника, было банальное переиначивание (см начало поста, специально не удалил) и отчехвостивание по какой-то там своей наболевшей теме. Да начихать мне, должно быть, вообще-то, на чьи-то больные мозоли, однако... Однако, я сейчас дам объяснение совсем другого плана, вовсе не технического.
Когда я увидел, что кто-то меня не так понял, я не поленился объясниться подробней. Мне ведь, глубоко фиолетово, что там домыслил АВК, ибо все остальные читатели поняли именно то, что я хотел сказать (сужу по их замечаниям). Почему фиолетово — потому как АВК не идет на обсуждение. Его стиль — пара малоотносящихся к делу вопросов, а потом какой-нить страшный диагноз по результатм пары несвязанных ответов на пару несвязанных вопросов. ню-ню, как говорится... Однако, ты еще не забыл, что публичный статус ресурса накладывает некие правила игры? Опонент продемонстрировал, что понял меня каким-то свои образом и я, разумеется, вынужден был потратить время на еще несколько постов с пояснением собственной позиции.
Понимаешь, тут никто не расписывает многотомные трактаты, все выражаются по-возможности кратно, надеясь на адекватное восприятие коллег по цеху. Если ты чего-то не допонял, дык уточни, желательно корректно, и мир станет гораздо лучше.
Но куда там... это было просто верхом вежливости с твоей стороны называть пояснения собственной точки зрения увертками. Вот он — здравствуй бред! "Мы тебя поняли так-то и так-то, даже если ты имел ввиду другое, это уже не имеет значения и учти, у тебя нет права на пояснения. Ты можешь только умолять о пощаде. В крайнем случае великий и ужасный Я согласен на извинения"
Вообще-то это не то, чтобы бред (вот я опять неточно выражаюсь)... есть слова более точные, только очень оффтопные, потому как весьма конкретные.
Одним словом, а-я-яй, больше так не делай, ok?
(и пощади rsdn-овскую базу ради дел праведных, хватит фигню всякую пережевывать, это как совет "зрителя из зала", коим большую часть времени являюсь)
Здравствуйте, Nickolay Ch, Вы писали:
NC>Тут вообще в основном собираются люди, чтобы поубивать время, насколько я понимаю(поправьте кто-нить, если ошибаюсь). Обычно на философствования времени то не остается.
Нет. Не путай со священными войнами. Форум действительно очень полезный. Почему он полезен для меня:
1. Здесь собираются люди с различных языков, разных проектов, и вообще с разным жизненным опытом. Здесь узнаешь вещи и направления о которых и не догадывался потому как не встречался.
2. Здесь обсуждаются вещи которые для других являются offtop. Ну например, где еще можно сравнивать языки между собой. Именно корректно сравнивать. Благодаря этому форуму я узнал многие вещи о других языка. Или о языках о существовании которых не знал.
3. Здесь обсуждаются отношение к программированию, и в программировании. То есть философия. А философия — точная наука. Просто программисты очень любят спорить.
Этот форум дает широкий кругозор. Собственно благодаря ему я ентот кругозор себе сильно расширил.
Среди недостатков, повышенная флеймистость, и некоторые темы исчезают отсюда в недрах священных войн.
Здравствуйте, VladD2, Вы писали:
VD>1. Собираем список нареканий пользователей.
У меня есть только одно замечание к данному тезису. Ничто не может насобирать столько замечаний пользователей сколько сам разработчик в роли пользователя
... << RSDN@Home 1.2.0 alpha rev. 0>>
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Вполне возможно. Кстати, студент вовсе не пострадал PD>Еще раз — не в POINT дело. Его вполне можно и по значению передать. Дело в принципе — незачем большие структуры по значению передавать.
Да нет, проблема в другом. При современном развитии железа и компиляторов, очень трудно прогнозировать как та или иная операция выйдет по производительности. В принципе от алгоритмической сложности отойти невозможно. Но вот сложность того или иного метода дизайна спрогнозировать сложно. Java — пытается запихнуть объекты по возможности в стек. Пытаются выдавить лишние действия из циклов. Пытаются работать через регистровую память. Пытаются уместить данные в кэше процессора. Пытаются ублажить конвейры процессора. И многое многое многое о чем я не знаю. Я только знаю что эта шняга будет работать, но каждый раз лазить в ассемблер и узнавать как оно в реальности работает, и узнавать что куча кода скомпилировалось в одну ассембленую команду(как это часто бывает в STL), я не могу и не буду. Знания конечно сила, я могу примерно прогнозировать во что это выльется для знакомых мне платформ. Но явно этими знаниями я пользуюсь редко и только для наибольшего криминальных команд и подсистем.
Лучше я отдам эти вопросы на откуп умному компилятору и заумному процессору. А сам буду делать логику, которая нужна мне а не им. Они сами справятся.
Здравствуйте, VladD2, Вы писали:
VD>Поясную свою оценку...
VD>Это за увертывание от прямого ответа и попытку переиначить свои же слова.
Ненавижу это занятие — приводить отрывки недавних постов, с целью "разбора полетов", но вынуждаешь:
VD>Нет, дело как раз не очень понятное. Кроме знаний о тонкостях реализации нужно еще иметь знания по грамотному дизайну приложений и желание этот самый грамтоный дизайн культивировать.
Может я не правильно истолковал выделеное? Что это за знания такие? Относительно дизайна мне кажется более уместным понятие умение. Почему именно так? Потому как сам современный ОО дизайн (как процесс) — это все еще лишь набор практик, которые надо уметь применять (как и само ОО — суть набор практик, встроенных в языки, и что смешно, в разные языки встроен разный набор практик, именующихся одним понятием ОО). Потому-то и не может быть единого формального подхода, если уж речь заходит о применении практик. И слово "применять" мне кажется здесь не точно выражающим смысл. Можно применять эти практики вообще в проекте, в смысле просто использовать (вчера был констатирован факт использования таких-то практик в таком-то проекте), или же можно применять практики в процессе анализа (вот AndrewVK это слово не дает покоя ), т.е. в том смысле, что накладывать имеющиеся практики на конкретные требования текущего уровня проектирования. Эти накладываемые практики должны быть наложены успешно. В чем измеряется успешность? Грубо — в степени реалиации требований. В чем измеряется "удачность"? — обратно пропорциональна сложности полученного решения. В области ПО удачность еще измеряется легкостью повторного применения (опять же — в случае нужды, и кстати, касательно общей темы — борьбы с оптимизациями, ведь это тоже один из частных случаев оптимизации — доведение кода до возможности повторного использования. И менеджеры тоже часто борятся с точно такой же "необоснованной" оптимизацией. Обоснование всегда может быть только одно — требования)
Влад, ты сейчас хоть разницу чуствуешь между оттенками словосочетания "примененение паттернов"? Даже если нет, то мне уже все равно нечего добавить.
Ну а дальше — мой ответ. Есть шанс попытаться судить повторно о моих словах:
Добавлю еще насчет грамотного дизайна. Опять все встает с ног на голову. Раньше люди решали путем анализа вполне конкретные программистские задачи. Потом обнаружили их похожесть. Потом дали имена паттернам и использовали так: спроектировал что-либо, максимально удовлетворяющее требованиям, а потом _обяснил_ разработку на языке паттернов. Т.е. язык паттернов — это всего лишь терминологическая база. А молодежь как сейчас что-то проектирует??? Вместо того, чтобы решать поставленную задачу, крутит эти паттерны как кубики Лего, путем полного перебора стараясь подобрать нечто условно отвечающее поставленной задаче. И выходят монстры, один другого страшнее. И _паттэрны_ вроде есть, и неграмотно при этом...
Что же именно меня немного раздражает в описанной мной ситуации? Из бесед с молодыми и горячими проектировщиками мне показалось, что сам факт применения паттернов уже сам по себе означает тот самый грамотный дизайн (который упомянул ты). Т.е. будто бы существует прямая связь: наличие паттернов в проекте ==> удачное решение. И мне так и не удалось объяснить отсутствие этой зависимости, т.е. разницу между необходимым и достаточным. (хотя и факт необходимости — тоже спорный)
Причем, я наблюдал такую ситуацию неоднократно именно последние пару лет. И вот, к моему величайшему удивлению мне приходится вести подобный спор на rsdn. Ну что же, тем лучше. В следующий раз я буду просто давать оппонентам ссылки на эту ветку.
-------------
Что же такое есть анализ в процессе проектирования — я отвечу Андрею в его ветке. И не только об ОО.
Здравствуйте, Pavel Dvorkin, Вы писали:
AVK>>Можно попросить указать на тот кусок, где я относился с религиозно-фанатичным обожанием к паттернам?
PD>Нельзя . Вопрос не ко мне — я только процитировал из постинга eao197
Не смешно. Подобные подколки отнюдь не способствуют конструктивному стилю общения.
Здравствуйте, vdimas, Вы писали:
V>Далось тебе это пресловутое "проползание на животе". На профильных специальностях готовят вполне адекватно
Когда я учился ничего (т.е. абсолютно ничего) не говорилось о проектировании приложений, за исключением навязшего на зубах восходящего/нисходящего подхода. Сейчас ситуация еще хуже — в качестве архитектора современный студент величина отрицательная. Отрицательная, потому что перво-наперво приходится тратить массу усилий на избавление от дурацкий навыков, которым его научили в ВУЗе.
VladD2,
> для этого как раз нужно отказаться от любьви к оптимизациям до беспаметсва и обратить внимание на дизайн приложения. Собственно на то что я этим тогда пренебрег я и намекал. Как в прочем намекал и на то, что именно этим чревато мировозрение против которого я сейчас выступаю. Мне казалось, что тут собрались разумные люди и им не нужно до такой степени разжевывать столь очевидные вещи. Но видимо в консерватории что-то не так (с).
Намекаю, что именно не так: этим разумным людям тебе еще и приходится объяснять, в чем именно состоит их мировоззрение, подкрепляя это дело примерами из твоей жизни. Внешне выглядит так, как будто ты воюешь с придуманными тобою же призраками, персонифицируя их в реальных оппонентах, подчас к твоей модельке отношения не имеющих.
Posted via RSDN NNTP Server 2.0 beta
Легче одурачить людей, чем убедить их в том, что они одурачены. — Марк Твен
VD>Однако я искренне считаю, что такая безрассудная борьба за производительность исходящая от преподавателя крайне деструктивно скажется на его учениках.
Думается мне, что товарищ Дворкин таки прав насчет оптимизации и стремлении к ней как к недостижимому идеалу коммунизьма. Умение писать быстрые проги с минимальными требованиями по памяти — это в некотором смысле культура пргграмминга. Если чел умеет писать оптимальные проги, то неоптимальные он напишет без проблем (если опнадобится) А вот наоборот — вряд ли.
Здравствуйте, GlebZ, Вы писали:
AVK>>Их тут полно. Просто писать они стесняются. GZ>Наверно. Тут и есть и профессионалы которые только читают да только минусы ставят(не буду показывать пальцем) GZ>[лишнее скипнуто]
А если они только читают, то почему ты решил что они профессионалы?
AVK>>Не помогут. GZ>И ты согласен.
Конечно. Серебрянной пули не существует.
AVK>>Знаешь, лично я воспринял это иначе. Сначала он обозвал паттерны чуть ли не мировым злом, а потом пытался доказатьчто он совсем не то имел ввиду. GZ>Нет. Ты по моему несколько некорректно прочитал его сообщение. Он высказал мнение о практике применении паттернов а не об их общей полезности(в чем существует множество аспектов). Правда он сделал несколько сумбурно ограничившись только паттернами дизайна.
Не знаю. Я не представляю как нужно извратить логику, чтобы трактовать его собственные фразы так как предлагается. Имхо это просто нежелание признаться в неправоте даже в мелочах.
? Нет, ты не путаешь цели со средствами, ты просто навязываешь свои цели и приоритеты другим. Ну нет у меня задач, требующих молниеносного чтения данных из файла. А если появятся, то уж на блочном чтении дело не остановится. В дело пойдёт сначала кеширование, а потом и до map-файлов дойдёт. Но пока таких нет. И не только у меня, а у подавляющего большинства здесь присутствующих, т.к. времена, когда это было действительно насущей проблемой для масс давно прошли.
... << RSDN@Home 1.2.0 alpha rev. 0>>
Если нам не помогут, то мы тоже никого не пощадим.
FR> А красивая архитектура и оптимизация не антиподы, очень часто это вещи совершенно независимые.
"Не красивые самолёты не летают". Красота это, в первую очередь, мерило функциональности. Соответсвенно "некрасивая программа" это когда в ней что-то не так. Если кто-то считает красивой тормозную программу, то такой человек только тормозные программы и может делать. Потому что это его понимание "правильности".
А дай-ка и я свой вклад внесу. За основу взял твой, но переделал по сути
#include <stdio.h>
#include <time.h>
//------------------------------------------------------------------------------
void Test( int nRepeat, int nPasses, int nSize)
{
char buf[1024];
double sum = 0.0;
FILE *file = fopen("test.txt", "rb");
clock_t t1 = clock();
for ( int i = 0; i < nRepeat; i++)
{
fseek(file,0,SEEK_SET);
for ( int j = 0; j < nPasses; j++)
size_t count = fread(buf+j, 1, nSize, file);
for(j = 0; i < 1024; ++i) sum += buf[i];
}
fclose(file);
clock_t t2 = clock();
printf("nSize = %d, time = %d, sum = %f\n", nSize, t2 - t1, sum);
}
int main(int argc, char *argv[])
{
Test(100000, 1024,1 );
Test(100000, 1, 1024);
return 0;
}
Автоматический буфер — это специально для тех, кто меня упрекает в том. что я могу иметь memory overrun. У них прекрасная возможность появляется еще раз меня упрекнуть, грешно им этой возможности не дать . Проверку, открылся ли файл, убрал по той же причине.
Итак, читается все время один и тот же первый Кбайт файла. nRepeat — цикл для замера времени. nPasses (число проходов цикла) — как нетрудно догадаться, либо 1024(побайтно), либо 1 (Кбайт) Сейчас, конечно, мне скажут — а что будет если иные значения передать ? Не передавайте, очень Вас прошу . Ну а nSize — размер элемента — 1 или 1024.
Еще раз обращаю внимание — весь Кбайт давно в кэше. Обращений к диску здесь вообще не происходит.
Результат (Release, VC6)
nSize = 1, time = 5546, sum = 70936.000000
nSize = 1024, time = 454, sum = 70936.000000
20 раз не получилось, только 12, ну да ладно, хватит и этого
Пойдем дальше. Перепишем это на WinAPI напрямую
void Test( int nRepeat, int nPasses, int nSize)
{
char buf[1024];
double sum = 0.0;
HANDLE hFile = CreateFile("test.txt", GENERIC_READ,0,NULL,OPEN_EXISTING,0,0);
clock_t t1 = clock();
DWORD dwBytes;
for ( int i = 0; i < nRepeat; i++)
{
SetFilePointer(hFile, 0, 0, FILE_BEGIN);
for ( int j = 0; j < nPasses; j++)
ReadFile(hFile,buf+j, nSize, &dwBytes,NULL);
for(j = 0; i < 1024; ++i) sum += buf[i];
}
CloseHandle(hFile);
clock_t t2 = clock();
printf("nSize = %d, time = %d, sum = %f\n", nSize, t2 - t1, sum);
}
Эффект чудовищный. Я уж думал, что у меня просто зависло. Проверил — нет. Пошел покурить, вернулся — готово.
nSize = 1, time = 230562, sum = 70936.000000
nSize = 1024, time = 375, sum = 70936.000000
Объяснение.
Для чтения 1024 байт за 1 раз ReadFile несколько эффективнее. fread — штука сложная, ее текст несколько десятков строк занимает. Ей проверить надо, не вышел ли я за границы файла, не пересек ли границу ее внутреннего буфера. А ReadFile — это просто вызов драйвера ФС, тот обнаруживает, что запрос идет с нулевого смещения, размер хороший, ну и копирует мне из кеша 1 Кбайт. Но, в общем, разница не столь уж большая — 375 против 454.
А вот при чтении по 1 байту ReadFile ужасен. На каждый вызов делается переключение в защищенный режим по int 2E, и делается это у меня 100000 * 1024 раз. Неудивительно, что результаты просто устрашающие.
Итог. При буферизованном вводе fread демпфирует эффект чтения по одному байту. В результате получаем в 12 раз хуже, всего лишь . Ну а при небуферизованном вводе (обращения к ОС) имеем проигрыш в 615(!!!!) раз.
Разумеется, надо учесть и то, что при чтении по 1 байту у меня проход по циклу 1024 раза, а при чтении по 1024 байта — всего 1 раз. Но ведь если хотите читать по одному байту , а прочитать 1024 — платите циклом .
В действительности это не очень существенно. Заменим строчку
ReadFile(hFile,buf+j, nSize, &dwBytes,NULL);
на
f(j);
где
void f(int j)
{
j++;
}
(сделать это приходится, иначе оптимизатор вообще выкинет цикл)
nSize = 1, time = 687, sum = 17621.000000
nSize = 1024, time = 125, sum = 17789.000000
Сумма, здесь, конечно, бессмысленная — данные не читались, мусор суммировался. Так что все время уходит именно на ReadFile.
P.S. Честно говоря, знал, что эффект будет до своих опытов, но чтобы такой — не ожидал. Господа, не откажите в просьбе — проверьте код. Может, я ошибку какую-то сделал и не вижу ее ?
Здравствуйте, vdimas, Вы писали:
GZ>>Отмазка. У буржуинов бывают разные системы обучения. V>Знаешь, довелось поработать консультантом в филиале одной весьма известной тебе фирмы в штатах. В общем, ехал — боялся, приехал — смеялся. Не то, чтобы уровень у "тамошних" программистов низкий, ни в коем случае, таких там не держат... А вот в плане "узколобости" — это сплошь и рядом. Слишком узкая специализация и зацикленность дает себя знать.
Во-первых, мне приходится делать такие вещи на средней полосе России.
Во-вторых, отчего же на RSDN так хорошо относятся к MIT'овским лекциям. И я что-то давно не читал интересные работы с постсоветских стран(хотя есть и такие). В основном буржуйские.
Вообще у них и у нас проблема одна. Если ты окончишь крутой вуз или курсы — начально зарплату ты будешь получать одну и ту же. Хотя у нас(по крайней мере я знаю) ситуация выправляется.
V>Вот ты какие задачи решал на зимней и летней практике первого курса, помнишь? У нас было дано окол 20 задач ......
Мое образование значительно хуже. Нас таким не мучили. Это что за универ такой крутой? Он в Севастополе?
V>А наши коллеги "оттуда" в это время усиленно учат библиотеки и технологии... Самые продвинутые — учат команды Unix Shell... Вот она и разница.
Проблема в том, что у нас не учили продвинутым библиотекам и технологиям. Сейчас в ведущих вузах подход меняется. Начинают учить вводить авторизованные курсы ведущих коммерческих компаний. Насколько это хорошо или плохо, вопрос второй. По моему, хорошего здесь значительно больше.
V>Ты легко можешь нарыть мапы стадий и артефактов RUP на наши 19-е и 34-е. Ради интереса, потрать на это время, ты обязательно удивишься тому, как современный RUP неплохо отображается на наши ГОСТ-ы хрен его знает каких годов.
Да сам RUP тоже не новенький. А вообще RUP подобные технологии родились очень давно.
V>ГОСТ — отличный пример систематизации стандартов. То, что ГОСТ отстает на сегодняшний день более чем на 20 лет имеет под собой скорее экономические причины (наша разруха), а не технические (слабоумие наших инженеров).
Нет, бюрократические. Сейчас у нас вроде бы облегчили требования следования гостам. Обязательных уже значительно меньше(хотя и до этого мало кто их выполнял).
Но у Госта есть и другие стороны. Например у нас ЭЦП на алгоритмах не соответсвующих ГОСТам и сделанные не сертифицированными криптопровайдерами не имеют юридической силы. Долгое время вообще существовал только один сертифицированный криптопровайдер, который принадлежал сыну шишки из ФАПСИ.
V>Однако, склонность к обобщеным решениям и правилам в наших ГОСТах по прежнему держит их на некоем уровне актуальности (все-таки 20 лет без обновления не позволяет их полностью назвать актуальными) даже в такой стремительно развивающейся области, как разработки IT (как хард так и софт).
+1
GZ>>Наши проблемы в том, что в институтах есть хорошие математики, но нет хороших разработчиков. Хорошие разработчики не работают в институтах. V>Да, проблема в ВУЗ-ах в первую очередь с кадрами, но проблема чуть другая. Не платят нихрена. При мне в 93-95-е уходили в первую очередь сильные как преподаватели и как личности. Уходили строить свою новую жизнь в этой стране, которая их "кинула". Больно и обидно было на это смотреть. Я сам остался в ВУЗе в аспирантуре, но пробыл там... ровно месяц. После получения первой "ЗП" срочно побежал искать работу
Мне тут дали почитать один внутривузовский документик. Оказалось что в Москве, между ведущими вузами уже существует конкуренция. И зарплаты там за преподавание достаточно нормальные. Для ведущих преподователей.
V>И откуда ты взял про "нет хороших разработчиков"? Классический советский ВУЗ — это в первую очередь куча тем для разработок. "Тема" — это такой институтский термин, сейчас почти не используется. Мне довелось с 3-го по 5-й курс работать в лаборатории, делали весьма сложные проекты (хард+софт). Подозреваю, что ты учился в "постсоветское" время. Конкретно наша лаборатория развалилась в 95-м году. Как раз из-за ухода ведущих спецов.
Учился да. Я вот работал в науке с 92-по 97. Раньше главным заказчиком было государство. Потом государству стало по фигу. А новых заказчиков тогда еще не научились искать. Вот и развалилось все. Те кто у нас научился находить, и сейчас неплохо живут.
V>И это дурацкое платное образование... Не зря его все собираются отменить на Украине, да денег нет. Качество образования падает. Более умный абитуриент, не прошедший на "бюджет" вытесняется платными "разнарядками". соотношение 1/3:2/3 — это доли "бюджетников" и "платников"... На 90% вторые 2/3 — баласт, которые все-равно не компенсируют расходы на свое обучение (около 10 тыс долларов обходится студент в течении 5-ти лет гос-ву, а платят за учебу эти "платники" гораздо меньше, т.е. пока налицо только вред)
Дурацкая популистская идея. Несмотря на некоторые выпендрежи, у буржуях образование могут получить фактически все. Для этого надо изначально хорошо учиться, и взять кредит который будешь возвращать. Тогда и качество образования для самого человека вещь важная. И качество образование выше в материальном плане. Государства, особенно наши, неспособны эффективно управлять образованием. А 10 штук возвратить за последующие лет 10 работы, вполне легко и ненакладно. Государство взамен этого могло бы давать кредиты и обеспечить конкуренцию между ВУЗ'ами за абитуриентов.
Здравствуйте, Дарней, Вы писали:
Д>...Нет никакого общего понятия красоты, ибо понятие это субъективное и к тому же подверженное изменениям со временем...
– Так, может, вы нам откроете сию тайну, – язвительно буркнул главный из художников, – раз уж вы такой знаток.
– Я не знаток, я просто врач, но я много думал над вопросами анатомии. Если упростить определение, которое на самом деле гораздо сложнее, как и вообще все в мире, то надо сказать прежде всего, что красота существует как объективная реальность, а не создается в мыслях и чувствах человека. Пора отрешиться от идеализма, скрытого и явного, в искусстве и его теории. Пора перевести понятия искусства на общедоступный язык знания и пользоваться научными определениями. Говоря этим общим языком, красота – это наивысшая степень целесообразности, степень гармонического соответствия и сочетания противоречивых элементов во всяком устройстве, во всякой вещи, всяком организме. А восприятие красоты нельзя никак иначе себе представить, как инстинктивное. Иначе говоря, закрепившееся в подсознательной памяти человека благодаря миллиардам поколений с их бессознательным опытом и тысячам поколений – с опытом осознаваемым. Поэтому каждая красивая линия, форма, сочетание – это целесообразное решение, выработанное природой за миллионы лет естественного отбора или найденное человеком в его поисках прекрасного, то есть наиболее правильного для данной вещи. Красота и есть та выравнивающая хаос общая закономерность, великая середина в целесообразной универсальности, всесторонне привлекательная, как статуя.
Нетрудно, зная материалистическую диалектику, увидеть, что красота – это правильная линия в единстве и борьбе противоположностей, та самая середина между двумя сторонами всякого явления, всякой вещи, которую видели еще древние греки и назвали аристон – наилучшим, считая синонимом этого слова меру, точнее – чувство меры. Я представляю себе эту меру чем-то крайне тонким – лезвием бритвы, потому что найти ее, осуществить, соблюсти нередко так же трудно, как пройти по лезвию бритвы, почти не видимому из-за чрезвычайной остроты. Но это уже другой вопрос. Главное, что я хотел сказать, это то, что существует объективная реальность, воспринимаемая нами как безусловная красота. Воспринимаемая каждым, без различия пола, возраста и профессии, образовательного ценза и тому подобных условных делений людей.
Иван Ефремов, Лезвие Бритвы.
... << RSDN@Home 1.1.4 stable rev. 510>>
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, IT, Вы писали:
IT>Я же говорю, мы с тобой о разном. Я буду заниматься оптимизацией процессов, которые нужны пользователю, потому что я сам пользователь. Не пытаюсь прикинуться, а именно сам пользователь и есть.
Нет. Нет и нет. Невозможно построить такую же систему как и у заказчика. Такую систему можно сделать в небольшом количестве решений, но не в большинстве. И бизнес-процессы разные, и система не отделывается от лейбла тестируемой. Разработчик в роли пользователя оперирует человеко-часами и знаниями системы. Ему ничего не стоит в том или ином случае воспользоваться этими знаниями. И если ему что-то неудобно, то у него есть отмазка в виде человекочасов. Пользователи на это меньше обращают внимание.
Как тебе такие примеры из жизни:
Поставили себе систему. Оттестировали. Вроде работает, и работает эффективно. Ставим пользователю — нарекания. У нас было 2-3 сотни объектов. У него несколько миллионов. Хорошо, взяли от него базу. Но только вопрос в том, что база не берется одна к одному. В ней заменяется вся коммерч. информация суррогатными данными. В результате, статистика базы неверна, и проследить планы запросов почти невозможно.
Или другой пример. Юзаем систему, эмулируем бизнес-процесс. Один отчет создается от 2-4 часов. Плохо. Не будет же пользователь ждать 2-4 часа каждый раз. А отчет нам кажется для выстроенного бизнес-процесса важным. Тратим кучу человекочасов на оптимизацию. Переписываем значительную часть кода. Делаем его более расширяемым, чтобы подцеплять для других отчетов. Сообщаем заказчику о том, что сделали, ставим update. На следующий день заказчик звонит и говорит, дескать вы бы сначало нас спросили нужно ли делать этот отчет. По ихнему бизнес-процессу, этот отчет будут делать ну минимум раз в полгода. И если начальник почешется и вспомнит. Поэтому 2-4 часа можно было бы и потерпеть. К тому же, на той кластерной системе время было значительно меньше. А вот избыточную нагрузку на сервера БД возникшую после оптимизации — терпеть не будут. Откатили. Потеряли на пустом месте деньги, силы и время. А вопрос был только в том, чтобы сделать один звонок и спросить у пользователей.
Поэтому нет правды у разработчиков. Ну нельзя предугадать что будет твориться у пользователей. Задача разработчика помочь высказать идеи и реализовать их. Но ни в коем случае не подменять пользователей собою.
Здравствуйте, eao197, Вы писали:
E>Таких POD типов не так уж мало. Два поля типа int в C-шной структуре и все -- POD тип в два раза больше указателя получается.
Кстати, такой объект есть в Win32 — POINT, 8 байт. И в Win32 есть функции, которые принимают его по значению. Причина — в Win16 POINT имел размер в 4 байта, указатель на него (дальний) — тоже 4 байта, так что все равно. А изменить интерфейс функции Win API, естественно, нельзя.
У меня буквально на днях на занятии было вот что. Показывает мне студент код (реально он его из Петцольда выдрал, я им не запрещаю, лишь бы разобрались — технические приемы). И вот у него (т.е у Петцольда) там POINT передается по значению. А функция, к слову сказать, вызывается на сообщении WM_MOUSEMOVE, так что чаще чем десятки раз в секунду ее все равно не вызовешь. И делается там много такого (рисование линий в режиме R2_NOT), что на фоне этого оверхед в 4 байта — форменный пустяк. Ни на быстродействие, ни на память это не влияет.
Должен был я ему замечание сделать или нет ?
Я замечание сделал. Аргумент простой — если он привыкнет передавать объекты с размером больше sizeof(void*) по значению — будет это и дальше делать, причем там, где это может серьезно сказаться.
Здравствуйте, AndrewVK, Вы писали:
AVK>Польза очень простая — товарищь агитирует за крайне вредную для новичком идею — что паттерны вредны.
Опа. Тут появились новички?
А кто тебе сказал что все иогурты полезны. Паттерны дают словарь, пытаются описать условия и цели, но не учат применять на практике. Поэтому вредная идея состоит в том, что паттерны полезны и вредны одновременно. Я вообще не понимаю, каким образом архитектора можно сделать архитектором по книгам хотя паттерны дают такое впечатление. Поэтому не все иогурты одинаковы полезны. Особенно новичкам. Научить думать, сомневаться и оценивать свое решение значительно сложней и значительно полезней чем чтения книжки. И паттерны(за исключением пожалуй тех паттернов о которых я сказал) тут не помогут.
Паттерны безусловно полезны не новичкам, поскольку расширяют его кругозор и дает дополнительное поле для игры ума в построении решений. Ну и дает некоторую терминологию в общении.
Ну и нельзя не упомянуть, что у каждого разработчика свой используемый набор паттернов.
С уважением, Gleb.
ЗЫ судя по всему, позиция вдимаса не отрицала паттерны как таковые и чем-то похожа на мою.
Здравствуйте, eao197, Вы писали:
E>А вот по поводу блочного и посимвольного чтения данных из файла лет 5-6 назад мне статья попалась (кажется в "Открытых системах"). Там метрики приводились для какого-то Unix-а. Так вот меня поразило, что во многих случаях блочное чтение не имеет преимуществ над посимвольным чтением.
Насчет "какого-то Unix" а не знаю. Но в любой защищённой OC вызов системных функций дорог сам по себе.
И если ты будешь читать файл по байту ими, то это будет очень медленно. По любому необходима буферизация в адресном пространстве процесса.
E>Учитывая, что сейчас файловые системы очень умные, решение о том, читать ли данные посимвольно или поблоково, лучше принимать с учетом конкретной ОС и железа.
Реализация буферизации -- тривиальная задача. Тем более, что обычно для доступа к файлам используются уже готовые библиотки, где буферизация уже реализована. Так что буферизация доступа к файлу -- это тот случай, когда надо не думать, а действовать.
Здравствуйте, Nickolay Ch, Вы писали:
NC>Тут вообще в основном собираются люди, чтобы поубивать время, насколько я понимаю(поправьте кто-нить, если ошибаюсь).
В моем случае ошибаешься. Мне участие в этом форуме помогает избавляться от однобокости взглядов, которая неизбежно возникает при программировании на одном языке, в проектах одного типа и участием только в специализированных форумах (к примеру, C/C++ или Unix).
... << RSDN@Home 1.1.4 stable rev. 510>>
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, Павел Кузнецов, Вы писали:
ПК>Намекаю, что именно не так: этим разумным людям тебе еще и приходится объяснять, в чем именно состоит их мировоззрение, подкрепляя это дело примерами из твоей жизни. Внешне выглядит так, как будто ты воюешь с придуманными тобою же призраками, персонифицируя их в реальных оппонентах, подчас к твоей модельке отношения не имеющих.
Дискуссия развернушаяся здесь однозначно показывает, что я правильно оценил мировозрение с которым борюсь.
... << RSDN@Home 1.2.0 alpha rev. 618>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
VD>Предположим завтра тебя попросят написать программу или сайт для хранения и поиска поворских рецептов (ну, скажут, что дадут лимон баксов, а работы там не неделю...). Неуже ли ты из-за этого по быстрому в повора переквалифицируешся?
В повора нет, но свои рецепты там хранить буду
... << RSDN@Home 1.2.0 alpha rev. 0>>
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, IT, Вы писали:
VD>>Предположим завтра тебя попросят написать программу или сайт для хранения и поиска поворских рецептов (ну, скажут, что дадут лимон баксов, а работы там не неделю...). Неуже ли ты из-за этого по быстрому в повора переквалифицируешся?
IT>В повора нет, но свои рецепты там хранить буду
Самогон?
... << RSDN@Home 1.2.0 alpha rev. 618>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, FR, Вы писали:
FR>Здравствуйте, eao197, Вы писали:
E>>Здравствуйте, FR, Вы писали:
FR>>>Давай представим себе что некая фирма выпустила текстовый редактор, самый крутой на рынке по своим возможностям, но на современных машинах, отклик после нажатия на клавишу две секунды. В таких условиях каким требованием будет быстродействие?
E>>Опыт IDEA показывает, что многих вполне устраивает отклик в две секунды
FR>то есть слово test набирается 8 секунд?
А шо вы себе думаете... У меня примерно полгода на ММХ 166 с 64М на борту стоял Жава Билдер — так вот бывали времена, что когда я нажимал enter чтоб перевести каретку комп так втыкал, что я спокойно шел на кухню ставить чайник и достать печеньица...А такие вещи, как код-комплит, подсветка списка параметров, подсветка скобок и т.п. нужно было вырубать сразу.
Здравствуйте, Pavel Dvorkin, Вы писали:
PD> Там то, что называется передачей по ссылке и по значению — в любом случае есть передача ссылки на объект, поскольку к самим объектам доступа нет.
Опять двойка. Читать про value-типы.
1.1.4 stable rev. 510
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Ох, боюсь, что именно они профессионалы, а не все мы здесь, грешные. Ну разве профессионалы будут обсуждать нелепые конструкции и доказывать , что они нелепые ?
Думаю будут. Архитектор, который, вместо того чтобы обсудить какие то свои мысли в комьюнити (весьма профессиональном, хочу заметить) продолжает варится в собственном котле и убежден что здесь народ занимается ерундой, не профессионал вовсе, а надутый индюк.
Здравствуйте, vdimas, Вы писали:
V>В общем, весь этот "флуд" с моей стороны скорее вызван твоей манерой ведения беседы, типа "изворачиваешься", "юлишь"... Короче, модератора на тебя нет.
Я очень рад, что ты не являешся нашим модератором и никогда им не сожешь стать. Иначе бы разговаривать тут стало бы не безопасно.
V>что знание одних только паттернов не помогает и далее по тексту.
Тебя сразу переспросили по поводу этих слов. Но вместо того чтобы просто сказать "я неверно выразился" ты развел флуд. Причем продолжашь делать это и дальше. Переводя обсуждение на личности. Вопрос — зачем?
ЗЫ
Обсуждение моей линости поискипаны.
... << RSDN@Home 1.2.0 alpha rev. 618>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, IT, Вы писали:
IT>Блин, надоела уже вся эта грызня.
Мне тоже . Но когда некоторые участники дискуссии начинают обвинять во всех смертных грехах, демонстрируя при этом порой мвое непонимание основных принципов, да еще делают это с крайне серьезным видом — единственное, что остается — относиться к их постам с иронией. Что я и делаю
IT>Павел, знаешь в чём твоя ошибка? Особенно в терминах цели vs. средсва
? Нет, ты не путаешь цели со средствами, ты просто навязываешь свои цели и приоритеты другим.
Игорь, да почему ты решил, что я навязываю ? Я просто высказал свою точку зрения и отстаиваю ее. Другие имеют право с ней соглашаться или нет. Кстати, судя по оценкам, большинство согласны (хотя, скажу в скобках, аппелировать к мнению большинства — не аргумент). Имею я право ее отстаивать или нет ?
>Ну нет у меня задач, требующих молниеносного чтения данных из файла. А если появятся, то уж на блочном чтении дело не остановится. В дело пойдёт сначала кеширование, а потом и до map-файлов дойдёт. Но пока таких нет. И не только у меня, а у подавляющего большинства здесь присутствующих, т.к. времена, когда это было действительно насущей проблемой для масс давно прошли.
Ну и бога ради. Еще раз — я же не министерство информатики, которое собирается выпустить инструкцию, обязательную для всех. Не согласны со мной — и не надо, кто у вас отнимает право делать иначе ?
Здравствуйте, vdimas, Вы писали:
V>Счастливый человек. ИМХО, судя по твоим приоритетам, общий дизайн ты уже давно не разрабатываешь, он у тебя "сам собой получается естественным образом".
Куда ж без дизайна? И дизайн и паттерны, всё как положено. Только средства это всё. Набор инструментов, кубиков и кирпичиков. Каждый подбирается под конкретную задачу. Ты же станешь лобзиком валить Беловежскую пущу? Так же как и на воробьёв тратить ядерные баллистические единицы. Так же?
V>Собственно, так и должно быть при наличии опыта.
Наличие опыта мне говорит другое. Сколько не проектируй, всё равно придёт заказчик и принесёт в своём воспалённом воображении новые идеи, принимающие самые причудливые формы. И весь твой дизайн после этого надо будет передизайнивать. От этого никуда не денешься, это нормально и с этим надо учиться жить. Именно поэтому я и говорю о сопровождабельности как о цели.
V>А у некоторых пока стоят проблемы, (хе-хе) с путями реализаций требований. Эти пути и обсуждаем.
А ты начинай делать, а не обсуждать. Очень часто пока не начнёшь делать ничего не видно и не понятно, а как только начнёшь, то сразу и увидишь куда грести. Просто будет готов всё это в какой-то момент переписать, забей себе в планах время на рефакторинг и всё получится
... << RSDN@Home 1.2.0 alpha rev. 0>>
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Должен был я ему замечание сделать или нет ?
PD>Я замечание сделал. Аргумент простой — если он привыкнет передавать объекты с размером больше sizeof(void*) по значению — будет это и дальше делать, причем там, где это может серьезно сказаться.
+1
Я и сам такие замечания делаю. Если с "детства" приучить С++ программиста передавать пользовательские типы по константным ссылкам или указателям, то проблем с производительностью на ровном месте у него точно не будет. И если нужно будет устранить какой-нибудь bottle neck, то изменять придется либо архитектурное решение, либо алгоритм. А не банальную передачу std::string по значению.
писал, что благодоря языку C++ на сложной вычислительно задаче и слабой технике у нас не было проблем с производительностью. Вообще. Потому, что мы не теряли ее на элементарных операциях -- т.к. передача аргументов в функции или обращения к элементам массива.
... << RSDN@Home 1.1.4 stable rev. 510>>
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, GlebZ, Вы писали:
GZ>Отмазка. У буржуинов бывают разные системы обучения.
Знаешь, довелось поработать консультантом в филиале одной весьма известной тебе фирмы в штатах. В общем, ехал — боялся, приехал — смеялся. Не то, чтобы уровень у "тамошних" программистов низкий, ни в коем случае, таких там не держат... А вот в плане "узколобости" — это сплошь и рядом. Слишком узкая специализация и зацикленность дает себя знать. Шаг вправо-влево — и уже не знаем что делать. В очереди за советами стояли и индусы и арабы и "аборигены" — сами штатовцы. Вплоть до того, что даже флеш-дизайнеру накидывал алгоритмы затухающих колебаний и графического самобалансирования дерева, развернутого во все стороны и вписанного в овал... А требовался, в принципе, уровень примерно 8-го класса средней школы для подобных расчетов. Хотя, своими инструментами (графическими) этот дизайнер владеет как бог. А учился на программиста, кстати...
Вот ты какие задачи решал на зимней и летней практике первого курса, помнишь? У нас было дано окол 20 задач (могу и ошибаться в количестве, наверно — больше), все они — типа запрограммировать такой-то алгоритм решения дифуров или матрицы обратить (не путать с перестановкой элементов) и т.д. После 3-го курса на тех же практиках требовалось написать ассемблер (с ограниченной системой команд) и эмулятор CPU, на которому множество твоих команд исполнялось. Причем, требовалось писать "как положено", т.е. лексический/синтаксический анализ для ассемблера и табличный диспетчер для эмулятора. Групповая курсовая работа на том же 3-м курсе — мини ОС для машины, придуманой Кнутом. Эмулятор его CPU (на котором он свои алгоритмы приводил), загрузчик, файловая система, ядро, планировщик, подсистема ввода/вывода...
А наши коллеги "оттуда" в это время усиленно учат библиотеки и технологии... Самые продвинутые — учат команды Unix Shell... Вот она и разница.
GZ>Второе — в большинстве институтов(университетов) готовят программистов для определенной предметной области, и этой предметной областью захламляют мозги. А эта предметная область бывает слишком обособленна от других процессов разработки. И третье, некоторые вещи имеют большой недостаток. Они не входят в ГОСТ. Отношение к госту как к непререкаемой истине, в нашей системе обучения, не вдохновляет.
Ты легко можешь нарыть мапы стадий и артефактов RUP на наши 19-е и 34-е. Ради интереса, потрать на это время, ты обязательно удивишься тому, как современный RUP неплохо отображается на наши ГОСТ-ы хрен его знает каких годов.
ГОСТ — отличный пример систематизации стандартов. То, что ГОСТ отстает на сегодняшний день более чем на 20 лет имеет под собой скорее экономические причины (наша разруха), а не технические (слабоумие наших инженеров).
Однако, склонность к обобщеным решениям и правилам в наших ГОСТах по прежнему держит их на некоем уровне актуальности (все-таки 20 лет без обновления не позволяет их полностью назвать актуальными) даже в такой стремительно развивающейся области, как разработки IT (как хард так и софт).
GZ>Наши проблемы в том, что в институтах есть хорошие математики, но нет хороших разработчиков. Хорошие разработчики не работают в институтах.
Да, проблема в ВУЗ-ах в первую очередь с кадрами, но проблема чуть другая. Не платят нихрена. При мне в 93-95-е уходили в первую очередь сильные как преподаватели и как личности. Уходили строить свою новую жизнь в этой стране, которая их "кинула". Больно и обидно было на это смотреть. Я сам остался в ВУЗе в аспирантуре, но пробыл там... ровно месяц. После получения первой "ЗП" срочно побежал искать работу
И откуда ты взял про "нет хороших разработчиков"? Классический советский ВУЗ — это в первую очередь куча тем для разработок. "Тема" — это такой институтский термин, сейчас почти не используется. Мне довелось с 3-го по 5-й курс работать в лаборатории, делали весьма сложные проекты (хард+софт). Подозреваю, что ты учился в "постсоветское" время. Конкретно наша лаборатория развалилась в 95-м году. Как раз из-за ухода ведущих спецов.
И это дурацкое платное образование... Не зря его все собираются отменить на Украине, да денег нет. Качество образования падает. Более умный абитуриент, не прошедший на "бюджет" вытесняется платными "разнарядками". соотношение 1/3:2/3 — это доли "бюджетников" и "платников"... На 90% вторые 2/3 — баласт, которые все-равно не компенсируют расходы на свое обучение (около 10 тыс долларов обходится студент в течении 5-ти лет гос-ву, а платят за учебу эти "платники" гораздо меньше, т.е. пока налицо только вред)
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Должен был я ему замечание сделать или нет ?
PD>Я замечание сделал. Аргумент простой — если он привыкнет передавать объекты с размером больше sizeof(void*) по значению — будет это и дальше делать, причем там, где это может серьезно сказаться.
Например где?
Вот простейший пример:
#include <iostream>
#include <Windows.h>
#include <time.h>
#include <math.h>
//typedef POINT POINT_PARAM;typedef const POINT &POINT_PARAM;
void __declspec(noinline) normalize(POINT_PARAM vect, POINT* res)
{
double norm = sqrt(double(vect.x * vect.x + vect.y * vect.y)) / 100;
res->x = LONG(vect.x / norm);
res->y = LONG(vect.y / norm);
}
int main(void)
{
POINT vect = {30, 40};
POINT nv;
clock_t start = clock();
for (unsigned i = 0; i < 100000000; ++i)
normalize(vect, &nv);
clock_t time = clock() - start;
std::cout << time << std::endl;
return 0;
}
Функция normalize. Принимает POINT и возвращает его нормализованным.
Внимание, вопрос. Как это point будет эффективнее принимать? по ссылке или по значению?
Ответ (Pentium D 2.80, VC7.1 без оптимизации):
Время работы при передаче по ссылке: 10921
Время работы при передаче по значению: 10734 (на 2% меньше!)
Здравствуйте, VladD2, Вы писали:
V>>Так вроде можно было управлять буфером FILE в С. По умолчанию он там, вроде, 256 байт был.
VD>Я рассказал то что было. Если тебе интересно можешь надыбать где-нибудь QuickC 1.0 или МС С 5 и поглядеть подробности.
Я с 1990-го работал на Turbo C, там можно было менять размер буфера структуры FILE (ты же ее использовал?)
VD>Собственно сага была не о том. Очень жаль что у большинства читавших нехватило сил оторваться от деталей и понять посыл.
Посыл понятен, жаль что у некоторых отвечающих не хватило сил оторваться от деталей и понять ответный посыл.
Ответ в том, что иногда оптимизация достается весьма малой кровью. И как вывод: вовсе игнорировать возможность оптимизации не стоит (собственно, я настаиваю на таком подходе). Надо лишь соизмерять потраченные усилия и получаемый эффект.
Понятное дело, что чем больше осведомленность о тонкостях используемых технологий, тем больше можно сделать оптимизаций без какого-либо ущерба для продукта или потраченного времени.
Да, очень важно, с оптимизации никогда не надо начинать. За исключением случая, когда некие вещи закладываются как ТРЕБОВАНИЯ (например, минимизации трафика или использования памяти), и тогда сама архитектура продукта разрабатывается с учетом требований. Обычная "бытовая" оптимизация делается ПОСЛЕ полной реализации всех требований, и опять же, НИКОГДА не служит самоцелью (как пытаются выставить некоторые). Даже такой фанат этого дела как я занимается оптимизацией только тех мест, где программа проводит больше всего времени. Как вычисляются эти места — второй вопрос.
В общем, как обычно, истина где-то посередине.
----------
А конкретно по твоему случаю, могу так же подкинуть информации.
Первые версии кеша драйва работали с глюками и их не торопились ставить на все подряд. В нашей лаборатории этот драйвер однажды похерил всю информацию на "главной" XT, я потерял более месяца работы.
Жаль, что ты не указал точно год, правда, если речь о 386-х и у нас, то предполагаю где-то после 92-го. Если бы ты писал свою утилиту ранее, и позиционировал ее именно для XT (c 4.7 MGh CPU) и без кеша драйва, то все твои усилия уже не выглядели бы такими уж ненужными и бесполезными. Тем более, что описанный способ буферизации не выдерживает никакой критики и вполне справедливо создал хаос в исходниках. Ты тогда еще в школе учился что-ли? Ибо студент после 1-го курса профилирующей специальности должен был просто отвязать интерфейс ввода от конкретной его реализации.
Так что, конкретно этот посыл попрежнему ммм... спорен.
Здравствуйте, Cyberax, Вы писали:
E>>А CRect? C>Не тестировали. У нас в одном модуле просто была задача быстро обработать несколько миллионов размеров, вот и искали оптимальный вариант. С CRect уже скорее всего будет эффективнее передача по ссылке.
А я вот накатал тестик. Вот результаты под Visual C++ 7.1 (-GX, -O2):
), похоже, при локальных вычислениях компилятор аргументы может по регистрам рассовать и этим достичь преимущества. Но, все же, при передаче аргументов по ссылке много не проиграешь, это точно.
Код теста:
#include <iostream>
#include <string>
#include <ctime>
using namespace std;
const unsigned int iterations = 10000000;
struct my_pod_2int_t
{
int m_x;
int m_y;
};
struct my_pod_3int_t
{
int m_x;
int m_y;
int m_cx;
};
struct my_pod_4int_t
{
int m_x;
int m_y;
int m_cx;
int m_cy;
};
struct my_pod_5int_t
{
int m_x;
int m_y;
int m_cx;
int m_cy;
int m_area;
};
struct my_byte_pod_t
{
char m_x;
char m_y;
char m_cx;
char m_cy;
};
template< class R, class T0, class T1, class T2, class T3 >
void
meter(
const std::string & test_case_name,
const std::string & method_name,
R (*pfn)( T1, T2, T3 ),
const T0 & a,
const T0 & b,
const T0 & c )
{
std::cout << test_case_name << "::" << method_name << " " << std::flush;
std::clock_t start = std::clock();
for( unsigned int i = 0; i != iterations; ++i )
(*pfn)( a, b, c );
std::clock_t finish = std::clock();
std::cout << "duration: "
<< double( finish - start ) / CLOCKS_PER_SEC
<< std::endl;
}
template< class TestCase >
void
initiate_meter( const std::string & test_case_name )
{
typename TestCase::value_t a, b, c;
meter( test_case_name, "references_only",
&TestCase::references_only, a, b, c );
meter( test_case_name, "refereces_args_value_return",
&TestCase::refereces_args_value_return, a, b, c );
meter( test_case_name, "all_values",
&TestCase::all_values, a, b, c );
}
template< class T >
class test_case_t
{
public :
typedef T value_t;
static const value_t &
references_only(
const value_t & a,
const value_t & b,
const value_t & c )
{
return a;
}
static value_t
refereces_args_value_return(
const value_t & a,
const value_t & b,
const value_t & c )
{
return a;
}
static value_t
all_values(
value_t a,
value_t b,
value_t c )
{
return a;
}
};
#define INITIATE_METER( type ) \
initiate_meter< test_case_t< type > >( #type )
int main()
{
INITIATE_METER( my_pod_2int_t );
INITIATE_METER( my_pod_3int_t );
INITIATE_METER( my_pod_4int_t );
INITIATE_METER( my_pod_5int_t );
INITIATE_METER( my_byte_pod_t );
}
... << RSDN@Home 1.1.4 stable rev. 510>>
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Теперь vdimas начал антипаттерновскую агитацию.
Думаю, что Дмитрий (vdimas) совершенно не собирался делать антипаттерновскую агитацию. А хотел сказать, что паттерны -- это всего лишь одна из программиских финтифлюшек (такой же, как и оптимизация, кстати). К которой и относится нужно соответственно, без религиозно-фанатичного обожания.
PD>Но пасаран!
Но пасаран!
... << RSDN@Home 1.1.4 stable rev. 510>>
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, VladD2, Вы писали:
VD>Напомню, я только начинал программировать и это была моя 3-я программа в жизни (первые две — это сама резидентная программа и первая версия компилятора).
VladD2 wrote:
> Это ловля блох. Бестолку так рассуждать. Ты поймашь 1000 совершенно не > важных для производительности приложения мест с микро-тормозами, но > действительно слабые места не заметишь.
Я смог ускорить одно свое приложение на 25% после замены std::string на
flex_string с правильными политиками.
Потом я написал свой велосипедный класс строк (с поддержкой move
constructors) и ускорил все еще в два раза.
> Если бы использование std::string могло что-то дать по сравнению с > CString, то никто последним бы не пользовался бы.
CString исопльзуют потому, что он поддерживается в MFC/ATL.
Здравствуйте, vdimas, Вы писали:
V>Диктую большими буквами: ЕСЛИ ВАМ И ПРОЕКТУ ЭТО НИЧЕГО НЕ СТОИТ, ТО ВЫБИРАЙТЕ НАИБОЛЕЕ ЭФФЕКТИВНОЕ РЕШЕНИЕ ЗАДАЧ НА ЛЮБЫХ УРОВНЯХ.
V>Ключевая фраза: "ничего не стоит".
Бесплатный сыр бывает только в мышеловках.
V>Ну представь хоть на секунду, что в стремлении выпустить, например, новую Тойоту на рынок, с новыми, прямо-таки космическими внешними обводами, фирма Тойота пошла на следующие допущения: V>- Весит в 2 раза больше, однако, по-прежнему шустро ездит за счет более мощного мотора V>- Топлива она жрет в 2 раза больше V>)
Как уже надоели кривые аналогии. Причины раздувания современного ПО отнюдь не в космических формах, а совсем даже в функционале и надежности. Рынок автостроения здесь плохая аналогия, поскольку все что можно из текущей технологии уже выжали и производителям ничего не остается кроме как вылизывать существующие модели. Если кто то сможет сказать новое слово в плане надежности или функционала при условии приемлемых остальных основных характеристик, то он подомнет под себя львиную долю рынка. На рынке ПО такое пока возможно прежде всего благодаря растущим вычислительным мощностям (а совсем не кривотой самой отрасли, как предполагаешь ты). Остановится рост мощностей, начнут вылизывать существующий софт.
V>Такое может привидется только в кошмарном сне кокого-нибудь инженера Тойоты. В реальности, каждая следующая модель выходит со все лучшими характеристиками, ос более оптимальным весом, с большим КПД (люди, вы еще помните это слово) двигателя.
Тем не менее разница между теперешними моделями и моделями пускай 5-тилетней давности в этом плане ничтожна. Индустрия автопрома точно так же высасывает деньги из покупателей, только у них приемы другие — продать то же самое в новой, более модной обертке. С технической точки зрения мода на дизайн, заставляющая производителей чуть ли не каждый год менять модельную линейку является форменным идиотизмом. В IT выхлоп от прогресса все таки поощутимее (и, кстати, именно он дал возможность автопрому хоть как то улучшить функционал и надежность).
V>Но ведь это не удивительно, над новой моделью работаюбт сотни инженеров. А у нас, у программистов, примерно 5-15 человек делают проекты, по информационной сложности мало уступающие проекту той же Тойты.
Боюсь, не просто не уступающими, но и значительно превосходящими.
V>Я бы не стриг всех под одну гребенку. К счастью, в крайности бросаются не многие. А что касается текущего положения дел, то на само понятие "эффективности" молодое поколение просто забило. Влад, даже ты пишешь свои программы более менее эффективно (сужу по публикуемым кускам). Ты по другому не можешь, хоть и озвучиваешь другую точку зрения. (гы-гы, кстати). А у нового поколения — ни стыда ни совести по отношению к ресурсам аппаратуры или сети.
Я почему то вижу прямо обратное. Если человек пишетоткровенно тормозной код на ровном месте, то обычно у него без этого масса проблем. Такого чтобы человек превосходно проектировал и писал код без багов, но при этом не умел оптимизировать по производительности я еще ни разу не встречал. Так не воюете ли вы с ветряными мельницами?
V>Добавлю еще насчет грамотного дизайна. Опять все встает с ног на голову. Раньше люди решали путем анализа вполне конкретные программистские задачи. Потом обнаружили их похожесть. Потом дали имена паттернам и использовали так: спроектировал что-либо, максимально удовлетворяющее требованиям, а потом _обяснил_ разработку на языке паттернов. Т.е. язык паттернов — это всего лишь терминологическая база. А молодежь как сейчас что-то проектирует??? Вместо того, чтобы решать поставленную задачу, крутит эти паттерны как кубики Лего, путем полного перебора стараясь подобрать нечто условно отвечающее поставленной задаче. И выходят монстры, один другого страшнее. И _паттэрны_ вроде есть, и неграмотно при этом...
Из этого можно сделать ровно один вывод — серебряных пуль не быват. О вреде паттернов это не говорит никоим образом. Влад вон тоже в свое время активно был против них и считал их костылями для ламеров. Однако ж стоило попробовать и ...
Вобще, как это не странно, паттерны это не столько что то новое собственно в готовых проектных решениях, сколько очень удобный инструмент обучения и коммуникаций. К примеру, решение, описанное в терминах паттернов, выглядит заметно короче и понятнее, чем если без них, ибо стандартные паттерны это суть алфавит проектировщика.
... << RSDN@Home 1.2.0 alpha rev. 615 on Windows XP 5.1.2600.131072>>
size = 1, time = 2383, sum = 332666720.000000
size = 1, time = 2333, sum = 332666720.000000
size = 1, time = 2334, sum = 332666720.000000
size = 1024, time = 120, sum = 332666720.000000
size = 1024, time = 110, sum = 332666720.000000
size = 1024, time = 130, sum = 332666720.000000
Здравствуйте, VladD2, Вы писали:
VD>Логичнее? Не факт.
К сожалению в данном случае твое мнение учитываться не будет, поскольку ты сам являешсья субъектом оценки. Сами для себя мы всегда белые и пушистые. А вот для других...
И вообще, извини за критику, я в этом форуме по большей части читатель, но вот какое дело. Ты модератор, а это по идее должно накладывать на человека определенную ответственность. Не так ли? Я не в коей мере не пытаюсь мораль читать, просто когда в форуме один из самых больших спорщиков модератор — то даже читать тяжко бывает становится. И никто урезонить тебя иногда не может. Худо.
Pavel Dvorkin wrote:
> Я замечание сделал. Аргумент простой — если он привыкнет передавать > объекты с размером больше sizeof(void*) по значению — будет это и > дальше делать, причем там, где это может серьезно сказаться.
Кстати о птичках. Мы тестировали что эффективнее передавать — ссылку на
CSize (те же 8 байт) или сам CSize по значению. Оказалось, что разницы
нет. Точнее, на одних процессорах (Intel Pentium M) был быстрее
указатель, а на других (AMD не-помню-какой) было выгодно передавать по
значению.
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Да бога ради. Это просто означает, что создание копий запрещено. И не у тебя только. В MFC таких классов полно, начиная с CWnd. Потому как бессмысленно создавать копию. PD>Но если копию создавать разработчик класса не запрещает — он обязан обеспечить конструктор копирования (и операцию присваивания)
Так и в .NET таже фигня... если разработчик хочет чтобы класс копировался он должен реализовать IClonable.
Разница лиш в том что в С++ по умолчанию объекты копируемые, а в .NET не копируемые.
... << RSDN@Home 1.1.4 beta 6a rev. 436>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, eao197, Вы писали:
E>А вот по поводу блочного и посимвольного чтения данных из файла лет 5-6 назад мне статья попалась (кажется в "Открытых системах"). Там метрики приводились для какого-то Unix-а. Так вот меня поразило, что во многих случаях блочное чтение не имеет преимуществ над посимвольным чтением. Учитывая, что сейчас файловые системы очень умные, решение о том, читать ли данные посимвольно или поблоково, лучше принимать с учетом конкретной ОС и железа.
Это все надо проверять. Но я точно знаю, что в MS-DOS вызов int21 был очень дорогим сам по себе. Разница же заключается в том, что полагаясь на эффективность системных вызовов, ты обязан верить, что это быстро. Но при определенных обстоятельствах нас может поджидать жестский облом. Если же придерживаться предположения, что системные вызовы в общем и целом дорогие (хотя в каких-то редких частных случаях это может быть и не так), эта прослойка с собственной буферизацией в 90% случаев ускорит чтение в 10 раз, а в 10% случаев — может замедлить на 10%. Вот, собственно и вся разница. Конечно же, сейчас нет ни малейшего смысла городить свою буферизацию. Просто потому, что CRT хорошо отработана на всех платформах и мы знаем это. Но когда это было неочевидно, самодельная буферизация имела смысл.
McSeem
Я жертва цепи несчастных случайностей. Как и все мы.
Здравствуйте, sch, Вы писали:
sch>Вывод для 11-мегабайтового файла: size = 11250929, tm2 — tm1 = 31, ratio = 362933.193548 sch>Вывод для 1,5-гигабайтовго файла: size = 1469875238, tm2 — tm1 = 47812, ratio = 30742.810131
sch>Вывод: нефига выступать коли руки кривые.
Я конечно понимаю что у тебя руки такие прямые что уже не гнутся, и что копьютер у тебя очень шустрый, но твой тест у меня только в 1.63 раза быстрее чем fread(1)
Здравствуйте, eao197, Вы писали:
E>На самом деле это получилась интересная, увлекательная и поучительная история о том, как ошибка при проектировании программы повлияло на ее производительность и расширяемость. Имхо, если бы на момент написания своего компилятора ты имел ну чуть-чуть больший опыт, все, что тебе пришлось сделать -- это задействовать собственный вариант getch, который прятал бы от тебя работу с буфером прочитанных из файла данных.
Можно на это посмотреть и так. Но смысл моего рассказа был как раз в том, что я сознательно не пошел на это так как сделал умозрительное предположение о том, что работа с буфером напрямую будет куда эффетивнее чем чтение по байту. Я понимал что чтение из файла операция не быстрая. И понимал, что если читать большими кусками, то скорость увеличится, но я так же думал, что во многом скорость определяется оптимальностью алгоритма. А это была ошибка. По сравнению со временем затрачиваемым на чтение данных с диска сам алгоритм занимал ничтожно мало времени. Собственно о выделенном и говорилось в моем рассказе. Очень жаль, что большиство уперлось в микроуровень и не поняло основного посыла этого рассказа. Я видел только одно сообщение
в этом обсуждении из которого можно понять, что человек правильно понял мои слва.
Если бы я был умнее тогда, я не стал делать оптимизацию на базе предположения. Вместо этого я бы просто проверил бы его на простом тесте и на основании результата выбрал бы куда более простое решение. Именно этим ценен данный опыт, а вовсе не какими-то там открывшимися деталями работы с файлами которые давно уже не интересны так как нет ни той ОС, ни тех библиотек.
E>Жаль только, что твой рассказ был переполнен наскоками на Павла Дворкина, это очень сильно впечатление от всей истории подпортило.
Да, наверно я переборщил с его пинанием. Однако этот пример как раз и был призван продемонстрировать крайнуюю неверность его мировозрения.
E>А вот по поводу блочного и посимвольного чтения данных из файла лет 5-6 назад мне статья попалась (кажется в "Открытых системах"). Там метрики приводились для какого-то Unix-а. Так вот меня поразило, что во многих случаях блочное чтение не имеет преимуществ над посимвольным чтением. Учитывая, что сейчас файловые системы очень умные, решение о том, читать ли данные посимвольно или поблоково, лучше принимать с учетом конкретной ОС и железа.
Это все не имеет значения. Скорость чтения определяется реализацией библиотеки. Конечно же чтение данных без кэширования в рамках процесса таких ОС как Виндовс или Линукс не может быть таким же быстрым как доступ к локальному буферу. Но библиотека может сама эффективно кэшировать данные.
В общем, еще раз выражу свое сожаление о том, что битобайтное мировозрение берет верх. Почти никто из прочитавших не смог понять основного посыла.
... << RSDN@Home 1.2.0 alpha rev. 618>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
FR>А тут никто вроде и не предлагал умозрительно все решать.
А вот предлагали, не будем показывать пальцем...
Посмотрите соседние топики.
NC>>"2. Проектируя код задумываемся над тем в каких условиях он должен работать и с какими проблемами можем столкнутся. Исходя из этого выбираем приемлемые алгоритмы и средства (библиотеки, рантаймы, компиляторы и т.п.) и другие проектные и локальные решения. "
FR>Нет не Ok есть ситуации в которых если следовать по порядку Владовым рекомендациям просто придется выбросить то что уже сделал и написать все по новой.
Жестких правил не бывает, не в армии
Но пункт 2 вроде как удовлетворяет тому, о чем вы писали — есть жесткие требования работы на пределе возможностей:
"задумываемся над тем в каких условиях он должен работать ... выбираем приемлемые алгоритмы и средства (библиотеки, рантаймы, компиляторы и т.п.)"
Здравствуйте, IT, Вы писали:
IT>У меня есть только одно замечание к данному тезису. Ничто не может насобирать столько замечаний пользователей сколько сам разработчик в роли пользователя
Вот тут не согласен. Разработчик конечно должен быть первым пользователем. Но его взгляд притуплен авторсвом. Автор не может 100%-но адекватно оценивать плоды своего туруда. Он ведь априори согласен со всеми принятыми решениями. Плюс лень. Так что мнение пользователей очень важно.
Другое дело, что если программа не нравится и самому, то о пользователях говорить уже смысла нет.
... << RSDN@Home 1.2.0 alpha rev. 618>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Nickolay Ch, Вы писали:
NC>Тут вообще в основном собираются люди, чтобы поубивать время, насколько я понимаю(поправьте кто-нить, если ошибаюсь). Обычно на философствования времени то не остается.
Ну, почему же? Я из этого форума почерпнул не мало новго. Многое из этого использую в своей работе редактором. Так что для меня это очень даже полезный форум.
... << RSDN@Home 1.2.0 alpha rev. 618>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
IT>>У меня есть только одно замечание к данному тезису. Ничто не может насобирать столько замечаний пользователей сколько сам разработчик в роли пользователя
VD>Вот тут не согласен. Разработчик конечно должен быть первым пользователем. Но его взгляд притуплен авторсвом. Автор не может 100%-но адекватно оценивать плоды своего туруда. Он ведь априори согласен со всеми принятыми решениями. Плюс лень. Так что мнение пользователей очень важно.
Я говорю не о просто кнопки подавить перед тем как пользователю отсылать, а серьёзном и продолжительном использовании для своих собственных нужд. Это очень хорошо заметно на том же самом .NET FW. Там где MS использует фреймворк для собственных разработок (та же ComponentModel), там всё как надо. Те части которые писались "для пользователя" иногда без дополнительной обработки напильником просто невозможно использовать.
... << RSDN@Home 1.2.0 alpha rev. 0>>
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, FR, Вы писали:
FR>А ведь Дворкин прав не следует даже сейчас на PC читать побайтово с диска
А я с этим и не спорю. Смысл-то в том, что перед тем, как оптимизировать что-то, нужно хорошо понимать, что за этим стоит. А иначе это пустая трата времени, скрывающая за собой множество других (неявных) пустых трат.
People who are more than casually interested in computers should have at least some idea of what the underlying hardware is like. Otherwise the programs they write will be pretty weird (c) D.Knuth
Здравствуйте, GlebZ, Вы писали:
IT>>Это кто такое сказал? GZ>Я сказал. И даже показал почему. Ты будешь заниматься оптимизацией процессов которые пользователю не важны. А ему важны другие процессы которые как оказалось, к твоему удивлению, не удовлетворяют его. Я с таким сталкивался.
Я же говорю, мы с тобой о разном. Я буду заниматься оптимизацией процессов, которые нужны пользователю, потому что я сам пользователь. Не пытаюсь прикинуться, а именно сам пользователь и есть.
... << RSDN@Home 1.2.0 alpha rev. 0>>
Если нам не помогут, то мы тоже никого не пощадим.
IT,
> Я говорю не о просто кнопки подавить перед тем как пользователю отсылать, а серьёзном и продолжительном использовании для своих собственных нужд.
Согласен.
> Это очень хорошо заметно на том же самом .NET FW. Там где MS использует фреймворк для собственных разработок (та же ComponentModel), там всё как надо. Те части которые писались "для пользователя" иногда без дополнительной обработки напильником просто невозможно использовать.
В MS для описания этого явления слово dogfood любят использовать.
Здравствуйте, kliff, Вы писали:
K>Я в восторге. Потрясающей силы художественное произведение.
Не... Произведение ниже плинтуса. Своей цели оно недостигло. Обсуждение меня просто подавило. В нём просто нет того о чем пытался сказать я, за то в избытке того против чего оно было направлено.
Снимаю шляпу перед Pavl-ом Dvorkin-ым. При всем моем несогласии с его мировозрением, писать он умеет убедительнее. Даже те кто, как оказалось, скорее стоит на одних позициях со мной поддержали его зажигательные речи.
... << RSDN@Home 1.2.0 alpha rev. 618>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
VD>Еще раз повторю, я в те времена намеренно отказался от "буферизации" воода и выбрал работу с "блоками памями". Это бло, можно сказать, дизайнерское решение. Безграмотное? Одназначно! Основанное на умозрительных предположениях? Безспорно. Но все же основанием для него явилось не то, что я не допер до буферизации и т.п. Основанием была погоня за производительностью.
Влад, твои слова: "я в те времена намерено отказался от 'буферизации'" выглядят совершенно не убедительно, т.к. ты сам несколько раз подчеркивал, что опыта у тебя на тот момент практически не было.
Вот ты бесишься, что народ не понимает, что оптимизировать нужно только то, что нужно и только на основании точных оценок.
Но ты и сам пойми, что оптимизация, выполненная не профессионалом -- это страшная штука. Практически тоже самое, что бесполезная или бестолковая оптимизация.
... << RSDN@Home 1.1.4 stable rev. 510>>
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, Nickolay Ch, Вы писали:
NC>Мне ни в этой, ни в соседнем треде так и не дали четокго ответа на вопрос: "ради чего проводить битовыжимание, изобретать велосипеды, отказываться от удобных механизмов и библиотек". По крайней мере, внятного ответа не услышал
Вы тоже перегибаете палку с заявлениями о ненужности оптимизации, пока еще (и это пока продлится похоже неопределенно долго) полно задач в которых битовыжимание необходимо. А красивая архитектура и оптимизация не антиподы, очень часто это вещи совершенно независимые.
Здравствуйте, Кузнецов Денис Викторович, Вы писали:
КДВ>К сожалению в данном случае твое мнение учитываться не будет, поскольку ты сам являешсья субъектом оценки. Сами для себя мы всегда белые и пушистые. А вот для других...
+1
КДВ>И вообще, извини за критику, я в этом форуме по большей части читатель,
Видимо ты тоже себя оценивать адекватно не можешь.
КДВ>но вот какое дело. Ты модератор, а это по идее должно накладывать на человека определенную ответственность. Не так ли? Я не в коей мере не пытаюсь мораль читать, просто когда в форуме один из самых больших спорщиков модератор — то даже читать тяжко бывает становится. И никто урезонить тебя иногда не может. Худо.
Возможно, возможно... Но вот все же здесь спорить все же можно. А вот в С++ с этим совсем никак. Там плохое слово о С++ табу, офтоп и вообще с прлюрализмом там не зашибись.
... << RSDN@Home 1.2.0 alpha rev. 618>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, FR, Вы писали:
FR>>Вы тоже перегибаете палку с заявлениями о ненужности оптимизации, пока еще (и это пока продлится похоже неопределенно долго) полно задач в которых битовыжимание необходимо. А красивая архитектура и оптимизация не антиподы, очень часто это вещи совершенно независимые.
VD>Цитату, пожалуйста, где бы говорилось о том, что оптимизации вообще ненужны.
Так общий фон такой что оптимизация это только зло, она и архитектуру портит и ничего кроме потери времени ни дает. А реально все это сильно зависит от решаемой задачи. Хотя сам все прекрасно понимаешь. Просто не надо крайностей.
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, Кузнецов Денис Викторович, Вы писали:
КДВ>>И вообще, извини за критику, я в этом форуме по большей части читатель,
VD>Ага. Оно и видно: http://rsdn.ru/Forum/Topa.aspx?days=0&gid=27 VD>
VD>Видимо ты тоже себя оценивать адекватно не можешь.
Влад, помоему ты кого-то с кем-то путаешь
... << RSDN@Home 1.2.0 alpha rev. 0>>
Если нам не помогут, то мы тоже никого не пощадим.
VD>Очередное неверное предположение. Попробуй посчитать 1994 — 1974 = Х.
Угу, теперь более-менее понятны внешние факторы, надо было сразу сказать про 1994-й, мне подумалось что гораздо раньше, раз речь шла о XT.
VD>Где Х — это мой приблизительный возраст к этому моменту.
20? Это 3-й курс? Тоже многое встает на свои места. Т.е. первое образование, очевидно, было непрофильным? Тем более странно было приводить тот случай как пример. McSeem2 немного в грубой форме, но все же пояснил, в чем состояли причины неудач.
В общем, мало ли кто на какие грабли наступал в своих первых прогах, делать далекоидущие выводы из этого не стоило. Мне почему-то кажется что ты и не сделал для себя этих далекоидущих выводов тогда, а просто сейчас вспомнил свой случай и попытался "пристроить" по месту. Потому и вышел общий эффект поста кривоватым.
Здравствуйте, Glоbus, Вы писали:
G>Думается мне, что товарищ Дворкин таки прав насчет оптимизации и стремлении к ней как к недостижимому идеалу коммунизьма. Умение писать быстрые проги с минимальными требованиями по памяти — это в некотором смысле культура пргграмминга.
Это ты про ассемблер что-ли?
... << RSDN@Home 1.2.0 alpha rev. 0>>
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, vdimas, Вы писали:
V>>>Другой уровень проектирования является аргументом? Например, какой смысл применять фасадные паттерны в тех местах, относительно которых требования к функциональности еще не устаканились. Это называется ставить телегу впереди лошади.
AVK>>Как это доказывает то, что "знание паттернов ничуть не помогает в разработке архитектуры"?
V>Могу уточнить, если кто не понял из контекста. Я утверждал, что зазубрить список паттернов недостаточно для грамотного проектирования. Более того, наблюдал примеры "тупого" применения паттернов не к месту, что и озвучил. Так с чем именно ты не согласен?
Фразу я уже привел —
знание паттернов ничуть не помогает в разработке архитектуры
. Вышеприведенное с этой фразой никак не стыкуется.
Здравствуйте, IT, Вы писали:
IT>Здравствуйте, Glоbus, Вы писали:
G>>Думается мне, что товарищ Дворкин таки прав насчет оптимизации и стремлении к ней как к недостижимому идеалу коммунизьма. Умение писать быстрые проги с минимальными требованиями по памяти — это в некотором смысле культура пргграмминга.
IT>Это ты про ассемблер что-ли?
Это вообще ... за жисть... Слысл таков, что если программер как одно из основных правил возьмет себе постоянно думать о том, как бы сделать текущий кусок кода оптимальным и стремится к этому т осо временем у человека просто вырабоатется другой подход — он с первого раза будет реализовывать 90% тех оптимизационных фич, о которых обычно вспоминают потом. Самый банальный пример — передача в плюсах объектов в функцию по ссылке а не по значению — тот же например std::string. В подавляющем большенстве случаев параметры функций используются именно как read-only и такой подход уже приведет к небольшому, но ускорению и экономии по памяти. И таких маленьких тонкостей в тех же плюсах может быть бесконечное множество. Так вот нужно чтоб чел воспитал в себе вот это умение "видеть". Говоря философски , в самой природе человека должно быть заложенро стремление сделать лучше сильнее быстрее, тогда он будет сам учится, развиваться и в конце концов поднимать свой уровень, что позволит писать ему эффективный код.
Здравствуйте, eao197, Вы писали:
E>А что, кто-то точно знает, что такое "ОО-анализ"?
Вот лично я не знаю, что такое обычный ОО-анализ, хотя именно этот самый анализ и является сферой моих профессиональных интересов и обязанностей. Методик этого самого анализа море (а кое кто вобще без них обходится, причем успешно), но ни одной общепризнанной.
Здравствуйте, vdimas, Вы писали:
VD>>Очень часто ты вместо ответа на мои слова разговариваешь сам с собой. Например: VD>>
V>>>> Лично я поддержал сам факт обсуждения этой темы. Согласен, что Дворкин немного перегибает,
VD>>>Будем надеяться, что тройка поставленная им за твое сообщение в том числе включает и согласие с этим вот высказыванием.
VD>>Что означает моя оценка я уже обяснил. Поддержку и раскрытие самой темы. Оценки привлекают читателей, не правда ли?
VD>>Создается впечатлинеие, что ты сражашся с вымышленным противником.
V>Где-то я уже слышал это недавно...
V>Влад, если бы ты знал на какой уровень домысливания приходится настраиваться, читая твои посты... V>Я прекрасно знаю, что обсуждение очепяток оппонентов находится за правилами RSDN, но тут уже просто количество переходит в качество, в требование определенного настроя...
Здорово! То есть ты перечитал текст, понял что сморозил ерунду и вместо того чтобы сказать "извини, плохо прочел" решил перевести разговор на обсуждение моих опечаток? А не объяснишь ли ты чем в донном случае мои опечатки помешали тебе отличить смысл слов "им" и "тобой"?
V>Конкретно в приведенном примере, да, получается что я домыслил твое предложение неверно.
V>Тогда ответ на тот абзац мог бы быть примерно таким: V>"По-абзацное оценивание не предусмотрено, к сожалению..."
Причем тут пообзацное оценивание? Я выразил легкий сарказм по поводу того, что он поставил оценку за сообщение которое во многом противоречит его суждениям.
Так понятно?
ЗЫ
Вообще меня угнетает мысль о том, что необходимо разжевывать любую мысль, а такие вещи как сарказм и юмор вообще восринимаются не адекватно. Подозреваю, что конечно в этом виноват я.
... << RSDN@Home 1.2.0 alpha rev. 618>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Тому , чему надо . Ты не понял суть моего высказывания
>Аргумент простой — если он привыкнет передавать объекты с размером больше sizeof(void*) по значению — будет это и дальше делать, причем там, где это может серьезно сказаться.
Здесь не идет речь о POINT, с ним, вполне возможно, разницы нет. Я имел в виду, что и в других случаях они будут это делать, там где размеры могут доходить до десятков и сотен байтов + конструктор копирования. Если не привыкнут сразу думать о том, что они передают и во что это превращается в коде.
Здравствуйте, vdimas, Вы писали:
V>Не надо выдирать фразы из контекста и все будет прекрасно стыковаться.
Не было там никакого контекста.
V> Могу в энный раз уточнить/переформулировать, мне не лень: знание одних лишь только паттернов не достаточно для успешного проектирования
А что, кто то утверждал обратное? Видишь ли, меня покоробило другое, как весело ты перешагнут от "некоторые (пип) паттерны применяют не по делу" к "паттерны не только бесполезны, но еще и вредны к тому же".
AVK>>Т.е. что это такое ты не знаешь. Что и требовалось доказать.
V>А ты знаешь?
А вот я как раз не знаю. Потому и спросил.
V>На отсутствие единого формального процесса я указал еще 2 поста назад (могу, кстати, подкинуть мысль, почему дело обстоит именно так, и заметь, не только в ОО-анализе). Однако, общая схема одинакова — анализ предметной области, построение оптимальной статической и динамической модели.
Тогда поясни как мне интерпретировать твою фразу.
Т.е. я порицаю практику попыток применения паттернов взамен "обычного" ОО-анализа.
Я так и не понял взамен чего нельзя применять паттерны.
V>Мне казалось, что я выразился предельно ясно, а тебе, очевидно, поразвлекаться захотелось.
Знаешь, если ты по прежнему будешь пытаться перелатывать свои слова и искать проблемы во мне, то не стоит продолжать, мне на это свое время жалко.
V> Без достаточной проработки самой модели и всех ее уровней с функциональной т.з. и с т.з. всевозможных ограничений, бросаться в конкретику паттернов, ИМХО, рановато.
Модели чего, конкретного приложения? Гут. Тогда расскажи мне — коль скоро мы отказываемся от паттернов — в каких терминах мы эту модель будем описывать? Ввиде UML? Красивых пассов руками? Самопальных схемок? Еще как то?
V> Тем более, что сами паттерны GoF как раз относятся к статической части модели,
Что такое статическая часть модели и почему GoF применимы только к этой части?
V>Применение паттернов должно являться СЛЕДСТВИЕМ анализа (или, учитывая итеративность, можно уточнить так: следствием очередной итерации анализа),
Какого анализа? Этого самого "обычного ОО-анализа"? Тогда, пока я не услышу от тебя, что ты под ним понимаешь, смысл этой фразы мне будет непонятен.
V> а не обогощать модель лишней/ненужной функциональностью,
Какая связь между паттернами и лишней/ненужной функциональностью?
V>заведомо рубить требования ввиду ограничений самих паттернов или применяемых связок паттернов.
Очень интересно. Можно пример?
V> Можно много сказать об итеративности и возвратах в процессе анализа проектирования по мере уточнения и развития модели. Сами эти моменты крайне важны, т.к. очень часто решения раннего этапа проектирования могут вполне огранично подменяться на более поздних итерациях, зачастую упрощаться, "склеиваться", вычленяться похожие части и т.д.
Круто. Осталось понять какое к этому отношение имеют паттерны.
V>А я лично наблюдал недавно процесс разработки примерно в таком духе: "Ну, тут мы прилепим это, здесь то, а вот в этом месте нечто эдакое, я тут новый ультрасовременный паттерн недавно в и-нете нарыл, очень хочу попользовать прямо здесь и сейчас".
И виноват в этом конечно паттерн.
Я тут недавно багу во 2 фреймворке нашел — уроды так удачно написали парсер TDS, что при селекте из таблицы с блобом и 4+ точками в имени этот самый парсер валится. Следуя аналогичной логике можно это привести в качестве аргумента к заявлению о том, что все парсеры вредны.
V>И вообще, если охота более конкретно порассуждать о тонкостях ОО-проектирования, ты не стесняйся, высказывайся, только уж пожалуйста, немного более предметно, ok?
Не мужик, я пока ничего тут не проповедую. Это тебе нужно подтверждать свои слова про вредность паттернов нормальными аргументами, а не ссылками на гипотетических идиотов.
V> А то разговор с тобой какой-то односторонний получается. И что не вывод у тебя — так пальцем в небо
Где это у меня ты выводы нашел. Я пока что вопросы задаю. На которые ты лепишь отмазки ввиде ссылок на гугль.
Я вот подумал — чего это адепты .Net так нас убеждают, что передавать по сылке и по значению — это все равно. У меня две идеи, взаимоисключающие , правда, есть.
1. Они так и не поняли. что такое конструктор копирования и где он вызывается . В C#, Java и т.д. его же нет вообще. Там то, что называется передачей по ссылке и по значению — в любом случае есть передача ссылки на объект, поскольку к самим объектам доступа нет. Вот если бы там от них потребовали при входе в функцию немедленно делать deep copy любого входного объекта — они бы иначе запели
2. Они все поняли, но заявляют это с далеко идущими целями. Вдруг кто-то из начинающих C++ программистов с ними согласится и начнет везде по значению передавать ? Тогда они смогут доказать без всякого труда, то, что им упорно хочется доказать — что С# быстрее, чем C++
Если второе верно — не дождетесь ! Мы на страже и этот номер не пройдет
S>) S>Для примера более интересного поведения, рекомендую ознакомиться со структурой System.DateTime.
Упс. Да, здесь синтаксически насахарили хорошо. А вот тебе примеры того, что есть кое-что, что применимо к ссылочным объектам, и неприменимо к плоским значениям:
1. Деструкторы.
2. Выделение на куче.
3. Управление временем жизни с помощью ГЦ.
...
n. % уверен ты ещё много чего вспомнишь...
Лично мне это даёт основание не называть value-значения объектами. И фраза П. Дворкина в этом смысле верна. Ты можешь называть всё объектами, но тогда в определённые моменты времени ты вынужден вставляеть оговорки "для ссылочных объектов X, а вот для плоских объектов Y", и вышеуказанная фраза для тебя содержит противоречие.
Здравствуйте, vdimas, Вы писали:
V>Паттерны так же относятся к набору практик. И упомянутый оценочный критерий тоже скорее из разряда практик.
Я что то совсем перестал понимать твой русский язык. Как может оценочный критерий быть практикой?
V>А практики — они такие интересные по сути вещи, что их применение может зависеть от внешних условий. Другими словами, даже упомянутый оценочный критерий не всегда требуется для оценки решений. Как пример — разработка практически любой аппаратуры, содержащей выч. компоненты. За требованиями минитюаризации, минимизации ресурсов, или даже исполнения в виде одной гибридной схемы и пр., оценка связанности компонентов просто теряет свою значимость. Связанность заведомо 100%-я.
Здравствуйте, TK, Вы писали:
TK>Интересно, а какой смысл вести дискуссию цель которой доказать, что твой собеседник чего-то там не знает? Какая в этом польза для сообщества?
Хороший вопрос. Надо бы чтобы ты сам на него и ответил. Ведь достаточно посмотреть на статистику твоих сообщений на форуме, чтобы понять, что ты сюда заходишь именно с этой целью.
... << RSDN@Home 1.2.0 alpha rev. 618>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, AndrewVK, Вы писали:
V>>Не надо выдирать фразы из контекста и все будет прекрасно стыковаться.
AVK>Не было там никакого контекста.
-1 за игнорирование контекста
V>> Могу в энный раз уточнить/переформулировать, мне не лень: знание одних лишь только паттернов не достаточно для успешного проектирования
AVK>А что, кто то утверждал обратное? Видишь ли, меня покоробило другое, как весело ты перешагнут от "некоторые (пип) паттерны применяют не по делу" к "паттерны не только бесполезны, но еще и вредны к тому же".
Я даже плохо представляю, есть ли смысл отвечать подобным постам. Ссылку в студию на мой пост с выделенными словами. И конкретно то место, которое тебя покоробило, ok?
AVK>А вот я как раз не знаю. Потому и спросил.
Да, а вот мне кажется, что я знаю, что такое "анализ",и применительно к ПО в т.ч.
V>>На отсутствие единого формального процесса я указал еще 2 поста назад (могу, кстати, подкинуть мысль, почему дело обстоит именно так, и заметь, не только в ОО-анализе). Однако, общая схема одинакова — анализ предметной области, построение оптимальной статической и динамической модели.
AVK>Тогда поясни как мне интерпретировать твою фразу. AVK>
Т.е. я порицаю практику попыток применения паттернов взамен "обычного" ОО-анализа.
AVK>Я так и не понял взамен чего нельзя применять паттерны.
Взамен "обычного" процесса разработки (мне больше всего импонирует нисходящий, неплохо описан в RUP и наших 19.xx ГОСТ-ах). Процесс разработки — вещь итерактивная, в общем случае. Чем сложнее система, тем больше итераций, возвратов и уточнений, т.к. с каждой итерацией уточняются требования, модель разбивается на все большее количество взаимодействующих моделей нижнего уровня. Полученную общую модель необходимо трассировать на работоспособность и удовлетворение всех собранных на текущую итерацию требований.
Конкретно, что мне не нравилось в виденом не однажды цирке под названием, "проектирование с паттернами". Это в первую очередь отсутствие итерации и обогащения требованиями. Т.е. слепили систему из паттернов "в лоб". В принципе, ничего страшного для начального этапа. В процессе уточнения модели и выхода на нижне уровни вполне могли быть найдены все несоответствия. Ан нет, ничего этого не было, сразу приступили к реализации. Почему то был сделан следущий вывод: "раз у нас все тут состоит из паттернов, то оно заведомо хорошо спроектировано". В результате, недавно ребята из соседней фирмы приходили за советами по разруливанию. У них же я и интересовался, как они докатились до такой жизни.
V>>Мне казалось, что я выразился предельно ясно, а тебе, очевидно, поразвлекаться захотелось.
AVK>Знаешь, если ты по прежнему будешь пытаться перелатывать свои слова и искать проблемы во мне, то не стоит продолжать, мне на это свое время жалко.
Я тебе уже указал на выдирание из контекста. Не приписывай мне того, что я не говорил. И тем более не собираюсь обосновывать не свои слова. По своим отвечаю ниже.
V>> Без достаточной проработки самой модели и всех ее уровней с функциональной т.з. и с т.з. всевозможных ограничений, бросаться в конкретику паттернов, ИМХО, рановато.
AVK>Модели чего, конкретного приложения? Гут. Тогда расскажи мне — коль скоро мы отказываемся от паттернов - в каких терминах мы эту модель будем описывать? Ввиде UML? Красивых пассов руками? Самопальных схемок? Еще как то?
И как с тобой разговаривать? Я специально оставил свой абзац с прошлого поста. Тебе говорят о своевременности, ты же приписываешь мне выделенное.
-1
V>> Тем более, что сами паттерны GoF как раз относятся к статической части модели,
AVK>Что такое статическая часть модели
это сразу в гугль
AVK>и почему GoF применимы только к этой части?
Потому как даже условие каждой задачи в той книжке зачастую ставится вполне конкретно, а на эту конкретику надо выйти.
Да блин, возьмем тот же визитор. Как стоит исходная задача? Перебрать полиморфный список и для каждого вызвать "собственный" метод? Да фиг там. В реальной жизни задача стоит так — есть несколько сущностей, над ними нужно совершать однотипные семантически действия, но тем не менее, отличающиеся для каждой сущности. На эту потребность надо выйти на некоторой итерации. Если удастья выделить отдельную роль для исполнителя этих действий и ограничить СИСТЕМУ ТИПОВ известными на момент, грубо говоря, компиляции. Если в результате предыдущих итераций проектирования выясниться, что все упомянутые сущности известны системе на момент разработки (т.е. никаких там динамически подгружаемых плагинов в этой части) то уже только тут и будет стоять эта задача. К тому же, двойная диспечеризация в классическом виде — это трюк, применимый не во всех ОО-языках. Попробуй сделать тоже самое на JavaScript.
V>> а не обогощать модель лишней/ненужной функциональностью,
AVK>Какая связь между паттернами и лишней/ненужной функциональностью?
Там еще я про искуственно вводимые ограничения сказал. На примере того же визитора, мы не сможем расширять систему используемых сущностей в виде плагинов. Это уже ограничение. Иногда очень болезненное.
V>> Можно много сказать об итеративности и возвратах в процессе анализа проектирования по мере уточнения и развития модели. Сами эти моменты крайне важны, т.к. очень часто решения раннего этапа проектирования могут вполне огранично подменяться на более поздних итерациях, зачастую упрощаться, "склеиваться", вычленяться похожие части и т.д.
AVK>Круто. Осталось понять какое к этому отношение имеют паттерны.
Такое, что применение паттерна в общем случае происходит как решение частной задачи. Например у нас стоит требование: есть много разновидностей документов со своими бизнес-операциями, документы должны иметь собственные наборы состояний, документы должны транзакционно переходить из состояния в состояние по одному или же группами (в случае, если в одной бизнес-операции участвует несколько документов). Какой паттерн применить? Пока что неясно какой и речь об этом идти не может. Нужно выбрать модель представления и взаимодействия документов, т.е. выйти на определенный уровень детализации. Нужно выйти на условия конкретных задач, и в качестве готового решения можно будет брать подходящие условию задач паттерны либо проектировать свои.
V>>А я лично наблюдал недавно процесс разработки примерно в таком духе: "Ну, тут мы прилепим это, здесь то, а вот в этом месте нечто эдакое, я тут новый ультрасовременный паттерн недавно в и-нете нарыл, очень хочу попользовать прямо здесь и сейчас".
AVK>И виноват в этом конечно паттерн.
Виноваты в этом люди, которые считают, что сам факт применения паттернов чего-то гарантирует. Ты вообще, оппонента внимательно читаешь? Все это время я выступал против бездумного применения паттернов взамен процесса проектирования. Никто и не утверждает, что сами по себе паттерны — зло. Так что пока ты споришь сам с собой.
AVK>Я тут недавно багу во 2 фреймворке нашел — уроды так удачно написали парсер TDS, что при селекте из таблицы с блобом и 4+ точками в имени этот самый парсер валится. Следуя аналогичной логике можно это привести в качестве аргумента к заявлению о том, что все парсеры вредны.
опять -1
Ты тратишь зря свое и мое время. Все уже прекрасно поняли, с чем именно ты споришь, но при чем тут моя ветка?
V>>И вообще, если охота более конкретно порассуждать о тонкостях ОО-проектирования, ты не стесняйся, высказывайся, только уж пожалуйста, немного более предметно, ok?
AVK>Не мужик, я пока ничего тут не проповедую. Это тебе нужно подтверждать свои слова про вредность паттернов нормальными аргументами, а не ссылками на гипотетических идиотов.
-1
Короче, мужик, ты окончательно увлекся.
Речь шла, вообще-то, о реальных мммм... (не могу назвать идиотами, в принципе, не глупые ребята) не очень опытных дизайнерах, которые наизусть знают паттерны и еще до недавнего времени свято верили, что этого достаточно. Всвязи с тем, что я наблюдал подобное уже не первый раз, я сделал замечание о тенденции.
Паттернами активно пользуюсь сам (собрался скоро выложить настраиваемый SQL-генератор в исходники эрэсдээна, визитор-визитором, бридж-бриджем, фасад-фасадом и прочее-прочим погоняет), так что, никак не могу сказать, что "все паттерны вредны" (C) AVK
AVK>Где это у меня ты выводы нашел. Я пока что вопросы задаю. На которые ты лепишь отмазки ввиде ссылок на гугль.
каков вопрос, таков ответ
-----------
короче, все что мог и хотел, я уже ответил тебе и Владу. Охота дальше развлекаться — плиз без меня.
Маленькая такая поправочка. Паттерны это не только паттерны дизайна(GoF). Паттерны могут быть ох как разными, и паттерны дизайна, не совсем, точнее всего, совсем не подходят под использование в архитектуре. Для этого случая, существуют свои паттерны.
Здравствуйте, AndrewVK, Вы писали:
AVK>А если они только читают, то почему ты решил что они профессионалы?
Ох, боюсь, что именно они профессионалы, а не все мы здесь, грешные. Ну разве профессионалы будут обсуждать нелепые конструкции и доказывать , что они нелепые ?
Здравствуйте, GlebZ, Вы писали:
VD>>Еще раз задаю вопрос. Ты можещь как-то иначе интерпретировать эти слова? GZ>Нет.
Вот и у меня нет. При этом совесная мешура выстриваемая вокруг всего этого только раздражает. Или ты имешь мнение которое хрен оспоришь, или отказывашся от него. А юление и ужимки меня лично только раздражают.
... << RSDN@Home 1.2.0 alpha rev. 618>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
PD>>И поверь,оптимизировать чтение из файла путем замены двух сопутствующих операторов я тоже не призываю. а вот когда некие умники начинают из файла по одному байту читать — это уже другой разговор.
Супер рассказ. Я столкнулся с подобным в своем старом коде, когда пришла пора его оптимизировать. Самое обидное — это то, что "оптимизируя" его при написании я "наоптимизировал" совсем не то, а главное создал совершенно немодифицируемый код. Пришлось переписывать по-человечески, и, разумеется, те микрооптимизации оказались ненужными ибо макрооптимизация с лихвой перекрыла прошлый выигрышь от них.
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, GlebZ, Вы писали:
GZ>>Нет. Ты по моему несколько некорректно прочитал его сообщение. Он высказал мнение о практике применении паттернов а не об их общей полезности(в чем существует множество аспектов). Правда он сделал несколько сумбурно ограничившись только паттернами дизайна.
VD>Объясни мне, плиз, что можно не корректно понять в этой фразе: VD>
Именно про этих уродцев я и говорил. И подмечал, что знание паттернов ничуть не помогает в разработке архитектуры.
VD>
Вобщем, обсуждение данных конкреных слов давно уже потеряло конструктив.
Ладно, возьмем Аристотелевскую логику как самую простейшею. Как известно, она прекрасно подходит под теорию множеств, и легко доказывается ею.
Итак,
Ситуация — разработка архитектуры
Подмечал — значит свойство искомой ситуации не есть величина постоянная, и она входит во множество ситуаций разработка архитектуры.
Разработчики — вводим существительное для более качественного анализа. Учитываем, что разработчики не обязательно занимаются архитектурой.
Знание паттернов — это свойство разработчиков, но не обязательное.
Ну и вывод — ничуть не помогает — есть множество всех этих решений.
Итого, что у нас получается.
Из данного рисунка можно вывести, что при разработке архитектуры некоторым разработчикам знание паттернов может помогать, а может вредить.(ндас, вышел вообще к другим выводам )
Вобщем vdimas уже давал разьяснения по этому поводу, что мне показалось значительно интересней чем обсуждение данной фразы.
Здравствуйте, AndrewVK, Вы писали:
V>>Ну... я тоже далеко не с пеленок с ними столкнулся... Однако, ведь не спроста подавляющую их часть воспринял за "старых знакомых". Т.е. подход не менее важен.
AVK>Подход штука абстрактная и ни о чем не говорящая.
Здравствуйте, VladD2, Вы писали:
PD>>И поверь,оптимизировать чтение из файла путем замены двух сопутствующих операторов я тоже не призываю. а вот когда некие умники начинают из файла по одному байту читать — это уже другой разговор.
VD>От как раз на эту тему могу рассказать призабавнейшую историю из своего опыта.
На самом деле это получилась интересная, увлекательная и поучительная история о том, как ошибка при проектировании программы повлияло на ее производительность и расширяемость. Имхо, если бы на момент написания своего компилятора ты имел ну чуть-чуть больший опыт, все, что тебе пришлось сделать -- это задействовать собственный вариант getch, который прятал бы от тебя работу с буфером прочитанных из файла данных. Я лет десять назад написал свой первый лексический анализатор для одного транслятора (в качестве инструмента для синтаксического анализа применялся yacc) и тоже использовал алгоритм распознавания лексем на основе посимвольного чтения. Только у меня getch был свой, поэтому проблем со скоростью никаких не было.
Жаль только, что твой рассказ был переполнен наскоками на Павла Дворкина, это очень сильно впечатление от всей истории подпортило.
А вот по поводу блочного и посимвольного чтения данных из файла лет 5-6 назад мне статья попалась (кажется в "Открытых системах"). Там метрики приводились для какого-то Unix-а. Так вот меня поразило, что во многих случаях блочное чтение не имеет преимуществ над посимвольным чтением. Учитывая, что сейчас файловые системы очень умные, решение о том, читать ли данные посимвольно или поблоково, лучше принимать с учетом конкретной ОС и железа.
... << RSDN@Home 1.1.4 stable rev. 510>>
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, VladD2, Вы писали:
E>>Влад, твои слова: "я в те времена намерено отказался от 'буферизации'" выглядят совершенно не убедительно, т.к. ты сам несколько раз подчеркивал, что опыта у тебя на тот момент практически не было.
VD>Понимаш ли. Мне не в чем тебя убеждать. Я тебе рассказываю как дело было. Я может быть уже не помню технические детали, но суть вопроса мне очень хорошо врезалась в память.
Влад, да меня не нужно убеждать, на самом деле я не так далек от твоей точки зрения, как тебе кажется (см., например, МКЭ в моей судьбе :)
). Я о том, что твоя позиция выглядит неубедительно как раз из-за этого фактора.
E>>Вот ты бесишься, что народ не понимает, что оптимизировать нужно только то, что нужно и только на основании точных оценок.
VD>Я не бушусь. Я сожалею и грущу.
Ну и зря, время само все по местам расставит.
E>>Но ты и сам пойми, что оптимизация, выполненная не профессионалом -- это страшная штука. Практически тоже самое, что бесполезная или бестолковая оптимизация.
VD>Оптимизация может быть полезной, бесполезной и вредной. Кто ее делает значения не имеет. Я же делился опытом и выводами сделанными из этого опыта. То что у некоторых проффесионалов выводы из этого рассказа постоянно сбиваются на обсуждение технических подробностей все же не моя вина, а их беда.
Мне кажется, что проблема твоего поста была в том, что для благой цели были выбраны не удачные средства. В то же время у Павла Дворкина средство оказалось даже лучше (значимее), чем преследуемая им цель. Но, в отличии от тебя, я придаю важное значение "оформлению" идей автора того или иного поста. Это как борьба Microsoft Windows и IBM OS/2. Целью обоих было создание ОС следующего поколения для PC. У M$ был корявенький продукт (цель), но отличный маркетинг (средства). А у IBM -- с точностью до наоборот. Результат всем известен.
По-моему, вы оба затронули две важнейшие тенденции. Павел -- о том, что внимание к элементарной эффективности на уровне написания кода падает. Пример тому: Смотрел на Java код. ...много думал.
Ведь в каждом языке есть примитивные приемы для повышения/понижения производительности на элементарном уровне. Например, в C++ возврат сложных объектов или передача их в качестве аргументов по значению -- очень дорогая операция. Например, функция, которая получает по значению пяток std::string и возвращающая std::string может серьезно просадить производительность. Самый простой выход -- использовать std::string & или const std::string &. В подавляющем большинстве случаев это уже даст необходимый прирост производительности. Хотя даже такая немудреная оптимизация уже содержит несколько неприятных подводных камней, про которые нужно знать, например:
const std::string & do_something( const std::string & title, const std::string & chapter )
{ ... return title; }
const std::string & processing_result = do_something( "I Love This Game!", "Long, long time ago..." );
processing_result.length(); // Бамс!!!
Так вот смысл высказываний Павла я вижу в том, чтобы научить разработчиков пользоваться подобными элементарными приемами оптимизации и понимать, что за этим может стоять. Смею тебя уверить, что многие начинающие C++ программисты очень долго не могут привыкнуть к тому, чтобы передавать сложные объекты как параметры через ссылки.
Смысл же твоего высказывания я вижу в том, что в современных условиях совершенно нет необходимости выходить дальше элементарной оптимизации (примеры которой я только что привел) или, что еще хуже, пренебрегать безопасностью в погоне за эфимерным выигрышем. Если кто-то сейчас использует для форматирования сложного выражения sprintf вместо std::ostringstream, то это как раз проявление того эффекта, о котором ты, имхо, и говоришь. Ведь все начинается с малого. Сначала sprintf вместо std::ostringstream (просто потому, что sprintf кажется эффективнее) даже без подсчета количества обращений к sprintf -- их может оказаться настолько ничтожно мало, что выигрыш будет на два порядка меньше, чем статистическая погрешность измерений скорости работы программы. Дальше больше -- выбор кажущихся более эффективными алгоритмов априори, без реальной оценки ситуации. Ну и дальше еще больше -- выбор неправильных архитектурных решений или неверная расстановка приоритетов при планировании работ по проекту. А все начинается с казалось бы безобидного выбора в пользу sprintf.
Так что, имхо, вы оба правы, но каждый говорит о крайних проявлениях. А истина, она где-то посередине. Или вообще в другой стороне.
Извини, если я опять тебя не правильно понял.
... << RSDN@Home 1.1.4 stable rev. 510>>
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, eao197, Вы писали:
E>А вот по поводу блочного и посимвольного чтения данных из файла лет 5-6 назад мне статья попалась (кажется в "Открытых системах"). Там метрики приводились для какого-то Unix-а. Так вот меня поразило, что во многих случаях блочное чтение не имеет преимуществ над посимвольным чтением. Учитывая, что сейчас файловые системы очень умные, решение о том, читать ли данные посимвольно или поблоково, лучше принимать с учетом конкретной ОС и железа.
Как всегда, память меня подвела и речь шла не о том
Приношу извинения всем, кого ввел в заблуждение.
А вообще-то я имел ввиду, что getch из стандартной библиотеки не обязательно будет каждый раз обращаться к OS. Более вероятно (чем лучше библиотека), что getch берет данные из внутреннего буфера, а запрашивает OS только при его опустошении. Причем стандартная библиотека может знать об особенностях OS и ее файловой системы, поэтому подчитываться могут блоки оптимального размера (скажем, сразу класстер или сектор). А если мы сами начнем читать данные блоками и не угадаем с размером блока, то ручной буфферизированный ввод будет проигрывать getch.
... << RSDN@Home 1.1.4 stable rev. 510>>
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Физически прочитать один байт из сектора невозможно, нужно считать весь сектор. Если глупый ДОС (хотя он имел полное право) ничего не буфирезировал, то 512 раз счтитывать один и тот же сектор... ИМХО, отличный пример, что нужно знать не только низкоуровневые вещи в софте, но и железо.
People who are more than casually interested in computers should have at least some idea of what the underlying hardware is like. Otherwise the programs they write will be pretty weird (c) D.Knuth
А по мне существует только один паттерн который называется Low Coupling/High Cohesion. Все остальное есть эквилибристика ума одного или нескольких индивидуумов в условиях границ функциональный и нефункциональных требований по достижению наибольшей близости к данному паттерну.
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>и у AnotherClass ICloneable не реализован. Как его deep copy сделать ?
Никак. Может быть это самим классом не поддерживается не просто так. Как стандартные варианты обхода — через сериализацию, или вручную через интероп. В принципе можно сделать и через маршалинг.
PD>В С++ такое в принципе невозможно. Есть AnotherClass — должен быть у него конструктор копирования. Как он устроен — меня не интересует, а работать будет.
А если конструктора нет?
С уважением, Gleb.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Re[5]: Готовность системы к её последующим изменениям
Здравствуйте, AndrewVK, Вы писали:
AVK>>>А можно реальный пример на форумах? Сдается мне что вы боретесь с ветряными мельницами. GZ>>Такой пример найти легко. Просто нужно сделать поиск по слову Фаулер в Архитектуре. Фаулер башку многим сносит, а разум и стремление к простоте отключает. AVK>Ну вот и найди
Вот люди, совсем совесть потеряли. Ему хотелось, а я ищи. Ну да ладно, я не гордый. Лови Mapper
Из жизни могу случаев рассказать. И в том числе про себя. Сейчас наблюдаю один проект с проблемой излишней и ненужной функциональнотью(слава богу со стороны).
С уважением, Gleb.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Re[6]: Готовность системы к её последующим изменениям
Здравствуйте, GlebZ, Вы писали:
GZ>Здравствуйте, AndrewVK, Вы писали:
AVK>>>>А можно реальный пример на форумах? Сдается мне что вы боретесь с ветряными мельницами. GZ>>>Такой пример найти легко. Просто нужно сделать поиск по слову Фаулер в Архитектуре. Фаулер башку многим сносит, а разум и стремление к простоте отключает. AVK>>Ну вот и найди GZ>Вот люди, совсем совесть потеряли. Ему хотелось, а я ищи. Ну да ладно, я не гордый. Лови
Или вот такой вопрос очень впечатляет Какие преимущества SOA перед Domain model?
> В чем смысл всей этой сказки то?
Сдается мне, что весь смысл этой сказки заключается в том, что нужн было использовать FILE * и fopen(), fread(), fgetc(), а не
open(), read()...
Д>в том то и мораль истории. Если уж ты берешься за оптимизацию, то проверять нужно всё и всегда — твои предположения "это работает быстро" и "это работает медленно" могут оказаться очень далеки от действительности. Д>А пытаться делать "оптимизацию всего и вся", как предлагают некоторые товарищи — это бессмыслица, и результаты ее будут никудышными, как и показал "разбор полетов"
Так ведь и обратный посыл который тут активно пиарится, "не оптимизируй пока не припрет" тоже неверен. Часто когда припрет оказывается уже поздно.
"McSeem2" <12737@users.rsdn.ru> сообщил/сообщила в новостях следующее: news:1459073@news.rsdn.ru... > Вообще-то я удивлен такой большой разницей.
Ну это-то и не вызывает удивления, т.к. при чтении по одному байту функция fread() будет вызвана в 1024 раз больше чем при чтении по килобайту. А на вызов функции требуется определенное время -- затолкать параметры в стек, прочитать их, локальные переменные, и проч. и проч. Если есть задача читать по байту -- надо пользоваться getc(), который определен в RTL Visual C++ следующим образом:
P.S. И еще, у меня складывается ощущение, что большинству участников данного спора надо перечитать (или прочтитать) K&R. Узнаете очень много нового и интересного про настоящее программирование.
Здравствуйте, VladD2, Вы писали:
E>>На самом деле это получилась интересная, увлекательная и поучительная история о том, как ошибка при проектировании программы повлияло на ее производительность и расширяемость. Имхо, если бы на момент написания своего компилятора ты имел ну чуть-чуть больший опыт, все, что тебе пришлось сделать -- это задействовать собственный вариант getch, который прятал бы от тебя работу с буфером прочитанных из файла данных.
VD>Можно на это посмотреть и так. Но смысл моего рассказа был как раз в том, что я сознательно не пошел на это так как сделал умозрительное предположение о том, что работа с буфером напрямую будет куда эффетивнее чем чтение по байту. Я понимал что чтение из файла операция не быстрая. И понимал, что если читать большими кусками, то скорость увеличится, но я так же думал, что во многом скорость определяется оптимальностью алгоритма. А это была ошибка. По сравнению со временем затрачиваемым на чтение данных с диска сам алгоритм занимал ничтожно мало времени. Собственно о выделенном и говорилось в моем рассказе. Очень жаль, что большиство уперлось в микроуровень и не поняло основного посыла этого рассказа. Я видел только одно сообщение
в этом обсуждении из которого можно понять, что человек правильно понял мои слва.
Извини Влад, значит ты не сумел донести смысл своего повествования до большинства читателей. Поскольку я, как, думаю, многие другие, обратил внимание вот на что:
Когда я читал символы последовательно, проблем в распознавании этой последовательности предшествующей ссылке не было. Я читал один символ... Если это был некий Х, то читал следующий, и если это был У, то было ясно, что передо мной ссылка и нужно действовать.
Похожим образом же я поступил и в буферизированной программе. Но я уже проверял подстроку а не отдельные символы. Так ведь было эффективнее!
Имхо, твоя проблема была в том, что ты стал оптимизировать не то место в программе. Ты стал изменять основной алгоритм поиска ссылок. Хотя этого можно было не делать. Оптимизацию можно было произвести на другом абстрактном уровне -- уровне ввода/вывода. Вот это и стало причиной твоих граблей.
... << RSDN@Home 1.1.4 stable rev. 510>>
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, FR, Вы писали:
Skipped.
Отлично.
К сожалению остаются проблемы с формализацией понятий
Например:
"может повлиять" — каждый будет воспринимать это в меру своей испорченности, и считать по своему что может, что не может... примеров масса, особенно в соседних тредах.
"решение ухудшает дизайн" — у каждого свои понимания этого, для кого то вылизывание кода и изобретения собственноручно наструганных лисапедов и есть лучший дизайн.
К чему это я? Все возвращается на круги своя — все зависит от здравомыслия(тут вообще формализация бессильна ) ведущего разработчика — либо это прагматичный человек, либо фанатик.
Здравствуйте, gear nuke, Вы писали:
GN>Таки почитав, как народ начал сравнивать inline и не-inline варианты функций при чтении не то с диска, не то из кеша файловой системы ОС, пошёл да исправил — на +.
GN>Вот уж воистину precipitate optimization is the root of all evil.
А ведь Дворкин прав не следует даже сейчас на PC читать побайтово с диска
NC>>А вот предлагали, не будем показывать пальцем... NC>>Посмотрите соседние топики.
FR>да ладно
Да сто пудов
FR>Может и не так, но в тех ситуациях про которые говорю я первым пунктом должно стоять тестирование и прототипизация, а проектирование уже вторым и структура программы будет в первую очередь подчинятся не требованиям красоты и простоты модернизации, а требованиям эффективности работы. Просто могу предположить что вы с Владом просто не работали при таких требованиях и не выкидывали на половину готовый красивый, но тормозной проект.
Предлагаю не спорить, потому что в общем согласен с вами
Как переставить пункты — это уже к конкретной задаче, не надо что то жестко фиксировать, я все время пытаюсь сказать, что абсолютных истин не бывает, надо адаптироваться
Я дейсвтительно не работал над серъезными вещами при сверхжестких требованиях к производительности, всегда можно было решить проблему с помощью расширения аппаратной части, кстати даже интересно было б когда-нибудь поучаствовать в подобном проекте, но текущая работа требует как раз обратного(быстрое написание, надежная работа приложения, простота расширения и поддержки, а вовсе не оптимизаций), а для участия в свободных проектах нет времени, да и ленив я
ЗЫ Сверхзадача — написать код так(выработать методы написания такого кода), чтобы было и красиво в смысле дизайна и легко оптимизировался при необходимости. Но честно говоря, не уверен, что это решиться даже в среднедалеком будущем.
Так что оставим это идеалистам
Здравствуйте, GlebZ, Вы писали:
IT>>У меня есть только одно замечание к данному тезису. Ничто не может насобирать столько замечаний пользователей сколько сам разработчик в роли пользователя GZ>Ни в коем случае....
Забавно, но всё что ты написал, а я нещадно поскипал никак не соотносится с тем о чём говорю я
... << RSDN@Home 1.2.0 alpha rev. 0>>
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, eao197, Вы писали:
E>Мне кажется, что проблема твоего поста была в том, что для благой цели были выбраны не удачные средства.
С этого момента можно по подробнее.
E> Это как борьба Microsoft Windows и IBM OS/2. Целью обоих было создание ОС следующего поколения для PC. У M$ был корявенький продукт (цель), но отличный маркетинг (средства). А у IBM -- с точностью до наоборот. Результат всем известен.
Аналогия не то что бы не уместна, она просто неверна, ну, или хотя бы спорна. Опять втягиваемся в религиозные возйны, но все же скажу пару слов. IBM OS/2 — это доработка MS OS/2. Другими словами OS/2 разрабатывал МС. Так вот в МС поняли, что OS/2 не является продуктом который требует рынок. Другими совами OS/2 не оптимальна для пользователя. Тогда МС начала разработку NT. NT оказался продуктом бескомпромисным, в отличии от OS/2 и намного более перспективным, но на то время NT была еще более неприемлема для пользователей. Тогда МС создала проект Чикаго (будующую Вынь 95). Его суть была скрещивание Windows 3.11 и Windows NT. Зазача быал — впихнуть максимум возможностей NT в ОС имеющюю намного меньшие потребности в ресустах и намного большую совместимось с 16-битным миром. Главное что пропихнул МС в Чикагу — это Win32 ATI. Конечно существовал Win32S, но в нем было реализовано уж очень мало нужных вещей. Причем и те что были реализованы — эмулировались. Второе по важности было введение изолированных адресных пространств. Для императивных языков того поколения это было очень важное нововведение. Дале шли многопоточность и красивый UI.
Конечно последние версии ОС тоже реализовали многое из того что решали проекты NT и Чикаго, но:
1. В полном объеме все фишки появились слишком поздно.
2. Полуось была компромисом — не такая надежная как NT и не такая неприхотливая к ресурсам, и (что намного важнее) не такая совместимая с Windows 3.1 как Чикаго.
В купе с намного более дружественным инсталлятором и конфигурацией эти ОС таки выиграли технологичесую гонку. А маркетинг... Он не маловажен, но люди не приняли бы такую важную вещь как ОС только на одном обмане.
Соственно сказал я об этом потому что вижу здесь очень похожие ошибки в логических рассуждениях, что и в осбуждении проблем производительности. "Хочется" заменят анализ фактов и холоднокровное вынесение суждений.
E>По-моему, вы оба затронули две важнейшие тенденции. Павел -- о том, что внимание к элементарной эффективности на уровне написания кода падает.
Плохой пример. Вырван из контекста и опять таки без реального анализа того какие оптимизации что дали бы. Думаю, что большинство рассуждения о проблемах этого кода чистый воды безсоновательный треп.
Ну, и главное. Если этот код являетс проблемой, то его можно просто переписать более эффективно когда в том появится реальная необходимость. Т.е. это случай когда нужно выполнить этап оптимизации. Думаю, в программе откуда был вырван этот кусок кода есть множество других место написанных более не оптимально. Но эти места проблем не создают. Так что опять таки о чем разговор? Нашел проблему? Устрани ее. А разжевывать сопли бья себя пяткой в грудь и крича "куда катится индустрия" не надо. Индустрия намного более размунее таких вот крикунов. Она подчиняется законма рынка и самобалансируется.
E> Ведь в каждом языке есть примитивные приемы для повышения/понижения производительности на элементарном уровне. Например, в C++ возврат сложных объектов или передача их в качестве аргументов по значению -- очень дорогая операция. Например, функция, которая получает по значению пяток std::string и возвращающая std::string может серьезно просадить производительность. Самый простой выход -- использовать std::string & или const std::string &.
Извини, но это очередная бредятина про оптимизацию. В стандарте С++для std::string описывается только интерфейс. Реализация же может быть любая. Посему твоя оптимизация на некоторых библиотеках приведет к потере производительности (хотя и небольшой). Но главное она в очередной раз усложнит код.
Например, погляди как реализован CString в MFC. Сам объект содеражит только ссылку на динамически занимаемый блок памяти. Все остальное в этом блоке. Передача CString в качестве параметра и даже возврат его из функции — это самое верное решение как с точки зрения производительности, так и с точки зрения удобства использования.
E> В подавляющем большинстве случаев это уже даст необходимый прирост производительности.
Как раз в подавляющем большинстве случаев — это ничено не даст. Ну, кроме глупой самоуверенности тому кто это делает.
E>Так вот смысл высказываний Павла я вижу в том, чтобы научить разработчиков пользоваться подобными элементарными приемами оптимизации и понимать, что за этим может стоять. Смею тебя уверить, что многие начинающие C++ программисты очень долго не могут привыкнуть к тому, чтобы передавать сложные объекты как параметры через ссылки.
Разработчик должен набираться опыта. Когда опыт у него уже будет, он и без умных советов сможет понять что более приемлемо, а что нет. Знании эти должны быть систематизированы и получены из надежных источников, а не браться из умозрительных предположений.
E>Смысл же твоего высказывания я вижу в том, что в современных условиях совершенно нет необходимости выходить дальше элементарной оптимизации (примеры которой я только что привел) или, что еще хуже, пренебрегать безопасностью в погоне за эфимерным выигрышем. Если кто-то сейчас использует для форматирования сложного выражения sprintf вместо std::ostringstream, то это как раз проявление того эффекта, о котором ты, имхо, и говоришь.
Вообще-то я говорил о другом. Я говорил, о том, что надо знать что делашь, и не делать ничего просто так.
... << RSDN@Home 1.2.0 alpha rev. 618>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
VD>Снимаю шляпу перед Pavl-ом Dvorkin-ым. При всем моем несогласии с его мировозрением, писать он умеет убедительнее. Даже те кто, как оказалось, скорее стоит на одних позициях со мной поддержали его зажигательные речи.
Такие "зажигательные речи" произносит чуть ли не каждый первый преподаватель по программированию в ВУЗЕ. Есть, конечно, исключения, но таких единицы. Это вбивается в голову людям в течении всего обучения, естественно, многие поддержат такое мнение. А все от того, что образование просто не поспевает за темпами развития отрасли. Ну не век сейчас процессоров, "в которые можно войти".
ЗЫ Сорри за офтоп, можем отдельно обсудить проблемы преподавания программирования в российских вузах, вроде даже обсуждалось уже..
Здравствуйте, eao197, Вы писали:
E>Его просто не может не быть E>Это почти как законы физики.
Это очередное предположение с обощением. Которое не верно в общем случае.
VD>>Нет. Я говорю, о том, что такие оптимизации как повсеместная передеча сторк по ссылке вряд ли приведет к заметному ускорению работы приложения. Хотя если это сделать в узких местах, то несомненно.
E>Приведет обязательно. Доказано практикой.
Ссылки на статистику, плиз.
E>Куда же проще? Один обобщенный класс для замера производительности и три тестируемых функции.
Да уж. Больше некуда. Хотя main() вроде так ничего читается.
Кстати, зачем вообще понадобился обобщенный класс для замера производительности? Чем банальные вызовы функциий провинилис?
E>Не сложнее твоего примера: Re[25]: Об эффективности программ
VD>Дык вот тот же Dvorkin вроде как даже пытается новое изучить. Но вот получается чистешая онтипатия, так как притят сами приципы заложенные в основу платформы. Как может показаться интересным новое если оно отвергает такие принципы как реинтерпретация памити, возню с указателями, а в добавок еще и навязывает абстрации и ОО-стиль программирования?
Вообщето и GC, и ооп, и абстракции — далеко не новые идеи, а очень даже старые по меркам существования индустрии. Если подходить к делу с идейной точки зрения, а не с прагматической, имхо, ничего хорошего не будет ни от нового, ни от старого. Это как бы от мировоззрения чтоль зависит уже. Хотя есть конечно привычки к тому, что уже хорошо знаешь.
Мне ни в этой, ни в соседнем треде так и не дали четокго ответа на вопрос: "ради чего проводить битовыжимание, изобретать велосипеды, отказываться от удобных механизмов и библиотек". По крайней мере, внятного ответа не услышал.
Здравствуйте, eao197, Вы писали:
E>Ради того, чтобы программа работала в заданных условиях. Например, SIM Toolkit апплет должен умещаться в 16Kb SIM карточку. Правильная, полностью функциональная версия занимает 19Kb. Нужно как-то "похудеть" апплет на 3Kb.
E>Такой пример подойдет?
Нет. Ты опять обобщашь частный случай. Никто не спорит, что если в очень окраниченные ресурсы нужно вжать довольно функциональную программу, то прийдется экономить на всем. Но это уже является частью спецификации ПО. И это нормально. Хотя опять таки есть варианты. Ведь, например, можно сменить железку и как следствие выпустить продукт на рынок раньше.
... << RSDN@Home 1.2.0 alpha rev. 618>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
VD>Погляди на свой тест. На 10 000 000 итераций (по буквам — десять миллионов итераций!) на моей машине уходит в худшем случае 1.5 секунды, т.е. 1500 милесекунд. То есть стоимость одного вызова == 0.00015 милисекунды, или 0.15 микросекунды. Из них 0.03 микросекунды уходит на сам вызовов, и только 1.2 на передачу 3-х параметров и возврат еще одного значения.
В server-side приложениях, которые обрабатывают сотни тысяч (всего лишь) транзакций в сутки эта величина легко достигается только лишь одной подсистемой логирования.
VD>Вот исходя из этих данных и можно строить предполжения где и когда стоимость передачи параметров может оказать заметное влияние на производительность. Не думаю, что столь малые велечины могут оказать серьезное влиятие на производительность.
VD>Так что передавать строковый класс по константной ссылке явно полезно, но вероятность того, что это приведет к серьезному увеличению производительности всегоп риложения я бы оценил скепрически. Конечно если это, например, компилятор, или парсер ХМЛ-я, то безусловно он значительно ускорится. Но если это, например, десктоп прилоежине, то это скорее всего ничего не даст.
За десктом не скажу, давно уже не писал. А вот то, что не POD-объекты (да и большие POD-объекты так же) нужно передавать по ссылке -- об этом нужно учить C++ программистов с детства.
... << RSDN@Home 1.1.4 stable rev. 510>>
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, VladD2, Вы писали:
VD>Например, погляди как реализован CString в MFC. Сам объект содеражит только ссылку на динамически занимаемый блок памяти. Все остальное в этом блоке. Передача CString в качестве параметра и даже возврат его из функции — это самое верное решение как с точки зрения производительности, так и с точки зрения удобства использования.
Это только начиная с MFC 7.1, да строки стали быстрее (в однотредовой модели), там подсчет ссылок. В MFC 4.2 строки копировались по значению. И вот тут мы имеем очередную дилему: если программист передает строку по значению, значит ли это, что он не хочет допускать модификацию исходной строки? В общем, вопрос имутабельности строк в С++ до сих пор обстоит невнятно. Наверно как раз из-за возможности пользовать сигнатуры операторов const string& и просто string как семантически различные заявления о намерениях или как контракт/соглашения. MFC 7.1 эти соглашения бессовестно обходит, ИМХО, и вообще расставила потенциальные грабли своими счетчиками ссылок на строки.
VD>Как раз в подавляющем большинстве случаев — это ничено не даст. Ну, кроме глупой самоуверенности тому кто это делает.
А ты проведи тест
Возьми MFC CString, создай проект и попередавай по значению и по константной ссылке. То же самое с возвращаемым значением, сравни возвращение CString либо возвращение в out-параметр CString&.
Как раз к вопросу о самоуверенности.
E>>Так вот смысл высказываний Павла я вижу в том, чтобы научить разработчиков пользоваться подобными элементарными приемами оптимизации и понимать, что за этим может стоять. Смею тебя уверить, что многие начинающие C++ программисты очень долго не могут привыкнуть к тому, чтобы передавать сложные объекты как параметры через ссылки.
VD>Разработчик должен набираться опыта. Когда опыт у него уже будет, он и без умных советов сможет понять что более приемлемо, а что нет. Знании эти должны быть систематизированы и получены из надежных источников, а не браться из умозрительных предположений.
На самом деле уже существуют вполне себе корректно составленные правила хорошего тона по кодированию на разных языках. Прямо в MSDN можно найти советы по VB, VB.Net, C#, C++. И не надо самому набираться опыта, претендующий на роль программиста на выбранном языке должен их просто изучить и понять (если сам еще не дошел своим опытом).
FR>Так общий фон такой что оптимизация это только зло, она и архитектуру портит и ничего кроме потери времени ни дает. А реально все это сильно зависит от решаемой задачи. Хотя сам все прекрасно понимаешь. Просто не надо крайностей.
Пардон, но общи фон формирует каждый для себя, читая тред. Я только и писал, что "все это сильно зависит от решаемой задачи". Могу привести цитаты...
Здравствуйте, VladD2, Вы писали:
E>>В server-side приложениях, которые обрабатывают сотни тысяч (всего лишь) транзакций в сутки эта величина легко достигается только лишь одной подсистемой логирования.
VD>Сотри тысяч? Гы-гы. Делим 100 000 на 24 == 4166. Делим еще на 60 == 70. Делим еще на 60 получается по транзацкии в секунду. Вспоминмаем что дает один вызов — 0.15 микросекнуд. То есть чтобы заметно затормозить сервер нам потребуется вызвать таую функцию в цигле ни как не менее 100 000 раз. Думашь это реальный сценарий?
Думаю, что вполне реальный. Поскольку транзакции распределяются не равномерно. Существуют т.н. часы-пик, когда транзакции будут валиться сотнями в секунду. Кроме того, почему ты думаешь, что обработка одной транзакции -- это элементарная операция? Сама обработка может быть весьма не тривиальной задачей.
VD>А ведь сервер с сотнями тысяч транзаций — это скорее всего мрогопроцессорный сервер.
Это для Java и C# уже протребуется многопроцессорный сервер
А для C++ обычный, однопроцессорный, класса P4 2GHz прекрасно справляется. И даже в часы пик запас прочности солидный остается.
E>>За десктом не скажу, давно уже не писал. А вот то, что не POD-объекты (да и большие POD-объекты так же) нужно передавать по ссылке -- об этом нужно учить C++ программистов с детства.
VD>Большие само собой. Но есть же и POD-ы размером с указатель? Учитывая еще архитектуру процессора вряд ли разбросннаые по всему приложению обхекты дадут ускорение. Пара промахов в кэше и ты получишь такой кайф от своих укзателей...
Таких POD типов не так уж мало. Два поля типа int в C-шной структуре и все -- POD тип в два раза больше указателя получается. Даже если POD структура всего из нескольких char-ов, то ты, имхо, можешь потерять производительность на некоторых типах процессоров, для которых важно выравнивание при обращении к памяти. А если при вызове функции ты передаешь ссылку на локальный объект, созданный на стеке, то промахнуться мимо кэша будет гораздо сложнее, чем при передаче указателя на размещенный в хипе объект.
... << RSDN@Home 1.1.4 stable rev. 510>>
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, FR, Вы писали:
FR>Давай представим себе что некая фирма выпустила текстовый редактор, самый крутой на рынке по своим возможностям, но на современных машинах, отклик после нажатия на клавишу две секунды. В таких условиях каким требованием будет быстродействие?
Опыт IDEA показывает, что многих вполне устраивает отклик в две секунды
Вообще-то потребитель далеко не всегда понимает, чего хочет. И лозунг "спрос рождает предложение" так же не совсем верен. Потребителем очень умело манипулируют. Те же самые супер-пупер IDE, которые тормозят на ноутбуках с 512Mb памяти -- хорошие примеры. Потребителю просто дали понять, что появилось новое качество, которое сейчас важнее, чем быстродействие. Со временем, когда к фенечкам и рюшечкам IDE привыкнут, быстродействие вновь станет фактором конкурентной борьбы. Но и тогда для отвлечения (или привлечения) потребителя что-нибудь новое придумают.
... << RSDN@Home 1.1.4 stable rev. 510>>
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, FR, Вы писали:
E>>Опыт IDEA показывает, что многих вполне устраивает отклик в две секунды
FR>то есть слово test набирается 8 секунд?
Нет, но иногда окошечки для выбора списка методов через несколько секунд напряженного свопа появляются.
E>>Вообще-то потребитель далеко не всегда понимает, чего хочет. И лозунг "спрос рождает предложение" так же не совсем верен. Потребителем очень умело манипулируют. Те же самые супер-пупер IDE, которые тормозят на ноутбуках с 512Mb памяти -- хорошие примеры. Потребителю просто дали понять, что появилось новое качество, которое сейчас важнее, чем быстродействие. Со временем, когда к фенечкам и рюшечкам IDE привыкнут, быстродействие вновь станет фактором конкурентной борьбы. Но и тогда для отвлечения (или привлечения) потребителя что-нибудь новое придумают.
FR>В играх такое не прокатит, я могу представить человека терпящего тормозящий рабочий инструмент, но если вместо игры получится слайд-шоу, то ее просто сразу снесут.
Смотря какая игра. Если это пасьянс на раздевание виртуального противника, то могут и не снести
... << RSDN@Home 1.1.4 stable rev. 510>>
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, AndrewVK, Вы писали:
AVK>Безусловно. К примеру паттерн инкапсуляция это просто разновидность MVC (M — поля, V — публичный интерфейс, C — код методов).
Основная задача МВЦ отделение модели от представления. Тут же это мягко говоря не совсем так.
... << RSDN@Home 1.2.0 alpha rev. 618>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, FR, Вы писали:
FR>Для шибко умных, тут трудно различить нефункциональные это требования или нет, если игра идет с 10 fps инграть в нее невозможно.
Т.е. берем железо по быстрее и функциональное требование исчезает?
... << RSDN@Home 1.2.0 alpha rev. 618>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, FR, Вы писали:
FR>>Для шибко умных, тут трудно различить нефункциональные это требования или нет, если игра идет с 10 fps инграть в нее невозможно.
VD>Т.е. берем железо по быстрее и функциональное требование исчезает?
Во первых среднее время жизни игры на рынке (когда она приносит 90% дохода) несколько месяцев, и когда появится нужное оборудование, уже будет поздно.
Во вторых среднее время жизни игровых приставок пять лет, и все эти пять лет более мощного оборудования просто не будет.(Хотя для приставок игра не прошедшая требования по быстродействию просто не будет издана).
Здравствуйте, VladD2, Вы писали:
V>>На самом деле уже существуют вполне себе корректно составленные правила хорошего тона по кодированию на разных языках. Прямо в MSDN можно найти советы по VB, VB.Net, C#, C++. И не надо самому набираться опыта, претендующий на роль программиста на выбранном языке должен их просто изучить и понять (если сам еще не дошел своим опытом).
VD>Несоменно, но я не уверен что это надо воспринимать как оптимизацию.
А вот он и камень преткновения. Многие тут говорили о том, что даже эти банальные правила зачастую не соблюдаются при кодировании. Процесс переписывания подобных участков кода "потом", ИМХО, является оптимизацией. Но она из разряда "ее могло и не быть".
Мне, например, не хватает что-то типа оператора with из VB. Приходится ручками заводить локальные переменные. Если кому-то это делать лень, то в случае нетривиального кода свойств можно получить серьезные тормоза на ровном месте. И таких примеров предостаточно.
писал, что благодоря языку C++ на сложной вычислительно задаче и слабой технике у нас не было проблем с производительностью. Вообще. Потому, что мы не теряли ее на элементарных операциях -- т.к. передача аргументов в функции или обращения к элементам массива.
Именно. Проще говоря, у вас сформирована была определенная культура написания кода, при котрой он пишется наиболее эффективным образом. При данном дизайне, данной архитектуре. И если потом проблемы возникнут — это может быть из-за неэффективного алгоритма, неправильной архитектуры или, может быть, из-за недооценки требований к железу (не тянет эта машина такое). А не из-за того, что кто-то съел 30% времени на бессмысленный вызов конструктора копирования и деструктора или насоздавал с десяток временных матриц.
Здравствуйте, Andrei N.Sobchuck, Вы писали:
ANS>См. выше. Я просто не смог сходу подобрать более лучшего слова чем "функциональность". Читай "интегральная оценка". А проблема в том, что довольно часто можно видеть высказывание типа "я написал красиво, а потом занялся оптимизацией и программа стала уродцем".
Sinclair,
PD>> Там то, что называется передачей по ссылке и по значению — в любом случае есть передача ссылки на объект, поскольку к самим объектам доступа нет. S>Опять двойка. Читать про value-типы.
Очевидно, что речь шла о значениях ссылочных типов, они и были названы объектами, что вполне логично.
Значение value-типа можно назвать "объектом" лишь натянув понятие "объект" на них.
Здравствуйте, TK, Вы писали:
TK>Интересно, а какой смысл вести дискуссию цель которой доказать, что твой собеседник чего-то там не знает? Какая в этом польза для сообщества?
Польза очень простая — товарищь агитирует за крайне вредную для новичком идею — что паттерны вредны.
Здравствуйте, eao197, Вы писали:
E>Думаю, что Дмитрий (vdimas) совершенно не собирался делать антипаттерновскую агитацию. А хотел сказать, что паттерны -- это всего лишь одна из программиских финтифлюшек (такой же, как и оптимизация, кстати). К которой и относится нужно соответственно, без религиозно-фанатичного обожания.
Я бы это утверждение расширил. Без религиозно-фанатичного обожания надо относиться к оптимизации, паттернам, абстракциям, С++, C#, Java, .Net и т.д. и т.п. И вообще — не сотвори себе кумира
Боюсь только, что объяснять это некоторым — все равно, что агитировать римского папу вступить в общество атеистов
Здравствуйте, AndrewVK, Вы писали:
AVK>Здравствуйте, TK, Вы писали:
TK>>Интересно, а какой смысл вести дискуссию цель которой доказать, что твой собеседник чего-то там не знает? Какая в этом польза для сообщества?
AVK>Польза очень простая — товарищь агитирует за крайне вредную для новичком идею — что паттерны вредны.
Где именно?
Новички уже давно поняли, за что именно я агитирую.
Здравствуйте, eao197, Вы писали:
E>Здравствуйте, Дарней, Вы писали:
Д>>...Нет никакого общего понятия красоты, ибо понятие это субъективное и к тому же подверженное изменениям со временем...
E>
E>[/i]красота – это наивысшая степень целесообразности, степень гармонического соответствия и сочетания противоречивых элементов во всяком устройстве, во всякой вещи, всяком организме[/i]. А восприятие красоты /.../ закрепившееся в подсознательной памяти человека благодаря миллиардам поколений с их бессознательным опытом и тысячам поколений – с опытом осознаваемым
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>В С++ такое в принципе невозможно.
Да ну? PD>Есть AnotherClass — должен быть у него конструктор копирования. PD>Как он устроен — меня не интересует, а работать будет.
Не факт.
Например у меня в программах на С++ у большенства классов конструктор копирования и копирующие присваивание заблокированы тем или иным образом.
И пошол я на это абсолютно сознательно ибо логика этих классов не предусматривает копирования.
А всякие ADT, умные указатели и тп это разговор отдельный.
... << RSDN@Home 1.1.4 beta 6a rev. 436>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Честно говоря я, в этом замечании, и не возражал и никуда не призывал. В большинстве своем у ссылки и у передачи по значению(если это не элементарные типы) разные цели.
Здравствуйте, GlebZ, Вы писали:
GZ>Честно говоря я, в этом замечании, и не возражал и никуда не призывал. В большинстве своем у ссылки и у передачи по значению(если это не элементарные типы) разные цели.
Так ведь и я тебе не возражал.
Просто осветил еще один аспект этой темы.
... << RSDN@Home 1.1.4 stable rev. 510>>
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, GlebZ, Вы писали:
AVK>>Польза очень простая — товарищь агитирует за крайне вредную для новичком идею — что паттерны вредны. GZ>Опа. Тут появились новички?
Жалко, что за это фразу отдельную оценку-смайлик поставить нельзя. А лучше сразу три смайлика!
... << RSDN@Home 1.1.4 stable rev. 510>>
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, vdimas, Вы писали:
V>Здравствуйте, GlebZ, Вы писали:
V>я все боялся озвучить эту мысль... но я имею более резкое мнение насчет изучения паттернов новичками. Не с них надо учиться проектировать, не с них. Поимев некий опыт самостоятельного нахождения решений, те, кто уже не новички, совсем по другому впитают эти паттерны, так сказать с гораздо большей пользой. Толку от того, что вместо условий задач студентам давать сразу ответы. Надо именно приучать самостоятельно решать задачи.
Самое интересное, что упомянутые мной Low coupling/High Cohesion — являются как оценочными критериями(как справдливо заметил AndrewVK) так и фундаментальными паттернами. Вообще я бы начинал обучения проектированию в ООП, с изучения метрик сложности объектно-ориентированного дизайна коих до фига, типа Чидамбера и Кремера, Лоренца-Кидда, или Фернандо Абреу(MOOD). Может применять это и не станут, но это даст не только основу для оценки, но и понимание основ объектной технологии.
Здравствуйте, vdimas, Вы писали:
VD>>Это за увертывание от прямого ответа и попытку переиначить свои же слова.
V>Ненавижу это занятие — приводить отрывки недавних постов, с целью "разбора полетов", но вынуждаешь:
V>
VD>>Нет, дело как раз не очень понятное. Кроме знаний о тонкостях реализации нужно еще иметь знания по грамотному дизайну приложений и желание этот самый грамтоный дизайн культивировать.
V>Может я не правильно истолковал выделеное?
А может ты вообще сообщением ошибся? Ты вообще-то с АВК дискутировал.
В общем, разговор с тобой постоянно превращается в театр абсурда. Мне это надоело. Или отвечай на вопросы котоыре тебе задаются без подмены тем и подмены собственных суждени, или можно вообще не начинать обсуждения.
Итак. Попробую еще раз вернусться к обсуждению твоей фразы вызвавшей несогласие АВК (и мое): знание паттернов [b]ничуть не помогает в разработке архитектуры[/b]
Хочу получить кратки и прямой ответ. Признашь ли ты эти слова ошибочными, или подверждаешь их правоту.
... << RSDN@Home 1.2.0 alpha rev. 618>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, AndrewVK, Вы писали:
AVK>Здравствуйте, GlebZ, Вы писали: GZ>>Опа. Тут появились новички? AVK>Их тут полно. Просто писать они стесняются.
Наверно. Тут и есть и профессионалы которые только читают да только минусы ставят(не буду показывать пальцем)
[лишнее скипнуто] AVK>А разве я такое говорил?
Это я сказал. AVK>И такого я тоже не говорил.
Это я сказал. GZ>>Я вообще не понимаю, каким образом архитектора можно сделать архитектором по книгам AVK>И такого тоже.
Это я сказал. AVK>Не помогут.
И ты согласен. AVK>Так о чем собственно спор то?
Вот это-то и есть загадка на данном этапе современного общества.
GZ>>ЗЫ судя по всему, позиция вдимаса не отрицала паттерны как таковые и чем-то похожа на мою. AVK>Знаешь, лично я воспринял это иначе. Сначала он обозвал паттерны чуть ли не мировым злом, а потом пытался доказатьчто он совсем не то имел ввиду.
Нет. Ты по моему несколько некорректно прочитал его сообщение. Он высказал мнение о практике применении паттернов а не об их общей полезности(в чем существует множество аспектов). Правда он сделал несколько сумбурно ограничившись только паттернами дизайна.
Здравствуйте, eao197, Вы писали:
E>У кого-то, может быть у того же Ефремова, я читал опровержение как раз тех фактов, которые ты приводишь ниже.
я предпочитаю верить тому, что говорят историки. А не тому, что говорят некие писатели неизвестного качества.
E>-- это не прижилось, поэтому можно считать это всего лишь тупиковой мутацией. Правилом, всего лишь подтверждающем исключения.
а что прижилось то? сначала была одна "мутация", потом другая, потом третья — а где тот общий для всех идеал красоты, о котором шла речь? его просто нет и никогда не было
Честно говоря структура разности между хотелками и действительностью значительно глубже и не зависит от паттернов. На основании собственных умозаключений можно наворотить значительно хуже и больше.
С уважением, Gleb.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Re[4]: Готовность системы к её последующим изменениям
Здравствуйте, GlebZ, Вы писали:
GZ>Такой пример найти легко. Просто нужно сделать поиск по слову Фаулер в Архитектуре. Фаулер башку многим сносит, а разум и стремление к простоте отключает.
По-моему, Фаулер как раз очень разумный человек. А если у кого от него бошку сносит, то пусть и не употребляет.
... << RSDN@Home 1.2.0 alpha rev. 618>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Здравствуйте, eao197, Вы писали:
PD>Я вот подумал — чего это адепты .Net так нас убеждают, что передавать по сылке и по значению — это все равно.
Очередная победа добра над разумом. Где ты увидил, что какие-то "адепты" "вас" умеждают "что передавать по сылке и по значению — это все равно"? Зачем подменять чужие фразы и на этом делать далеко идущие выводы?
Тебе просто заметили, что передача небольших POD-типов, т.е. структур не имеющих сложных кострукторов и деструкторов по ссылке смысла не имеет. Более того, даже вредна, так как могут начаться проблемы третьего порядка (вроде промахов мимо кэша). Вот и все.
PD> У меня две идеи, взаимоисключающие , правда, есть.
PD>1. Они так и не поняли. что такое конструктор копирования и где он вызывается .
Ага. Тупые. С++ правда знают не хуже некоторых, но его религиозным духом не прониклись.
PD> В C#, Java и т.д. его же нет вообще.
Вот и задумайся на досуге почему это так. Я вот думал и пришел, к выводу, что этот отказ не случаен, т.е. — это осознанное архитектурное решение.
PD> Там то, что называется передачей по ссылке и по значению — в любом случае есть передача ссылки на объект, поскольку к самим объектам доступа нет.
Вообще-то на сегодны это не так. И передача по значению есть передача по значению. Но ты практически уловил одну из предпосылок архитекторов управляемых сред. Такое решение позволяет в будущем делать очень некислые оптимизации. Да и на сегодня оно позволяет, например, копировать содержимое массива аналогами memmove (что нельзя в общем случае делать с массивами С++-объектов). Другой предпосылкой было серьезное упращение семантики языков. Били и другие предпосылки, но это уже нужно отдельную статью писать.
PD> Вот если бы там от них потребовали при входе в функцию немедленно делать deep copy любого входного объекта — они бы иначе запели
Это может потребовать только прикладной алгоритм. И когда он того требует, то делается и глубокое копирование графа объектов. Например, в R# копирование AST-веток именно что глубокое. Иначе ветки разных AST начинают пересекаться, что недопустимо.
PD>2. Они все поняли, но заявляют это с далеко идущими целями. Вдруг кто-то из начинающих C++ программистов с ними согласится и начнет везде по значению передавать ? Тогда они смогут доказать без всякого труда, то, что им упорно хочется доказать — что С# быстрее, чем C++
Ага. Ну, прям заговор. А C# и так бысрее С++ если он в умелых руках, а С++ в руках начинающих или горе-оптимизаторов. Так что все ОК.
... << RSDN@Home 1.2.0 alpha rev. 618>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
VD>Однако же идея бросать новичков на произвол судбьбы и заставлять их проходить все на своем животе крайне порочна.
Далось тебе это пресловутое "проползание на животе". На профильных специальностях готовят вполне адекватно, однако паттерны если и читают, то ближе к последнему курсу ВУЗа, или же вообще не считают нужным их преподавать, справедливо считая, что подготовленный человек без труда осилит их самостоятельно.
VD>Так как таким путем зания будут получаться значительно медленее и не факт, что в конечном итоге они вообще появятся.
Каким путем? Путем самостоятельного несистематизированного изучения IT? Согласен, но тоже самое можно сказать о любой области.
VD>Это все равно как при обучении математики вместо чередования теории с практикой предлагать ученикам сразу решать сложные задачи. Конечно кто-то из них может их решит...
Нет, это как при обучении математике уже в течении 5-ти лет, под конец предложить самостоятельно доказать несколько теорем. Невелико требование
Здравствуйте, IT, Вы писали:
IT>Здравствуйте, GlebZ, Вы писали:
IT>Паттерн — это типовое решение, ничего более. Но в отличии процедур, они не могут быть закодированы один раз и сложены в библиотеки
Причем нет никаких четких и ясных критериев где их стоит применять, а где нет. То есть есть обобщения типа "а здесь ОБЫЧНО делают так и так". И все. Так что все зависит строго от квалификации применяющего.
Здравствуйте, AndrewVK, Вы писали:
AVK>Здравствуйте, Pavel Dvorkin, Вы писали:
AVK>Не смешно. Подобные подколки отнюдь не способствуют конструктивному стилю общения.
А еще на обиженных воду возят )))
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Re[6]: Готовность системы к её последующим изменениям
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Смотря где обсуждать. Если в "Архитектуре" или тематических форумах — это одно.
Так Философия тоже технический форум. Другое дело что кое кто срывается на личные разборки, но с этим я в меру сил и способностей стараюсь бороться.
PD> А если он не хочет здесь светиться, дабы не получить десятки ценнейших советов на предмет правильного чтения из файла по байтам или копирования объектов на входе — может, он и прав....
Видишь ли, неумение признать себя неправым один из признаков непрофессионализма. А если таковое умение есть, то ничего страшного в таких советах нет. Откровенную пургу нормалшьный человек профильтрует, а из остального получит крупицы ценной информации.
Здравствуйте, Кузнецов Денис Викторович, Вы писали:
КДВ>Причем нет никаких четких и ясных критериев где их стоит применять, а где нет. То есть есть обобщения типа "а здесь ОБЫЧНО делают так и так". И все. Так что все зависит строго от квалификации применяющего.
Вообще-то критерии и цели в описании есть. Проблема в интерпретации.
Здравствуйте, AndrewVK, Вы писали:
AVK>Когда я учился ничего (т.е. абсолютно ничего) не говорилось о проектировании приложений, за исключением навязшего на зубах восходящего/нисходящего подхода.
Не так уж мало. Т.е. преподавалась методология, стадии, этапы, артефакты, процедуры завершения/приемки стадий и т.д. Взять, на пример, процесс нисходящего специфирования входных и выходных данных подсистем (программных или аппаратных). Ничего не напоминает?
Достаточно общий термин "входные/выходные данные" подменить на частные "сигналы и протоколы взаимодействия" и получим ОО-анализ в действии
Да и бог с ним ОО-анализом, это тоже частный случай частных подсистем. Если я видел ошибки проектирования, то обычно причина их была в элементарной невнимательности или небрежности. Казалось бы — так все просто. Бери сценарии использования как ТЗ и уточняй постепенно требования на каждом уровне проектирования. Как говорится — не промахнешься, если внимателен. (да, кстати, еще же учат проектированию БД, нормализации и пр., тоже мозги на место неплохо вправляет и не только в плане структуры БД)
Единственно, где требуется "эквилибристика ума" в чистом виде, или даже состязание в хорошем вкусе, так это в ситуации, когда сценарии использования не даны и их надо проектировать самому. Однако, все набирающий по численности класс аналитиков считает, что проектировщики систем к этой процедуре не должны лежать никаким боком. Это только их хлеб и они, типа, умеют это лучше всего, учитывая их времяпрепровождение в общении с заказчиком в качестве доктора-психолога. Вероятно, они правы.
AVK>Сейчас ситуация еще хуже — в качестве архитектора современный студент величина отрицательная. Отрицательная, потому что перво-наперво приходится тратить массу усилий на избавление от дурацкий навыков, которым его научили в ВУЗе.
Если кто-то величина отрицательная в этом деле после 5-ти лет учебы, так может не стоит и время тратить на "выбивание"?
Да, мало выходит толковых ребят, менее 10% (по личному наблюдению около 10 толковых было из 100 человек потока, а девушки вообще непонятно зачем на IT учатся). Я же говорил уже многократно, что корень большинства проблем молодого поколения в том, что в IT идут люди, которым не стоит туда идти. Пруться как танки в IT из-за высоких ЗП все подряд, портят общую статистику. Переиначивают понятия, путают ср-ва с целями (как во всей этой ветке про паттерны).
Здравствуйте, VladD2, Вы писали:
IT>>R#, как я понимаю, остановился в своём развитии на пол пути. А что умеют XDE и DSL Tools?
VD>Что значит остановился? Просто времени не хватает. Вот добъем все дела и доведем R# до совершенства.
Ok, заменим остановился на приостановился
... << RSDN@Home 1.2.0 alpha rev. 0>>
Если нам не помогут, то мы тоже никого не пощадим.
E>На самом деле это получилась интересная, увлекательная и поучительная история о том, как ошибка при проектировании программы повлияло на ее производительность и расширяемость. Имхо, если бы на момент написания своего компилятора ты имел ну чуть-чуть больший опыт, все, что тебе пришлось сделать -- это задействовать собственный вариант getch, который прятал бы от тебя работу с буфером прочитанных из файла данных.
Естественно. Мне с подобной деятельность пришлось столкнуться во времена незабвенной СМ-4 и Фортрана. Там вообще никаких строк в смысле ASCIIZ не было, а ввод/вывод был либо Фортрановский (о нем умолчу , либо можно было с диска читать прямо-таки сектора. Фортрановский ввод не годился , поэтому я читал сектора, из них брал то что надо, а функция чтения при необходимости подчитывала новый сектор. В общем, все это старо как мир.
А кстати, как fread-то работает ? Там ведь ввод буферизованный (кстати, понимаю, почему, но уж не совсем понимаю, зачем сейчас — Windows и так все кеширует). Т.е. читается в буфер где-то в, условно говоря, <stdio.h>, а оттуда возвращают порции, и если надо, делают новый запрос для перегрузки буфера.
E>А вот по поводу блочного и посимвольного чтения данных из файла лет 5-6 назад мне статья попалась (кажется в "Открытых системах"). Там метрики приводились для какого-то Unix-а. Так вот меня поразило, что во многих случаях блочное чтение не имеет преимуществ над посимвольным чтением. Учитывая, что сейчас файловые системы очень умные, решение о том, читать ли данные посимвольно или поблоково, лучше принимать с учетом конкретной ОС и железа.
ИМХО файловые системы здесь ни при чем. Они все равно посимвольно читать не будут . Чтение идет кластера или нескольких кластеров. То, что называется посимвольным чтением (из файла, конечно) , т.е. fgetc и т.п., есть в действительности чтение из буфера , который в "<stdio.h>", а он перегружается, как уже сказано. И время уходит здесь не на чтение, а просто на обращения к функциям — либо один вызов fread (на 1000 байт), либо 1000 fgetc (на один байт). А ОС об этих наших потугах и не узнает скорее всего, если только при этом чтении 1000 байт не придется подчитать новый кластер.
Здравствуйте, eao197, Вы писали:
E>А вообще-то я имел ввиду, что getch из стандартной библиотеки не обязательно будет каждый раз обращаться к OS. Более вероятно (чем лучше библиотека), что getch берет данные из внутреннего буфера, а запрашивает OS только при его опустошении. Причем стандартная библиотека может знать об особенностях OS и ее файловой системы, поэтому подчитываться могут блоки оптимального размера (скажем, сразу класстер или сектор). А если мы сами начнем читать данные блоками и не угадаем с размером блока, то ручной буфферизированный ввод будет проигрывать getch.
К тому же это будет создавать дополнительный расход памяти.
Для более адекватной оценки надо бы убрать вызов feof(file), тем более, что конец файла можно отловить по count из fread. Но не думаю, что результат будет кардинально другим. Вообще-то я удивлен такой большой разницей. Хотя приколы случаются. Помню как у нас около 30% времени отъедала isspace() на винде. Оказалось, что оно аж ядро вызывает! Понятно, что кодировки, locale и все такое, но нам тогда не требовалось ничего, кроме банального 7-битного ASCII.
McSeem
Я жертва цепи несчастных случайностей. Как и все мы.
Здравствуйте, McSeem2, Вы писали:
MS>Для более адекватной оценки надо бы убрать вызов feof(file), тем более, что конец файла можно отловить по count из fread. Но не думаю, что результат будет кардинально другим. Вообще-то я удивлен такой большой разницей. Хотя приколы случаются. Помню как у нас около 30% времени отъедала isspace() на винде. Оказалось, что оно аж ядро вызывает! Понятно, что кодировки, locale и все такое, но нам тогда не требовалось ничего, кроме банального 7-битного ASCII.
Да бывает
А мораль такая если работаешь с большими объемами то проверять нужно обязательно, иначе можно нарватся на то что программа грузится минуты вместо секунд.
feof убирать пробовал реакции ноль.
Здравствуйте, FR, Вы писали:
FR>Так ведь и обратный посыл который тут активно пиарится, "не оптимизируй пока не припрет" тоже неверен. Часто когда припрет оказывается уже поздно.
тоже верно
но таких случаев все-таки меньше. К тому же, это все равно не отменяет правила "сначала проверь, потом оптимизируй"
Здравствуйте, eao197, Вы писали:
E>А вообще-то я имел ввиду, что getch из стандартной библиотеки не обязательно будет каждый раз обращаться к OS. Более вероятно (чем лучше библиотека), что getch берет данные из внутреннего буфера, а запрашивает OS только при его опустошении.
Да надо было просто посмотреть исходники CRT. Они не секрет
int __cdecl fgetc ( REG1 FILE *stream)
{
int retval;
_ASSERTE(stream != NULL);
_lock_str(stream);
retval = _getc_lk(stream);
_unlock_str(stream);
return(retval);
}
>Причем стандартная библиотека может знать об особенностях OS и ее файловой системы, поэтому подчитываться могут блоки оптимального размера (скажем, сразу класстер или сектор). А если мы сами начнем читать данные блоками и не угадаем с размером блока, то ручной буфферизированный ввод будет проигрывать getch.
Здравствуйте, FR, Вы писали:
FR>Простенький тест
FR>у меня на 7mb файле выдает такие результаты: FR>
FR>size = 1, time = 2383, sum = 332666720.000000
FR>size = 1, time = 2333, sum = 332666720.000000
FR>size = 1, time = 2334, sum = 332666720.000000
FR>size = 1024, time = 120, sum = 332666720.000000
FR>size = 1024, time = 110, sum = 332666720.000000
FR>size = 1024, time = 130, sum = 332666720.000000
FR>разница в почти 20 раз фигня?
Напомню, что fread(1) и fgetc -- это чуть разные понятия. Что и доказывается простой модификацией примера:
size = 128, time = 93, sum = 1096917.000000
size = 128, time = 93, sum = 1096917.000000
size = 128, time = 94, sum = 1096917.000000
size = 1024, time = 94, sum = 1096917.000000
size = 1024, time = 78, sum = 1096917.000000
size = 1024, time = 78, sum = 1096917.000000
size = 1, time = 219, sum = 1096917.000000
size = 1, time = 250, sum = 1096917.000000
size = 1, time = 219, sum = 1096917.000000
Разница осталась, но уже далеко не на порядок.
Хотя результаты сильно зависят от компилятора. Например, Borland C++ 5.6 и Digital Mars C++ 8.42n:
size = 128, time = 218, sum = 1096917.000000
size = 128, time = 250, sum = 1096917.000000
size = 128, time = 188, sum = 1096917.000000
size = 1024, time = 219, sum = 1096917.000000
size = 1024, time = 156, sum = 1096917.000000
size = 1024, time = 219, sum = 1096917.000000
size = 1, time = 2515, sum = 1096917.000000
size = 1, time = 2500, sum = 1096917.000000
size = 1, time = 2516, sum = 1096917.000000
И от операционки. Например GNU C++ 3.2.2 на Slackware 10.0:
size = 128, time = 150000, sum = 1096917.000000
size = 128, time = 150000, sum = 1096917.000000
size = 128, time = 160000, sum = 1096917.000000
size = 1024, time = 130000, sum = 1096917.000000
size = 1024, time = 130000, sum = 1096917.000000
size = 1024, time = 120000, sum = 1096917.000000
size = 1, time = 750000, sum = 1096917.000000
size = 1, time = 750000, sum = 1096917.000000
size = 1, time = 750000, sum = 1096917.000000
(значение time в 1000 раз больше, т.к. под Linux-ом CLOCK_PER_SEC так же больше).
... << RSDN@Home 1.1.4 stable rev. 510>>
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
PD>P.S. Честно говоря, знал, что эффект будет до своих опытов, но чтобы такой — не ожидал. Господа, не откажите в просьбе — проверьте код. Может, я ошибку какую-то сделал и не вижу ее ?
Точно, сделал. В суммировании. Черт меня угораздил его оставить. Вместо
for(j = 0; i < 1024; ++i) sum += buf[i];
должно быть, конечно
for(j = 0; j < 1024; ++i) sum += buf[j];
Ошибка, конечно, серьезная. Посыпаю голову пеплом . Но на результатах это не очень сказалось — просто цикл выполнился на 1024 раза меньше.
fread
nSize = 1, time = 6031, sum = 7093600000.000000
nSize = 1024, time = 797, sum = 7093600000.000000
ReadFile
nSize = 1, time = 231390, sum = 7093600000.000000
nSize = 1024, time = 750, sum = 7093600000.000000
Здравствуйте, FR, Вы писали:
FR>Здравствуйте, sch, Вы писали:
sch>>Вывод для 11-мегабайтового файла: size = 11250929, tm2 — tm1 = 31, ratio = 362933.193548 sch>>Вывод для 1,5-гигабайтовго файла: size = 1469875238, tm2 — tm1 = 47812, ratio = 30742.810131
sch>>Вывод: нефига выступать коли руки кривые.
FR>Я конечно понимаю что у тебя руки такие прямые что уже не гнутся, и что копьютер у тебя очень шустрый, но твой тест у меня только в 1.63 раза быстрее чем fread(1)
На некоторых платформах getc() определен не как макрос, а как функция.
Какой компилятор используешь, какая операционная система?
Здравствуйте, sch, Вы писали:
sch>Здравствуйте, FR, Вы писали:
FR>>Здравствуйте, sch, Вы писали:
sch>>>Вывод для 11-мегабайтового файла: size = 11250929, tm2 — tm1 = 31, ratio = 362933.193548 sch>>>Вывод для 1,5-гигабайтовго файла: size = 1469875238, tm2 — tm1 = 47812, ratio = 30742.810131
sch>>>Вывод: нефига выступать коли руки кривые.
FR>>Я конечно понимаю что у тебя руки такие прямые что уже не гнутся, и что копьютер у тебя очень шустрый, но твой тест у меня только в 1.63 раза быстрее чем fread(1)
sch>На некоторых платформах getc() определен не как макрос, а как функция. sch>Какой компилятор используешь, какая операционная система?
VC7.1 Win2k. Да и не такой и большой вклад дает вызов функции на фоне операций с диском. То что твой первый результат такой шустрый объясняется только тем что твой файл полностью засосало в кеш операционки, реально ты мерял скорость памяти, попробую удали и создай файл заново, скорость упадет на порядок. Да и пожалуйста не кричи больше.
Здравствуйте, FR, Вы писали:
FR>VC7.1 Win2k. Да и не такой и большой вклад дает вызов функции на фоне операций с диском. То что твой первый результат такой шустрый объясняется только тем что твой файл полностью засосало в кеш операционки, реально ты мерял скорость памяти, попробую удали и создай файл заново, скорость упадет на порядок.
У меня та же платформа.
Возможно оптимизатор заинлайнил fread(), так что надо посмотреть.
FR>Да и пожалуйста не кричи больше.
Прошу прощения если это выглядело так, я собственно и не кричал
Здравствуйте, sch, Вы писали:
sch>Здравствуйте, FR, Вы писали:
FR>>VC7.1 Win2k. Да и не такой и большой вклад дает вызов функции на фоне операций с диском. То что твой первый результат такой шустрый объясняется только тем что твой файл полностью засосало в кеш операционки, реально ты мерял скорость памяти, попробую удали и создай файл заново, скорость упадет на порядок. sch>У меня та же платформа. sch>Возможно оптимизатор заинлайнил fread(), так что надо посмотреть.
Здравствуйте, McSeem2, Вы писали:
MS>Это все надо проверять. Но я точно знаю, что в MS-DOS вызов int21 был очень дорогим сам по себе.
Прирывания это функция процессора. МС ДОС всего лишь использовал одно из программынй прирываний. Как я понимаю, смартдайв тупо подменял обработчик прирывания и кэшировал результат.
... << RSDN@Home 1.2.0 alpha rev. 618>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, eao197, Вы писали:
E>Извини Влад, значит ты не сумел донести смысл своего повествования до большинства читателей.
Видимо. Остается только понять виноват ли в этом я или те кто читал.
Первым моим решением было — сэмулировать getch() которым я читал данные в первом варианте компилятора. Но я тут же сделал очередное гениальное предположение в котором нисколько не сомневался. Звучало оно так — на возню с передачей символов и анализ по одному символу я убью кучу времени и моя программа станет не эффективна!
... << RSDN@Home 1.2.0 alpha rev. 618>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
позволило в несколько раз увеличить скорость обработки (там, кстати, речь идёт о 200Mb файлах)
People who are more than casually interested in computers should have at least some idea of what the underlying hardware is like. Otherwise the programs they write will be pretty weird (c) D.Knuth
Здравствуйте, McSeem2, Вы писали:
MS>Получается противоречие.
Да нет никаких противоречий. Нужно просто читать что написано, а не то что хочется.
MS> Сначала посимвольный анализ был для темя простым и логичным, а при "эмуляции getch()" он ни с того ни с сего вдруг стал плохим? Не вижу никакой логической связи. Зачем надо было отказываться от уже отработанного решения?
Простой и логичный не значит оптимальный/быстрый.
MS>Далее. Ты решил анализируешь строки а не символы. Пожалуйста, имеешь право. Но тогда возможность попадания ссылки "промеж буферов" — это первое, что приходит в голову при наличии элементарных инженерных навыков (повторюсь — самых элементарных).
Очередное неверное предположение. Попробуй посчитать 1994 — 1974 = Х. Где Х — это мой приблизительный возраст к этому моменту. Я уже не помню когда точно начал программировать, но скорее всего не более чем за год до этого момента. Видил бы ты как была написана та резидентная программа... Это была песня достойная отдельного описания. Довольно сложное приложение состояло практически из одной функции с громадным свитчом... на экране были полноценные окна, но таких сущьностей в программе не существовало. В общем — мрак. За-то через год я задумался над разработкой собственной оконной библиотеки для доста, что логичным образом привело меня к пониманию необходимости ООП. Сначала это была эмуляция на С, но когда я прочел книжку по С++ я понял, что изобретаю кривой велосипед. Хотя библиотеку я уже в каком-то виде реализовал. Код в ней был на порядки лучше того что был в первой программе. И только Виндовс, как нельзя кстати появившийся на моем горизонте, остановил меня от создания собственного аналога ТурбоВижон .
MS> Следующая мысль "инженерного типа" — это то, что выносить такую ситуацию в особый случай — это плохое решение, поскольку оно неоправданно усложняет логику (насколько я понял, ты на нем и остановился).
Ага. Верно мыслишь. Но для этого как раз нужно отказаться от любьви к оптимизациям до беспаметсва и обратить внимание на дизайн приложения. Собственно на то что я этим тогда пренебрег я и намекал. Как в прочем намекал и на то, что именно этим чревато мировозрение против которого я сейчас выступаю. Мне казалось, что тут собрались разумные люди и им не нужно до такой степени разжевывать столь очевидные вещи. Но видимо в консерватории что-то не так (с).
MS> Это как раз и есть та самая "оптимизация", против которой ты так яростно выступаешь — она действительно никудышная.
Ну, наконец то ты что-то заметил по существу! Теперь пойди перечитай текст еще раз и постарайся при этом отбросить предвзятость сосредоточившись на улавливании мест несущих в себе сарказм.
MS> Нормальным решением было бы сделать буфер из двух последовательных частей.
Нормальным решением было провести эксперемент, убедиться в том, что смысла в построчном сравнеии нет и просто остановиться на кэшировании вода/вывода. Так же логично было бы поиграть с размером буфера и понять, что выделять "буфер максимально возможного размера" тоже смысла не имеет.
MS> Как только наш указатель в буфере вылезает за пределы первой части, она становится ненужной. Следовательно, мы имеет право скопировать вторую часть на место первой, после чего дочитать следующую порцию из файла размером в полбуфера. Все!
Э нет. Не все. Когда жаждешь максимальной скорости плюс эффективности использования ресурсов и при этом слепо веришь в свои предположения, то решение выделить два буфера кажется ужасной растратой ресурсов. Ведь памяти то мало! Я ведь почти всю ее выделяю под этот самый буфер!!!
(доходит о чем я?)
MS> Мы имеем полное право пользоваться строковыми фунциями с гарантией неразрывности. Логика здесь тривиальна, она не тянет ни на какой "алгоритм". И накладные расходы на копирование — мизерны. Засада может случится только в случае, если размер токена превысит размер полу-буфера, но это можно объявить ограничением на использование. Такая цепочка рассуждений является нормальным инженерным, дизайнерским и оптимизационным решением. У тебя же присутствовал какой-то бессистемный поток сознания, из которого ты сделал глобальный по жизни вывод, что оптимизация — зло. Она и есть зло, если в башке бардак.
Бесситемный поток сознания скорее у тебя. Ты умудрился прочесть текст говорящий практически о том же что пишешь сейчас ты, но при этом ничего не понять.
Оптимизация — это решение. Она несомненно в большинстве случаев является злом в том смысле что усложняет программу. Но посыл сказанного был не в этом. Посыл был в том, что не нужно делать умных предположений и ориентируясь на свое чутье лепить оптимизации на всякий пожарный.
Как я уже сказал, банальный смартдрайв свел на нет все мои усилия. А ведь вторая версия компилятора была не просто напичкана "оптимизациями", она еще была написана для совершенно иных условий. Она была написана на Win32S, т.е. на Win32 API, что позяолило использовать куда больше ресуросов. ДОСовкая программка и мечтать о них не могла... Так что даже будь я тогда стольк же опытен как ты и Dvorkin сейчас. Я бы все равно попосту убил бы время на оптмизации.
MS>Я вообще удивляюсь, что тебе понадобилась "неделя потения" на то, чтобы понять проблему разрыва ссылок.
Неделя — это образно. Я сейчас уже не помню сколько ушло времени на поиск бага. Но учитывая что код конечно был безобразным, а знания стримились к нулю, думаю что неделя срок в полне реальный. К тому же в то время я не мог программировать 5 дней в неделю. Я учился и работал в другом месте по графигу сутки через трое.
MS>Теперь о smartdrv. Ты говоришь, что испытал некий шок. Но этот шок как раз и является следствием невежества. Получается, что твоя программа зависит от smartdrv и может работать только с ним. Но ведь тот же NortonGuide прекрасно работал и без всяких smartdrv.
Что касается Нортон Гайда, то его компилятор работал примерно с той же скоростью что и мой первый и точно так же ускорялся от смартдрайва. Резидентная же часть о обоих продуктов работала одинаково шустро, вот только НГ занимал раз в 5 больше памяти и имел кучу других недостатков.
Что же до слова "невежество" примененное тобой, то кроме как очередным оскорблением его ничем другим назвать нельзя. Ведь ежу понятно, что человек только осваевающий некую область знаний имеет в этой области знаний не много. И это совершенно нормально. Но "невежество" в русском языке имеет ярко негативный характер и подразумевает некультурность и полное отсуствие знаний. Если так можно оценивать знания начинающего, то как же оценивать призывы к бездумной оптимизации и примеры кода которые с точки зрения дизайна зачастую находятся на грани (а то и за гранью) фола?
MS> И чего тогда твоя "программа" стоила, если она требовала некую "ускоряющую приблуду"?
О. Это я тебе могу приблизительно сказать. В месте с контентом собранным/созданным моим отцом она стоила неплохих денег и продовалась в течении лет семи. Хотя на сегодня она закончила свое существование, а перед этом перешла сначала под Виндовс, а потом вообще в HTML-формат, но упоминания о ней до сих пор можно найти если погуглить: Компьютерная Энциклопедия Бухгалтерского Учета и Аудита, Дом АРМов бухгалтера.
MS> Типа все нормальные программы ускоряются от smartdrv в полтора-два раза на дисковых операциях, а твоя ускорялась в десять раз? Один этот факт говорит о том, что программа — отстой.
Ну, тебе виднее.
MS>Более того, из всего этого ты сделал совершенно ложный по жизни вывод, что оптимизация непременно приводит к ухудшению дизайна.
Таких выводов я не делал. Да и рассказ мой несет несколько другую смысловую нагрузку. Так что я делаю вивод о том, что ты сейчас занимашься демогогий и популизмом.
Я сделал вывод, что оптимизации очень часто ухудшают дизайн — это правда. Но это не главное. Главное — я сделал вывод, что бежать делать оптимизации и выбирать сложные и мудренные решения нужно только после того, как ты будешь на 100% уверен, что твоя оптимизация даст необходимый эффект инет других, более простых, путей добиться того же результата.
MS> Так вот, я скажу, что это — чушь. Нормальная оптимизация только помогает и способствует хорошему дизайну.
Вот это действительно чущь. Оптимизация по скорости есть оптимизация по скорости. Бывает конечто, что оптимальный с точки зрения производительности путь по совместительству является еще и наиболее простым и/или удобным (оптимальным по другим критериям). Но это как раз скорее исключение. Да и не рассматривает никто, по крайней мере здравые люди, выбор таких решений как оптимизацию. При таких совпадениях — это просто разумный выбор. Например, возьмем близкую тебе отрисовку. Создавая некое представление отображающее некий документ намного проще просто перерисовывать все представление, а не вычислять что изменилось и пытаться перерисовать только эту часть. Во многих случаях такое решение более чем прокатывает. Но как не крути, если ты хочешь чтобы сложная отрисовка одинаково быстро работала и на старом железе тебе прийдется заниматься реализацией частичной отрисовки. Это уже оптимизация. Ее результатом неизбежно станет серьезное увеличение кода и увеличение вероятности появления глюков. Например, Ворд оптимизирован в этом плане очень сильно. Но именно это приводит к тому, что иногда Ворд глючит при отрисовке.
MS> Но то, что лично ты считаешь оптимизацией, на самом деле ей не является. Это — не оптимизация. Для этого есть даже специальный термин — spaghetti-code.
Хм. Если код приводит к ускорению работы программы, то совершенно все равно макаронный ли он или очень крассивый. Он все равно будет являться оптимизацией. И макаронный код зачастую является следствием оптимизации. Я не раз видел как орлы отказывались от декомпозиции на фукнции или классы только потому-что они боялись что это приведет к замедлению. Причем иногда они даже были правы. Точно так же считал и я тогда. Причем тогда на это будо куда больше оснований, так как ни о каком инлайнинге и речи идти не могло. Вот только в отличии от многих других я извлек урок из своих ошибок и на сегодня скорее пожертувю небольшой потерей производительности нежели буду заниматься ручным инлайнингом методов или отказываться от виртуальных вызовов и т.п.
... << RSDN@Home 1.2.0 alpha rev. 618>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, vdimas, Вы писали:
V>Я с 1990-го работал на Turbo C, там можно было менять размер буфера структуры FILE (ты же ее использовал?)
Я уже не помню что я использовал. Название getch и то взято на абум как одно из близких. К делу это отношения не имеет. Ты просто вообще ничего не понял из написанного. Попробуй перечитать текст не обращая внимания на технические детали.
VD>>Собственно сага была не о том. Очень жаль что у большинства читавших нехватило сил оторваться от деталей и понять посыл.
V>Посыл понятен, жаль что у некоторых отвечающих не хватило сил оторваться от деталей и понять ответный посыл.
Посыл явно непонятен, раз ты продолжаешь рассуждать о каких-то там структурах и версиях компиляторов.
V>Ответ в том, что иногда оптимизация достается весьма малой кровью. И как вывод: вовсе игнорировать возможность оптимизации не стоит (собственно, я настаиваю на таком подходе). Надо лишь соизмерять потраченные усилия и получаемый эффект.
Дажа малая кровь в сумме может привести к смерти от обезкровлевания. Но тут важнее не это. Важнее то, что миросозерцание пропагандируемое тов. Dvorkin-ым (против этого миросозерцания и был направлен этот рассказ) приводит к тому, что люди начинают пытаться написать максимально оптимальный (с точки зрения производительности) код и вместе с водой выплескивают ребенка. Именно это я вижу в его примерах и словах. Там явным образом прослеживается натуральная борьба с абстракциями. Ведь за них нужно латаить. Заметь у него в коде ни разу не появился ни один строковый класс. В коде сплошные сишные строки размещаемые исключительно в стеке. А ведь по его же словам приводимый им код написан на С++. Ручная работа с буйером из моего рассказа — это как раз результат такого подхода. Мне казалось, что это очевидно. А оказывается подавляющему большенству это нужно разжевывать и запихивать в рот. Мне это противно. Это как смех за кадром или отсуствие реакции на шутку если за ней не стоит смайлик.
V>Понятное дело, что чем больше осведомленность о тонкостях используемых технологий, тем больше можно сделать оптимизаций без какого-либо ущерба для продукта или потраченного времени.
Нет, дело как раз не очень понятное. Кроме знаний о тонкостях реализации нужно еще иметь знания по грамотному дизайну приложений и желание этот самый грамтоный дизайн культивировать.
V>Да, очень важно, с оптимизации никогда не надо начинать. За исключением случая, когда некие вещи закладываются как ТРЕБОВАНИЯ (например, минимизации трафика или использования памяти), и тогда сама архитектура продукта разрабатывается с учетом требований.
Вот ты это понимашь, хотя умудрился не понять о чем я говорю. А некоторые не только не понимают, но и призывают к совершенно обртаному. Причем получают очень радушную поддержку своих мыслей. Собственно от этого и становится страшно, и именно это подталкивает на борьбу с подобными залихватскими добрыми идеями.
V>Обычная "бытовая" оптимизация делается ПОСЛЕ полной реализации всех требований, и опять же, НИКОГДА не служит самоцелью (как пытаются выставить некоторые). Даже такой фанат этого дела как я занимается оптимизацией только тех мест, где программа проводит больше всего времени. Как вычисляются эти места — второй вопрос.
V>В общем, как обычно, истина где-то посередине.
V>---------- V>А конкретно по твоему случаю, могу так же подкинуть информации.
V>Первые версии кеша драйва работали с глюками и их не торопились ставить на все подряд. В нашей лаборатории этот драйвер однажды похерил всю информацию на "главной" XT, я потерял более месяца работы.
V>Жаль, что ты не указал точно год, правда, если речь о 386-х и у нас, то предполагаю где-то после 92-го. Если бы ты писал свою утилиту ранее, и позиционировал ее именно для XT (c 4.7 MGh CPU) и без кеша драйва, то все твои усилия уже не выглядели бы такими уж ненужными и бесполезными. Тем более, что описанный способ буферизации не выдерживает никакой критики и вполне справедливо создал хаос в исходниках. Ты тогда еще в школе учился что-ли? Ибо студент после 1-го курса профилирующей специальности должен был просто отвязать интерфейс ввода от конкретной его реализации.
Я бы поверил тебе, что ты так всегда поступашь, если бы не видел твоей "тройки" вот на этом призыве
. Возможно ты и его не понял доконца, но тогда вопрос можно ставить об адекватности восприятия тобой и вещей вроде объема крови жертвуемой на оптимизации и необходимостью этих оптимизаций. (ни прими это за оскорбление, плиз)
V>Так что, конкретно этот посыл попрежнему ммм... спорен.
Ну, любая идея требует критического взгляда. Но хотелось бы чтобы этот взгляд был действительно критическим, а не основанным на непонимании.
... << RSDN@Home 1.2.0 alpha rev. 618>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Таки почитав, как народ начал сравнивать inline и не-inline варианты функций при чтении не то с диска, не то из кеша файловой системы ОС, пошёл да исправил — на +.
Вот уж воистину precipitate optimization is the root of all evil.
People who are more than casually interested in computers should have at least some idea of what the underlying hardware is like. Otherwise the programs they write will be pretty weird (c) D.Knuth
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, FR, Вы писали:
FR>>Так ведь и обратный посыл который тут активно пиарится, "не оптимизируй пока не припрет" тоже неверен. Часто когда припрет оказывается уже поздно.
VD>Все не совсем так. Лично я выступаю за очень простой набор правил:
Все хорошо и красиво и у меня возражений по существу нет. Но ты упустил главное, эти правила хороши при разработке определенного вида приложений, таких которые не требуют выжимать из аппаратуры все. Но эти жа правила могут просто навредить для тех кто пишет приложения работающие на пределе, для них нужны совсем другие правила, и первое из них тестировать все что можно на скорость и без этого даже не начинать проектировать.
FR>Все хорошо и красиво и у меня возражений по существу нет. Но ты упустил главное, эти правила хороши при разработке определенного вида приложений, таких которые не требуют выжимать из аппаратуры все. Но эти жа правила могут просто навредить для тех кто пишет приложения работающие на пределе, для них нужны совсем другие правила, и первое из них тестировать все что можно на скорость и без этого даже не начинать проектировать.
Опять же — тестировать, а не умозрительно выбирать решения, все решает опыт
"2. Проектируя код задумываемся над тем в каких условиях он должен работать и с какими проблемами можем столкнутся. Исходя из этого выбираем приемлемые алгоритмы и средства (библиотеки, рантаймы, компиляторы и т.п.) и другие проектные и локальные решения. "
Вот отсюда и исходим, смотрим, что уже было сделано до нас в подобных областях, все таки не на пустом месте работаем, так что все ок
Здравствуйте, Nickolay Ch, Вы писали:
NC>Опять же — тестировать, а не умозрительно выбирать решения, все решает опыт
А тут никто вроде и не предлагал умозрительно все решать.
NC>"2. Проектируя код задумываемся над тем в каких условиях он должен работать и с какими проблемами можем столкнутся. Исходя из этого выбираем приемлемые алгоритмы и средства (библиотеки, рантаймы, компиляторы и т.п.) и другие проектные и локальные решения. "
NC>Вот отсюда и исходим, смотрим, что уже было сделано до нас в подобных областях, все таки не на пустом месте работаем, так что все ок
Нет не Ok есть ситуации в которых если следовать по порядку Владовым рекомендациям просто придется выбросить то что уже сделал и написать все по новой.
FR>>А тут никто вроде и не предлагал умозрительно все решать.
NC>А вот предлагали, не будем показывать пальцем... NC>Посмотрите соседние топики.
да ладно
FR>>Нет не Ok есть ситуации в которых если следовать по порядку Владовым рекомендациям просто придется выбросить то что уже сделал и написать все по новой.
NC>Жестких правил не бывает, не в армии NC>Но пункт 2 вроде как удовлетворяет тому, о чем вы писали — есть жесткие требования работы на пределе возможностей: NC>"задумываемся над тем в каких условиях он должен работать ... выбираем приемлемые алгоритмы и средства (библиотеки, рантаймы, компиляторы и т.п.)"
NC>Может я вас не так понял...
Может и не так, но в тех ситуациях про которые говорю я первым пунктом должно стоять тестирование и прототипизация, а проектирование уже вторым и структура программы будет в первую очередь подчинятся не требованиям красоты и простоты модернизации, а требованиям эффективности работы. Просто могу предположить что вы с Владом просто не работали при таких требованиях и не выкидывали на половину готовый красивый, но тормозной проект.
Здравствуйте, FR, Вы писали:
FR>Все хорошо и красиво и у меня возражений по существу нет. Но ты упустил главное, эти правила хороши при разработке определенного вида приложений, таких которые не требуют выжимать из аппаратуры все. Но эти жа правила могут просто навредить для тех кто пишет приложения работающие на пределе, для них нужны совсем другие правила, и первое из них тестировать все что можно на скорость и без этого даже не начинать проектировать.
Эти правила никогда навредить не могут. Просто акценты смещаются. При выборе алгоритмов и проектных решений фактор производительности или ресурсоемкости оказывает большее воздействие на решение.
Ну, и еще хочется сказать, что все же большая часть приложений все же пишется не для контроллеров где все дико ограничено. Даже игры вроде Квэйка 4 не требуют истошного битовыжимания. Наоборот они скорее требуют понимания, что основные тормоза происходят из проектных решений.
В любом, случае совет не предпологать, а знать лишним никогда не будет. Прежде чем убить время на "более оптимальное решение" неплохо бы убедиться, что от него будет реальный бенефит.
... << RSDN@Home 1.2.0 alpha rev. 618>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, FR, Вы писали:
FR>А тут никто вроде и не предлагал умозрительно все решать.
ХМ. Именно это и предпологали. Заявления типа "а вот когда некие умники начинают из файла по одному байту читать" как раз и является таким примером. Причем тут даже нельзя сказать правильно оно или нет. Все упирается во множество факторов.
FR>Нет не Ok есть ситуации в которых если следовать по порядку Владовым рекомендациям просто придется выбросить то что уже сделал и написать все по новой.
Рекомендации не совсем мои. По ним собственно 90% коммерческого софта делается. Это просто тут рассадник инакомыслия. Собственно их верность подтверждает то что коммерческий софт живет и здравствует.
... << RSDN@Home 1.2.0 alpha rev. 618>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, gear nuke, Вы писали:
GN>Таки почитав, как народ начал сравнивать inline и не-inline варианты функций при чтении не то с диска, не то из кеша файловой системы ОС,
Вот и я о том же. Грустно, блин.
... << RSDN@Home 1.2.0 alpha rev. 618>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, FR, Вы писали:
FR>>Все хорошо и красиво и у меня возражений по существу нет. Но ты упустил главное, эти правила хороши при разработке определенного вида приложений, таких которые не требуют выжимать из аппаратуры все. Но эти жа правила могут просто навредить для тех кто пишет приложения работающие на пределе, для них нужны совсем другие правила, и первое из них тестировать все что можно на скорость и без этого даже не начинать проектировать.
VD>Эти правила никогда навредить не могут. Просто акценты смещаются. При выборе алгоритмов и проектных решений фактор производительности или ресурсоемкости оказывает большее воздействие на решение.
Все-таки могут, я на своем опыте прошел, но так как не мастер рассказывать байки, то пересказывать грустную историю не буду. Кроме битовыжимания есть еще один тип программ, где эти правила могут принести больше вреда чем пользы, это разовые небольшие утилтиты, и вообще небольшие программы (~20000 строк).
VD>Ну, и еще хочется сказать, что все же большая часть приложений все же пишется не для контроллеров где все дико ограничено. Даже игры вроде Квэйка 4 не требуют истошного битовыжимания. Наоборот они скорее требуют понимания, что основные тормоза происходят из проектных решений.
Игры понятие очень растяжимое, но сейчас больше 80% рынка игр это приставки, а это в некторых аспектах похлеще контролеров,(ситуация такая что аппаратура неизменна а требования к программам все выше и выше) и битовыжимание там нормальная практика.
VD>В любом, случае совет не предпологать, а знать лишним никогда не будет. Прежде чем убить время на "более оптимальное решение" неплохо бы убедиться, что от него будет реальный бенефит.
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, FR, Вы писали:
FR>>А тут никто вроде и не предлагал умозрительно все решать.
VD>ХМ. Именно это и предпологали. Заявления типа "а вот когда некие умники начинают из файла по одному байту читать" как раз и является таким примером. Причем тут даже нельзя сказать правильно оно или нет. Все упирается во множество факторов.
Ладно, они немного погорячились, но и ты тоже не во всем прав.
FR>>Нет не Ok есть ситуации в которых если следовать по порядку Владовым рекомендациям просто придется выбросить то что уже сделал и написать все по новой.
VD>Рекомендации не совсем мои. По ним собственно 90% коммерческого софта делается. Это просто тут рассадник инакомыслия. Собственно их верность подтверждает то что коммерческий софт живет и здравствует.
Да я сам часто примерно по такой схеме и работаю, но ситуации бывают разные и есть отрасли с многомиллиардными оборотами в которые с такими рекоменациями лучше не лезть.
VD>Рекомендации не совсем мои. По ним собственно 90% коммерческого софта делается. Это просто тут рассадник инакомыслия. Собственно их верность подтверждает то что коммерческий софт живет и здравствует.
Тут вообще в основном собираются люди, чтобы поубивать время, насколько я понимаю(поправьте кто-нить, если ошибаюсь). Обычно на философствования времени то не остается.
Спорить с теми, кто убежденно следует каким то догматам, бессмысленно, их не переубедить. Действительно напоминает религиозные споры.
Единственный смысл, который я вижу в ответах в данном форуме(равно как и в выставлении оценок, согласий, несогласий), это, чтобы те, кто только начинает программировать и попадает сюда, могли выработать более прагматичный(специально не пишу "более правильный") подход к разработке, дабы прийдя на работу писали софт, адекватный текущему состоянию рынка(не пишу "хороший"), а не строгали бы велосипеды, меряясь пузами, кто сколько байт съэкономил, и у кого код быстрее работает на несколько процентов, не философствовали в курилках и на форумах в стиле: "ах, как бы тут заоптимизить, чтобы было все зашибись". От такого софта только головная боль и производителям и заказчикам.
Не секрет, что наше образование и обучение программированию в вузах(про школы лучше не вспоминать), оставляет желать много лучшего, и подталкивает к уже упомянутому ужасному(имхо) стилю, ведь многие преподаватели любят так отругать студента за выделение нескольких лишних байт, чтобы он долго это помнил.
Здравствуйте, FR, Вы писали:
FR>Ладно, они немного погорячились, но и ты тоже не во всем прав.
Я на абсолютную правоту и не притендую.
Но все же хотелось бы услышать в чем я не прав конкретно.
FR>Да я сам часто примерно по такой схеме и работаю, но ситуации бывают разные и есть отрасли с многомиллиардными оборотами в которые с такими рекоменациями лучше не лезть.
Возможно. Но я их не видел.
... << RSDN@Home 1.2.0 alpha rev. 618>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, FR, Вы писали:
FR>>Ладно, они немного погорячились, но и ты тоже не во всем прав.
VD>Я на абсолютную правоту и не притендую. VD>Но все же хотелось бы услышать в чем я не прав конкретно.
Просто тон надо было помягче и без личных наездов. Ну и не надо говорить за всех, список может и подходит в очень многих случаях, но не для 90% точно.
FR>>Да я сам часто примерно по такой схеме и работаю, но ситуации бывают разные и есть отрасли с многомиллиардными оборотами в которые с такими рекоменациями лучше не лезть.
VD>Возможно. Но я их не видел.
Так пожалуйста разработка игр под консоли и другие не PC устройства.
Здравствуйте, FR, Вы писали:
FR>Просто тон надо было помягче и без личных наездов.
А... Тут согласен. Погорячился конечно.
FR> Ну и не надо говорить за всех, список может и подходит в очень многих случаях, но не для 90% точно.
Я говорил за себя. Цифра конечно с потолка, но это моя оценка.
FR>Так пожалуйста разработка игр под консоли и другие не PC устройства.
Да не выжимает там никто 100% во всех случаях. Выжимаются там обычно 3D-движки, да и то не по части мелких оптимизаций. Скорее оптимизации там идут на уровне алгоритмическом и API-ном.
Простой пример. Туча игр используют интерпретирующие скрипты для описания логики. Это верх неразумности. Одако многие считают что производительность оных скриптов погоды не делает. А это и есть жизнь по описываемым мною приципам. Другое дело, что скрипт можно было заменить на управляемый или функциональный язык, короче, на типобезопасный и компилируемый язяк. Но это уже отдельная песня.
... << RSDN@Home 1.2.0 alpha rev. 618>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
FR>>Так пожалуйста разработка игр под консоли и другие не PC устройства.
VD>Да не выжимает там никто 100% во всех случаях. Выжимаются там обычно 3D-движки, да и то не по части мелких оптимизаций. Скорее оптимизации там идут на уровне алгоритмическом и API-ном.
ты скажи это тем кому приходится писать так чтобы современная игра работала на 32Mb памяти (притом не виртуальной) и грузилась с DVD (так чтобы можно было уже начать играть) за 20 секунд, да еще плюс жесткие требования к минимальному fps (именно к минимальному а не к среднему). И притом оригиналу на PC не хватало памяти объемом 256Mb для нормальной работы. В общем тому кому придется это портировать я не завидую
VD>Простой пример. Туча игр используют интерпретирующие скрипты для описания логики. Это верх неразумности. Одако многие считают что производительность оных скриптов погоды не делает. А это и есть жизнь по описываемым мною приципам. Другое дело, что скрипт можно было заменить на управляемый или функциональный язык, короче, на типобезопасный и компилируемый язяк. Но это уже отдельная песня.
Нет просто ты не понимаешь роль скриптов в играх, извини ты просто не в теме.
Здравствуйте, VladD2, Вы писали:
VD>Вот и я о том же.
А мне что бы понять, 2й раз перечитать потребовалось. Пропуская при этом эмоциональные детали .
People who are more than casually interested in computers should have at least some idea of what the underlying hardware is like. Otherwise the programs they write will be pretty weird (c) D.Knuth
Здравствуйте, IT, Вы писали:
IT>У меня есть только одно замечание к данному тезису. Ничто не может насобирать столько замечаний пользователей сколько сам разработчик в роли пользователя
Ни в коем случае....
1. Разработчик ленив и самовлюблен. У него свои понятия о достаточности функционала. Насчет ленив, тут есть еще и плюс. Прослеживается в пункте 2.
2. Разработчик крут. И это плохо. А плохо тем что он мысли не функционалом пользователя, а механизмами. Вообще у PM, арихтектора или team leader должна всегда на столе находится специальная дубинка. Чтобы согласно иерархии он подходил к разработчику и бил по голове. Не надо крутизны. Бум. Не изобретай велосипеда. Бум. Не домысливая за заказчика. Бум. Не оптимизируй не вовремя. Бум. И количество шишек перерастает в денежный эквивалент.
Мне в свое время много таких шишек набили. За что и благодарен. В свое время, я долго "беседовал" с аналитиками по поводу их неправильного отношения к программам по тому или иному вопросу. Долго спорил, что так не делают, что вы неправы, что я знаю как пользователи хотят. Но часто выезжал к пользователям, и у них было совсем другое мнение. Часто принимал слова благодарности за идеи аналитиков. Теперь стараюсь под страхом смертной казни не делать работу, которая никому не нужна.
Есть несколько программ которые мне не нравятся. Чуствую хреново построил. Что здесь не так, и здесь может быть не то. Только пользователи другого мнения. Некоторые временные(потому что считал их неудачными и промежуточными) решения работают у пользователей 4 года.
Единственное мнение которое можно брать за истину — это мнение аналитика и PM. Именно они общаются с пользователями, знают что они хотят, и самое главное, как трансформировать это в форму понятную остальным разработчикам.
Здравствуйте, IT, Вы писали:
IT>Здравствуйте, GlebZ, Вы писали:
IT>>>У меня есть только одно замечание к данному тезису. Ничто не может насобирать столько замечаний пользователей сколько сам разработчик в роли пользователя GZ>>Ни в коем случае....
IT>Забавно, но всё что ты написал, а я нещадно поскипал никак не соотносится с тем о чём говорю я
Да нет. Имеет. Я просто ответил более широко. А разницы то нет. Это все одна и та же проблема. Разработчик — не есть пользователь. Даже при оптимизации.
Здравствуйте, IT, Вы писали:
GZ>>Разработчик — не есть пользователь.
IT>Это кто такое сказал?
Я сказал. И даже показал почему. Ты будешь заниматься оптимизацией процессов которые пользователю не важны. А ему важны другие процессы которые как оказалось, к твоему удивлению, не удовлетворяют его. Я с таким сталкивался.
Здравствуйте, McSeem2, Вы писали:
>из которого ты сделал глобальный по жизни вывод, что оптимизация — зло. Она и есть зло, если в башке бардак.
+++ !!!
MS>Я вообще удивляюсь, что тебе понадобилась "неделя потения" на то, чтобы понять проблему разрыва ссылок.
MS>Теперь о smartdrv. Ты говоришь, что испытал некий шок. Но этот шок как раз и является следствием невежества. Получается, что твоя программа зависит от smartdrv и может работать только с ним. Но ведь тот же NortonGuide прекрасно работал и без всяких smartdrv. И чего тогда твоя "программа" стоила, если она требовала некую "ускоряющую приблуду"? Типа все нормальные программы ускоряются от smartdrv в полтора-два раза на дисковых операциях, а твоя ускорялась в десять раз? Один этот факт говорит о том, что программа — отстой.
MS>Более того, из всего этого ты сделал совершенно ложный по жизни вывод, что оптимизация непременно приводит к ухудшению дизайна. Так вот, я скажу, что это — чушь. Нормальная оптимизация только помогает и способствует хорошему дизайну. Но то, что лично ты считаешь оптимизацией, на самом деле ей не является. Это — не оптимизация. Для этого есть даже специальный термин — spaghetti-code.
Здравствуйте, IT, Вы писали:
IT>Я говорю не о просто кнопки подавить перед тем как пользователю отсылать, а серьёзном и продолжительном использовании для своих собственных нужд. Это очень хорошо заметно на том же самом .NET FW. Там где MS использует фреймворк для собственных разработок (та же ComponentModel), там всё как надо. Те части которые писались "для пользователя" иногда без дополнительной обработки напильником просто невозможно использовать.
С этим согласен, но не всегда бывает ситуация когда разработчик может стать пользователем своего труда.
... << RSDN@Home 1.2.0 alpha rev. 618>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, IT, Вы писали:
IT>Я же говорю, мы с тобой о разном. Я буду заниматься оптимизацией процессов, которые нужны пользователю, потому что я сам пользователь. Не пытаюсь прикинуться, а именно сам пользователь и есть.
Предположим завтра тебя попросят написать программу или сайт для хранения и поиска поворских рецептов (ну, скажут, что дадут лимон баксов, а работы там не неделю...). Неуже ли ты из-за этого по быстрому в повора переквалифицируешся?
... << RSDN@Home 1.2.0 alpha rev. 618>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, vdimas, Вы писали:
V>Здравствуйте, VladD2, Вы писали:
V>Фуу, давненько не пересекались, но ощущения все те же, все те же. Попробуй представить себе ситуацию, что собеседник тебя все-таки прекрасно понимает, и тратит на обдумывание твоих постов гораздо больше времени, чем ты тратишь на посты собеседника (это видно невооруженным взглядом... этот вопиющий факт уже просто на грани оскорбления — настолько по диагонали читать оппонентов )
V>В общем, так. Свой первый пост ты предоставил в настолько разжеванном виде, и до того гипертрофированно стоят акценты в нужных местах, что основной посыл поймет даже человек, весьма далекий от программирования как такового. Давай условимся считать, что оппонент понял, просто не согласен, либо же имеет замечания/дополнения.
Казалось бы. Но на сегодня в этой теме уже более 90 сообщений, а по делу только 2-3. Так что может кто-то и читает все нимательно, но понять написанного не всилах даже когда написанное с акцентами и разжевано.
V>Очевидно, настала моя очередь "разжевывать".
Ну, ну...
V> Отвергать преимущество оптимального кода над неоптимальным пока никто не собирается.
Верные слова, но с не верным смыслом. Для меня опимальность не сводится только к скорости. Я могу судить или об оптимальности в некоторой обаласти, или об оптимальности как совокупности факторов многие из кторых отрицательно воздействуют на другие. Но даже говоря об оптимальности производительности я не думаю, об абсолютной потимальности. По этому я и говорю, не об оптимальности, а о достаточности и приемлемости.
V> И даже ты относишься к этому делу всего лишь взвешенно, примерно как и я, как и подавляющее большинство разработчкиков с некоторым опытом. Когда речь идет об усилиях, затрачиваемых на оптимизацию, то мы всего лишь оцениваем отношение объема этих усилий к получаемому положительному эффекту (оговорюсь опять — за исключением случаев, когда на быстродействие и потребляемые ресурсы накладывается ограничение либо непосредственно в ТЗ, либо коссвено, выплывает на стадии анализа через смежные/используемые программные и аппаратные технологии)
Опять же не совсем так. Кроме затрат физических есть еще другие аспекты "оптимальности". Если быстродействие будет требовать от меня использовать кривой С-подобный код примеры которого в изобилии демонстрировались отдельными поборниками производительности, то я скорее предпочту более медленный код, но и более просто читаемый/изменяемый.
V>Так вот, если уж речь идет об отношении затраченных усилий к полученному эффекту, то очевидно, что необходимо минимизировать потраченные усилия, либо отказаться от их траты, если получаемый эффект невелик. Так вот, ОЧЕНЬ ЧАСТО т.н. "оптимизация" ничего не стоит,
Оптимизация ничего не стоит очень редко. Да и говорить о таких случаях как об оптимизации не стоит. Ну, да я уже повторяюсь.
V> никак не портит программу, не усложняет код и не требует полного повторного цикла тестирования. Мы давно пишем свои программы не с 0-ля, не с машинных кодов, а основываясь на весьма мощных платформах весом в миллионы строк исходников. Владение информацией об этом окружении помогает выбрать оптимальный путь решения задачи. Сам выбор оптимального пути уже является оптимизацией, даже если разработчик не потратил ни лишней минуты на это. Назовем это дело по другому: "грамотное инженерное решение".
Снова смотрим мои слова, об том что оптимальность бывает разная.
V>Ты в своем посте красочно обрисовал тонны потраченных усилий, были ярки картины загубленной красоты исходников... Ты ведь "потомству в пример" это все написал, признайся? Так вот, потомство должно так же знать, что недостаточное владение инструментом может породить все эти проблемы даже при решении такой несложной задачи как буферизация ввода.
Согласен. Собственно кривой код и тормоза на ровном месте это скорее не отсуствие погони за скоростью или красотой, а отсутсвие опыта или кривой опыт. Ну, возможно еще проблемы с ДНК.
Однако тенденция к отказу от абстракций подчеркнуто демонстрируемая, ну, вы знаете кем, как раз демонстрирует, то что выбор некрасивых и даже совсем кривых решений очень даже может являться следствием неразумной погони за производительностью.
Еще раз повторю, я в те времена намеренно отказался от "буферизации" воода и выбрал работу с "блоками памями". Это бло, можно сказать, дизайнерское решение. Безграмотное? Одназначно! Основанное на умозрительных предположениях? Безспорно. Но все же основанием для него явилось не то, что я не допер до буферизации и т.п. Основанием была погоня за производительностью.
V>Опять же... Требования и еще раз требования... Ну почему мы всегда обсуждаем что-то абстрактно, и как тут можно понять, чьи позиции устойчивее, если контекст не задан? Более-менее воссоздать картину можно попробовать из твоих эмоциональных акцентов. Но где гарантия, что их правильно истолковали? А может быть ты тогда не совсем правильно истолковал внешние условия? Какой был процент "покрытия" этими кеш-драйверами? Предназначалась ли твоя прога и для XT? Даже для тех, у кого 256кБ? (На них эти всякие кеши не ставились принципиально никогда, но тем не менее одно время таких машин было достаточно)
Нда, беда. Мне ПОХРЕНУ проценты, килобайты, названия функий И ДАЖЕ причины приведщие к этому. Я ГОВОРИЛ О НЕВЕРНЫХ ПОСЫЛАХ... неверных стремлениях, неверных действиях.
Что килопроцентов, то исходная версия программы писалась на ХТ и там изумительно вставал Смартдрайв, ведь у них один хрен был метр памяти.
VD>>Посыл явно непонятен, раз ты продолжаешь рассуждать о каких-то там структурах и версиях компиляторов.
V>Ловко, однако не зачтено.
Ты видимо непонимашь реального положения вещей. Мне не нужно сдавать тебе зачеты.
V>Диктую большими буквами: ЕСЛИ ВАМ И ПРОЕКТУ ЭТО НИЧЕГО НЕ СТОИТ, ТО ВЫБИРАЙТЕ НАИБОЛЕЕ ЭФФЕКТИВНОЕ РЕШЕНИЕ ЗАДАЧ НА ЛЮБЫХ УРОВНЯХ.
Ну, тогда я тоже продиктую ДУМАЙТЕ НА ДВА ШАГА ВПЕРЕД, МАТЬ ВАШУ. Не думайте о битах и байтах пока в этом не будет крайней нужды.
Вообще я кажется понял. Разница между нами не в подходах к программированию. Разница в том что мое мировозрение испочено кроме программирования еще и экономикой с юриспруденцией. По этому для меня очевидны многие вщеи не очевидные для программистов. Видимо чистый программист принципиально не может в рассуждениях не оперировать битами. Вопрос только в степени зациклинности на них.
V>Ключевая фраза: "ничего не стоит".
Да? Привести тебе примеры кода кого приводишиеся в качестве агрументов битовыжимания, чтобы ты обяснил как они могут ничего не стоить?
V>Но тем не менее, факт остается фактом. Тысячи и тысячи программистов пишут одно и то же, выпускают массу продуктов очень близкой функциональности, все получают немаленькую ЗП, и вопрос минимизации затрат на разработку ПО встает в гораздо более жесткой форме — быть бизнесу или же провалиться с треском. Отсюда все эти веяния. Теперь примерно понятно, почему я там 3 поставил?
Это ты о битовыжимальной агитации? Не, не понятно. Ели бы было понятно, то я пошел бы тоже чё-нить поставил.
V>В своей жизни я уже успел написать несколько учетных систем, массу системных и т.д. и т.п. И очень многие мои коллеги так же. Кое какие продукты используются до сих пор, кое-какие скоро начнут активно использоваться (я очень надеюсь). Однако, я ни на секунду не забываю, что программист (и я в том числе) сейчас используется крайне неэффективно. Процесс раздела рынка ПО сейчас в самом разгаре, и продлиться по прогнозам еще не менее 20 лет, т.е. сейчас рулят правила джунглей. А правила не гласят — "сделай лучше всех", правила гласят: "сделай всех", или еще короче: "выживи". И вот такой вот внешний контекст оказывает весьма серьезное влияние на умы даже опытных разработчиков, да такое, что они в пылу спора уже и не помнят, где причина а где следствие обсуждаемых вещей.
Понятно. У тебя экономические причины. Ты уж извини, но экомические вопросы мне мало интересны. И уж обсуждать я их стал бы не с программистами и не в темах связанных с производительностью ПО.
V>Ну представь хоть на секунду, что в стремлении выпустить, например, новую Тойоту на рынок, с новыми, прямо-таки космическими внешними обводами, фирма Тойота пошла на следующие допущения: V>- Весит в 2 раза больше, однако, по-прежнему шустро ездит за счет более мощного мотора V>- Топлива она жрет в 2 раза больше V>)
Вы хотите поговорить об этом? (с)
Я не буду обяснять почему эта налогия здесь не применима. Иначе прийдется вдаться в очень тонкие проблемы рынков и рыночных ниш. Хватватет того, что доказательство по аналогии является машейничеством.
V>Такое может привидется только в кошмарном сне кокого-нибудь инженера Тойоты. В реальности, каждая следующая модель выходит со все лучшими характеристиками, ос более оптимальным весом, с большим КПД (люди, вы еще помните это слово) двигателя.
Тебе не странно, что когда фирма выпускает вертолет вместо легковушки строит машину весящую болше и жрущую больше ресутсов? А не странно что лимизин представительского класса "Весит в 2 раза больше, однако, по-прежнему шустро ездит за счет более мощного мотора — Топлива она жрет в 2 раза больше"?
Вот и мне не странно, что программа которая предоставляет мне рефактринг, хорошо работающее автодополнение при вводе, контекстную справку на каждый чих, отличный расширяемый редактор и отладчик и т.п. жрет чуть ли не в 10 раз больше времени. Точно так же как не странно, что графический Ворд 2003 с морем фич на два-три порядка более прожерлив чем скажем Лексикон, или Ворд фор ДОС.
Так что кончай увликаться аналогиями, а обрати внимание на свою логику. В своих рассуждениях ты забывашь, что продукты жрущие больше ресурсов и дают больше. А те что жрут больше не давая ничего в замен по сравнению с продуктами конкурента попросу теряют потребителя и вымирают.
А слезы по повду расходвания 10 метров из гига — это глупость и ханжество. Не нравится? Старые программы работать не перестали.
V>Но ведь это не удивительно, над новой моделью работаюбт сотни инженеров. А у нас, у программистов, примерно 5-15 человек делают проекты, по информационной сложности мало уступающие проекту той же Тойты.
Ну, что же. Тебе никто не мешает заработать денег, создать свою фирму, нанять сотню инжинеров и сделать продукт который пользователи предпочтут потому другим. Вот только на этом пути ты будешь вынужден научиться зарабатывать деньги и поймушь в чем ты был не прав.
V> Поянтное дело, что для самого факта успешности подобных проектов жизненно необходимо максимально все упрощать и выкидывать все лишнее (и оптимальные пути разумеется тоже). А иначе как? Человеческий мозг — весьма ограниченная в своем объеме штуковина.
А иначе так. Пусть все занимаются своим делом. Пусть успешность продукта на рынке предсказывают маркетологи и сложбы по взаимодействию с клиентами. Пусть проектами управляют люди знающие толк в этом деле. А программируют и проектируют ПО люди проффеисиональные в этом деле. Тогда маркетологи и т.п определять набор требуемых возможностей, менеджеры спланируют их реализацию, а программисты запрограммируют и оттестируют все в нужные сроки с нужным качеством. Тогда успешные продукты автоматически выявят более грамотные команды, а безграмотные развалятся. В общем, через рынок потребитель сам определит что ему надо. А прямое управление как бы оно не казалось заманчивым неизбежно приведет к маразму и деградации. О программистах тут вообще речи вести не стоит. Они тут могут сделать только одно — найти или создать контору палитика и прицыпы работы которой их устроит.
На этом рассуждения о экономике и бизнесе лично я заканчиваю и возвращаться в рамках этой темы не собираюсь.
V>... Хотел еще примеров написать, но вроде и так общий (самый общий) мой посыл должен быть понятен.
Безусловно. Жаль, что не всем.
V>А что касается конкретных выводов для молодого поколения: ребята, исходим из того что есть (собственно, это и есть формула выживания ).
Ага. В рамках поднятых тобой вопросов можно смело посоветовать первый принцип — занимайтесь тем, в чем являетсесь специалистами и старайтесь стать еще большими специалистами.
V>Я бы не стриг всех под одну гребенку. К счастью, в крайности бросаются не многие.
Вопрос который мы обсуждаем является таким, что в крайности в нем бросаются очень многие. По-моему, тут уже половина народу призналась, что их порой тянет пооптимизировать что-нить без особой на то необходиомости. Так что тут речь не о стрижке, а о выробатывании здорового эмунитета к дурным пристрастиям.
V> А что касается текущего положения дел, то на само понятие "эффективности" молодое поколение просто забило.
Это не так.
V> Влад, даже ты пишешь свои программы более менее эффективно (сужу по публикуемым кускам). Ты по другому не можешь, хоть и озвучиваешь другую точку зрения. (гы-гы, кстати).
Что значит "даже"? Я пишу вмеру разумно. Иногда тоже увлекаюсь оптимизациями, а потом понимаю что валял дурака. От чего и предостерегаю других.
Мои слова предназначены для тех самых молодых, но умных людей которые понимают, что учиться нужно по возможности на чужих ошибках и чужом опыте. Видя проста таки пропаганду в коре ошибочного (по-моему) подхода, я и стараюсь противопоставить ей обратную пропаганду. Надеюсь, что мои усили не пропадут даром.
V>В споре рождается истина, только дураки учаться на своих ошибках и т.д.
И я о том же. Но надо еще понимать, что является ошибкой.
V>Как еще молодым научиться оценивать тот хрупкий баланс м/у потраченными усилиями и получаемым эффектом? И еще немаловажно, куда эти усилия тратить. В описанном тобой примере их стоило потратить не на кодирование, а на изучение документации.
Вот, например, это высказывание явная ошибка. Документация тут ну никаким обоком не поможет. Тут время нужно было потратить на поиск наиболее простого решения на проверки своих предполжений. Короче на формирование знания о предмете, а не на попытку решить проблему на основании отрывочных знаний и предположений.
V>Знаешь, когда я писал лексические анализаторы, я тоже не пользовался классами строк, и тоже активно использовал стек. При определенной аккуратности лекго исключаются возможности прохода по стеку. Обяснить как?
Не надо. Ты потратил время зря, если конечно ты не писал его 20 лет назад. Я вот писал парсер на Шарпе и он работает очень и очень шустро. Сам понимашь, ни о каком стеке тут и речи не идет.
V>Т.е., повторю, в отрыве от контекста доказывать свою правоту бесполезно.
О том и речь. Собственно вопрос и был в том, что предположения бросамемые извеснтым товарищем — это как раз вот такие безконтекстные рассуждения. Они могут быть верны и не верны одновременно. Так что не нужно предпологать. Нужно знать и сопоставлять.
V> Лично я поддержал сам факт обсуждения этой темы. Согласен, что Дворкин немного перегибает,
Будем надеяться, что тройка поставленная им за твое сообщение в том числе включает и согласие с этим вот высказыванием.
V>но, может он это делает специально, в ответ полное пренебрежение к этому вопросу у окружающего мира?
Вряд ли. Я вижу за этим именно деструктивное мировозрение усиливаемое его статусом. Хотя возможно тут уже я перегибаю палку.
V>Вообще-то, согласно правилам инженерии, самое общее решение является самым неподходящим для конкретного случая.
Да? Можно источники? Люди всегда стремились к универсальным решениям. Другое дело, что частные решения проще оптимизировать. Но это не одно и то же.
V> Однако, в ПО повторное использование ничего не стоит (т.е. разможение информации и кода ничего не стоит).
К сожалению, стоит. Со временем все меньше и меньше, но этого достаточно чтобы очень многие забивали на него исходя из тех же вопросов производительности. Я, кстатати, каюсь, грешен... тоже забивл и порой продолжаю забивать на повторное решение ради производительсности или чего-то еще. Только я делаю это скрипя сердцем, а очень многие с радостью в душе.
V> И вот мы называем самые общие решения "грамотным дизайном", потому как они повторно применимы. В общем, это совсем другой вопрос — что считать грамотным. Я тоже люблю фреймворки писать.
Нет. Лично я называю грамотными решениями — решения подходящие для задачь по многим параметрам (совокпностью которых и выражается мое мировозрение). Общность решения не является решающим, как и скорость.
Скорее грамотным решением я назову некое обобщенное решение которое в то же время позволяет хорошо адаптироваться к задаче. Ну, например, можно написать общее решение, а можно "общее решение с параметрами". Параметры повзолят настроить решение под конкретные задачи.
V>Добавлю еще насчет грамотного дизайна. Опять все встает с ног на голову. Раньше люди решали путем анализа вполне конкретные программистские задачи. Потом обнаружили их похожесть. Потом дали имена паттернам и использовали так: спроектировал что-либо, максимально удовлетворяющее требованиям, а потом _обяснил_ разработку на языке паттернов. Т.е. язык паттернов — это всего лишь терминологическая база. А молодежь как сейчас что-то проектирует??? Вместо того, чтобы решать поставленную задачу, крутит эти паттерны как кубики Лего, путем полного перебора стараясь подобрать нечто условно отвечающее поставленной задаче. И выходят монстры, один другого страшнее. И _паттэрны_ вроде есть, и неграмотно при этом...
Не, с ног на голову, по-моему, все ставишь как раз ты.
Паттерны — это опыт. Слово "паттерн" появилось в программистском лексиконе очень недавно и я по началу был сильно против него. Но потом я понял, что паттерн — это опыт решения конкретной задачи который описан настолько хорошо, что им можно оперировать как сущьностью. 90% паттернов я применял по наитию и раньше. Я использовал Синглтоны и Фабрикуи классов в КОМ-е и т.п.
Доходил я до этих паттерно одним из двух способов:
1. Решая конкретную задачу натыкался на сложности. Раз за разом преодолевая сложности я накапливал опыт их преодоления.
2. Подсматривая неординарные решенеия (т.е. те до которых сам не допер) у других (например, в АТЛ).
Со временем я запоминал эти решения и начинал их использовать еще на стадии проектирования (ну, или на стадии принятия решения о том как решать вставшую проблему).
Что же я делаю глупости? Нужно как во времена когда я только учился программировать каждый раз проползать на брюхе все трудные места, и только потом распозновать паттерны и заменять некрасивые решения на них?
Или что же тем кто родился на 10 лет позже тоже нужно обязательно проползти на брюхе все что прополз я? Эдак человечество остановилось бы в развитии и каждое следующее поколение смогло бы только чуть-чуть поодвигаться впердед и то только если верить в то, что каждое новое поколение в принципе становится умнее.
Это несусветная глупость!
Человечество идет семемильными шагами вперед исключительно благодаря тому что научилось обобщать опыт. Паттерны это и есть обобщенный опыт. Кстати, описанный мной принцип получения программ приемлемых по быстродействию тоже есть обощение опыта. Более того не моего! Это и есть те самые инженерные приципы которыеми тут многие так гордятся, если хотите.
Так что молдые очень правильно делают, что используют паттерны при проектировании ПО. Тем самым они повышают свою производительность.
Ну, а беспокоиться нужно о том, чтобы эти молодые привильно понимали эти паттерны и умели быстро и безошибочно распозновать места где они применими (выбирать нужный паттерн).
Конечно, человек неспособный "проползти на брюхе" то для чего еще нет паттерна — это и есть тот самый ламер! Любой хороший программист обязан уметь пробивать проблемы на одном упорстве. Но только если проблема не имеет готового качественного решения.
VD>>Я бы поверил тебе, что ты так всегда поступашь, если бы не видел твоей "тройки" вот на этом призыве
. Возможно ты и его не понял доконца, но тогда вопрос можно ставить об адекватности восприятия тобой и вещей вроде объема крови жертвуемой на оптимизации и необходимостью этих оптимизаций. (ни прими это за оскорбление, плиз)
V>(уффф, чтоб меня так чужие оценки беспокоили...)
Меня не беспокоит сама оценка. Уж кому кому, а не мне чужим оценкам завидывать.
Я считаю оценку выражением согласия и поддержки. И куча положительных оценок на явно, по-моему, деструктивном мнеии меня обижает и пугает. Особенно пугает когда оценки ставят не те ктого я считаю ортодоксами или фанатиками.
V>В этом месте ты уже забыл, что я настаивал на выборе оптимального инженерного решения, и обращал внимание, что сам этот выбор может ничего не стоить. А оценку я поставил за художественную силу и злободневность самой темы. И за то, что не поленился человек такой большой пост откатать, и при этом вовсе не нудный. В общем, по аналогии с фигурным катанием, оценки не только за технику ставим, но еще и за артистичность.
Я не вижу злободневности. Я вижу деструктивность. Очень жаль, что ее не видешь ты и многие друние.
Ставить же оценки за графоманство, чем собственно и является художественная сила, то же считаю не очень разумно, так как яорум посвящен программированию и оценка будет воспринята как одобрение и поддержка основных посылов сообщения.
Именно по этому меня волнуют оценки на пдообных мениях.
Я рассуждаю просто... Если на этот форум зайдет человек мировозрение которого еще не сформировалось, то он обязательно обратит внимание на то, что множество вроде как разумных и достоиных людей поддерживают мнение о том, что нужно делать все максимально быстрым. Дальше скорее всего начнутся дейсвия которые лет через 20 могут привести к появлению еще одной волны, ну, ты понял чего.
VD>>Ну, любая идея требует критического взгляда. Но хотелось бы чтобы этот взгляд был действительно критическим, а не основанным на непонимании.
V>Мы все тебя прекрасно понимаем, мамой клянусь!
Неуверен. Вернее даже уверен в обратном.
V>Давайте, после артподготовки (обмена любезностями), перейдем к ближнему бою. Выкладывайте у кого что есть из актуальных примеров, когда по чьему-то мнению требвалось принимать волевое решение об затратах на оптимизацию, заодно попытаемся собрать максимум внешних ограничений/требований и оценить адекватность подобных затрат. У меня есть пара весьма актуальных примеров, если народу будет интересно, с удовольствием пообсуждаю.
Незнаю. У меня все просто. Если вижу что что-то работает медленно, то думаю как исправить и исправляю. У меня обратная проблема. Часто стараюсь сделать оптимальнее чем нужно на что убиваю кучу времени.
... << RSDN@Home 1.2.0 alpha rev. 618>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, IT, Вы писали:
VD>>Предположим завтра тебя попросят написать программу или сайт для хранения и поиска поворских рецептов (ну, скажут, что дадут лимон баксов, а работы там не неделю...). Неуже ли ты из-за этого по быстрому в повора переквалифицируешся?
IT>В повора нет, но свои рецепты там хранить буду
Хорошая идея ...
... << RSDN@Home 1.2.0 alpha rev. 615 on Windows XP 5.1.2600.131072>>
Здравствуйте, eao197, Вы писали:
E>Влад, твои слова: "я в те времена намерено отказался от 'буферизации'" выглядят совершенно не убедительно, т.к. ты сам несколько раз подчеркивал, что опыта у тебя на тот момент практически не было.
Понимаш ли. Мне не в чем тебя убеждать. Я тебе рассказываю как дело было. Я может быть уже не помню технические детали, но суть вопроса мне очень хорошо врезалась в память.
E>Вот ты бесишься, что народ не понимает, что оптимизировать нужно только то, что нужно и только на основании точных оценок.
Я не бушусь. Я сожалею и грущу.
E>Но ты и сам пойми, что оптимизация, выполненная не профессионалом -- это страшная штука. Практически тоже самое, что бесполезная или бестолковая оптимизация.
Оптимизация может быть полезной, бесполезной и вредной. Кто ее делает значения не имеет. Я же делился опытом и выводами сделанными из этого опыта. То что у некоторых проффесионалов выводы из этого рассказа постоянно сбиваются на обсуждение технических подробностей все же не моя вина, а их беда.
... << RSDN@Home 1.2.0 alpha rev. 618>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, vdimas, Вы писали:
VD>>Именно это я вижу в его примерах и словах. Там явным образом прослеживается натуральная борьба с абстракциями. Ведь за них нужно латаить. Заметь у него в коде ни разу не появился ни один строковый класс. В коде сплошные сишные строки размещаемые исключительно в стеке. А ведь по его же словам приводимый им код написан на С++.
V>Знаешь, когда я писал лексические анализаторы, я тоже не пользовался классами строк, и тоже активно использовал стек. При определенной аккуратности лекго исключаются возможности прохода по стеку. Обяснить как?
V>Т.е., повторю, в отрыве от контекста доказывать свою правоту бесполезно. Лично я поддержал сам факт обсуждения этой темы. Согласен, что Дворкин немного перегибает, но, может он это делает специально, в ответ полное пренебрежение к этому вопросу у окружающего мира?
Не совсем так. Специально, я конечно, это не делаю. Кстати, на вопрос, почему я в примерах из своего проекта не использую string и т.д. ответ очень простой — проект делался на чистом С. Мне это активно не нравилось, но я вошел в проект, когда он уже существовал и изменить ничего не мог.
А вот чего я не понимаю — почему некоторые упорно приписывают мне то, чего я не говорил ? Я говорю, что надо писать эффекктивно — мне отвечают "он призывает писать эффективно любой ценой". Я ничего вообще о дизайне и архитектуре не говорил — у меня, оказывается, натуральная борьба с абстракциями. Покажите мне место, где я призывал "любой ценой"
Увы, существует два способа спорить. Один — для того, чтобы попытаться найти истину. Другой — чтобы победить в споре любой ценой. При этом используются явные передергивания, приписывание оппоненту того, что он не говорил и т.д. В общем, что тут объяснять — PR-технологии у всех на глазах.
V>(уффф, чтоб меня так чужие оценки беспокоили...)
V>В этом месте ты уже забыл, что я настаивал на выборе оптимального инженерного решения, и обращал внимание, что сам этот выбор может ничего не стоить. А оценку я поставил за художественную силу и злободневность самой темы. И за то, что не поленился человек такой большой пост откатать, и при этом вовсе не нудный. В общем, по аналогии с фигурным катанием, оценки не только за технику ставим, но еще и за артистичность.
FR>Игры понятие очень растяжимое, но сейчас больше 80% рынка игр это приставки, а это в некторых аспектах похлеще контролеров,(ситуация такая что аппаратура неизменна а требования к программам все выше и выше) и битовыжимание там нормальная практика.
Это ты случайно не про PlayStation 3? Который вроде как 2 HDTV потока может одновременно декомпрессить, а стандартного MPEG — так под 1000 видеопотоков? Я презенташечку бегло так посмотрел — дык десктопы лет через пять только догнать эту железяку смогут.
1.1.4 stable rev. 510
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Sinclair, Вы писали:
FR>>Игры понятие очень растяжимое, но сейчас больше 80% рынка игр это приставки, а это в некторых аспектах похлеще контролеров,(ситуация такая что аппаратура неизменна а требования к программам все выше и выше) и битовыжимание там нормальная практика. S>Это ты случайно не про PlayStation 3? Который вроде как 2 HDTV потока может одновременно декомпрессить, а стандартного MPEG — так под 1000 видеопотоков? Я презенташечку бегло так посмотрел — дык десктопы лет через пять только догнать эту железяку смогут.
Я про PlayStation 2 про который тоже говорили что PC их долго не догонит, это долго длилось только два года. И под этот PS2 еще года три будут активно разрабатывать игры, так просто от 100 миллионов проданных устройств не отмахнутся.
Если же говорить про PS3 то надо внимательней читать презентации (где почти все чистый пиар, даже ролики там были предрендереные, а если подсчитать производительность любой современной видеокарты по их методике тоже получатся терафлопсы ) и смотреть тех. характеристики, и можно увидеть что памяти там всего 256 Mb (не ресурс?) она снова таки не виртуальна, а процессор это Cell оптимально программировать под который без выкрутасов не получится.
Здравствуйте, FR, Вы писали: FR>Я про PlayStation 2 про который тоже говорили что PC их долго не догонит, это долго длилось только два года. И под этот PS2 еще года три будут активно разрабатывать игры, так просто от 100 миллионов проданных устройств не отмахнутся. FR>Если же говорить про PS3 то надо внимательней читать презентации (где почти все чистый пиар, даже ролики там были предрендереные,
Я их увы, не читал. Только смотрел. И как-то слабо верится в то, что демонстрашка прямого управления 3d объектами предрендеренная. Что касается супергеймов — это да. Возможен и пререндеринг. Хотя я в этом сомневаюсь — у парней бы оторвали все лишнее, если бы демка нового GPU случайно оказалась невоспроизводима на реальном железе. Это ж не писюк, где все можно списать на корявую сборку, некошерную память и прочие пуговки. Все легко проверяется.
1.1.4 stable rev. 510
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Sinclair, Вы писали:
FR>>Если же говорить про PS3 то надо внимательней читать презентации (где почти все чистый пиар, даже ролики там были предрендереные, S>Я их увы, не читал. Только смотрел. И как-то слабо верится в то, что демонстрашка прямого управления 3d объектами предрендеренная. Что касается супергеймов — это да. Возможен и пререндеринг. Хотя я в этом сомневаюсь — у парней бы оторвали все лишнее, если бы демка нового GPU случайно оказалась невоспроизводима на реальном железе. Это ж не писюк, где все можно списать на корявую сборку, некошерную память и прочие пуговки. Все легко проверяется.
Ну я тоже смотрел Знакомые художники говорят что демки игр нарисованы. Да и простое сравнение с демками от XBOX 360 в котором железки примерно того же уровня показывает, что все таки нарисовали. У Сони никто ничего оторвать не сможет она на этом рынке как ms на pc'ишном
Да и графическую карту что будет на PS3 (nVidia RSX) чудом техники не назовешь, Nvidia говорит что она шустрее чем пара (через SLI) GeForce 6800 Ultra , а это значит что скорее всего уже следующим летом топовые карты на PC уже обгонят nVidia RSX.
Здравствуйте, VladD2, Вы писали:
E>>Мне кажется, что проблема твоего поста была в том, что для благой цели были выбраны не удачные средства.
VD>С этого момента можно по подробнее.
А чего тут подробнее? Я уже несколько раз об этом говорил. Ты привел в качестве примера свой опыт на тот момент, когда ты и программировать-то нормально не умел (по твоим же словам). А следовательно (для меня лично) -- грош цена этому опыту.
Да и ты сам сказал:
Вообще-то я говорил о другом. Я говорил, о том, что надо знать что делашь, и не делать ничего просто так.
Так вот, делая вторую или третью программу в своей жизни, сложно знать "что делаешь".
Ну об этом мы уже говорили.
E>> Это как борьба Microsoft Windows и IBM OS/2. Целью обоих было создание ОС следующего поколения для PC. У M$ был корявенький продукт (цель), но отличный маркетинг (средства). А у IBM -- с точностью до наоборот. Результат всем известен.
VD>Аналогия не то что бы не уместна, она просто неверна, ну, или хотя бы спорна. Опять втягиваемся в религиозные возйны, но все же скажу пару слов. IBM OS/2 — это доработка MS OS/2. Другими словами OS/2 разрабатывал МС.
Не так уж и долго MC разрабатывал OS/2. Уже OS/2 2.0 IBM доделывала без MC, а уж OS/2 3.0 и OS/2 4.0 были сделаны вообще без МС.
VD> Так вот в МС поняли, что OS/2 не является продуктом который требует рынок. Другими совами OS/2 не оптимальна для пользователя. Тогда МС начала разработку NT. NT оказался продуктом бескомпромисным, в отличии от OS/2 и намного более перспективным, но на то время NT была еще более неприемлема для пользователей. Тогда МС создала проект Чикаго (будующую Вынь 95). Его суть была скрещивание Windows 3.11 и Windows NT. Зазача быал — впихнуть максимум возможностей NT в ОС имеющюю намного меньшие потребности в ресустах и намного большую совместимось с 16-битным миром. Главное что пропихнул МС в Чикагу — это Win32 ATI. Конечно существовал Win32S, но в нем было реализовано уж очень мало нужных вещей. Причем и те что были реализованы — эмулировались. Второе по важности было введение изолированных адресных пространств. Для императивных языков того поколения это было очень важное нововведение. Дале шли многопоточность и красивый UI.
Так об этом я и говорил. Обе корпорации хотели сделать продукт следующего уровня для PC. Только MC отталкивалась от нужд пользователей и поэтому смогла привлечь к себе разработчиков ПО. А вот IBM, видимо, расчитывала на стройность архитектуры, но нужды пользователей были им фиолетовы. Уж не знаю как, но IBM не удалось привлечь разработчиков ПО. Может из-за того, что в Presentation Manager координаты откладывались от нижнего левого угла? Из-за этого мне было лично мне было геморройно Windows-код в PM портировать.
VD>Конечно последние версии ОС тоже реализовали многое из того что решали проекты NT и Чикаго, но: VD>1. В полном объеме все фишки появились слишком поздно. VD>2. Полуось была компромисом — не такая надежная как NT и не такая неприхотливая к ресурсам, и (что намного важнее) не такая совместимая с Windows 3.1 как Чикаго.
Не надо мне-то байки про ненадежность OS/2 рассказывать. Она падала только из-за кривых драйверов (как и NT). Ну и Watcom-овский отладчик пару раз у меня OS/2 повесил. Так что надежность Warp-а была ничуть не хуже NT.
E>> Ведь в каждом языке есть примитивные приемы для повышения/понижения производительности на элементарном уровне. Например, в C++ возврат сложных объектов или передача их в качестве аргументов по значению -- очень дорогая операция. Например, функция, которая получает по значению пяток std::string и возвращающая std::string может серьезно просадить производительность. Самый простой выход -- использовать std::string & или const std::string &.
VD>Извини, но это очередная бредятина про оптимизацию. В стандарте С++для std::string описывается только интерфейс. Реализация же может быть любая. Посему твоя оптимизация на некоторых библиотеках приведет к потере производительности (хотя и небольшой). Но главное она в очередной раз усложнит код.
ДА-А-А? Ну-ну. Примеры в студию, пожалуйста.
Но об этом в отдельном посте.
VD>Например, погляди как реализован CString в MFC. Сам объект содеражит только ссылку на динамически занимаемый блок памяти. Все остальное в этом блоке. Передача CString в качестве параметра и даже возврат его из функции — это самое верное решение как с точки зрения производительности, так и с точки зрения удобства использования.
И многопоточности, надо полагать.
... << RSDN@Home 1.1.4 stable rev. 510>>
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, FR, Вы писали:
FR>Да и графическую карту что будет на PS3 (nVidia RSX) чудом техники не назовешь, Nvidia говорит что она шустрее чем пара (через SLI) GeForce 6800 Ultra , а это значит что скорее всего уже следующим летом топовые карты на PC уже обгонят nVidia RSX.
Вроде как GeForce 7800 GTX уже быстрее двух ульр. От этого SLI толку почти нет. Вот может у ATI что выйдет. Хотя до Voodoo 2 SLI они вряд ли дотянут. Та почти удваивала скорость.
... << RSDN@Home 1.2.0 alpha rev. 618>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Кстати, на вопрос, почему я в примерах из своего проекта не использую string и т.д. ответ очень простой — проект делался на чистом С. Мне это активно не нравилось, но я вошел в проект, когда он уже существовал и изменить ничего не мог.
А причем тут проект? Речь шала о примерах на голом С под названием С++.
PD>А вот чего я не понимаю — почему некоторые упорно приписывают мне то, чего я не говорил ? Я говорю, что надо писать эффекктивно — мне отвечают "он призывает писать эффективно любой ценой". Я ничего вообще о дизайне и архитектуре не говорил — у меня, оказывается, натуральная борьба с абстракциями. Покажите мне место, где я призывал "любой ценой"
Глядя на примеры все становится ясно и без призывов. Достаточно объяснить, что строки в донтете сакс подкрепив примером в стиле С с буферами на стэке и все будет ясно.
... << RSDN@Home 1.2.0 alpha rev. 618>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Lloyd, Вы писали:
L>>Очень поучительная иллюстрация к тому, что по-байтово считывать из файла действительно не стиот.
L>2VladD2: Задам столь любимый тобою вопрос. А минус-то за что?
За повторение глупости.
... << RSDN@Home 1.2.0 alpha rev. 618>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
E>> Ведь в каждом языке есть примитивные приемы для повышения/понижения производительности на элементарном уровне. Например, в C++ возврат сложных объектов или передача их в качестве аргументов по значению -- очень дорогая операция. Например, функция, которая получает по значению пяток std::string и возвращающая std::string может серьезно просадить производительность. Самый простой выход -- использовать std::string & или const std::string &.
VD>Извини, но это очередная бредятина про оптимизацию. В стандарте С++для std::string описывается только интерфейс. Реализация же может быть любая.
Ок. Смотрим тесты производительности (тест программы в низу сообщения).
VD> Посему твоя оптимизация на некоторых библиотеках приведет к потере производительности (хотя и небольшой). Но главное она в очередной раз усложнит код.
E>> В подавляющем большинстве случаев это уже даст необходимый прирост производительности.
VD>Как раз в подавляющем большинстве случаев — это ничено не даст. Ну, кроме глупой самоуверенности тому кто это делает.
Итак, ты пытаешься утверждать что передача объекта по значению, с вызовом конструкторов и деструкторов в большинстве случаев будет настолько же эффективно, как передача ссылки на объект? Это только если конструктор и декструктор будут тривиальными, а объекты будут содержать не более одного атрибута.
Вообще Влад, ты в последнее время делаешь такие заявления, после которых я начинаю сомневаться, что ты вообще хорошо программировал на C++.
Тест производительности при передачи std::string в качестве аргументов и возвращаемого значения:
#include <iostream>
#include <string>
#include <ctime>
using namespace std;
const unsigned int iterations = 10000000;
template< class R, class T1, class T2, class T3 >
struct meter_t
{
typedef R (*pfn_t)( T1 a, T2 b, T3 c );
pfn_t m_pfn;
const std::string & m_a;
const std::string & m_b;
const std::string & m_c;
meter_t( pfn_t pfn,
const std::string & a,
const std::string & b,
const std::string & c )
: m_pfn( pfn )
, m_a( a )
, m_b( b )
, m_c( c )
{}
void
operator()( const std::string & method_name )
{
std::cout << method_name << " " << std::flush;
std::clock_t start = std::clock();
for( unsigned int i = 0; i != iterations; ++i )
(*m_pfn)( m_a, m_b, m_c );
std::clock_t finish = std::clock();
std::cout << "duration: "
<< double( finish - start ) / CLOCKS_PER_SEC
<< std::endl;
}
};
template< class R, class T1, class T2, class T3 >
meter_t< R, T1, T2, T3 >
meter( R (*pfn)( T1, T2, T3 ),
const std::string & a,
const std::string & b,
const std::string & c )
{
return meter_t< R, T1, T2, T3 >( pfn, a, b, c );
}
const std::string &
references_only(
const std::string & a,
const std::string & b,
const std::string & c )
{
return a;
}
std::string
refereces_args_value_return(
const std::string & a,
const std::string & b,
const std::string & c )
{
return a;
}
std::string
all_values(
std::string a,
std::string b,
std::string c )
{
return a;
}
int main()
{
const std::string a = "Long long time ago...";
const std::string b = "...in far far galaxy...";
const std::string c = "...test for std::string perfomance...";
meter( &references_only, a, b, c )( "references_only" );
meter( &refereces_args_value_return, a, b, c )( "refereces_args_value_return" );
meter( &all_values, a, b, c )( "all_values" );
}
... << RSDN@Home 1.1.4 stable rev. 510>>
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, eao197, Вы писали:
E>А чего тут подробнее? Я уже несколько раз об этом говорил. Ты привел в качестве примера свой опыт на тот момент, когда ты и программировать-то нормально не умел (по твоим же словам). А следовательно (для меня лично) -- грош цена этому опыту.
Опыт есть опыт. Просто бессмысленно его оценивать по тому чей это опыт. Да и не причем там умение программировать.
E>Да и ты сам сказал: E>
E>Вообще-то я говорил о другом. Я говорил, о том, что надо знать что делашь, и не делать ничего просто так.
E>Так вот, делая вторую или третью программу в своей жизни, сложно знать "что делаешь".
Об этом и говорилось в рассказе.
E>Ну об этом мы уже говорили.
Ага. Но бестолку.
E>Не так уж и долго MC разрабатывал OS/2. Уже OS/2 2.0 IBM доделывала без MC, а уж OS/2 3.0 и OS/2 4.0 были сделаны вообще без МС.
Да, да. Не долго. Ровно от начала и до момента когда МС понял бесперспективность ее развитя.
Короче МС ее создал. И этим все сказано.
VD>> Так вот в МС поняли, что OS/2 не является продуктом который требует рынок. Другими совами OS/2 не оптимальна для пользователя. Тогда МС начала разработку NT. NT оказался продуктом бескомпромисным, в отличии от OS/2 и намного более перспективным, но на то время NT была еще более неприемлема для пользователей. Тогда МС создала проект Чикаго (будующую Вынь 95). Его суть была скрещивание Windows 3.11 и Windows NT. Зазача быал — впихнуть максимум возможностей NT в ОС имеющюю намного меньшие потребности в ресустах и намного большую совместимось с 16-битным миром. Главное что пропихнул МС в Чикагу — это Win32 ATI. Конечно существовал Win32S, но в нем было реализовано уж очень мало нужных вещей. Причем и те что были реализованы — эмулировались. Второе по важности было введение изолированных адресных пространств. Для императивных языков того поколения это было очень важное нововведение. Дале шли многопоточность и красивый UI.
E>Так об этом я и говорил.
Нет. Ты говорил о том, что во всем виноват маркетинг. А он то тут как раз делом десятым был. Главное было разумность проектных решений.
E> Обе корпорации хотели сделать продукт следующего уровня для PC. Только MC отталкивалась от нужд пользователей и поэтому смогла привлечь к себе разработчиков ПО.
Это так.
E>А вот IBM, видимо, расчитывала на стройность архитектуры, но нужды пользователей были им фиолетовы.
А это не так. Небыло в Полуоси никакой стройности архитекруры. Полуось, как и Вынь95 была компромисом. Причем многопараметрическим. И в определении важности приоритетов IBM координально ошиблась.
E> Уж не знаю как, но IBM не удалось привлечь разработчиков ПО.
Ну, почему же? До появления 95-ых и NT очень многие разработчики перепрыгнули на Полуось. Причем некоторые так привязались к ней, что стали откровенными ее фанатами. Другое дело, что при наличии более привлекатльной ОС только фанатики ее и не бросили. ОС оказалась не интересной в первую очередь для пользователей. А уж для программистов было только неудобно что АПИ этой ОС сильно отличалось от Виндовс 3.х которая в то время держала рынок.
Кстати, что до быстро бросила, то я вспоминаю как году в 1994-ом я читал документацию по MS C 6 и море ее было посвящено разработке для Полуоси 1.х. А вот СДК для виндовс там небыло. Так что МС довольно долго смотрел на Полуось как на любимое детя.
E>Не надо мне-то байки про ненадежность OS/2 рассказывать. Она падала только из-за кривых драйверов (как и NT).
До некоторой версии она намертво зависала от банального метвого цикла. Даже вынь 3.1 можно было в таких случаях оживить, а Полуось — нет. В общем, снова фанатский спор. Надоело. Сравнивать NT 3.х и Полуось (особенно ранних версий) по надежности — это форменный фанатизм.
E> Ну и Watcom-овский отладчик пару раз у меня OS/2 повесил. Так что надежность Warp-а была ничуть не хуже NT.
Warp был тогда когда Полуось уже была практически на лопатках. Да и он не дотягивал до NT по надежности. Другое дело, что в NT 4 был сделан шаг назад. Но этот шаг делался в рассчете на то, что ОС завоюет хайэндный рынок где тогда нужна была быстрая 3D-крафика. В общем, очередной разумный компромис.
VD>>Извини, но это очередная бредятина про оптимизацию. В стандарте С++для std::string описывается только интерфейс. Реализация же может быть любая. Посему твоя оптимизация на некоторых библиотеках приведет к потере производительности (хотя и небольшой). Но главное она в очередной раз усложнит код.
E>ДА-А-А? Ну-ну. Примеры в студию, пожалуйста.
Примеры чего? Вот ты живой пример. Ты изучил исходники всех реализаций STL?
VD>>Например, погляди как реализован CString в MFC. Сам объект содеражит только ссылку на динамически занимаемый блок памяти. Все остальное в этом блоке. Передача CString в качестве параметра и даже возврат его из функции — это самое верное решение как с точки зрения производительности, так и с точки зрения удобства использования.
E>И многопоточности, надо полагать.
Давай еще про распределенные системы поговорим. Это тоже будет очень в тему.
... << RSDN@Home 1.2.0 alpha rev. 618>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, eao197, Вы писали:
E>Ок. Смотрим тесты производительности (тест программы в низу сообщения).
...
Здорово. Вот теперь ты можешь утверждать о протестированных версиях библиотеки, то что на них выигрышь есть.
E>Итак, ты пытаешься утверждать что передача объекта по значению, с вызовом конструкторов и деструкторов в большинстве случаев будет настолько же эффективно, как передача ссылки на объект? Это только если конструктор и декструктор будут тривиальными, а объекты будут содержать не более одного атрибута.
Нет. Я говорю, о том, что такие оптимизации как повсеместная передеча сторк по ссылке вряд ли приведет к заметному ускорению работы приложения. Хотя если это сделать в узких местах, то несомненно.
E>Вообще Влад, ты в последнее время делаешь такие заявления, после которых я начинаю сомневаться, что ты вообще хорошо программировал на C++.
А С++ тут не причем. Более того, я вообще не буду использовать std::string так как он попросту не удобен. Я говорю опять же о твоих предположениях.
E>Тест производительности при передачи std::string в качестве аргументов и возвращаемого значения:
...
Кстати, читается ужасно. Неужели по проще нельзя?
... << RSDN@Home 1.2.0 alpha rev. 618>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
E>>А вот IBM, видимо, расчитывала на стройность архитектуры, но нужды пользователей были им фиолетовы.
VD>А это не так. Небыло в Полуоси никакой стройности архитекруры. Полуось, как и Вынь95 была компромисом. Причем многопараметрическим. И в определении важности приоритетов IBM координально ошиблась.
Ты то откуда знаешь? Ты что, под OS/2 работал или программировал?
E>> Уж не знаю как, но IBM не удалось привлечь разработчиков ПО.
VD>Ну, почему же? До появления 95-ых и NT очень многие разработчики перепрыгнули на Полуось. Причем некоторые так привязались к ней, что стали откровенными ее фанатами. Другое дело, что при наличии более привлекатльной ОС только фанатики ее и не бросили. ОС оказалась не интересной в первую очередь для пользователей.
Потому, что софт под нее не разрабатывался.
VD> А уж для программистов было только неудобно что АПИ этой ОС сильно отличалось от Виндовс 3.х которая в то время держала рынок.
А вот это причина, по которой софт под OS/2 не разрабатывался. Да еще и потому, что MS лучше своих клиентов обхаживала. В частности, смогла заинтересовать производителей аппаратуры в первую очередь выпускать драйвера под Windows. Что в скором времени привело к тому, что OS/2 можно было заставить работать далеко не на всем железе.
VD>Кстати, что до быстро бросила, то я вспоминаю как году в 1994-ом я читал документацию по MS C 6 и море ее было посвящено разработке для Полуоси 1.х. А вот СДК для виндовс там небыло. Так что МС довольно долго смотрел на Полуось как на любимое детя.
E>>Не надо мне-то байки про ненадежность OS/2 рассказывать. Она падала только из-за кривых драйверов (как и NT).
VD>До некоторой версии она намертво зависала от банального метвого цикла.
До каких версий? Я с 3.0 начал под OS/2 работать и не было такого.
E>> Ну и Watcom-овский отладчик пару раз у меня OS/2 повесил. Так что надежность Warp-а была ничуть не хуже NT.
VD>Warp был тогда когда Полуось уже была практически на лопатках. Да и он не дотягивал до NT по надежности.
Вот только не надо. По ресурсоемкости Warp делал Windows (любой) только так (я помню как на 386 с 4Mb крутилась OS/2 Warp в TShell-е и свободно позволяла в первый Doom играть, и держать рядом несколько сессий с MultiEdit-ом). А надежность у него была на уровне NT.
VD>>>Извини, но это очередная бредятина про оптимизацию. В стандарте С++для std::string описывается только интерфейс. Реализация же может быть любая. Посему твоя оптимизация на некоторых библиотеках приведет к потере производительности (хотя и небольшой). Но главное она в очередной раз усложнит код.
E>>ДА-А-А? Ну-ну. Примеры в студию, пожалуйста.
VD>Примеры чего? Вот ты живой пример. Ты изучил исходники всех реализаций STL?
А причем здесь исходники? Об этом даже здавый смысл говорит: передача объекта по значению -- это вызов конструктора и деструктора. Если std::string сделан на основе подсчета ссылок, то конструктор должен сделать, по крайней мере, один инкремент. А деструктор -- один декремент. Даже если эти два действия заинлайнятся -- все равно это будет дольше, чем передать аргумент по ссылке.
... << RSDN@Home 1.1.4 stable rev. 510>>
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, VladD2, Вы писали:
E>>Ок. Смотрим тесты производительности (тест программы в низу сообщения). VD>...
VD>Здорово. Вот теперь ты можешь утверждать о протестированных версиях библиотеки, то что на них выигрышь есть.
Его просто не может не быть
Это почти как законы физики.
E>>Итак, ты пытаешься утверждать что передача объекта по значению, с вызовом конструкторов и деструкторов в большинстве случаев будет настолько же эффективно, как передача ссылки на объект? Это только если конструктор и декструктор будут тривиальными, а объекты будут содержать не более одного атрибута.
VD>Нет. Я говорю, о том, что такие оптимизации как повсеместная передеча сторк по ссылке вряд ли приведет к заметному ускорению работы приложения. Хотя если это сделать в узких местах, то несомненно.
Приведет обязательно. Доказано практикой.
E>>Тест производительности при передачи std::string в качестве аргументов и возвращаемого значения: VD>... VD>Кстати, читается ужасно. Неужели по проще нельзя?
Куда же проще? Один обобщенный класс для замера производительности и три тестируемых функции.
Не сложнее твоего примера: Re[25]: Об эффективности программ
Здравствуйте, eao197, Вы писали:
E>Ты то откуда знаешь? Ты что, под OS/2 работал или программировал?
А как же! Ты меня уже совсем за мальчика держишь.
E>Потому, что софт под нее не разрабатывался.
Да его в то время и под виндвос не дофига разрабатывалось. Софт для бизнеса жил под ДОС.
Кстати, мы думали писать код для полуоси, но воврмемя спохватились и передумали.
E>А вот это причина, по которой софт под OS/2 не разрабатывался.
Вряд ли. Если бы был рынок, то и разработки были бы.
E> Да еще и потому, что MS лучше своих клиентов обхаживала. В частности, смогла заинтересовать производителей аппаратуры в первую очередь выпускать драйвера под Windows. Что в скором времени привело к тому, что OS/2 можно было заставить работать далеко не на всем железе.
Хм. Что-то ты путашь. Драйверы под Windows были практически не нужны. Windows спокойно использовала ДОС-овские дрова (причем даже 95-ая). Это, кстати, и привело к тому, что на Windows перепрыгнуло много народа. У Полуоси с этим были большие проблемы. Родные дрова под Windows стали появляться ближе к 1995-му году и это явилось следствием признания ОС пользователями.
Кстати, многие до сих пор не считают Windows 3.х ОС. Типа оболочка над ДОС. Типа убогость. А ведь это позволило завоевать рынок.
E>До каких версий? Я с 3.0 начал под OS/2 работать и не было такого.
От это не помню. В Вынь вс. Линь ссылка была, но перерывать это барахло я не стану. Но что зависала я точно помню. Сам ее вешал. А ведь даже для 95-ых это пустяк.
VD>>Warp был тогда когда Полуось уже была практически на лопатках. Да и он не дотягивал до NT по надежности.
E>Вот только не надо. По ресурсоемкости Warp делал Windows (любой) только так (я помню как на 386 с 4Mb крутилась OS/2 Warp в TShell-е и свободно позволяла в первый Doom играть, и держать рядом несколько сессий с MultiEdit-ом). А надежность у него была на уровне NT.
Хм... Странно ты отвечашь. Я про надежность, ты про ресурсоемкость.
Ну, да и ресурсоемкость чистая не правда. Windows 3.1 жила на 2-х метрах памяти. 3.0 вообще на 640 Кб. Windows 95 жила на 4 метрах (я даже умудрился из под нее Дум 2 запустить, а ведь он сам 4 метра требовал), а на 8 просто летала с несколькими приложениями и сетью. Полуось, даже 2.х в 8 метрах только начинала работать. Запуст Windows из под Полуоси уже приводил к проблемам на 8 метрах. А для 95-ых 16-ти бытные приложения были как родные.
8 же метов по тем временам была нехилая цифра. Ну, а когда память подешевела, то 95-ые уже захватили рынок, да и NT начала пробивать себе дорогу. Все же NT тоже жила на 8 метрах, а на 16 уже даже неплохо себя чувствовала.
VD>>Примеры чего? Вот ты живой пример. Ты изучил исходники всех реализаций STL?
E>А причем здесь исходники?
При том что это завист от реализации.
E> Об этом даже здавый смысл говорит: передача объекта по значению -- это вызов конструктора и деструктора.
Вот только не надо апеллировать к зравому смыслу. Я как раз вижу его отсуствие в подобных рассуждениях. Объекты объектам рознь. Я уже приводил пример CString который только проигрывает при передаче по ссылке.
E> Если std::string сделан на основе подсчета ссылок, то конструктор должен сделать, по крайней мере, один инкремент. А деструктор -- один декремент. Даже если эти два действия заинлайнятся -- все равно это будет дольше, чем передать аргумент по ссылке.
Это ловля блох. Бестолку так рассуждать. Ты поймашь 1000 совершенно не важных для производительности приложения мест с микро-тормозами, но действительно слабые места не заметишь.
Если бы использование std::string могло что-то дать по сравнению с CString, то никто последним бы не пользовался бы.
... << RSDN@Home 1.2.0 alpha rev. 618>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Nickolay Ch, Вы писали:
NC>А все от того, что образование просто не поспевает за темпами развития отрасли. Ну не век сейчас процессоров, "в которые можно войти".
Дык вот тот же Dvorkin вроде как даже пытается новое изучить. Но вот получается чистешая онтипатия, так как притят сами приципы заложенные в основу платформы. Как может показаться интересным новое если оно отвергает такие принципы как реинтерпретация памити, возню с указателями, а в добавок еще и навязывает абстрации и ОО-стиль программирования?
NC>ЗЫ Сорри за офтоп, можем отдельно обсудить проблемы преподавания программирования в российских вузах, вроде даже обсуждалось уже..
Вроде уже пробовали. Количество мнений было вообще необозримым.
... << RSDN@Home 1.2.0 alpha rev. 618>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
E>>Куда же проще? Один обобщенный класс для замера производительности и три тестируемых функции.
VD>Да уж. Больше некуда. Хотя main() вроде так ничего читается.
VD>Кстати, зачем вообще понадобился обобщенный класс для замера производительности? Чем банальные вызовы функциий провинилис?
Последствия copy-paste. Я этот тест не с нуля делал, а взял готовый, в котором этот functor уже был.
... << RSDN@Home 1.1.4 stable rev. 510>>
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Спасибо за внезапную holy war OS/2 vs Windows
Хоть каждый и остался при своем мнении, но вспомнить молодость было приятно.
E>> Об этом даже здавый смысл говорит: передача объекта по значению -- это вызов конструктора и деструктора.
VD>Вот только не надо апеллировать к зравому смыслу. Я как раз вижу его отсуствие в подобных рассуждениях. Объекты объектам рознь. Я уже приводил пример CString который только проигрывает при передаче по ссылке.
А ты уверен, что CString проигрывает от передачи по ссылке?
Все-таки со здравым смыслом спорить сложно. Да и вряд ли полезно.
Кроме того, я не зря вначале говорил про многопоточность. Реализации std::string, основанные на подсчете ссылок и copy on write, в многопоточных приложениях имеют скрытый оверхед: скопированная в другую нить строка при первом обращении к ней на изменение будет останавливать нить для синхронизации с исходной строкой. Поэтому reference counting реализации дают выигрыш при копировании, но проигрывают его обратно при изменении строки.
E>> Если std::string сделан на основе подсчета ссылок, то конструктор должен сделать, по крайней мере, один инкремент. А деструктор -- один декремент. Даже если эти два действия заинлайнятся -- все равно это будет дольше, чем передать аргумент по ссылке.
VD>Это ловля блох. Бестолку так рассуждать. Ты поймашь 1000 совершенно не важных для производительности приложения мест с микро-тормозами, но действительно слабые места не заметишь.
Вот здесь у меня другое мнение. 1000 мест, каждое из которых дает проигрыш 0.002% (малая величина, не так ли), в сумме дадут 2% прироста производительности. За просто так заметь.
Ну и обрати внимание на разрыв в тестах между references_only и all_values. Разница в 26 раз для тебя кажется мелочью?
VD>Если бы использование std::string могло что-то дать по сравнению с CString, то никто последним бы не пользовался бы.
А я CString и не пользуюсь. Им пользуются только те, кто был вынужден на MFC/ATL/WTC под Windows программировать.
Текст программы для измерения оверхеда при передаче CString.
#include"stdafx.h"#include <iostream>
#include <string>
#include <ctime>
using namespace std;
const unsigned int iterations = 10000000;
template< class R, class T1, class T2, class T3 >
void
meter(
const std::string & method_name,
R (*pfn)( T1, T2, T3 ),
const CString & a,
const CString & b,
const CString & c )
{
std::cout << method_name << " " << std::flush;
std::clock_t start = std::clock();
for( unsigned int i = 0; i != iterations; ++i )
(*pfn)( a, b, c );
std::clock_t finish = std::clock();
std::cout << "duration: "
<< double( finish - start ) / CLOCKS_PER_SEC
<< std::endl;
}
const CString &
references_only(
const CString & a,
const CString & b,
const CString & c )
{
return a;
}
CString
refereces_args_value_return(
const CString & a,
const CString & b,
const CString & c )
{
return a;
}
CString
all_values(
CString a,
CString b,
CString c )
{
return a;
}
int main()
{
const CString a = "Long long time ago...";
const CString b = "...in far far galaxy...";
const CString c = "...test for std::string perfomance...";
meter( "references_only", &references_only, a, b, c );
meter( "refereces_args_value_return", &refereces_args_value_return, a, b, c );
meter( "all_values", &all_values, a, b, c );
}
... << RSDN@Home 1.1.4 stable rev. 510>>
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
VD>Да, я скорее не неуважительно. Я скорее раздражительно. Возможно я тут не прав и перегибаю плаку. Однако я искренне считаю, что такая безрассудная борьба за производительность исходящая от преподавателя крайне деструктивно скажется на его учениках. Свобода слова и свобода после слова несомненно незыблема. Но это до тех пор пока речь идет о твоем личном мнении. Как только ты начинашь учить других, то твое мнение превращается в инструмент воспитания. Ведь ты отвественнен за то что будет в головах твоих учеников. И если неподготовленные головы пропаласкать вот такими залихватскими речами о производительности, то практически гарантированно можно получить людей которые просто не в состоянии будут понять, что такое грамотное проектирование, так как их учитель им обяснил, что словами о грамотном проектировании обычно прикрывают неумение и не желание писать оптимальный код. Ну, а если это еще смазать твоими рассуждениями об индусах... Кому же хочется быть поставленным в один ряд с индусами?
Вот за это жирный плюс.
ЗЫ. Опыт — очень абстрактная и расплывчатая категория. Опыт опыту рознь.
В данной тематике актуален конкретно программерский опыт(а технологии меняются очень динамично).
Не общежизненный(кстати, и в такой не верю).
Здравствуйте, Nickolay Ch, Вы писали:
NC>Мне ни в этой, ни в соседнем треде так и не дали четокго ответа на вопрос: "ради чего проводить битовыжимание, изобретать велосипеды, отказываться от удобных механизмов и библиотек". По крайней мере, внятного ответа не услышал.
Ради того, чтобы программа работала в заданных условиях. Например, SIM Toolkit апплет должен умещаться в 16Kb SIM карточку. Правильная, полностью функциональная версия занимает 19Kb. Нужно как-то "похудеть" апплет на 3Kb.
Такой пример подойдет?
... << RSDN@Home 1.1.4 stable rev. 510>>
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, eao197, Вы писали:
E>Здравствуйте, VladD2, Вы писали:
E>Спасибо за внезапную holy war OS/2 vs Windows E>Хоть каждый и остался при своем мнении, но вспомнить молодость было приятно.
Это тебе спасибо ты же ее к ночи упомянул.
E>А ты уверен, что CString проигрывает от передачи по ссылке?
Нет. С одной стороны лишняя косвенность, с другой там ведь подсчет ссылок. Тут нужно тестировать. Хотя уверен, что влияние будет мизерным.
E>
Вообще, логично. Там же все же вызывается конструктор/деструктор. Действительно тут ты прав, для С++, передача некоторых объектов по значению может быть медленее. Хотя опять таки есть POD-ы, да и инлайнинг иногда рулит. В твоме тесте инлайнинга быть не может (указатель на функцию как ни как).
А, например, разные POINT-ы передавать по ссылке только время терять.
E>Кроме того, я не зря вначале говорил про многопоточность. Реализации std::string, основанные на подсчете ссылок и copy on write, в многопоточных приложениях имеют скрытый оверхед: скопированная в другую нить строка при первом обращении к ней на изменение будет останавливать нить для синхронизации с исходной строкой. Поэтому reference counting реализации дают выигрыш при копировании, но проигрывают его обратно при изменении строки.
Ерунду говоришь. Скопированная строка есть скопированная строка. А если ты ее без копирования передашь (по ссылке), то в любом случае потребуется синхронизация. Так что разница тут только в семантике копирования.
Создание глобальных строк вообще не разумный выход в многопоточном приложении. А в рамках потока проблем сней не будет.
Для многопоточности конечно хорошо прменять имьютебл-кобъекты, но в С++ с ними беда. За пару секунд можно плучить ссылку и делать все что хочешь.
E>Вот здесь у меня другое мнение. 1000 мест, каждое из которых дает проигрыш 0.002% (малая величина, не так ли),
Величина высосаная из пальца. Не так ли?
E> в сумме дадут 2% прироста производительности. За просто так заметь.
Только к пакетным приложениям применима матрика "общая производительность". Для всех остальных она смысла не имеет. Для них унжно говорить о пиковой производительности в узких местах. Все твои 2, и даже 22 процента ровном счетом ничего не будут значит.
Простой пример, если я пишут дрэг-дроп для некого контрола, то мне совершенно все равно сколь эффектинво я работаю со стороками. Ведь я обрабатываю мизерное их число. Время же у меня регламентируется очщущениями пользовтеля. Человек ощущает тормоза когда не чувствует отклика в диапазоне 0.3 секунды. Эта цифра может варьироваться от 0.1 до 0.5 в завимимости от тормознутости пользователя и инерции девайсов которые он использует. Так вот все что успевает произойти в эти 0.1-0.3 секунды для человека выглядит как просходящее мгновенно. И я тебе гарантирую, что десяток переданных по значению строк ни на что ровным счетом не повлияют.
Повлиять же неэффектиная передача объектов может только при одном условии. Если эта передача делается очень большое количество раз в узком мете приложения. Вывод — нужно обращать внимание именно на узкие места.
Собственно вот мы опять пришли к выводу, что контролировать нужно не все приложение, а только его узкие места.
E>Ну и обрати внимание на разрыв в тестах между references_only и all_values. Разница в 26 раз для тебя кажется мелочью?
Кажется. В узких местах конечно такого допускать нельзя. Но вот в каком-нибудь MessageBox и т.п. без проблем. Это ровны счетом ничему не повредит.
VD>>Если бы использование std::string могло что-то дать по сравнению с CString, то никто последним бы не пользовался бы.
E>А я CString и не пользуюсь. Им пользуются только те, кто был вынужден на MFC/ATL/WTC под Windows программировать.
Что значит "был вынужден"? MFC/ATL — это библиотеки нехило упрощающие разработку приложений под Виндвос. Тот же CString намного удобнее уродца из СТЛ. Это как раз его скорее используют по нужде.
ЗЫ
Погляди на свой тест. На 10 000 000 итераций (по буквам — десять миллионов итераций!) на моей машине уходит в худшем случае 1.5 секунды, т.е. 1500 милесекунд. То есть стоимость одного вызова == 0.00015 милисекунды, или 0.15 микросекунды. Из них 0.03 микросекунды уходит на сам вызовов, и только 1.2 на передачу 3-х параметров и возврат еще одного значения.
Вот исходя из этих данных и можно строить предполжения где и когда стоимость передачи параметров может оказать заметное влияние на производительность. Не думаю, что столь малые велечины могут оказать серьезное влиятие на производительность.
Так что передавать строковый класс по константной ссылке явно полезно, но вероятность того, что это приведет к серьезному увеличению производительности всегоп риложения я бы оценил скепрически. Конечно если это, например, компилятор, или парсер ХМЛ-я, то безусловно он значительно ускорится. Но если это, например, десктоп прилоежине, то это скорее всего ничего не даст.
... << RSDN@Home 1.2.0 alpha rev. 618>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, FR, Вы писали:
FR>Вы тоже перегибаете палку с заявлениями о ненужности оптимизации, пока еще (и это пока продлится похоже неопределенно долго) полно задач в которых битовыжимание необходимо. А красивая архитектура и оптимизация не антиподы, очень часто это вещи совершенно независимые.
Цитату, пожалуйста, где бы говорилось о том, что оптимизации вообще ненужны.
... << RSDN@Home 1.2.0 alpha rev. 618>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
E>>Ради того, чтобы программа работала в заданных условиях. Например, SIM Toolkit апплет должен умещаться в 16Kb SIM карточку. Правильная, полностью функциональная версия занимает 19Kb. Нужно как-то "похудеть" апплет на 3Kb.
E>>Такой пример подойдет?
VD>Нет. Ты опять обобщашь частный случай. Никто не спорит, что если в очень окраниченные ресурсы нужно вжать довольно функциональную программу, то прийдется экономить на всем. Но это уже является частью спецификации ПО. И это нормально. Хотя опять таки есть варианты. Ведь, например, можно сменить железку и как следствие выпустить продукт на рынок раньше.
Я как раз не обобщал, а один пример привел. Мог бы еще парочку.
А на счет сменить железку, то есть области, где сменить железку можно будет лишь через 2-3 года. Вот сейчас, например, мобильные операторы начинают закупать карты 64K, но хотят туда загнать как можно больше апплетов, поэтому в распоряжении одного апплета все равно остается очень ограниченный объем памяти.
... << RSDN@Home 1.1.4 stable rev. 510>>
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
AVK>Остановится рост мощностей, начнут вылизывать существующий софт.
Согласен, а кто вылизывать будет?
AVK>Тем не менее разница между теперешними моделями и моделями пускай 5-тилетней давности в этом плане ничтожна. Индустрия автопрома точно так же высасывает деньги из покупателей, только у них приемы другие — продать то же самое в новой, более модной обертке. С технической точки зрения мода на дизайн, заставляющая производителей чуть ли не каждый год менять модельную линейку является форменным идиотизмом. В IT выхлоп от прогресса все таки поощутимее (и, кстати, именно он дал возможность автопрому хоть как то улучшить функционал и надежность).
V>>Но ведь это не удивительно, над новой моделью работаюбт сотни инженеров. А у нас, у программистов, примерно 5-15 человек делают проекты, по информационной сложности мало уступающие проекту той же Тойты.
AVK>Боюсь, не просто не уступающими, но и значительно превосходящими.
Да нет, сейчас там довольно сложная электроника, + незабывай миллион расчетов на каждый чих, так что вряд ли превосходящими.
V>>Я бы не стриг всех под одну гребенку. К счастью, в крайности бросаются не многие. А что касается текущего положения дел, то на само понятие "эффективности" молодое поколение просто забило. Влад, даже ты пишешь свои программы более менее эффективно (сужу по публикуемым кускам). Ты по другому не можешь, хоть и озвучиваешь другую точку зрения. (гы-гы, кстати). А у нового поколения — ни стыда ни совести по отношению к ресурсам аппаратуры или сети.
AVK>Я почему то вижу прямо обратное. Если человек пишетоткровенно тормозной код на ровном месте, то обычно у него без этого масса проблем. Такого чтобы человек превосходно проектировал и писал код без багов, но при этом не умел оптимизировать по производительности я еще ни разу не встречал. Так не воюете ли вы с ветряными мельницами?
МЫ???
Как в том отрыывке из "Есенина" — "пишу как дышу", по-другому не умею. Пальцы уже сами помнят как им надо поступать в сотнях различных ситуаций в коде. Ловлю себя часто на том, что практически не думаю во время кодирования
Просто не могу могу вспомнить, чтобы какие-либо оптимизации отняли у меня хоть раз прилично времени или сил. У меня ни разу не было истории, наподобие описанной Владом. Я никогда не переписывал или дорабатывал свои программы по соображениям лишь быстродействия. Если требуется некое быстродействие — то оно либо требуется вначале, либо не требуется. А если выясняется задним числом, что все-таки требовалось быстродействие, а система не удовлетворяет, то это признак неопытности, либо банальной небрежности подхода к разработке (скорее второе, ибо выпускник ВУЗа все-таки уже инженер, и уже многое знает и умеет).
Я вышел из электронщиков и долгое время имел привычку расчитывать параметры будущих систем. Макетировал основные кусочки, замерял, просчитывал, моделировал. В обработке сигналов (чем занимался долго) по другому просто ничего не работало на той технике (embedded в т.ч.). Все это, на самом деле, стоит не дорого на начальных этапах разработки. Гораздо дороже обходятся переделки архитектуры, связанные с неудовлитворительным быстродействием. Как правило намного дороже переделок, связанных с уточнением функциональных требований.
AVK>Из этого можно сделать ровно один вывод — серебряных пуль не быват. О вреде паттернов это не говорит никоим образом. Влад вон тоже в свое время активно был против них и считал их костылями для ламеров. Однако ж стоило попробовать и ...
Сами эти паттерны весьма специфичны, кстати. Большинство из них расчитано на представление о ООП, требующем БИНАРНУЮ совместимость, типа как в Java, С++, Дельфи, C#, которая достигается через интерфейсную развязку. Больше половины паттернов просто не нужны на ООП-языках с динамической типизацией или диспецерезацией в духе VBA. Всякие бриджы и итераторы — из этой области.
AVK>Вобще, как это не странно, паттерны это не столько что то новое собственно в готовых проектных решениях, сколько очень удобный инструмент обучения и коммуникаций. К примеру, решение, описанное в терминах паттернов, выглядит заметно короче и понятнее, чем если без них, ибо стандартные паттерны это суть алфавит проектировщика.
Паттерны — это практически самый нижный, 0-й уровень проектирования, за которым зачастую идет собственно кодирование. Прикол в том, что подробности архитектуры на этом уровне уже мало кого интересуют, ибо это уровень имплементации. Для библиотеки — это важно, да, это — самоцель. Для функциональных требований бизнес-системы — нет. Именно про этих уродцев я и говорил. И подмечал, что знание паттернов ничуть не помогает в разработке архитектуры.
Я говорил о том, что проектирование надо вести от анализа требований, а не от попытки наложить знакомые паттерны на эти самые требования. Они часто просто не ложатся, ибо работают совсем в другой области, в области реализации той самой архитектуры.
------------
Насчет знаний паттернов. Когда читал эту книгу в 2000-м, долго смеялся. Я ожидал чего-то необычного, какого-то откровения (ибо был уже наслышан, и некоторые отзывались воссоржено). А увидел кучу знакомых ситуаций. (Интерпретатор у них поверхностный, правда, и вовсе не к месту там)
Где что видно? И почему я себя адекватно оценивать не могу? Ничего не понимаю. Кто-то из нас действительно не совсем адекватен.
КДВ>>но вот какое дело. Ты модератор, а это по идее должно накладывать на человека определенную ответственность. Не так ли? Я не в коей мере не пытаюсь мораль читать, просто когда в форуме один из самых больших спорщиков модератор — то даже читать тяжко бывает становится. И никто урезонить тебя иногда не может. Худо.
VD>Возможно, возможно... Но вот все же здесь спорить все же можно. А вот в С++ с этим совсем никак. Там плохое слово о С++ табу, офтоп и вообще с прлюрализмом там не зашибись.
Спорить — да сколько угодно. Просто не все человеки спорить умеют. Некоторые за кирпичи хватаются и т.д. и т.п. (я сам такой бываю). Вот и нужны модераторы для того, чтобы народ по сторонам разводить иногда. Понимаешь, о чем я?
В общем того, я особо переписываться на эту тему не хочу, но со стороны видно, что форуму нужен другой модератор. Просто который меньше спорит сам. Вот и вся мораль.
P.S. Влад, ничего личного, извини, что я так это прямо говорю.
Здравствуйте, Кузнецов Денис Викторович, Вы писали:
КДВ>Где что видно? И почему я себя адекватно оценивать не могу? Ничего не понимаю. Кто-то из нас действительно не совсем адекватен.
Не принимай близко к сердцу. Это скорее всего не к тебе относилось, а к одному твоему однофамильцу
... << RSDN@Home 1.2.0 alpha rev. 0>>
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, IT, Вы писали:
IT>Здравствуйте, Кузнецов Денис Викторович, Вы писали:
КДВ>>Где что видно? И почему я себя адекватно оценивать не могу? Ничего не понимаю. Кто-то из нас действительно не совсем адекватен.
IT>Не принимай близко к сердцу. Это скорее всего не к тебе относилось, а к одному твоему однофамильцу
что ты, наоборот, я ж именно однофамильцами и богат ))
Здравствуйте, IT, Вы писали:
IT>Здравствуйте, FR, Вы писали:
FR>>Вы тоже перегибаете палку с заявлениями о ненужности оптимизации...
IT>Блин, народ, ну вы как маленькие студебеккеры. Сколько можно уже об этом говорить
? Оптимизацией нужно заниматься тогда и только тогда, когда это часть non-functional requirements. В противном случае линейкой по рукам.
Я думаю бесполезно дальше говорить на эту тему, просто если бы ты почитал чуть выше, то понял бы что я писал именно про случай когда быстродействие (а не оптимизация) это основное требование. И если у вас нет подобных задач это не повод все выстраивать только на своем опыте.
Здравствуйте, vdimas, Вы писали:
AVK>>Остановится рост мощностей, начнут вылизывать существующий софт.
V>Согласен, а кто вылизывать будет?
Найдется кому, не переживай.
AVK>>Боюсь, не просто не уступающими, но и значительно превосходящими.
V>Да нет, сейчас там довольно сложная электроника,
Которая разрабатывается в полном соответствии с традициями IT отрасли, которые здесь так ругают . И, кстати, совсем не инженерами Тойоты.
V> + незабывай миллион расчетов на каждый чих, так что вряд ли превосходящими.
Расчеты == юнит-тесты. Коих может быть очень много и для софта.
V>Просто не могу могу вспомнить, чтобы какие-либо оптимизации отняли у меня хоть раз прилично времени или сил. У меня ни разу не было истории, наподобие описанной Владом. Я никогда не переписывал или дорабатывал свои программы по соображениям лишь быстродействия.
, ты бы догадался сразу?
V>Сами эти паттерны весьма специфичны, кстати.
Эти это которые?
V> Большинство из них расчитано на представление о ООП, требующем БИНАРНУЮ совместимость, типа как в Java, С++, Дельфи, C#, которая достигается через интерфейсную развязку. Больше половины паттернов просто не нужны на ООП-языках с динамической типизацией или диспецерезацией в духе VBA. Всякие бриджы и итераторы — из этой области.
Ну и отлично. Там свои паттерны. В чем проблема то?
V>Паттерны — это практически самый нижный, 0-й уровень проектирования
Паттерны, они разные бывают. В GoF вожможно они довольно простые. Там цель такая стояла. А есть например общеизвесный MVC, который может применяться и на низком уровне и на очень высоком. Или можешь посмотреть на Microsoft Pattern&Practice, там паттерны тоже по большей части довольно высокоуровневые.
V>, за которым зачастую идет собственно кодирование. Прикол в том, что подробности архитектуры на этом уровне уже мало кого интересуют, ибо это уровень имплементации.
Тебя не интересуют, а меня интересуют. Хотя бы потому что вместо разговора сунь туда, вынь это, я могу просто сказать — здесь нужно применить визитор. Паттерны GoF это азбука проектирования.
V> Для библиотеки — это важно, да, это — самоцель. Для функциональных требований бизнес-системы — нет. Именно про этих уродцев я и говорил. И подмечал, что знание паттернов ничуть не помогает в разработке архитектуры.
Аргументы?
V>Я говорил о том, что проектирование надо вести от анализа требований, а не от попытки наложить знакомые паттерны на эти самые требования.
Прежде чем бегать надо научиться ходить.
V>------------ V>Насчет знаний паттернов. Когда читал эту книгу в 2000-м, долго смеялся. Я ожидал чего-то необычного, какого-то откровения (ибо был уже наслышан, и некоторые отзывались воссоржено). А увидел кучу знакомых ситуаций. (Интерпретатор у них поверхностный, правда, и вовсе не к месту там)
А если бы ты еще прочел введение, в котором написано с какой целью книжка создавалась ... И еще раз напомню — паттерны это отнюдь не только GoF.
Здравствуйте, eao197, Вы писали:
E>Здравствуйте, Nickolay Ch, Вы писали:
NC>>Мне ни в этой, ни в соседнем треде так и не дали четокго ответа на вопрос: "ради чего проводить битовыжимание, изобретать велосипеды, отказываться от удобных механизмов и библиотек". По крайней мере, внятного ответа не услышал.
E>Ради того, чтобы программа работала в заданных условиях. Например, SIM Toolkit апплет должен умещаться в 16Kb SIM карточку. Правильная, полностью функциональная версия занимает 19Kb. Нужно как-то "похудеть" апплет на 3Kb.
E>Такой пример подойдет?
Очень подойдет, если стоит такая задача. За которую будет соответствующе заплачено
Лозунги же, кидаемые тут, претендуют(или смахивают) на абсолютные истины. Уже писал, что идем от задачи....
FR>Вы тоже перегибаете палку с заявлениями о ненужности оптимизации, пока еще (и это пока продлится похоже неопределенно долго) полно задач в которых битовыжимание необходимо. А красивая архитектура и оптимизация не антиподы, очень часто это вещи совершенно независимые.
Я никогда не говорил "о ненужности" оптимизации. Я говорил, что оптимизировать надо по необходимости каждом конкретном случае, и четко понимать, что это дает.
Здравствуйте, Nickolay Ch, Вы писали:
E>>Ради того, чтобы программа работала в заданных условиях. Например, SIM Toolkit апплет должен умещаться в 16Kb SIM карточку. Правильная, полностью функциональная версия занимает 19Kb. Нужно как-то "похудеть" апплет на 3Kb.
E>>Такой пример подойдет?
NC>Очень подойдет, если стоит такая задача.
Стоит.
NC> За которую будет соответствующе заплачено
Платят.
NC>Лозунги же, кидаемые тут, претендуют(или смахивают) на абсолютные истины. Уже писал, что идем от задачи....
Да здесь уже сама суть спора давно забылась. "Когда споры кипят, истина испаряется" ((С) народная мудрость).
... << RSDN@Home 1.1.4 stable rev. 510>>
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, eao197, Вы писали:
E>В server-side приложениях, которые обрабатывают сотни тысяч (всего лишь) транзакций в сутки эта величина легко достигается только лишь одной подсистемой логирования.
Сотри тысяч? Гы-гы. Делим 100 000 на 24 == 4166. Делим еще на 60 == 70. Делим еще на 60 получается по транзацкии в секунду. Вспоминмаем что дает один вызов — 0.15 микросекнуд. То есть чтобы заметно затормозить сервер нам потребуется вызвать таую функцию в цигле ни как не менее 100 000 раз. Думашь это реальный сценарий?
А ведь сервер с сотнями тысяч транзаций — это скорее всего мрогопроцессорный сервер.
E>За десктом не скажу, давно уже не писал. А вот то, что не POD-объекты (да и большие POD-объекты так же) нужно передавать по ссылке -- об этом нужно учить C++ программистов с детства.
Большие само собой. Но есть же и POD-ы размером с указатель? Учитывая еще архитектуру процессора вряд ли разбросннаые по всему приложению обхекты дадут ускорение. Пара промахов в кэше и ты получишь такой кайф от своих укзателей...
... << RSDN@Home 1.2.0 alpha rev. 618>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, vdimas, Вы писали:
V>На самом деле уже существуют вполне себе корректно составленные правила хорошего тона по кодированию на разных языках. Прямо в MSDN можно найти советы по VB, VB.Net, C#, C++. И не надо самому набираться опыта, претендующий на роль программиста на выбранном языке должен их просто изучить и понять (если сам еще не дошел своим опытом).
Несоменно, но я не уверен что это надо воспринимать как оптимизацию.
... << RSDN@Home 1.2.0 alpha rev. 618>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
? Оптимизацией нужно заниматься тогда и только тогда, когда это часть non-functional requirements. В противном случае линейкой по рукам.
FR>Я думаю бесполезно дальше говорить на эту тему, просто если бы ты почитал чуть выше, то понял бы что я писал именно про случай когда быстродействие (а не оптимизация) это основное требование.
Т.е. это non-functional requirements?
FR>И если у вас нет подобных задач это не повод все выстраивать только на своем опыте.
Ok. Для особо одарённых придётся перевести термин. Nonfunctional requirements — это требования к системе, определяющие не её функциональность и поведение, а её такие свойства как надёжность, расширяемость, нагрузку, стоимость и в том числе быстродействие.
... << RSDN@Home 1.2.0 alpha rev. 0>>
Если нам не помогут, то мы тоже никого не пощадим.
IT>Ok. Для особо одарённых придётся перевести термин. Nonfunctional requirements — это требования к системе, определяющие не её функциональность и поведение, а её такие свойства как надёжность, расширяемость, нагрузку, стоимость и в том числе быстродействие.
Для шибко умных, тут трудно различить нефункциональные это требования или нет, если игра идет с 10 fps инграть в нее невозможно.
Здравствуйте, FR, Вы писали:
FR>Здравствуйте, IT, Вы писали:
IT>>Ok. Для особо одарённых придётся перевести термин. Nonfunctional requirements — это требования к системе, определяющие не её функциональность и поведение, а её такие свойства как надёжность, расширяемость, нагрузку, стоимость и в том числе быстродействие.
FR>Для шибко умных, тут трудно различить нефункциональные это требования или нет, если игра идет с 10 fps инграть в нее невозможно.
Да но для начала нужно определиться что именно у тебя должно идти быстрее чем с 10 fps. Это и будут функциональные требования.
Здравствуйте, FR, Вы писали:
FR>Нет не Ok есть ситуации в которых если следовать по порядку Владовым рекомендациям просто придется выбросить то что уже сделал и написать все по новой.
Кстати, интересно. Что может вызвать ситуацию, когда другого решения не избежать? (т.е. выбросить все и переписать заново ради оптимизации — это единственный путь)
Радикально неправильный выбор используемых средств исключим (не та база данных, не тот сервер приложений и т.п.).
У кого такие случаи бывали?
Здравствуйте, eao197, Вы писали:
E>Таких POD типов не так уж мало. Два поля типа int в C-шной структуре и все -- POD тип в два раза больше указателя получается. Даже если POD структура всего из нескольких char-ов, то ты, имхо, можешь потерять производительность на некоторых типах процессоров, для которых важно выравнивание при обращении к памяти. А если при вызове функции ты передаешь ссылку на локальный объект, созданный на стеке, то промахнуться мимо кэша будет гораздо сложнее, чем при передаче указателя на размещенный в хипе объект.
Здравствуйте, _Winnie, Вы писали:
E>>Таких POD типов не так уж мало. Два поля типа int в C-шной структуре и все -- POD тип в два раза больше указателя получается. Даже если POD структура всего из нескольких char-ов, то ты, имхо, можешь потерять производительность на некоторых типах процессоров, для которых важно выравнивание при обращении к памяти. А если при вызове функции ты передаешь ссылку на локальный объект, созданный на стеке, то промахнуться мимо кэша будет гораздо сложнее, чем при передаче указателя на размещенный в хипе объект.
_W>aliasing, aliasing, aliasing, aliasing, aliasing, aliasing _W>
А можно то же самое но внятно и по-русски?
... << RSDN@Home 1.1.4 stable rev. 510>>
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, Alexey Axyonov, Вы писали:
AA>Здравствуйте, FR, Вы писали:
FR>>Здравствуйте, IT, Вы писали:
IT>>>Ok. Для особо одарённых придётся перевести термин. Nonfunctional requirements — это требования к системе, определяющие не её функциональность и поведение, а её такие свойства как надёжность, расширяемость, нагрузку, стоимость и в том числе быстродействие.
FR>>Для шибко умных, тут трудно различить нефункциональные это требования или нет, если игра идет с 10 fps инграть в нее невозможно.
AA>Да но для начала нужно определиться что именно у тебя должно идти быстрее чем с 10 fps. Это и будут функциональные требования.
Давай представим себе что некая фирма выпустила текстовый редактор, самый крутой на рынке по своим возможностям, но на современных машинах, отклик после нажатия на клавишу две секунды. В таких условиях каким требованием будет быстродействие?
Здравствуйте, Дарней, Вы писали:
Д>Здравствуйте, FR, Вы писали:
FR>>Нет не Ok есть ситуации в которых если следовать по порядку Владовым рекомендациям просто придется выбросить то что уже сделал и написать все по новой.
Д>Кстати, интересно. Что может вызвать ситуацию, когда другого решения не избежать? (т.е. выбросить все и переписать заново ради оптимизации — это единственный путь)
Я тут уже приводил пример, есть игра для PC требует больше 256Mb памяти, ее сейчас портируют на PS2 где памяти всего 32Mb, реально легче переписать с нуля.
Здравствуйте, FR, Вы писали:
FR>Я тут уже приводил пример, есть игра для PC требует больше 256Mb памяти, ее сейчас портируют на PS2 где памяти всего 32Mb, реально легче переписать с нуля.
и как правило, это сопровождается радикальным урезанием функциональности
фактически, на выходе может получиться совсем другая программа, имеющая только некоторые общие свойства с оригинальной
я бы вообще не стал называть это "оптимизацией"
Здравствуйте, Дарней, Вы писали:
Д>Здравствуйте, FR, Вы писали:
FR>>Я тут уже приводил пример, есть игра для PC требует больше 256Mb памяти, ее сейчас портируют на PS2 где памяти всего 32Mb, реально легче переписать с нуля.
Д>и как правило, это сопровождается радикальным урезанием функциональности Д>фактически, на выходе может получиться совсем другая программа, имеющая только некоторые общие свойства с оригинальной Д>я бы вообще не стал называть это "оптимизацией"
Нет, урезание есть но не радикальное, просто оригинал так "хорошо" написан, на PS2 есть и более сложные игры.
Здравствуйте, AndrewVK, Вы писали:
IT>>Кстати, наследование, инкапсуляция и полиморфизм тоже в определённом смысле есть ни что иное как патерны
AVK>Безусловно. К примеру паттерн инкапсуляция это просто разновидность MVC (M — поля, V — публичный интерфейс, C — код методов).
Хм. Интересній взгляд! Хотя, имхо, М это скорее код, а С — диспетчиризатор сообщений.
Здравствуйте, eao197, Вы писали:
E>Здравствуйте, FR, Вы писали:
FR>>Давай представим себе что некая фирма выпустила текстовый редактор, самый крутой на рынке по своим возможностям, но на современных машинах, отклик после нажатия на клавишу две секунды. В таких условиях каким требованием будет быстродействие?
E>Опыт IDEA показывает, что многих вполне устраивает отклик в две секунды
то есть слово test набирается 8 секунд?
E>Вообще-то потребитель далеко не всегда понимает, чего хочет. И лозунг "спрос рождает предложение" так же не совсем верен. Потребителем очень умело манипулируют. Те же самые супер-пупер IDE, которые тормозят на ноутбуках с 512Mb памяти -- хорошие примеры. Потребителю просто дали понять, что появилось новое качество, которое сейчас важнее, чем быстродействие. Со временем, когда к фенечкам и рюшечкам IDE привыкнут, быстродействие вновь станет фактором конкурентной борьбы. Но и тогда для отвлечения (или привлечения) потребителя что-нибудь новое придумают.
В играх такое не прокатит, я могу представить человека терпящего тормозящий рабочий инструмент, но если вместо игры получится слайд-шоу, то ее просто сразу снесут.
Здравствуйте, eao197, Вы писали:
E>Таких POD типов не так уж мало. Два поля типа int в C-шной структуре и все -- POD тип в два раза больше указателя получается. Даже если POD структура всего из нескольких char-ов, то ты, имхо, можешь потерять производительность на некоторых типах процессоров, для которых важно выравнивание при обращении к памяти.
Вообще-то получение адреса, закладывание его в стэк, разадресация и вытягивание данных то же не бесплатные операции. Причем со ссылками намного проще вылететь из кэша. А это уже очень дорого. Так что не факт, что 2-инта имеет смысл передавать по ссылке. К тому же на 64-битном камне два инта как раз вписываются в слово процессора.
E> А если при вызове функции ты передаешь ссылку на локальный объект, созданный на стеке, то промахнуться мимо кэша будет гораздо сложнее, чем при передаче указателя на размещенный в хипе объект.
А кто сказал что объект нахдится в стэке? А вдруг где-то еще? Или в сэке, но он отмотан на пол метра...
ЗЫ
В общем, это разговор уже о полнейшем битовыжимании. Он совершенно бессмысленен. Такую фигню ты уж точно с микроскопом не заметишь.
... << RSDN@Home 1.2.0 alpha rev. 618>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, AndrewVK, Вы писали:
V>>, за которым зачастую идет собственно кодирование. Прикол в том, что подробности архитектуры на этом уровне уже мало кого интересуют, ибо это уровень имплементации.
AVK>Тебя не интересуют, а меня интересуют. Хотя бы потому что вместо разговора сунь туда, вынь это, я могу просто сказать — здесь нужно применить визитор. Паттерны GoF это азбука проектирования.
Так ты споришь или соглашаешься, не понятно? Именно так их и надо использовать.
V>> Для библиотеки — это важно, да, это — самоцель. Для функциональных требований бизнес-системы — нет. Именно про этих уродцев я и говорил. И подмечал, что знание паттернов ничуть не помогает в разработке архитектуры.
AVK>Аргументы?
Другой уровень проектирования является аргументом? Например, какой смысл применять фасадные паттерны в тех местах, относительно которых требования к функциональности еще не устаканились. Это называется ставить телегу впереди лошади. Может, вместо фасада удасться применить декомпозицию и обойтись некими стандартными/распространенными интерфейсами имеющего API?
Т.е. я порицаю практику попыток применения паттернов взамен "обычного" ОО-анализа.
Здравствуйте, vdimas, Вы писали:
V>>> Для библиотеки — это важно, да, это — самоцель. Для функциональных требований бизнес-системы — нет. Именно про этих уродцев я и говорил. И подмечал, что знание паттернов ничуть не помогает в разработке архитектуры.
AVK>>Аргументы?
V>Другой уровень проектирования является аргументом? Например, какой смысл применять фасадные паттерны в тех местах, относительно которых требования к функциональности еще не устаканились. Это называется ставить телегу впереди лошади.
Как это доказывает то, что "знание паттернов ничуть не помогает в разработке архитектуры"?
V>Т.е. я порицаю практику попыток применения паттернов взамен "обычного" ОО-анализа.
Здравствуйте, AndrewVK, Вы писали:
V>>>> Для библиотеки — это важно, да, это — самоцель. Для функциональных требований бизнес-системы — нет. Именно про этих уродцев я и говорил. И подмечал, что знание паттернов ничуть не помогает в разработке архитектуры.
AVK>>>Аргументы?
V>>Другой уровень проектирования является аргументом? Например, какой смысл применять фасадные паттерны в тех местах, относительно которых требования к функциональности еще не устаканились. Это называется ставить телегу впереди лошади.
AVK>Как это доказывает то, что "знание паттернов ничуть не помогает в разработке архитектуры"?
Могу уточнить, если кто не понял из контекста. Я утверждал, что зазубрить список паттернов недостаточно для грамотного проектирования. Более того, наблюдал примеры "тупого" применения паттернов не к месту, что и озвучил. Так с чем именно ты не согласен?
Здравствуйте, VladD2, Вы писали:
VD>Сейчас нет времени на полный ответ, но хочется заметить, то что бросается в глаза.
VD>Очень часто ты вместо ответа на мои слова разговариваешь сам с собой. Например: VD>
V>>> Лично я поддержал сам факт обсуждения этой темы. Согласен, что Дворкин немного перегибает,
VD>>Будем надеяться, что тройка поставленная им за твое сообщение в том числе включает и согласие с этим вот высказыванием.
VD>Что означает моя оценка я уже обяснил. Поддержку и раскрытие самой темы. Оценки привлекают читателей, не правда ли?
VD>Создается впечатлинеие, что ты сражашся с вымышленным противником.
Где-то я уже слышал это недавно...
Влад, если бы ты знал на какой уровень домысливания приходится настраиваться, читая твои посты...
Я прекрасно знаю, что обсуждение очепяток оппонентов находится за правилами RSDN, но тут уже просто количество переходит в качество, в требование определенного настроя...
Конкретно в приведенном примере, да, получается что я домыслил твое предложение неверно.
Тогда ответ на тот абзац мог бы быть примерно таким:
"По-абзацное оценивание не предусмотрено, к сожалению..."
Здравствуйте, VladD2, Вы писали:
VD>С тех времен прошло уже 12 лет (если не ошибаюсь). И мне казалось что уже все знают, что посимвольное чтение из файла — это совершенно не смертельно. Но вот появляется еще один перформанс-варьер который не был столь прозорлив чтобы наступить на эти грабли 12 лет назад, и делает смелые заявления
Хочу возразить и жестко. Буквально год назад я столкнулся с тем, что на VB девушка программист выданный ей массив байтов записывала в файл побайтово. Так вот, когда этот код на VB заменили на запись всего массива за раз, то скорость выросла примерно на два порядка. Я понимаю, что это особенности VB, но тем не менее, все грешили на то, что тормозит Сишный код, который формировал этот массив байтов.
Так что не всегда посимвольная в данном случае запись является не смертельной.
Здравствуйте, Cyberax, Вы писали:
C>Кстати о птичках. Мы тестировали что эффективнее передавать — ссылку на C>CSize (те же 8 байт) или сам CSize по значению. Оказалось, что разницы C>нет. Точнее, на одних процессорах (Intel Pentium M) был быстрее C>указатель, а на других (AMD не-помню-какой) было выгодно передавать по C>значению.
А CRect?
... << RSDN@Home 1.1.4 stable rev. 510>>
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, eugen1001, Вы писали:
E>Хочу возразить и жестко. Буквально год назад я столкнулся с тем, что на VB девушка программист выданный ей массив байтов записывала в файл побайтово. Так вот, когда этот код на VB заменили на запись всего массива за раз, то скорость выросла примерно на два порядка. Я понимаю, что это особенности VB, но тем не менее, все грешили на то, что тормозит Сишный код, который формировал этот массив байтов.
E>Так что не всегда посимвольная в данном случае запись является не смертельной.
И какой вывод? Варианты ответов:
1. Ни в коем случ не пишите в файл по одному байту.
2. Ищите места снижающие производительность и устраняйте их.
И еще вопрос. Предположим, чтобы утранить эту проблему можно:
1. Переписать алгоритм записи данных используя буфер.
2. Использовать кэшурующую оберкту для объекта проивзодящего запись в файл.
... << RSDN@Home 1.2.0 alpha rev. 618>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, eao197, Вы писали:
C>>Кстати о птичках. Мы тестировали что эффективнее передавать — ссылку на C>>CSize (те же 8 байт) или сам CSize по значению. Оказалось, что разницы C>>нет. Точнее, на одних процессорах (Intel Pentium M) был быстрее C>>указатель, а на других (AMD не-помню-какой) было выгодно передавать по C>>значению. E>А CRect?
Не тестировали. У нас в одном модуле просто была задача быстро обработать несколько миллионов размеров, вот и искали оптимальный вариант. С CRect уже скорее всего будет эффективнее передача по ссылке.
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, eugen1001, Вы писали:
E>>Хочу возразить и жестко. Буквально год назад я столкнулся с тем, что на VB девушка программист выданный ей массив байтов записывала в файл побайтово. Так вот, когда этот код на VB заменили на запись всего массива за раз, то скорость выросла примерно на два порядка. Я понимаю, что это особенности VB, но тем не менее, все грешили на то, что тормозит Сишный код, который формировал этот массив байтов.
E>>Так что не всегда посимвольная в данном случае запись является не смертельной.
VD>И какой вывод? Варианты ответов: VD>1. Ни в коем случ не пишите в файл по одному байту. VD>2. Ищите места снижающие производительность и устраняйте их.
VD>И еще вопрос. Предположим, чтобы утранить эту проблему можно: VD>1. Переписать алгоритм записи данных используя буфер. VD>2. Использовать кэшурующую оберкту для объекта проивзодящего запись в файл.
Выводов два:
1. В каждом отдельном случае нужно отдельно изучать ситуацию, по возможности точно контролировать в какой момент времени и почему тормозит.
В нашем случае показано, что бывают ситуации, когда работа по одному байту или блоками особой роли не играет, а бывает, когда очень даже играет.
2. Прежде, чем что-то оптимизировать, да еще с серьезными переделками, нужно провести оценку: соизмерим ли ожидаемый выйгрыш по времени с затратами на оптимизацию.
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Здесь не идет речь о POINT,
Здесь-то она может и не идет, а вот там где вы со студентом пинали Петцольда — шла именно о POINT-е.
И студент теперь будет всегда передавать по ссылке все типы, у которых размер > sizeof(void *).
PD>с ним, вполне возможно, разницы нет.
В том-то и дело, что в приведенном мною примере разница есть. Передача по значению оказалась эффективнее.
И таких примеров тысячи. В конце концов, sizeof(double) тоже > sizeof(void *), но вряд ли будет разумно и его везде по ссылке передавать. ТщательнЕЕ надо...
PD>Я имел в виду, что и в других случаях они будут это делать, там где размеры могут доходить до десятков и сотен байтов + конструктор копирования. Если не привыкнут сразу думать о том, что они передают и во что это превращается в коде.
+1
Тут ошибочка у вас Павел вышла. Сам недавно на такое наткнулся. В этом случае Петцольд был прав. Зря студент пострадал.
Начиная с Пентиумов шина 64 битная. То есть за раз, она забирает 8 байт. И не меньше. В результате если значение не в массиве, то разницы между 4 байтами и 8 байтами нет.
Здравствуйте, AndrewVK, Вы писали:
GZ>>А по мне существует только один паттерн который называется Low Coupling/High Cohesion.
AVK>Это не паттерн, это оценочный критерий.
Многие с тобой не согласятся. Насколько я помню в GRASP это было описано как паттерн(или как два паттерна). Ну или вот wikipedia. А то что метрики ОО систем построены в том числе на измерении этих параметров, то это отношения не имеет. Просто увеличивает ценность. AVK>Паттерн это конкретное архитектурное решение.
Не-а. И "конкретное" не всегда. И "архитектурное" тоже. Паттерн — это некоторое приблизительное решение описанное в некотором формализованном виде.
Здравствуйте, Andrei N.Sobchuck, Вы писали:
ANS>"Не красивые самолёты не летают". Красота это, в первую очередь, мерило функциональности.
птеродактили вот тоже летали, хотя с виду — сущие уродцы
или твое правило относится только к самолетам?
ANS>Соответсвенно "некрасивая программа" это когда в ней что-то не так. Если кто-то считает красивой тормозную программу, то такой человек только тормозные программы и может делать.
как ловко ты перешел от "функциональности" к "скорости работы". А ничего, что это понятия абсолютно ортогональные?
Здравствуйте, FR, Вы писали:
FR>Во вторых среднее время жизни игровых приставок пять лет, и все эти пять лет более мощного оборудования просто не будет.(Хотя для приставок игра не прошедшая требования по быстродействию просто не будет издана).
Здравствуйте, eugen1001, Вы писали:
E>Выводов два: E>1. В каждом отдельном случае нужно отдельно изучать ситуацию, по возможности точно контролировать в какой момент времени и почему тормозит. E>В нашем случае показано, что бывают ситуации, когда работа по одному байту или блоками особой роли не играет, а бывает, когда очень даже играет.
E>2. Прежде, чем что-то оптимизировать, да еще с серьезными переделками, нужно провести оценку: соизмерим ли ожидаемый выйгрыш по времени с затратами на оптимизацию.
Ай, маладца! Полностью согласен! Теперь перечитай еще раз внимательно то, что я написал в тематическом сообщении и поймешь, что там об этом речь и идет. Просто выводы не разжованы и в рот не положены.
ЗЫ
Разжевывание :
Самая большая ошибка начинать заниматься оптимизациями исходя из предположений, не прозводя тестов и глубокого анализа проблем/последствий от их устранения тем или иным образом.
И вот, как раз, заявления вроде того, что "запись в файл по байтно тормоза и вообще лам" — как раз и является таким вот предположением, а следствием, зачастую, является как раз угроханный код с пятидесятипроцентной вероятностью того, что толк от оптимизации или отсутствует вообще, или мизерный. Обратное предположение тоже не верно. Но разумно предполагать по умолчанию, что библиотеки написаны более менее оптимально. Ведь на не делание оптимизации усилий обычно не тратится. Да и ее никогда не поздно сделать. Ну, и естественно это не может повредить качеству кода. А вот на деланье...
Простой пример. В дотнете файловые потоки кэшируют вод/вывод и единственное что можно выиграть от записи большими блоками — это избавиться от виртуальных и иных вызовов. Это конечно может дать выигрыш если файл уже читается из кэша ОС (иначе заметить что-то на фоне обращения к физическим дискам просто невозможно), но выигрыш будет в два раза максимум и на фоне других операций с данными будет попросту незаметен. Зато блочное чтение может значительно ухудшить код. Создание же промежуточной абстракции скорее всего обойдется не дешево (с точки зрения трудозатрат), и мало что даст.
Ну, и последнее. Скорость понятие относительное. Одна и та же операция может оказаться дико медленной в одних условиях и незаметной в другой. Зависит все от двух факторов:
1. Объема сопутствующей нагрузки. Например, глупо оптимизировать проверки в for-ах занимающие микросекунды если внутри них идет обращение к БД занимающие от миллисекунд, до секунд.
2. Объема вычислений. Ведь вряд ли что-то даст оптимизация чтения 10 байт.
У меня вот недавно был замечательный случай. Вызов функции SelectObject(hFont) практически ничего не стоила при отрисовке (как для самой отрисовки, так и для расчета размеров строк), но становилась узким местом при расчете переносов строк (для расчета их длинны) в больших текстовых файлах. Понятно, что если бы у меня не стояло второй задачи, то оптимизация в этой области была бы глупостью и вредительством, но при наличии второй задачи она уже более чем оправданна, ведь скорость считывания закэшированных файлов, при этом, возрастает в 3 раза.
... << RSDN@Home 1.2.0 alpha rev. 618>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, vdimas, Вы писали:
V>А вот он и камень преткновения. Многие тут говорили о том, что даже эти банальные правила зачастую не соблюдаются при кодировании. Процесс переписывания подобных участков кода "потом", ИМХО, является оптимизацией. Но она из разряда "ее могло и не быть".
Возможно, но тогда спор терминалогический.
V>Мне, например, не хватает что-то типа оператора with из VB. Приходится ручками заводить локальные переменные. Если кому-то это делать лень, то в случае нетривиального кода свойств можно получить серьезные тормоза на ровном месте. И таких примеров предостаточно.
А это очередной пример предположенческой оптимизации. И вообще, такие вещи должен оптимизировать компилятор.
Да и with от "ручками заводить локальные переменные" мало чем отличается. Разве что на одну строчку короче.
... << RSDN@Home 1.2.0 alpha rev. 618>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, eao197, Вы писали:
E>Здравствуйте, Cyberax, Вы писали:
C>>Кстати о птичках. Мы тестировали что эффективнее передавать — ссылку на C>>CSize (те же 8 байт) или сам CSize по значению. Оказалось, что разницы C>>нет. Точнее, на одних процессорах (Intel Pentium M) был быстрее C>>указатель, а на других (AMD не-помню-какой) было выгодно передавать по C>>значению.
E>А CRect?
Ты еще учти, что во многих случаях компиляторы просто инлайнят методы. Так же учти промахи мимо кэша. В реальном приложении и на CRect/RECT разница будет стримиться к нулю. Причем зачастую от ссылок на таких структурах ты проиграшь, так как промахи мимо кэша участятся. Ведь ты передашь параметр для использования. А значит компилятор породит код читающй уже содержимое структуры. Если она объявлена перед вызовом метода, то не беда, а если она лежит очень далего?
... << RSDN@Home 1.2.0 alpha rev. 618>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
VD>Ты еще учти, что во многих случаях компиляторы просто инлайнят методы. Так же учти промахи мимо кэша. В реальном приложении и на CRect/RECT разница будет стримиться к нулю. Причем зачастую от ссылок на таких структурах ты проиграшь, так как промахи мимо кэша участятся. Ведь ты передашь параметр для использования. А значит компилятор породит код читающй уже содержимое структуры. Если она объявлена перед вызовом метода, то не беда, а если она лежит очень далего?
А если она передается через длинную цепочку вызовов методов?
... << RSDN@Home 1.1.4 stable rev. 510>>
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, Дарней, Вы писали:
ANS>>"Не красивые самолёты не летают". Красота это, в первую очередь, мерило функциональности.
Д>птеродактили вот тоже летали, хотя с виду — сущие уродцы
а что, есть абсолютная уверенность, что они летали?
Д>или твое правило относится только к самолетам?
"Красота", это интегральная субьективная оценка, которую ты присваиваешь чему-либо. Вот ты считаеш птеродактелей уродцами, а может если бы ты знал об устройстве их крыльев, об аэродинамических качествах, то считал бы их образцом для подражания. То есть кто-то считает мечь прекрасным оценивая балансировку, сталь, а кто-то по наличию рюшиков.
ANS>>Соответсвенно "некрасивая программа" это когда в ней что-то не так. Если кто-то считает красивой тормозную программу, то такой человек только тормозные программы и может делать.
Д>как ловко ты перешел от "функциональности" к "скорости работы". А ничего, что это понятия абсолютно ортогональные?
См. выше. Я просто не смог сходу подобрать более лучшего слова чем "функциональность". Читай "интегральная оценка". А проблема в том, что довольно часто можно видеть высказывание типа "я написал красиво, а потом занялся оптимизацией и программа стала уродцем".
Здравствуйте, GlebZ, Вы писали:
GZ>Здравствуйте, Pavel Dvorkin, Вы писали:
GZ>Тут ошибочка у вас Павел вышла. Сам недавно на такое наткнулся. В этом случае Петцольд был прав. Зря студент пострадал. GZ>Начиная с Пентиумов шина 64 битная. То есть за раз, она забирает 8 байт. И не меньше. В результате если значение не в массиве, то разницы между 4 байтами и 8 байтами нет.
Вполне возможно. Кстати, студент вовсе не пострадал
Еще раз — не в POINT дело. Его вполне можно и по значению передать. Дело в принципе — незачем большие структуры по значению передавать.
Здравствуйте, eugals, Вы писали:
E>В том-то и дело, что в приведенном мною примере разница есть. Передача по значению оказалась эффективнее. E>И таких примеров тысячи.
Неужели ?
В конце концов, sizeof(double) тоже > sizeof(void *), но вряд ли будет разумно и его везде по ссылке передавать. ТщательнЕЕ надо...
Здравствуйте, Andrei N.Sobchuck, Вы писали:
ANS>Внимание вопрос, как бы автор поста писал подобную систему, если он считает, что внутри всё круче, чем варенные яйца?
Не знаю
Я на самом деле не критиковал ни то ни другое. Есть, грубо говоря, два подхода к разработке софта:
Сверху вниз: мы начинаем от требований, и по мере уточнения требований описываем все более мелкие детали софта. Апологеты этого подхода считают, что аккуратное следование ему приведет к красивому внутреннему устройству. Или не приведет — не столь уж важно.
Снизу вверх: мы обобщаем все, что можно обобщить, и делаем могучую внутренне непротиворечивую модель. Конкретные требования пользователя будут реализованы как небольшой частный случай этой всеобъемлющей модели. Или не будут — не столь уж важно.
Конечно, как два путника, вышедших друг другу навстречу из пунктов A и B, они непременно встретятся. Если будут идти достаточно упорно.
А если не будут, то одни останутся со всеобъемлющей, но абсолютно бесполезной платформой, а другие — с нерасширяемым негибким решением некоторого подмножества требований пользователя. Потому как у первых не хватит терпения дописать нужные плагины, а у вторых — не хватит сил добавлять фичи.
Обе среды — и Idea и Eclipse — зашли достаточно далеко по своим путям, чтобы их можно было считать успешными. Тем не менее, недостатки в них вполне логично следуют из различия подходов. К моменту, когда они все же встретятся, различия сотрутся.
1.1.4 stable rev. 510
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Sinclair, Вы писали:
S>Здравствуйте, Pavel Dvorkin, Вы писали:
PD>> Там то, что называется передачей по ссылке и по значению — в любом случае есть передача ссылки на объект, поскольку к самим объектам доступа нет. S>Опять двойка. Читать про value-типы.
Ну если мы начнем двойки друг другу ставить — боюсь, давно уже друг друга бы отчислили
По существу — естественоо, я имел в виду классы, а не структуры.
Здравствуйте, GlebZ, Вы писали:
GZ>Здравствуйте, Pavel Dvorkin, Вы писали:
PD>>Вполне возможно. Кстати, студент вовсе не пострадал PD>>Еще раз — не в POINT дело. Его вполне можно и по значению передать. Дело в принципе — незачем большие структуры по значению передавать. GZ>Да нет, проблема в другом. При современном развитии железа и компиляторов, очень трудно прогнозировать как та или иная операция выйдет по производительности. В принципе от алгоритмической сложности отойти невозможно. Но вот сложность того или иного метода дизайна спрогнозировать сложно. Java — пытается запихнуть объекты по возможности в стек. Пытаются выдавить лишние действия из циклов. Пытаются работать через регистровую память. Пытаются уместить данные в кэше процессора. Пытаются ублажить конвейры процессора. И многое многое многое о чем я не знаю. Я только знаю что эта шняга будет работать, но каждый раз лазить в ассемблер и узнавать как оно в реальности работает, и узнавать что куча кода скомпилировалось в одну ассембленую команду(как это часто бывает в STL), я не могу и не буду. Знания конечно сила, я могу примерно прогнозировать во что это выльется для знакомых мне платформ. Но явно этими знаниями я пользуюсь редко и только для наибольшего криминальных команд и подсистем. GZ>Лучше я отдам эти вопросы на откуп умному компилятору и заумному процессору. А сам буду делать логику, которая нужна мне а не им. Они сами справятся.
Я готов со всем этим согласиться, но с одним "но". Если речь идет все же о С++, то никакой умный компилятор и заумный процессор тебя не спасет, если ты начнешь развесистое дерево передавать по значению. Там все же конструктор копирования, который в себе такое потянет, что мало не покажется (и по времени, и по памяти). Если же там даже чистая структура С, то при ее размерах порядка десятков байт (а таких структур в том же Win32 много) делать копии — просто время зря расходовать (конечно, если не нужна именно копия). И вот это надо не допускать.
В пограничных случаях — (POINT, double и т.д.) разница может быть несущественной, верно. Но приучать надо все же к грамотному кодированию.
А кстати, как в C# сделать копию объекта, если надо все же ? Как я понимаю, надо реализовать ICloneable в классе ? А что если в классе есть ссылки на другие классы, которые этот интерфейс не реализуют и помечены как sealed ?
Здравствуйте, IT, Вы писали:
IT>Последнее время я всё больше и больше убеждаюсь, что все эти проработки-шмаработки, паттерны-шматтерны конечно хорошо, но находятся далеко не на первом месте. Почему-то у меня всё чаще и чаще на первое место выходит готовность системы к её последующим изменениям под новые требования. Т.е. заменить вот эту фенечку вот на такую шменечку и воткнуть между ними вот такую жменечку. Второе место занимает, кто бы мог подумать — готовность системы к изменениям после её изменения.
а паттерны-шматтерны не способствуют разве большей прозрачности (понятности) реализации? что в конечном итоге и равно готовности к изменениям. Или как ты эту готовность обеспечиваешь?
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Я готов со всем этим согласиться, но с одним "но". Если речь идет все же о С++, то никакой умный компилятор и заумный процессор тебя не спасет, если ты начнешь развесистое дерево передавать по значению. Там все же конструктор копирования, который в себе такое потянет, что мало не покажется (и по времени, и по памяти). Если же там даже чистая структура С, то при ее размерах порядка десятков байт (а таких структур в том же Win32 много) делать копии — просто время зря расходовать (конечно, если не нужна именно копия). И вот это надо не допускать.
И здесь не всегда. Если процедура синлайнется, то вполне возможно что компилятор поймет что копировать не стоит. Вобщем ситуаций может быть много.
PD>В пограничных случаях — (POINT, double и т.д.) разница может быть несущественной, верно. Но приучать надо все же к грамотному кодированию.
Вобщем, насколько я понял, у нас различия в термине "грамотное кодирование".
PD>А кстати, как в C# сделать копию объекта, если надо все же ? Как я понимаю, надо реализовать ICloneable в классе ?
Да. PD>А что если в классе есть ссылки на другие классы, которые этот интерфейс не реализуют и помечены как sealed ?
Ключевые слова deep copy и shadow copy. Первый копирует все объекты на который ссылаются, второй копирует ссылки. По умолчанию обычно действует shadow copy.
Здравствуйте, AndrewVK, Вы писали:
GZ>>А по мне существует только один паттерн который называется Low Coupling/High Cohesion.
AVK>Это не паттерн, это оценочный критерий. Паттерн это конкретное архитектурное решение.
Паттерны так же относятся к набору практик. И упомянутый оценочный критерий тоже скорее из разряда практик. (или ссылку на формальное доказательство, если есть)
А практики — они такие интересные по сути вещи, что их применение может зависеть от внешних условий. Другими словами, даже упомянутый оценочный критерий не всегда требуется для оценки решений. Как пример — разработка практически любой аппаратуры, содержащей выч. компоненты. За требованиями минитюаризации, минимизации ресурсов, или даже исполнения в виде одной гибридной схемы и пр., оценка связанности компонентов просто теряет свою значимость. Связанность заведомо 100%-я.
V>>Без достаточной проработки самой модели и всех ее уровней с функциональной т.з. и с т.з. всевозможных ограничений, бросаться в конкретику паттернов, ИМХО, рановато.
IT>Последнее время я всё больше и больше убеждаюсь, что все эти проработки-шмаработки, паттерны-шматтерны конечно хорошо, но находятся далеко не на первом месте. Почему-то у меня всё чаще и чаще на первое место выходит готовность системы к её последующим изменениям под новые требования. Т.е. заменить вот эту фенечку вот на такую шменечку и воткнуть между ними вот такую жменечку. Второе место занимает, кто бы мог подумать — готовность системы к изменениям после её изменения.
Счастливый человек. ИМХО, судя по твоим приоритетам, общий дизайн ты уже давно не разрабатываешь, он у тебя "сам собой получается естественным образом". Собственно, так и должно быть при наличии опыта.
А у некоторых пока стоят проблемы, (хе-хе) с путями реализаций требований. Эти пути и обсуждаем.
Здравствуйте, GlebZ, Вы писали:
PD>>Я готов со всем этим согласиться, но с одним "но". Если речь идет все же о С++, то никакой умный компилятор и заумный процессор тебя не спасет, если ты начнешь развесистое дерево передавать по значению. Там все же конструктор копирования, который в себе такое потянет, что мало не покажется (и по времени, и по памяти). Если же там даже чистая структура С, то при ее размерах порядка десятков байт (а таких структур в том же Win32 много) делать копии — просто время зря расходовать (конечно, если не нужна именно копия). И вот это надо не допускать. GZ>И здесь не всегда. Если процедура синлайнется, то вполне возможно что компилятор поймет что копировать не стоит. Вобщем ситуаций может быть много.
Тут еще вот в чем дело. Передавая что-то по значению, мы должны знать, что это не приведет к черезмерным накладным расходам. Для POINT и RECT я это знаю, т.к. структуры тривиальные. Для std::vector, std::list или std::string я так же знаю, что, скорее всего, приведет к расходам, т.к. их реализации используют динамическую память. А если мне встречается какой-то не стандартный тип, скажем, auth_info_t или priority_levels_t. Про который я должен знать только его public-интерфейс и не должен знать деталей его реализации. Как мне оценить, что передача priority_levels_t по значению будет эффективной? Заглянув в состав его полей? А если там только одно поле-указатель, то значит ли это что-нибудь? Вдруг priority_levels_t через идиому PImpl реализован. Или, что еще опаснее, в текущей версии priority_levels_t можно эффективно копировать, а в следующей версии его реализацию сменят на более догоростоющую в копировании. Передача же объекта по ссылке гарантированно дает мне низкие накладные расходы и не обязывает меня обращать внимание на детали реализации используемых мной типов.
И еще один момент. В C++ есть понятие копирования объекта. А есть понятие копирования указателя на объект. Если мы передаем объект по значению мы используем именно понятие копирование объекта. И если функция/метод требует в качестве параметра именно значение объекта, то это не спроста. Значит функция внутри себя будет это свою личную копию иметь так, как фантазия позволит. И иметь именно копию, а не исходный объект. В случае же, если функция требует в качестве параметра константный указатель/ссылку на объект, функция декралирует, что исходный объект будет использоваться в операция внутри функции. Не константный указатель/ссылка же явно декларирует, что функция функция будет изменять исходный объект. В любом из случаев намерения функции по отношению к объекту становятся понятными исходя просто из описания функции. Поэтому описание параметра функции как константной ссылки или указателя на объект говорит пользователю: не бойся, не съем я твой объект
... << RSDN@Home 1.1.4 stable rev. 510>>
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, Andrei N.Sobchuck, Вы писали:
ANS>а что, есть абсолютная уверенность, что они летали?
сам не знаю, не видел но специалисты утверждают, что летали
ANS>"Красота", это интегральная субьективная оценка, которую ты присваиваешь чему-либо. Вот ты считаеш птеродактелей уродцами, а может если бы ты знал об устройстве их крыльев, об аэродинамических качествах, то считал бы их образцом для подражания. То есть кто-то считает мечь прекрасным оценивая балансировку, сталь, а кто-то по наличию рюшиков.
вот ты сам это и сказал. Нет никакого общего понятия красоты, ибо понятие это субъективное и к тому же подверженное изменениям со временем. Вполне логично, что конструктор самолетов считает красивым хорошо спроектированный самолет (особенно — им самим спроектированный ). Вполне логично, что другой конструктор с ним не согласится. И также вполне логично, что тот самый конструктор посмотрит лет через двадцать на свой самолет и скажет "ну и уродец!"
ANS>См. выше. Я просто не смог сходу подобрать более лучшего слова чем "функциональность". Читай "интегральная оценка". А проблема в том, что довольно часто можно видеть высказывание типа "я написал красиво, а потом занялся оптимизацией и программа стала уродцем".
А ты представь себе, что тот самый конструктор сделал красивейший самолет, который замечательно летает, а ему потом сказали "ну ты извини, но твой самолет по размаху крыльев на три метра превышает имеющиеся у нас ангары. Так что ты придумай уж что-нибудь"
Здравствуйте, GlebZ, Вы писали:
GZ>И здесь не всегда. Если процедура синлайнется, то вполне возможно что компилятор поймет что копировать не стоит. Вобщем ситуаций может быть много.
Стоп, или я что-то не понимаю, или здесь что-то не так. Если ее передают по значению, ее обязаны скопировать. Потому что будет там inline или нет — не так уж важно, а вот формальный параметр, переданный по значению, я имею полное право изменять внутри вызываемой функции, и эти изменения не должны сказаться на фактическом параметре.
GZ>Вобщем, насколько я понял, у нас различия в термине "грамотное кодирование".
GZ>Ключевые слова deep copy и shadow copy. Первый копирует все объекты на который ссылаются, второй копирует ссылки. По умолчанию обычно действует shadow copy.
Это я все понимаю, а как все же этот deep copy реализовать ?
class MyClass
{
AnotherClass c;
//
}
и у AnotherClass ICloneable не реализован. Как его deep copy сделать ?
В С++ такое в принципе невозможно. Есть AnotherClass — должен быть у него конструктор копирования. Как он устроен — меня не интересует, а работать будет.
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Я бы это утверждение расширил. Без религиозно-фанатичного обожания надо относиться к оптимизации, паттернам, абстракциям, С++, C#, Java, .Net и т.д. и т.п. И вообще — не сотвори себе кумира
PD>Боюсь только, что объяснять это некоторым — все равно, что агитировать римского папу вступить в общество атеистов
Можно попросить указать на тот кусок, где я относился с религиозно-фанатичным обожанием к паттернам?
E> – Так, может, вы нам откроете сию тайну, – язвительно буркнул главный из художников, – раз уж вы такой знаток.
E> – Я не знаток, я просто врач, но я много думал над вопросами анатомии. Если упростить определение, которое на самом деле гораздо сложнее, как и вообще все в мире, то надо сказать прежде всего, что красота существует как объективная реальность, а не создается в мыслях и чувствах человека. Пора отрешиться от идеализма, скрытого и явного, в искусстве и его теории. Пора перевести понятия искусства на общедоступный язык знания и пользоваться научными определениями. Говоря этим общим языком, красота – это наивысшая степень целесообразности, степень гармонического соответствия и сочетания противоречивых элементов во всяком устройстве, во всякой вещи, всяком организме. А восприятие красоты нельзя никак иначе себе представить, как инстинктивное. Иначе говоря, закрепившееся в подсознательной памяти человека благодаря миллиардам поколений с их бессознательным опытом и тысячам поколений – с опытом осознаваемым. Поэтому каждая красивая линия, форма, сочетание – это целесообразное решение, выработанное природой за миллионы лет естественного отбора или найденное человеком в его поисках прекрасного, то есть наиболее правильного для данной вещи. Красота и есть та выравнивающая хаос общая закономерность, великая середина в целесообразной универсальности, всесторонне привлекательная, как статуя.
E> Нетрудно, зная материалистическую диалектику, увидеть, что красота – это правильная линия в единстве и борьбе противоположностей, та самая середина между двумя сторонами всякого явления, всякой вещи, которую видели еще древние греки и назвали аристон – наилучшим, считая синонимом этого слова меру, точнее – чувство меры. Я представляю себе эту меру чем-то крайне тонким – лезвием бритвы, потому что найти ее, осуществить, соблюсти нередко так же трудно, как пройти по лезвию бритвы, почти не видимому из-за чрезвычайной остроты. Но это уже другой вопрос. Главное, что я хотел сказать, это то, что существует объективная реальность, воспринимаемая нами как безусловная красота. Воспринимаемая каждым, без различия пола, возраста и профессии, образовательного ценза и тому подобных условных делений людей.
E>Иван Ефремов, Лезвие Бритвы.
сначала призывает отрешиться от идеализма, а потом начинает втирать про существование некоего "единственно верного и наилушего варианта" — не что иное, как тот самый идеал
рассмотрим в качестве примера женскую красоту — я думаю, этот предмет близок сердцу большинства читателей
были времена, когда красивыми считали бледных и худых женщин — чем худее и бледнее, тем красивее. Особенно красивыми считались женщины, больные чахоткой.
Бывали времена, когда красивыми считались полные и "мощные" женщины — сейчас такой бы сказали "иди занимайся фитнесом, корова!"
Бывали времена, когда красивыми считались женщины с плоской грудью — с этой целью девочкам-подросткам туго затягивали грудь и накладывали на грудь специальные металлические пластины, в конце концов она становилась не то чтобы плоской, а скорее даже "вогнутой"
список можно еще продолжить — например, вспомнить про аборигенов, для которых идеал красоты — это длинная шея. Так что для улушения внешности тамошние женщины надевают на шею множество колец, постепенно добавляя новые и новые.
Ну как, где тут единственно верный вариант, который понравится всем?
Здравствуйте, VladD2, Вы писали:
VD>Здорово! То есть ты перечитал текст, понял что сморозил ерунду и вместо того чтобы сказать "извини, плохо прочел" решил перевести разговор на обсуждение моих опечаток? А не объяснишь ли ты чем в донном случае мои опечатки помешали тебе отличить смысл слов "им" и "тобой"?
V>>Конкретно в приведенном примере, да, получается что я домыслил твое предложение неверно.
Так оказалось недостаточно?
VD>Причем тут пообзацное оценивание? Я выразил легкий сарказм по поводу того, что он поставил оценку за сообщение которое во многом противоречит его суждениям.
Но кое что и близко, потому я и заметил насчет по-абзацного оценивания.
VD>Вообще меня угнетает мысль о том, что необходимо разжевывать любую мысль, а такие вещи как сарказм и юмор вообще восринимаются не адекватно. Подозреваю, что конечно в этом виноват я.
+1 насчет разжевывать
в ветке насчет паттернов вынужден был убить на это прилично времени. Виновато конечно стремление выдавать свои мысли как можно более сжато, надеясь на адекватное восприятие коллегами.
Д>рассмотрим в качестве примера женскую красоту — я думаю, этот предмет близок сердцу большинства читателей Д>были времена, когда красивыми считали бледных и худых женщин — чем худее и бледнее, тем красивее. Особенно красивыми считались женщины, больные чахоткой. Д>Бывали времена, когда красивыми считались полные и "мощные" женщины — сейчас такой бы сказали "иди занимайся фитнесом, корова!" Д>Бывали времена, когда красивыми считались женщины с плоской грудью — с этой целью девочкам-подросткам туго затягивали грудь и накладывали на грудь специальные металлические пластины, в конце концов она становилась не то чтобы плоской, а скорее даже "вогнутой" Д>список можно еще продолжить — например, вспомнить про аборигенов, для которых идеал красоты — это длинная шея. Так что для улушения внешности тамошние женщины надевают на шею множество колец, постепенно добавляя новые и новые. Д>Ну как, где тут единственно верный вариант, который понравится всем?
Так это всё ориентация на вторичные половые признаки. Например, бледные — следствие ориентации на аристократический образ жизни, в то время, как бедным приходилось работать под открытым небом где они загорали. То есть тогда, брали в жены не женщину, а замок А уж логику дикарей предсказать не берусь. Может "плоская" вылезла из какой-то ловушки, и все ей подражать начали
Здравствуйте, WolfHound, Вы писали:
WH>Здравствуйте, Pavel Dvorkin, Вы писали:
WH>Не факт. WH>Например у меня в программах на С++ у большенства классов конструктор копирования и копирующие присваивание заблокированы тем или иным образом. WH>И пошол я на это абсолютно сознательно ибо логика этих классов не предусматривает копирования.
Да бога ради. Это просто означает, что создание копий запрещено. И не у тебя только. В MFC таких классов полно, начиная с CWnd. Потому как бессмысленно создавать копию.
Но если копию создавать разработчик класса не запрещает — он обязан обеспечить конструктор копирования (и операцию присваивания)
Здравствуйте, Дарней, Вы писали:
Д>рассмотрим в качестве примера женскую красоту — я думаю, этот предмет близок сердцу большинства читателей
У кого-то, может быть у того же Ефремова, я читал опровержение как раз тех фактов, которые ты приводишь ниже. В частности то, что на картинах старых мастеров часто были нарисованы очень худосочные, чахоточные женщины -- это из-за того, что в те времена позировать художником считалось грехом и на это отчаивались те, кому терять уже было нечего (в частности, беднота, которая никогда не могла похвастаться здоровьем). А по поводу издевательств над организмом, то следует отметить, что:
-- это не были массовые явления, в основном, подобными вещами занималась "знать", которым безделие в голову давало и на всякие придури тянуло;
-- это не прижилось, поэтому можно считать это всего лишь тупиковой мутацией. Правилом, всего лишь подтверждающем исключения.
... << RSDN@Home 1.1.4 stable rev. 510>>
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, VladD2, Вы писали:
VD>Возможно, но тогда спор терминалогический.
Что считать оптимизацией? Безусловно, без определения трудно спорить, а то может оказаться, что обе стороны скорее согласны, чем нет.
V>>Мне, например, не хватает что-то типа оператора with из VB. Приходится ручками заводить локальные переменные. Если кому-то это делать лень, то в случае нетривиального кода свойств можно получить серьезные тормоза на ровном месте. И таких примеров предостаточно.
VD>А это очередной пример предположенческой оптимизации. И вообще, такие вещи должен оптимизировать компилятор.
Я, вроде, упомянул о случае нетривильного кода св-в. Да и вообще, большая часть оптимизаций строится исходя из неких предположений. Писать одни и те же тесты каждый раз накладно, однажды уяснил для себя некие моменты, потом используешь...
VD>Да и with от "ручками заводить локальные переменные" мало чем отличается. Разве что на одну строчку короче.
Здравствуйте, IT, Вы писали:
IT>Наиболее частая ошибка которую я вижу и в своей практике и иногда здесь на форумах — это перевод средсв достижения целей в разряд самих целей. Т.е. большинство проблем начинает возникать когда ООП дизайн или паттерны становятся целями, а не средствами их достижения.
+3 за удачно выраженную мысль (кою я выразил не столь удано в этой подветке)
а ту фразу ты из середины обсуждения взял. Прочти плиз целиком это обсуждение относительно того, как именно применяются паттерны, и тебе, надеюсь, будет полностью понятна моя т.з. Если где-то в начале я слишком сжато выразился, то уже успел неоднократно обясниться подробнее.
Здравствуйте, WolfHound, Вы писали:
WH>Так и в .NET таже фигня... если разработчик хочет чтобы класс копировался он должен реализовать IClonable. WH>Разница лиш в том что в С++ по умолчанию объекты копируемые, а в .NET не копируемые.
GZ>Никак. Может быть это самим классом не поддерживается не просто так. Как стандартные варианты обхода — через сериализацию, или вручную через интероп. В принципе можно сделать и через маршалинг.
Все ясно. Спасибо.
PD>>В С++ такое в принципе невозможно. Есть AnotherClass — должен быть у него конструктор копирования. Как он устроен — меня не интересует, а работать будет. GZ>А если конструктора нет?
Не быть его не может (будет дефолтный). А вот закрыть его можно (сделать private)
Здравствуйте, vdimas, Вы писали:
AVK>>Я что то совсем перестал понимать твой русский язык. Как может оценочный критерий быть практикой?
V>Было сказано "относится к разряду практик".
Еще менее понятно.
V> Или же он имеет под собой теоретическое обоснование?
Здравствуйте, IT, Вы писали:
IT>Наиболее частая ошибка которую я вижу и в своей практике и иногда здесь на форумах — это перевод средсв достижения целей в разряд самих целей. Т.е. большинство проблем начинает возникать когда ООП дизайн или паттерны становятся целями, а не средствами их достижения.
А можно реальный пример на форумах? Сдается мне что вы боретесь с ветряными мельницами.
Здравствуйте, jhfrek, Вы писали:
J>Супер рассказ. Я столкнулся с подобным в своем старом коде, когда пришла пора его оптимизировать. Самое обидное — это то, что "оптимизируя" его при написании я "наоптимизировал" совсем не то, а главное создал совершенно немодифицируемый код. Пришлось переписывать по-человечески, и, разумеется, те микрооптимизации оказались ненужными ибо макрооптимизация с лихвой перекрыла прошлый выигрышь от них.
Вот именно! Очень жаль, что без прямого тыканья носом многие так и не поняли о чем этот рассказ.
... << RSDN@Home 1.2.0 alpha rev. 618>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, vdimas, Вы писали:
V>в ветке насчет паттернов вынужден был убить на это прилично времени. Виновато конечно стремление выдавать свои мысли как можно более сжато, надеясь на адекватное восприятие коллегами.
В ветке про паттерны ты бросил явно неостоножное высказывание и вместо того чтобы просто признать ее ошибочность и согласиться с АВК начал изворачиваться. Заметь с IT никто не спорит. Так что если ты с ним согласен, то должен понять, что никто не говорит "чтобы проектировать хорошие программы достаточно знать паттерны". Но обратное высказывание (твое, о котором идет речь) так же абсурдно.
... << RSDN@Home 1.2.0 alpha rev. 618>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[3]: Готовность системы к её последующим изменениям
Здравствуйте, AndrewVK, Вы писали:
AVK>А можно реальный пример на форумах? Сдается мне что вы боретесь с ветряными мельницами.
Такой пример найти легко. Просто нужно сделать поиск по слову Фаулер в Архитектуре. Фаулер башку многим сносит, а разум и стремление к простоте отключает.
Здравствуйте, AndrewVK, Вы писали:
AVK>Не знаю. Я не представляю как нужно извратить логику, чтобы трактовать его собственные фразы так как предлагается. Имхо это просто нежелание признаться в неправоте даже в мелочах.
Maybe.
С уважением, Gleb.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Re[4]: Готовность системы к её последующим изменениям
Здравствуйте, GlebZ, Вы писали:
AVK>>А можно реальный пример на форумах? Сдается мне что вы боретесь с ветряными мельницами. GZ>Такой пример найти легко. Просто нужно сделать поиск по слову Фаулер в Архитектуре. Фаулер башку многим сносит, а разум и стремление к простоте отключает.
Здравствуйте, Andrei N.Sobchuck, Вы писали:
ANS>А уж логику дикарей предсказать не берусь. Может "плоская" вылезла из какой-то ловушки, и все ей подражать начали
то были не дикари, а вполне даже "цивилизованные" европейцы. точнее, испанцы, если мне не изменяет память
Здравствуйте, AndrewVK, Вы писали:
AVK>Не знаю. Я не представляю как нужно извратить логику, чтобы трактовать его собственные фразы так как предлагается. Имхо это просто нежелание признаться в неправоте даже в мелочах.
Я уже давно признал, что выразился более сжато, чем стоило. И потратил время на несколько постов потом, чтобы лично тебе и Владу развернуть свою мысль. Вот тут последние ответы по этой теме: http://www.rsdn.ru/Forum/Message.aspx?mid=1482077&only=1
Здравствуйте, vdimas, Вы писали:
V>я все боялся озвучить эту мысль... но я имею более резкое мнение насчет изучения паттернов новичками. Не с них надо учиться проектировать, не с них. Поимев некий опыт самостоятельного нахождения решений, те, кто уже не новички, совсем по другому впитают эти паттерны, так сказать с гораздо большей пользой. Толку от того, что вместо условий задач студентам давать сразу ответы. Надо именно приучать самостоятельно решать задачи. А после приобретения некого опыта — давать наиболее часто встречающиеся случаи, чтобы в реальной практике не изобретать велосипеды, заодно снабдить терминологической базой.
Вообще-то паттерны как раз и даются как типовая задача. Задача с решением. Никто не мешает при изучении паттернов не показывать решение, а сподвигнуть учеников к самостоятельному поиску решения.
Однако же идея бросать новичков на произвол судбьбы и заставлять их проходить все на своем животе крайне порочна. Так как таким путем зания будут получаться значительно медленее и не факт, что в конечном итоге они вообще появятся. Это все равно как при обучении математики вместо чередования теории с практикой предлагать ученикам сразу решать сложные задачи. Конечно кто-то из них может их решит...
... << RSDN@Home 1.2.0 alpha rev. 618>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, GlebZ, Вы писали:
GZ>Нет. Ты по моему несколько некорректно прочитал его сообщение. Он высказал мнение о практике применении паттернов а не об их общей полезности(в чем существует множество аспектов). Правда он сделал несколько сумбурно ограничившись только паттернами дизайна.
Объясни мне, плиз, что можно не корректно понять в этой фразе:
Именно про этих уродцев я и говорил. И подмечал, что знание паттернов ничуть не помогает в разработке архитектуры.
... << RSDN@Home 1.2.0 alpha rev. 618>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, vdimas, Вы писали:
V>Здравствуйте, AndrewVK, Вы писали:
AVK>>Не знаю. Я не представляю как нужно извратить логику, чтобы трактовать его собственные фразы так как предлагается. Имхо это просто нежелание признаться в неправоте даже в мелочах.
V>Я уже давно признал, что выразился более сжато, чем стоило. И потратил время на несколько постов потом, чтобы лично тебе и Владу развернуть свою мысль. Вот тут последние ответы по этой теме: V>http://www.rsdn.ru/Forum/Message.aspx?mid=1482077&only=1
Возможно ты в очередной раз выразился очень сжато. Но вот что я вижу в твоем "рзборе полетов":
Своя цитата:
Именно про этих уродцев я и говорил. И подмечал, что знание паттернов ничуть не помогает в разработке архитектуры.
И следом фраза:
И я не НЕ СОБИРАЮСЬ отказываться от своих слов, т.к. действитльно уже дважды подмечал эту ситуацию.
Собственно с этим я и похоже АВК и не согласны. Обоснований этому мнению ты не привел. На мой взгяд это суждение крайне алогично и как верно заметил АВК является призывом к забивинию на паттерны начинающими. По карйней мере ее легко понять так. Все же остальные твои слова — это увретки и ужимки чтобы просто не сказать "да я так думаю" или "извините я не верно выразился".
... << RSDN@Home 1.2.0 alpha rev. 618>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, eao197, Вы писали:
VD>>Ты еще учти, что во многих случаях компиляторы просто инлайнят методы. Так же учти промахи мимо кэша. В реальном приложении и на CRect/RECT разница будет стримиться к нулю. Причем зачастую от ссылок на таких структурах ты проиграшь, так как промахи мимо кэша участятся. Ведь ты передашь параметр для использования. А значит компилятор породит код читающй уже содержимое структуры. Если она объявлена перед вызовом метода, то не беда, а если она лежит очень далего?
E>А если она передается через длинную цепочку вызовов методов?
Длинная это сколько? Да и опять таки не беда. Данные опять же будут в кэше.
... << RSDN@Home 1.2.0 alpha rev. 618>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, vdimas, Вы писали:
V>Было сказано "относится к разряду практик". Или же он имеет под собой теоретическое обоснование?
Кстати, "практик" — это такой мужик который что-то делает на практике. А практика во множественном числе вроде как не бывает. Но и без этого я тоже что-то тебя не понял.
... << RSDN@Home 1.2.0 alpha rev. 618>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
VD>В ветке про паттерны ты бросил явно неостоножное высказывание и вместо того чтобы просто признать ее ошибочность и согласиться с АВК начал изворачиваться. Заметь с IT никто не спорит. Так что если ты с ним согласен, то должен понять, что никто не говорит "чтобы проектировать хорошие программы достаточно знать паттерны". Но обратное высказывание (твое, о котором идет речь) так же абсурдно.
Не смеши, насчет неосторожного высказывания. Сдается мне, ты так и не посетил тот мой пост, а свое это умозаключение сделал из постов АВК.
, который ты для себя видимо посчитал точкой отсчета, состоит целиком из домысливаний и беседы с самим собой.
"паттерны не только бесполезны, но еще и вредны к тому же" ...
"Тогда расскажи мне — коль скоро мы отказываемся от паттернов" ...
"заявлению о том, что все парсеры вредны" ...
"тебе нужно подтверждать свои слова про вредность паттернов" ...
Короче, я так и не понял, с кем он там беседовал, и тем более не понял, как мне на все это отвечать, если эти фразы я первый раз у него в посте обнаружил. С какой радости ты так же требуешь от меня ответы на эти глупости — непонятно?
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Ну если мы начнем двойки друг другу ставить — боюсь, давно уже друг друга бы отчислили PD>По существу — естественоо, я имел в виду классы, а не структуры.
Классы в дотнете и Яве невозможно передавать по значению.
... << RSDN@Home 1.2.0 alpha rev. 618>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>В конце концов, sizeof(double) тоже > sizeof(void *), но вряд ли будет разумно и его везде по ссылке передавать. ТщательнЕЕ надо...
PD>+1.
Значит с double ты согласен? Тогда поясни, плиз, чем double отличается при передаче от POINT?
... << RSDN@Home 1.2.0 alpha rev. 618>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Еще раз — не в POINT дело. Его вполне можно и по значению передать. Дело в принципе — незачем большие структуры по значению передавать.
Здорово. Теперь вернись в верх по дереву и перечитай его еще раз. Увидишь много интересного.
... << RSDN@Home 1.2.0 alpha rev. 618>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, GlebZ, Вы писали:
GZ>Маленькая такая поправочка. Паттерны это не только паттерны дизайна(GoF). Паттерны могут быть ох как разными, и паттерны дизайна, не совсем, точнее всего, совсем не подходят под использование в архитектуре. Для этого случая, существуют свои паттерны.
Паттерн — это типовое решение, ничего более. Но в отличии процедур, они не могут быть закодированы один раз и сложены в библиотеки
... << RSDN@Home 1.2.0 alpha rev. 0>>
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, vdimas, Вы писали:
V>Было сказано "относится к разряду практик". Или же он имеет под собой теоретическое обоснование?
Если я правильно понял, ты хочешь сказать, что паттерны не имеют под собой теоретической базы. То есть они есть просто наиболее успешные практики. Так?
Здравствуйте, vdimas, Вы писали:
V>я все боялся озвучить эту мысль... но я имею более резкое мнение насчет изучения паттернов новичками. Не с них надо учиться проектировать, не с них. Поимев некий опыт самостоятельного нахождения решений, те, кто уже не новички, совсем по другому впитают эти паттерны, так сказать с гораздо большей пользой. Толку от того, что вместо условий задач студентам давать сразу ответы. Надо именно приучать самостоятельно решать задачи. А после приобретения некого опыта — давать наиболее часто встречающиеся случаи, чтобы в реальной практике не изобретать велосипеды, заодно снабдить терминологической базой.
V>Аналогично в шахматах. Есть куча известных комбинаций и заведомо известны оценки позиций фигур в этих комбинациях (и эти комбинации имеют свои названия). Однако новичкам их не преподают, их именно учать самостоятельно оценивать позиции фигур на доске. А известные комбинации... после достижения определенного уровня неплохо экономят время и помогают в общении с коллегами.
Согласен на 101%.
With best regards
Pavel Dvorkin
Re[3]: Готовность системы к её последующим изменениям
Здравствуйте, AndrewVK, Вы писали:
AVK>Думаю будут. Архитектор, который, вместо того чтобы обсудить какие то свои мысли в комьюнити (весьма профессиональном, хочу заметить) продолжает варится в собственном котле и убежден что здесь народ занимается ерундой, не профессионал вовсе, а надутый индюк.
Смотря где обсуждать. Если в "Архитектуре" или тематических форумах — это одно. А если он не хочет здесь светиться, дабы не получить десятки ценнейших советов на предмет правильного чтения из файла по байтам или копирования объектов на входе — может, он и прав....
Здравствуйте, AndrewVK, Вы писали:
AVK>Видишь ли, неумение признать себя неправым один из признаков непрофессионализма.
+1
>А если таковое умение есть, то ничего страшного в таких советах нет. Откровенную пургу нормалшьный человек профильтрует, а из остального получит крупицы ценной информации.
При условии, что есть время этим ситом заниматься. Вот у нас есть
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>При условии, что есть время этим ситом заниматься. Вот у нас есть
Ну, надо же на самосовершенествование выделять толику времени. Опять же, надеюсь, диссскуссии здесь хоть чуть чуть изменили твою точку зрения на критерии эффективности приложений. Если так, то в итоге страна получит больше хлеба (грамотных специалистов я имею ввиду)
Здравствуйте, AndrewVK, Вы писали:
AVK>Ну, надо же на самосовершенествование выделять толику времени. Опять же, надеюсь, диссскуссии здесь хоть чуть чуть изменили твою точку зрения на критерии эффективности приложений.
А твои ?
Про себя могу сказать вот что. На мое отношение к технической оптимальности — нет, не изменили. А вот на то, что в нынешних условиях порой возникают факторы, не лежащие в русле технической оптимальности (отношения с заказчиком, избыток ресурсов и т.д.) — в чем-то да. Хотя и здесь есть одно "но", которое я сейчас пытаюсь додумать. Может, еще одни постинг устрою
With best regards
Pavel Dvorkin
Re[5]: Готовность системы к её последующим изменениям
Здравствуйте, VladD2, Вы писали:
VD>По-моему, Фаулер как раз очень разумный человек. А если у кого от него бошку сносит, то пусть и не употребляет.
Никто и не говорил что он неразумный. Ошибки только в интерпретации и применении. Значительно важнее на этапе обучения прочитать методы попроще, например такую статью — http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnbda/html/BOAGag.asp. А затем переварив перейти к Фаулеру и уже говорить о применимости паттернов.
Здравствуйте, IT, Вы писали:
IT>Паттерн — это типовое решение, ничего более. Но в отличии процедур, они не могут быть закодированы один раз и сложены в библиотеки
Паттерны паттернам рознь. Некоторые паттерны дизайна, могут быть сгенерены автоматизированными средствами.
И еще, паттерны, к функциям не имеют никакого отношения. Паттерны — это формализованная модель решения которое по крайней мере описывает не только решаемую задачу, но и применимость.
В общем случае паттерн состоит из четырех основных элементов:
1. Имя. Сославшись на него, мы можем сразу описать проблему проектирова-
ния; ее решения и их последствия. Присваивание паттернам имен позволяет
проектировать на более высоком уровне абстракции. С помощью словаря
паттернов можно вести обсуждение с коллегами, упоминать паттерны в до-
кументации, в тонкостях представлять дизайн системы. Нахождение хоро-
ших имен было одной из самых трудных задач при составлении каталога.
2. Задача. Описание того, когда следует применять паттерн. Необходимо сфор-
мулировать задачу и ее контекст. Может описываться конкретная проблема
проектирования, например способ представления алгоритмов в виде объек-
тов. Иногда отмечается, какие структуры классов или объектов свидетель-
ствуют о негибком дизайне. Также может включаться перечень условий, при
выполнении которых имеет смысл применять данный паттерн.
3. Решение. Описание элементов дизайна, отношений между ними, функций
каждого элемента. Конкретный дизайн или реализация не имеются в виду,
поскольку паттерн — это шаблон, применимый в самых разных ситуациях.
Просто дается абстрактное описание задачи проектирования и того, как она
может быть решена с помощью некоего весьма обобщенного сочетания эле-
ментов (в нашем случае классов и объектов).
4. Результаты — это следствия применения паттерна и разного рода компро-
миссы. Хотя при описании проектных решений о последствиях часто не упо-
минают, знать о них необходимо, чтобы можно было выбрать между различ-
ными вариантами и оценить преимущества и недостатки данного паттерна.
Здесь речь идет и о выборе языка и реализации. Поскольку в объектно-ори-
ентированном проектировании повторное использование зачастую является
важным фактором, то к результатам следует относить и влияние на степень
гибкости, расширяемости и переносимости системы. Перечисление всех по-
следствий поможет вам понять и оценить их роль.
Это определение из GoF в котором они ссылались на Андриеску. Сами они не выбиваясь из общей задачи, описывали по другому
Название и классификация паттерна Назначение
Известен также под именем Мотивация
Применимость Структура Участники
Отношения Результаты
Реализация
Пример кода Известные применения
Родственные паттерны
Вот выделенное и не умеют интерпретировать. А вся информация для правильного применения решения есть.
Здравствуйте, AndrewVK, Вы писали:
AVK> Отрицательная, потому что перво-наперво приходится тратить массу усилий на избавление от дурацкий навыков, которым его научили в ВУЗе.
Лирика:
Предлагаю тост: "За наших наставников!" Почему-то мы вырастаем и забываем своих наставников, которые выбивали из нас всякую "дурь", а их надо помнить!
Здравствуйте, VladD2, Вы писали:
VD>Много красивых слов не относящихся к делу поскипано.
Это было доказательство что нет. VD>Еще раз задаю вопрос. Ты можещь как-то иначе интерпретировать эти слова?
Нет. У меня нет оснований опровергать систему решения силлогизмов придуманую не мной. Разница может быть только в контестно-зависимости(чего я здесь не вижу) и в эмоциальной оценке.
Здравствуйте, GlebZ, Вы писали:
IT>>Паттерн — это типовое решение, ничего более. Но в отличии процедур, они не могут быть закодированы один раз и сложены в библиотеки
GZ>Паттерны паттернам рознь. Некоторые паттерны дизайна, могут быть сгенерены автоматизированными средствами.
Могут. Более того, я думаю что когда это будет поддерживаться промышленными компиляторами так же как сейчас поддерживается OOP, то можно будет говорить о новом этапе в развитии индустрии.
... << RSDN@Home 1.2.0 alpha rev. 0>>
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, IT, Вы писали:
IT>Могут. Более того, я думаю что когда это будет поддерживаться промышленными компиляторами так же как сейчас поддерживается OOP, то можно будет говорить о новом этапе в развитии индустрии.
В принципе, декларативные языки этим и занимаются. Можно считать, что они и построены на наборе паттернов. [IMHO] Через чистый набор паттернов проектирования GoF по моему легко собирать, но трудно изменять. А у функциональных языков проблема в том, что для них удобней именно рекурсивные решения, но такие решения сложнее для человеческих мозгов. [конец IMHO]
Здравствуйте, IT, Вы писали:
IT>Могут. Более того, я думаю что когда это будет поддерживаться промышленными компиляторами так же как сейчас поддерживается OOP, то можно будет говорить о новом этапе в развитии индустрии.
Уже. Борланд, например, поддерживает паттерны в своих средствах проектрования.
... << RSDN@Home 1.2.0 alpha rev. 618>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Здравствуйте, eugals, Вы писали:
E>>Ну, и чему мы студентов учим?
PD>Тому , чему надо . Ты не понял суть моего высказывания
>>Аргумент простой — если он привыкнет передавать объекты с размером больше sizeof(void*) по значению — будет это и дальше делать, причем там, где это может серьезно сказаться.
PD>Здесь не идет речь о POINT, с ним, вполне возможно, разницы нет. Я имел в виду, что и в других случаях они будут это делать, там где размеры могут доходить до десятков и сотен байтов + конструктор копирования. Если не привыкнут сразу думать о том, что они передают и во что это превращается в коде.
Вы опять учите студентов абсолютным истинам и идеалам... В общем то, это характерно для всего нашего ит образования, как уже писалось...
Здравствуйте, VladD2, Вы писали:
VD>Уже. Борланд, например, поддерживает паттерны в своих средствах проектрования.
Вообще-то не только Борланд. XDE, DSL Tools, и наверняка список можно продолжить(R# в конце концов ).
Здравствуйте, GlebZ, Вы писали:
VD>>Уже. Борланд, например, поддерживает паттерны в своих средствах проектрования. GZ>Вообще-то не только Борланд. XDE, DSL Tools, и наверняка список можно продолжить(R# в конце концов ).
R#, как я понимаю, остановился в своём развитии на пол пути. А что умеют XDE и DSL Tools?
... << RSDN@Home 1.2.0 alpha rev. 0>>
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, Nickolay Ch, Вы писали:
NC>Вы опять учите студентов абсолютным истинам и идеалам... В общем то, это характерно для всего нашего ит образования, как уже писалось...
И слава богу, что хоть в образовании еще истина есть...
Здравствуйте, IT, Вы писали:
IT>R#, как я понимаю, остановился в своём развитии на пол пути. А что умеют XDE и DSL Tools?
Не знаю, точно. Только по картинкам смотрел. Все времени не хватает.
Здравствуйте, vdimas, Вы писали:
V>Единственно, где требуется "эквилибристика ума" в чистом виде, или даже состязание в хорошем вкусе, так это в ситуации, когда сценарии использования не даны и их надо проектировать самому. Однако, все набирающий по численности класс аналитиков считает, что проектировщики систем к этой процедуре не должны лежать никаким боком. Это только их хлеб и они, типа, умеют это лучше всего, учитывая их времяпрепровождение в общении с заказчиком в качестве доктора-психолога. Вероятно, они правы.
Команда должна оставаться всегда командой. Консультации архитектора, или лица который выполняет его обязанности должны вестись еще на стадии определения границ проекта. Вот тут действительно важен опыт и эквилибристика ума. Оценить то, чего еще нет. При написании требований — показ каждого требования архитектору до того, как оно ушло к пользователю уже обязательно. Это понимает каждый адекватный PM.
AVK>>Сейчас ситуация еще хуже — в качестве архитектора современный студент величина отрицательная. Отрицательная, потому что перво-наперво приходится тратить массу усилий на избавление от дурацкий навыков, которым его научили в ВУЗе. V>Если кто-то величина отрицательная в этом деле после 5-ти лет учебы, так может не стоит и время тратить на "выбивание"?
Почему так ценятся у нас выпукники ВМК МГУ. Да потому что они думать умеют. А остальному таких людей легко научить.
V>Да, мало выходит толковых ребят, менее 10% (по личному наблюдению около 10 толковых было из 100 человек потока, а девушки вообще непонятно зачем на IT учатся). Я же говорил уже многократно, что корень большинства проблем молодого поколения в том, что в IT идут люди, которым не стоит туда идти. Пруться как танки в IT из-за высоких ЗП все подряд, портят общую статистику. Переиначивают понятия, путают ср-ва с целями (как во всей этой ветке про паттерны).
А лишние люди быстро сами вымываются из IT. Легко учиться и зубрить, а работать, если у тебя голова не настроена в нужном диапазоне, невозможно. Таких людей видел достаточно, работают обычно не дольше двух недель. Сами уходят.
2 Moderators: Приношу извинения за оффтоп, форс-мажор небольшой, завтра днём проголосую сей оффтоп грохнуть.
2 All: Просьба на это сообщение не отвечать.
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Здравствуйте, vdimas, Вы писали:
V>Не так уж мало.
По современным меркам катастрофически мало.
V>Достаточно общий термин "входные/выходные данные" подменить на частные "сигналы и протоколы взаимодействия" и получим ОО-анализ в действии
Не получим. Либо это какой то странный своей убогостью анализ.
V>Да и бог с ним ОО-анализом, это тоже частный случай частных подсистем. Если я видел ошибки проектирования, то обычно причина их была в элементарной невнимательности или небрежности.
Значит тебе повезло. Все таки, если человек серьезно относится к своей работе, то ошибки там совсем другие. По большей частью вызванные непониманием того, что он делает. Тут не зря народ в один голос твердит — архитектор должен писать код.
V>Единственно, где требуется "эквилибристика ума" в чистом виде, или даже состязание в хорошем вкусе, так это в ситуации, когда сценарии использования не даны и их надо проектировать самому. Однако, все набирающий по численности класс аналитиков считает, что проектировщики систем к этой процедуре не должны лежать никаким боком. Это только их хлеб и они, типа, умеют это лучше всего, учитывая их времяпрепровождение в общении с заказчиком в качестве доктора-психолога. Вероятно, они правы.
Мне кажется ты о другом говоришь. Классический software architect озабочен не сценариями импользования. Задача обычно ставится совсем иначе — есть требуемый и желаемый функционал, есть определенное количество разработчиков, есть уже написанные куски, есть планы по развитию, есть еще куча мелких факторов. Задача — реализовать максимально качественно максимальный функционал за минимальное время.
А уточнение сценариев это уже совсем другой специалист.
AVK>>Сейчас ситуация еще хуже — в качестве архитектора современный студент величина отрицательная. Отрицательная, потому что перво-наперво приходится тратить массу усилий на избавление от дурацкий навыков, которым его научили в ВУЗе.
V>Если кто-то величина отрицательная в этом деле после 5-ти лет учебы, так может не стоит и время тратить на "выбивание"?
Стоит. Иначе у нас бы вобще таких специалистов не было.
V>Да, мало выходит толковых ребят, менее 10% (по личному наблюдению около 10 толковых было из 100 человек потока, а девушки вообще непонятно зачем на IT учатся). Я же говорил уже многократно, что корень большинства проблем молодого поколения в том, что в IT идут люди, которым не стоит туда идти. Пруться как танки в IT из-за высоких ЗП все подряд, портят общую статистику. Переиначивают понятия, путают ср-ва с целями (как во всей этой ветке про паттерны).
Здравствуйте, AndrewVK, Вы писали:
AVK>Здравствуйте, Pavel Dvorkin, Вы писали:
PD>>Ох, боюсь, что именно они профессионалы, а не все мы здесь, грешные. Ну разве профессионалы будут обсуждать нелепые конструкции и доказывать , что они нелепые ?
AVK>Думаю будут. Архитектор, который, вместо того чтобы обсудить какие то свои мысли в комьюнити (весьма профессиональном, хочу заметить) продолжает варится в собственном котле и убежден что здесь народ занимается ерундой, не профессионал вовсе, а надутый индюк.
Да не, бывают просто другие, чуть более "направленые" форумы в и-нете по этому направлению. Хотя относительно философии программирования — против истины не попрешь, именно тут беседы самые увлекательные, спасибо VladD2 и Co
Здравствуйте, AndrewVK, Вы писали:
V>>Достаточно общий термин "входные/выходные данные" подменить на частные "сигналы и протоколы взаимодействия" и получим ОО-анализ в действии
AVK>Не получим. Либо это какой то странный своей убогостью анализ.
В любом случае, в основе ОО-проектирования лежит декомпозиция, я намекал на нее.
AVK>Значит тебе повезло. Все таки, если человек серьезно относится к своей работе, то ошибки там совсем другие. По большей частью вызванные непониманием того, что он делает. Тут не зря народ в один голос твердит — архитектор должен писать код.
Выходит, повезло. Мне даже трудно представить на месте архитектора человека, который не понимает, что он делает (!!!). Даже в том пресловутом недавнем случае коллег про "промах" в дизайне было очевидно, что имело место небрежность, она же — шапкозакидательство, ввиду веры в "магическую силу" паттернов. Т.е. элементарно не потрудились провести еще пару итераций и уточнений.
V>>Единственно, где требуется "эквилибристика ума" в чистом виде, или даже состязание в хорошем вкусе, так это в ситуации, когда сценарии использования не даны и их надо проектировать самому. Однако, все набирающий по численности класс аналитиков считает, что проектировщики систем к этой процедуре не должны лежать никаким боком. Это только их хлеб и они, типа, умеют это лучше всего, учитывая их времяпрепровождение в общении с заказчиком в качестве доктора-психолога. Вероятно, они правы.
AVK>Мне кажется ты о другом говоришь. Классический software architect озабочен не сценариями импользования.
По-моему, я именно эту мысль и высказал. Однако — это классический software architect (скорее — идеальный). На практике, отдельную роль аналитика могут себе позволить не все конторы, и эти роли совмещают.
AVK>Задача обычно ставится совсем иначе — есть требуемый и желаемый функционал, есть определенное количество разработчиков, есть уже написанные куски, есть планы по развитию, есть еще куча мелких факторов. Задача — реализовать максимально качественно максимальный функционал за минимальное время.
Тут ты уже примешал роль PM, извини. Правда их тоже часто смешивают. В идеале все упомянутые роли должны работать в связке и как результатом своей деятельности выходить на конкретные ТЗ разработчикам с одной стороны (как следствие разработанной архитектуры/функционала), так и на Project Plan с другой стороны (как результат экономического планирования: ресурсы, время и т.д.).
AVK>А уточнение сценариев это уже совсем другой специалист.
Опять же, в идеале. Да, собственно, и я так же считаю.
AVK>Стоит. Иначе у нас бы вобще таких специалистов не было.
Наверно, у тебя есть конкретные примеры, раз ты так настаиваешь. Можно пару слов о конкретных ошибках? Мне уже интересно, возможно это будет поучительно и мне.
V>>Да, мало выходит толковых ребят, менее 10% (по личному наблюдению около 10 толковых было из 100 человек потока, а девушки вообще непонятно зачем на IT учатся). Я же говорил уже многократно, что корень большинства проблем молодого поколения в том, что в IT идут люди, которым не стоит туда идти. Пруться как танки в IT из-за высоких ЗП все подряд, портят общую статистику. Переиначивают понятия, путают ср-ва с целями (как во всей этой ветке про паттерны).
AVK>Вывод из этого какой?
Кесарю — кесарево. Нам, например, сейчас требуется довольно много людей в команду. И есть уже приличная база резюме, однако... По-любому нужен сильный костяк. Я не рискну доверить опытному разработчику большее количество малоопытных, чем он сможет адекватно "переварить". На мой взгляд, это соотношение должно быть не хуже 1:1. Если в других конторах наблюдается перекос — то это их личное право так рисковать.
Здравствуйте, VladD2, Вы писали:
AVK>>>Не знаю. Я не представляю как нужно извратить логику, чтобы трактовать его собственные фразы так как предлагается. Имхо это просто нежелание признаться в неправоте даже в мелочах.
V>>Я уже давно признал, что выразился более сжато, чем стоило. И потратил время на несколько постов потом, чтобы лично тебе и Владу развернуть свою мысль. Вот тут последние ответы по этой теме: V>>http://www.rsdn.ru/Forum/Message.aspx?mid=1482077&only=1
VD>Возможно ты в очередной раз выразился очень сжато. Но вот что я вижу в твоем "рзборе полетов": VD>Своя цитата: VD>
Именно про этих уродцев я и говорил. И подмечал, что знание паттернов ничуть не помогает в разработке архитектуры.
VD>И следом фраза: VD>
И я не НЕ СОБИРАЮСЬ отказываться от своих слов, т.к. действитльно уже дважды подмечал эту ситуацию.
VD>Собственно с этим я и похоже АВК и не согласны. Обоснований этому мнению ты не привел.
Че-то я окончательно запутался. Ты не согласен с тем, что я это подмечал? По приведенным ссылкам я раскрыл ситуацию более подробно. Дальнейшая подробность — это выкладывать сюда куски проекта с пояснениями.
Или ты не согласен с тем выводом, который я сделал на основе своих наблюдений. Если последнее, так это твое демократическое право, однако сути происходящего оно не меняет и тенденция имеет место быть. А именно — слепая вера в заведомую грамотность дизайна, если в нем использовались паттерны. Нет этой зависимости.
Действительно смешно было пытаться приписать мне мысль о том, что "паттерны вредны". Смешно именно потому, как следующий очевидный логический вывод: "учиться вообще вредно".
Вредным является восприятие чего-либо на веру. И пусть себе народ ползает на животе в выбранном направлении. У меня фраза "ползать на животе" ассоциируется с "пробовать, ошибаться, думать, сравнивать, подглядывать в ответ, снова решать" и т.д. ИМХО, полезное времяпрепровождение...
А насчет того твоего высказывания, что наука потому и движется вперед, что мы пользуемся знаниями предков как трамплином... Я не думаю, что люди стали умнее физиологически. Наука двигается вперед в основном благодаря всю более глубокой и необратимой специализации. Ты еще должен был застать времена, когда слово "программист" обозначало сразу всё. А теперь оно не обозначает НИЧЕГО, без указания специализации.
VD>На мой взгяд это суждение крайне алогично и как верно заметил АВК является призывом к забивинию на паттерны начинающими. По карйней мере ее легко понять так. Все же остальные твои слова — это увретки и ужимки чтобы просто не сказать "да я так думаю" или "извините я не верно выразился".
Здравствуйте, vdimas, Вы писали:
AVK>>Не получим. Либо это какой то странный своей убогостью анализ.
V>В любом случае, в основе ОО-проектирования лежит декомпозиция, я намекал на нее.
Да пофигну что там лежит в основе. Главное — то что рассказывают ныне в вузах имеет к реальной практике проектирования очень отдаленное отношение.
V>Выходит, повезло. Мне даже трудно представить на месте архитектора человека, который не понимает, что он делает (!!!).
Тем не менее 100% даже талантливых выпускников этого не понимают.
V>По-моему, я именно эту мысль и высказал. Однако — это классический software architect (скорее — идеальный). На практике, отдельную роль аналитика могут себе позволить не все конторы, и эти роли совмещают.
Все мало мальски серьезные конторы, которые я видел, все таки старались эти моменты разделить. Уж слишком сильно разнятся требуемые навыки.
AVK>>Задача обычно ставится совсем иначе — есть требуемый и желаемый функционал, есть определенное количество разработчиков, есть уже написанные куски, есть планы по развитию, есть еще куча мелких факторов. Задача — реализовать максимально качественно максимальный функционал за минимальное время.
V>Тут ты уже примешал роль PM, извини.
Неа. PM в классическом понимании должен организовывать процесс. Технические моменты как правило вне его компетенции. PM это прежде всего менеджер, а уж потом программист.
AVK>>Стоит. Иначе у нас бы вобще таких специалистов не было.
V>Наверно, у тебя есть конкретные примеры, раз ты так настаиваешь.
Конечно.
V> Можно пару слов о конкретных ошибках? Мне уже интересно, возможно это будет поучительно и мне.
Ну так чтобы сразу не напишу. Скажем одна из самых неприятных — стремление съэкономить на архитектуре. Очень часто бывает, что есть решение, требующее большого объема проектирования, но сравнительно дешевого кодирования, и есть наоборот — легко проектировать и долго кодировать. Очевидно что первое предпочтительнее, потому что объем кодирования стукнет по башке многократно, но по неопытности народ очень часто это не понимает. Еще из этого же разряда — если система состоит из нескольких кусков, то часто стремятся упростить проектируемый кусок, не думая о том, какие последствия будут для других частей. Например при проектировании сильно упрощать клиента за счет усложнения сервера и увеличения нагрузки на коммуникации.
Еще очень мешает, когда начинают переносить решения из одной области в другую без оглядки на их применимость.
А вот с пиханием куда не попадя паттернов я еще ни разу на практике не сталкивался, зато с незнанием онных сталкиваюсь регулярно.
Здравствуйте, vdimas, Вы писали:
PD>>>Ох, боюсь, что именно они профессионалы, а не все мы здесь, грешные. Ну разве профессионалы будут обсуждать нелепые конструкции и доказывать , что они нелепые ?
AVK>>Думаю будут. Архитектор, который, вместо того чтобы обсудить какие то свои мысли в комьюнити (весьма профессиональном, хочу заметить) продолжает варится в собственном котле и убежден что здесь народ занимается ерундой, не профессионал вовсе, а надутый индюк.
V>Да не, бывают просто другие, чуть более "направленые" форумы в и-нете по этому направлению.
Речь шла не про конкретно данный форум, а про форумы вобще.
AVK>Ну так чтобы сразу не напишу. Скажем одна из самых неприятных — стремление съэкономить на архитектуре. Очень часто бывает, что есть решение, требующее большого объема проектирования, но сравнительно дешевого кодирования, и есть наоборот — легко проектировать и долго кодировать.
Ну да, когда-то я уже высказывался здесь, но применительно к библиотекам, что структура библиотеки должна подразумевать не столько легкое кодирование самой библиотеки, сколько легкость использования (собственно, для чего функционал в либы и выделяют). Однако, этот принцип применим даже к традиционному структурному подходу к проектированию ПО (не говоря уже об ОО) и этому все-таки учат.
AVK>Еще из этого же разряда — если система состоит из нескольких кусков, то часто стремятся упростить проектируемый кусок, не думая о том, какие последствия будут для других частей.
Да и этому тоже учат — сисемный подход. Анализ взаимодействия подсистем. Разбиение функционала по принципу минимизации связей м/у выделенными подсистемами. Эта минимизация обычно прямо или коссвено влияет на "последствия" и "сложность".
AVK>Например при проектировании сильно упрощать клиента за счет усложнения сервера и увеличения нагрузки на коммуникации.
Хм... вот спорно, без дополнительных вводных. Например у нас есть некий мета-енжин на клиенте и сервере. Не скажу, что простой, но реализованные на его основе клиенты действительно просты и буквально "накидываются мышкой". И, разумеется, наличие мета-информации — это лишний трафик. Другое дело, что с этим легко бороться, если предположить, что метаинформация для запущенного экземпляра сервера неизменна, то ее можно просто кешировать.
AVK>Еще очень мешает, когда начинают переносить решения из одной области в другую без оглядки на их применимость.
AVK>А вот с пиханием куда не попадя паттернов я еще ни разу на практике не сталкивался,
2 последних предложения подразумевают потенциальное противоречие
Т.е. если наблюдается первое, то ненулевая вероятность наблюдения второго. Просто ты не наблюдал.
AVK>зато с незнанием онных сталкиваюсь регулярно.
Ну... я тоже далеко не с пеленок с ними столкнулся... Однако, ведь не спроста подавляющую их часть воспринял за "старых знакомых". Т.е. подход не менее важен.
Здравствуйте, vdimas, Вы писали:
V>Ну да, когда-то я уже высказывался здесь, но применительно к библиотекам, что структура библиотеки должна подразумевать не столько легкое кодирование самой библиотеки, сколько легкость использования (собственно, для чего функционал в либы и выделяют). Однако, этот принцип применим даже к традиционному структурному подходу к проектированию ПО (не говоря уже об ОО)
Безусловно.
V> и этому все-таки учат.
Не замечал.
AVK>>Еще из этого же разряда — если система состоит из нескольких кусков, то часто стремятся упростить проектируемый кусок, не думая о том, какие последствия будут для других частей.
V>Да и этому тоже учат — сисемный подход.
Тоже не замечал. У всех молодых специалистов в этом плане полный ноль. Они поначалу просто непонимают о чем ты им говоришь и делают круглые глаза.
AVK>>Например при проектировании сильно упрощать клиента за счет усложнения сервера и увеличения нагрузки на коммуникации.
V>Хм... вот спорно, без дополнительных вводных.
Речь не о конкретике, а о принципе. Один и тот же человек проектируя клиента усложняет сервер, потом, проектируя сервер, усложняет клиента. Просто потому что у него мысль о том, что думать надо о системе в целов даже не возникает.
AVK>>зато с незнанием онных сталкиваюсь регулярно.
V>Ну... я тоже далеко не с пеленок с ними столкнулся... Однако, ведь не спроста подавляющую их часть воспринял за "старых знакомых". Т.е. подход не менее важен.
Здравствуйте, AndrewVK, Вы писали:
AVK>Речь не о конкретике, а о принципе. Один и тот же человек проектируя клиента усложняет сервер, потом, проектируя сервер, усложняет клиента. Просто потому что у него мысль о том, что думать надо о системе в целов даже не возникает.
В общем, пора rsdn-овцам прекращать тусоваться по разным конторам и бороться с, во многом, исскуственными проблемами. Собраться, блин, в один мощный кулак, и писать самый конкурентноспособный софт на свете
А иначе какой толк в обучении молодого поколения, которое, насколько я понял, не потрудилось вынести из 5-летнего протирания штанов даже азы. Где та увлеченность, и не побоюсь этого слова "преданность" своему делу? Подобный "молодой специалист" чуть понабравшись опыта будет ерзать на своем стуле и искать следующее место потеплее. Толку от вложений в него драгоценнейшего времени? У программистов в Питере/Москве в возрасте до 27 лет среднее время пребывания на одном месте 1 год. Смешно, не правда ли? Да — дефицит, да — head-hunting, но таким людям обсуждаемые здесь вопросы мягко говоря до одного места, и принцип "лишь бы работало" — рулит. Ведь за это платят и платят нехило...
Так что, я бы делил на "стремящихся" и всех остальных. Первые априори должны были вынести если не с лекций, то по крайней мере из собственного любопытства и изучения те самые азы. (благо интернет весьма доступен последние годы для всех).
Именно про этих уродцев я и говорил. И подмечал, что знание паттернов ничуть не помогает в разработке архитектуры.
...
И я не НЕ СОБИРАЮСЬ отказываться от своих слов, т.к. действитльно уже дважды подмечал эту ситуацию.
...
Действительно смешно было пытаться приписать мне мысль о том, что "паттерны вредны".
Вспоминается анекдот про Штирлица:
Идет сикретное заседание в бункере Гитлера...
Вдруг входит штирлиц с блюдом апельсинов. Необращая ни на кого внимания проходит к сейфу. Открывает его. Берет бумаги. Разворачивается и уходит.
Кто-то из новеньких спрашивает:
— Кто это? И почему мы его не остановили?
— А это Штирлиц — русский разведчик. А что до "почему не остановили", дык все равно ведь собака выкрутится. Скажет, что апельсины приносил.
V>извините я не верно выразился
Давно бы так. И не пришлось апельсины с собой всюду таскать.
... << RSDN@Home 1.2.0 alpha rev. 618>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, vdimas, Вы писали:
V>Выходит, повезло. Мне даже трудно представить на месте архитектора человека, который не понимает, что он делает (!!!). Даже в том пресловутом недавнем случае коллег про "промах" в дизайне было очевидно, что имело место небрежность, она же — шапкозакидательство, ввиду веры в "магическую силу" паттернов. Т.е. элементарно не потрудились провести еще пару итераций и уточнений.
Ты уверен, что ещё пару итераций помогли бы избежать веру в паттерны? Мне кажется эти вещи абсолютно никак не связаны.
... << RSDN@Home 1.2.0 alpha rev. 0>>
Если нам не помогут, то мы тоже никого не пощадим.
Однако существуют и некоторые особенности российского образования в области информатики. В нем, по сравнению с американской системой образования, придается большее значение фундаментальному математическому образованию и несколько меньшее значение естественным наукам и профессиональной подготовке. Это связано с тем, что компьютерные науки в России создавались преимущественно математиками, традиционно отдающими предпочтение фундаментальным знаниям. Овладение такими знаниями в наибольшей степени способствует формированию мышления обучающихся. Причина различий здесь в том, что в России компьютерные науки и соответствующие образовательные программы исторически преимущественно математические, а в Америке — инженерные.
Следствием этого является то, что американский стиль обучения ориентирован на изучение процесса набора стандартных решений под типовые ситуации. Российский стиль обучения подразумевает осмысление принципов получения решения и понимание важности развития решения задачи до обобщенного подхода.
Здравствуйте, IT, Вы писали:
IT>Здравствуйте, vdimas, Вы писали:
V>>Выходит, повезло. Мне даже трудно представить на месте архитектора человека, который не понимает, что он делает (!!!). Даже в том пресловутом недавнем случае коллег про "промах" в дизайне было очевидно, что имело место небрежность, она же — шапкозакидательство, ввиду веры в "магическую силу" паттернов. Т.е. элементарно не потрудились провести еще пару итераций и уточнений.
IT>Ты уверен, что ещё пару итераций помогли бы избежать веру в паттерны? Мне кажется эти вещи абсолютно никак не связаны.
Да фиг с ней, с верой. Опустись они чуть ниже (на более детальную реализацию подсистем), сами бы увидели несоответствие.
Отмазка. У буржуинов бывают разные системы обучения.
Наши проблемы в том, что в институтах есть хорошие математики, но нет хороших разработчиков. Хорошие разработчики не работают в институтах. Второе — в большинстве институтов(университетов) готовят программистов для определенной предметной области, и этой предметной областью захламляют мозги. А эта предметная область бывает слишком обособленна от других процессов разработки. И третье, некоторые вещи имеют большой недостаток. Они не входят в ГОСТ. Отношение к госту как к непререкаемой истине, в нашей системе обучения, не вдохновляет.
Здравствуйте, vdimas, Вы писали:
IT>>Ты уверен, что ещё пару итераций помогли бы избежать веру в паттерны? Мне кажется эти вещи абсолютно никак не связаны.
V>Да фиг с ней, с верой. Опустись они чуть ниже (на более детальную реализацию подсистем), сами бы увидели несоответствие.
Это у меня как раз и вызывает наибольшее сомнение. Что значит спуститься ниже и увидеть? Что там в низу?
... << RSDN@Home 1.2.0 alpha rev. 0>>
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, vdimas, Вы писали:
V>Вот ты какие задачи решал на зимней и летней практике первого курса, помнишь? У нас было дано окол 20 задач (могу и ошибаться в количестве, наверно — больше), все они — типа запрограммировать такой-то алгоритм решения дифуров или матрицы обратить (не путать с перестановкой элементов) и т.д. После 3-го курса на тех же практиках требовалось написать ассемблер (с ограниченной системой команд) и эмулятор CPU, на которому множество твоих команд исполнялось. Причем, требовалось писать "как положено", т.е. лексический/синтаксический анализ для ассемблера и табличный диспетчер для эмулятора. Групповая курсовая работа на том же 3-м курсе — мини ОС для машины, придуманой Кнутом. Эмулятор его CPU (на котором он свои алгоритмы приводил), загрузчик, файловая система, ядро, планировщик, подсистема ввода/вывода...
Респект, однако! Нам до этого далеко было...
... << RSDN@Home 1.1.4 stable rev. 510>>
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, vdimas, Вы писали:
V>Когда я увидел, что кто-то меня не так понял, я не поленился объясниться подробней.
V> Мне ведь, глубоко фиолетово, что там домыслил АВК, ибо все остальные читатели поняли именно то, что я хотел сказать (сужу по их замечаниям).
А, ну тебе конечно виднее. А главное, что именно ты имешь право говорить за всех.
V> Почему фиолетово — потому как АВК не идет на обсуждение.
Есть и другая версия — это vdimas всячески пытается превратить обсуждение во флуд. И, делает это потому, что понял что сморозил глупость, но признать свою неправоту не может.
V>Понимаешь, тут никто не расписывает многотомные трактаты, все выражаются по-возможности кратно,
Оно и видно.
V> надеясь на адекватное восприятие коллег по цеху. Если ты чего-то не допонял, дык уточни, желательно корректно, и мир станет гораздо лучше.
У тебя уточняли не раз. Результат уточнений и привден в цитатах.
V>Но куда там... это было просто верхом вежливости с твоей стороны называть пояснения собственной точки зрения увертками.
Думаю любой непредвзятый человек прочитавший цитаты твоих сообщений вряд ли назовет твои слова "пояснениями собственной точки зрения".
Меня вообще радует то рвение с которым ты переходишь к обсуждению адекватности оппонентов. Особенно это радует на фоне твоих же слов.
V> Вот он — здравствуй бред! "Мы тебя поняли так-то и так-то, даже если ты имел ввиду другое, это уже не имеет значения и учти, у тебя нет права на пояснения. Ты можешь только умолять о пощаде. В крайнем случае великий и ужасный Я согласен на извинения"
Ненадо делать вид что тебя кто-то непонял. Тебе пресросили имел ли ты в виду, то что написал. Твой ответ был однозначным. Ну, а то что он противоречит твоему же ответу данному позже говорит о чем угодно но только не об неадекватности твоих оппонентов.
V>(и пощади rsdn-овскую базу ради дел праведных, хватит фигню всякую пережевывать, это как совет "зрителя из зала", коим большую часть времени являюсь)
Я предлагаю тебе перестать спекулировать на темамх святости rsdn-а и неадекватности оппонентов. За одно воздержаться от обсуждения чужиш личностей, хотя бы, в контексте обсуждения твоих слов.
... << RSDN@Home 1.2.0 alpha rev. 618>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
В общем, весь этот "флуд" с моей стороны скорее вызван твоей манерой ведения беседы, типа "изворачиваешься", "юлишь"... Короче, модератора на тебя нет.
Когда я увидел, что кое-кто истолковал мои слова не так, как мне хотелось, я потрудился развернуть тему. И буквально там же, рядом с выдранными цитатами уточнил, что знание одних только паттернов не помогает и далее по тексту. И ссылки на истоки обсуждения уже давал. (Поменьше бы вырывал цитаты из десятой перепечатки, и по-другому бы воспринял мою т.з.) Кому и что еще может быть непонятно? Это твердолобость или желание поразвлекаться?
Пообточил свой словарный запас не лучшим образом и плюешь им в оппонента: "смороженная глупость" и т.д. Не много ли берем на себя? Я реально неоднократно наблюдал подобные факты, их и упомянул. В крайнем случае ты мог бы сказать так: "я тебе не верю, ты все это придумал". И то не факт, что это было бы корректно. Так что, твои манеры никак на адекватность не тянут, извини.
И упертость твоя — тоже вешь неоднократно продемонстрированная. Предоставляю шанс оставить это сообщение без ответа.
Здравствуйте, vdimas, Вы писали:
V>В этом месте ты уже забыл, что я настаивал на выборе оптимального инженерного решения, и обращал внимание, что сам этот выбор может ничего не стоить.
если ты делаешь выбор, то это уже создает дополнительные затраты, не так ли?
к тому же выбор может быть сделан неправильно, что подтверждается массой примеров
Здравствуйте, VladD2, Вы писали:
V>>что знание одних только паттернов не помогает и далее по тексту.
VD>Тебя сразу переспросили по поводу этих слов. Но вместо того чтобы просто сказать "я неверно выразился" ты развел флуд. Причем продолжашь делать это и дальше. Переводя обсуждение на личности. Вопрос — зачем?
Ну тогда тем более твоя позиция непонятна, твой пост насчет "юлишь" и "изворачиваешься" был уже после того, как я уточнил выделенное выше. Согласись, что после подобного уточнения было весьма трудно понять, от чего же я, собственно, изворачивался или от каких слов должен был отказываться.
Здравствуйте, GlebZ, Вы писали:
V>>Да, проблема в ВУЗ-ах в первую очередь с кадрами, но проблема чуть другая. Не платят нихрена. При мне в 93-95-е уходили в первую очередь сильные как преподаватели и как личности. Уходили строить свою новую жизнь в этой стране, которая их "кинула". Больно и обидно было на это смотреть. Я сам остался в ВУЗе в аспирантуре, но пробыл там... ровно месяц. После получения первой "ЗП" срочно побежал искать работу GZ>Мне тут дали почитать один внутривузовский документик. Оказалось что в Москве, между ведущими вузами уже существует конкуренция. И зарплаты там за преподавание достаточно нормальные. Для ведущих преподователей.
Ну... я рад за Москву, все у нее будет хорошо.
У нас тоже последние пару лет ЗП приподняли преподователям в вузах. Только поздно, малость. Преемственности не было. Лучшие поуходили и не вернулись. Те, что остались, 10 лет больше о выживании думали, чем о собственном росте как преподавателя... Надеюсь, что Москва сдемпфирует этот эффект законом больших чисел. Кто-то же должен был остаться.
V>>И откуда ты взял про "нет хороших разработчиков"? Классический советский ВУЗ — это в первую очередь куча тем для разработок. "Тема" — это такой институтский термин, сейчас почти не используется. Мне довелось с 3-го по 5-й курс работать в лаборатории, делали весьма сложные проекты (хард+софт). Подозреваю, что ты учился в "постсоветское" время. Конкретно наша лаборатория развалилась в 95-м году. Как раз из-за ухода ведущих спецов. GZ>Учился да. Я вот работал в науке с 92-по 97. Раньше главным заказчиком было государство. Потом государству стало по фигу. А новых заказчиков тогда еще не научились искать. Вот и развалилось все. Те кто у нас научился находить, и сейчас неплохо живут.
Получить заказ в 1995-м на техническую разработку на Украине было не реально... Тогда не было НИ ОДНОГО ЗАКАЗЧИКА, и при этом как раз вышел закон, запрещающий разработки на околовоенные темы по заказу других гос-в. Последний проект, который делали — это система измерения качки судов. На судно ставится наш прибор — суть куча гироскопов, датчики, и мощная самописная математическая приблуда для обсчета показаний. По морю раскидываются цифровые датчики волнения (лично мною разработанные и в количестве 5 шт изготовленные для испытаний, от А до Я, , кроме радиоканала, который соседняя кафедра проектировала) И система сопоставляет реакцию судна с внешними условиями. Испытывали военные корабли, заказчик — гос.контора из Питера. Собственно, после принятия упомянутого закона, наше направление благополучно накрылось.
Я попрежнему подозреваю, что в Москве/Питере "хоть кто-то выжил".
GZ>Дурацкая популистская идея. Несмотря на некоторые выпендрежи, у буржуях образование могут получить фактически все. Для этого надо изначально хорошо учиться, и взять кредит который будешь возвращать. Тогда и качество образования для самого человека вещь важная. И качество образование выше в материальном плане. Государства, особенно наши, неспособны эффективно управлять образованием. А 10 штук возвратить за последующие лет 10 работы, вполне легко и ненакладно. Государство взамен этого могло бы давать кредиты и обеспечить конкуренцию между ВУЗ'ами за абитуриентов.
Ха, правильно. Пусть сумма покрывает расходы на обучение. Тогда, быть может, модель платного образования начнет работать.
1. Меньше народу попрется в платники "корочки ради", ибо кредит отдавать придется, т.е. надо будет все-таки стать специалистом.
2. Можно вообще извлечь двойную выгоду. Увеличить стоимость платного образования, но улучшить соотношение платников:бюджетников. Гос-во ничего не потеряет финансово, но избавится от части баласта, который все-равно не компенсировал затраты на свое обучение.
В общем, половинное решение как обычно не сработало.
Здравствуйте, IT, Вы писали:
IT>>>Ты уверен, что ещё пару итераций помогли бы избежать веру в паттерны? Мне кажется эти вещи абсолютно никак не связаны.
V>>Да фиг с ней, с верой. Опустись они чуть ниже (на более детальную реализацию подсистем), сами бы увидели несоответствие.
IT>Это у меня как раз и вызывает наибольшее сомнение. Что значит спуститься ниже и увидеть? Что там в низу?
Ниже — составные части подсистем верхнего уровня и т.д. рекурсивно (результаты декомпозиций). Соответственно на каждом уровне все более уточняются и специфицируются протоколы взаимодействия подсистем и конкретные "локальные" требования.
Конкретно в их случае — они решили попользовать какой-то левый паттерн (не из GoF), который им очень понравился, названия которого я даже не помню. Паттерн описывал нужды организации распространения сигналов. И вот в какой-то момент они уперлись в тупик,. т.к. не смогли реализовать какие-то там нотификации на какие-то команды. Заодно запутались с роутингом сигналов. А уже ОЧЕНЬ много было написано. Я им к этому чуду прилепил рядом обычный паттерн Command, и описал несколько простейших правил роутинга. Довольно много пришлось переделать, но пришлось бы еще больше, если бы полностью перейти на Command. Т.е. кое-какие части работали по схеме подписывания на события, и параллельно — роутинг команд. Сделав изначально на Command, сэкономили бы кучу нервов и времени, и вся их система была бы чище и стройнее.
Они просто не дошли в проектировании до обработки команд, остановились на самой общей архитектуре, потому и не могли оценить применимость решений верхнего уровня. Не было тех самых итераций, на которых настаивает большинство процессов проектирования.
Здравствуйте, vdimas, Вы писали:
V>Сделав изначально на Command, сэкономили бы кучу нервов и времени, и вся их система была бы чище и стройнее.
Ты же, кажется, сам говорил, что знание паттернов не освобождает от ответственности. Ведь знали они наверняка про Command, но очень сильно хотели "поюзать" другой паттерн. Ну поюзали. Ещё один уровень детализации вряд ли чем бы помог.
... << RSDN@Home 1.2.0 alpha rev. 0>>
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, IT, Вы писали:
IT>Здравствуйте, vdimas, Вы писали:
V>>Сделав изначально на Command, сэкономили бы кучу нервов и времени, и вся их система была бы чище и стройнее.
IT>Ты же, кажется, сам говорил, что знание паттернов не освобождает от ответственности. Ведь знали они наверняка про Command, но очень сильно хотели "поюзать" другой паттерн. Ну поюзали. Ещё один уровень детализации вряд ли чем бы помог.
Мне помог, когда стали разбирать что у них происходит. На Command я тоже не сразу вышел, сначала дошел в понимании подробностей до конкретных мест, где он показался более применим, чем первоначальный вариант.
Я привык проектировать "по старинке", т.е. 7 раз отмерь — один отрежь. В электронике по-другому никак, все-таки цена даже ерундовой ошибки довольно высока. Поэтому на начальных этапах разработки либо стараюсь уточнить особенности, либо макетирую (экспериментирую), либо стараюсь полностью и бесповоротно отвязаться интерфейсами и высокоуровневыми протоколами от тех вещей, которые трудно/нецелесообразно полностью спроектировать лишь "на бумаге".
Решение о применении того или иного паттерна должно диктоваться потребностями конкретной ситуации (конкретного участка "чертежа"). Они приняли решение не на том уровне проектирования. Да и вообще, инитересная практика — кое-где принимать низкоуровневые решения, а кое-где оставлять "на потом". Получается кривая "линия фронта", она же — отражение приинципа "авось".
------------
Еще в спорах с "молодым поколением" меня забавляет их противопоставление XP-подхода к традиционным. Наверно, сказывается однобокое владение информацией (обычно только об XP). XP — это сборище неплохих, в общем-то, практик. Большинство этих практик успешно используются в традиционных процессах (кроме субъективно-спорного "парного программирования").
Например "тесты вперед" — вполне себе макетирование/моделирование. Оно-же — традиционный восходящий подход. Акценты, разве что, по-другому расставлены.
"Постоянный рефакторинг" — перенос итерационного подхода на стадию кодирования. Почему нет, если тех.ср-ва поддерживают процесс?
Единственное главное отличие XP — это отсутствие полноты. Сами же XP-практики весьма применимы, как дополнение к стадиям традиционных подходов. Например, при разработке GUI у нас зачастую самое что ни на есть XP. Макеты, они же — "почти production", они же — база обсуждений, уточнений требований и плацдарм последующих изменений. (Все-таки, трудно спроектировать все аспекты GUI на бумаге. Надо долго и упорно клацать мышкой и клавой и обращаться, помимо "правил хорошего тона", к "внутреннему зрению" и мимике заказчика)
Здравствуйте, vdimas, Вы писали:
V>Ну тогда тем более твоя позиция непонятна, твой пост насчет "юлишь" и "изворачиваешься" был уже после того, как я уточнил выделенное выше.
Я прочел минимум 3 разных ответа от тебя по этому пводу. Как по-твоему это расценивать?
... << RSDN@Home 1.2.0 alpha rev. 620>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
) его и формировал выходной поток и записывал его (уже более большими кусками) на диск в тот самый выходной файл. Потом делался второй проход в котором разрешались ссылки, но это уже детали. Главно, что в обоих проходах я как раз читал файл посимвольно.
По тем временам огромная память!!! Заполучив в свое распоряжение это богатство я смекнул, что читать файлы по одному символу не эффективно!!! Вывод этот я сделал так же как Pavel Dvorkin, то есть чисто из своего чутья, которого у меня надо признать тогда было в избытке, но оно было еще круче чем чутье легендарного Pavl-а Dvorkin-а.
)
Так вот, потомство должно так же знать, что недостаточное владение инструментом может породить все эти проблемы даже при решении такой несложной задачи как буферизация ввода.
Если нам не помогут, то мы тоже никого не пощадим.
Больно и обидно было на это смотреть. Я сам остался в ВУЗе в аспирантуре, но пробыл там... ровно месяц. После получения первой "ЗП" срочно побежал искать работу 
1.1.4 stable rev. 510
quicksort =: (($:@(<#[),(=#[),$:@(>#[)) ({~ ?@#)) ^: (1<#)
