Здравствуйте, Shmj, Вы писали:
S>Не буду спорить, занимался этим 24 года назад примерно. Много воды утекло.
Да принцип тот же и в клавах IBM PC — шина адреса порта замыкается кнопкой на шину данных.
Причём, в простых схемах обходятся без сложного дешифратора номера порта.
Например, в ZX Spectrum де-факто нужен был просто 0 в младшем адресе порта, чтобы подключить буферный регистр скан-адреса клавы к шине данных через замыкатели кнопок.
Re[6]: Что наиболее быстро развивается? Замедлились ли телеф
Здравствуйте, Serginio1, Вы писали:
S> На самом деле еще зависит и от того сколько стоит аренда памяти, герцев и диска. S> Например в .Net набирает популярность Native AOT. Да есть проблемы с динамической компиляцией, обрезкой, но с каждой версией всё веселее и веселее.
S>Our Vision for .NET 9 S> Делается ставка на Native AOT,ИИ.
Не знаю, что в .NET, но могу предположить, что это связано скорей с быстрым стартом. В Java есть проблема, что у популярного фреймворка старт даже небольшого приложения занимает секунд 10, а большого — там и несколько минут может быть. В то же время в облаках используется концепция эластичности. Это когда приложения запускаются в нескольких экземплярах и число экземпляров зависит от нагрузки на систему. Если на пальцах — запускаем одно приложение. Когда у него нагрузка на CPU вырастает выше 80%, запускаем второй экземпляр и половину запросов отсылаем на второй экземпляр. Если нагрузка растёт и дальше, то третий и тд. А если нагрузка падает, то останавливаем часть экземпляров. Ну и очевидная проблема — нагрузка выросла, а приложению ещё минуту стартовать. А запущенный инстанс уже не справляется и начинается перегрузка сервиса, которая каскадом может пойти по другим сервисам.
Также на старт влияет и размер приложения. Прежде чем его запустить, сервер его должен скачать. Конечно можно скачивать заранее, тут есть разные подходы, но в общем и целом — чем меньше приложение, тем меньше проблем.
Вот на фоне вышеописанной ситуации популярность снискал Go, у которого старт мгновенный, образ занимает считанные мегабайты в сравнение с десятками, а то и сотнями у Java. И для решения этой проблемы в Java потихоньку пилят AOT и подобное.
Вот в .NET подозреваю, ситуация похожая.
А насчёт потребления памяти и процессора — тут совсем не факт, что будет выигрыш. Но большого проигрыша точно не будет.
Re[7]: Что наиболее быстро развивается? Замедлились ли телеф
S>> На самом деле еще зависит и от того сколько стоит аренда памяти, герцев и диска. S>> Например в .Net набирает популярность Native AOT. Да есть проблемы с динамической компиляцией, обрезкой, но с каждой версией всё веселее и веселее.
S>>Our Vision for .NET 9 S>> Делается ставка на Native AOT,ИИ.
vsb>Не знаю, что в .NET, но могу предположить, что это связано скорей с быстрым стартом. В Java есть проблема, что у популярного фреймворка старт даже небольшого приложения занимает секунд 10, а большого — там и несколько минут может быть. В то же время в облаках используется концепция эластичности. Это когда приложения запускаются в нескольких экземплярах и число экземпляров зависит от нагрузки на систему. Если на пальцах — запускаем одно приложение. Когда у него нагрузка на CPU вырастает выше 80%, запускаем второй экземпляр и половину запросов отсылаем на второй экземпляр. Если нагрузка растёт и дальше, то третий и тд. А если нагрузка падает, то останавливаем часть экземпляров. Ну и очевидная проблема — нагрузка выросла, а приложению ещё минуту стартовать. А запущенный инстанс уже не справляется и начинается перегрузка сервиса, которая каскадом может пойти по другим сервисам.
Ну для более быстрого старта есть технология NGEN и Компиляция ReadyToRun vsb>Также на старт влияет и размер приложения. Прежде чем его запустить, сервер его должен скачать. Конечно можно скачивать заранее, тут есть разные подходы, но в общем и целом — чем меньше приложение, тем меньше проблем.
vsb>Вот на фоне вышеописанной ситуации популярность снискал Go, у которого старт мгновенный, образ занимает считанные мегабайты в сравнение с десятками, а то и сотнями у Java. И для решения этой проблемы в Java потихоньку пилят AOT и подобное.
vsb>Вот в .NET подозреваю, ситуация похожая.
vsb>А насчёт потребления памяти и процессора — тут совсем не факт, что будет выигрыш. Но большого проигрыша точно не будет.
Native AOT это и есть высокоуровневая альтернатива Go. Все скомпилировано на С++ со сборщиком мусора.
По памяти нет CLR с Jit ом, по процессору С++ компиляция более долгая и опимизирована в отличие от джита https://devblogs.microsoft.com/dotnet/performance-improvements-in-aspnet-core-8/
и солнце б утром не вставало, когда бы не было меня
Здравствуйте, Carc, Вы писали:
C>Зачем? Вот скажите мне, зачем современным приложениям, столько памяти?
Во все времена обычные софтины требовали раз в 100-1000 больше памяти, чем это было минимально необходимо.
Плата за упрощение разработки, скорость деливери, качество и тд. Все джаваскрипты-питон едят больше, чем джавы-дотнеты которые едят больше, чем Си, который ест больше чем чистый ассемблер.
Re[2]: Что наиболее быстро развивается? Замедлились ли телеф
— Массивы выделяются предварительно и в процессе вычислений затем не выделяются и не освобождаются.
— При межпоточной передаче работает что-то вроде круговой очереди указателей на такие массивы.
— Перекладывать данные при расчётах в новое место или делать их inplace зависит сугубо от характера вычислений и ни от чего более. Например, преобразование блока сигнала, представленного int32, во float32 можно и нужно делать только inplace, иначе попахивает профнепригодностью.
— Рассуждения Синклера про "гарантии" и прочее можно смело в dev/null, бо инкапсуляцию данных модулей/объектов еще никто не отменял. Способы владения (и передачи владения) блоков данных подчиняются исключительно и только алгоритмам, их обрабатывающим, а не внутренним взглядам и жизненным принципам особо упрямых коллег. ))
Здравствуйте, Sinclair, Вы писали:
S>Насколько надёжно ваше доказательство того, что "после функции этот массив никому не нужен"? S>Насколько надёжно предположение о том, что это не изменится в будущем?
Опять ты скатываешься в эту ересь. ))
Уже лет 40 назад один неглупый чувак убедительно показал, что серебрянной пули не существует.
Ни одно известное решение не является универсальным, у любого решения есть плюсы и минусы.
Ты же каждый раз предлагаешь смотреть на задачу одним глазом (причём, не скрывая каким именно), рассуждая снова и снова о "гарантиях".
Такое ощущение, что у нас баснословный запас по производительности. ))
Да нет такого запаса...
Он случается, по моим наблюдениям, только в те периоды IT, когда железо умудряется резко обогнать окучивающее его ПО, что на некоторое время создаёт ложное представление о происходящем у людей с неустойчивой психикой.
Эти периоды были дважды на моей памяти и дважды эти периоды были очень малы по историческим меркам.
Зато породили кучу балласта в современном IT, в виде неэффективных ЯП и целого сомна бесполезных на практике религий.
Re[24]: Что наиболее быстро развивается? Замедлились ли теле
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Резюмирую. Бизнес оценит коммерческую приемлемость решения, а оценку стоимости разработки дадут инженеры, базируясь на своем знании стоимости железа, софта, разработки и т.д. PD>При этом бизнес готов выставить свои соображения насчет максимальной стоимости, выше которой он заплатить не может, исходя только из бизнес-соображений (рентабельность, окупаемость и т.д.). PD>Верно ? Да или нет ?
На практике почти всегда есть вилка характеристик и цен.
И у этой вилки может быть овердохрена зубцов.
Поэтому, инженеры обязаны в том числе помогать с выбором решения бизнесу.
И более того, при впечатляющих характистиках решения бизнес может и должен изыскивать инвестиции, что на практике и происходит, т.к. нетривиальные решения конкретных задач порождают порой повторяемые решения, что само ПО становится уже ценностью.
Например, так родились почти все современные популярные CMI и интернетные "платформы", заточенные на те или иные виды деятельности.
В этом месте происходит отделение бизнеса по разработке ПО от конкретного окучиваемого этим ПО бизнеса.
Здравствуйте, Carc, Вы писали:
C>Зачем? Вот скажите мне, зачем современным приложениям, столько памяти? C>Особенно на телефонках. Где по сути вся реальная работа, вся реальная нагрузка идет на какой-либо удаленный сервер, который и делает всю полезную работу! C>Зачем интерфейсным по сути приложениям вот столько нужно памяти? C>Примеров тому масса.
Это классическая "проблема общественного ресурса". Например, стоять в пробке надо 1 час. Не все готовы к этому, поэтому едут на метро. Дорогу расширили в полтора раза, и пробка стала 45 минут. Народ радостно пересел обратно на машины. И пробка снова 1 час... (только на большее кол-во машин)
Как только объем доступной памяти увеличивается, программистам нет смысла ужиматься и экономить. Поэтому они снова забивают ее до предела. И так будет с любым кол-вом памяти.
Проект Ребенок8020 — пошаговый гайд как сделать, вырастить и воспитать ребенка.
Здравствуйте, Sinclair, Вы писали:
S>Из общих соображений бизнес хочет, чтобы это новшество окупилось за время T. S>Отсюда сразу имеем неравенство: 0 < Z/(X-Y) <= (T-T0), где T0 — это срок реализации проекта. Из которого следует, что Z <= (T-T0) * (X-Y). S>В частности, Z0+Z1 <= (T-T0) * (X-Y) — Z2.
Безразмерная величина сравнивается с днями, это нормально?
Кодом людям нужно помогать!
Re[20]: Что наиболее быстро развивается? Замедлились ли теле
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Впрочем, все может быть даже проще. Ты хочешь распознавалку. Отлично. А откуда бизнес знает, можно ли ее вообще реализовать ? Если, вернемся к прежнему, у нас времена MS-DOS или NT4. Бизнес знает, что компьютеры есть, видеокамеры тоже, вообще-то распознавалки сделать можно. Но тебе надо же в риэлтайме, да еще и сколько-то в минуту. Это технически вообще возможно ? Откуда бизнесу это знать ? PD>А если можно все же, то каковы требования к ресурсам ? Во времена NT4 было одно, сейчас несколько иное. А от этого Zi зависят.
Ну принципиальную возможность RnD крупных компаний выясняет или гос. заказы. Бизнес уже потом подбивает под нужды пользователей и
возможной выгоды, с оглядкой на сущ. решения (результат RnD компаний или гос-ва). Так думаю.
Здравствуйте, Sharov, Вы писали:
S>Безразмерная величина сравнивается с днями, это нормально?
У Z размерность "деньги". У X и Y размерность "деньги в единицу времени":
X рублей в год
Y рублей в год
Деление Z/(X-Y) соответственно, имеет размерность "время". В данном случае, измеренное в годах.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[26]: Что наиболее быстро развивается? Замедлились ли теле
Здравствуйте, Pavel Dvorkin, Вы писали: PD>Вот и отлично. Заказчик тут меня мало интересует, с ним понятно.
Ну, ок. Всего-то за десяток постов мы таки выяснили, что исходный вопрос
был малоинтересен. PD>А вот 80 можно распределить несколькими способами PD>Обращаю внимание на то, что во всех этих вариантах предполагается, что результат заказчика удовлетворит по ТЗ. Все будет сделано и будет работать. PD>Если у нас жесткие технические ограничения по памяти и быстродействию машины , то вариант 3 просто не проходит.
Они не смогут написать код, чтобы уложиться в эти 16 Мбайт. А больше взять неоткуда — машин с большей памятью просто нет.
Да всё есть. Просто нужно будет поставить не одну машину с 16 Мбайт, а четыре машины по 16 Мбайт каждая. Это даст разницу в полном Z для вариантов 1, 2, и 3. PD>А вот если такие ограничения отсутствуют, то и команда-3 сделает продукт. Только памяти он займет в 10 раз больше, чем для команд 1-2, и работать будет в 10 раз медленнее, чем для них же.
Всё верно.
PD>А все равно работает. Заказчик доволен. Он теперь вполне знает, сколько за подобный продукт можно просить. И главное, он теперь знает, какие требования к железу и ПО можно предъявлять. Памяти нужно M Гбайт. Раньше он не знал, а теперь знает. Вот же продукт, он требует M, значит, для задачи такого рода меньше быть не может. Быстродействие — аналогично.
С чего это "быть не может"? То, что заказчик — не инженер, не означает, что он идиот.
Из того, что есть программа с требованиями M означает ровно одно — в M можно уложиться. Теперь, когда у заказчика или его конкурента возникает аналогичная задача, инженеры не смогут сказать "нам нужно 2M" — заказчик показывает им готовое решение и говорит "ну ведь вот эти уложились в M, значит и вы уложитесь".
PD>Дальнейшее.
PD>Закончен проект и они разойдутся. Юниоры — в уверенности, что так код писать можно, и вообще качественный код — это код, который удовлетворяет заказчика. Других требований к нему не может быть.
Всё верно. PD>А сеньор, глядя на все это , и сам подумает : а не зря ли я писал качественно. Вот сделали проект черт те как, но все работает, заказчик доволен.
Всё верно. PD>Юниоры через некоторое время станут сеньорами, вполне уверенными, что сорить памятью и применять неэффективные алгоритмы — это норма.
Конечно.
PD>И когда через некоторое время заказчик попросит сделать новую работу стоимостью в 200, поручат ее бывшей команде 3. А они потребуют 500, так как с их пониманием что требуется для чего, надо памяти раз в 5 больше или процессор в 5 раз быстрее. На 300 сойдутся, и сделают, с тем же качеством.
А куда делись команды 1 и 2? Заказчик прекрасно понимает, что монополизация рынка — это плохо, и при прочих равных всё равно запросит коммерческие предложения от всех трёх команд.
И если окажется, что в новом проекте команды предлагают разные результаты, то выиграет более профессиональная команда. Так работает рынок. PD>Вот поэтому мы и имеем, что имеем.
Нет, мы имеем то, что имеем, ровно по одной причине — железо стало дешёвым. В реальности окажется так, что команд типа 1 — раз-два и обчёлся. Они готовы взяться за проект, и сделать его быстро и качественно. Но — не сейчас. Сейчас они уже заняты. Приходите к нам через пару лет — и мы вам всё сделаем. Особенно если вы прямо сейчас внесёте предоплату. А если хотите прямо сейчас — то платить сеньорам надо будет не по 20, а по 40. Они же в дефиците, значит разрыв в зарплате между сеньорами и юниорами будет гораздо более значительным. Открытый рынок балансируется ровно так, чтобы экономия на аппаратуре компенсировалась ростом затрат на фонд оплаты труда.
Мы с вами можем сколько угодно ныть о том, что современная разработка деградировала. Я сам это прекрасно вижу — взять любую "контрольную панель", поставляемую вместе с железками. Что видеокарты, что принтеры — оно же всё ужасное. Гигабайт кода, который помимо умения "переключиться со встроенного видеопроцессора на дискретный" показывает сотни анимированных диалогов, глючит, падает, и тащит с собой две версии питона, джава-машину, и node.js.
Да, печальное, унылое зрелище. Но — то, что оно такое, означает, что большинство участников рынка это устраивает. Переход к оптимальному и устойчивому софту не даёт зримого конкурентного преимущества, увы.
Помимо этого, есть эффект ограниченной информации. Идеальный баланс работает только в идеализированной модели "полной и достоверной информации", которая в жизни не встречается. Заказчик скорее отдаст заказ команде, с которой есть предыдущий успешный опыт — потому что альтернативные команды обещать-то могут всё, что угодно — в том числе и M/2 памяти и T/3 сроков. А потом окажется, что "не получилось" ни M ни T.
Или заказчик был бы готов заказать команде, которая предложит M/2 памяти и T/3 сроков, но он просто не нашёл такую команду. Не успел / не смог / не знал, что такая команда вообще есть.
Вот с этими аспектами и стоит бороться — распространять информацию о том, как писать эффективный код. Писать и пропагандировать фреймворки, которые позволяют писать оптимальный код даже нубам, которые сами не очень понимают, как там оно устроено под капотом, и всё ещё с гарантиями корректности получающегося кода.
Потому что, как ни удивительно, требования производительности идут после требований корректности. Никому не нужна программа, которая тратит M/10 памяти, но в половине случаев даёт неверный результат, или падает.
Помнится, когда мы проверяли смелую гипотезу о том, что на linq нельзя написать эффективную реализацию бинаризации Савола, в исходном C++ коде нашлась пара ошибок. Ну, просто они не стреляли достаточно зрелищно, поэтому автор их так и не заметил
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[27]: Что наиболее быстро развивается? Замедлились ли теле
Здравствуйте, Sinclair, Вы писали:
PD>>Если у нас жесткие технические ограничения по памяти и быстродействию машины , то вариант 3 просто не проходит. PD>Они не смогут написать код, чтобы уложиться в эти 16 Мбайт. А больше взять неоткуда — машин с большей памятью просто нет. S>Да всё есть. Просто нужно будет поставить не одну машину с 16 Мбайт, а четыре машины по 16 Мбайт каждая. Это даст разницу в полном Z для вариантов 1, 2, и 3.
С чего вдруг ? При их способе написания они просто в эти 16 Мбайт не уложатся. Хоть 4 машины поставь, хоть 16. Они могут написать более медленный код, и тогда да, добавлением машин можно проблему решить. Но если уж в ограничения по памяти не уложатся, то новые машины тут не помогут. Или разбить процесс на несколько машин и устроить их взаимодействие ? Ну тогда они в сроки не уложатся, да еще и вопрос, сумеют ли вообще сделать.
PD>>А вот если такие ограничения отсутствуют, то и команда-3 сделает продукт. Только памяти он займет в 10 раз больше, чем для команд 1-2, и работать будет в 10 раз медленнее, чем для них же. S>Всё верно.
Отлично.
PD>>А все равно работает. Заказчик доволен. Он теперь вполне знает, сколько за подобный продукт можно просить. И главное, он теперь знает, какие требования к железу и ПО можно предъявлять. Памяти нужно M Гбайт. Раньше он не знал, а теперь знает. Вот же продукт, он требует M, значит, для задачи такого рода меньше быть не может. Быстродействие — аналогично. S>С чего это "быть не может"? То, что заказчик — не инженер, не означает, что он идиот. S>Из того, что есть программа с требованиями M означает ровно одно — в M можно уложиться. Теперь, когда у заказчика или его конкурента возникает аналогичная задача, инженеры не смогут сказать "нам нужно 2M" — заказчик показывает им готовое решение и говорит "ну ведь вот эти уложились в M, значит и вы уложитесь".
Он не идиот, он дилетант. Теперь он понял, что в М можно уложиться. А до этого не знал.
И понял лишь потому, что ему такие требования эта команда типа 3 выставила. С 4 машинами, как ты предлагаешь (допустим, что это все же удалось бы сделать). Он и теперь не знает, что можно было с одной машиной сделать, если бы делала команда 1
PD>>Дальнейшее.
PD>>Закончен проект и они разойдутся. Юниоры — в уверенности, что так код писать можно, и вообще качественный код — это код, который удовлетворяет заказчика. Других требований к нему не может быть. S>Всё верно. PD>>А сеньор, глядя на все это , и сам подумает : а не зря ли я писал качественно. Вот сделали проект черт те как, но все работает, заказчик доволен. S>Всё верно.
Тоже хорошо.
PD>>Юниоры через некоторое время станут сеньорами, вполне уверенными, что сорить памятью и применять неэффективные алгоритмы — это норма. S>Конечно.
Хорошо.
PD>>И когда через некоторое время заказчик попросит сделать новую работу стоимостью в 200, поручат ее бывшей команде 3. А они потребуют 500, так как с их пониманием что требуется для чего, надо памяти раз в 5 больше или процессор в 5 раз быстрее. На 300 сойдутся, и сделают, с тем же качеством. S>А куда делись команды 1 и 2?
Ну вообще-то я рассматривал варианты. Если делала команда 1 или 2, то по окончании проекта команда разошлась. Может, они соберутся в другом проекте по типу команды 1 или 2, тогда все опять будет хорошо. А может, их раскидают на 4 команды типа 3 — тогда см. выше.
>Заказчик прекрасно понимает, что монополизация рынка — это плохо, и при прочих равных всё равно запросит коммерческие предложения от всех трёх команд. S>И если окажется, что в новом проекте команды предлагают разные результаты, то выиграет более профессиональная команда. Так работает рынок.
Заказчик, если ему первый проект делала команда 3, уже уверен, что именно такие ресурсы нужны. И выставит такие же требования на новый проект, умножив на 2, так как новый проект сложнее. И скорее всего обратится в ту же фирму, они же все сделали, можно им и опять поручить. Ну а если он все же решится устроить конкурс, то для начала выставит те же требования, что и в прошлом проекте * 2. Что при этом скажет потенциальная команда типа 1 — не знаю. Может, и ответит, что 8 машин тут не надо и 200 единиц стоимости тоже, а хватит и 1 машины и 100. Может, и нет. Зачем себе проблемы создавать, да и лишние 100 единиц не помешают. И сделать можно в стиле команды 3, раз уж такие ресурсы предлагают.
PD>>Вот поэтому мы и имеем, что имеем. S>Нет, мы имеем то, что имеем, ровно по одной причине — железо стало дешёвым. В реальности окажется так, что команд типа 1 — раз-два и обчёлся. Они готовы взяться за проект, и сделать его быстро и качественно. Но — не сейчас. Сейчас они уже заняты. Приходите к нам через пару лет — и мы вам всё сделаем. Особенно если вы прямо сейчас внесёте предоплату. А если хотите прямо сейчас — то платить сеньорам надо будет не по 20, а по 40. Они же в дефиците, значит разрыв в зарплате между сеньорами и юниорами будет гораздо более значительным. Открытый рынок балансируется ровно так, чтобы экономия на аппаратуре компенсировалась ростом затрат на фонд оплаты труда.
Вполне могу согласиться. Но почему они в дефиците ? А именно потому, что команды типа 3 смогут сделать при этом железе, а в результате это станет нормой, и команды типа 1-2 будет просто не из кого собрать.
S>Мы с вами можем сколько угодно ныть о том, что современная разработка деградировала. Я сам это прекрасно вижу — взять любую "контрольную панель", поставляемую вместе с железками. Что видеокарты, что принтеры — оно же всё ужасное. Гигабайт кода, который помимо умения "переключиться со встроенного видеопроцессора на дискретный" показывает сотни анимированных диалогов, глючит, падает, и тащит с собой две версии питона, джава-машину, и node.js.
Именно. Голландская болезнь.
S>Да, печальное, унылое зрелище. Но — то, что оно такое, означает, что большинство участников рынка это устраивает. Переход к оптимальному и устойчивому софту не даёт зримого конкурентного преимущества, увы.
Согласен. Вполне согласен. Это и есть деградация отрасли. Потеря качества исполнения
S>Помимо этого, есть эффект ограниченной информации. Идеальный баланс работает только в идеализированной модели "полной и достоверной информации", которая в жизни не встречается. Заказчик скорее отдаст заказ команде, с которой есть предыдущий успешный опыт — потому что альтернативные команды обещать-то могут всё, что угодно — в том числе и M/2 памяти и T/3 сроков. А потом окажется, что "не получилось" ни M ни T. S>Или заказчик был бы готов заказать команде, которая предложит M/2 памяти и T/3 сроков, но он просто не нашёл такую команду. Не успел / не смог / не знал, что такая команда вообще есть.
См. выше.
S>Вот с этими аспектами и стоит бороться — распространять информацию о том, как писать эффективный код. Писать и пропагандировать фреймворки, которые позволяют писать оптимальный код даже нубам, которые сами не очень понимают, как там оно устроено под капотом, и всё ещё с гарантиями корректности получающегося кода.
Глас вопиющего в пустыне. Я еще 20 лет назад тут писал про эффективность, ну и что ? С тех пор только хуже стало.
Нет, не тогда это закончится. Закончится тогда, когда ВТ выйдет на плато. Когда характеристики перестанут расти вообще. Вот тогда понадобятся опять те, кто умеет писать эффективный код. Если они к тому времени останутся.
И то нет уверенности. Просто тогда вместо 1 машины эта команда типа 3 создаст такой кластер, что не дай бог. И будут все уверены, что только так и можно. А стоимость оборудования расти вряд ли будет, она только падает.
S>Потому что, как ни удивительно, требования производительности идут после требований корректности. Никому не нужна программа, которая тратит M/10 памяти, но в половине случаев даёт неверный результат, или падает.
Ну это особый разговор. Я же написал — все 3 команды могут сделать вполне корректно работающее ПО. Если это не выполняется, то говорить не о чем.
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>С чего вдруг ? При их способе написания они просто в эти 16 Мбайт не уложатся. Хоть 4 машины поставь, хоть 16. Они могут написать более медленный код, и тогда да, добавлением машин можно проблему решить. Но если уж в ограничения по памяти не уложатся, то новые машины тут не помогут. Или разбить процесс на несколько машин и устроить их взаимодействие ?
Конечно. Точно так же, как и для роста быстродействия. PD>Ну тогда они в сроки не уложатся, да еще и вопрос, сумеют ли вообще сделать.
Ну так и отлично — тогда проект отдадут тем, кто сможет.
PD>Он не идиот, он дилетант. Теперь он понял, что в М можно уложиться. А до этого не знал. PD>И понял лишь потому, что ему такие требования эта команда типа 3 выставила. С 4 машинами, как ты предлагаешь (допустим, что это все же удалось бы сделать). Он и теперь не знает, что можно было с одной машиной сделать, если бы делала команда 1
Да, не знает. Но точно знает, что 8 машин — избыток. PD>>>Дальнейшее.
PD>Ну вообще-то я рассматривал варианты. Если делала команда 1 или 2, то по окончании проекта команда разошлась.
Не-не-не. Проект отдали команде 3. Что в это время происходит с командами 1 и 2?
Разбегаются из-за невостребованности?
PD>Заказчик, если ему первый проект делала команда 3, уже уверен, что именно такие ресурсы нужны. И выставит такие же требования на новый проект, умножив на 2, так как новый проект сложнее.
Зачем он будет умножать на 2? Он точно так же выставит бизнес-требования (я надеюсь, я достаточно понятно объяснил, откуда берутся бизнес-требования, и мне не придётся ещё раз это пересказывать?).
И точно так же команды будут предлагать решения с разными потребностями в памяти и процессорной мощности.
PD>И скорее всего обратится в ту же фирму, они же все сделали, можно им и опять поручить. Ну а если он все же решится устроить конкурс, то для начала выставит те же требования, что и в прошлом проекте * 2. Что при этом скажет потенциальная команда типа 1 — не знаю. Может, и ответит, что 8 машин тут не надо и 200 единиц стоимости тоже, а хватит и 1 машины и 100.
Напомню, что в предыдущем проекте количества машин среди требований не было. И в новом не будет. PD>Может, и нет. Зачем себе проблемы создавать, да и лишние 100 единиц не помешают. И сделать можно в стиле команды 3, раз уж такие ресурсы предлагают.
Неа. Команде 1 нужно очень прогнуться, потому что у команды 3 есть значительное конкурентное преимущество — сделанный проект. Поэтому если предложить те же условия, то ты точно, с гарантией пролетишь на тендере.
Надо предложить прямо существенное отличие — по срокам, стоимости, или эффективности.
А если вы не готовы напрягаться, или не можете показать реальный экономический эффект — то нефиг и жаловаться, что работу отдают не вам, а недоучкам, пишущим неэффективный код.
PD>Вполне могу согласиться. Но почему они в дефиците ? А именно потому, что команды типа 3 смогут сделать при этом железе, а в результате это станет нормой, и команды типа 1-2 будет просто не из кого собрать.
Нет, не поэтому. А потому, что переход на каждый следующий этап "могу написать программу, которая работает иногда", "могу написать программу, которая работает всегда", и "могу написать программу, которая работает всегда и очень эффективна" требует x10 усилий и времени.
Невозможно с нуля стать сениором за шесть месяцев, увы. А стать джуниором — можно. Было бы можно стать сениором за полгода — джуниоры не смогли бы устроится на работу.
Все компании, где я работал последние 15 лет, говорят: "мы бы хотели брать супер-специалистов, но на рынке их нет. Единственный способ — это брать с улицы и обучать самим".
PD>Согласен. Вполне согласен. Это и есть деградация отрасли. Потеря качества исполнения
Деградация отрасли — это потеря денег. Пока в отрасли крутятся триллионы, с ней всё в порядке.
Если посмотреть в абсолютных цифрах, то специалистов по эффективной разработки стало не меньше, а больше. И софта эффективного стало больше.
Просто помимо этого эффективного софта есть ещё x10000 софта, который не удовлетворяет нашим высоким моральным требованиям. И это прекрасно.
Потому что сениоры — они не из воздуха берутся; это джуниоры, которые научились и выросли. И вчерашний джун — это гораздо более удачная заготовка для сениора, чем просто человек со стороны.
PD>Глас вопиющего в пустыне. Я еще 20 лет назад тут писал про эффективность, ну и что ? С тех пор только хуже стало.
PD>Нет, не тогда это закончится. Закончится тогда, когда ВТ выйдет на плато. Когда характеристики перестанут расти вообще. Вот тогда понадобятся опять те, кто умеет писать эффективный код. Если они к тому времени останутся.
Вообще не закончится. Будет весь спектр. Это как, скажем, с одеждой. Рынок завален низкокачественным ширпотребом. Но если надо — по-прежнему можно купить хорошую вещь.
PD>Ну это особый разговор. Я же написал — все 3 команды могут сделать вполне корректно работающее ПО. Если это не выполняется, то говорить не о чем.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[28]: Что наиболее быстро развивается? Замедлились ли теле
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Глас вопиющего в пустыне. Я еще 20 лет назад тут писал про эффективность, ну и что ? С тех пор только хуже стало. PD>Нет, не тогда это закончится. Закончится тогда, когда ВТ выйдет на плато. Когда характеристики перестанут расти вообще. Вот тогда понадобятся опять те, кто умеет писать эффективный код. Если они к тому времени останутся. PD>И то нет уверенности. Просто тогда вместо 1 машины эта команда типа 3 создаст такой кластер, что не дай бог. И будут все уверены, что только так и можно. А стоимость оборудования расти вряд ли будет, она только падает.
Я еще помню те времена когда программировали в основном математики. Хотя и тогда существовали техникумы и книги "Всё об АСУ"
Но сколько было тех программистов и программ?
Сейчас стоимость софта, значительно дороже чем железо. Для ускорения стали внедрять распараллеливание, асинхронщину итд.
То есть экстенсивные методы.
Например сейчас набирает обороты Native AOT. То есть больше внимание уделяется библиотекам, генераторам кода и оптимизации компиляции.
и солнце б утром не вставало, когда бы не было меня
Re[29]: Что наиболее быстро развивается? Замедлились ли теле
Здравствуйте, Sinclair, Вы писали:
PD>>С чего вдруг ? При их способе написания они просто в эти 16 Мбайт не уложатся. Хоть 4 машины поставь, хоть 16. Они могут написать более медленный код, и тогда да, добавлением машин можно проблему решить. Но если уж в ограничения по памяти не уложатся, то новые машины тут не помогут. Или разбить процесс на несколько машин и устроить их взаимодействие ? S>Конечно. Точно так же, как и для роста быстродействия. PD>>Ну тогда они в сроки не уложатся, да еще и вопрос, сумеют ли вообще сделать. S>Ну так и отлично — тогда проект отдадут тем, кто сможет.
Так я об этом и говорил — команда типа 3 просто не смогла бы его сделать, и увеличение количества машин тут не помогло бы.
PD>>Он не идиот, он дилетант. Теперь он понял, что в М можно уложиться. А до этого не знал. PD>>И понял лишь потому, что ему такие требования эта команда типа 3 выставила. С 4 машинами, как ты предлагаешь (допустим, что это все же удалось бы сделать). Он и теперь не знает, что можно было с одной машиной сделать, если бы делала команда 1 S>Да, не знает. Но точно знает, что 8 машин — избыток.
А откуда ? Вот представь себе, что команда типа 3 все же сделала по твоему алгоритму, только машин им понадобилось бы не 4, а 8. Все, теперь заказчик знает, что нужно 8.
PD>>>>Дальнейшее.
PD>>Ну вообще-то я рассматривал варианты. Если делала команда 1 или 2, то по окончании проекта команда разошлась. S>Не-не-не. Проект отдали команде 3. Что в это время происходит с командами 1 и 2? S>Разбегаются из-за невостребованности?
Ты, видимо, не понял. Не было 3 команд. Я рассматривал варианты — либо собрать команду типа 1, либо типа 2, либо типа 3. В итоге есть одна команда, какого-то типа, ей и поручили.
PD>>Заказчик, если ему первый проект делала команда 3, уже уверен, что именно такие ресурсы нужны. И выставит такие же требования на новый проект, умножив на 2, так как новый проект сложнее. S>Зачем он будет умножать на 2? Он точно так же выставит бизнес-требования (я надеюсь, я достаточно понятно объяснил, откуда берутся бизнес-требования, и мне не придётся ещё раз это пересказывать?).
Да нет, не надо. Я же писал — новая задача сложнее примерно в 2 раза. Это заказчик и сам может оценить, по набору фич. Вот он, базируясь на прежнем проекте, и умножает на 2. Бизнес-требования удовлетворяются, допустим.
PD>>И скорее всего обратится в ту же фирму, они же все сделали, можно им и опять поручить. Ну а если он все же решится устроить конкурс, то для начала выставит те же требования, что и в прошлом проекте * 2. Что при этом скажет потенциальная команда типа 1 — не знаю. Может, и ответит, что 8 машин тут не надо и 200 единиц стоимости тоже, а хватит и 1 машины и 100. S>Напомню, что в предыдущем проекте количества машин среди требований не было. И в новом не будет.
Я вообще о количестве машин не писал, это твое. И по твоему алгоритму сделали (допустим) на 4 машинах. Ну а тут сам бог велел согласиться и на 8.
PD>>Может, и нет. Зачем себе проблемы создавать, да и лишние 100 единиц не помешают. И сделать можно в стиле команды 3, раз уж такие ресурсы предлагают. S>Неа. Команде 1 нужно очень прогнуться, потому что у команды 3 есть значительное конкурентное преимущество — сделанный проект. Поэтому если предложить те же условия, то ты точно, с гарантией пролетишь на тендере. S>Надо предложить прямо существенное отличие — по срокам, стоимости, или эффективности. S>А если вы не готовы напрягаться, или не можете показать реальный экономический эффект — то нефиг и жаловаться, что работу отдают не вам, а недоучкам, пишущим неэффективный код.
Верно. У команды 3 есть преимущество — она прошлый проект сделала. Черт-те как, но сделала. К ней и обратятся, скорее всего. А команду типа 1 возьмут только если она предложит сделать с меньшими расходами.
PD>>Вполне могу согласиться. Но почему они в дефиците ? А именно потому, что команды типа 3 смогут сделать при этом железе, а в результате это станет нормой, и команды типа 1-2 будет просто не из кого собрать. S>Нет, не поэтому. А потому, что переход на каждый следующий этап "могу написать программу, которая работает иногда", "могу написать программу, которая работает всегда", и "могу написать программу, которая работает всегда и очень эффективна" требует x10 усилий и времени. S>Невозможно с нуля стать сениором за шесть месяцев, увы. А стать джуниором — можно. Было бы можно стать сениором за полгода — джуниоры не смогли бы устроится на работу.
А кто говорит про 6 месяцев ? Я вот что писал (для команды типа 2)
PD>Сеньоры команды 2 будут работать надо следующим проектом, с ними все хорошо. Юниоры команды 2 чему-то научатся, и если не в следующем, то через пару проектов сами станут грамотными сеньорами.
S>Все компании, где я работал последние 15 лет, говорят: "мы бы хотели брать супер-специалистов, но на рынке их нет. Единственный способ — это брать с улицы и обучать самим".
Совершенно согласен. Я этим и занимался последние 10 лет, в Школе, которую мы создали в омской фирме. Правда, я доводил их до юниора, а дальше делали уже другие люди, но именно так. Есть среди них и сеньоры, есть и архитекторы.
PD>>Согласен. Вполне согласен. Это и есть деградация отрасли. Потеря качества исполнения S>Деградация отрасли — это потеря денег. Пока в отрасли крутятся триллионы, с ней всё в порядке.
Смотря с какой точки зрения. Да, триллионы, да, в основном бизнес устраивает. Но делается в N раз хуже, чем могло бы делаться. Вот в этом деградация и заключается. В профессиональном качестве продукта. Ты сам об этом писал.
S>Если посмотреть в абсолютных цифрах, то специалистов по эффективной разработки стало не меньше, а больше. И софта эффективного стало больше.
Ну по сравнению с тем, что было 10 лет назад — да, конечно. В N раз больше. Вот только неэффективного стало в KN раз больше.
S>Просто помимо этого эффективного софта есть ещё x10000 софта, который не удовлетворяет нашим высоким моральным требованиям. И это прекрасно. S>Потому что сениоры — они не из воздуха берутся; это джуниоры, которые научились и выросли. И вчерашний джун — это гораздо более удачная заготовка для сениора, чем просто человек со стороны.
Если они пришли из команды типа 2 — да. А если из команды типа 3 — нет. Точнее, они многом, конечно, научились, но вот писать эффективно не научились. Негде было.
PD>>Нет, не тогда это закончится. Закончится тогда, когда ВТ выйдет на плато. Когда характеристики перестанут расти вообще. Вот тогда понадобятся опять те, кто умеет писать эффективный код. Если они к тому времени останутся. S>Вообще не закончится. Будет весь спектр. Это как, скажем, с одеждой. Рынок завален низкокачественным ширпотребом. Но если надо — по-прежнему можно купить хорошую вещь.
Согласен. Я не имею в виду, что вообще закончится. Просто когда компьютеры выйдут на плато, а потребности на плато не выйдут и будут все еще расти, возникнет опять необходимость в качественной разработке. И то не доказано, так как сейчас поставить много машин совсем не проблема, а таким способом можно будет решать эти проблемы без повышения качества. А до выхода количества машин на плато очень далеко, если это плато вообще может быть.
With best regards
Pavel Dvorkin
Re[4]: Что наиболее быстро развивается? Замедлились ли телефоны?
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Нет шансов ошибиться (ну почти , после функции этот массив никому не нужен. Чистый код. На входе массив, на выходе результат. Массив забываем, результат используем.
Как правило, "нет шансов ошибиться" и "всё под контролем" это уверенные симптомы проблемы.
