Re[16]: Почему преждевременная оптимизация - корень всех зол
От: eao197 Беларусь http://eao197.blogspot.com
Дата: 04.09.08 11:24
Оценка:
Здравствуйте, Юрий Жмеренецкий, Вы писали:

ЮЖ>Да тут все просто. Правило треугольника(или как там), — Время, Стоимость, Качество. Фиксировать можно две величины. Для проектов из "реального мира" зафиксированы первые две. Мне больше импонирует ситуация, когда первым компонентом является качество, а вторым может быть хоть что.


Юрий, просто интересно: какого типа ПО вы разрабатываете?


SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Re[16]: Почему преждевременная оптимизация - корень всех зол
От: Sinclair Россия https://github.com/evilguest/
Дата: 04.09.08 14:53
Оценка: +1
Здравствуйте, Юрий Жмеренецкий, Вы писали:

ЮЖ>Такие описанные места называются "vulnerability window" — то о чем у нас нет достоверных данных, документации и т.п. и им уделяется максимальное внимание. Так как по определению там можно нарватся на просады производительности, то все эти места тестируются(перед использованием) в различных режимах, собирается(и документируется) статистика и делается вывод о пригодности использования в каких-то рамках.

Это бессмысленная работа:
1. В любом windows-приложении такими окнами являются все системные вызовы.
2. Никакое тестирование этих "мест" без окружения не даст нужного результата. Ну вот снимаем мы, к примеру, метрики сетевых интерфейсов, а потом бац! и оказывается, что во время проигрывания видеоконтента сеть искусственно затормаживается. Если у нас приложение связано с воспроизведением видео и сетью, то мы попадаем.

ЮЖ>Этот подход не может давать гарантированные 100% результаты, но очень сильно снижает недетерминированность системы в целом. Кроме того эти места действуют на всех как красная тряпка на быка: про них все знают, и если возникают какие либо подозрения — то они проверяются в первую очередь.

Юра, что значит "проверяются в первую очередь"? Вот у меня есть такое "место": функция FileRead(). Вижу, что у меня приложение плохо шевелится. Что мне "проверять"?

ЮЖ>Если у нас имеется контракт, который описывает все возможные исходы, то иногда, даже несмотря на это, — нет уверенности в правильности результата. Начиная от невозможности протестировать: не с чем сравнивать например, или тестовые прогоны очень дорогие, или наличие скрытых взаимодействий. и т.п.

Угу. И это покрывает 99.9% всех полезных приложений.

ЮЖ>Кое-что из этого решает N-version programming, но это совсем крайность: делаем N реализаций одного алгоритма, запускаем, и... попадаем: а что делать с результатами?...

Как что? Этот подход замечателен для распила бабла. К моменту запуска все стейкхолдеры уже давно на канарах.


ЮЖ>Представить что любая программа должна работать в режиме 24x7. Вообще любая.

ЮЖ>Другой вариант(как бы нелепо это не звучало) — представить что ошибка в любой программе приведет к человеческим жертвам. После этого даже просто отношение меняется.
А, опять медитативные техники. Юра, это не ко мне. Это надо даже не знаю куда.


ЮЖ>Вот кстати, зачем обязательно в реально окружении? Почему нельзя заранее протестировать изолированные части? Что мешает? Смоделировать низкий пропускной канал, например, не проблема, тучу клиентских запросов тоже. Неужели система в "целом" начинает жить непредсказуемо?

Ну конечно, Юра! Срываю покровы: во-первых, стоимость тестирования всех изолированных частей во всех мыслимых режимах заведомо выходит за пределы коммерческих бюджетов. Во-вторых, система "в целом" всегда живет непредсказуемо — пример я уже привел: сеть отдельно и видео отдельно работают хорошо; включаем вместе — сеть тормозит. Ну и зачем было заниматься закапыванием денег в землю? Это и есть premature optimization.

ЮЖ>И еще: cколько времени понадобилось вышеописанному оптимизатору? Для него в такой ситуации — тормоза могут быть где угодно(в пределах сценариев использования), система ведь большая.

Что значит "где угодно"? Я же говорю — поводом для оптимизации является наблюдаемая проблема с производительностью, а не абстрактное желание "хочу побыстрее". Недавний пример я уже приводил.
Времени на выяснение места, где тормозит, уходит немного. Как правило, всё становится ясно в тот же день. Больше всего времени уходит на подготовку нужного тестового окружения; собственно анализ выхода профайлера — дело значительно более простое, чем копание в контрактах.

ЮЖ>В моем случае — тормоза гдето в местах обозначенных красной тряпкой. А их количство стремятся минимизировать.

Совершенно верно. Вот я приводил пример — Instant Messenger. В нем тормоза где-то в UI. Либо в сети. Либо в файлухе. Либо жрет много памяти, а это может тормозить из-за вытеснения в своп. Больше тормозить нечему. Впрочем, в нем больше ничего и нет. "Что ж вы флажками не обозначили? Как не обозначили — на выезде из Шереметьево красный флаг был."
Поэтому вместо анализа "списка тряпок" мы получаем конкретные данные.

ЮЖ>Да тут все просто. Правило треугольника(или как там), — Время, Стоимость, Качество. Фиксировать можно две величины. Для проектов из "реального мира" зафиксированы первые две. Мне больше импонирует ситуация, когда первым компонентом является качество, а вторым может быть хоть что.

К сожалению, при добавлении в квантовую механику постулатов теории относительности, вопрос "бесконечного качества" приходится отбросить по причине конечности оси "стоимость".

Поэтому, Юра, отбрось свои предрассудки и попробуй профайлер хоть раз. Я понимаю, нет ничего страшнее неизвестности, но в жизни профайлеры вовсе не так страшны. Еще не было ни одного случая, когда профайлер силой заставил разработчика оптимизировать неправильную строчку.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[17]: Почему преждевременная оптимизация - корень всех зол
От: eao197 Беларусь http://eao197.blogspot.com
Дата: 04.09.08 15:06
Оценка: +1
Здравствуйте, Sinclair, Вы писали:

S>Либо жрет много памяти, а это может тормозить из-за вытеснения в своп. Больше тормозить нечему.


Кстати о памяти. Не обязательно выходить в своп, чтобы получить тормоза. Например, можно иметь бинарное дерево поиска, размер которого в несколько раз превышает размер L2 кэша. При обращениях к узлам дерева, которые не находятся в кэше, происходит загрузка страницы памяти в кэш (медленная операция). При достаточно частых промахах мимо кэша можно получить тормоза на, казалось бы, оптимизированной для поиска структуре данных с хорошей O-асимптотикой.

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


SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Re[17]: Почему преждевременная оптимизация - корень всех зол
От: Юрий Жмеренецкий ICQ 380412032
Дата: 04.09.08 22:33
Оценка: -1
Здравствуйте, Sinclair, Вы писали:

S>Здравствуйте, Юрий Жмеренецкий, Вы писали:


ЮЖ>>Такие описанные места называются "vulnerability window" — то о чем у нас нет достоверных данных, документации и т.п. и им уделяется максимальное внимание. Так как по определению там можно нарватся на просады производительности, то все эти места тестируются(перед использованием) в различных режимах, собирается(и документируется) статистика и делается вывод о пригодности использования в каких-то рамках.

S>Это бессмысленная работа:
S>1. В любом windows-приложении такими окнами являются все системные вызовы.
Ну наконец-то ты начинаешь понимать. Но вот любое windows-приложение состоит не только из системных вызовов. Из компонентов с низкой надежностью можно собирать компоненты обладающие высокой. Это для тебя новость ?

S>2. Никакое тестирование этих "мест" без окружения не даст нужного результата.

А подробнее ?

ЮЖ>>Если у нас имеется контракт, который описывает все возможные исходы, то иногда, даже несмотря на это, — нет уверенности в правильности результата. Начиная от невозможности протестировать: не с чем сравнивать например, или тестовые прогоны очень дорогие, или наличие скрытых взаимодействий. и т.п.

S>Угу. И это покрывает 99.9% всех полезных приложений.
Начало перечитай — "если у нас имеется контракт".

ЮЖ>>Кое-что из этого решает N-version programming, но это совсем крайность: делаем N реализаций одного алгоритма, запускаем, и... попадаем: а что делать с результатами?...

