Что наиболее быстро развивается? Замедлились ли телефоны? - Компьютерные священные войны

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

K>Только её кучу раз переделывали. Лет 15 назад официальный клиент ICQ был очень прожорливый и 20 МБ точно потреблял.

Ну а когда я с ней работал, у меня всего 8 или 16 было. И едва ли я позволил бы ей хотя бы 3 занять — мне работать надо.

K>Потому народ массово сидел на сторонней поделке в виде qip, который был компактнее.

Не имел с ним дела. Мне и ICQ хватало тогда.

PD>>А между тем и с тем ,и с другим я в основном работаю так же, как с ICQ тогда, то есть обмениваюсь короткими сообщениями

K>ICQ и сейчас существует.

Я знаю.

K>Активный частный набор 26 МБ
K>Выделенная память — 140 МБ
K>После небольшой переписки активный частный набор стал 44 МБ.

Итого в результате обмена нескольких Кбайт (небольшая переписка) добавилось 18 Мбайт.

Что и требовалось доказать.

PD>>Notepad (пустой) занял примерно 2 Мбайта. На моей машине того времени он бы четверть памяти занял!

K>Так и битность системы наверно 64, а не 32 и строки наверно в Unicode хранятся.

Ну и что ? Пусть Unicode, значит, в 2 раза больше. Всего в 2

K>Не думаю, что блокнот как-то переписывали кривыми руками, чтобы больше ресурсов потреблял.

Ничего там не переписывали. Notepad — это просто multiline edit с привешенным меню.

K>Просто пересобирают под актуальные системы и вот результат.

Именно. И этот multiline edit потребляет во много раз больше памяти

PD>>А черт его знает. Но на моем прежнем смартфоне было 4 Гб, а новый купил (года 2 назад) уже с 6. А сейчас и 6 — так себе.

K>У меня на 4 Гб прекрасно все мессенджеры работают и сайты открываются, никаких тормозов и проблем.

Да и у меня на 4 на старом смартфоне все было хорошо. купил новый из-за экрана, ну а уж раз покупать — взял на 6, кто его знает, сколько памяти будут новые версии жрать.

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

PD>>Просто разучились писать приложения компактно.
C>Может просто и не умели!?!

Умели. Когда на машине 8 Мбайт, неумевшие уложиться в несколько сот Кбайт просто исчезали из отрасли.

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

SK>Уже практически норма, когда реакция приложения на ввод одной буквы с клавиатуры больше 300мс.

Когда для обработки нажатия клавиши надо привлечь 3 фабрики, 2 фасада и 4 адаптера и гонять между ними данные, то ничего удивительного.

SK>такого себе не позволяли даже XT c 256кб..

А тогда их не было, или, по крайней мере, о них особо не знали.

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

PD>Активный частный набор (то есть то, что в ОП, не в свопе) 70 Мбайт

15 лет не пользовался Windows, но если не ошибаюсь Active Working Set отличается от Working Set не только тем что последний выгружается на диск.
Скорее всего,
Active Working Set — это RSS, resident set size, the non-swapped physical memory that a task has used.
Working Set — это VSZ, virtual memory size of the process.
Память пользовательских процессов включает в себя:
code/stack/data
heap
file mappings
shared memory
в Linux еще vDSO/vsyscall/vvar

Эти страницы могут находиться в RAM или предоставляться ОС при обращении процесса: всевозможная виртуальная память, copy-on-write в том числе для shared-pages и zero-page(если память выделена через zmalloc); userfaultfd; при обращении к файлам драйверов; на диске в свопе/file-mappings.

Например, для Telegram: VSZ 190Gb, RSS 526Mb, всего 2459 участков.

ps -aux
USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND
...
roman 3350437 1.2 1.6 190023936 526996 ? SLl Feb20 43:47 /snap/telegram-desktop/5581/usr/bin/telegram-desktop --

wc -l /proc/3350437/maps
2459 /proc/3350437/maps

Если сравнить, процесс виртуальной машины qemu/kvm(в idle-состоянии centos8 16gb): VSZ 18Gb, RSS 2.5Gb, всего 835 участков.

ps -aux|grep qemu
root 746000 0.0 0.0 9080 2560 pts/3 S+ 11:14 0:00 grep --color=auto qemu
libvirt+ 1364436 6.7 7.5 18371608 2470232 ? Sl Feb20 273:26 /usr/bin/qemu-system-x86_64 ...

wc -l /proc/1364436/maps
835 /proc/1364436/maps

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

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

PD>>>Просто разучились писать приложения компактно.
C>>Может просто и не умели!?!

PD>Умели. Когда на машине 8 Мбайт, неумевшие уложиться в несколько сот Кбайт просто исчезали из отрасли.
Я не к тому мысль вёл. То, что раньше умели , я и не сомневался никогда.
Да только те, что умели, явно не создают современные приложения.

Новомодные "хипстеры" из подходов к разработке по моему знают только "хлоп, шлёп, хренакс и в продакшн".
Какое уж тут профилирование, требования к ресурсам, да и заканчивая обычной UX, Use-case аналитикой, code-review, да usability в придачу.

PD>Умели. Когда на машине 8 Мбайт, неумевшие уложиться в несколько сот Кбайт просто исчезали из отрасли.
Я в курсе, и более чем в курсе.

а) самому доводилось... 95-ая винда, 16 метров, 300 МБ HDD, а надо чтобы "работало и всё тут". Что ж вы хотели, это ж ~~бубльгум~~ минздрав 99-го года...

б) учился у людей которые еще БЭСМ-6 и PDP портировали, да до ума доводили Unix System V.

Как-то уже приводил здесь ссылку: "История одного байта"
Еще раз оговорюсь: мопед не мой!.
И еще раз, по слогам: "не ма-ё! Афф-тар ни-я!!!" (а то тут в привате как-то намекали уже).

Был найдено на просторах этих ихних интернетов, в далеких началах еще аж нулевых... Ни то в 2002-ом, ни то в 2003-ем..
Оригинал потом потерялся, хорошо что в архивах, в оффлайне остался. Вот и выложил себе на память, да потомкам на заметку

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

lpd>Active Working Set — это RSS, resident set size, the non-swapped physical memory that a task has used.

Это количество ОП, которые процесс реально сейчас занимает. Сейчас эти страницы в ОП. В дальнейшем возможно, что окажутся в свопе.

lpd>Working Set — это VSZ, virtual memory size of the process.

Нет. Последнее в терминах Task Manager и есть VM Size или Выделенная память

Я привел значения обоих

Телеграм —

Активный частный набор (то есть то, что в ОП, не в свопе) 70 Мбайт
Выделенная память — 436 Мбайт

Это значит, что он выделил 436 Мб с помощью VirtualAllov. Из них 70 Мб сейчас в ОП, а остальное на диске в свопе или mmf

Я когда-то на этот счет сообщение написал

https://rsdn.org/forum/dotnet/1869304.1

lpd>Память пользовательских процессов включает в себя:
lpd> code/stack/data
lpd> heap
lpd> file mappings
lpd> shared memory

Это на уровне процесса. На уровне системы это все аллоцированная память, хотя атрибуты PAGE_* различны

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

PD>>Умели. Когда на машине 8 Мбайт, неумевшие уложиться в несколько сот Кбайт просто исчезали из отрасли.
C>Я в курсе, и более чем в курсе.

C>а) самому доводилось... 95-ая винда, 16 метров, 300 МБ HDD, а надо чтобы "работало и всё тут". Что ж вы хотели, это ж ~~бубльгум~~ минздрав 99-го года...

C>б) учился у людей которые еще БЭСМ-6 и PDP портировали, да до ума доводили Unix System V.

Мне довелось участвовать в одном проекте, где мне прощалось все. Нарушение всех принципов ООП (их, впрочем, нарушить было несложно, так как писалось на С). Непонятные структуры данных. Копипастинг вместо рефакторинга. И т.д.

В общем все. Код был ужасный, но мне никто и слова не сказал.

Не прощалось лишь одно — недостаточно высокое быстродействие. Ради этого я и возился 3 года.

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

PD>Когда для обработки нажатия клавиши надо привлечь 3 фабрики, 2 фасада и 4 адаптера и гонять между ними данные, то ничего удивительного.

Добавление фич всегда приводит к росту сложности архитектуры и соотв. потреблаемых ресурсов.
В данном случае целое — не есть сумма компонентов, а нечто большее.

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

__>Добавление фич всегда приводит к росту сложности архитектуры и соотв. потреблаемых ресурсов.

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

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

PD>Не имел с ним дела. Мне и ICQ хватало тогда.

Ну, у меня был комп с 256 МБ оперативы. Официальный клиент в жрал что-то около 20 МБ. QIP раза в 4 меньше, ещё и субъективно удобнее был.

PD>Итого в результате обмена нескольких Кбайт (небольшая переписка) добавилось 18 Мбайт.

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

PD>Что и требовалось доказать.

Ну, да. Наглядная иллюстрация подхода "Но пусть все это другое сидит на диске, пока не потребуется.".

PD>Ничего там не переписывали. Notepad — это просто multiline edit с привешенным меню.

Если не переписывали, а стало жрать больше памяти, значит дело не в том, что разучились писать.
Компиляторы может память не жалеют, в ОС поменяли планировщик памяти или ещё что привело к повышенному потреблению.

Итого имеем стандартный Notepad, который написан под WinAPI и использует стандартные библиотеки и контролы, но у него за годы выросло потребление памяти в разы.
А те же мессенджеры используют Qt или ещё что-то для кроссплатформенности, т.к. нужно и винду и линукс и в веб ещё засунуть.
В той же ICQ не было никакого оформления сообщений (смайлики просто через замену символов работали). Сейчас и картинки можно со стикерами и markdown.
Мало кому заплатят денег под нативную реализацию для всех платформ. Обычно берётся что-то универсальное с кучей лишнего.
Думаю, что основное там — это библиотеки для GUI и т.п. Иначе не знаю чего там в ICQ напихали, что exe занимает больше 100 МБ. Хотя Qt отдельно 26 МБ лежит.
20 лет назад кроссплатформа не так важна была и людям платили за разработку на WTL, MFC или голом WinAPI.
Сейчас на меня как на идиота посмотрят, если что-то из этого предложу.
А если я те же самые окошки создам в Qt и подключу эту библиотеку, то и памяти куда больше улетит автоматически. Кривизна моих рук уже малую роль тут сыграет.
Нужно, чтобы железо было дорогим, а программисты дешёвыми, тогда опять перестанут использовать универсальное и прожорливое и начнут дёргать нативное.

Можно ещё игрушки вспомнить. Раньше рисовали текстурку со шрифтом и вот набор символов одинаковой ширины, мало памяти занимает, быстро и оптимально (ещё забавная локализация с потерей знаков препинания и т.п.)
Сейчас такой оптимизацией никто заниматься не будет не потому что не умеют и не знают, а потому что результат плохой будет и современное железо позволяет о таком не задумываться.

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

SK>>Уже практически норма, когда реакция приложения на ввод одной буквы с клавиатуры больше 300мс.

PD>Когда для обработки нажатия клавиши надо привлечь

Кому надо и зачем?

По моему, это большой красный плакат, на котором "разработчики" ПО, все поголовно, расписываются в своей проф. непригодности.

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

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

K>Ну, у меня был комп с 256 МБ оперативы. Официальный клиент в жрал что-то около 20 МБ. QIP раза в 4 меньше, ещё и субъективно удобнее был.

У меня тоже был такой, но намного, само собой, позже. И да, ICQ там занимал сколько-то Мбайт.

PD>>Итого в результате обмена нескольких Кбайт (небольшая переписка) добавилось 18 Мбайт.

K>Кроме переписки там и история сообщений подгрузилась с картинками, превьюшками ссылок и т.п

Вся твоя история сообщений (с одним человеком) едва ли и на 100 Кбайт понянет. Ты сначала эти 100000 символов набери, а потом поговорим.

А картинки — ну да. Только вот в мессенджере хватит и тумбиналов, а сами картинки спокойно могут подгружаться, когда надо. Ты даже на 50 картинок одновременно смотреть не сможешь.

Там ведь не только картинки, там и видео может быть на десятки Мб, если не больше. Их тоже нужно все в ОП хранить ?

PD>>Что и требовалось доказать.

K>Ну, да. Наглядная иллюстрация подхода "Но пусть все это другое сидит на диске, пока не потребуется.".

Не понял. Он тебе не нравится ?

K>Если не переписывали, а стало жрать больше памяти, значит дело не в том, что разучились писать.
K>Компиляторы может память не жалеют, в ОС поменяли планировщик памяти или ещё что привело к повышенному потреблению.

Планировщик серьезно не меняли. А вот сами контролы переписали, да и стек тоже. Раньше все было ясно : user32.dll -> win32k.sys . Или kernel32.dll -_ntdll.dll -> ntoskrl.exe/ А сейчас чего-то там накрутили

