Re[16]: История одной оптимизации
От: VladD2 Российская Империя www.nemerle.org
Дата: 01.11.05 14:27
Оценка:
Здравствуйте, eao197, Вы писали:

E>Последствия copy-paste. Я этот тест не с нуля делал, а взял готовый, в котором этот functor уже был.


Ясно...
... << RSDN@Home 1.2.0 alpha rev. 618>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[6]: История одной оптимизации
От: VladD2 Российская Империя www.nemerle.org
Дата: 01.11.05 14:27
Оценка: :))
Здравствуйте, Кузнецов Денис Викторович, Вы писали:

КДВ>К сожалению в данном случае твое мнение учитываться не будет, поскольку ты сам являешсья субъектом оценки. Сами для себя мы всегда белые и пушистые. А вот для других...


+1

КДВ>И вообще, извини за критику, я в этом форуме по большей части читатель,


Ага. Оно и видно: http://rsdn.ru/Forum/Topa.aspx?days=0&amp;gid=27


Видимо ты тоже себя оценивать адекватно не можешь.

КДВ>но вот какое дело. Ты модератор, а это по идее должно накладывать на человека определенную ответственность. Не так ли? Я не в коей мере не пытаюсь мораль читать, просто когда в форуме один из самых больших спорщиков модератор — то даже читать тяжко бывает становится. И никто урезонить тебя иногда не может. Худо.


Возможно, возможно... Но вот все же здесь спорить все же можно. А вот в С++ с этим совсем никак. Там плохое слово о С++ табу, офтоп и вообще с прлюрализмом там не зашибись.
... << RSDN@Home 1.2.0 alpha rev. 618>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[7]: История одной оптимизации
От: VladD2 Российская Империя www.nemerle.org
Дата: 01.11.05 14:27
Оценка: +1
Здравствуйте, eao197, Вы писали:

E>Ради того, чтобы программа работала в заданных условиях. Например, SIM Toolkit апплет должен умещаться в 16Kb SIM карточку. Правильная, полностью функциональная версия занимает 19Kb. Нужно как-то "похудеть" апплет на 3Kb.


E>Такой пример подойдет?


Нет. Ты опять обобщашь частный случай. Никто не спорит, что если в очень окраниченные ресурсы нужно вжать довольно функциональную программу, то прийдется экономить на всем. Но это уже является частью спецификации ПО. И это нормально. Хотя опять таки есть варианты. Ведь, например, можно сменить железку и как следствие выпустить продукт на рынок раньше.
... << RSDN@Home 1.2.0 alpha rev. 618>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[7]: История одной оптимизации
От: VladD2 Российская Империя www.nemerle.org
Дата: 01.11.05 14:27
Оценка:
Здравствуйте, FR, Вы писали:

FR>Вы тоже перегибаете палку с заявлениями о ненужности оптимизации, пока еще (и это пока продлится похоже неопределенно долго) полно задач в которых битовыжимание необходимо. А красивая архитектура и оптимизация не антиподы, очень часто это вещи совершенно независимые.


Цитату, пожалуйста, где бы говорилось о том, что оптимизации вообще ненужны.
... << RSDN@Home 1.2.0 alpha rev. 618>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[17]: История одной оптимизации
От: eao197 Беларусь http://eao197.blogspot.com
Дата: 01.11.05 14:54
Оценка: +1
Здравствуйте, 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++.
Re[8]: История одной оптимизации
От: eao197 Беларусь http://eao197.blogspot.com
Дата: 01.11.05 14:54
Оценка:
Здравствуйте, VladD2, Вы писали:

E>>Ради того, чтобы программа работала в заданных условиях. Например, SIM Toolkit апплет должен умещаться в 16Kb SIM карточку. Правильная, полностью функциональная версия занимает 19Kb. Нужно как-то "похудеть" апплет на 3Kb.


E>>Такой пример подойдет?