S>Как что? Этот подход замечателен для распила бабла.
Для тебя — может быть. Но вопрос-то в другом на самом деле.

ЮЖ>>Вот кстати, зачем обязательно в реально окружении? Почему нельзя заранее протестировать изолированные части? Что мешает? Смоделировать низкий пропускной канал, например, не проблема, тучу клиентских запросов тоже. Неужели система в "целом" начинает жить непредсказуемо?

S>Ну конечно, Юра! Срываю покровы:
Спасибо конечно.

S> во-первых, стоимость тестирования всех изолированных частей во всех мыслимых режимах заведомо выходит за пределы коммерческих бюджетов.

"заведомо" — это заблуждение. При твоем подходе, да — выходит, и ты ничего с этим не сделаешь.

S>Во-вторых, система "в целом" всегда живет непредсказуемо

Приплыздец(с). Антон, ты халтуру заказчику поставляеш. Точка. Ты даже предсказать не можешь что она делает. Ты даже не можешь утвержать что система выполняет то что от нее требуется.

S>Времени на выяснение места, где тормозит, уходит немного. Как правило, всё становится ясно в тот же день. Больше всего времени уходит на подготовку нужного тестового окружения; собственно анализ выхода профайлера — дело значительно более простое, чем копание в контрактах.

Откуда ты знаешь как происходит "копание в контрактах"? У тебя же их нет.

ЮЖ>>В моем случае — тормоза гдето в местах обозначенных красной тряпкой. А их количство стремятся минимизировать.

S>Совершенно верно. Вот я приводил пример — Instant Messenger. В нем тормоза где-то в UI. Либо в сети. Либо в файлухе. Либо жрет много памяти, а это может тормозить из-за вытеснения в своп.
S>Больше тормозить нечему.
Неверно. У тебя непредсказуемая система. Играй по своим правилам до конца.

S>Поэтому вместо анализа "списка тряпок" мы получаем конкретные данные.

Оригинальная фраза. Смысла столько же как и в "Вместо яблока мы получаем позавчера".

ЮЖ>>Да тут все просто. Правило треугольника(или как там), — Время, Стоимость, Качество. Фиксировать можно две величины. Для проектов из "реального мира" зафиксированы первые две. Мне больше импонирует ситуация, когда первым компонентом является качество, а вторым может быть хоть что.

S>К сожалению, при добавлении в квантовую механику постулатов теории относительности, вопрос "бесконечного качества"
Опять ты присваеваешь мне авторство слов, которых я не говорил. И зачем ты упомянул квантовую механику ?

S>Поэтому, Юра, отбрось свои предрассудки и попробуй профайлер хоть раз. Я понимаю, нет ничего страшнее неизвестности, но в жизни профайлеры вовсе не так страшны.

У тебя какие-то странные призывы. Такое ощущение что ты мне наркотики предлагаешь... "Это не ко мне"(c)

Все что я пытаюсь сказать, — это то что система с хоть какими-нибудь контрактами лучше чем система без контрактов. Но ты меня обвиняешь в абстракционизме.
Re[18]: Почему преждевременная оптимизация - корень всех зол
От: Юрий Жмеренецкий ICQ 380412032
Дата: 04.09.08 22:43
Оценка: -1
Здравствуйте, eao197, Вы писали:

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


S>>Либо жрет много памяти, а это может тормозить из-за вытеснения в своп. Больше тормозить нечему.


E>Кстати о памяти. Не обязательно выходить в своп, чтобы получить тормоза. Например, можно иметь бинарное дерево поиска, размер которого в несколько раз превышает размер L2 кэша. При обращениях к узлам дерева, которые не находятся в кэше, происходит загрузка страницы памяти в кэш (медленная операция). При достаточно частых промахах мимо кэша можно получить тормоза на, казалось бы, оптимизированной для поиска структуре данных с хорошей O-асимптотикой.


E>Чесно говоря, я не представляю, какими контрактами или предварительными умозрительными оценками можно заранее защититься от подобной ситуации.


Достаточно понимать что такая ситуация имеет место быть. А если понимание присутствует до начала написания кода, то возможно это выльется в другое решение. Для этого и существует предварительный анализ сильных и слабых сторон применяемых решений. Тут вот контракты как раз и рулят.
Re[18]: Почему преждевременная оптимизация - корень всех зол
От: Sinclair Россия https://github.com/evilguest/
Дата: 05.09.08 03:11
Оценка: +3
Здравствуйте, Юрий Жмеренецкий, Вы писали:

ЮЖ>Ну наконец-то ты начинаешь понимать. Но вот любое windows-приложение состоит не только из системных вызовов. Из компонентов с низкой надежностью можно собирать компоненты обладающие высокой. Это для тебя новость ?

Нет. Но для меня новость, что из низкопроизводительных компонент можно собирать высокопроизводительные.
ЮЖ>А подробнее ?
Я уже написал подробнее. С конкретными примерами.

ЮЖ>"заведомо" — это заблуждение. При твоем подходе, да — выходит, и ты ничего с этим не сделаешь.

При моем подходе просто не нужно тестировать производительность всех изолированных частей. Точка.

ЮЖ>Приплыздец(с). Антон, ты халтуру заказчику поставляеш. Точка. Ты даже предсказать не можешь что она делает. Ты даже не можешь утвержать что система выполняет то что от нее требуется.

Хрен там. Видишь ли, мои утверждения о системе базируются не на предсказаниях, а на измерениях.

.
ЮЖ>Неверно. У тебя непредсказуемая система. Играй по своим правилам до конца.
Я и так играю до конца.

S>>Поэтому вместо анализа "списка тряпок" мы получаем конкретные данные.

ЮЖ>Оригинальная фраза. Смысла столько же как и в "Вместо яблока мы получаем позавчера".
Юра, ты наверное используешь какой-то другой русский язык. Поясняю еще раз: вместо списка возможных узких мест мы получаем список фактических узких мест. Не все 150 вхождений FileRead в программе скажутся на ее производительности. В твоем подходе каждое из них — это красная тряпка, так?
В моем подходе анализ дает те call stack, в которых реально проводится много времени


ЮЖ>Все что я пытаюсь сказать, — это то что система с хоть какими-нибудь контрактами лучше чем система без контрактов.

Да нет, Юра. Ты пытаешься сказать, что профайлер — это плохо. На твои контракты никто не наезжал: контракты — вещь замечательная. Особенно, если их поддерживает компилятор.
ЮЖ>Но ты меня обвиняешь в абстракционизме.
Ну естественно. Потому что ты критикуешь использование профайлера для анализа производительности и оптимизации программы. Аргументируя при этом какими-то дурацкими фобиями.
А что ты предлагаешь взамен? Конкретные рецепты?
Нет. Ты предлагаешь медитативные практики:

- Представить что любая программа должна работать в режиме 24x7.
— представить что ошибка в любой программе приведет к человеческим жертвам.

Ты предлагаешь невыполнимые действия:

если вся система построена на таких F, с четко выраженнымы контрактами(включая контракты по сложности), которым следуют все клиенты, то все точки входа/выхода(в очень широком смысле) имеют не что иное как, опять же, контракт.

А теперь вдруг оказывается, что ты имел в виду, что система с какими-то контрактами лучше...
Впрочем, в этом ты тоже неправ. Потому что из разрозненных контрактов ничего полезного получить нельзя. Это очень легко доказать — ведь если у нас есть F() с полным контрактом и G() без контракта, то любая H() = { F(); G() } тоже будет без контракта. В итоге мы так и получим недетерменированное поведение всех точек входа. Ну и в чем смысл этих контрактов?
Проблема всех пуританских подходов — в том, что одна маленькая дырка портит всю картинку.
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[19]: Почему преждевременная оптимизация - корень всех зол
От: eao197 Беларусь http://eao197.blogspot.com
Дата: 05.09.08 04:27
Оценка:
Здравствуйте, Юрий Жмеренецкий, Вы писали:

ЮЖ>Достаточно понимать что такая ситуация имеет место быть. А если понимание присутствует до начала написания кода, то возможно это выльется в другое решение. Для этого и существует предварительный анализ сильных и слабых сторон применяемых решений. Тут вот контракты как раз и рулят.