K>Итого имеем стандартный Notepad, который написан под WinAPI и использует стандартные библиотеки и контролы, но у него за годы выросло потребление памяти в разы.
K>А те же мессенджеры используют Qt или ещё что-то для кроссплатформенности, т.к. нужно и винду и линукс и в веб ещё засунуть.
K>В той же ICQ не было никакого оформления сообщений (смайлики просто через замену символов работали). Сейчас и картинки можно со стикерами и markdown.

Да уж. Чтобы добавить картинки небольшого размера, надо потребление памяти увеличить на 2 порядка.

K>Мало кому заплатят денег под нативную реализацию для всех платформ. Обычно берётся что-то универсальное с кучей лишнего.

А вот это верно. Жертва качества за счет удовлетворения требований по скорости разработки, требованиям заказчика и т.д. Эффективность — в последнюю очередь, когда уж припрет.

K>Думаю, что основное там — это библиотеки для GUI и т.п. Иначе не знаю чего там в ICQ напихали, что exe занимает больше 100 МБ. Хотя Qt отдельно 26 МБ лежит.

Это то выяснить несложно, посмотреть структуру EXE. Но не в этом дело. Если там 90% ресурсов, то ничего страшного нет. Понятно, что картинки надо где-то хранить, объем памяти при этом фиксирован. Вот только почему в ОП ?

K>20 лет назад кроссплатформа не так важна была и людям платили за разработку на WTL, MFC или голом WinAPI.
K>Сейчас на меня как на идиота посмотрят, если что-то из этого предложу.

Да, увы, тут ты прав.

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

Голосование по эффективности и расходам ресурсов

https://rsdn.org/poll/9966

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

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

PD>Голосование по эффективности и расходам ресурсов

PD>https://rsdn.org/poll/9966
Павел, «ну кто так строит» (ц).

Надо обработать большой массив по не совсем тривиальному алгоритму. Можно создать его копию, можно и не создавать. На написание кода с копией уйдет час Вашего времени, без копии — 4 часа. Что предпочтете ?

Насколько большой? Что за алгоритм (модифицирует массив или нет)?
Массив большой это что — по памяти или по числу элементов?

Имхо, тут сразу же всё упрется в структуры данных (векторы, деки, списки односвязные или двухсвязные) ну и.т.д.
А мы ж прекрасно понимаем, что структуры данных и алгоритмы обработки идут рука об руку. Для одних алгоритмов хороши одни структуры памяти, а для других другие (я в смысле идиомы: бинарный поиск азмЪ езмЪ гут, но уже извольте отсортированный массив подать).
Тут сразу же вспоминается Скотт Мейерс, с его клевыми рецептами.

А по сути я б сам сделал иначе в архитектурном плане.
Разделил бы реализации, и доступ к ним.

Handle_Array_WithCopy(MyArray& ar);//функция с созданием копии
Handle_Array_NOCopy(MyArray& ar);//функция без копии

//общая функция - суть фасад, она сама выбирает какую реализацию звать. 
//А уж как выбирает - в рантайме, в дизайн-тайме, мрачно хардкодно - это уже детали
//Главное: эта фасадная функция скрывает доступ к деталям реализации
//PS: потом можно и открыть доступ к реализационным функциями отдельно.
//Главное в другом: по умолчанию реализацию лучше держать закрытой, и скрывать детали выбора 
//- чтоб через единственную точку доступа все шло - а именно через фасадную Handle_Array(MyArray& ar);
Handle_Array(MyArray& ar);

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

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

PD>Голосование по эффективности и расходам ресурсов

Зависит от кучи факторов.
Одно дело если это какая-то достаточно редкая функция.
Например, пользователь раз в месяц пользуется импортом из какого-то файла и там вызывается эта функция.
В итоге либо оптимизированный метод потратит 100 МБ памяти и 30 секунд процессорного времени, либо с копией — 200 МБ и 50 секунд.
В этом случае я напишу на копии, т.к. тут меньше шансов ошибиться самому и другим.
Сегодня я массив не редактирую и всё хорошо. Завтра в другом месте этот массив кто-то использует и опять всё хорошо.
Послезавтра ещё кто-то начнёт его редактировать и всё начнёт падать с непонятными ошибками.
Если же это часто вызываемая функция и в результате либо у пользователя периодические фризы, либо всё гладко будет работать, то там можно и неделю на оптимизацию потратить.

Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Хорошая архитектура тем и отличается от плохой, что добавление фич ее не портит.

Только в обозримом будущем, универсальных архитектур навсегда не существует.
Как для приложений, так и для фреймворков.

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

PD>https://rsdn.org/poll/9966

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

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

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

C>Надо обработать большой массив по не совсем тривиальному алгоритму. Можно создать его копию, можно и не создавать. На написание кода с копией уйдет час Вашего времени, без копии — 4 часа. Что предпочтете ?
C>[/q]
C>Насколько большой? Что за алгоритм (модифицирует массив или нет)?

Я специально не стал конкретизировать. Вопрос такой — сделаете копию, если без копии сделаете за 4 часа, а с ней — за час ? Не важно, что там, время на разработку указано.

C>Массив большой это что — по памяти или по числу элементов?

А что, это не связано одно с другим как elems.size*sizeof(elem) ?

C>Имхо, тут сразу же всё упрется в структуры данных (векторы, деки, списки односвязные или двухсвязные) ну и.т.д.

Не важно. Вы можете за 1 час/ 4 часа сделать с ними или без них, быстрее не сможете.

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

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

PD>>Голосование по эффективности и расходам ресурсов

K>Зависит от кучи факторов.
K>Одно дело если это какая-то достаточно редкая функция.
K>Например, пользователь раз в месяц пользуется импортом из какого-то файла и там вызывается эта функция.
K>В итоге либо оптимизированный метод потратит 100 МБ памяти и 30 секунд процессорного времени, либо с копией — 200 МБ и 50 секунд.
K>В этом случае я напишу на копии, т.к. тут меньше шансов ошибиться самому и другим.
K>Сегодня я массив не редактирую и всё хорошо. Завтра в другом месте этот массив кто-то использует и опять всё хорошо.
K>Послезавтра ещё кто-то начнёт его редактировать и всё начнёт падать с непонятными ошибками.
K>Если же это часто вызываемая функция и в результате либо у пользователя периодические фризы, либо всё гладко будет работать, то там можно и неделю на оптимизацию потратить.

Нет шансов ошибиться (ну почти

, после функции этот массив никому не нужен. Чистый код. На входе массив, на выходе результат. Массив забываем, результат используем.

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

PD>А картинки — ну да. Только вот в мессенджере хватит и тумбиналов, а сами картинки спокойно могут подгружаться, когда надо. Ты даже на 50 картинок одновременно смотреть не сможешь.

Если источник картинки отдельный механизм превьюшек не предоставляет, то придётся таки загрузить картинку, сформировать в памяти ужатый вариант для отображения пользователю, а полноразмерное выкинуть из памяти. Но программа всё равно вряд ли сразу память назад отдаст, подержит на всякий случай ещё какое-то время.
Ну, и кроме картинки, нужно загрузить библиотеку, которая умеет работать с набором в 100500 популярных графических форматов. Некоторые ещё и анимированные и там дополнительный механизм нужен.
Да и сама возможность прикладывать картинки усложняет формат передачи данных и увеличивает потребление памяти.
Можно один и тот же текст сохранить в txt и rtf и удивляться, что rtf больше занимает, хотя никакое форматирование не используется.

PD>Там ведь не только картинки, там и видео может быть на десятки Мб, если не больше. Их тоже нужно все в ОП хранить ?

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

PD>Не понял. Он тебе не нравится ?

Нравится. И нравится, что оно "само" работает, не нужно особо вручную ничего делать.

PD>Да уж. Чтобы добавить картинки небольшого размера, надо потребление памяти увеличить на 2 порядка.

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

PD>А вот это верно. Жертва качества за счет удовлетворения требований по скорости разработки, требованиям заказчика и т.д. Эффективность — в последнюю очередь, когда уж припрет.

Ну, это всегда так было. То под железо ужимались, упрощали и оптимизировали. Сейчас несколько другие критерии, но качество всегда страдало.

PD>Это то выяснить несложно, посмотреть структуру EXE. Но не в этом дело. Если там 90% ресурсов, то ничего страшного нет. Понятно, что картинки надо где-то хранить, объем памяти при этом фиксирован. Вот только почему в ОП ?

Если на каждый чих бежать на диск, выкачивать очередную небольшую *.ico, потом выбрасывать её из памяти, то пользы от этого никакой не будет.
Для меня самого непривычно качать мессенджер на 300 МБ, ведь когда-то жесткий диск компа был на 200 МБ.
Но объективно на фоне современных объёмов ОЗУ это достаточно мало.
Когда-то на плюсовиков смотрели как на транжир, которые на свои бесполезные классы кучу памяти тратят.
Сейчас плюсовики уже выделываются тем какой у них язык нативный и ничего лишнего.

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

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

А не зря я дал 1 и 4 часа.

Вот если бы сказал — 1 день и 4 дня, тогда да, задержит работу, может быть. И то если график напряженный, а проект небольшой. Если проект на полгода — ничего не задержит. Будут тебе 23 февраля/8марта/1мая и что, вся работа полетит ?

А 4 часа работу не задержат, если конечно, не дедлайн через день. Работа в самом начале, и пара дней даже мало что изменят. Пара митингов, на которых утрясают задачу, еще пара чаепитий...

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

Вот поэтому мы и имеем то, что имеем.

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

K>Если источник картинки отдельный механизм превьюшек не предоставляет, то придётся таки загрузить картинку, сформировать в памяти ужатый вариант для отображения пользователю, а полноразмерное выкинуть из памяти. Но программа всё равно вряд ли сразу память назад отдаст, подержит на всякий случай ещё какое-то время.

Придется. А вот отдаст или нет — это от программиста зависит. Если delete в С++ сделать — VM Size точно уменьшит. Из working set может, и не сразу удалит, но раньше или позже тоже.

K>Ну, и кроме картинки, нужно загрузить библиотеку, которая умеет работать с набором в 100500 популярных графических форматов. Некоторые ещё и анимированные и там дополнительный механизм нужен.

Ох, что-то плохо верится в 100500. Их с десяток популярных, не больше. А прочие могут сидеть на диске и ждать, когда понадобится какой-то pcx распарсить.

Кстати, код занимает на удивление мало места. Попробуй dumpbin на любую DLL и увидишь сам. Основное — .data и .resource

K>Да и сама возможность прикладывать картинки усложняет формат передачи данных и увеличивает потребление памяти.

Что тут за такое усложнение ? Принять ее как файл (а она и передается как файл), записать на диск и ждать, пока ее не попросят показать

K>Можно один и тот же текст сохранить в txt и rtf и удивляться, что rtf больше занимает, хотя никакое форматирование не используется.

PD>>Там ведь не только картинки, там и видео может быть на десятки Мб, если не больше. Их тоже нужно все в ОП хранить ?

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

Верно. Потому что не поместится, это понимают. А картинки поместятся. Вот и не экономят. А памяти нужно все больше и больше...

PD>>Да уж. Чтобы добавить картинки небольшого размера, надо потребление памяти увеличить на 2 порядка.

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

И сколько же нужно памяти на растеризацию этих текстов ? Точно мегабайты ? При этом, что это все же не Word, а только Telegram, тут шрифт, в общем-то, один.

K>Ну, это всегда так было. То под железо ужимались, упрощали и оптимизировали. Сейчас несколько другие критерии, но качество всегда страдало.

+1

PD>>Это то выяснить несложно, посмотреть структуру EXE. Но не в этом дело. Если там 90% ресурсов, то ничего страшного нет. Понятно, что картинки надо где-то хранить, объем памяти при этом фиксирован. Вот только почему в ОП ?

K>Если на каждый чих бежать на диск, выкачивать очередную небольшую *.ico, потом выбрасывать её из памяти, то пользы от этого никакой не будет.

Почему ? При нынешних скоростях SSD время на подгрузку невелико.

K>Для меня самого непривычно качать мессенджер на 300 МБ, ведь когда-то жесткий диск компа был на 200 МБ.
K>Но объективно на фоне современных объёмов ОЗУ это достаточно мало.

Именно. Бери сколько можешь. Было бы сейчас не больше 1 Гб ОЗУ — хватило бы и его.

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

А это они всегда говорили. Я в том числе

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

PD>А 4 часа работу не задержат

Я бозначил общий подход, то, что разработчик с опытом в большом проекте (и не вчерашний студент) скорее всего выберет.
Чем больше и сложнее проект, тем больше в нём людей, и тем меньше свободы у того, кто занимается непосредственно реализацией.
В достаточно большой команде есть специальные люди, которые ничем другим не занимаются, кроме как вопросами анализа производительности.
Иногда для этого даже нанимаются сторонние фирмы.
К тому же, один программист может одновременно работать в нескольких проектах, и тогда 3 часа имеют значение, потому что если проекта 3, то 3 часа превращаются в 9, а это уже больше одного рабочего дня.

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

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

C>>Надо обработать большой массив по не совсем тривиальному алгоритму. Можно создать его копию, можно и не создавать. На написание кода с копией уйдет час Вашего времени, без копии — 4 часа. Что предпочтете ?
C>>[/q]
C>>Насколько большой? Что за алгоритм (модифицирует массив или нет)?

PD>Я специально не стал конкретизировать. Вопрос такой — сделаете копию, если без копии сделаете за 4 часа, а с ней — за час ? Не важно, что там, время на разработку указано.
Ну я поэтому и написал, что сделал бы через фасадную функцию обработки массива. А та уж будет как-то выбирать функцию реализации.
А эти самые несколько разных функций разных реализаций будут работать по-разному. В зависимости от требований и главное их сочетаний: надежность, скорость, требования к памяти, как часто используется. Как верно написал _student, как часто оный функционал вовсе нужен пользователю (импорт\экспорт раз в месяц, или по 3 раза за минуту).
Мысль была в том, чтобы скрыть за фасадом выбор конкретных реализаций. Оставить себе свободу выбора на будущее, и в то же время полностью контролировать выбор в конкретный момент.

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

C>>Массив большой это что — по памяти или по числу элементов?

PD>А что, это не связано одно с другим как elems.size*sizeof(elem) ?
В математике связано. У пользователя нет. У пользователя нет математики: у него более приземленные понятия (быстро, надежно, тормозит\не тормозит, вызывает в UI какие-нить фризы и.т.д). И вот тут вот и всплывает то самое магическое sizeof(elem). Если там sizeof(long), то вроть и пофиг (для конечного пользователя системы), а если там sizeof(нихрена_себе_PFF-ка_с_жесткого диска), то очень даже и есть разница.
Дьявол — он в деталях. Универсального подхода здесь нет.

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

__>Я бозначил общий подход, то, что разработчик с опытом в большом проекте (и не вчерашний студент) скорее всего выберет.
__>Чем больше и сложнее проект, тем больше в нём людей, и тем меньше свободы у того, кто занимается непосредственно реализацией.

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

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

PD>Нет шансов ошибиться (ну почти

, после функции этот массив никому не нужен.
Вооот, начинаются дополнительные ограничения.
"я забыл сказать — жителями этого дома будет семья глухонемых жирафов".
Наверняка ещё есть какое-нибудь невинное ограничение вида "предположим, что это именно C-style массив, то есть набор значений, плотно уложенных в непрерывной области памяти".
И всякие там произвольные уточнения вида "нет, мы не знаем, какую именно долю этого массива затрагивают изменения нашей функцией", "у нас есть гарантия того, что в параллельном потоке никто с этим массивом не работает ни на чтение, ни на запись", и т.п.

Насколько надёжно ваше доказательство того, что "после функции этот массив никому не нужен"?
Насколько надёжно предположение о том, что это не изменится в будущем?
Сможете ли вы написать код так, чтобы
а) использовалась in-place модификация
б) в случае, если окружающий код будет модифицирован так, что ссылка на оригинальный массив станет использоваться после вызова этой функции, то это вызовет compile-time error или иным способом защитит будущего программиста от выстрела себе в ногу?
в) даже если сможете — станете ли вы писать код именно таким способом, или самонадеянно нахреначите in-place версию, надеясь на авось?

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

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

