Здравствуйте, McSeem2, Вы писали:
MS>Это все надо проверять. Но я точно знаю, что в MS-DOS вызов int21 был очень дорогим сам по себе.
Прирывания это функция процессора. МС ДОС всего лишь использовал одно из программынй прирываний. Как я понимаю, смартдайв тупо подменял обработчик прирывания и кэшировал результат.
... << RSDN@Home 1.2.0 alpha rev. 618>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, eao197, Вы писали:
E>На самом деле это получилась интересная, увлекательная и поучительная история о том, как ошибка при проектировании программы повлияло на ее производительность и расширяемость. Имхо, если бы на момент написания своего компилятора ты имел ну чуть-чуть больший опыт, все, что тебе пришлось сделать -- это задействовать собственный вариант getch, который прятал бы от тебя работу с буфером прочитанных из файла данных.
Можно на это посмотреть и так. Но смысл моего рассказа был как раз в том, что я сознательно не пошел на это так как сделал умозрительное предположение о том, что работа с буфером напрямую будет куда эффетивнее чем чтение по байту. Я понимал что чтение из файла операция не быстрая. И понимал, что если читать большими кусками, то скорость увеличится, но я так же думал, что во многом скорость определяется оптимальностью алгоритма. А это была ошибка. По сравнению со временем затрачиваемым на чтение данных с диска сам алгоритм занимал ничтожно мало времени. Собственно о выделенном и говорилось в моем рассказе. Очень жаль, что большиство уперлось в микроуровень и не поняло основного посыла этого рассказа. Я видел только одно сообщение
в этом обсуждении из которого можно понять, что человек правильно понял мои слва.
Если бы я был умнее тогда, я не стал делать оптимизацию на базе предположения. Вместо этого я бы просто проверил бы его на простом тесте и на основании результата выбрал бы куда более простое решение. Именно этим ценен данный опыт, а вовсе не какими-то там открывшимися деталями работы с файлами которые давно уже не интересны так как нет ни той ОС, ни тех библиотек.
E>Жаль только, что твой рассказ был переполнен наскоками на Павла Дворкина, это очень сильно впечатление от всей истории подпортило.
Да, наверно я переборщил с его пинанием. Однако этот пример как раз и был призван продемонстрировать крайнуюю неверность его мировозрения.
E>А вот по поводу блочного и посимвольного чтения данных из файла лет 5-6 назад мне статья попалась (кажется в "Открытых системах"). Там метрики приводились для какого-то Unix-а. Так вот меня поразило, что во многих случаях блочное чтение не имеет преимуществ над посимвольным чтением. Учитывая, что сейчас файловые системы очень умные, решение о том, читать ли данные посимвольно или поблоково, лучше принимать с учетом конкретной ОС и железа.
Это все не имеет значения. Скорость чтения определяется реализацией библиотеки. Конечно же чтение данных без кэширования в рамках процесса таких ОС как Виндовс или Линукс не может быть таким же быстрым как доступ к локальному буферу. Но библиотека может сама эффективно кэшировать данные.
В общем, еще раз выражу свое сожаление о том, что битобайтное мировозрение берет верх. Почти никто из прочитавших не смог понять основного посыла.
... << RSDN@Home 1.2.0 alpha rev. 618>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
E>>На самом деле это получилась интересная, увлекательная и поучительная история о том, как ошибка при проектировании программы повлияло на ее производительность и расширяемость. Имхо, если бы на момент написания своего компилятора ты имел ну чуть-чуть больший опыт, все, что тебе пришлось сделать -- это задействовать собственный вариант getch, который прятал бы от тебя работу с буфером прочитанных из файла данных.
VD>Можно на это посмотреть и так. Но смысл моего рассказа был как раз в том, что я сознательно не пошел на это так как сделал умозрительное предположение о том, что работа с буфером напрямую будет куда эффетивнее чем чтение по байту. Я понимал что чтение из файла операция не быстрая. И понимал, что если читать большими кусками, то скорость увеличится, но я так же думал, что во многом скорость определяется оптимальностью алгоритма. А это была ошибка. По сравнению со временем затрачиваемым на чтение данных с диска сам алгоритм занимал ничтожно мало времени. Собственно о выделенном и говорилось в моем рассказе. Очень жаль, что большиство уперлось в микроуровень и не поняло основного посыла этого рассказа. Я видел только одно сообщение
в этом обсуждении из которого можно понять, что человек правильно понял мои слва.
Извини Влад, значит ты не сумел донести смысл своего повествования до большинства читателей. Поскольку я, как, думаю, многие другие, обратил внимание вот на что:
Когда я читал символы последовательно, проблем в распознавании этой последовательности предшествующей ссылке не было. Я читал один символ... Если это был некий Х, то читал следующий, и если это был У, то было ясно, что передо мной ссылка и нужно действовать.
Похожим образом же я поступил и в буферизированной программе. Но я уже проверял подстроку а не отдельные символы. Так ведь было эффективнее!
Имхо, твоя проблема была в том, что ты стал оптимизировать не то место в программе. Ты стал изменять основной алгоритм поиска ссылок. Хотя этого можно было не делать. Оптимизацию можно было произвести на другом абстрактном уровне -- уровне ввода/вывода. Вот это и стало причиной твоих граблей.
... << RSDN@Home 1.1.4 stable rev. 510>>
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, eao197, Вы писали:
E>Извини Влад, значит ты не сумел донести смысл своего повествования до большинства читателей.
Видимо. Остается только понять виноват ли в этом я или те кто читал.
Первым моим решением было — сэмулировать getch() которым я читал данные в первом варианте компилятора. Но я тут же сделал очередное гениальное предположение в котором нисколько не сомневался. Звучало оно так — на возню с передачей символов и анализ по одному символу я убью кучу времени и моя программа станет не эффективна!
... << RSDN@Home 1.2.0 alpha rev. 618>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
V>>Так вроде можно было управлять буфером FILE в С. По умолчанию он там, вроде, 256 байт был.
VD>Я рассказал то что было. Если тебе интересно можешь надыбать где-нибудь QuickC 1.0 или МС С 5 и поглядеть подробности.
Я с 1990-го работал на Turbo C, там можно было менять размер буфера структуры FILE (ты же ее использовал?)
VD>Собственно сага была не о том. Очень жаль что у большинства читавших нехватило сил оторваться от деталей и понять посыл.
Посыл понятен, жаль что у некоторых отвечающих не хватило сил оторваться от деталей и понять ответный посыл.
Ответ в том, что иногда оптимизация достается весьма малой кровью. И как вывод: вовсе игнорировать возможность оптимизации не стоит (собственно, я настаиваю на таком подходе). Надо лишь соизмерять потраченные усилия и получаемый эффект.
Понятное дело, что чем больше осведомленность о тонкостях используемых технологий, тем больше можно сделать оптимизаций без какого-либо ущерба для продукта или потраченного времени.
Да, очень важно, с оптимизации никогда не надо начинать. За исключением случая, когда некие вещи закладываются как ТРЕБОВАНИЯ (например, минимизации трафика или использования памяти), и тогда сама архитектура продукта разрабатывается с учетом требований. Обычная "бытовая" оптимизация делается ПОСЛЕ полной реализации всех требований, и опять же, НИКОГДА не служит самоцелью (как пытаются выставить некоторые). Даже такой фанат этого дела как я занимается оптимизацией только тех мест, где программа проводит больше всего времени. Как вычисляются эти места — второй вопрос.
В общем, как обычно, истина где-то посередине.
----------
А конкретно по твоему случаю, могу так же подкинуть информации.
Первые версии кеша драйва работали с глюками и их не торопились ставить на все подряд. В нашей лаборатории этот драйвер однажды похерил всю информацию на "главной" XT, я потерял более месяца работы.
Жаль, что ты не указал точно год, правда, если речь о 386-х и у нас, то предполагаю где-то после 92-го. Если бы ты писал свою утилиту ранее, и позиционировал ее именно для XT (c 4.7 MGh CPU) и без кеша драйва, то все твои усилия уже не выглядели бы такими уж ненужными и бесполезными. Тем более, что описанный способ буферизации не выдерживает никакой критики и вполне справедливо создал хаос в исходниках. Ты тогда еще в школе учился что-ли? Ибо студент после 1-го курса профилирующей специальности должен был просто отвязать интерфейс ввода от конкретной его реализации.
Так что, конкретно этот посыл попрежнему ммм... спорен.
Здравствуйте, VladD2, Вы писали:
VD>Видимо. Остается только понять виноват ли в этом я или те кто читал.
Начинаем разбор полетов.
То есть, переводя на русский язык, ты сначала:
E>Когда я читал символы последовательно, проблем в распознавании этой последовательности предшествующей ссылке не было. Я читал один символ... Если это был некий Х, то читал следующий, и если это был У, то было ясно, что передо мной ссылка и нужно действовать.
Потом:
VD>
Первым моим решением было — сэмулировать getch() которым я читал данные в первом варианте компилятора. Но я тут же сделал очередное гениальное предположение в котором нисколько не сомневался. Звучало оно так — на возню с передачей символов и анализ по одному символу я убью кучу времени и моя программа станет не эффективна!
Получается противоречие. Сначала посимвольный анализ был для темя простым и логичным, а при "эмуляции getch()" он ни с того ни с сего вдруг стал плохим? Не вижу никакой логической связи. Зачем надо было отказываться от уже отработанного решения?
Далее. Ты решил анализируешь строки а не символы. Пожалуйста, имеешь право. Но тогда возможность попадания ссылки "промеж буферов" — это первое, что приходит в голову при наличии элементарных инженерных навыков (повторюсь — самых элементарных). Следующая мысль "инженерного типа" — это то, что выносить такую ситуацию в особый случай — это плохое решение, поскольку оно неоправданно усложняет логику (насколько я понял, ты на нем и остановился). Это как раз и есть та самая "оптимизация", против которой ты так яростно выступаешь — она действительно никудышная. Нормальным решением было бы сделать буфер из двух последовательных частей. Как только наш указатель в буфере вылезает за пределы первой части, она становится ненужной. Следовательно, мы имеет право скопировать вторую часть на место первой, после чего дочитать следующую порцию из файла размером в полбуфера. Все! Мы имеем полное право пользоваться строковыми фунциями с гарантией неразрывности. Логика здесь тривиальна, она не тянет ни на какой "алгоритм". И накладные расходы на копирование — мизерны. Засада может случится только в случае, если размер токена превысит размер полу-буфера, но это можно объявить ограничением на использование. Такая цепочка рассуждений является нормальным инженерным, дизайнерским и оптимизационным решением. У тебя же присутствовал какой-то бессистемный поток сознания, из которого ты сделал глобальный по жизни вывод, что оптимизация — зло. Она и есть зло, если в башке бардак.
Я вообще удивляюсь, что тебе понадобилась "неделя потения" на то, чтобы понять проблему разрыва ссылок.
Теперь о smartdrv. Ты говоришь, что испытал некий шок. Но этот шок как раз и является следствием невежества. Получается, что твоя программа зависит от smartdrv и может работать только с ним. Но ведь тот же NortonGuide прекрасно работал и без всяких smartdrv. И чего тогда твоя "программа" стоила, если она требовала некую "ускоряющую приблуду"? Типа все нормальные программы ускоряются от smartdrv в полтора-два раза на дисковых операциях, а твоя ускорялась в десять раз? Один этот факт говорит о том, что программа — отстой.
Более того, из всего этого ты сделал совершенно ложный по жизни вывод, что оптимизация непременно приводит к ухудшению дизайна. Так вот, я скажу, что это — чушь. Нормальная оптимизация только помогает и способствует хорошему дизайну. Но то, что лично ты считаешь оптимизацией, на самом деле ей не является. Это — не оптимизация. Для этого есть даже специальный термин — spaghetti-code.
McSeem
Я жертва цепи несчастных случайностей. Как и все мы.
позволило в несколько раз увеличить скорость обработки (там, кстати, речь идёт о 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>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
VD>1. Собираем список нареканий пользователей.
У меня есть только одно замечание к данному тезису. Ничто не может насобирать столько замечаний пользователей сколько сам разработчик в роли пользователя
... << RSDN@Home 1.2.0 alpha rev. 0>>
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, FR, Вы писали:
Skipped.
Отлично.
К сожалению остаются проблемы с формализацией понятий
Например:
"может повлиять" — каждый будет воспринимать это в меру своей испорченности, и считать по своему что может, что не может... примеров масса, особенно в соседних тредах.
"решение ухудшает дизайн" — у каждого свои понимания этого, для кого то вылизывание кода и изобретения собственноручно наструганных лисапедов и есть лучший дизайн.
К чему это я? Все возвращается на круги своя — все зависит от здравомыслия(тут вообще формализация бессильна ) ведущего разработчика — либо это прагматичный человек, либо фанатик.
Таки почитав, как народ начал сравнивать 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>Все не совсем так. Лично я выступаю за очень простой набор правил:
Все хорошо и красиво и у меня возражений по существу нет. Но ты упустил главное, эти правила хороши при разработке определенного вида приложений, таких которые не требуют выжимать из аппаратуры все. Но эти жа правила могут просто навредить для тех кто пишет приложения работающие на пределе, для них нужны совсем другие правила, и первое из них тестировать все что можно на скорость и без этого даже не начинать проектировать.
Здравствуйте, gear nuke, Вы писали:
GN>Таки почитав, как народ начал сравнивать inline и не-inline варианты функций при чтении не то с диска, не то из кеша файловой системы ОС, пошёл да исправил — на +.
GN>Вот уж воистину precipitate optimization is the root of all evil.
А ведь Дворкин прав не следует даже сейчас на PC читать побайтово с диска
FR>Все хорошо и красиво и у меня возражений по существу нет. Но ты упустил главное, эти правила хороши при разработке определенного вида приложений, таких которые не требуют выжимать из аппаратуры все. Но эти жа правила могут просто навредить для тех кто пишет приложения работающие на пределе, для них нужны совсем другие правила, и первое из них тестировать все что можно на скорость и без этого даже не начинать проектировать.
Опять же — тестировать, а не умозрительно выбирать решения, все решает опыт
"2. Проектируя код задумываемся над тем в каких условиях он должен работать и с какими проблемами можем столкнутся. Исходя из этого выбираем приемлемые алгоритмы и средства (библиотеки, рантаймы, компиляторы и т.п.) и другие проектные и локальные решения. "
Вот отсюда и исходим, смотрим, что уже было сделано до нас в подобных областях, все таки не на пустом месте работаем, так что все ок
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, vdimas, Вы писали:
V>>Я с 1990-го работал на Turbo C, там можно было менять размер буфера структуры FILE (ты же ее использовал?)
VD>Я уже не помню что я использовал. Название getch и то взято на абум как одно из близких. К делу это отношения не имеет. Ты просто вообще ничего не понял из написанного. Попробуй перечитать текст не обращая внимания на технические детали.
Доктор мой не лыком шит, он хитер и осторожен:
"Это правда, но возможен ход обратный", говорит.
Например, "Ты просто ничего не написал из понятого. Попробуй переписать текст, обращая внимание на технические детали".
PS: А впрочем, чего это я? Чем больше людей согласится с автором, тем легче мне будет с работой.
Здравствуйте, Nickolay Ch, Вы писали:
NC>Опять же — тестировать, а не умозрительно выбирать решения, все решает опыт
А тут никто вроде и не предлагал умозрительно все решать.
NC>"2. Проектируя код задумываемся над тем в каких условиях он должен работать и с какими проблемами можем столкнутся. Исходя из этого выбираем приемлемые алгоритмы и средства (библиотеки, рантаймы, компиляторы и т.п.) и другие проектные и локальные решения. "
NC>Вот отсюда и исходим, смотрим, что уже было сделано до нас в подобных областях, все таки не на пустом месте работаем, так что все ок
Нет не Ok есть ситуации в которых если следовать по порядку Владовым рекомендациям просто придется выбросить то что уже сделал и написать все по новой.
FR>А тут никто вроде и не предлагал умозрительно все решать.
А вот предлагали, не будем показывать пальцем...
Посмотрите соседние топики.
NC>>"2. Проектируя код задумываемся над тем в каких условиях он должен работать и с какими проблемами можем столкнутся. Исходя из этого выбираем приемлемые алгоритмы и средства (библиотеки, рантаймы, компиляторы и т.п.) и другие проектные и локальные решения. "
FR>Нет не Ok есть ситуации в которых если следовать по порядку Владовым рекомендациям просто придется выбросить то что уже сделал и написать все по новой.
Жестких правил не бывает, не в армии
Но пункт 2 вроде как удовлетворяет тому, о чем вы писали — есть жесткие требования работы на пределе возможностей:
"задумываемся над тем в каких условиях он должен работать ... выбираем приемлемые алгоритмы и средства (библиотеки, рантаймы, компиляторы и т.п.)"
Здравствуйте, IT, Вы писали:
IT>У меня есть только одно замечание к данному тезису. Ничто не может насобирать столько замечаний пользователей сколько сам разработчик в роли пользователя
Вот тут не согласен. Разработчик конечно должен быть первым пользователем. Но его взгляд притуплен авторсвом. Автор не может 100%-но адекватно оценивать плоды своего туруда. Он ведь априори согласен со всеми принятыми решениями. Плюс лень. Так что мнение пользователей очень важно.
Другое дело, что если программа не нравится и самому, то о пользователях говорить уже смысла нет.
... << RSDN@Home 1.2.0 alpha rev. 618>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Если нам не помогут, то мы тоже никого не пощадим.