А можно привести пример контракта для этого случая?


SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Re[19]: Почему преждевременная оптимизация - корень всех зол
От: Юрий Жмеренецкий ICQ 380412032
Дата: 05.09.08 05:23
Оценка: -2
Здравствуйте, Sinclair, Вы писали:

S>Здравствуйте, Юрий Жмеренецкий, Вы писали:


ЮЖ>>Ну наконец-то ты начинаешь понимать. Но вот любое windows-приложение состоит не только из системных вызовов. Из компонентов с низкой надежностью можно собирать компоненты обладающие высокой. Это для тебя новость ?

S>Нет. Но для меня новость, что из низкопроизводительных компонент можно собирать высокопроизводительные.
Многопоточность, кеширование...

ЮЖ>>Приплыздец(с). Антон, ты халтуру заказчику поставляеш. Точка. Ты даже предсказать не можешь что она делает. Ты даже не можешь утвержать что система выполняет то что от нее требуется.

S>Хрен там. Видишь ли, мои утверждения о системе базируются не на предсказаниях, а на измерениях.
Неа. все гораздо хуже. В непредсказуемой системе ты по результатам измерений предсказываешь дальнейшее поведение. Только вот твои предсказания в корне отличаются от моих, которые базируются на контрактах.

ЮЖ>>Неверно. У тебя непредсказуемая система. Играй по своим правилам до конца.

S>Я и так играю до конца.
Хорошо, запомним.

S>вместо списка возможных узких мест мы получаем список фактических узких мест.

Первое — А, второе B. У меня B <= A. А тебе придется анализировать все B.

S>Не все 150 вхождений FileRead в программе скажутся на ее производительности. В твоем подходе каждое из них — это красная тряпка, так?

Нет, только те компонеты, в которых она используется, и которые не дают контрактов.

ЮЖ>>Все что я пытаюсь сказать, — это то что система с хоть какими-нибудь контрактами лучше чем система без контрактов.

S>Да нет, Юра. Ты пытаешься сказать, что профайлер — это плохо.
Профайлер — не плохо, плохо бездумное использование (см ниже).

S>На твои контракты никто не наезжал:

Да ладно уже.

S>контракты — вещь замечательная. Особенно, если их поддерживает компилятор.

Да какой нафиг компилятор? Берем банальные предусловия — "Для установки операционной системы требуется наличие как минимум N Mb оперативной памяти" Куда будем вставлять компилятор?


S>Ты предлагаешь невыполнимые действия:

S>

если вся система построена на таких F, с четко выраженнымы контрактами(включая контракты по сложности), которым следуют все клиенты, то все точки входа/выхода(в очень широком смысле) имеют не что иное как, опять же, контракт.

S>А теперь вдруг оказывается, что ты имел в виду, что система с какими-то контрактами лучше...
Об это я и говорю. Ты не согласен ?

S>Впрочем, в этом ты тоже неправ. Потому что из разрозненных контрактов ничего полезного получить нельзя. Это очень легко доказать — ведь если у нас есть F() с полным контрактом и G() без контракта, то любая H() = { F(); G() } тоже будет без контракта.


И что ты этим доказал ? хотел ведь это: "из разрозненных контрактов ничего полезного получить нельзя". Снабдим G контрактом и твое утверждение станет неверным.

S>В итоге мы так и получим недетерменированное поведение всех точек входа. Ну и в чем смысл этих контрактов?

Для тебя они смысла не имеют(хотя выше: "контракты — вещь замечательная"), потому как у тебя все полностью недетерминировано. А у меня есть гарантии на компоненты, на системы созданные из таких компонентов. Но. Я прекрасно отдаю себе отчет о существовании "vulnerability window" и связанных проблемах. Только вот они потому и "window" поскольку их размеры не такие большие(так бывает, если у тебя такого не бывает, это не значит что это невозможно). ПО ведь еще чем-то занимается кроме как вызывает ReadFile.

ЮЖ>>Но ты меня обвиняешь в абстракционизме.

S>Ну естественно. Потому что ты критикуешь использование профайлера для анализа производительности и оптимизации программы.
Да, критикую. Только критикую не просто использование, а бездумное использование. Смотри:

Дан use case(или набор). Для него, помимо всего прочего указываются требования по производительности(мы ведь о таких ситуациях говорим).

Реализуем:

Вариант 1: Без привлечения сторонних компонентов. Например алгорирм сортировки. Здесь, если реализация не обеспечивает заявленных требований, то это баг реализации. Попытки назвать исправление багов "оптимизацией", — запудривание мозгов.

Вариант 2: Имеются компоненты которые можно использовать. У каждого компонента есть свои pre requirements. Во-первых надо отдавать себе отчет в том, что невыполнение этих требований ни к чему хорошему не приведет. Так же у каждого компонента есть "описание" результата.

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

Дальше. use case реализован.
Через некоторое время встает вопрос о повышении производительности(если это из-за багов, то см. выше). Повышение производельности здесь опять называется оптимизацией. А вот на более высоком уровне происходит изменение требований, и оптимизация выглядит просто как попытка подогнать существующее решение к новым требованиям. Это аналогично разгону компьютера вместо смены начинки. С аналогичными проблемами. Меняются режимы работы всех связанных компонентов, возникают нарушения контрактов, появляются скрытые неучтенные зависимости. Дополнительные тесты не появляются практически никогда... А ведь это происходит постоянно. В результате система становится все меньше и меньше предсказуемой, снижается общая надежность. Происходит деградация до непредсказуемого состояния, и постулируется что так и должно быть.
Это то к чему приводит твой подход с оптимизацие "по необходимости". Понятно что в практически любых ситуациях найдутся эффективные приемы работы, только вот лечить надо причину, а не симптомы.

Только не надо говорить "добро пожаловать в реальный мир" — это все равно что говорить "все побежали, и я побежал. присоединяйся".

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

PS: В паралельной ветке предлагается кидание исключений при нарушении предусловий(контракта). На самом деле неважно что должно происходить.
Важно понимать почему и когда возникают такие нарушения, и что из этого следует.
Re[20]: Почему преждевременная оптимизация - корень всех зол
От: eao197 Беларусь http://eao197.blogspot.com
Дата: 05.09.08 06:01
Оценка: +2
Здравствуйте, Юрий Жмеренецкий, Вы писали:

ЮЖ>Дан use case(или набор). Для него, помимо всего прочего указываются требования по производительности(мы ведь о таких ситуациях говорим).


ЮЖ>Реализуем:


ЮЖ>Вариант 1: Без привлечения сторонних компонентов. Например алгорирм сортировки. Здесь, если реализация не обеспечивает заявленных требований, то это баг реализации. Попытки назвать исправление багов "оптимизацией", — запудривание мозгов.


ЮЖ>Вариант 2: Имеются компоненты которые можно использовать. У каждого компонента есть свои pre requirements. Во-первых надо отдавать себе отчет в том, что невыполнение этих требований ни к чему хорошему не приведет. Так же у каждого компонента есть "описание" результата.


ЮЖ>Вопрос. Как мы будем выбирать один компонент из нескольких(решающих определенную задачу)? На основе чего?

ЮЖ>Правильный и единственный ответ: используя контракты, если их нет — придется мерить(не важно что, но это эквивалентно созданию своих контрактов).

Как показывает практика
Автор: eao197
Дата: 22.08.08
производительность одной и той же hash-таблицы в зависимости от hash-функции может отличаться в разы. Вопрос. Как имея hash-таблицу со своими контрактами и hash-функцию со своими контрактами без замеров и профайлера оценить производительность?


SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Re[20]: Почему преждевременная оптимизация - корень всех зол
От: Sinclair Россия https://github.com/evilguest/
Дата: 05.09.08 06:18
Оценка: +1
Здравствуйте, Юрий Жмеренецкий, Вы писали:

ЮЖ>Многопоточность, кеширование...

И? Многопоточность дает крайне труднопредсказуемые результаты. К примеру, на одноядерной машине CPU-bound задачи параллелить не только бессмысленно, но и вредно.
Кэширование дает труднопредсказуемые результаты, т.к. без реальных данных мы не только не знаем cache hit ratio, но и не можем предсказать влияние роста потребления памяти на другие части системы, которые на первый взгляд никак с этим не связаны. Я имел опыт подобных решений.