PD>Вот поэтому мы и имеем то, что имеем.

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

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

_>нет, не поэтому. В разработке ПО участвует не только программист. Он тут появляется уже на третьих ролях, как ни странно звучит. Сначала идут требования бизнеса — надо сделать вот это, мы это готовы продать за много денег, есть заказчики и сроки.

Эти требования святой дух определил ? Сроки и прочее. Нет, они на основе предыдущих разработок сделаны.

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

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

>Сроки — вот такие с учетом разработки и тестирования. И только теперь задача попадает к программисту, которому надо написать конкретный кусок кода в четкие сроки. Не уложишься — и твой супер красивый и быстрый код станет НИКОМУ НЕ НУЖЕН, потому что его некому продать, нишу заняли конкуренты, которые успели. А вот когда успели и продали, но например на машинах заказчика работает медленно,

А заказчику святой дух объяснил, что тут медленно, и что нет ? Нет опять же, он на основе тех программ , что видел, делает свои предположения, сколько времени на что надо ?

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

Ни требования, ни менеджеры с аналитиками, ни заказчики не могут ответить на вопрос — сколько каких ресурсов надо потратить на ту или иную операцию. Аналитики еще что-то могу, потому что они зачастую бывшие программисты, а остальные только могут исходить из аналогичного. А аналогичное писалось так же, как и предыдущее аналогичное, вот только ресурсов стало побольше и тратить их можно свободнее.

Только программист может сказать, что и как тут можно сделать, если сделать качественно, памятью не сорить, лишнее не делать и т.д. И сколько — если сделать по принципу "это должно было быть готово вчера"

А в итоге мы и имеем то, что имеем. Решения принимаются исходя не из соображений качества собственно продукта, а из всяких прочих.

Мы сами их приучили так делать.

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

S>А что телефоны? В 2014 достаточно было 2 Гб ОЗУ и 32 Гб диска — сейчас нужно минимум 6 Гб ОЗУ и 128 Гб диска. Ну в 4 раза примерно, уже не так стремительно. Некоторые считают, что сейчас можно брать телефон на 10 лет, что в 2034 особо ничего не изменится, т.к. все уже есть и особо развивать некуда.

Сейчас всё в батарейку упирается — да, можно было бы запихнуть убер-процессор, растащить экран ещё лопатнее, но смысл, если оно будет помирать через пару часов. Т.е. можно превратить смартфон "в троллейбус, но зачем?" (ц)

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

_>>нет, не поэтому. В разработке ПО участвует не только программист. Он тут появляется уже на третьих ролях, как ни странно звучит. Сначала идут требования бизнеса — надо сделать вот это, мы это готовы продать за много денег, есть заказчики и сроки.

PD>Эти требования святой дух определил ? Сроки и прочее. Нет, они на основе предыдущих разработок сделаны.

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

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

S>Вопрос такой.

Сегодня быстрее всего развиваются всякого рода свистоперделки для всех типов гаджетов.

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

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

И ты попробуй понять, что эти требования и сроки сложились на основе программистской практики и технических возможностей. Без этого никакой заказчик не мог бы их сформулировать.
А практика, увы, такая, о которой я писал.

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

PD>И ты попробуй понять, что эти требования и сроки сложились на основе программистской практики и технических возможностей. Без этого никакой заказчик не мог бы их сформулировать.
PD>А практика, увы, такая, о которой я писал.

Снова телега впереди лошади. Еще раз — есть конкретная задача, за решение которой к определенному времени заказчик готов заплатить. Если ее решат позже, то платить уже не готов или заплатит сильно меньше. Все остальное вторично и пляшет уже внутри этих начальных условий.

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

PD>>И ты попробуй понять, что эти требования и сроки сложились на основе программистской практики и технических возможностей. Без этого никакой заказчик не мог бы их сформулировать.
PD>>А практика, увы, такая, о которой я писал.

_>Снова телега впереди лошади. Еще раз — есть конкретная задача, за решение которой к определенному времени заказчик готов заплатить. Если ее решат позже, то платить уже не готов или заплатит сильно меньше. Все остальное вторично и пляшет уже внутри этих начальных условий.

Ладно, давай иначе. Из каких соображений он исходит, устанавливая эти требования и сроки ?

Вот допустим

Требования по фичам — вполне разумные, ничего невозможного
Требования по быстродействию — некая операция за N единиц времени
Требования по памяти — не более M единиц памяти
Требования по срокам — не более L месяцев.

На основании какой информации заказчик эти требования выдвинул ?

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

Как он определил N, M и L ?

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

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

Заказчик так глубоко не копает. Ну например, нужна защита информации от утечек. У нас парк из 100 машин от win7 до win11, 4 сервера HP. Защита нужна максимум через месяц и сертифицированная, иначе мы в тендер не попадем. Заплатим условный чемодан денег. Сможете?

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

_>Заказчик так глубоко не копает. Ну например, нужна защита информации от утечек. У нас парк из 100 машин от win7 до win11, 4 сервера HP. Защита нужна максимум через месяц и сертифицированная, иначе мы в тендер не попадем. Заплатим условный чемодан денег. Сможете?

Нет, не переводи вопрос на безопасность, да еще в каком-то кластере машин, это другая тема.

Просто разработка некоей программы (или серверной части). Требования к ней он дает.
Набор фич он точно должен сформулировать, кто же еще может ?.
И требования по быстродействию тоже.
Насчет памяти — тут он действительно может и не разбираться, ладно.

На основании каких соображений он эти требования может выдвинуть ?

Набор фич — ладно, должен же он знать, что ему надо.
А вот с быстродействием как ? На основании чего он может сказать, что вот такое его устроит, а такое нет ?

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

PD>Просто разучились писать приложения компактно.

Так это нормально. Прогресс в железе, а довеском к нему — массовость профессии, которая ведет к снижению среднего уровня.

В древности я мог экономить 100 байт кода или данных, часто в ущерб быстродействию и своему времени. Есть факторы:
— технические ограничения. Они другие;
— критерий эффективности разработки — число фич в час;
— тот же выбор между экономией памяти и быстродействием никуда не делся.
Рождаются новые требования. Та же безопасность, например, — это приличные накладные расходы, в т.ч., насколько я понимаю, дублирование части кода и данных в памяти.

В общем, оно эволюционно пухнет на всех слоях — от ядра через api и либы с фреймворами до приложения. Еще случаются революции вроде запихивания броузера в нативные приложения. Броузер же с его песочницами и прочим — прожорливая скотинка.

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

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

PD>На основании какой информации заказчик эти требования выдвинул ?
На основании объективной.
Вот берём что-нибудь простое — например, распознавалка номеров автомобилей на шлагбауме, который стоит на въезде на офисную парковку.
Любой аналитик тебе безо всякого программистского опыта скажет, что больше 10 секунд — нельзя, т.к. водитель решит, что система неисправна, и уедет.
И что меньше 0.5 секунды — нерелевантно, т.к. время проезда будет определяться временем реакции водителя, а не автомата.
Поэтому будет сказано "500 миллисекунд", а дальше — твоя работа, как разработчика, спроектировать так, чтобы всё работало.
В том числе и сформулировать требования к железке. И тут может возникнуть некое пространство вариантов.
Например, в одном варианте ты предлагаешь потратить лишние полтора месяца (то есть примерно 500к рублей, плюс налоги, плюс сборы, плюс накладные, умножить на риск) на оптимизацию, и упихаться в один сервер за 200к рублей.
Во втором — забить на оптимизацию, и просто поднять два сервера по 200к рублей.
И вот бизнес вполне способен выбрать между этими вариантами, если ты сам не сможешь.

PD>Обязательное условие — заказчик сам не программист , не архитектор и т.д, а лишь пользователь.
PD>Как он определил N, M и L ?
Из требований предметной области.
Или вот, скажем, надо тебе показывать пользователю фильм. Бизнес тебе говорит: надо показывать 30 FPS 4K, при этом терять можно не более 1 кадра в 10 секунд.
Почему? Потому, что вот такой видеоконтент, и вот таковы данные тестирования целевой аудитории — если теряем чаще, то пользователи это замечают и уходят. Ты идёшь и делаешь. Никому не надо воспроизводить видео со скоростью 900 FPS, особенно за дополнительные затраты.

Не бывает такого бизнеса, который бы говорил "сделай мне распознавание номеров машин как можно быстрее", а ты такой ему с высоты своего опыта поясняешь "я умею это делать за 1 миллисекунду, а если кто-то предлагает за 20 — гоните его в шею, он ламер".
Иногда бывает так, что бизнес приходит к тебе и говорит: "я тут посмотрел — на рынке есть планшеты, которые на одной зарядке могут играть 60FPS 4K видео четыре часа. Я считаю, что есть ниша долгоживущих плееров, которые смогут делать то же самое 12 часов — на рейсах между Европой и Южной Америкой. Возможности увеличивать вес батареи уже исчерпаны. Я говорил с учёными — увеличить ёмкость батареи при том же весе пока способов нет; разработка потребует 5 миллиардов долларов и неизвестное количество лет. Говорил с чипмейкерами — сократить энергопотребление втрое при сохранении производительности можно, но разработка потребует 5 миллиардов долларов и несколько лет.
Вот теперь тебя спрашиваю — можешь переписать код, чтобы плеер на том же чипе и с той же батареей работал 12 часов вместо 4х?"
И ты ему отвечаешь — можно или нельзя. И сколько стоит.
Типа — могу удвоить производительность, потребуется полгода работы. Утроить — не знаю, надо пробовать. Пробовать буду год, если не получится — увы, деньги будут потрачены зря.
И бизнес решает — дать тебе такую открытую задачу, или ну его нафик. Может быть и даст — "даже если получится 8 часов, то уже неплохо — будем позиционировать для рейсов Европа-Северная Америка".

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