VD>Нет. Ты опять обобщашь частный случай. Никто не спорит, что если в очень окраниченные ресурсы нужно вжать довольно функциональную программу, то прийдется экономить на всем. Но это уже является частью спецификации ПО. И это нормально. Хотя опять таки есть варианты. Ведь, например, можно сменить железку и как следствие выпустить продукт на рынок раньше.


Я как раз не обобщал, а один пример привел. Мог бы еще парочку.
А на счет сменить железку, то есть области, где сменить железку можно будет лишь через 2-3 года. Вот сейчас, например, мобильные операторы начинают закупать карты 64K, но хотят туда загнать как можно больше апплетов, поэтому в распоряжении одного апплета все равно остается очень ограниченный объем памяти.
... << RSDN@Home 1.1.4 stable rev. 510>>


SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Re[11]: История одной оптимизации
От: vdimas Россия  
Дата: 01.11.05 15:45
Оценка: +1
Здравствуйте, 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++. И не надо самому набираться опыта, претендующий на роль программиста на выбранном языке должен их просто изучить и понять (если сам еще не дошел своим опытом).
Re[7]: История одной оптимизации
От: vdimas Россия  
Дата: 01.11.05 16:35
Оценка:
Здравствуйте, AndrewVK, Вы писали:


AVK>Остановится рост мощностей, начнут вылизывать существующий софт.


Согласен, а кто вылизывать будет?

AVK>Тем не менее разница между теперешними моделями и моделями пускай 5-тилетней давности в этом плане ничтожна. Индустрия автопрома точно так же высасывает деньги из покупателей, только у них приемы другие — продать то же самое в новой, более модной обертке. С технической точки зрения мода на дизайн, заставляющая производителей чуть ли не каждый год менять модельную линейку является форменным идиотизмом. В IT выхлоп от прогресса все таки поощутимее (и, кстати, именно он дал возможность автопрому хоть как то улучшить функционал и надежность).


V>>Но ведь это не удивительно, над новой моделью работаюбт сотни инженеров. А у нас, у программистов, примерно 5-15 человек делают проекты, по информационной сложности мало уступающие проекту той же Тойты.


AVK>Боюсь, не просто не уступающими, но и значительно превосходящими.


Да нет, сейчас там довольно сложная электроника, + незабывай миллион расчетов на каждый чих, так что вряд ли превосходящими.

V>>Я бы не стриг всех под одну гребенку. К счастью, в крайности бросаются не многие. А что касается текущего положения дел, то на само понятие "эффективности" молодое поколение просто забило. Влад, даже ты пишешь свои программы более менее эффективно (сужу по публикуемым кускам). Ты по другому не можешь, хоть и озвучиваешь другую точку зрения. (гы-гы, кстати). А у нового поколения — ни стыда ни совести по отношению к ресурсам аппаратуры или сети.


AVK>Я почему то вижу прямо обратное. Если человек пишетоткровенно тормозной код на ровном месте, то обычно у него без этого масса проблем. Такого чтобы человек превосходно проектировал и писал код без багов, но при этом не умел оптимизировать по производительности я еще ни разу не встречал. Так не воюете ли вы с ветряными мельницами?


МЫ???

Как в том отрыывке из "Есенина" — "пишу как дышу", по-другому не умею. Пальцы уже сами помнят как им надо поступать в сотнях различных ситуаций в коде. Ловлю себя часто на том, что практически не думаю во время кодирования

Просто не могу могу вспомнить, чтобы какие-либо оптимизации отняли у меня хоть раз прилично времени или сил. У меня ни разу не было истории, наподобие описанной Владом. Я никогда не переписывал или дорабатывал свои программы по соображениям лишь быстродействия. Если требуется некое быстродействие — то оно либо требуется вначале, либо не требуется. А если выясняется задним числом, что все-таки требовалось быстродействие, а система не удовлетворяет, то это признак неопытности, либо банальной небрежности подхода к разработке (скорее второе, ибо выпускник ВУЗа все-таки уже инженер, и уже многое знает и умеет).