S>>Хрен там. Видишь ли, мои утверждения о системе базируются не на предсказаниях, а на измерениях.

ЮЖ>Неа. все гораздо хуже. В непредсказуемой системе ты по результатам измерений предсказываешь дальнейшее поведение.
Не обязательно. Дальнейшее поведение мы прогнозируем очень редко. Мы делаем всё наоборот: делаем тестовую инсталляцию, замеряем поведение, и после этого даем некоторые гарантии. Но мы не даем никаких гарантий для систем, выходящих за пределы тестовой инсталляции.
То есть если мы намерили на одной коробке 20000 пользователей, то мы гарантируем, что мы столько выдержим. Мы понимаем, что двумя коробками мы обслужим больше, но не знаем сколько именно. Факторов слишком много, чтобы их учесть. Если кого-то интересует 30000, то мы ставим две коробки, и опять мерим. Если не получилось 30000, то мы смотрим (естественно, при помощи профайлера и других инструментальных средств), где оказался боттлнек, и чиним его. Заранее сказать, где он будет, невозможно — к примеру, глючный DNS может свести на нет ширину полосы гигабитного езернета. tcp/ip вообще весь устроен так, что его поведение можно только измерить, и практически невозможно предсказать. Требовать вместо tcp/ip транспорт с QoS — это оверкилл для большинства практических случаев. Достаточно померить результаты и подкрутить то, что мешает — к примеру, починить глючный DNS.

ЮЖ>Только вот твои предсказания в корне отличаются от моих, которые базируются на контрактах.

Совершенно верно. Моим — можно верить. Потому, что у меня есть test report, в котором бесстрастная машина продемонстрировала конкретный воспроизводимый результат. В случае контрактов нужно верить тому, что процедуры вывода контрактов системы из контрактов компонентов были проведены корректно.

S>>вместо списка возможных узких мест мы получаем список фактических узких мест.

ЮЖ>Первое — А, второе B. У меня B <= A. А тебе придется анализировать все B.
Вот это мне непонятно. У меня B в любом случае меньше A, независимо от того, были ли эти А мне известны до измерения. Потому, что это — объективная реальность.
Неужели ты можешь проигнорировать часть из тех B, которые я намерил?

ЮЖ>Нет, только те компонеты, в которых она используется, и которые не дают контрактов.

Отлично, у нас есть 150 компонентов, которые используют FileRead. Или одна компонента, но она используется в 150 местах — от природы не уйдешь; если у нас есть 150 разных стеков, которые уперлись в FileRead, то их всё равно 150.
При этом 149 из них могут не влиять на производительность, потому что вызываются очень редко. И только 1 лежит на критическом пути.

ЮЖ>Профайлер — не плохо, плохо бездумное использование (см ниже).

Бездумное использование никто не предлагал. Предлагается вдумчивое использование профайлера. Если бы можно было обойтись бездумным использованием, то профайлер был бы не нужен. Впрочем, есть наработки и на эту тему: profile-guided optimization — это полностью автоматическая техника. Но мы-то считаем что она уже применена, и ее не хватило.

S>>контракты — вещь замечательная. Особенно, если их поддерживает компилятор.

ЮЖ>Да какой нафиг компилятор? Берем банальные предусловия — "Для установки операционной системы требуется наличие как минимум N Mb оперативной памяти" Куда будем вставлять компилятор?
Как куда? Всё наоборот: компилятор должен нам сказать, сколько памяти требуется для установки операционной системы.
Проверку этого условия мы вставляем в инсталлятор.
Если мы говорим об автоматической системе провижнинга операционок, то в ней такие предусловия контролируются при помощи подсистемы выделения ресурсов.

S>>Впрочем, в этом ты тоже неправ. Потому что из разрозненных контрактов ничего полезного получить нельзя. Это очень легко доказать — ведь если у нас есть F() с полным контрактом и G() без контракта, то любая H() = { F(); G() } тоже будет без контракта.


ЮЖ>И что ты этим доказал ? хотел ведь это: "из разрозненных контрактов ничего полезного получить нельзя". Снабдим G контрактом и твое утверждение станет неверным.

Что значит "снабдим"? Откуда мы возьмем контракт на G()? Его нет, G() — это твое "окно в уязвимость". Более того, у нас в системе есть 99 таких G и только 1 такая F. Сколько усилий мы потратим на снабжение контрактами всех G?

ЮЖ>Для тебя они смысла не имеют(хотя выше: "контракты — вещь замечательная"), потому как у тебя все полностью недетерминировано. А у меня есть гарантии на компоненты, на системы созданные из таких компонентов. Но. Я прекрасно отдаю себе отчет о существовании "vulnerability window" и связанных проблемах. Только вот они потому и "window" поскольку их размеры не такие большие(так бывает, если у тебя такого не бывает, это не значит что это невозможно). ПО ведь еще чем-то занимается кроме как вызывает ReadFile.

Если посмотреть на результат профайлера, то всё остальное, как правило, будет занимать пренебрежимо малое время. Давай конкретно — чем таким может заниматься софтина, чтобы ее быстродействие можно было оценить контрактом.

ЮЖ>Дан use case(или набор). Для него, помимо всего прочего указываются требования по производительности(мы ведь о таких ситуациях говорим).


ЮЖ>Реализуем:


ЮЖ>Вариант 1: Без привлечения сторонних компонентов. Например алгорирм сортировки. Здесь, если реализация не обеспечивает заявленных требований, то это баг реализации. Попытки назвать исправление багов "оптимизацией", — запудривание мозгов.


Отличный пример. Комментирую:
1. Сортировка в реальной жизни — крошечный кирпичик реальной системы, который никогда не быает частью use-case. Примеры реального use-case можно посмотреть, допустим, на tpc-c.
2. Ок, пусть будет сортировка. Что такое "требование по производительности"? На уровне пользователя это время работы.
К сожалению, для реальных случаев невозможно дать гарантий времени работы для сортировки без привлечения измерительных инструментов. С твоей точки зрения, все имеющиеся реализации — с багами. Поясняю почему: мы не знаем заранее того, какие данные будут сортироваться. Очень немного алгоритмов имеют хорошие гарантии наихудшего времени сортировки. Mean time может сильно отличаться от Worst time, и нас это может устраивать, а может и нет.

ЮЖ>Вариант 2: Имеются компоненты которые можно использовать. У каждого компонента есть свои pre requirements. Во-первых надо отдавать себе отчет в том, что невыполнение этих требований ни к чему хорошему не приведет. Так же у каждого компонента есть "описание" результата.

Покажи мне хоть какую-то прикладную библиотеку с таким "описанием" результата, по которому мы поймем, подойдет ли она по производительности.
Вот например, в рамках нашего use-case нужно отпарсить некий XML. Вход — строка (пусть в памяти), выход — DOM. Есть сотни библиотек, которые это делают. Кого выберем? Сколько будет стоить выбор в терминах затраченного времени?

ЮЖ>Вопрос. Как мы будем выбирать один компонент из нескольких(решающих определенную задачу)? На основе чего?

ЮЖ>Правильный и единственный ответ: используя контракты, если их нет — придется мерить(не важно что, но это эквивалентно созданию своих контрактов).
Непонятно. Вот у нас есть сложный use case. Его, очевидно, нужно строить из многих компонентов. Если для него есть готовые компоненты, то нет и программистской работы.
Контракт у нас есть на весь use-case. Каким образом мы выведем требуемые контракты для компонентов? Да никаким. Это еще более сложная задача, чем построить контракт для Use-case из готовых контрактов компонентов.

ЮЖ>Дальше. use case реализован.

ЮЖ>Через некоторое время встает вопрос о повышении производительности(если это из-за багов, то см. выше). Повышение производельности здесь опять называется оптимизацией. А вот на более высоком уровне происходит изменение требований, и оптимизация выглядит просто как попытка подогнать существующее решение к новым требованиям.
Совершенно верно. Более того, в 99% случаев никаких требований заранее нет. Ну то есть есть какие-то приблизительные соображения о том, что должно работать гладко. Сколько для этого нужно FPS, никто не знает. Какая будет аппаратура доступна к моменту выхода софта, никто не знает.
В каких условиях будет работать софтина — никто не знает. Требования появляются после того, как готов прототип. Например "время проведения заказа должно быть в пределах 1 секунды"