PD>Набор фич — ладно, должен же он знать, что ему надо.
PD>А вот с быстродействием как ? На основании чего он может сказать, что вот такое его устроит, а такое нет ?
Да очень просто. Любой бизнес занимается планированием и анализом рынка.
Мы же не просто "делаем серверную часть". У нас известно:
а) сколько будет пользователей. Через 3, 6, 12 месяцев.
б) сколько и каких функций они будут выполнять
в) какие у пользователей ожидания по времени ответа на запрос.

Вот мы и получаем что-нибудь типа "20к запросов в сутки в среднем, в пике вырастает впятеро" + "95% запросов должны исполняться за 500мс".

Тут нет никакой rocket science, и техническая подготовка бизнесмена почти никакой роли не играет.

Понятно, что правила игры в основном задаются рынком. Я помню, как в начале 2000х мне в местном банке объясняли, что внутрибанковский перевод из московского офиса в новосибирский идёт до 3х дней, и это нормально.
Понятно — перевод на сберкнижку из другого города мог и месяц идти, поэтому три дня им казалось разумным сроком. А я им объяснял, что даже наличку можно привезти за 8 часов, а безнал должен идти со скоростью прохождения сигнала в кабеле.

Ну, так на то и бизнес — постепенно появились бодрые ребята, которые сломали эти стереотипы. Не программисты, а бизнесмены. Ведь три дня перевод "шёл" потому, что был такой процесс, в котором раз в сутки кто-то нажимал на кнопку "провести межфилиальные взаиморасчёты". А три дня — потому что перевод, отправленный в 13:00 пятницы будет обработан в 12:00 понедельника. А вовсе не потому, что сервера Собинбанка были написаны неквалифицированными программистами на медленных языках программирования.

Появляется у бизнесмена идея — и он начинает её исследовать, копать в нужную сторону.

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

S>Вот мы и получаем что-нибудь типа "20к запросов в сутки в среднем, в пике вырастает впятеро" + "95% запросов должны исполняться за 500мс".

Во времена Windows NT 4 Server на 80486 процессоре c памятью 16 Мбайт можно было бы такое обеспечить ?

Если да — значит, 16 Мбайт хватит.

Если нет — начиная с которого можно было бы ?

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

S>Вопрос такой.

На персональных девайсах наиболее быстро развивается перифирия и характеристики ОЗУ.
Причём, это относительно замедлившегося развития быстродействия в пересчёте на ядро центрального процессора, а на самом деле перифирия всегда развивалась и продолжает развиваться медленно.

Еще неплохо развивилось ПО — сейчас на персональных девайсах возможности ПО, можно сказать, целиком используют возможности железа.

В деле развития инфраструктуры и степени интеграции различного ПО (в т.ч. через инфраструктурно-образующее ПО) — по-прежнему наблюдается серьезное отставание от располагаемых современных технологий в вопросе в продуманности самой инфраструктуры и обслуживающего ПО. Но именно здесь идёт самое быстрое развитие из всего перечисленного (в последние лет 10 точно), спасибо мобильным девайсам и мобильной связи.

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

C>Новомодные "хипстеры" из подходов к разработке по моему знают только "хлоп, шлёп, хренакс и в продакшн".

Но эти действия выполняются на всё более мощных программных платформах.
Я тут не об эффективности этих платформ в пересчёте на тик процессора, а о предоставляемых "кирпичиках".

В идеале, решения типовых задач примерно так и должны выглядеть — как сборка из кубиков Лего, как оно происходит уже лет 40 в электронике (аналоговой и цифровой).
В ПО в этом смысле до сих пор происходит первобытный хаос, "поиск себя", утруска, усушка и т.д. ))

C>Какое уж тут профилирование, требования к ресурсам, да и заканчивая обычной UX, Use-case аналитикой, code-review, да usability в придачу.

Эти вещи должны всё чаще быть решаемы на платформенном уровне.
В т.ч. платформы должны предоставлять удобные ср-ва диагностики полученных с их помощью решений.

Взять тот же Питон — тормоз хуже некуда...
Но всё больше "кирпичиков" являются обертками над низкоуровневыми нейтивными библиотеками, что в ИИ Питон теперь рулит, выступая популярным клеем для готовых ИИ-алгоритмов.

Причём, Питон рулит в обучении и прототипировании, а в боевых приложениях Питон уже оказывается часто не нужен, ценностью является конфигурация сети, методы обучения/диагностики и, собсно, сами обученные сетки.

Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Здравствуйте, Sinclair, Вы писали:
S>>Вот мы и получаем что-нибудь типа "20к запросов в сутки в среднем, в пике вырастает впятеро" + "95% запросов должны исполняться за 500мс".
PD>Во времена Windows NT 4 Server на 80486 процессоре c памятью 16 Мбайт можно было бы такое обеспечить ?
Не могу сказать — не моя область специализации.
Вполне может быть, что можно было бы, только потребовалась бы серверная ферма и аккуратное распараллеливание задачи.
PD>Если нет — начиная с которого можно было бы ?
Это как раз вопрос к специалистам. Ещё раз: бизнес ставит задачу. Инженер её решает — в том числе и выбирая технические средства.

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

S>Вполне может быть, что можно было бы, только потребовалась бы серверная ферма и аккуратное распараллеливание задачи.
PD>>Если нет — начиная с которого можно было бы ?
S>Это как раз вопрос к специалистам. Ещё раз: бизнес ставит задачу. Инженер её решает — в том числе и выбирая технические средства.

Я не случайно этот вопрос задал.

Ясно, что в MS-DOS она либо не могла быть вообще решена, либо пришлось бы писать какую-то собственную настройку распараллеливания.

А в какой-то момент она смогла быть решенной. Не в NT4 Server, так в 2008 Server или раньше, это и впрямь неважно.

И только тогда бизнес смог бы поставить эту задачу.

Так что вчера было еще нельзя, а сегодня стало можно.

Вопрос — как бизнес узнал, что уже можно и, главное, как определил цену ?

Задача тут могла быть любая. Например, серьезную обработку картинки вряд ли можно было делать в CP/M на 64 Кбайтах, а в MS-DOS уже можно.

Или другой пример, не из программирования. Деревянные и каменные мосты умели делать в глубокой древности, и не бизнес. А вот металлические мосты появились в конце 18 века. Как бизнес определил стоимость постройки. Инженеров спрашивать нельзя о стоимости. по твоим правилам — они должны потом выбрать технические средства.

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

S>А вот разница между компом 2014 и 2024 — уже почти нет ее. Ну может в 2 раза только — раньше ставили от 4 Гб ОЗУ, теперь от 8 Гб на минималке. Т.е. уже даже не в 5 раз. Ну разве что SSD подешевели.
...
S>А что сильно отличается?

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

PD>Я не случайно этот вопрос задал.
PD>Ясно, что в MS-DOS она либо не могла быть вообще решена, либо пришлось бы писать какую-то собственную настройку распараллеливания.
Эмм, распараллеливание в MS-DOS — это какой-то оксюморон. Эта ОС принципиально не умеет работать на многоядерном ЦПУ; а на одном ядре параллелить CPU-bound задачи — бессмыслица.
Верх параллельности под MS-DOS — это какой-нибудь fastback, который параллелил IO с компрессией.
PD>А в какой-то момент она смогла быть решенной. Не в NT4 Server, так в 2008 Server или раньше, это и впрямь неважно.
Брр. Какие-то непонятные прыжки от MS DOS к NT4, и потом — к 2008 Server.
С точки зрения задачи "распознавание цифирь на фото" NT4 от 2008 Server или там 10 Server ничем не отличаются.
Скорее можно говорить о том, какое железо для этого потребно, и от него уже плясать в выборе операционки.
PD>И только тогда бизнес смог бы поставить эту задачу.
Когда "тогда"? Задача была в некотором смысле всегда. Просто её решение было до какого-то момента недоступно

PD>Вопрос — как бизнес узнал, что уже можно и, главное, как определил цену ?
Очень просто он определил цену. Вот смотри: у нас есть, скажем, работающая (с 1990го года) система допуска народа на парковку. Система называется "сторож с кнопкой и списком номеров".
У этой системы есть эксплуатационная себестоимость — зарплаты четырёх сторожей, плюс налоги, плюс сборы, плюс отопление будки в зимний период. X рублей в год.
Бизнес говорит "а давайте тётеньку вытащим, автомат засунем". Сколько будет стоить эксплуатация распознавалки, которая будет эмулировать нажатие на кнопку? Допустим, некоторый Y рублей в год. Пока, ессессно, неизвестный — мы ж ещё даже не знаем, что там будет за железка, сколько их, и т.п. Когда инженер станет предлагать железку, мы сможем посчитать стоимость для неё электроэнергии, кондиционирования, обслуживания специалистом, и амортизацию. Но пока пишем в блокнотик просто Y.
Теперь — для запуска этой системы нам нужно потратить Z, который складывается из
— стоимости железок (камер, проводов, столбов, серверов) Z0
— стоимости разработки программы Z1
— стоимости инженерных работ по прокладке проводов, привинчивания камер, вкапывания столбов Z2.

Из общих соображений бизнес хочет, чтобы это новшество окупилось за время T.
Отсюда сразу имеем неравенство: 0 < Z/(X-Y) <= (T-T0), где T0 — это срок реализации проекта. Из которого следует, что Z <= (T-T0) * (X-Y).
В частности, Z0+Z1 <= (T-T0) * (X-Y) — Z2.
Даём задачу инженерам — они предлагают варианты. Если ни один из вариантов по Z0, Z1, T0, и Y не укладывается в неравенство — значит, проект не имеет экономического смысла, и мы его закрываем. Довольные тем, как быстро мы убедились в его нереализуемости.
Если есть разные варианты — смотрим, какой из них окупается быстрее, и выбираем его.
Это — уровень детского сада; реальные бизнес-уравнения несколько сложнее (иначе бы все программисты были бы уже мега-магнатами). В частности, нужно учитывать внутренние и внешние риски. Но пока достаточно и такого приближения.

PD>Задача тут могла быть любая. Например, серьезную обработку картинки вряд ли можно было делать в CP/M на 64 Кбайтах, а в MS-DOS уже можно.
Смотря какой картинки, и какую обработку. Распознавалки цифр на конвертах внедрили, емнип, в 1960х. Специализированную распознавалку регистрационных номеров, рассчитанную на невраждебных пользователей, можно построить с минимумом памяти и вычислительной мощности. Применяемые сейчас были разработаны для ГИБДД, где нужно работать с враждебно настроенным "пользователем" и минимизировать ошибки.

PD>Или другой пример, не из программирования. Деревянные и каменные мосты умели делать в глубокой древности, и не бизнес. А вот металлические мосты появились в конце 18 века. Как бизнес определил стоимость постройки.
Точно так же. Это же азы проектного планирования.
PD>Инженеров спрашивать нельзя о стоимости. по твоим правилам — они должны потом выбрать технические средства
Инженеров можно и нужно спрашивать о стоимости. Делаем именно так — спрашиваем "сколько будет стоить металлический мост". И пока такой мост обходился дороже каменного, никому и в голову не приходило строить металлические мосты. Или даже так — говорим "нужен мост, который бы соединял берега в таком-то месте, на шесть полос в каждую сторону". И инженеры соревнуются, предлагая свои проекты. Кто-то — каменные, кто-то — металлические, кто-то — железобетонные. У всех у них разные Y, Z, и T0. Бизнес смотрит на них и выбирает устраивающий его вариант.

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

Все опущу, так как главное вот здесь

>Теперь — для запуска этой системы нам нужно потратить Z, который складывается из
> стоимости железок (камер, проводов, столбов, серверов) Z0
> стоимости разработки программы Z1
> стоимости инженерных работ по прокладке проводов, привинчивания камер, вкапывания столбов Z2.

PD>>Инженеров спрашивать нельзя о стоимости. по твоим правилам — они должны потом выбрать технические средства

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

Что, если заказчик поставит в проекте требование решить мимоходом задачу NP-полную ? Приближенные решения не годятся, допустим. Но только инженер сможет сказать, при каких условиях ее все же можно решать полным перебором, а при каких задача неразрешима при текущем уровне железа. Да даже и не NP-полная — пусть там совсем не бог весть что по требованиям, но для Z1 надо потратить столько, что денег у заказчика не хватит.

S>Инженеров можно и нужно спрашивать о стоимости. Делаем именно так — спрашиваем "сколько будет стоить металлический мост". И пока такой мост обходился дороже каменного, никому и в голову не приходило строить металлические мосты. Или даже так — говорим "нужен мост, который бы соединял берега в таком-то месте, на шесть полос в каждую сторону". И инженеры соревнуются, предлагая свои проекты. Кто-то — каменные, кто-то — металлические, кто-то — железобетонные. У всех у них разные Y, Z, и T0. Бизнес смотрит на них и выбирает устраивающий его вариант.