Я вышел из электронщиков и долгое время имел привычку расчитывать параметры будущих систем. Макетировал основные кусочки, замерял, просчитывал, моделировал. В обработке сигналов (чем занимался долго) по другому просто ничего не работало на той технике (embedded в т.ч.). Все это, на самом деле, стоит не дорого на начальных этапах разработки. Гораздо дороже обходятся переделки архитектуры, связанные с неудовлитворительным быстродействием. Как правило намного дороже переделок, связанных с уточнением функциональных требований.


AVK>Из этого можно сделать ровно один вывод — серебряных пуль не быват. О вреде паттернов это не говорит никоим образом. Влад вон тоже в свое время активно был против них и считал их костылями для ламеров. Однако ж стоило попробовать и ...


Сами эти паттерны весьма специфичны, кстати. Большинство из них расчитано на представление о ООП, требующем БИНАРНУЮ совместимость, типа как в Java, С++, Дельфи, C#, которая достигается через интерфейсную развязку. Больше половины паттернов просто не нужны на ООП-языках с динамической типизацией или диспецерезацией в духе VBA. Всякие бриджы и итераторы — из этой области.

AVK>Вобще, как это не странно, паттерны это не столько что то новое собственно в готовых проектных решениях, сколько очень удобный инструмент обучения и коммуникаций. К примеру, решение, описанное в терминах паттернов, выглядит заметно короче и понятнее, чем если без них, ибо стандартные паттерны это суть алфавит проектировщика.


Паттерны — это практически самый нижный, 0-й уровень проектирования, за которым зачастую идет собственно кодирование. Прикол в том, что подробности архитектуры на этом уровне уже мало кого интересуют, ибо это уровень имплементации. Для библиотеки — это важно, да, это — самоцель. Для функциональных требований бизнес-системы — нет. Именно про этих уродцев я и говорил. И подмечал, что знание паттернов ничуть не помогает в разработке архитектуры.

Я говорил о том, что проектирование надо вести от анализа требований, а не от попытки наложить знакомые паттерны на эти самые требования. Они часто просто не ложатся, ибо работают совсем в другой области, в области реализации той самой архитектуры.

------------
Насчет знаний паттернов. Когда читал эту книгу в 2000-м, долго смеялся. Я ожидал чего-то необычного, какого-то откровения (ибо был уже наслышан, и некоторые отзывались воссоржено). А увидел кучу знакомых ситуаций. (Интерпретатор у них поверхностный, правда, и вовсе не к месту там)
Re[8]: История одной оптимизации
От: FR  
Дата: 01.11.05 16:52
Оценка: -2
Здравствуйте, VladD2, Вы писали:

VD>Здравствуйте, FR, Вы писали:


FR>>Вы тоже перегибаете палку с заявлениями о ненужности оптимизации, пока еще (и это пока продлится похоже неопределенно долго) полно задач в которых битовыжимание необходимо. А красивая архитектура и оптимизация не антиподы, очень часто это вещи совершенно независимые.


VD>Цитату, пожалуйста, где бы говорилось о том, что оптимизации вообще ненужны.


Так общий фон такой что оптимизация это только зло, она и архитектуру портит и ничего кроме потери времени ни дает. А реально все это сильно зависит от решаемой задачи. Хотя сам все прекрасно понимаешь. Просто не надо крайностей.
Re[7]: История одной оптимизации
От: IT Россия linq2db.com
Дата: 02.11.05 01:10
Оценка: 56 (3) +4 :)
Здравствуйте, FR, Вы писали:

FR>Вы тоже перегибаете палку с заявлениями о ненужности оптимизации...


Блин, народ, ну вы как маленькие студебеккеры. Сколько можно уже об этом говорить
Автор: IT
Дата: 07.05.05
? Оптимизацией нужно заниматься тогда и только тогда, когда это часть non-functional requirements. В противном случае линейкой по рукам.