ЮЖ>Это аналогично разгону компьютера вместо смены начинки.

Непонятно, почему. Разгон и смена — это два варианта решения. Решение мы принимаем только исходя из результатов анализа.
ЮЖ>С аналогичными проблемами. Меняются режимы работы всех связанных компонентов, возникают нарушения контрактов, появляются скрытые неучтенные зависимости.
Скрытые неучтенные зависимости есть всегда.
ЮЖ> Дополнительные тесты не появляются практически никогда...
Это непонятно. Всё как раз наоборот: добавляем тесты, и на их основе принимаем решения.

ЮЖ>Это то к чему приводит твой подход с оптимизацие "по необходимости".

Да нет. Мой подход приводит к работоспособным приложениям, удовлетворяющим запросы кастомеров.

ЮЖ>Понятно что в практически любых ситуациях найдутся эффективные приемы работы, только вот лечить надо причину, а не симптомы.

Всё как раз наоборот: причину лечить как правило невозможно. Более того, это не нужно никому. Это примерно как говорить "ну что же вы, надо было с самого начала выбирать QNX для платформы. А так я ничего не могу сделать с вашим плагином к аутлуку. Его тормоза — это симптомы, а причина — в том, что в винде memory manager не дает никаких гарантий".

ЮЖ>Только не надо говорить "добро пожаловать в реальный мир" — это все равно что говорить "все побежали, и я побежал. присоединяйся".

Нет, не то же самое. Это, во-первых, robust подход — он дает результаты даже тогда, когда предварительная работа не была проведена.
Это возможность отложить расходы, и даже если в итоге они окажутся выше, чем при плановом подходе, с точки зрения конечного результата это может оказаться выгоднее.
Во-вторых, это понимание глубинного принципа рыночной экономики — satisficing. Он состоит в том, что нам важнее не абсолютная производительность/качество/итд, а достаточная.

ЮЖ>Я вот в последнее время все больше склоняюсь к тому, что профайлер — это просто одно из средств поиска ошибок в контрактах или реализации.

Совершенно верно! Это средство поиска ошибок. Это не средство исправления ошибок. Я не знаю, почему ты решил, что профайлер исправит ошибки. Он всего лишь поможет подсказать, куда смотреть.
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[21]: Почему преждевременная оптимизация - корень всех зол
От: Юрий Жмеренецкий ICQ 380412032
Дата: 05.09.08 08:53
Оценка:
Здравствуйте, Sinclair, Вы писали:

S>Здравствуйте, Юрий Жмеренецкий, Вы писали:


ЮЖ>>Многопоточность, кеширование...

S>И?
Факт отстается фактом.
S>Многопоточность дает крайне труднопредсказуемые результаты. К примеру, на одноядерной машине CPU-bound задачи параллелить не только бессмысленно, но и вредно.
S>Кэширование дает труднопредсказуемые результаты, т.к. без реальных данных мы не только не знаем cache hit ratio, но и не можем предсказать влияние роста потребления памяти на другие части системы, которые на первый взгляд никак с этим не связаны. Я имел опыт подобных решений.
И что? Представь современный процессор с отключенными кэшами.

S>>>Хрен там. Видишь ли, мои утверждения о системе базируются не на предсказаниях, а на измерениях.

ЮЖ>>Неа. все гораздо хуже. В непредсказуемой системе ты по результатам измерений предсказываешь дальнейшее поведение.
S>Не обязательно. Дальнейшее поведение мы прогнозируем очень редко. Мы делаем всё наоборот: делаем тестовую инсталляцию, замеряем поведение, и после этого даем некоторые гарантии. Но мы не даем никаких гарантий для систем, выходящих за пределы тестовой инсталляции.
Антон, проснись. Это — контракты. Для них дается гарантии при соблюдении некоторых условий.
Контракт не это не только 'assert(a > 0)' — это любая документированная(не важно каким способом) особенность. Некоторые можно вывести из других, некторые нет, неважно. Важно наличие.

S>То есть если мы намерили на одной коробке 20000 пользователей, то мы гарантируем, что мы столько выдержим.

Опять часть контракта.

S>Мы понимаем, что двумя коробками мы обслужим больше, но не знаем сколько именно.

Опять часть контракта.

S>Факторов слишком много, чтобы их учесть. Если кого-то интересует 30000, то мы ставим две коробки, и опять мерим. Если не получилось 30000, то мы смотрим (естественно, при помощи профайлера и других инструментальных средств), где оказался боттлнек, и чиним его. Заранее сказать, где он будет, невозможно — к примеру, глючный DNS может свести на нет ширину полосы гигабитного езернета.

Вот ты говоришь — невозможно предсказать, и тут же приводишь в качестве примера DNS. =)

S>tcp/ip вообще весь устроен так, что его поведение можно только измерить, и практически невозможно предсказать. Требовать вместо tcp/ip транспорт с QoS — это оверкилл для большинства практических случаев.

Зависит от требований.

ЮЖ>>Только вот твои предсказания в корне отличаются от моих, которые базируются на контрактах.

S>Совершенно верно. Моим — можно верить. Потому, что у меня есть test report, в котором бесстрастная машина продемонстрировала конкретный воспроизводимый результат.
Это можно рассматривать как контракт, но только в точно таких же условиях. В таких же условиях этому можно верить, в других — нет.

S>В случае контрактов нужно верить тому, что процедуры вывода контрактов системы из контрактов компонентов были проведены корректно.

Контракты — это намного больше того, о чем ты думаешь.

ЮЖ>>Нет, только те компонеты, в которых она используется, и которые не дают контрактов.

S>Отлично, у нас есть 150 компонентов, которые используют FileRead. Или одна компонента, но она используется в 150 местах — от природы не уйдешь; если у нас есть 150 разных стеков, которые уперлись в FileRead, то их всё равно 150.
Да абсолютно все равно что там используется внутри компонента. Это детали реализации. Посмотри на это с точки зрения существования контрактов.

S>При этом 149 из них могут не влиять на производительность, потому что вызываются очень редко. И только 1 лежит на критическом пути.

Это потому что окружение другое. Кто-то вызывает FileRead.

S>>>контракты — вещь замечательная. Особенно, если их поддерживает компилятор.

ЮЖ>>Да какой нафиг компилятор? Берем банальные предусловия — "Для установки операционной системы требуется наличие как минимум N Mb оперативной памяти" Куда будем вставлять компилятор?
S>Как куда? Всё наоборот: компилятор должен нам сказать, сколько памяти требуется для установки операционной системы.
Компилятор на клиенте? =)

S>Проверку этого условия мы вставляем в инсталлятор.

Как компилятор проконтролирует это? =)

S>Если мы говорим об автоматической системе провижнинга операционок, то в ней такие предусловия контролируются при помощи подсистемы выделения ресурсов.

Неважно чем они контролируются.

S>>>Впрочем, в этом ты тоже неправ. Потому что из разрозненных контрактов ничего полезного получить нельзя. Это очень легко доказать — ведь если у нас есть F() с полным контрактом и G() без контракта, то любая H() = { F(); G() } тоже будет без контракта.


ЮЖ>>И что ты этим доказал ? хотел ведь это: "из разрозненных контрактов ничего полезного получить нельзя". Снабдим G контрактом и твое утверждение станет неверным.

S>Что значит "снабдим"?
Где твое доказательство выделенного ? Будешь манимулировать словом "разрозненных" ?

S>Откуда мы возьмем контракт на G()? Его нет, G() — это твое "окно в уязвимость". Более того, у нас в системе есть 99 таких G и только 1 такая F.

Даже одна F лучше чем 0. Окон стало меньше.

S>Давай конкретно — чем таким может заниматься софтина, чтобы ее быстродействие можно было оценить контрактом.


Например, запросы в SQL сервере. Только не надо опускаться на уровеь реализации. Ты же не говоришь что тормозит ReadFile(например). Ты не смог обеспечить предусловия(существования индексов, и т.п.). В результате full table scan. Вот они контракты. В документации.

ЮЖ>>Дан use case(или набор). Для него, помимо всего прочего указываются требования по производительности(мы ведь о таких ситуациях говорим).