Вопрос был слегка провокационный.

Для финансирования строительства были выпущены акции, но их не хватило, и Дарби согласился частично финансировать недостающее (в целом на 3200 фунтов стерлингов). По предварительным расчётам, для строительства требовались 300 тонн чугуна (стоимостью 7 фунтов за тонну), однако фактически было потрачено 379 тонн. Учитывая дополнительные расходы (монтаж, опоры и т. д.), проект оказался гораздо дороже, чем изначально предполагалось, и Дарби понёс большие убытки, оставшись в долгах до конца жизни.

https://ru.wikipedia.org/wiki/%D0%A7%D1%83%D0%B3%D1%83%D0%BD%D0%BD%D1%8B%D0%B9_%D0%BC%D0%BE%D1%81%D1%82_%D1%87%D0%B5%D1%80%D0%B5%D0%B7_%D0%A1%D0%B5%D0%B2%D0%B5%D1%80%D0%BD#:~:text=%C2%AB%D0%A7%D1%83%D0%B3%D1%83%D0%BD%D0%BD%D1%8B%D0%B9%20%D0%BC%D0%BE%D1%81%D1%82%C2%BB%20(%D0%B0%D0%BD%D0%B3%D0%BB.,%D0%AE%D0%9D%D0%95%D0%A1%D0%9A%D0%9E%20%D0%BA%D0%B0%D0%BA%20%D0%BF%D0%B0%D0%BC%D1%8F%D1%82%D0%BD%D0%B8%D0%BA%20%D0%92%D1%81%D0%B5%D0%BC%D0%B8%D1%80%D0%BD%D0%BE%D0%B3%D0%BE%20%D0%BD%D0%B0%D1%81%D0%BB%D0%B5%D0%B4%D0%B8%D1%8F.

Может, конечно, инженеры были плохие, но выделенное мной говорит о том, что их сначала спрашивали, а потом уж оценивали. И, как видишь, не совсем точно.

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

S>А что сильно отличается?

в телефонах 14 и современных — камера отличается. в современном обыватель уже не отличает снимки от зеркалки, а камеры 14 года — это мыльное шумное говно.

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

PD>О стоимости их спрашивать придется, а именно про твои Zi, так как только они могут сказать, во что примерно это может обойтись.
Налицо какая-то путаница. Про "нельзя спрашивать о стоимости" я не писал — это ваша фантазия.
Я писал "Инженеров можно и нужно спрашивать о стоимости".

PD>Они , и только они знают, какова cтоимость всех этих Zi. Без этого ты вообще не можешь сказать, реализуем ли проект.
Я вроде бы написал прямо пошаговую инструкцию проверки реализуемости проекта. Что именно непонятно? Как это так получилось, что бизнес заранее знает верхний предел на Z?

S>>Инженеров можно и нужно спрашивать о стоимости. Делаем именно так — спрашиваем "сколько будет стоить металлический мост". И пока такой мост обходился дороже каменного, никому и в голову не приходило строить металлические мосты. Или даже так — говорим "нужен мост, который бы соединял берега в таком-то месте, на шесть полос в каждую сторону". И инженеры соревнуются, предлагая свои проекты. Кто-то — каменные, кто-то — металлические, кто-то — железобетонные. У всех у них разные Y, Z, и T0. Бизнес смотрит на них и выбирает устраивающий его вариант.
PD>Вопрос был слегка провокационный.

Да не вижу тут никакой провокационности. Вижу какое-то непонимание базовых принципов бизнес-планирования

PD>

PD>Для финансирования строительства были выпущены акции, но их не хватило, и Дарби согласился частично финансировать недостающее (в целом на 3200 фунтов стерлингов). По предварительным расчётам, для строительства требовались 300 тонн чугуна (стоимостью 7 фунтов за тонну), однако фактически было потрачено 379 тонн. Учитывая дополнительные расходы (монтаж, опоры и т. д.), проект оказался гораздо дороже, чем изначально предполагалось, и Дарби понёс большие убытки, оставшись в долгах до конца жизни.

PD>https://ru.wikipedia.org/wiki/%D0%A7%D1%83%D0%B3%D1%83%D0%BD%D0%BD%D1%8B%D0%B9_%D0%BC%D0%BE%D1%81%D1%82_%D1%87%D0%B5%D1%80%D0%B5%D0%B7_%D0%A1%D0%B5%D0%B2%D0%B5%D1%80%D0%BD#:~:text=%C2%AB%D0%A7%D1%83%D0%B3%D1%83%D0%BD%D0%BD%D1%8B%D0%B9%20%D0%BC%D0%BE%D1%81%D1%82%C2%BB%20(%D0%B0%D0%BD%D0%B3%D0%BB.,%D0%AE%D0%9D%D0%95%D0%A1%D0%9A%D0%9E%20%D0%BA%D0%B0%D0%BA%20%D0%BF%D0%B0%D0%BC%D1%8F%D1%82%D0%BD%D0%B8%D0%BA%20%D0%92%D1%81%D0%B5%D0%BC%D0%B8%D1%80%0%BD%D0%BE%D0%B3%D0%BE%20%D0%BD%D0%B0%D1%81%D0%BB%D0%B5%D0%B4%D0%B8%D1%8F.

PD>Может, конечно, инженеры были плохие, но выделенное мной говорит о том, что их сначала спрашивали, а потом уж оценивали. И, как видишь, не совсем точно.
Не, это не инженеры плохие, это переводчики. В англоязычных источниках про "оставшись в долгах до конца жизни" нету. Зато

Darby had agreed to construct the bridge with a budget of £3,250 (equivalent to £426,353 in 2023)[iv] and this was raised by subscribers to the project, mostly from Broseley. While the actual cost of the bridge is unknown, contemporary records suggest it was as high as £6,000 (£787,113 in 2023)[iv], and Darby, who was already indebted from other ventures, agreed to cover the excess.[36] However, by the mid-1790s the bridge was highly profitable, and tolls were giving the shareholders an annual dividend of 8 per cent.[37]

То есть перед тем, как принять решение по проекту, было проведено ТЭО, учитывавшее популярность маршрута и ожидаемую таксу за проезд по мосту.
И в итоге бизнес-таки выиграл, несмотря на то, что инженеры лажанулись с оценкой затрат. Просто окупаемость оказалась подлиннее.

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

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

PD>>О стоимости их спрашивать придется, а именно про твои Zi, так как только они могут сказать, во что примерно это может обойтись.
S>Налицо какая-то путаница. Про "нельзя спрашивать о стоимости" я не писал — это ваша фантазия.
S>Я писал "Инженеров можно и нужно спрашивать о стоимости".

Хорошо. Итак, на том, что инженеры должны ответить на вопрос, сколько это будет примерно стоить, мы согласны.
Тогда вопрос, к которому я и вел : каким образом инженеры будут оценивать эту стоимость ?

И зря ты не ответил на мой вопрос. Повторяю его, и надеюсь все же ответ получить

Что, если заказчик поставит в проекте требование решить мимоходом задачу NP-полную ? Приближенные решения не годятся, допустим. Но только инженер сможет сказать, при каких условиях ее все же можно решать полным перебором, а при каких задача неразрешима при текущем уровне железа. Да даже и не NP-полная — пусть там совсем не бог весть что по требованиям, но для Z1 надо потратить столько, что денег у заказчика не хватит.

Впрочем, все может быть даже проще. Ты хочешь распознавалку. Отлично. А откуда бизнес знает, можно ли ее вообще реализовать ? Если, вернемся к прежнему, у нас времена MS-DOS или NT4. Бизнес знает, что компьютеры есть, видеокамеры тоже, вообще-то распознавалки сделать можно. Но тебе надо же в риэлтайме, да еще и сколько-то в минуту. Это технически вообще возможно ? Откуда бизнесу это знать ?
А если можно все же, то каковы требования к ресурсам ? Во времена NT4 было одно, сейчас несколько иное. А от этого Zi зависят.

PD>>Они , и только они знают, какова cтоимость всех этих Zi. Без этого ты вообще не можешь сказать, реализуем ли проект.
S>Я вроде бы написал прямо пошаговую инструкцию проверки реализуемости проекта. Что именно непонятно? Как это так получилось, что бизнес заранее знает верхний предел на Z?

Цитирую

>Но пока пишем в блокнотик просто Y.

Y — прямо зависит от Z, только с учетом времени на окупаемость, так как X — текущие расходы, это константа, уже данная, а T устанавливает заказчик, по твоему механизму.

S>Да не вижу тут никакой провокационности. Вижу какое-то непонимание базовых принципов бизнес-планирования

Да не в принципах бизнес-планирования дело. Бизнес может, конечно, на основе этих принципов определить желаемую цену проекта. А вот насколько это реальная цена с точки зрения разработчиков ?

Кстати, зря ты так уверен, что, скажем, T — это константа планирования.

Бизнес хочет, чтобы это окупилось за T. Обсудили с инженерами, стоимость выходит в 2 раза больше, и за T не окупится. Но, возможно, окупится за 2T. Бизнес обдумывает ситуацию. Возможно, и согласится. Если T=1 год, как бизнес хотел бы, то, может, его и устроит 2 года.

PD>>Может, конечно, инженеры были плохие, но выделенное мной говорит о том, что их сначала спрашивали, а потом уж оценивали. И, как видишь, не совсем точно.
S>Не, это не инженеры плохие, это переводчики. В англоязычных источниках про "оставшись в долгах до конца жизни" нету. Зато

Скорее всего это вообще не перевод, а оригинальная статья. Например, вот такое

"В 1935 году мост закрыт для движения транспорта[4]."

в англоязычной версии отсутствует. Переводчик это никак добавить не мог.

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

Так все же не бизнес, а инженеры провели оценку затрат ?

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

PD>Хорошо. Итак, на том, что инженеры должны ответить на вопрос, сколько это будет примерно стоить, мы согласны.
PD>Тогда вопрос, к которому я и вел : каким образом инженеры будут оценивать эту стоимость ?
Традиционно — суммированием произведений количества на цену. В чём вопрос-то?

PD>И зря ты не ответил на мой вопрос. Повторяю его, и надеюсь все же ответ получить
PD>Что, если заказчик поставит в проекте требование решить мимоходом задачу NP-полную ?
Получит неприемлемые оценки для быстродействия и закроет проект

PD>Но только инженер сможет сказать, при каких условиях ее все же можно решать полным перебором, а при каких задача неразрешима при текущем уровне железа.
Опять смешение мух и котлет. Работа инженера — дать оценки стоимости, как асимптотические, так и в терминах конкретного времени.
А "можно или нельзя" — это вопрос бизнеса. NP-полнота — это ж не бабайка, которой детишек пугают. Это совершенно конкретная вещь, когда в асимптотике времени исполнения есть экспонента.
Ну, да, можно иногда ограничиться низкими степенями и всё ещё уложиться в нормативы — например, если мы возьмёмся факторизовывать маленькие числа, то несмотря на NP-полноту получим приемлемое время работы.
Но приемлемость определяется не инженерами, а обратно бизнесом. Хороший инженер, конечно же, помогает бизнесу с этим определением. Потому что бизнес не всегда имеет экспертизу в UX, а инженеру, если он берётся рассуждать о требованиях, такая экспертиза крайне полезна.

Вот, кстати, даже в формулировке задачи прозвучало "Приближенные решения не годятся, допустим". Откуда взялось это требование? Его что, инженер придумал?
Нет, это бизнес по какой-то своей, бизнесу ведомой причине потребовал точных решений. Скажем, если мы там подбираем простые делители для криптографии, то нас будет интересовать точное решение.
А для задачи коммивояжёра приближённое решение устроит примерно любой бизнес. То есть — приемлемость приближений зависит не от инженерных свойств (потому что математически все NP-полные задачи сводимы друг к другу), а от потребностей бизнеса. Почему эта простая мысль вызывает такие трудности в освоении?

PD>Да даже и не NP-полная — пусть там совсем не бог весть что по требованиям, но для Z1 надо потратить столько, что денег у заказчика не хватит.
Я вроде бы русским языком пишу. Вот цитата:

Если ни один из вариантов по Z0, Z1, T0, и Y не укладывается в неравенство — значит, проект не имеет экономического смысла, и мы его закрываем.

Какой из пунктов непонятен? Вы же пишете ровно то же самое, только другими словами. "Денег у заказчика не хватит" — ну вот это и означает, что предел стоимости проекта определяет не инженер, а заказчик.
Откуда инженер знает, хватит или нет у заказчика денег?

