Здравствуйте, 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 года назад примерно. Много воды утекло.