ЮЖ>>Реализуем:


ЮЖ>>Вариант 1: Без привлечения сторонних компонентов. Например алгорирм сортировки. Здесь, если реализация не обеспечивает заявленных требований, то это баг реализации. Попытки назвать исправление багов "оптимизацией", — запудривание мозгов.

S>
S>Отличный пример. Комментирую:
S>1. Сортировка в реальной жизни — крошечный кирпичик реальной системы, который никогда не быает частью use-case.
Согласен, тут я промазал.

S>2. Ок, пусть будет сортировка. Что такое "требование по производительности"? На уровне пользователя это время работы.

Для пользователя алгоритма (программиста) — нет.

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

Легко, например O(N^2). Это гарантия.

S>С твоей точки зрения, все имеющиеся реализации — с багами. Поясняю почему: мы не знаем заранее того, какие данные будут сортироваться. Очень немного алгоритмов имеют хорошие гарантии наихудшего времени сортировки.

))
Во-первых: В таких случаях _всегда_ исполозуется Worst time.

Во-вторых: Какие могут быть Mean/Wrost time для O(N^2) ?
Они могут быть только для конкретных реализаций. Причем все константы вынятся(попутно там с сами собой добавляются/элиминируются и т.п.) "за скобки" на верхний уровень. Вот скажи зачем мне(зная O(N^2)) знать Worst/Mean time, которые нужно мерить(!) для каждого(!) компонента. (компоненты ведь могут использоваться по отдельности).

Баг в моей интерпретации — если вместо O(N) — по факту О(N^2).

S>Mean time может сильно отличаться от Worst time, и нас это может устраивать, а может и нет.

Используя такие утверждения хороших контрактов ты не добъешся.

ЮЖ>>Вариант 2: Имеются компоненты которые можно использовать. У каждого компонента есть свои pre requirements. Во-первых надо отдавать себе отчет в том, что невыполнение этих требований ни к чему хорошему не приведет. Так же у каждого компонента есть "описание" результата.

S>Покажи мне хоть какую-то прикладную библиотеку с таким "описанием" результата, по которому мы поймем, подойдет ли она по производительности.
S>Вот например, в рамках нашего use-case нужно отпарсить некий XML. Вход — строка (пусть в памяти), выход — DOM. Есть сотни библиотек, которые это делают. Кого выберем? Сколько будет стоить выбор в терминах затраченного времени?

Но вооще то я тебя спрашивал об этом одной строкой ниже:
ЮЖ>>Вопрос. Как мы будем выбирать один компонент из нескольких(решающих определенную задачу)? На основе чего?
Жду ответа.

ЮЖ>>Правильный и единственный ответ: используя контракты, если их нет — придется мерить(не важно что, но это эквивалентно созданию своих контрактов).

S>Непонятно. Вот у нас есть сложный use case. Его, очевидно, нужно строить из многих компонентов. Если для него есть готовые компоненты, то нет и программистской работы.
S>Контракт у нас есть на весь use-case. Каким образом мы выведем требуемые контракты для компонентов? Да никаким.
Кгхм. Опять стена непонимания.

S>Это еще более сложная задача,

Надо обеспечить поиск с логарифмической сложностью(это контракт 'для use-case'). Почему ты не будешь использовать пузырек ?

S>чем построить контракт для Use-case из готовых контрактов компонентов.

ты видимо о чем-то о своем.


ЮЖ>>Дальше. use case реализован.

ЮЖ>>Через некоторое время встает вопрос о повышении производительности(если это из-за багов, то см. выше). Повышение производельности здесь опять называется оптимизацией. А вот на более высоком уровне происходит изменение требований, и оптимизация выглядит просто как попытка подогнать существующее решение к новым требованиям.
S>Совершенно верно. Более того, в 99% случаев никаких требований заранее нет.
Ууу... Как ты поймешь что делаешь то что нужно?

S>Ну то есть есть какие-то приблизительные соображения о том, что должно работать гладко.

Это заказчики так говорит.

S>Какая будет аппаратура доступна к моменту выхода софта, никто не знает.

S>В каких условиях будет работать софтина — никто не знает. Требования появляются после того, как готов прототип.
Ну слава богу.

S>Например "время проведения заказа должно быть в пределах 1 секунды"

Нормальное требование верхнего уровня.

ЮЖ>>Это аналогично разгону компьютера вместо смены начинки.

S>Непонятно, почему. Разгон и смена — это два варианта решения.
Ты сможешь разогнать O(N^2) до O(N) ?

ЮЖ>> Дополнительные тесты не появляются практически никогда...

S>Это непонятно. Всё как раз наоборот: добавляем тесты, и на их основе принимаем решения.
Стоп, стоп. я про другие тесты. которые тестируют функционал. В описанном случае меняются контракты.


ЮЖ>>Понятно что в практически любых ситуациях найдутся эффективные приемы работы, только вот лечить надо причину, а не симптомы.

S>Всё как раз наоборот: причину лечить как правило невозможно.
Причина как раз в том что выбирают O(N^2) вместо O(N) (фигурально выражаясь, для ясности).

S>Во-вторых, это понимание глубинного принципа рыночной экономики — satisficing. Он состоит в том, что нам важнее не абсолютная производительность/качество/итд, а достаточная.

Достаточное качество/итд бывает оочень разным.


S>Я не знаю, почему ты решил, что профайлер исправит ошибки. Он всего лишь поможет подсказать, куда смотреть.

Я не знаю почему ты решил что я решил...
Re[22]: Почему преждевременная оптимизация - корень всех зол
От: Sinclair Россия https://github.com/evilguest/
Дата: 05.09.08 09:54
Оценка: 1 (1) +3 -1
Здравствуйте, Юрий Жмеренецкий, Вы писали:

ЮЖ>Факт отстается фактом.

Где факт-то??? Факт в студию.

ЮЖ>Антон, проснись.

Я как раз не сплю
ЮЖ>Это — контракты. Для них дается гарантии при соблюдении некоторых условий.
ЮЖ>Контракт не это не только 'assert(a > 0)' — это любая документированная(не важно каким способом) особенность.
Примеры контрактов в студию.
ЮЖ>Некоторые можно вывести из других, некторые нет, неважно. Важно наличие.
Как это неважно??? Мне лично важно не наличие, а способ получения. Потому, что я не верю в контракты, которые мне спустятся как манна небесная. Если пренебречь способом получения, то можно вообще просто считать, что все программы уже написаны. Неважно, как — важно просто наличие.
Так что пример вывода контракта на производительность — в студию. Без примера продолжаю считать твою позицию эротическими снами подростка.

S>>Мы понимаем, что двумя коробками мы обслужим больше, но не знаем сколько именно.

ЮЖ>Опять часть контракта.
Что именно "часть контракта"? То, что мы ничего не знаем? Практическая ценность такого контракта = 0.

ЮЖ>Вот ты говоришь — невозможно предсказать, и тут же приводишь в качестве примера DNS. =)

Для тех, кто в танке, поясняю: это был пример непредсказуемого фактора. Этих факторов — сотни, и я знаю всего про три из них. Что делать с остальными?

ЮЖ>Зависит от требований.

А зачем нам завышенные требования? Улучшение качества еще на 5% потребует увеличения стоимости в 20 раз. Кому это нужно?

ЮЖ>Это можно рассматривать как контракт, но только в точно таких же условиях. В таких же условиях этому можно верить, в других — нет.

Правильно.

ЮЖ>Контракты — это намного больше того, о чем ты думаешь.

Ну так расскажи. Хватит делать таинственное лицо.

ЮЖ>Да абсолютно все равно что там используется внутри компонента. Это детали реализации. Посмотри на это с точки зрения существования контрактов.

Посмотрел. Есть 150 разных компонентов, контракт производительности которых "неограниченно плохая". Дальше что?

S>>При этом 149 из них могут не влиять на производительность, потому что вызываются очень редко. И только 1 лежит на критическом пути.

ЮЖ>Это потому что окружение другое. Кто-то вызывает FileRead.
Ну и? Где конструктив?

S>>Что значит "снабдим"?

ЮЖ>Где твое доказательство выделенного ?
Юра, я привел доказательство два поста назад. В чем проблема?