PD>Цитирую
>>Но пока пишем в блокнотик просто Y.
PD>Y — прямо зависит от Z, только с учетом времени на окупаемость, так как X — текущие расходы, это константа, уже данная.
Y зависит от Z косвенно. Потому что можно за очень большой Z сделать систему со вполне себе стрёмным Y — в том числе, и выше, чем X.
А иногда с невеликим Z можно получить систему с хорошим Y.
Бывает, что уменьшение Y на считанные проценты требует кратного роста Z.
Но чаще всего у нас получается ряд вариантов с примерно одинаковым Z, которые дают существенно разные Y (что опровергает гипотезу о существовании зависимости Y от Z), и парочка экстремальных вариантов — "для бедных", с низким Z и высоким Y, и "наилучший" — с приемлемым Z и хорошим Y.

PD>Да не в принциапх бизнес-планирования дело. Бизнес может, конечно, на основе этих принципов определить желаемую цену проекта. А вот насколько это реальная цена с точки зрения разработчиков ?
Ну так это пусть разработчики скажут. Ещё раз поясню простую вещь, которая от вашего понимания почему-то ускользает: бизнес выставляет требования. Например — уложиться в стоимость Z.
Если эти требования нереалистичны — ну ок, пусть нереалистичны. Просто проект не будет стартован. Всё. Иногда эти требования нежёсткие — ну там, посчитали, Z в полтора раза выше, чем хотел заказчик. Тот консультируется с финдиром, оценивает риски и доп.расходы — и берёт кредит. Если получится нужный Y, то кредит можно будет отдать. Если нет, то такой тип деятельности называется "прожектом".
Но в топике-то речь не об убыточных проектах, а о том, почему программисты не понимают причин выбора более низких Z, когда можно же потратить гораздо больше. А ответ обычно прост — непонимание это формировалось в эпоху, когда Z0 >> Z1, поэтому потратить втрое больше времени на программирование для получения 10% выигрыша в производительности всё ещё окупалось.
А сейчас уже Z0 < Z1, а иногда и << Z1, поэтому лучше потратить $2000 на ещё одну машинку, а не $5000 на ещё один человеко-месяц с неизвестным заранее выхлопом.

PD>Кстати, зря ты так уверен, что, скажем, T — это константа планирования.
(вздох). Я же написал: изложена упрощённая модель, для детского сада. Когда её усвоите, можно будет обсуждать более сложные вещи — такие, как эластичность, NPV, а так же вероятностные модели и работу с неопределённостями.

PD>Бизнес хочет, чтобы это окупилось за T. Обсудили с инженерами, стоимость выходит в 2 раза больше, и за T не окупится. Но, возможно, окупится за 2T. Бизнес обдумывает ситуацию. Возможно, и согласится. Если T=1 год, как бизнес хотел бы, то, может, его и устроит 2 года.
Всё верно. А может — не устроит. Инженерам об этом узнать неоткуда. Именно бизнес определяет, устроит или не устроит.

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

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

PD>>Хорошо. Итак, на том, что инженеры должны ответить на вопрос, сколько это будет примерно стоить, мы согласны.
PD>>Тогда вопрос, к которому я и вел : каким образом инженеры будут оценивать эту стоимость ?
S>Традиционно — суммированием произведений количества на цену. В чём вопрос-то?

Как определить количество и цену ?

PD>>И зря ты не ответил на мой вопрос. Повторяю его, и надеюсь все же ответ получить
PD>>Что, если заказчик поставит в проекте требование решить мимоходом задачу NP-полную ?
S>Получит неприемлемые оценки для быстродействия и закроет проект

От кого ? От инженеров ?

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

А, все же инженер должен дать оценки ?

S>А "можно или нельзя" — это вопрос бизнеса. NP-полнота — это ж не бабайка, которой детишек пугают. Это совершенно конкретная вещь, когда в асимптотике времени исполнения есть экспонента.

Это все слова, а реально это может означать, что проект вообще не осуществим. Сказать об этом может только инженер.

S>Ну, да, можно иногда ограничиться низкими степенями и всё ещё уложиться в нормативы — например, если мы возьмёмся факторизовывать маленькие числа, то несмотря на NP-полноту получим приемлемое время работы.
S>Но приемлемость определяется не инженерами, а обратно бизнесом. Хороший инженер, конечно же, помогает бизнесу с этим определением. Потому что бизнес не всегда имеет экспертизу в UX, а инженеру, если он берётся рассуждать о требованиях, такая экспертиза крайне полезна.

Значит, инженер, хоть и как-то туманно, но все же помогает ?

S>Вот, кстати, даже в формулировке задачи прозвучало "Приближенные решения не годятся, допустим". Откуда взялось это требование? Его что, инженер придумал?

Да. С приближенными решениями не получить нужный результат.

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

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

S>А для задачи коммивояжёра приближённое решение устроит примерно любой бизнес. То есть — приемлемость приближений зависит не от инженерных свойств (потому что математически все NP-полные задачи сводимы друг к другу), а от потребностей бизнеса. Почему эта простая мысль вызывает такие трудности в освоении?

Бизнес уже знает про задачу коммивояжера ? И может определить без инженеров, что она тут возникает ?

PD>>Да даже и не NP-полная — пусть там совсем не бог весть что по требованиям, но для Z1 надо потратить столько, что денег у заказчика не хватит.
S>Я вроде бы русским языком пишу. Вот цитата:
S>

S>Если ни один из вариантов по Z0, Z1, T0, и Y не укладывается в неравенство — значит, проект не имеет экономического смысла, и мы его закрываем.

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

А он и не должен знать. Его дело — оценить задачу и затраты. А потом выяснится, устраивает ли это заказчика. По деньгам, срокам разработки и окупаемости.

PD>>Цитирую
>>>Но пока пишем в блокнотик просто Y.
PD>>Y — прямо зависит от Z, только с учетом времени на окупаемость, так как X — текущие расходы, это константа, уже данная.
S>Y зависит от Z косвенно. Потому что можно за очень большой Z сделать систему со вполне себе стрёмным Y — в том числе, и выше, чем X.
S>А иногда с невеликим Z можно получить систему с хорошим Y.
S>Бывает, что уменьшение Y на считанные проценты требует кратного роста Z.
S>Но чаще всего у нас получается ряд вариантов с примерно одинаковым Z, которые дают существенно разные Y (что опровергает гипотезу о существовании зависимости Y от Z), и парочка экстремальных вариантов — "для бедных", с низким Z и высоким Y, и "наилучший" — с приемлемым Z и хорошим Y.

PD>>Да не в принциапх бизнес-планирования дело. Бизнес может, конечно, на основе этих принципов определить желаемую цену проекта. А вот насколько это реальная цена с точки зрения разработчиков ?
S>Ну так это пусть разработчики скажут. Ещё раз поясню простую вещь, которая от вашего понимания почему-то ускользает: бизнес выставляет требования. Например — уложиться в стоимость Z.

Мне кажется, что мы говорим о разных вещах. Ты — о том, как бизнес выставляет требования. Это понятно, что он их должен выставлять из бизнес-соображений, но не будучи компетентен в технической реализации, он может что угодно выставить. И только специалисты-инженеры могут определить, насколько такие требования реальны. И сказать — нет, за время T мы не сделаем, сделаем только за 2T. И железа нужно не на N USD, а на 10N. И обрабатывать K элементов в минуту мы вообще не сможем, техника не позволяет, а только K/2. И т.д.

С этим согласен ? Да или нет ?

S>Всё верно. А может — не устроит. Инженерам об этом узнать неоткуда. Именно бизнес определяет, устроит или не устроит.

Разумеется, только бизнес определяет, устроит или нет его. Деньги-то его. А инженеры определяют эти данные для бизнеса.

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

PD>>Я не случайно этот вопрос задал.
PD>>Ясно, что в MS-DOS она либо не могла быть вообще решена, либо пришлось бы писать какую-то собственную настройку распараллеливания.
S>Эмм, распараллеливание в MS-DOS — это какой-то оксюморон. Эта ОС принципиально не умеет работать на многоядерном ЦПУ; а на одном ядре параллелить CPU-bound задачи — бессмыслица.

Зато для IO не бессмыслица и в этом смысле распараллеливание в MS-DOS было всегда — через прерывания.

Еще не бессмыслица параллелить GUI — ведь пользователь тыкает в периферию очень редко с т.з. CPU, можно в фоне играть музыку, например, автоматически проверять почту... вот тебе Windows до Win95 — это просто DOS-программа. ))

Здравствуйте, Pavel Dvorkin, Вы писали:
S>>Традиционно — суммированием произведений количества на цену. В чём вопрос-то?
PD>Как определить количество и цену ?
Количество:
1. По таблицам.
2. По формулам.
3. Экстраполяцией.
Цену — по прайс-листам.
Обычная, простая инженерная деятельность. Что именно непонятно?

S>>Получит неприемлемые оценки для быстродействия и закроет проект

PD>От кого ? От инженеров ?
Конечно от инженеров. А от кого ещё?

PD>А, все же инженер должен дать оценки ?
Что значит "всё же"??? Я с самого начала писал, что оценки делает именно инженер.

PD>Это все слова, а реально это может означать, что проект вообще не осуществим. Сказать об этом может только инженер.
Опять пошёл бред после минуты просветления. Я же написал, как устроен критерий неосуществимости проекта.
Как раз в большинстве случаев инженер не владеет нужными данными для принятия решения об осуществимости или неосуществимости.
Инженер не знает ничего ни о ёмкости рынка, ни о доступности финансов

S>>Ну, да, можно иногда ограничиться низкими степенями и всё ещё уложиться в нормативы — например, если мы возьмёмся факторизовывать маленькие числа, то несмотря на NP-полноту получим приемлемое время работы.
S>>Но приемлемость определяется не инженерами, а обратно бизнесом. Хороший инженер, конечно же, помогает бизнесу с этим определением. Потому что бизнес не всегда имеет экспертизу в UX, а инженеру, если он берётся рассуждать о требованиях, такая экспертиза крайне полезна.
PD>Значит, инженер, хоть и как-то туманно, но все же помогает ?
Ну, да. Например, когда заказчик говорит "давайте всё зафигачим в одну форму с 297 вопросами", инженер может предложить что-нибудь типа "давайте порежем на несколько под-форм, или хотя бы разрешим сохранять недозаполненную версию. Потому что вы, как бизнесмен, видите только оптимистичный сценарий, а я, с учётом моего опыта, вижу ещё с десяток, которые тоже для вас важны, хоть вы этого и не осознаёте".

PD>Да. С приближенными решениями не получить нужный результат.

А откуда инженер знает, что такое "нужный результат"?

PD>Бизнес вообще не знает, чем приближенное решение отличается от точного, и вообще даже, есть тут точные решения, приближенные или вообще только эвристические, и насколько они годятся.
У вас какие-то очень, очень мифологические представления о бизнесе.

PD>Бизнес уже знает про задачу коммивояжера ? И может определить без инженеров, что она тут возникает ?
Конечно. Как вы думаете, откуда эта задача вообще возникла? Формулировка задачи была дана никакими не инженерами, а вполне себе бизнесменами: Der Handlungsreisende – wie er sein soll und was er zu tun hat, um Aufträge zu erhalten und eines glücklichen Erfolgs in seinen Geschäften gewiß zu sein – von einem alten Commis-Voyageur.

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

PD>Мне кажется, что мы говорим о разных вещах. Ты — о том, как бизнес выставляет требования. Это понятно, что он их должен выставлять из бизнес-соображений, но не будучи компетентен в технической реализации, он может что угодно выставить.
PD>И только специалисты-инженеры могут определить, насколько такие требования реальны. И сказать — нет, за время T мы не сделаем, сделаем только за 2T. И железа нужно не на N USD, а на 10N. И обрабатывать K элементов в минуту мы вообще не сможем, техника не позволяет, а только K/2. И т.д.
PD>С этим согласен ? Да или нет ?
Да, всё верно. Но точно так же — специалисты-инженеры оценивают параметры будущего решения. И только бизнес-специалисты могут сказать, будут ли эти параметры коммерчески оправданы, или нет. Потому что будучи некомпетентны в вопросах бизнеса, инженеры могут нарисовать лишних расходов на разработку там, где это не даст никакого бизнес-выхлопа.

PD>Разумеется, только бизнес определяет, устроит или нет его. Деньги-то его. А инженеры определяют эти данные для бизнеса.
Ну, теперь, надеюсь, понятно, откуда берутся требования к софту?
Или всё ещё остались иллюзии про то, что это инженер придумывает что-то вроде "нам нужно обрабатывать одновременные запросы от 10B пользователей", и пофиг, что столько пользователей на всей планете не найдётся?

Здравствуйте, vdimas, Вы писали:
V>Зато для IO не бессмыслица и в этом смысле распараллеливание в MS-DOS было всегда — через прерывания.
Я понимаю, что читать больше одного предложения подряд — это тяжело.

Верх параллельности под MS-DOS — это какой-нибудь fastback, который параллелил IO с компрессией.

V>Еще не бессмыслица параллелить GUI — ведь пользователь тыкает в периферию очень редко с т.з. CPU, можно в фоне играть музыку, например, автоматически проверять почту... вот тебе Windows до Win95 — это просто DOS-программа. ))
Это и есть IO. Консольный, аудио, сетевой, дисковый. С чем спорим-то?

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

