Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Хм... Когда ракету строили — были уверены, что она первую космическую наберет ? Прототипов-то не было. Или строили по принципу — давайте построим, тогда и выясним, может она со скоростью 8 км/ч летать или нет ? Сомнительно. Все же, думаю, рассчитали, и пришли к выводу, что можно. PD>А атомную бомбу возьми ? Получится или нет технически — никто не мог быть уверен, но что физически она возможна — знали точно, иначе бы и делать, скорее всего, не стали.
А термоядерный реактор до сих пор делают, и уже 60 лет не могут доделать, притом всем ясно что в принципе он возможен, да и природный прототип каждый день над головой висит. У нас в программировании такие "термоядерные реакторы" (то есть проекты по предварительной оценке требующей x трудозатрат, а реально делающиеся за NN * x ) скорее норма чем исключение.
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Еще раз — для тебя и всех остальных. Я не спрашиваю, нужно ли это делать. Я спрашиваю — можно ли это сделать (оценить характеристики априорно) или в принципе нельзя ?
Если вспомнить проблему остановки и прочие невычислимости то в принципе нельзя.
PD>Верно ли, что мы столкнулись с ситуацией, когда такая оценка невозможна в принципе ? Законы-то есть (скорость процессора, объем ОП, пропускная способность сети или диска , временнАя зависимость алгоритмов и т.д.), но на основании этих данных (и других, что я не перечислил) в принципе нельзя оценить некие характеристики разрабатываемой системы, а остается лишь действовать по принципу черного ящика ?
в общем случае, верно. т.к. сложность алгоритмов отличается от O(1) до O(n^n) и более.
и соответственно пока не зафиксирован алгоритм — тяжело сделать какие-то расчеты.
но если основные алгоритмы зафиксированы, то можно провести оценку вычислительной сложности, например, можно легко провести оценку задачи про peg-парсер, про который упоминал wolfhound
Одно из требований это возможность использования полученного парсера для разбора кода в IDE в реальном времени те 2-3 метра в секунду минимум вынь да полож.
попробуй прикинуть вычислительную сложность задачи
первая оценка снизу: 2-3*10^6 операций/с — обработать эти данные быстрее, чем линейно не получится, хотя... (если каждый раз парсится один и тот же текст, то можно это использовать, и перейти, например, к задаче парсинга только изменений)
алгоритм peg-парсера простой: либо движемся вперед по строке, либо возвращаемся на одну из предыдущих позиций и опять вперед.
общая сложность такого алгоритма — это:
сколько в среднем мы пробегаем по каждому символу,
или другими словами — как часто делается возврат, сколько при этом делается неудачных попыток и на какую глубину.
для обычной грамматике — перебор делается каждый десятый символ, перебирается 3-5 неудачных варианта на глубину 20
итого: 6-10 пробегов по строке
вторая оценка снизу: 2-3 * 10^7 операций/с
возможность процессора можно оценить как те же 2-3*10^9 операций (в первом приближении считаем, что выполняется одна элементарная операция за такт, и 2-3 взято для круглости)
делим одно на другое — получаем:
1. что задача выполнима — есть 100 кратный запас по сравнению с идеалом,
2. что близкая к идеалу программа будет обсчитывать 2-3 мб текста за 1мс
зы
если вспомнить, что задача peg-парсера связана со сравнением(поиском) одного текста с другим, а для этого:
1. есть более эффективные алгоритмы чем линейные
2. за один такт можно обрабатывать несколько символов
то в идеале используя эти техники можно улучшить еще в 10 раз.
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Вот это интереснее. То есть ты все же оценил, как эту задачу решать и пришел к выводу, что она решается. Способ оценки ? (естественно, мне твои секреты ни к чему, общие принципы)
Ничего я не оценивал. Я ее решил.
Причем решал я ее итерациями.
Сначала получилось решение которе тормозило.
Потом проводя оптимизации я довел производительность до вполне приемлемого уровня.
... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Откуда данные, что управляемый термояд в принципе возможен при адекватных размерах реактора ?
Так он уже достигнут на последних установках, вопрос уже скорее технический. Тот же ITER уже будет реально работать.
>> да и природный прототип каждый день над головой висит.
PD>Это не аргумент. Атомная бомба возможна, но пока нет критической массы — теоретически невозможна. А сделать размером с Солнце не получится
Ну взрывной термоядерный реактор по проектам монстр конечно, но размером скорее со стадион а не с солнце
Здравствуйте, Pavel Dvorkin,
PD>>>Заявляя такое, отдаете ли вы себе отчет, в том, что вы фактически говорите : "Мы не в состоянии априорно оценить характеристики разрабатываемой системы. Мы можем лишь ее сделать, а потом посмотрим, что у нас получилось" ? ГМ>>-- ГМ>>Я, естественно, буду говорить только о своих задачах, и ответ на вопрос будет для меня положительным.
PD>То есть ты согласен, что "Мы не в состоянии априорно оценить характеристики разрабатываемой системы. Мы можем лишь ее сделать, а потом посмотрим, что у нас получилось ?"
--
Да, согласен (для моих, так сказать, личных задач).
При этом для, так сказать, официальных моих работ ответ как раз отрицательный — сначала была не только оценена, но и задана характеристика системы, а потом ее стали имплементировать.
ГМ>>4. Имеет смысл реализовать систему, а затем оценить сложность (ограничение) рещаемых задач.
PD>Еще раз — для тебя и всех остальных. Я не спрашиваю, нужно ли это делать. Я спрашиваю — можно ли это сделать (оценить характеристики априорно) или в принципе нельзя ?
--
Да, я вполне могу представить системы, для которых это можно (и нужно) сделать до начала выполнения работы. Однако под "апприорной оценкой характеристик системы" мы, скорее всего, понимаем разные вещи...
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Я упорно спрашиваю о принципе. Я не спрашиваю, как лучше делать, что выгоднее и т.д. Меня один вопрос интересует — в принципе оценить можно или нет ? А мне в ответ опять — лучше не оценивать, потому что...
О чем вообще тут рассуждать без привязки к конкретной задаче и методам ее решения?
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Если вы признаете, что предсказать характеристики системы априорно нельзя, то из-за чего это ?
Встречный вопрос: из той системы, которую ты сейчас разрабатываешь, сколько еще байтов и микросекунд на каждой итерации, согласно твоим расчетам, ты еще можешь выбросить без ущерба для остальных характеристик системы? Насколько точен был твой анализ для текущей версии твоей системы?
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>>>Верно ли, что мы столкнулись с ситуацией, когда такая оценка невозможна в принципе ? Законы-то есть (скорость процессора, объем ОП, пропускная способность сети или диска , временнАя зависимость алгоритмов и т.д.), но на основании этих данных (и других, что я не перечислил) в принципе нельзя оценить некие характеристики разрабатываемой системы, а остается лишь действовать по принципу черного ящика ?
S>>Уже неоднократно отвечено: стоимость подобных расчётов будет сопоставима с разработкой программы, а погрешность оценки будет заведомо выше, чем у результатов трассировки на рабочем коде.
PD>Без аргументов. Без объяснения причин. Да или нет ?
Производительность — это всего лишь один из параметров системы. Вы уже научились верифицировать параметры программы без ее запуска? Да или нет?
PD>Верно ли, что мы столкнулись с ситуацией, когда такая оценка невозможна в принципе ? Законы-то есть (скорость процессора, объем ОП, пропускная способность сети или диска , временнАя зависимость алгоритмов и т.д.), но на основании этих данных (и других, что я не перечислил) в принципе нельзя оценить некие характеристики разрабатываемой системы, а остается лишь действовать по принципу черного ящика ?
Не верно. Если говорите что оценка для конкретной задачи невозможна, то обоснуйте и скажите что реально сделать на сегодня и в какие сроки и с какими ограничениями. Пусть с меньшими характеристиками, но в перспективе при доступности таких то и таких технологий в полном объеме.
PD>Еще раз — для тебя и всех остальных. Я не спрашиваю, нужно ли это делать. Я спрашиваю — можно ли это сделать (оценить характеристики априорно) или в принципе нельзя ?
Еще раз для тебя и для тебя. Заявлять что такой класс задач решаем всегда — абсурд. Если вопрос задается в общем виде — то ответ нет — нельзя
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Здравствуйте, gandjustas, Вы писали:
G>>Поэтому оценивать заранее конечно можно, но зачастую не нужно.
PD>То есть твой ответ — в принципе (или теоретически) все же можно, но по ряду соображений не нужно, не выгодно, не стоит ?
Мой ответ: незачем. В большинстве случаев это ничего не даст, поэтому и не занимаются.
Например я каким-то образом посчитал что документ в системе документооборота обрабатывается 2 секунды. Это много или мало?
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Еще раз — для тебя и всех остальных. Я не спрашиваю, нужно ли это делать. Я спрашиваю — можно ли это сделать (оценить характеристики априорно) или в принципе нельзя ?
Еще раз: что ты собираешься оценивать?
Вот я создаю сайт. Что мне оценивать?
1)Скорость загрузки страниц? Она будет зависеть от количества пользователей.
2)Время обработки запросов. Оно будет зависеть от количества пользователей.
3)Объем базы данных\места на диске? Оно будет зависеть от количества пользователей.
4)Сколько запросов я смогу выдержать на данном железе? Только в этом можно дать оценку.
Но мне важно чтобы я мог добавить железа и выдержать больше пользователей, возможно даже ценой уменьшения возможностей для одной железки.
имеет смысл оценивать теоретическую вычислительную сложность задачи, и сравнивать ее с вычислительной сложностью реальной программы.
это дает невязку между реализацией и идеалом, и дает возможность оценить эффективность текущей реализации, а также спрогнозировать величину возможной оптимизации.
G>Например я каким-то образом посчитал что документ в системе документооборота обрабатывается 2 секунды. Это много или мало?
многовато, как-то.
какие задачи при этом решаются, и на что время уходит?
какой размер документа?
какое кол-во документов в хранилище?
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>В настоящее время большинство решило, что premature optimization — это зло, что этого делать не надо. Надо создать некую работающую систему, а потом посмотреть — работает ли она с нужными характеристиками. Если нет — оптимизировать те места, которые являются узким местом, находить их можно с помощью профайлера и т.д.
Преждевременная оптимизация — зло, отсутствие такой оптимизации — верх глупости
PD>Заявляя такое, отдаете ли вы себе отчет, в том, что вы фактически говорите : "Мы не в состоянии априорно оценить характеристики разрабатываемой системы. Мы можем лишь ее сделать, а потом посмотрим, что у нас получилось" ?
Вообще говоря характеристики разрабатываемой системы оценить достаточно сложно.
Когда говорят про преждевременную оптимизацию, то обычно это значит, оптимизация наобум, без наличия должной информации.
PD>(Отмечу со своей стороны, что ИМХО эта точка зрения как-то не очень вяжется с методами, используемыми при разработке иных систем. Трудно предположить, что разрабатывая самолет, создатели бы сказали — мы не знаем, с какой скорстью он будет летать, построим — посмотрим, если мало будет — будем что-то улучшать. Или, скажем, мостостроители заявили — не знаем, выдержит ли это мост груженые песком МАЗы, если не выдержит и обломится — добавим быков и укрепим полотно. Или.. примеров можно много привести. Но это в скобках).
Основная часть опыта была получена методом проб и ошибок.
Мост можно построить, потому что опыт был получен на других таких же или похожих мостах, бОлшая часть которых просто развалилась
Зато были разработаны методы достижения характеристик.
С самолетами — тоже самое.
Грубо говоря — были построены N-полнофункциональных версий прежде чем удалось гарантировать характеристики.
В случае с софтом нужно получить некоторую гарантию с первой же версии.
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Пример не пойдет. Да, нельзя рассчитать поведение всех молекул, если их 5 млн. Но методы для оценки поведения этой системы есть, они совсем другие (статистическая термодинамика), и дают в результате информацию о поведении системы в целом не менее адекватно, чем квантовая механика об одной или 5 молекулах.
Когда люди толко научились строить мосты, про газ у них не было никакого понятия.
Это сейчас есть методы оценки поведения таких систем, а раньше их не было.
С чего ты взял, что для софтостроения эти методы уже есть ?
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Что он есть — конечно, знал, что именно 10 — нет.
А между тем тебе его несколько раз сообщали в другом форуме, в треде про JS.
PD>Но это ничего не меняет. Чтобы применить к чему-то коэффициент, надо это сначала вычислить.
Вычислить не получилось. До сих пор хотят вычислить и не выходит. Не хватает адекватной модели например по сопромату.
Потому берется от балды — что бы подстраховаться и что бы дома было строить рентабельно.
Здравствуйте, gandjustas, Вы писали:
g> Вот я создаю сайт. Что мне оценивать? g> 1)Скорость загрузки страниц? Она будет зависеть от количества пользователей. g> 2)Время обработки запросов. Оно будет зависеть от количества пользователей. g> 3)Объем базы данных\места на диске? Оно будет зависеть от количества пользователей.
Это верно, но минимальный и предельный объем пользователей заранее известен и ты можешь исходить из этой эвристики. Дополнительно у тебя на руках есть теоретический доход с одного пользователя, бюджет, оптимальные и предельные временные оценки обработки запросов и т.д. Сложив все вместе ты получаешь нужные тебе требования к производительности, масштабируемости и т.д.
Здравствуйте, samius, Вы писали:
S>Здравствуйте, Pavel Dvorkin, Вы писали:
PD>>Я упорно спрашиваю о принципе. Я не спрашиваю, как лучше делать, что выгоднее и т.д. Меня один вопрос интересует — в принципе оценить можно или нет ? А мне в ответ опять — лучше не оценивать, потому что...
S>О чем вообще тут рассуждать без привязки к конкретной задаче и методам ее решения?
Здравствуйте, Ikemefula, Вы писали:
PD>>Пример не пойдет. Да, нельзя рассчитать поведение всех молекул, если их 5 млн. Но методы для оценки поведения этой системы есть, они совсем другие (статистическая термодинамика), и дают в результате информацию о поведении системы в целом не менее адекватно, чем квантовая механика об одной или 5 молекулах.
I>Когда люди толко научились строить мосты, про газ у них не было никакого понятия.
I>Это сейчас есть методы оценки поведения таких систем, а раньше их не было.
I>С чего ты взял, что для софтостроения эти методы уже есть ?
То есть они могут быть созданы в принципе, но пока их нет ?