ЮЖ>Будешь манимулировать словом "разрозненных" ?

При чем тут слова? Юра, я тебе показал, что одна компонента без контракта "отламывает" контракты у всех, кто ее попользовал. Будем признавать, или будем фигней заниматься?

S>>Откуда мы возьмем контракт на G()? Его нет, G() — это твое "окно в уязвимость". Более того, у нас в системе есть 99 таких G и только 1 такая F.

ЮЖ>Даже одна F лучше чем 0. Окон стало меньше.
Повторяю вопрос: Откуда мы возьмем контракт на G()?

ЮЖ>Например, запросы в SQL сервере. Только не надо опускаться на уровеь реализации. Ты же не говоришь что тормозит ReadFile(например). Ты не смог обеспечить предусловия(существования индексов, и т.п.). В результате full table scan. Вот они контракты. В документации.

)
Юра, это отличный пример. Ну и расскажи мне про контракт на производительность SQL запроса. Давай конкретный пример в студию. А то, может, я и правда не понимаю, что такое "контракт"?

И про то, как ты умеешь оптимизировать запросы без профайлера, т.е. без execution plan и execution statistics. Только не торопись — я за попкорном схожу.


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

ЮЖ>Легко, например O(N^2). Это гарантия.
1. Где константа? Без константы это разговоры в пользу бедных
2. Что такое O(N)? Количество тактов? Количество вызовов процедуры сравнения? Что это?
3. У нас есть пятьдесят алгоритмов с таким хреновым контрактом. На основе чего будем выбирать?

ЮЖ>Во-вторых: Какие могут быть Mean/Wrost time для O(N^2) ?

ЮЖ>Они могут быть только для конкретных реализаций. Причем все константы вынятся(попутно там с сами собой добавляются/элиминируются и т.п.) "за скобки" на верхний уровень. Вот скажи зачем мне(зная O(N^2)) знать Worst/Mean time, которые нужно мерить(!) для каждого(!) компонента. (компоненты ведь могут использоваться по отдельности).
Как это? А какая польза от знания O(N^2)? У тебя сортировка вызывается как часть операции выбора сервера, которая производится как часть операции по восстановлению соединения, которая производится как часть операции по отправке мессаги. Вот на эту последнюю у тебя требование: успеть за 0.1 секунды.
Как понять, плохо ли O(N^2) или хорошо?

ЮЖ>Баг в моей интерпретации — если вместо O(N) — по факту О(N^2).


А в моей — если по факту 0.2 секунды. И неважно, из-за чего это — или из-за того, что сравнение вызвали О(N^2) раз, или что само сравнение заняло слишком много времени.

ЮЖ>Используя такие утверждения хороших контрактов ты не добъешся.

Меня мои контракты вполне устраивают — вся зарплата в белую, просторный кабинет, бесплатный кофе.

ЮЖ>Но вооще то я тебя спрашивал об этом одной строкой ниже:

ЮЖ>>>Вопрос. Как мы будем выбирать один компонент из нескольких(решающих определенную задачу)? На основе чего?
ЮЖ>Жду ответа.
Выберем первую попавшуюся реализацию, которая не содержит очевидных проблем.
А теперь ответь на мой вопрос.

S>>Это еще более сложная задача,

ЮЖ>Надо обеспечить поиск с логарифмической сложностью(это контракт 'для use-case'). Почему ты не будешь использовать пузырек ?
Юра, откуда взялось это "надо"? Кто его придумал такое? У меня требований к сложности поиска не было с тех пор, как я собеседование проходил в 1998 году.
Как, впрочем, и use-case типа "поиск целого числа в массиве". Если вы до сих пор занимаетесь такими юз-кейзами, то вам повезло. Остальным программистам приходится еще и делать что-то полезное.

ЮЖ>Ууу... Как ты поймешь что делаешь то что нужно?

Итеративно, Юра, итеративно. А ты как понимаешь, что делаешь то, что нужно?

S>>Ну то есть есть какие-то приблизительные соображения о том, что должно работать гладко.

ЮЖ>Это заказчики так говорит.
Ну да. А кто еще задачу ставит?


S>>Например "время проведения заказа должно быть в пределах 1 секунды"

ЮЖ>Нормальное требование верхнего уровня.

ЮЖ>>>Это аналогично разгону компьютера вместо смены начинки.

S>>Непонятно, почему. Разгон и смена — это два варианта решения.
ЮЖ>Ты сможешь разогнать O(N^2) до O(N) ?
Может, и не смогу. А вот сделать так, чтобы O(N^2) работал быстрее О(N), или незначительно медленее — очень может быть что и смогу.

ЮЖ>Стоп, стоп. я про другие тесты. которые тестируют функционал. В описанном случае меняются контракты.

У кого меняются контракты?

S>>Всё как раз наоборот: причину лечить как правило невозможно.

ЮЖ>Причина как раз в том что выбирают O(N^2) вместо O(N) (фигурально выражаясь, для ясности).
Это очень упрощенное понимание. Никто не пишет специально плохой код. Пишут код, который должен был работать как надо.
А оказалось, что баланс требований — совсем другой. Вот, к примеру, выбрали список, потому что в него добавление O(1). А пришлось перейти на массив, потому что оказалось, что добавления бывают в 1000 раз реже, чем доступ, а он в списке — O(N). А заранее сказать было невозможно — откуда ты знаешь, что будут делать пользователи сервиса, которого еще и в природе нет?
А может быть, можно не переходить на массив, а просто сделать "кэш" — хранить в списке последний элемент, к которому мы обращались, и это разгонит наши существующие обращения List за счет того, что i у нас распределены неравномерно. И вместо O(N) мы опять получим O(1), которое не по контракту, а на практике.
А главное, что практическому подходу неважно, [i]почему
был выбран список. Мы видим результат. И отматываем назад до того места, где это можно исправить.
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[23]: Почему преждевременная оптимизация - корень всех зол
От: Юрий Жмеренецкий ICQ 380412032
Дата: 05.09.08 12:43
Оценка: -2 :)
Здравствуйте, Sinclair, Вы писали:

По пунктам.

-------------

Антон, ты отрицаешь мои доводы на основе своего неудачного опыта(причем не один раз):
Показываю на пальцах:

S>"Но для меня новость, что из низкопроизводительных компонент можно собирать высокопроизводительные."

ЮЖ>>Многопоточность, кеширование...
S>...Кэширование дает труднопредсказуемые результаты... Я имел опыт подобных решений

------------

Ты сам себе противоречишь.
Показываю на пальцах:

S>"Но для меня новость, что из низкопроизводительных компонент можно собирать высокопроизводительные."

ЮЖ>>Многопоточность, кеширование...
S>...Кэширование дает труднопредсказуемые результаты...
ЮЖ>>Факт отстается фактом.
S>Где факт-то??? Факт в студию.
S>"...а просто сделать "кэш... И вместо O(N) мы опять получим O(1)"

------------


Ты не читаешь, то что я пишу.
Показываю на пальцах:

ЮЖ>>например O(N^2). Это гарантия

ЮЖ>> <много всего>, проснись. Это — контракты.
ЮЖ>> Контракт не это не только 'assert(a > 0)'
S>Примеры контрактов в студию.

------------

Я хочу верить что ты знаешь теорию сложности, но твои реплики заставляют сомневаться меня в этом.
Показываю на пальцах:

ЮЖ>>O(N^2).

S>1. Где константа? Без константы это разговоры в пользу бедных

Это на грани фола:
S>O(N^2) работал быстрее О(N), или незначительно медленее — очень может быть что и смогу.

--------------
И еще присутствуют проблемы с логикой.
Показываю на пальцах:

S>Потому что из разрозненных контрактов ничего полезного получить нельзя. Это очень легко доказать — ведь если у нас есть F() с полным контрактом и G() без контракта, то любая H() = { F(); G() } тоже будет без контракта.


Здесь доказано совершенно не то. Те берешь один частный случай и обобщаешь решение.
Для все случаев необходимо рассмотреть, как минимум, варианты {F G} и {G F}, и кроме того, {F F} и { G G }. Вот это ты пытался доказать.
Я тебе давал попытку "срулить" на слове "разрозненных", но ты эту попытку проморгал.