По 100 раз одно и то же — сил нет, оставлю главное.

S>Конечно от инженеров. А от кого ещё?

Слава богу, хоть тут согласие

S>Что значит "всё же"??? Я с самого начала писал, что оценки делает именно инженер.

И тут.

PD>>Мне кажется, что мы говорим о разных вещах. Ты — о том, как бизнес выставляет требования. Это понятно, что он их должен выставлять из бизнес-соображений, но не будучи компетентен в технической реализации, он может что угодно выставить.
PD>>И только специалисты-инженеры могут определить, насколько такие требования реальны. И сказать — нет, за время T мы не сделаем, сделаем только за 2T. И железа нужно не на N USD, а на 10N. И обрабатывать K элементов в минуту мы вообще не сможем, техника не позволяет, а только K/2. И т.д.
PD>>С этим согласен ? Да или нет ?
S>Да, всё верно. Но точно так же — специалисты-инженеры оценивают параметры будущего решения. И только бизнес-специалисты могут сказать, будут ли эти параметры коммерчески оправданы, или нет. Потому что будучи некомпетентны в вопросах бизнеса, инженеры могут нарисовать лишних расходов на разработку там, где это не даст никакого бизнес-выхлопа.

И я с этим согласен. Все, с бизнесом разобрались. Он оценивает коммерческую приемлемость предложенного инженерами решения. Я никогда и не утверждал, что коммерческую приемлемость будут оценивать сами инженеры, нет у меня такого. Все, консенсус

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

Верно ? Да или нет ?

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

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

ну не совсем, это задача для менеджеров, связать запросы бизнеса, потребности инженеров и предупредить, что несвязуха есть

Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Верно ? Да или нет ?
Да, верно. Надеюсь, теперь понятно, откуда заказчик берёт требования к срокам, быстродействию, и стоимости железки?

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

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

Вот и отлично. Заказчик тут меня мало интересует, с ним понятно. А вот с исполнителем все сложнее, и возвращаемся к исходной теме обсуждения — свойствам программ.

Итак, заказчик определил максимальную стоимость как 100 некоторых единиц.

1. Исполнитель может заявить, что задача не решается ни за 100, ни за 100000. Тут все ясно.
2. Исполнитель может заявить, что задача не решается за 100, но за 500 он ее сделает. Тут торг и уточнение параметров. Если не договорятся, то расходимся, иначе (3)
3. И заказчик и исполнитель согласны на 100. Вариант, когда исполнитель считает в душе, что хватит и 10, не обсуждаем, он выходит за рамки темы.

Итак, исполнитель согласен на 100. Пусть из этих 100 80 уйдут программистам, а 20 — накладные расходы. Соотношение не так уж важно.

20 не оптимизируешь, с ними все ясно.

А вот 80 можно распределить несколькими способами

Обращаю внимание на то, что во всех этих вариантах предполагается, что результат заказчика удовлетворит по ТЗ. Все будет сделано и будет работать.

1. Нанять 4 сеньоров , дать каждому по 20. Они сделают все качественно.
2. Нанять 3 сеньоров , дать каждому по 20, и двух юниоров, дать каждому по 10. Сеньоры будут делать основное, а юниоры будут на подхвате, им будет поручено то, что некачественно сделать трудно, Ну а если все же сделают некачественно, сеньоры их ткнут и скажут переделать.
3. Нанять 1 сеньора , дать ему 20, и шесть юниоров, дать каждому по 10. Сеньор будет тимлидом, а писать в основном будут юниоры.

Если у нас жесткие технические ограничения по памяти и быстродействию машины , то вариант 3 просто не проходит. Они не смогут написать код, чтобы уложиться в эти 16 Мбайт. А больше взять неоткуда — машин с большей памятью просто нет.

А вот если такие ограничения отсутствуют, то и команда-3 сделает продукт. Только памяти он займет в 10 раз больше, чем для команд 1-2, и работать будет в 10 раз медленнее, чем для них же.

А все равно работает. Заказчик доволен. Он теперь вполне знает, сколько за подобный продукт можно просить. И главное, он теперь знает, какие требования к железу и ПО можно предъявлять. Памяти нужно M Гбайт. Раньше он не знал, а теперь знает. Вот же продукт, он требует M, значит, для задачи такого рода меньше быть не может. Быстродействие — аналогично.

Дальнейшее.

Члены команды 1 будут работать надо следующим проектом, с ними все хорошо.
Сеньоры команды 2 будут работать надо следующим проектом, с ними все хорошо. Юниоры команды 2 чему-то научатся, и если не в следующем, то через пару проектов сами станут грамотными сеньорами.

А вот с командой 3 все намного хуже. Сеньор добиться качественного кода всех 6 юниоров не сможет. Увидит что-то один раз — поправит. Второй раз — поправит. А потом махнет рукой. Работает же, требованиям заказчика удовлетворяет, ну и ладно.

Закончен проект и они разойдутся. Юниоры — в уверенности, что так код писать можно, и вообще качественный код — это код, который удовлетворяет заказчика. Других требований к нему не может быть.
А сеньор, глядя на все это , и сам подумает : а не зря ли я писал качественно. Вот сделали проект черт те как, но все работает, заказчик доволен.

Юниоры через некоторое время станут сеньорами, вполне уверенными, что сорить памятью и применять неэффективные алгоритмы — это норма.

И когда через некоторое время заказчик попросит сделать новую работу стоимостью в 200, поручат ее бывшей команде 3. А они потребуют 500, так как с их пониманием что требуется для чего, надо памяти раз в 5 больше или процессор в 5 раз быстрее. На 300 сойдутся, и сделают, с тем же качеством.

Вот поэтому мы и имеем, что имеем.

Размер SSD растёт (ну или цена падает, другими словами).

Вроде размер HDD тоже растёт, хотя уже перестал следить за ними.

Если брать хай-энд за разумные деньги, то в 2024 году будет гораздо больше ядер, чем в 2014.

По сути растёт число транзисторов. Однопоточную скорость процессора это не увеличивает, но число потоков увеличивает.

Видеокарты — да, развивались и развиваются. Тут и специфика устройства сказывается, в котором распараллеливание задач практически идеальное, и хайп ИИ сказывается, и статус де-факто монополиста, что приносит nvidia огромные деньги и возможность прогрессировать на них.

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

C>>Зачем? Вот скажите мне, зачем современным приложениям, столько памяти?

PD>Просто разучились писать приложения компактно.

Никто не разучился. Я тоже пример приведу.

Я купил iPhone 4S в 2012 году. У него было 512 MB RAM и двухядерный процессор с частотой 1 ГГц. При покупке в нём интерфейс просто летал, андроиды сравнения просто не выдерживали никакого. Я на этом телефоне и в потрясающие 3D игры играл в том числе. Меня просто поражало, сколько вычислительной мощи туда запихнули.

Помимо прочего одно из наиболее часто используемых приложений у меня было — Яндекс Навигатор. У меня были большие проблемы со знанием города, я тогда начал водить машину и этот навигатор был моим незаменимым помощником.

Прошло 5 лет. Apple выпустила iOS 7, ну и последующие, которые превратили телефон в тыкву. Яндекс Навигатор с каждой новой версией тормозил всё больше, дошло до того, что он у меня запускался чуть ли не минуту, в то время как раньше это был почти мгновенный запуск. Если переключить приложения, фоновое практически всегда прибивалось. В последние месяцы он порой тупо вылетать начал, полагаю, что из-за нехватки памяти. Ну про то, что взаимодействие с интерфейсом уже подтормаживало, думаю, и упоминать не стоит.

Естественно покупка iPhone 8 исправила все эти проблемы и всё стало как было.

Что — за 5 лет программисты вымерли в яндексе? Вряд ли. Просто программы пишут под целевое железо. Если целевое железо слабое — пишут "компактно". Если целевое железо по мощности перегнало десктоп (не шутки, у iPhone 8 процессор был быстрей десктопного) — значит пишут "размашисто".

Я и сам такой. Сегодня пишу под микроконтроллер, в котором пара килобайтов памяти, 20 килобайтов флеша и процессора на пару мегагерцев мне хватает. Копируя байты через DMA и проверяя сгенерированный машинный код в некоторых местах. А завтра пишу на жаве под приложение в кластере, которое работает на пяти серверах. Естественно я пишу совсем по-разному. Я могу и жаву заменить на C. И кластер из пяти серверов заменить на один распи. Но сроки выполнения такой задачи будут весьма большие. Учиывая, что эти 5 серверов в месяц стоят раз в 10 дешевле, чем я, это просто неразумная трата денег, когда речь заходит о финансовой целесообразности.

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

vsb>Я и сам такой. Сегодня пишу под микроконтроллер, в котором пара килобайтов памяти, 20 килобайтов флеша и процессора на пару мегагерцев мне хватает. Копируя байты через DMA и проверяя сгенерированный машинный код в некоторых местах. А завтра пишу на жаве под приложение в кластере, которое работает на пяти серверах. Естественно я пишу совсем по-разному. Я могу и жаву заменить на C. И кластер из пяти серверов заменить на один распи. Но сроки выполнения такой задачи будут весьма большие. Учиывая, что эти 5 серверов в месяц стоят раз в 10 дешевле, чем я, это просто неразумная трата денег, когда речь заходит о финансовой целесообразности.
На самом деле еще зависит и от того сколько стоит аренда памяти, герцев и диска.
Например в .Net набирает популярность Native AOT. Да есть проблемы с динамической компиляцией, обрезкой, но с каждой версией всё веселее и веселее.

Our Vision for .NET 9
Делается ставка на Native AOT,ИИ.

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

vsb>Размер SSD растёт (ну или цена падает, другими словами).

Но скорость роста за 10 лет — примерно в 2 раза. Не в 200 раз.

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

V>>Зато для IO не бессмыслица и в этом смысле распараллеливание в MS-DOS было всегда — через прерывания.
S>Я понимаю, что читать больше одного предложения подряд — это тяжело.
S>

S>Верх параллельности под MS-DOS — это какой-нибудь fastback, который параллелил IO с компрессией.

Да пофик конкретно на Fastback, забавным является позиция "IO фигня".
А принтер как печатал из текстовых редакторов с одновременным отображением в GUI?
PostScript, PRESCRIBE, MS Works for DOS?

V>>Еще не бессмыслица параллелить GUI — ведь пользователь тыкает в периферию очень редко с т.з. CPU, можно в фоне играть музыку, например, автоматически проверять почту... вот тебе Windows до Win95 — это просто DOS-программа. ))
S>Это и есть IO. Консольный, аудио, сетевой, дисковый. С чем спорим-то?

С непониманием, ес-но.
На прерываниях и делается, собсно, многозадачность.
И более всего многозадачность в персоналках нужна для IO, ес-но, т.к. пользователь способен работать только с одной активной программой с т.з. CPU в каждый момент времени.

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

В общем, ты опять пролетел мимо важной сути, определившей лицо ПО примерно на десятилетие, а именно — ограничением DOS была не-реентерабельность обработчиков прерываний.
Только поэтому версии Windows до Win95 вынужденно работали через кооперативную многозадачность, а не через вытесняющую...
(а не потому что вытесняющую ниасилили)

Поэтому, верхом MS DOS была кооперативная многозадачность, а не прерывания IO, которые были в персоналках отродясь, даже в 8-битных — иначе бы они работать не смогли бы.
ZX-Spectrum в фоне сканировал клавиатуру 50 раз в секунду, если что (по прерыванию видеоподсистемы).

И без всяких MS DOS.

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

V>ZX-Spectrum в фоне сканировал клавиатуру 50 раз в секунду, если что (по прерыванию видеоподсистемы).

V>И без всяких MS DOS.

Ох, было время.

Как-то задался целью узнать где расположена эта подпрограмма обработки прерывания с клавы.

Начал изучать код ассемблера. Доки не было практически, но каждую команду до этого я исследовал как ученый — проверял какие изменения в регистрах производит и т.д. Т.е. брал отдельную команду, запускал, смотрел регистры. Была там и довольно сложная команда типа для работы с массивом данных, емнип.

Так вот, пытался изучать код из ПЗУ, что очень не просто. Дизассемблер был самодельный, не все коды поддерживал.

И таки нашел эту подпрограмму, осталось только проверить гипотезу. Но как?

А проверил так — замаскировал прерывание от клавы. Это значит что она как бы перестала откликаться. Отпаял ножку процессора от немаскируемого перывания (второго) и подал туда сигнал 50 герц от генератора. Направил немаскируемое прерывание на тот же адрес, куда ранее было направлено маскируемое. Клава заработала. ЧТД.

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

S>Как-то задался целью узнать где расположена эта подпрограмма обработки прерывания с клавы.

