Почему вода? Формулируете описание вашего продукта и список фич по этой бумажке и третья сторона может тестировать вас на соответствие описанию, пользователи видят описание и плашку, в идеале всё гуд. Другое дело все мы знаем, как и за сколько третья сторона, сиречь государство, всё это будет тестировать. Но с СРО проблемы совершенно те же.
Боюсь что из-за этого разработчики программ в которых 3.5 кнопки, но которые удовлетворяют 80% домашних пользователей с задачами посмотреть кино, да полистать интернет, получат рычаг давления на тех, кто делает действительно сложное ПО, но которое удовлетворяет всего 20% профессиональных пользователей.
Ну так бы и сказали, что я капитанствую, а не начинали бы завуалированно говорить про то, что: «интерфейс тоже не похож на них». Это ведь тоже в своем роде капитанство. Я и не говорил, что процесс — это код и данные. Я даже не говорил, что код вообще имеет какое-то значение. Я говорил про то, что зачастую о более высокой важности интерфейса перед алгоритмами говорят люди, у которых самый сложный алгоритм в приложении, это — бинарный поиск, естественно для них интерфейс важнее чем алгоритмы, потому что алгоритмы им в общем-то вообще не нужны. У них может быть много кода, но код сам по себе действительно не особо важен, важно чтобы он выполнял свою задачу, без выполнения задачи любой интерфейс бесполезен.
>что этот ГОСТ рассказывает как проектировать это само ПО.
Самые боянистые ГОСТ 34 и IEEE 1471 описывают процесс проектирования. Естественно это не учебник, а просто формальное описание процесса.
Но я то не о том, я ГОСТы вообще привел в пример просто как место, где четко описывается определения алгоритма и архитектуры, в качестве ответ на фейспалм о фразе, говорящей о том, что архитектура и алгоритм это не одно и то же.
Я эти стандарты привел не потому что там единственно верный вариант архитектуры софта(тем более они стандартизируют в основном не архитектуру, а ее проектирование, но тут я виноват, не правильно сформулировал в прошлом комментарии), а потому что там терминология ясно определена. Под изучением стандартов я имею в виду изучение этих стандартов в рамках университетского курса. Там есть конкретные стандарты, и ПО по ним иногда требуется сертифицировать, поэтому их обычно изучают в ВУЗе.
К слову этот пост тоже не об архитектуре, а о методологии разработки ПО.
А что не так в моем комментарии. Вы что, не изучали ни ГОСТ, ни ISO, ни IEEE стандарты на архитектуру ПО, и не знаете в чем разница между архитектурой и алгоритмом? Я в своем первом комментарии сказал, что сейчас прибегут и будут доказывать, что слова Степанова ошибочны, а вы начали что-то говорить про пересказ Макконела и о том, что я рассуждаю что правильно, и что нет.
А я в свою очередь предлагаю вам перечитать комментарий, на который я отвечал, чтобы понять контекст в котором я говорил, и пытаться вникать, вникать, вникать…
1) Хотелось бы увидеть пример, чтобы пара связанных данными алгоритмов выполнялась достаточно быстро на GPU, как и на CPU при одинаковом количестве GFlops. Алгоритмы будут должны выполнятся либо последовательно, либо ветвления уведут производительность в глубокий минус.
2) Это не то. Это чтобы на рядом работающих ядрах выполнять задачи, чтобы при ветвлениях не терять много времени из-за пинга. Это не даст отдать 100 ядер под 100 задач, даже под 50 задач не даст.
3) И что? Производительность то не суммируется. 100 GFlops GPU + 10 GFlops CPU не дадут при таком варианте даже близко столько же производительности на большинстве алгоритмов, как 110 GFlops CPU. Компилятор тоже вам не говорит, будут ли использоваться регистры или память, но это же не говорит, что 1 мбайт ОЗУ работает так же быстро, как и 1 мбайт кэша процессора.
Нет смысла считать флопсы GPU и CPU вместе. На GPU вы можете в один момент времени исполнять только одну программу, сколько бы ядер там не было. А этот процессор работает как полноценный CPU. То есть на нем можно вполне запустить 64 разные программы выполняющиеся параллельно. Это позволяет работать с гораздо большим количеством существующих алгоритмов.
Самые боянистые ГОСТ 34 и IEEE 1471 описывают процесс проектирования. Естественно это не учебник, а просто формальное описание процесса.
Но я то не о том, я ГОСТы вообще привел в пример просто как место, где четко описывается определения алгоритма и архитектуры, в качестве ответ на фейспалм о фразе, говорящей о том, что архитектура и алгоритм это не одно и то же.
К слову этот пост тоже не об архитектуре, а о методологии разработки ПО.
2) Это не то. Это чтобы на рядом работающих ядрах выполнять задачи, чтобы при ветвлениях не терять много времени из-за пинга. Это не даст отдать 100 ядер под 100 задач, даже под 50 задач не даст.
3) И что? Производительность то не суммируется. 100 GFlops GPU + 10 GFlops CPU не дадут при таком варианте даже близко столько же производительности на большинстве алгоритмов, как 110 GFlops CPU. Компилятор тоже вам не говорит, будут ли использоваться регистры или память, но это же не говорит, что 1 мбайт ОЗУ работает так же быстро, как и 1 мбайт кэша процессора.
У них патент на хэш таблицы?