Занимаюсь ли я сам оптимизацией? К сожалению, да, довольно часто и много. Чаще и больше чем хотелось бы. Порой в довольно извращённых формах, например, в виде имита. Но это всегда стрельба по площадям, а не по воробьям. Не клубнику у соседки потырить, блин, а уж если обносить, то сразу колхозное поле. И только если оно того стоит. Ускорить что-нибудь в несколько раз всегда имеет смысл, если это критично. Париться ради 5-10% — увольте.

Единственная оптимизация, даже ради 1 процента, на которую стоит постоянно тратить время и которую я считаю очень правильной и необходимой (особенно для студентов) — это оптимизация читабельности и восприятия исходного кода. И ради этого я всегда готов пожертвовать жалкими 5-ю процентами производительности. Впрочем, жертвовать практически никогда и не приходится.
... << RSDN@Home 1.2.0 alpha rev. 0>>
Если нам не помогут, то мы тоже никого не пощадим.
Re[7]: История одной оптимизации
От: IT Россия linq2db.com
Дата: 02.11.05 01:26
Оценка: +1 :)
Здравствуйте, VladD2, Вы писали:

VD>Здравствуйте, Кузнецов Денис Викторович, Вы писали:


КДВ>>И вообще, извини за критику, я в этом форуме по большей части читатель,


VD>Ага. Оно и видно: http://rsdn.ru/Forum/Topa.aspx?days=0&amp;gid=27

VD>

VD>Видимо ты тоже себя оценивать адекватно не можешь.


Влад, помоему ты кого-то с кем-то путаешь
... << RSDN@Home 1.2.0 alpha rev. 0>>
Если нам не помогут, то мы тоже никого не пощадим.
Re[7]: История одной оптимизации
От: Кузнецов Денис Викторович Казахстан  
Дата: 02.11.05 03:40
Оценка:
Здравствуйте, VladD2, Вы писали:


VD>Ага. Оно и видно: http://rsdn.ru/Forum/Topa.aspx?days=0&amp;gid=27

VD>

VD>Видимо ты тоже себя оценивать адекватно не можешь.


Где что видно? И почему я себя адекватно оценивать не могу? Ничего не понимаю. Кто-то из нас действительно не совсем адекватен.

КДВ>>но вот какое дело. Ты модератор, а это по идее должно накладывать на человека определенную ответственность. Не так ли? Я не в коей мере не пытаюсь мораль читать, просто когда в форуме один из самых больших спорщиков модератор — то даже читать тяжко бывает становится. И никто урезонить тебя иногда не может. Худо.


VD>Возможно, возможно... Но вот все же здесь спорить все же можно. А вот в С++ с этим совсем никак. Там плохое слово о С++ табу, офтоп и вообще с прлюрализмом там не зашибись.


Спорить — да сколько угодно. Просто не все человеки спорить умеют. Некоторые за кирпичи хватаются и т.д. и т.п. (я сам такой бываю). Вот и нужны модераторы для того, чтобы народ по сторонам разводить иногда. Понимаешь, о чем я?


В общем того, я особо переписываться на эту тему не хочу, но со стороны видно, что форуму нужен другой модератор. Просто который меньше спорит сам. Вот и вся мораль.

P.S. Влад, ничего личного, извини, что я так это прямо говорю.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Re[8]: История одной оптимизации
От: IT Россия linq2db.com
Дата: 02.11.05 04:35
Оценка:
Здравствуйте, Кузнецов Денис Викторович, Вы писали:

КДВ>Где что видно? И почему я себя адекватно оценивать не могу? Ничего не понимаю. Кто-то из нас действительно не совсем адекватен.


Не принимай близко к сердцу. Это скорее всего не к тебе относилось, а к одному твоему однофамильцу
... << RSDN@Home 1.2.0 alpha rev. 0>>
Если нам не помогут, то мы тоже никого не пощадим.
Re[9]: История одной оптимизации
От: Кузнецов Денис Викторович Казахстан  
Дата: 02.11.05 05:13
Оценка:
Здравствуйте, IT, Вы писали:

IT>Здравствуйте, Кузнецов Денис Викторович, Вы писали:


КДВ>>Где что видно? И почему я себя адекватно оценивать не могу? Ничего не понимаю. Кто-то из нас действительно не совсем адекватен.


IT>Не принимай близко к сердцу. Это скорее всего не к тебе относилось, а к одному твоему однофамильцу


что ты, наоборот, я ж именно однофамильцами и богат ))
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Re[8]: История одной оптимизации
От: FR  
Дата: 02.11.05 05:23
Оценка:
Здравствуйте, IT, Вы писали:

IT>Здравствуйте, FR, Вы писали:


FR>>Вы тоже перегибаете палку с заявлениями о ненужности оптимизации...


IT>Блин, народ, ну вы как маленькие студебеккеры. Сколько можно уже об этом говорить
Автор: IT
Дата: 07.05.05
? Оптимизацией нужно заниматься тогда и только тогда, когда это часть non-functional requirements. В противном случае линейкой по рукам.


Я думаю бесполезно дальше говорить на эту тему, просто если бы ты почитал чуть выше, то понял бы что я писал именно про случай когда быстродействие (а не оптимизация) это основное требование. И если у вас нет подобных задач это не повод все выстраивать только на своем опыте.
Re[8]: История одной оптимизации
От: AndrewVK Россия http://blogs.rsdn.org/avk
Дата: 02.11.05 11:23
Оценка:
Здравствуйте, vdimas, Вы писали:

AVK>>Остановится рост мощностей, начнут вылизывать существующий софт.


V>Согласен, а кто вылизывать будет?


Найдется кому, не переживай.

AVK>>Боюсь, не просто не уступающими, но и значительно превосходящими.


V>Да нет, сейчас там довольно сложная электроника,


Которая разрабатывается в полном соответствии с традициями IT отрасли, которые здесь так ругают . И, кстати, совсем не инженерами Тойоты.

V> + незабывай миллион расчетов на каждый чих, так что вряд ли превосходящими.


Расчеты == юнит-тесты. Коих может быть очень много и для софта.

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


Значит тебе повезло. Или ты хочешь сказать что, к примеру, о проблеме, которую я описал в Re[11]: Выводы из одной дискуссии
Автор: AndrewVK
Дата: 01.11.05
, ты бы догадался сразу?

V>Сами эти паттерны весьма специфичны, кстати.


Эти это которые?

V> Большинство из них расчитано на представление о ООП, требующем БИНАРНУЮ совместимость, типа как в Java, С++, Дельфи, C#, которая достигается через интерфейсную развязку. Больше половины паттернов просто не нужны на ООП-языках с динамической типизацией или диспецерезацией в духе VBA. Всякие бриджы и итераторы — из этой области.


Ну и отлично. Там свои паттерны. В чем проблема то?

V>Паттерны — это практически самый нижный, 0-й уровень проектирования


Паттерны, они разные бывают. В GoF вожможно они довольно простые. Там цель такая стояла. А есть например общеизвесный MVC, который может применяться и на низком уровне и на очень высоком. Или можешь посмотреть на Microsoft Pattern&Practice, там паттерны тоже по большей части довольно высокоуровневые.

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


Тебя не интересуют, а меня интересуют. Хотя бы потому что вместо разговора сунь туда, вынь это, я могу просто сказать — здесь нужно применить визитор. Паттерны GoF это азбука проектирования.

V> Для библиотеки — это важно, да, это — самоцель. Для функциональных требований бизнес-системы — нет. Именно про этих уродцев я и говорил. И подмечал, что знание паттернов ничуть не помогает в разработке архитектуры.


Аргументы?