С клавы ZX Spectrum не было аппаратного прерывания, оно генерировалось программно.
Алгоритм опроса клавы сидел на аппаратном прерывании, обыгрывал дребезжание и если "понимал", что кнопка надёжно нажата или отпущена, генерировал программное прерывание.

В IBM PC в клаве сидел сравнимый i8080, который по RS-232 гонял уже управляющие коды, и CPU реагировал на прерывание от последовательного порта.
Позже в линейке IBM PS/2 возник одноимённый порт, но он был виден софтом всё-равно как прежний последовательный.

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

V>С клавы ZX Spectrum не было аппаратного прерывания, оно генерировалось программно.

Мне нужно было узнать адрес куда оно уходило.

В Z80 было два прерывания — маскируемое и не маскируемое. Одно из них именно аппаратное — подаешь сигнал на ножку процессора и оно срабатывало.

Адрес программного емнип 64 ячейка и его нельзя было изменить (точно не уверен что 64).

V>Алгоритм опроса клавы сидел на аппаратном прерывании, обыгрывал дребезжание и если "понимал", что кнопка надёжно нажата или отпущена, генерировал программное прерывание.

Какая кнопка? Там же много кнопок — как вы все одновременно будете проверять?

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

V>>Еще не бессмыслица параллелить GUI — ведь пользователь тыкает в периферию очень редко с т.з. CPU, можно в фоне играть музыку, например, автоматически проверять почту... вот тебе Windows до Win95 — это просто DOS-программа. ))
S>Это и есть IO. Консольный, аудио, сетевой, дисковый. С чем спорим-то?

Кстате, тут можно поспорить еще о том, чем являлись программы под Windows до Win95.

Де-факто они не были программами с т.з. операционки, хотя имели расширение exe.
Это что-то вроде оверлеев/модулей, который загружались и выгружались хостовой MSDOS-программой windows.exe.

Именно поэтому различия exe и dll под Windows минимальны, отличаются только вербальными соглашениями о точках входа и происходящем при этом.
dll должна вернуться из точки входа DllMain как можно раньше (точка входа для DLL опциональна), а после возврата из точки входа exe (обязательное наличие точки main или WinMain) внешняя инфраструктура выгружала модуль.

Если склероз не изменяет, можно определить точку входа DllMain и для экзешника, и пользоваться как либой.

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

V>>Алгоритм опроса клавы сидел на аппаратном прерывании, обыгрывал дребезжание и если "понимал", что кнопка надёжно нажата или отпущена, генерировал программное прерывание.
S>Какая кнопка? Там же много кнопок — как вы все одновременно будете проверять?

Почему одновременно?
Поочерёдным сканированием.

Всего 40 кнопок.
8 линий сканирования по 5 разрядов в каждой.

Сбрасываешь в 0 один из старших битов адреса порта (младший всегда FE), читаешь байт из порта, в нём интересуют разряды с 0-го по 4-й.

Если в разряде 0 — кнопка на текущей скан-линии нажата.

Программно это выглядит как примерно такая последовательность:

KbScanArray:
    ds 8

...

KbScanProc:
   ld hl, KbScanArray

   ld a, F7h
   in a, FEh
   ld (hl), a
   inc hl

   ld a, FBh
   in a, FEh
   ld (hl), a
   inc hl
...
   ld a, 7Fh
   in a, FEh
   ld (hl), a

По окончании в KbScanArray будет 8 скан-кодов.

Вдогонку.
В реальности это всё расписывалось на макро-ассемблере и выглядело более читабельно:

KbScanArray:
    ds 8

...
   .macro ScanLine %L 
   ld a, %L
   in a, FEh
   ld (hl), a
   .endm

   .macro ScanLineInc %L 
   ScanLine %L
   inc hl
   .endm

KbScanProc:
   ld hl, KbScanArray
   ScanLineInc F7h
   ScanLineInc FBh
   ScanLineInc FDh
   ScanLineInc FEh
   ScanLineInc EFh
   ScanLineInc DFh
   ScanLineInc BFh 
   ScanLine 7Fh

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

V>>>Алгоритм опроса клавы сидел на аппаратном прерывании, обыгрывал дребезжание и если "понимал", что кнопка надёжно нажата или отпущена, генерировал программное прерывание.
S>>Какая кнопка? Там же много кнопок — как вы все одновременно будете проверять?

Не буду спорить, занимался этим 24 года назад примерно. Много воды утекло.

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

S>Не буду спорить, занимался этим 24 года назад примерно. Много воды утекло.

Да принцип тот же и в клавах IBM PC — шина адреса порта замыкается кнопкой на шину данных.

Причём, в простых схемах обходятся без сложного дешифратора номера порта.
Например, в ZX Spectrum де-факто нужен был просто 0 в младшем адресе порта, чтобы подключить буферный регистр скан-адреса клавы к шине данных через замыкатели кнопок.

Здравствуйте, 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 подозреваю, ситуация похожая.

А насчёт потребления памяти и процессора — тут совсем не факт, что будет выигрыш. Но большого проигрыша точно не будет.

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

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 больше памяти, чем это было минимально необходимо.

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

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

PD>Голосование по эффективности и расходам ресурсов
PD>https://rsdn.org/poll/9966

Просто из своего опыта построения числодробилок.

— Организуется конвейер.

— Массивы выделяются предварительно и в процессе вычислений затем не выделяются и не освобождаются.

— При межпоточной передаче работает что-то вроде круговой очереди указателей на такие массивы.

— Перекладывать данные при расчётах в новое место или делать их inplace зависит сугубо от характера вычислений и ни от чего более. Например, преобразование блока сигнала, представленного int32, во float32 можно и нужно делать только inplace, иначе попахивает профнепригодностью.

— Рассуждения Синклера про "гарантии" и прочее можно смело в dev/null, бо инкапсуляцию данных модулей/объектов еще никто не отменял. Способы владения (и передачи владения) блоков данных подчиняются исключительно и только алгоритмам, их обрабатывающим, а не внутренним взглядам и жизненным принципам особо упрямых коллег. ))

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

S>Насколько надёжно ваше доказательство того, что "после функции этот массив никому не нужен"?
S>Насколько надёжно предположение о том, что это не изменится в будущем?

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

Ни одно известное решение не является универсальным, у любого решения есть плюсы и минусы.
Ты же каждый раз предлагаешь смотреть на задачу одним глазом (причём, не скрывая каким именно), рассуждая снова и снова о "гарантиях".

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

Эти периоды были дважды на моей памяти и дважды эти периоды были очень малы по историческим меркам.
Зато породили кучу балласта в современном IT, в виде неэффективных ЯП и целого сомна бесполезных на практике религий.

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

PD>Резюмирую. Бизнес оценит коммерческую приемлемость решения, а оценку стоимости разработки дадут инженеры, базируясь на своем знании стоимости железа, софта, разработки и т.д.
PD>При этом бизнес готов выставить свои соображения насчет максимальной стоимости, выше которой он заплатить не может, исходя только из бизнес-соображений (рентабельность, окупаемость и т.д.).
PD>Верно ? Да или нет ?

На практике почти всегда есть вилка характеристик и цен.
И у этой вилки может быть овердохрена зубцов.

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

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

Например, так родились почти все современные популярные CMI и интернетные "платформы", заточенные на те или иные виды деятельности.

В этом месте происходит отделение бизнеса по разработке ПО от конкретного окучиваемого этим ПО бизнеса.

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

C>Зачем? Вот скажите мне, зачем современным приложениям, столько памяти?

C>Особенно на телефонках. Где по сути вся реальная работа, вся реальная нагрузка идет на какой-либо удаленный сервер, который и делает всю полезную работу!
C>Зачем интерфейсным по сути приложениям вот столько нужно памяти?
C>Примеров тому масса.

Это классическая "проблема общественного ресурса". Например, стоять в пробке надо 1 час. Не все готовы к этому, поэтому едут на метро. Дорогу расширили в полтора раза, и пробка стала 45 минут. Народ радостно пересел обратно на машины. И пробка снова 1 час... (только на большее кол-во машин)

Как только объем доступной памяти увеличивается, программистам нет смысла ужиматься и экономить. Поэтому они снова забивают ее до предела. И так будет с любым кол-вом памяти.

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

S>Из общих соображений бизнес хочет, чтобы это новшество окупилось за время T.
S>Отсюда сразу имеем неравенство: 0 < Z/(X-Y) <= (T-T0), где T0 — это срок реализации проекта. Из которого следует, что Z <= (T-T0) * (X-Y).
S>В частности, Z0+Z1 <= (T-T0) * (X-Y) — Z2.

Безразмерная величина сравнивается с днями, это нормально?

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

PD>Впрочем, все может быть даже проще. Ты хочешь распознавалку. Отлично. А откуда бизнес знает, можно ли ее вообще реализовать ? Если, вернемся к прежнему, у нас времена MS-DOS или NT4. Бизнес знает, что компьютеры есть, видеокамеры тоже, вообще-то распознавалки сделать можно. Но тебе надо же в риэлтайме, да еще и сколько-то в минуту. Это технически вообще возможно ? Откуда бизнесу это знать ?
PD>А если можно все же, то каковы требования к ресурсам ? Во времена NT4 было одно, сейчас несколько иное. А от этого Zi зависят.

Ну принципиальную возможность RnD крупных компаний выясняет или гос. заказы. Бизнес уже потом подбивает под нужды пользователей и
возможной выгоды, с оглядкой на сущ. решения (результат RnD компаний или гос-ва). Так думаю.

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

S>Безразмерная величина сравнивается с днями, это нормально?
У Z размерность "деньги". У X и Y размерность "деньги в единицу времени":

X рублей в год
Y рублей в год

Деление Z/(X-Y) соответственно, имеет размерность "время". В данном случае, измеренное в годах.

Здравствуйте, 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++ коде нашлась пара ошибок. Ну, просто они не стреляли достаточно зрелищно, поэтому автор их так и не заметил

Здравствуйте, 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 команды могут сделать вполне корректно работающее ПО. Если это не выполняется, то говорить не о чем.

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

PD>Глас вопиющего в пустыне. Я еще 20 лет назад тут писал про эффективность, ну и что ? С тех пор только хуже стало.
PD>Нет, не тогда это закончится. Закончится тогда, когда ВТ выйдет на плато. Когда характеристики перестанут расти вообще. Вот тогда понадобятся опять те, кто умеет писать эффективный код. Если они к тому времени останутся.
PD>И то нет уверенности. Просто тогда вместо 1 машины эта команда типа 3 создаст такой кластер, что не дай бог. И будут все уверены, что только так и можно. А стоимость оборудования расти вряд ли будет, она только падает.

Я еще помню те времена когда программировали в основном математики. Хотя и тогда существовали техникумы и книги "Всё об АСУ"
Но сколько было тех программистов и программ?
Сейчас стоимость софта, значительно дороже чем железо. Для ускорения стали внедрять распараллеливание, асинхронщину итд.
То есть экстенсивные методы.
Например сейчас набирает обороты Native AOT. То есть больше внимание уделяется библиотекам, генераторам кода и оптимизации компиляции.

Здравствуйте, 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>Вообще не закончится. Будет весь спектр. Это как, скажем, с одеждой. Рынок завален низкокачественным ширпотребом. Но если надо — по-прежнему можно купить хорошую вещь.

Согласен. Я не имею в виду, что вообще закончится. Просто когда компьютеры выйдут на плато, а потребности на плато не выйдут и будут все еще расти, возникнет опять необходимость в качественной разработке. И то не доказано, так как сейчас поставить много машин совсем не проблема, а таким способом можно будет решать эти проблемы без повышения качества. А до выхода количества машин на плато очень далеко, если это плато вообще может быть.

	От:	Shmj
	Дата:	22.02.24 23:41
	Оценка:

	От:	xma
	Дата:	22.02.24 23:49
	Оценка:

	От:	Pavel Dvorkin
	Дата:	23.02.24 03:42
	Оценка:	4 (3) +1

От:	Carc	https://vk.com/gosha_mazov
Дата:	23.02.24 05:55
Оценка:	+5 -1

	От:	Pavel Dvorkin
	Дата:	23.02.24 07:37
	Оценка:	+1

	"нам то не гони" (c)
	https://www.youtube.com/watch?v=5PZNMRTK4fk

	От:	Stanislaw K
	Дата:	23.02.24 09:10
	Оценка:	+2 -1

	От:	karbofos42
	Дата:	23.02.24 11:41
	Оценка:	1 (1)

	От:	student__
	Дата:	23.02.24 14:34
	Оценка:	1 (1) +1

От:	Sinclair	https://github.com/evilguest/
Дата:	24.02.24 04:01
Оценка:	1 (1)

От:	Serginio1	https://habrahabr.ru/users/serginio1/topics/
Дата:	28.02.24 20:21
Оценка:

От:	Pauel	http://blogs.rsdn.org/ikemefula
Дата:	29.02.24 20:02
Оценка:	1 (1) +1

От:	Basil2	https://starostin.msk.ru
Дата:	02.03.24 08:54
Оценка: