S>>И большинство из них к алгоритмической оптимизации никакого отношения не имеют. Потому как для математика оптимизация — это нахождение экстремума некоторой функции
B>А для программиста это то же самое. B>Только функция очень сложная
Не думаю, что функциональный подход здесь уместен.
Коллега, а вам не кажется, что вы делаете в точности то же самое, спорите с абсолютно не существующим противником?
Кто он, ваш оппонент? Где вы видели того, кто сказал бы, "нужно использовать медленные алгоритмы и писать неэффективные программы"?
Вам все хором поют о том, что на глаз определить узкое место как правило все равно не удается и о том, что скорость работы программы — это не самая важная ее особенность. И все. А что быстрые программы лучше медленных — вроде никто и не спорит.
Кстати, пару мыслЕй вдогонку:
— разработка программ для мобильных телефонов требует нехилых навыков оптимизации, без них тут не выживают. И, соответственно, оптимизируют. Те же самые люди, в общем-то.
— лет 10 назад меня сильно удручала невозможность купить (за мало-мальски разумные деньги) компьютер, который бы "не тормозил". А сейчас, несмотря на всю глубину кризиса, который вы в таких красках описали, мой не самый новый и не самый дорогой (даже во времена покупки) компьютер отнюдь не бесит меня своей производительностью. К чему бы это?
Иными словами — а был ли мальчик? А может, мальчика-то никакого и не было?
Здравствуйте, OnThink, Вы писали:
PD>>Трудно спорить с людьми, которые не хотят даже слушать, что им говорят. При чем здесь оптимизация всей программы ?
OT>прочитайте строки на которые был ответ.
Прочитайте строки, на которое было замечание. Ваши строки
>при оптимизации всей программы, мы ничего кроме нечитаемого кода не получаем.
Вот я и ответил, что ни о какой оптимизации всей программы речи не идет.
Здравствуйте, OnThink, Вы писали:
PD>>Трудно спорить с людьми, которые не хотят даже слушать, что им говорят. При чем здесь оптимизация всей программы ?
OT>Интересно посмотреть, как можно априорно выделить эти 4-5%.
Тут ничего сложного нет. Берем Доркина:
PD>Я вовсе не призываю к оптимизации любой ценой. И те, кто меня в этом обвиняют — ломятся в открытую дверь.
PD>Я призываю к неиспользованию заведомо неэффективных решений. Что, к сожалению, и будет иметь место, если программист элементарно не понимает, что здесь почем и относится к ресурсам как к бездонной бочке. А то, что это не так уж редко бывает — показывает исходный постинг. Если уж такой грамотный специалист, как VladD2 (говорю это без всякой иронии) допускает такие ляпы (и даже в этом я его не обвиняю, с кем не бывает), то что говорить о тех, кто только начинает!
PD>В общем, я призываю думать. Думать, и искать наилучшее решение. И не сковывать себя при этом никакими шорами.
Последний абзац в данном случае придется выкинуть Но, ничего, действуем по следующей схеме:
1. Составляем чеклист оптимизаций.
2. Строго следуем чек листу при написании кода. Здесь главное проверять этот чеклист сразу. например, написал метод — проверил.
Что включить в чеклист?
1. (сразу возьмем ввод вывод) Увидел посимвольное чтение — пошел проверил что, ввод вывод буферизирован — что это и зачем нужно в данном случае не важно надо просто проверить и, исправить.
2. Копирование массивов. Если один массив копируется в другой то, тот при создании другого лучше сразу выделить память нужного объема. Почему именно — тоже не важно — это как тарелька...
Ну и так далее (читаем умные посты и составляем дальше свой чеклист). Если следовать аккуратно, то в результате и получится что, оптимизировать надо 4-5% а не рефакторить все приложение
Если у Вас нет паранойи, то это еще не значит, что они за Вами не следят.
Здравствуйте, TK, Вы писали:
TK>Ну и так далее (читаем умные посты и составляем дальше свой чеклист). Если следовать аккуратно, то в результате и получится что, оптимизировать надо 4-5% а не рефакторить все приложение
А не проще профайлером побаловаться?
Здравствуйте, GlebZ, Вы писали:
TK>>Ну и так далее (читаем умные посты и составляем дальше свой чеклист). Если следовать аккуратно, то в результате и получится что, оптимизировать надо 4-5% а не рефакторить все приложение GZ>А не проще профайлером побаловаться?
Вот у тебя и получится, что опитимизировать будешь все приложение, а не 4-5% процентов. Есть вещи на понимание которых надо изначально потратить какое-то время (обычно этому и учат в институтах) а потом, эффективно их использовать. Если же институт понимания не дал, то сдача экзаменов научит заранее писать шпаргалки (они же чеклисты) и, возможно, правильно их использовать... Если же это игнорировать, то так и придется в профайлере сидеть и получать макаронный код на выходе... Либо, надеяться на тех, кто в школе хорошо учился а потом, смартдрайв написал.
Вобщем, не слушайте Влада — еще не того насоветует (он тут рядом вообще кончину Win32 предрекал
Если у Вас нет паранойи, то это еще не значит, что они за Вами не следят.
GZ>>А не проще профайлером побаловаться?
TK>Вот у тебя и получится, что опитимизировать будешь все приложение, а не 4-5% процентов. Есть вещи на понимание которых надо изначально потратить какое-то время (обычно этому и учат в институтах) а потом, эффективно их использовать. Если же институт понимания не дал, то сдача экзаменов научит заранее писать шпаргалки (они же чеклисты) и, возможно, правильно их использовать... Если же это игнорировать, то так и придется в профайлере сидеть и получать макаронный код на выходе... Либо, надеяться на тех, кто в школе хорошо учился а потом, смартдрайв написал.
Профайлером надо пользоваться, чтоб узкие места искать. Об этом была речь, я думаю. То, о чём ты пишешь здесь, по большому счёту не является оптимизацией. Оптимизация — это то, алгоритм чего ты привёл в прошлый раз. Оптимизация почти всегда ухудшает структуру кода и речь о том, чтобы применять её только в крайних специализированных случаях. А ухудшение читаемости кода вдоль всей его длины — это имхо великое зло.
Здравствуйте, TK, Вы писали:
TK>Если же это игнорировать, то так и придется в профайлере сидеть и получать макаронный код на выходе...
Неее. Во первых профайлер не изменяет код. Он делает отчеты. Макаронный код — это пререгатива программиста. Ну а во-вторых, профайлер оперирует точными цифрами, а не догадками. В третьих — ты прав. Если писать лабуду вначале, то тебе никто не поможет. Знания сила. Надо выбирать оптимальные алгоритмы и оптимальные инструменты и стараться уместить в оптимальном дизайне. В четвертых — ты неправ. В любом случае ошибки производительности случаются независимо от нас. Сейчас приложения слишком сложны и для предсказание узких мест нужно в группу брать экстрасенса. В пятых ты неправ потому что требования к оптимальному дизайну и оптимальным алгоритмам зачастую противоречивы. И вот что в этом противоречии выбрать и есть вопрос. Я выбираю оптимальный дизайн. Алгоритм я не знаю как поведет себя, могу заточить профайлером если понадобится и переделать на более сложный дизайн, а вот если плохой дизайн, то в случае чего будет полная сипука.
TK>(он тут рядом вообще кончину Win32 предрекал
Мечтатель. Оно еще всех нас переживет.
Здравствуйте, minorlogic, Вы писали:
M>На пустом месте проблема . M> Просто использовать у себя в программе АБСТРАКЦИЮ поток данных stream, и еслии надо тогдаделать его реализацию буферизованной , не надо неделать .
О, вот и появилось ключевое слово — абстракция. Но тут оно как. Абстракции иногда обходятся не бесплатным. А это уже противоричит приципу выбора наиболее оптимальных решений (по скорости разумеется).
... << RSDN@Home 1.2.0 alpha rev. 618>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Pavel Dvorkin, Вы писали:
M>> Просто использовать у себя в программе АБСТРАКЦИЮ поток данных stream, и еслии надо тогдаделать его реализацию буферизованной , не надо неделать .
PD>Естественно. Но я же не о нем
А чем:
char ch = file.ReadChar();
отличается от использования потока?
... << RSDN@Home 1.2.0 alpha rev. 618>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, GlebZ, Вы писали:
TK>>Если же это игнорировать, то так и придется в профайлере сидеть и получать макаронный код на выходе... GZ>Неее. Во первых профайлер не изменяет код. Он делает отчеты. Макаронный код — это пререгатива программиста. Ну а во-вторых, профайлер оперирует точными цифрами, а не догадками.
Если ты думаешь, что запустил профайлер, посмотрел на цифры и получил результат, в котором написано где и что надо поменять то, это не так. Как раз догадками будет будет оперировать программист. Профайлер для него эти цифры никак не проинтерпритирует. Кроме того, профайлер сам вносит достаточную погрешность в измерения не каждое приложение можно запустить под профайлером и получить адекватные результаты.
GZ>В третьих — ты прав. Если писать лабуду вначале, то тебе никто не поможет. Знания сила. Надо выбирать оптимальные алгоритмы и оптимальные инструменты и стараться уместить в оптимальном дизайне. В четвертых — ты неправ. В любом случае ошибки производительности случаются независимо от нас.
Ошибки сами по себе не случаются. влада тому пример. данный пример замечательно показывает как незначительный просчет в дизайне может привести к тому, что приложение станет абсолютно не поддерживаемым.
GZ>Сейчас приложения слишком сложны и для предсказание узких мест нужно в группу брать экстрасенса.
Может, лучше архитектора? Откуда такое мнение, что хорошо спроектированное приложение обязательно будет работать медленно?
GZ>Алгоритм я не знаю как поведет себя, могу заточить профайлером если понадобится и переделать на более сложный дизайн, а вот если плохой дизайн, то в случае чего будет полная сипука.
Думаю, что алгоритм сортировки пузырьком как не точи ничего хорошего не выйдет... А вот переделка ошибок дизайна в "большом" приложении может стоить очень дорого. Это, хорошо, если это поймали на этапе тестирования. А если в эксплуатации? Сколько будет стоить исправление ошибки?
Хотя, в целом интересное наблюдение... Похоже, что большинство местных посетителей начинают думать только после того, как написанные софт вернулся из QA... из разряда "и как-же мне это чудо теперь ускорить?"
Если у Вас нет паранойи, то это еще не значит, что они за Вами не следят.
Здравствуйте, peterbes, Вы писали:
P>Павел, коллега, вы похоже пытаетесь вывести некие универсальные законы которые должно воспринимать как некие откровения. Может быть мой опыт программирования и не столь велик и писать программы я стал в зрелом 32-х летнем возрасте, но если бы мне пришлось мучиться такими парадигмами, то уверен, что дальше задачи написания программы Hello_World.exe дело бы не сдвинулось. У меня нет опыта преподавания, потому мое мнение сугубо дилетанское — нет нужды загружать чужие мозги задачами которые не кричат, у всех своя голова, как и кто будет решать конкретную задачу зависить от обстоятельств и от человека.
ИХМО, Павел в первую очередь учит людей (студентов) думать. А просто программировать можно и по чукотски — что вижу то и пишу (для большинства задач этого впоне хватит). А если еще быстро печатать то, вообще супер будет
Если у Вас нет паранойи, то это еще не значит, что они за Вами не следят.
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Остается только одно понять — и зачем же вы все придумываете себе вымышленных персонажей и с ними упорно спорите ?
Слушай... Сделай, плиз, пример кода некоторого простого приложения. Ну, например, подсчитывающего количество слов некотором каталоге где находится море ХТМЛ-файлов.
Условия задачи такие. В конце ты должен вывести в файл с именем report.txt результат подсчета слов отсортированный по этим словам. Ну, вот так:
Мама 10
Папа 100
я 3
В этом списке должны быть только слова удовлетворяющие понитию С++-идентефикатору (т.е. начинающиеся на букву или символв "_" и содержащие символы и цифры).
Потом ты объяснишь почему выбрал те или иные решения. Ну, а мы почитаем это описание и поймем что ты имеш в виду и под оптимизацией, и под оптимальностью.
Можешь выбирать любые классы, использовать любые АПИ доступные на Виндовс или писать любой код. В общем, никаких ограничений.
... << RSDN@Home 1.2.0 alpha rev. 618>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
PD>еще раз показала, что истина конкретна, о чем я не раз уже заявлял, но, к сожалению, мои оппоненты этого услышать не хотели.
Истин есть как минимум две. (С) Сергей Лукьяненко
PD>Так все же — можно ли читать из файла по одному байту ? Да или нет ? Стоит ли это оптимизировать ? Стоит ли это априорно оптимизировать ? Стоит ли это оптимизировать, если такая оптимизация скажется на дизайне и архитектуре не лучшим образом ?
ИМХО, надо смотреть по ситуации.
Что делает программа? Это моделирование каких-то белков? Это новый 3D-шутер с фотографическими текстурами? Что-то, сделанное для Palm'a? Программа самонаведения зенитной ракеты? Ядро операциоонной системы? Какие-то вещи, где важна скорость или память? Тогда надо оптимизировать. Безусловно. Потому что в данном случае скорость работы — одно из первейших условий.
Вы собираетесь писать что-то для общего употребления? Бухгалтерию, броузер, какую-то фичу для ОС?
Сколько вы собираетесь разрабатывать программу? Месяц, полгода, год? Не случится ли так, что пока вы эту самую программу допишете, скорость компьютеров удвоится в полном сответствии с законом Тьюринга?
Сколько вы собираетесь поддерживать эту программу? Вам надо будет в ней баги исправлять и вносить бесчетное количество изменений следующие 5 лет? Ну, как это делает всем известная и всеми ругаемая фирма с ее ОС Windows? Если так, то о дизайне и архитектуре стоит думать _БОЛЬШЕ_, чем об оптимизации. Иначе сейчас Вы где-то можете сэкономить килоабайт, а через год потерять мегабакс.
Мое мнение: определенного рецепта нет. Оптимизировать надо там, где это необходимо.
Здравствуйте, TK, Вы писали:
TK>Если ты думаешь, что запустил профайлер, посмотрел на цифры и получил результат, в котором написано где и что надо поменять то, это не так. Как раз догадками будет будет оперировать программист. Профайлер для него эти цифры никак не проинтерпритирует.
Да уж, не проинтерпритирует. Голову никто не отменял. Только цифры профайлера достаточно точны чтобы точно выявить где нужно оптимизировать. И действовать не догадками, но разумом. А догадки — вещь нехорошая. Сам грешен, не пользовался профайлером(их еще тогда не было, или я о них не знал) или логами и оптимизировал по догадкам. Смотришь — тормозит. Ага, вот здесь оптимизировали — тормозит. А вот здесь оптимизировали — тормозит. Вот здесь оптимизировали — не тормозит. А вот две предыдущей оптимизации уже непонятно, нужны ли они были, и вообще были ли оптимизациями — непонятно. Доказательств нет.
TK>Кроме того, профайлер сам вносит достаточную погрешность в измерения
Это хреновый профайлер, или неумение им пользоваться.
TK>не каждое приложение можно запустить под профайлером и получить адекватные результаты.
Бывает. А вот для этого логи никто не отменял.
И вообще, в современном мире наиболее часто тормозным является БД. Обычно ее оптимизацией и оптимизацией качества и количества запросов все и обходится.
TK>Ошибки сами по себе не случаются. влада тому пример. данный пример замечательно показывает как незначительный просчет в дизайне может привести к тому, что приложение станет абсолютно не поддерживаемым.
Это не слишком показательный пример. У меня показательный пример был в моей первой программе. Целевыми компами были XT и 286. За плечами аж две книжки по Турбо-Паскалю. Программа достаточно большая. Загрузка формы в районе 5-6 секунд. При чтении с диска использовались BlockRead, и я грешил что это диск тормозит, чем и отмазывался. Дескать программа сложная. Смущало только большой промежуток времени между миганиями лампочки диска при чтении. Потом по мере появления опыта — я понял что тормозило перекатывание из памяти после чтения с BlockRead в родные паскалевские типыв условиях жуткой оптимизации формата файла, чтобы он меньше занимал места(сейчас такое кажется смешным потому такие вещи делаются часто и в лет) . Оптимизация файла была лишней.
GZ>>Сейчас приложения слишком сложны и для предсказание узких мест нужно в группу брать экстрасенса. TK>Может, лучше архитектора? Откуда такое мнение, что хорошо спроектированное приложение обязательно будет работать медленно?
Во-первых, хороший архитектор понимает две вещи, нужно уменьшать риски путем предварительных тестов, все не уменьшишь всегда что-нибудь останется. Во-вторых, хороших архитекторов немного. А в третьих — не везде они есть.
TK>Думаю, что алгоритм сортировки пузырьком как не точи ничего хорошего не выйдет...
Ай-ай-ай. Попался на пустом месте. Пузырек очень эффективен если список уже почти отсортирован.
TK>А вот переделка ошибок дизайна в "большом" приложении может стоить очень дорого. Это, хорошо, если это поймали на этапе тестирования. А если в эксплуатации? Сколько будет стоить исправление ошибки?
+1
TK>Хотя, в целом интересное наблюдение... Похоже, что большинство местных посетителей начинают думать только после того, как написанные софт вернулся из QA... из разряда "и как-же мне это чудо теперь ускорить?"
Зависит от типа приложения. Если у тебя мат. рассчеты то это делается до QA в обязательном порядке.
Здравствуйте, TK, Вы писали:
TK>ИХМО, Павел в первую очередь учит людей (студентов) думать. А просто программировать можно и по чукотски — что вижу то и пишу (для большинства задач этого впоне хватит). А если еще быстро печатать то, вообще супер будет
[flame] — как и вся тема.
Можно и по-чукотски, кто же против. Разные люди, разные подходы, быстро взял, быстро сделал, и комплексы не мучают (китай-индия), криво, но пурга сойдет, оленей дальше поведем, 100 долларов деньги большие. Есть и другие подходы. Я когда вижу профессионала, мне очень приятно, я выжму из этого человека все что только возможно, даже если его знания мне не пригодятся, и буду при этом молчать, человек сам расколется, знания без вез возможности передать другим — это вещь отрицательная по сути, я это хрошо понимат все у кого эти знания есть, у меня свои знания, а передать их некому и это тяготит. Ладно, проехали, возможно я что не понял в вашей месаге, и понял, наверное, привратно.
ЗЫ. В этой задаче Павел ничему и не учит, по моему дилетанскому мнению, это одна сплошная пальцевитость на локальной проблеме — читать по байтам или грузить блоки. У каждого есть свои задачи, решенные элегантным образом это не повод выносить тему в философию.
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, minorlogic, Вы писали:
M>>На пустом месте проблема . M>> Просто использовать у себя в программе АБСТРАКЦИЮ поток данных stream, и еслии надо тогдаделать его реализацию буферизованной , не надо неделать .
VD>О, вот и появилось ключевое слово — абстракция. Но тут оно как. Абстракции иногда обходятся не бесплатным. А это уже противоричит приципу выбора наиболее оптимальных решений (по скорости разумеется).
Абстракцию легко заменить на конкретную реализацию , а вот наоборот сложнее.
TK>ИХМО, Павел в первую очередь учит людей (студентов) думать. А просто программировать можно и по чукотски — что вижу то и пишу (для большинства задач этого впоне хватит). А если еще быстро печатать то, вообще супер будет
Думать — это хорошо. Студентов надо учить думать. Но надо и учить ПРАВИЛЬНО РАБОТАТЬ. Иначе будем как всегда (как при союзе) — все умные, но почему-то в дерьме.
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, Pavel Dvorkin, Вы писали:
M>>> Просто использовать у себя в программе АБСТРАКЦИЮ поток данных stream, и еслии надо тогдаделать его реализацию буферизованной , не надо неделать .
PD>>Естественно. Но я же не о нем
VD>А чем: VD>
VD>char ch = file.ReadChar();
VD>
VD>отличается от использования потока?
Я имел ввиду что fopen fread это тоже абстракция , не имел ввиду какой то std::stream
Но, ничего, действуем по следующей схеме: 