V>Я говорил о том, что проектирование надо вести от анализа требований, а не от попытки наложить знакомые паттерны на эти самые требования.


Прежде чем бегать надо научиться ходить.

V>------------

V>Насчет знаний паттернов. Когда читал эту книгу в 2000-м, долго смеялся. Я ожидал чего-то необычного, какого-то откровения (ибо был уже наслышан, и некоторые отзывались воссоржено). А увидел кучу знакомых ситуаций. (Интерпретатор у них поверхностный, правда, и вовсе не к месту там)

А если бы ты еще прочел введение, в котором написано с какой целью книжка создавалась ... И еще раз напомню — паттерны это отнюдь не только GoF.
... << RSDN@Home 1.2.0 alpha rev. 617>>
AVK Blog
Re[7]: История одной оптимизации
От: Nickolay Ch  
Дата: 02.11.05 14:36
Оценка:
Здравствуйте, eao197, Вы писали:

E>Здравствуйте, Nickolay Ch, Вы писали:


NC>>Мне ни в этой, ни в соседнем треде так и не дали четокго ответа на вопрос: "ради чего проводить битовыжимание, изобретать велосипеды, отказываться от удобных механизмов и библиотек". По крайней мере, внятного ответа не услышал.


E>Ради того, чтобы программа работала в заданных условиях. Например, SIM Toolkit апплет должен умещаться в 16Kb SIM карточку. Правильная, полностью функциональная версия занимает 19Kb. Нужно как-то "похудеть" апплет на 3Kb.


E>Такой пример подойдет?


Очень подойдет, если стоит такая задача. За которую будет соответствующе заплачено
Лозунги же, кидаемые тут, претендуют(или смахивают) на абсолютные истины. Уже писал, что идем от задачи....
Re[7]: История одной оптимизации
От: Nickolay Ch  
Дата: 02.11.05 14:38
Оценка:
FR>Вы тоже перегибаете палку с заявлениями о ненужности оптимизации, пока еще (и это пока продлится похоже неопределенно долго) полно задач в которых битовыжимание необходимо. А красивая архитектура и оптимизация не антиподы, очень часто это вещи совершенно независимые.

Я никогда не говорил "о ненужности" оптимизации. Я говорил, что оптимизировать надо по необходимости каждом конкретном случае, и четко понимать, что это дает.
Re[9]: История одной оптимизации
От: Nickolay Ch  
Дата: 02.11.05 14:40
Оценка: +1
FR>Так общий фон такой что оптимизация это только зло, она и архитектуру портит и ничего кроме потери времени ни дает. А реально все это сильно зависит от решаемой задачи. Хотя сам все прекрасно понимаешь. Просто не надо крайностей.

Пардон, но общи фон формирует каждый для себя, читая тред. Я только и писал, что "все это сильно зависит от решаемой задачи". Могу привести цитаты...
Re[8]: История одной оптимизации
От: eao197 Беларусь http://eao197.blogspot.com
Дата: 02.11.05 14:44
Оценка:
Здравствуйте, Nickolay Ch, Вы писали:

E>>Ради того, чтобы программа работала в заданных условиях. Например, SIM Toolkit апплет должен умещаться в 16Kb SIM карточку. Правильная, полностью функциональная версия занимает 19Kb. Нужно как-то "похудеть" апплет на 3Kb.


E>>Такой пример подойдет?


NC>Очень подойдет, если стоит такая задача.


Стоит.

NC> За которую будет соответствующе заплачено


Платят.

NC>Лозунги же, кидаемые тут, претендуют(или смахивают) на абсолютные истины. Уже писал, что идем от задачи....


Да здесь уже сама суть спора давно забылась. "Когда споры кипят, истина испаряется" ((С) народная мудрость).
... << RSDN@Home 1.1.4 stable rev. 510>>


SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Подождите ...
Wait...
Пока на собственное сообщение не было ответов, его можно удалить.