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

F>Здравствуйте, Pavel Dvorkin, Вы писали:


F>Быстрее и еще быстрее сделать что? А то может тебе не надо ничего писать а просто скачать Nada — она выполняет свои обязанности в режиме 24/7, с нулевыми затратами процессорного времени и оперативной памяти — просто идеальное решение!

Смотреть лень. Если можешь, расскажи, как там хотя бы суммировать матрицы 5000*5000 с нулевыми затратами процессорного времени.


F>Функциональные требования описывают, что должна делать система.

+1

>Нефункциональные — как она должна это делать. То есть ограничения, накладываемые при выполнении данных функций.

Эти ограничения тоже функциональны. Например, требование решать некую NP-полную задачу — это функциональное ? А если это требуют делать при N=1000, это уже нефункционально ? Сначала напишешь алгоритм полного перебора, а потом скажешь — ой, извините, ответ вы получите в 50 веке

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

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

F>Причем, твое ограничение "Быстрее, черт возьми. Еще быстрее! А теперь еще быстрее" делается просто на раз, всегда бы такие задачи мне ставили. Решение очень простое — делаем очень медленную версию, потом немного улучшаем ее — и она "быстрее, черт возьми", потом еще раз улучшаем — и она "Еще быстрее!", а теперь опять оптимизируем — и теперь она "еще быстрее!". Ура, требования по быстродействию удовлетворены всего за 4 релиза, забираем деньги, идем радоваться.

Не спеши радоваться. Дело в том, что после того, как ты сделаешь очень медленную версию, тебя просто уволят. Она просто никому не нужна.

F>Почему-то чаще ограничения по быстродействию накладываются как-то иначе. Примерно так:

F>1. Сперва все функциональные требования
F>2. Нефункциональные:
F>2.1. Быстродействие:

Еще раз. Быстродействие входит в число функциональных требований. При недостаточно высоком — решение просто не рассматривается.

Вот представь себе ПО управления самолетом. Если оно будет реагировать на изменение обстановки очень медленно — его просто выкинут сразу. В функциональные требования такого ПО входит — реакция не медленнее, чем за такое-то время. Более того. Если окажется, что удовлетворить другим требованиям за это время не удастся — я вполне могу допустить, что часть других требований будет снята или ослаблена. А время — нет, потому что если реакция будет медленнее, чем ..., то управлять уже будет нечем.
У меня, конечно, не самолетное ПО, но идея та же самая. Риски там, правда, нулевые, ничего не грохнется, но недостаточно быстрые решения не рассматриваются. А для достаточно быстрого решения всегда макисма такая — сделайте еще быстрее, если можете.


F>А вот как доказать заказчику, что ты успешно выполнил функции "Быстрее, черт возьми" и, одновременно, "Еще быстрее"? Особенно, если система — что-то новое и раньше другой версии ее же не было? Тут можно только прогрузить его, что делается это на чистом С и использовалось 148 ассемблерных вставок, и, черт возьми, быстрее уже никто не будет, зуб даю. Короче — упражнение в красноречии.

Если нет совсем аналогов — может, и да. Но аналоги обычно есть. И если заказчик мне показывает коммареческую программу, которая делает это за 3 сек, а я ему сначала делаю за 500 мсек, а потом на CUDA за 100 — он будет (был) доволен, хотя не исключено, что попросит сделать за 50 мсек. А поскольку он меня давно знает и знает, что я делаю максимум из того. что могу, то дальше будет одно из двух — либо я сделаю за 50 мсек, либо заяввлю — все, предел, лучше не могу. Он мне поверит, не волнуйся . Впрочем, поверит и в случае, если ПО нне имеет аналогов.

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

А мне и не надо.