"Будем признавать, или будем фигней заниматься? " (c)
Впрочем, ответ мне не интересен.

--------------

Специально заикнулся про SQL, поскольку ты его знаешь, но на фоне вышесказанного я не могу надеятся на адекватное понимание(или хотя бы желание понять).

Учитывая все написанное, плюс:
S>Меня мои контракты вполне устраивают — вся зарплата в белую, просторный кабинет, бесплатный кофе.

считаю что дальнейший разговор о контрактах и их влиянии на оптимизацию не имеет смысла. В это ветке меня нет. Dixi.
Re[24]: Почему преждевременная оптимизация - корень всех зол
От: eao197 Беларусь http://eao197.blogspot.com
Дата: 05.09.08 13:15
Оценка: +3
Здравствуйте, Юрий Жмеренецкий, Вы писали:

ЮЖ>считаю что дальнейший разговор о контрактах и их влиянии на оптимизацию не имеет смысла. В это ветке меня нет. Dixi.


Юрий, я понимаю, что ваш разговор с Антоном отбил у вас желание его продолжать. Тем не менее, прошу вас, по возможности:
— все таки дать свое определение понятия "контракт". Поскольку я представляю себе, что такое контракт в системах с DbC. Но вот что такое контракты, которые изложены в документации или комментариях и их влияние на качество/надежность ПО я себе не очень представляю;
— прокомментировать с позиции контрактов вот этот мой вопрос: http://www.rsdn.ru/forum/message/3090969.1.aspx
Автор: eao197
Дата: 05.09.08

— озвучить, над какими типами ПО вам приходится работать. Поскольку из разговоров с вами складываются три версии: a) вы занимаетесь разработкой и/или анализом алгоритмов или b) вы занимается разработкой вычислительного ПО (научные расчеты и пр.), или c) вы занимаетесь разработкой высоконадежного ПО (грубо говоря, ПО для управления ядерными, химическими объектами или ракетами/спутниками).

Буду очень признателен, если вы все-таки ответите.


SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Re[19]: Почему преждевременная оптимизация - корень всех зол
От: Valery A. Boronin Россия linkedin.com/in/boronin
Дата: 06.10.08 01:09
Оценка:
оффтоп

S>Проблема всех пуританских подходов — в том, что одна маленькая дырка портит всю картинку.

это пять

PS по теме, что есть профайлер, когда и зачем он нужен — не понимаю о чем тут можно дискутировать столь долго
PPS Можно было бы для продолжения дискуссии в подветке сначала дождаться ответа на вопрос про хэш функции с "контрактами"
Автор: eao197
Дата: 05.09.08
— просто несмотря на гигантский объем написанного пока так и не стало яснее что за "контракты" у их адепта. Впрочем, вижу не меня одного
Автор: eao197
Дата: 05.09.08
это заставило проявить любопытство.
Valery A. Boronin, RSDN Team, linkedin.com\in\boronin
R&D Mgmt & Security. AppSec & SDL. Data Protection and Systems Programming. FDE, DLP, Incident Management. Windows Filesystems and Drivers.
Re[4]: Почему преждевременная оптимизация - корень всех зол?
От: Mirrorer  
Дата: 06.10.08 06:39
Оценка:
Здравствуйте, Pavel Dvorkin, Вы писали:

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

Необязательно все. Интеграционные тесты останутся. Если интрефейс к внешним системам не менять.
Re[5]: Почему преждевременная оптимизация - корень всех зол?
От: jazzer Россия Skype: enerjazzer
Дата: 07.10.08 12:40
Оценка: +1
Здравствуйте, Кэр, Вы писали:

J>>>>если тормоза уже заметны, то, очевидно, это уже не преждевременная оптимизация

Кэр>>>Осталось ответить на вопрос — как они заметны? "На глазок"?
J>>Да, "на глазок".

Кэр>Ваш "глазок" сможет детектировать только общую проблему.

Не так. "Глазок" сможет детектировать наличие проблемы. Напоминаю, мы обсуждаем фразу "как тормоза заметны? — на глазок", а не "как понять, в какой строчке кода тормоза? — на глазок".
Я на всякий случай оставил сверху то, что говорилось, дабы не было искушения поменять предмет обсуждения.
Словосочетания "общая проблема" я вообще не понимаю.

Кэр>Очень (очень!) редко анализ работы программы и ее кода сам по себе подскажет, где решение проблемы. Поможет тут только профайлер запущенный на реальных данных.

Я где-то говорил обратное? (Кстати, где брать реальные данные для нового софта, который только разрабатывается?)

Кэр>Разговоры про оптимизацию без замеров профайлера — пустое сотрясание воздуха. И уж точно не разговор инженеров.

Т.е. если программа тормозит, то ни один инженер не должен говорить, что она тормозит и ее надо бы пооптимизировать, пока не прогонит ее под профайлером?
Интересная логика.

J>>А профайлер только поможет найти конкретное место, которое надо оптимизировать, не более того.

Кэр>Ну да. Всего навсего покажет что является проблемой. Куда уж ему до "глазка"
Совершенно верно, потому что у "глазка" другие задачи — показать, что проблема вообще существует.
И как только показано, что проблема существует — с этого момента оптимизация не является преждевременной.
Преждевременная оптимизация — это когда ты сразу пишешь код, закладывая в него какие-то свои с потолка взятые предположения о том, что будет работать быстрее, т.е. когда ты реально ни разу программу не прогнал и пресловутый "глазок" остался вообще незадействованным.

Кэр>Если вы хотите, чтобы ваши шутки ценились за остроумие — шутите умно и смешно. Если конечно вы не Петросян

Если Вы хотите, чтоб с Вами вообще общались, прекратите хамить.
jazzer (Skype: enerjazzer) Ночная тема для RSDN
Автор: jazzer
Дата: 26.11.09

You will always get what you always got
  If you always do  what you always did
Re[6]: Почему преждевременная оптимизация - корень всех зол?
От: Alxndr Германия http://www.google.com/profiles/alexander.poluektov#buzz
Дата: 07.10.08 12:57
Оценка:
Здравствуйте, jazzer, Вы писали:

Кэр>>Если вы хотите, чтобы ваши шутки ценились за остроумие — шутите умно и смешно. Если конечно вы не Петросян

J>Если Вы хотите, чтоб с Вами вообще общались, прекратите хамить.

+1

Просто шуткой про тормозной софт Microsoft ты задел инсайдера за живое
Re[7]: Почему преждевременная оптимизация - корень всех зол?
От: jazzer Россия Skype: enerjazzer
Дата: 07.10.08 13:28
Оценка:
Здравствуйте, Alxndr, Вы писали:

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


Кэр>>>Если вы хотите, чтобы ваши шутки ценились за остроумие — шутите умно и смешно. Если конечно вы не Петросян

J>>Если Вы хотите, чтоб с Вами вообще общались, прекратите хамить.

A>+1


A>Просто шуткой про тормозной софт Microsoft ты задел инсайдера за живое


А-а-а... Чувствительный нынче инсайдер пошел. Вон Саттер наоборот, сам все время хохмит на эту тему, и ничего, и вроде не последний в Microsoft человек

А я вообще сказал только то, что MS, в отличие от программистов-одиночек, совершенно начхать, что там кто кричит на форумах о них и их продуктах, пока альтернативные продукты не начнут отъедать у них ощутимую долю рынка. Собственно, даже утверждения, что у MS софт тормозной, в моих словах не было
jazzer (Skype: enerjazzer) Ночная тема для RSDN
Автор: jazzer
Дата: 26.11.09

You will always get what you always got
  If you always do  what you always did
Re: Почему преждевременная оптимизация - корень всех зол?
От: minorlogic Украина  
Дата: 07.10.08 17:15
Оценка:
Здравствуйте, <Аноним>, Вы писали:

А>Ведь оптимизация может привести к переписыванию много чего и даже в рамках одного модуля или класса. Какой смысл в этой фразе?


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


Обычно 90% времени тратится в 10% кода , так что переписывать много не придется
... << RSDN@Home 1.2.0 alpha 4 rev. 1111>>
Ищу работу, 3D, SLAM, computer graphics/vision.
Подождите ...
Wait...
Пока на собственное сообщение не было ответов, его можно удалить.