В последнее время пришлось изрядно повозиться с разной электроникой, что не могло не навести на грустные мысли.
Помнится, в 70-е бОльшую часть электроники делали на "рассыпухе", микросхем тогда было мало, в основном цифровая логика. Микросхемы тех времен были простенькими, очень требовательными к качеству питания, нестабильными, капризными. Но с течением времени абсолютно все параметры микросхем непрерывно улучшались. Операционные усилители требовали двуполярного питания 12-15 В и имели несколько служебных выводов для обвязки стабилизации и частотной коррекции — теперь большинство имеет лишь выводы питания, входов и выхода, работает в широком диапазоне напряжений, нуль на выходе не "плывет" при изменениях температуры. Ранняя КМОП-логика выдерживала лишь мизерные токи, была чрезвычайно чувствительна к электростатике и наводкам, требовала минимум 9 В питания, а теперь она работает от полутора вольт, каждый выход может без внешних ключей зажигать десяток светодиодов, и паять ее можно без антистатического браслета. Раньше было легко спалить микросхему по неосторожности, а теперь многие микросхемы имеют встроенные защиты от перенапряжения, перегрева, а нередко — даже от переполюсовки питающего напряжения.
Сложность применения тоже значительно понизилась. Например, раньше большинство сложных цифровых микросхем непременно требовало внешнего сигнала сброса, а теперь они корректно переживают даже кратковременные провалы по питанию. Простым микроконтроллерам достаточно лишь подать питание, чтобы они корректно завелись и начали работать по программе.
То есть, современные микросхемы превосходят микросхемы прошлых лет по всем параметрам. Я знаю только один параметр, который испортился с тех времен, да и то лишь для любителей — компоновка выводов. Расстояние между выводами уменьшилось настолько, что их невозможно паять без лупы и тонкого жала, а для BGA требуются специальные технологии пайки, но все это даже сугубый любитель может освоить за часы, а потребное оборудование стоит копейки.
И вот, когда на фоне всего этого смотрю на эволюцию ПО, так прям тоска берет.
Здравствуйте, Евгений Музыченко, Вы писали:
ЕМ>То есть, современные микросхемы превосходят микросхемы прошлых лет по всем параметрам. Я знаю только один параметр, который испортился с тех времен, да и то лишь для любителей — компоновка выводов. Расстояние между выводами уменьшилось настолько, что их невозможно паять без лупы и тонкого жала, а для BGA требуются специальные технологии пайки, но все это даже сугубый любитель может освоить за часы, а потребное оборудование стоит копейки.
ЕМ>И вот, когда на фоне всего этого смотрю на эволюцию ПО, так прям тоска берет.
Но если посмотреть вооруженным глазом ***** вовнутрь этих мелкосхем, то возьмёт та же самая тоска
Тыщщи транзисторов (и офигенное энергопотребление) только для того, чтобы компенсировать криворукость радиоконструктора.
_____________________
С уважением,
Stanislav V. Zudin
Здравствуйте, Евгений Музыченко, Вы писали:
ЕМ>И вот, когда на фоне всего этого смотрю на эволюцию ПО, так прям тоска берет.
Возможно, дела так обстоят потому, что микросхема — материальный объект.
Не только производство каждого экземпляра стоит денег, но и подготовка производства тоже.
Поэтому отношение к разработке другое, чем в "мире поправимых ошибок".
Re[2]: Тенденции в развитии микроэлектроники и ПО :)
Здравствуйте, Stanislav V. Zudin, Вы писали:
SVZ>Но если посмотреть вооруженным глазом ***** вовнутрь этих мелкосхем, то возьмёт та же самая тоска SVZ>Тыщщи транзисторов
Чтобы увидеть эти тыщи, нужен или рентген, или обычный микроскоп (плюс шлифовка корпуса до кристалла). И для конструктора, и для потребителя они никак не видны — корпуса микросхем имеют меньшие размеры и массу, при той же функциональности обычно имеют меньше выводов.
SVZ>(и офигенное энергопотребление)
Это где? Подавляющее большинство микросхем имеет энергопотребление на порядки ниже тех, что были в 70-80-х.
SVZ>только для того, чтобы компенсировать криворукость радиоконструктора.
Если Вы про процессоры/контроллеры, то компенсируется криворукость не конструктора, а исключительно программиста. С теми методами программирования, что применялись в 70-х, сейчас элементарно достичь и предельной компактности, и чрезвычайно низкого энергопотребления.
Сколько Вы знаете конструкторов электроники, которые начинали в 70-80-х, и сейчас были бы недовольны тенденциями развития отрасли? А таких же программистов?
Re[2]: Тенденции в развитии микроэлектроники и ПО :)
Здравствуйте, alexsmirnoff, Вы писали:
A>Возможно, дела так обстоят потому, что микросхема — материальный объект. A>Не только производство каждого экземпляра стоит денег, но и подготовка производства тоже.
При всем этом микросхемы стоят сущие копейки, даже в рознице не так много моделей дороже доллара. Повышение цены на единицы центов значимо не влияет на стоимость конечных изделий — только на доходы эффективных менеджеров, которые в компания занимаются оптимизацией производства.
Кстати, автоматизация и проектирования, и оптимизации топологий привела только к улучшению параметров микросхем. А автоматизация проектирования/оптимизации программного кода приводит к его улучшению лишь в локальном плане, а в общем — только ухудшает.
ЕМ>И вот, когда на фоне всего этого смотрю на эволюцию ПО, так прям тоска берет.
На входе в электронику есть хотя бы фильтр на умение держать инструмент. А за пальцетыкательный девайс для программирования — любых абизьян усадить могут, и много лет не заметят никаких проблем.
Re[3]: Тенденции в развитии микроэлектроники и ПО :)
Здравствуйте, Евгений Музыченко, Вы писали:
SVZ>>Но если посмотреть вооруженным глазом ***** вовнутрь этих мелкосхем, то возьмёт та же самая тоска SVZ>>Тыщщи транзисторов
ЕМ>Чтобы увидеть эти тыщи, нужен или рентген, или обычный микроскоп (плюс шлифовка корпуса до кристалла). И для конструктора, и для потребителя они никак не видны — корпуса микросхем имеют меньшие размеры и массу, при той же функциональности обычно имеют меньше выводов.
Поэтому ты смотришь на микросхемы с позиции юзера.
SVZ>>(и офигенное энергопотребление) ЕМ>Это где? Подавляющее большинство микросхем имеет энергопотребление на порядки ниже тех, что были в 70-80-х.
А если бы были спроектированы правильно, то имели бы энергопотребление еще на порядок меньше.
Но это больше относится к печатным платам и к скоростям 56Гб/с и выше. Большая часть энергии от передатчика не доходит до приёмника и тупо превращается по дороге в тепло.
Наверняка можно минимизировать число транзисторов и сократить энергопотребление на дофига.
В 98 году делали подобную мульку для проектирования ASIC'ов. Но софтинка была на заказ для внутреннего употребления, в тираж не пошла.
SVZ>>только для того, чтобы компенсировать криворукость радиоконструктора.
ЕМ>Если Вы про процессоры/контроллеры, то компенсируется криворукость не конструктора, а исключительно программиста. С теми методами программирования, что применялись в 70-х, сейчас элементарно достичь и предельной компактности, и чрезвычайно низкого энергопотребления.
Нет, я про косяки именно конструкторов, не осиливших Signal Integrity.
Для исправления их ошибок внутри мелкосхем наверчены здоровенные блоки, которые усиливают и исправляют сигналы.
ЕМ>Сколько Вы знаете конструкторов электроники, которые начинали в 70-80-х, и сейчас были бы недовольны тенденциями развития отрасли? А таких же программистов?
Ты смотришь на код с точки зрения программиста.
А на микросхемы — с точки зрения пользователя и не знаешь, что творится под капотом.
Пользователи твоих программ тоже удивляются, "до чего дошел прогресс".
_____________________
С уважением,
Stanislav V. Zudin
Re[2]: Тенденции в развитии микроэлектроники и ПО :)
Здравствуйте, Osaka, Вы писали:
O>На входе в электронику есть хотя бы фильтр на умение держать инструмент.
Да это ж элементарщина, осваивается за минуты. И в целом сложность применения большинства микросхем только падает. И выпуск новой серии микросхем почти никогда не требует обязательного апгрейда оборудования для монтажа или тестирования, обязательного же использования других микросхем определенных моделей, ужесточения условий эксплуатации и т.п. Появились корпуса SSOP с шагом выводов 0.65 мм — достаточно было взять лупу и заточить жало, и все, можно паять. Появился JTAG — ему сразу было достаточно примитивного адаптера для подключения к компьютеру. Схемы сброса, UVLO/OVLO, защиты по току/температуре — почти везде внутри.
Да, а еще микросхема для развязки подключения к Ethernet не будет сливать через него производителю статистику о стабильности температуры и напряжения питания. Хотя наиболее сложные процессоры это уже умеют.
А в софте как? Вышла новая версия — какие-то ОС или мониторы больше не поддерживаются, требуется обновление фреймворка X и библиотеки Y (при этом другой софт как раз не будет работать с обновленными, поэтому придется поставить в параллель)...
Здравствуйте, Евгений Музыченко, Вы писали:
ЕМ>И вот, когда на фоне всего этого смотрю на эволюцию ПО, так прям тоска берет.
Ну не знаю, я даже 10-летнию Idea с современной считаю несравнимой. А Github Codespaces для меня это просто космос, прорыв, фантастика, фильм из будущего. А если с 70-ми сравнивать, то это считай две разные цивилизации. Правда я в 70-е не жил, но подозреваю, тогда вообще на проводках программировали и жёсткие диски втроём носили самые сильные программисты.
Здравствуйте, Stanislav V. Zudin, Вы писали:
SVZ>Поэтому ты смотришь на микросхемы с позиции юзера.
У микросхем не бывает таких юзеров, как у программ, это не конечные изделия. Можно сказать, что я смотрю на них, скажем, с позиции прикладного программиста на функции API. Но при этом у типичного программиста на функции API обычно возникает куда больше матов, чем у конструктора аппаратуры — на микросхемы.
А когда я смотрю на ПО с позиции конечного юзера, мне регулярно приходится вникать в подробности вроде "встанет ли Win10 на этот ноутбук, а Win7 — на тот", "потребует ли новая версия этого софта обновления .NET, IE или установки обновлений ОС", "смогу ли я открыть все свои любимые сайты, поменяв или обновив браузер" и т.п.
SVZ>А если бы были спроектированы правильно, то имели бы энергопотребление еще на порядок меньше.
Для большинства это вряд ли имеет смысл — все равно типичный миллиамперметр показывает нули, нужен специальный.
SVZ>Но это больше относится к печатным платам и к скоростям 56Гб/с и выше.
Ну, это уже весьма специальные области применения (на фоне всех существующих).
SVZ>Ты смотришь на код с точки зрения программиста.
В большинстве случаев на код даже смотреть не требуется. Например, за несколько лет развития программы функциональность меняется не особо, объем возрастает на порядок-два, а скорость работы во столько же раз падает — это все видно невооруженным глазом.
SVZ>Пользователи твоих программ тоже удивляются, "до чего дошел прогресс".
Здравствуйте, Евгений Музыченко, Вы писали:
ЕМ>То есть, современные микросхемы превосходят микросхемы прошлых лет по всем параметрам. Я знаю только один параметр, который испортился с тех времен, да и то лишь для любителей — компоновка выводов. Расстояние между выводами уменьшилось настолько, что их невозможно паять без лупы и тонкого жала, а для BGA требуются специальные технологии пайки, но все это даже сугубый любитель может освоить за часы, а потребное оборудование стоит копейки.
ЕМ>И вот, когда на фоне всего этого смотрю на эволюцию ПО, так прям тоска берет.
Ну за это же время сложность ПО возросла на порядки, при хоть и упавшем качестве, но далеко не в той степени, в которой возросла сложность.
Хуже то, что софт становится всё более хрупким. Тогда была совершенно невозможной ситуация, когда ваш софт начинал падать из за того, что кто-то на каком-то сайте вообще не вашей фирмы изменит что-то в куске кода, который вы даже не видели. Всё было под контролем.
Ну и ещё раньще было сложно предстьавить, что сложность софта будет многократно возрастать только для того, чтобы показать то же самое, но с плавно выплывающими 3D картинками. Простота, надёжность и универсальность раньше были гораздо важнее внешней красивости. А теперь ровно наобророт.
Re[2]: Тенденции в развитии микроэлектроники и ПО :)
Здравствуйте, vsb, Вы писали:
vsb>Ну не знаю, я даже 10-летнию Idea с современной считаю несравнимой. А Github Codespaces для меня это просто космос, прорыв, фантастика, фильм из будущего. А если с 70-ми сравнивать, то это считай две разные цивилизации. Правда я в 70-е не жил, но подозреваю, тогда вообще на проводках программировали и жёсткие диски втроём носили самые сильные программисты.
На проводках не программировали, для этого перфокарты были
Жесткий диск емкостью в 29 Мбайт (я не ошибся, мегабайт) мог перенести любой программист.
А вот дисковод даже целой компанией поднять было сложно.
Здравствуйте, Евгений Музыченко, Вы писали:
ЕМ>Помнится, в 70-е бОльшую ЕМ>И вот, когда на фоне всего этого смотрю на эволюцию ПО, так прям тоска берет.
Мой отец работал программистом в 80е и раньше.
Как-то он смотрел как я работаю — прикручиваю к проекту либу.
Смотрел-смотрел, а потом не выдержал — говорит "фантастика". Не надо откуда-то доставать (под)программу, читать инструкцию по её использованию. Автодополнение есть (это его очень впечатлило), справка — мышкой наводишь и читаешь что она делает (а не идешь в библиотеку за книгой), билдитися сразу, не надо в очереди стоять чтобы программу на перфокартах набрали =)
Запускается сразу, результат видно сразу, а не не распечатке матричным принтером на рулоне.
Здравствуйте, Евгений Музыченко, Вы писали:
ЕМ>И вот, когда на фоне всего этого смотрю на эволюцию ПО, так прям тоска берет.
Ты не учитываешь один фактор.
Ни тогда, ни сейчас не было микроэлектроники, с которой должен был бы уметь работать каждый. Не нужно это было тогда и не нужно сейчас. С микроэлектроникой работают только те, кто имеет хоть какие-то познания в этой области.
Иными словами, это для профессионалов.
А в случае ПО произошло разделение. Есть ПО для профессионалов, и оно точно не стало хуже.
Не хуже современный Линукс, чем RSX-11 или Unix 1990-х годов. Лучше.
И Windows 11 внутри, не хуже Windows 95. Намного лучше.
А для массовой аудитории — да, что имеем, то и имеем. Но потому, что требования там определяются отнюдь не профессионалами, а они лишь делают по принципу "чего изволите".
Здравствуйте, L.K., Вы писали:
ЕМ>>И вот, когда на фоне всего этого смотрю на эволюцию ПО, так прям тоска берет.
LK>Какое ПО было в 70-е? Текстовый редактор, электронная почта, игрушка-змейка и бэйсик? Это если говорить об IBM 5100 или Apple 1-2.
В 88 по для автоматической посадки бурана успешно функционировало.
Здравствуйте, Евгений Музыченко, Вы писали:
ЕМ>И вот, когда на фоне всего этого смотрю на эволюцию ПО, так прям тоска берет.
Смысл ПО в том, чтобы можно было делать ошибки как можно быстрее, и как можно быстрее их исправлять. Это значит, что в любой момент времени ширпотребное ПО содержит ошибки. Это свойство ПО, которое невозможно преодолеть, потому что практически весь прогресс в ИТ был возможен из-за того, что на порядок большее количество людей (по сравнению с разработчиками элементной базы и вообще железа) делали ошибки, наступали на грабли, и исправляли только те из них, которые были достаточно критичны.
Re[3]: Тенденции в развитии микроэлектроники и ПО :)
LK>>Какое ПО было в 70-е? Текстовый редактор, электронная почта, игрушка-змейка и бэйсик? Это если говорить об IBM 5100 или Apple 1-2. _>В 88 по для автоматической посадки бурана успешно функционировало.
Ага. Только тогда это была сверх-задача для ведущих институтов сверхдержавы на 10+ лет. Из-за жесточайших ограничений, требований космической надёжности и убогой элементной базы приходилось придумывать гениальные решения, которые потом в обычной промышленности оказались либо неприменимы совсем, либо слишком дороги для использования. А сейчас полёт и посадка на автопилоте — это примерно задача диплома топового вуза. Или курсовой, если ограничиться только виртуальной моделькой и в железе не делать.
Если же взять коллектив и заморочиться на год-два, то можно сделать систему из 2-х нейросетей, одна из которых пытается слетать и сесть, а вторая максимально усложняет задачу, ломая аппарат и заливая подбранную "структурированную дезинформацию" в 1/3 датчиков. По итогу будет "условный Буран" не просто садиться, а подавляемый РЭБ, под обстрелом, без хвоста и на половине крыла. Типа как тут ИИ выдержал "вспышку справа":
Здравствуйте, L.K., Вы писали:
LK>Какое ПО было в 70-е? Текстовый редактор, электронная почта, игрушка-змейка и бэйсик? Это если говорить об IBM 5100 или Apple 1-2. LK>А сейчас цветные картинки, FullHD-видео, прямые трансляции, интерактивные сайты с яваскриптом.
Давай лучше сравним с тем, что было 20 лет назад.
Ад пуст, все бесы здесь.
Re[3]: Тенденции в развитии микроэлектроники и ПО :)
Диск с верхнего фото, по-моему 5 а не 29МВ, а дисководы с нижнего, таки да 29 МВ. И тетки-операторы (ЕС1035) весьма радовались тому, что программисты ( в основном 20+ пацаны) меняли диски сами.
Re[3]: Тенденции в развитии микроэлектроники и ПО :)
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>На проводках не программировали, для этого перфокарты были PD>Жесткий диск емкостью в 29 Мбайт (я не ошибся, мегабайт) мог перенести любой программист.
PD>Image: images
Это 7MB (привод ЕС5050 == IBM 2311, диск IBM 1316), не путайте.
7MB диски это такие, от которых пластины использовали как антенны телевидения: http://rsdn.org//forum/philosophy/8156327
Здравствуйте, vsb, Вы писали:
vsb>Ну не знаю, я даже 10-летнию Idea с современной считаю несравнимой. А Github Codespaces для меня это просто космос, прорыв, фантастика, фильм из будущего. А если с 70-ми сравнивать, то это считай две разные цивилизации.
И что из этого было технически невозможно в 70-е? Тогда даже распределенные сети были, только медленные и не глобальные.
vsb>Правда я в 70-е не жил
С этого и нужно начинать. Вообще, очень полезно иметь хотя бы общее представление о том, как что делалось в разные времена и эпохи.
Re[2]: Тенденции в развитии микроэлектроники и ПО :)
Здравствуйте, vmpire, Вы писали:
V>Ну за это же время сложность ПО возросла на порядки
На порядки — не возросла, максимум — в разы. В те времена хватало сложного ПО, которое сообща делали сотни людей из разных организаций.
V>при хоть и упавшем качестве, но далеко не в той степени, в которой возросла сложность.
А вот ресурсы, потребные для работы ПО, возросли как раз на порядки, очень сильно опережая рост сложности.
V>Хуже то, что софт становится всё более хрупким. Тогда была совершенно невозможной ситуация, когда ваш софт начинал падать из за того, что кто-то на каком-то сайте вообще не вашей фирмы изменит что-то в куске кода, который вы даже не видели. Всё было под контролем.
Ничего подобного. Тогда софт мог падать даже из-за того, что в машине/периферии заменили блок (что на больших машинах случалось практически ежедневно), и у нового оказались немного другие временнЫе характеристики. Чтоб система неделями исправно работала без присмотра, было редкостью.
V>Ну и ещё раньще было сложно предстьавить, что сложность софта будет многократно возрастать только для того, чтобы показать то же самое, но с плавно выплывающими 3D картинками. Простота, надёжность и универсальность раньше были гораздо важнее внешней красивости.
Вот это верно. И ладно бы, если б дело было только в картинках. Во многих случаях это напоминает изготовление в течение недели инструмента, который сэкономит минуту времени, но потребует часа на освоение. Такое оправдано в крупносерийном производстве, но в производстве ПО эта экономия в итоге размазывается по всем производителям, и конечный эффект редко получается критичным.
Re[3]: Тенденции в развитии микроэлектроники и ПО :)
Здравствуйте, Евгений Музыченко, Вы писали:
ЕМ>И что из этого было технически невозможно в 70-е? Тогда даже распределенные сети были, только медленные и не глобальные.
Хотя бы развитый GUI? И дисплеи с графическим железом были слабоваты. И сами GUI, их технология ПО тогда была в зачаточном состоянии. Между прочим, дабы создавать навороченные GUI, нужно объектно-ориентированное программирование. Которое тогда только зарождалось.
Re[5]: Тенденции в развитии микроэлектроники и ПО :)
Здравствуйте, Евгений Музыченко, Вы писали:
ЕМ>У микросхем не бывает таких юзеров, как у программ, это не конечные изделия. Можно сказать, что я смотрю на них, скажем, с позиции прикладного программиста на функции API. Но при этом у типичного программиста на функции API обычно возникает куда больше матов, чем у конструктора аппаратуры — на микросхемы.
ЕМ>А когда я смотрю на ПО с позиции конечного юзера, мне регулярно приходится вникать в подробности вроде "встанет ли Win10 на этот ноутбук, а Win7 — на тот", "потребует ли новая версия этого софта обновления .NET, IE или установки обновлений ОС", "смогу ли я открыть все свои любимые сайты, поменяв или обновив браузер" и т.п.
Ага, ага. Этому подтяни вход к плюсу, этому не подтягивай, потому что будет постоянная утечка. У этого питание и уровень единицы +5, у этого +3, у этого +1, у этого +12. Этому надо подавать входы только через on-delay буфер, иначе от любой неустойчивости фронта делает лишние движения. C этим общайся через SPI, с этим через I2C. У этого нельзя заменить один параметр настройки, можно только всё переинициализировать с нуля, и во время этого процесса ничего не работает и на выходах херня. И так далее.
Даже я, сам ничего не проектировавший, наслушался/начитался таких ситуаций под сотню.
И ещё и отладка — логов не добавить, отладчиком не остановить, снимай диаграммы в конкретных местах и ищи иголки осциллографом (а они происходят один раз на миллион).
Про ресурсы я более-менее согласен, но вот мышление железячников, особенно в области как управлять цифровыми элементами, это что-то за пределами цензуры.
ЕМ>В большинстве случаев на код даже смотреть не требуется. Например, за несколько лет развития программы функциональность меняется не особо, объем возрастает на порядок-два, а скорость работы во столько же раз падает — это все видно невооруженным глазом.
Это ещё разработчики не привыкли, что рост железных ресурсов реально прекратился.
The God is real, unless declared integer.
Re[3]: Тенденции в развитии микроэлектроники и ПО :)
Здравствуйте, Евгений Музыченко, Вы писали:
O>>На входе в электронику есть хотя бы фильтр на умение держать инструмент.
ЕМ>Да это ж элементарщина, осваивается за минуты.
Месяцы, на то, чтобы освоить движения и совершить все типовые ошибки, как случайно закоротить питание (сожгя дорожки), воткнуть микруху строго наоборот, или не рассчитать сопротивление резистора и получить яркий, но быстро сгоревший светодиод. Даже на просто натренироваться не попадать паяльником на соседний контакт — уже много попыток.
EM>Появились корпуса SSOP с шагом выводов 0.65 мм — достаточно было взять лупу и заточить жало, и все, можно паять.
Во-во. Ты не замечаешь, что без тренировки руки вполне дрожат на миллиметр-два при любом напряжении. А тут про шаг 0.65мм (то есть надо иметь точность 0.2мм, чтобы гарантированно не дёрнуться на соседний). Ну да, привык с юности, я понимаю.
ЕМ>Да, а еще микросхема для развязки подключения к Ethernet не будет сливать через него производителю статистику о стабильности температуры и напряжения питания. Хотя наиболее сложные процессоры это уже умеют.
Во-во. Ты уже не знаешь, что там внутри и что когда оно передаст.
ЕМ>А в софте как? Вышла новая версия — какие-то ОС или мониторы больше не поддерживаются, требуется обновление фреймворка X и библиотеки Y (при этом другой софт как раз не будет работать с обновленными, поэтому придется поставить в параллель)...
Новый процессор, SPI воткнули, I2C (для примера) убрали. Судорожно ищешь переходник и разбираешься, как его подключатьт (нетривиально)...
The God is real, unless declared integer.
Re[5]: Тенденции в развитии микроэлектроники и ПО :)
Здравствуйте, Евгений Музыченко, Вы писали:
SVZ>>Поэтому ты смотришь на микросхемы с позиции юзера.
ЕМ>У микросхем не бывает таких юзеров, как у программ, это не конечные изделия. Можно сказать, что я смотрю на них, скажем, с позиции прикладного программиста на функции API. Но при этом у типичного программиста на функции API обычно возникает куда больше матов, чем у конструктора аппаратуры — на микросхемы.
Вполне себе изделия, а юзеры у них простые инженеры-электронщики. И ты не знаешь, сколько матов иногда складывают на эти изделия
ЕМ>А когда я смотрю на ПО с позиции конечного юзера, мне регулярно приходится вникать в подробности вроде "встанет ли Win10 на этот ноутбук, а Win7 — на тот", "потребует ли новая версия этого софта обновления .NET, IE или установки обновлений ОС", "смогу ли я открыть все свои любимые сайты, поменяв или обновив браузер" и т.п.
Число errata документов на на контроллеры STM32 исчисляется тысячами, если что
SVZ>>А если бы были спроектированы правильно, то имели бы энергопотребление еще на порядок меньше.
ЕМ>Для большинства это вряд ли имеет смысл — все равно типичный миллиамперметр показывает нули, нужен специальный.
А типичный микроамперметр — покажет. Когда у нас в устройстве под полсотни плат, и как минимум на половине есть STMки со всякими периферийными чипами-датчиками, вопрос энергопотребления становится весьма заметным
Здравствуйте, Евгений Музыченко, Вы писали:
A>>Возможно, дела так обстоят потому, что микросхема — материальный объект. A>>Не только производство каждого экземпляра стоит денег, но и подготовка производства тоже.
ЕМ>При всем этом микросхемы стоят сущие копейки, даже в рознице не так много моделей дороже доллара. Повышение цены на единицы центов значимо не влияет на стоимость конечных изделий — только на доходы эффективных менеджеров, которые в компания занимаются оптимизацией производства.
Копейки — они такие копейки. Некоторые STMки, которые мы раньше брали мешками по ценам меньше бакса, сейчас в чип дипе под сотню бакинских стоят
ЕМ>А в софте как? Вышла новая версия — какие-то ОС или мониторы больше не поддерживаются, требуется обновление фреймворка X и библиотеки Y (при этом другой софт как раз не будет работать с обновленными, поэтому придется поставить в параллель)...
"Ваша прошивка ST-Link устарела и может не поддерживать некоторые возможности. Обновить?"
А потом — опа, и что-то отвалилось. А обратно уже и не вернуть...
Здравствуйте, vsb, Вы писали:
ЕМ>>И вот, когда на фоне всего этого смотрю на эволюцию ПО, так прям тоска берет.
vsb>Ну не знаю, я даже 10-летнию Idea с современной считаю несравнимой. А Github Codespaces для меня это просто космос, прорыв, фантастика, фильм из будущего.
А что это за зверь?
Не, я конечно могу погуглить, но раз ты уж упомянул, может не затруднит хоть коротенько рассказать, чем оно тебя восхитило?
Здравствуйте, Евгений Музыченко, Вы писали:
vsb>>Ну не знаю, я даже 10-летнию Idea с современной считаю несравнимой. А Github Codespaces для меня это просто космос, прорыв, фантастика, фильм из будущего. А если с 70-ми сравнивать, то это считай две разные цивилизации.
ЕМ>И что из этого было технически невозможно в 70-е? Тогда даже распределенные сети были, только медленные и не глобальные.
Ну хз, взять тот же P-CAD начала 90ых и Altium 19 — небо и земля
Здравствуйте, kov_serg, Вы писали:
ЕМ>>>И вот, когда на фоне всего этого смотрю на эволюцию ПО, так прям тоска берет.
LK>>Какое ПО было в 70-е? Текстовый редактор, электронная почта, игрушка-змейка и бэйсик? Это если говорить об IBM 5100 или Apple 1-2. _>В 88 по для автоматической посадки бурана успешно функционировало.
Сейчас такое ПО мой коллега в симуляторе своём напишет и отладит за месяц, прошьёт в STM32 и оно может лететь в космос. И это на современном софте. Но коллега крут, у него наколбашен какой-то фреймворк вокруг каких-то открытых симуляторов, у него физика/электродинамика/и тп там моделируется. Для Бурана прошивку, конечно, может и не месяц, а подольше придётся делать, два-три
Здравствуйте, Евгений Музыченко, Вы писали:
SVZ>>(и офигенное энергопотребление) ЕМ>Это где? Подавляющее большинство микросхем имеет энергопотребление на порядки ниже тех, что были в 70-80-х.
Нет. Как была CMOS логика, так и осталась. И скорей даже больше. Уменьшились потери на переключение,
но увеличились статические потери.
И да, у операционников всё так же нуль плавает в широких пределах... Может не в таких широких,
но эффект заметен глазом.
SVZ>>только для того, чтобы компенсировать криворукость радиоконструктора.
ЕМ>Если Вы про процессоры/контроллеры, то компенсируется криворукость не конструктора, а исключительно программиста. С теми методами программирования, что применялись в 70-х, сейчас элементарно достичь и предельной компактности, и чрезвычайно низкого энергопотребления.
Чушь. За методы программирования из 70-х нужно, считаю, нужно лишать QR-кода и
отправлять куда-нибудь в Омск... Между нормальным программированием и поделками
а-ля ранний юникс -- гигантская пропасть. Как и между первыми ламповыми приёмниками
прямого усиления и современным цифровым приёмником в GSM-телефоне, например.
Точно так же, как есть прогресс в электронике, есть прогресс и в технологиях создания ПО.
За последние 20 лет он по-моему виден явственно. Точно так же как в чипе появились сотни тысяч
транзисторов, так же и объёмы ПО и сложность выросли на порядки. И точно так же готовые
библиотеки/фреймворки легко применять как и микросхемы...
ЕМ>Сколько Вы знаете конструкторов электроники, которые начинали в 70-80-х, и сейчас были бы недовольны тенденциями развития отрасли? А таких же программистов?
Эти недовольные программисты может безнадёжно отстали от реальности в своих 70-х?
Re[3]: Тенденции в развитии микроэлектроники и ПО :)
Здравствуйте, Marty, Вы писали:
M>Не, я конечно могу погуглить, но раз ты уж упомянул, может не затруднит хоть коротенько рассказать, чем оно тебя восхитило?
VScode в браузере, часть выполняется на удалённом сервере (анализ кода и тд). При этом всё, связанное с разработкой проекта хранится в контейнерах, также запускаясь на удалённо сервере.
Т.е. для программиста это выглядит так: взял любой компьютер, зашёл на гитхаб-репозиторий, нажал Codespaces и у тебя открылась IDE с того места, где ты её прошлый раз закрыл (ну или с начала, если ты первый раз открыл). У тебя настроены все окружения, т.е. ты следующим же нажатием кнопки можешь собрать и запустить проект с нужными окружениями, зависимостями и тд.
Это решит прям кучу боли лично для меня.
Re[4]: Тенденции в развитии микроэлектроники и ПО :)
Здравствуйте, vsb, Вы писали:
vsb>VScode в браузере, часть выполняется на удалённом сервере (анализ кода и тд). При этом всё, связанное с разработкой проекта хранится в контейнерах, также запускаясь на удалённо сервере.
vsb>Т.е. для программиста это выглядит так: взял любой компьютер, зашёл на гитхаб-репозиторий, нажал Codespaces и у тебя открылась IDE с того места, где ты её прошлый раз закрыл (ну или с начала, если ты первый раз открыл). У тебя настроены все окружения, т.е. ты следующим же нажатием кнопки можешь собрать и запустить проект с нужными окружениями, зависимостями и тд.
vsb>Это решит прям кучу боли лично для меня.
А, ну хз, не моё, значит. В робота прошивку оно не зальёт и из кулемета по моей команде стрелять не будет
Здравствуйте, Marty, Вы писали:
M>Некоторые STMки, которые мы раньше брали мешками по ценам меньше бакса, сейчас в чип дипе под сотню бакинских стоят
Это ведь гипербола?
Неужто реально такая разница — 2 порядка? А чем хотя бы объясняется — чисто розница/опт?
Re[4]: Тенденции в развитии микроэлектроники и ПО :)
Здравствуйте, Marty, Вы писали:
M>Копейки — они такие копейки. Некоторые STMки, которые мы раньше брали мешками по ценам меньше бакса, сейчас в чип дипе под сотню бакинских стоят
Я с ними вживую не сталкивался, но по отзывам, чип-и-дип всегда обожал накручивать в разы на ровном месте, а сейчас так вообще. Есть более вменяемые ценовые источники?
The God is real, unless declared integer.
Re[4]: Тенденции в развитии микроэлектроники и ПО :)
Здравствуйте, jamesq, Вы писали:
J>Хотя бы развитый GUI? И дисплеи с графическим железом были слабоваты. И сами GUI, их технология ПО тогда была в зачаточном состоянии. Между прочим, дабы создавать навороченные GUI, нужно объектно-ориентированное программирование. Которое тогда только зарождалось.
Именно для этого и зарождалось. Крайне рекомендую к прочтению мемуары Alan C. Key: https://www.researchgate.net/publication/221501755_The_Early_History_of_Smalltalk
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[5]: Тенденции в развитии микроэлектроники и ПО :)
Здравствуйте, Михаил Романов, Вы писали:
M>>Некоторые STMки, которые мы раньше брали мешками по ценам меньше бакса, сейчас в чип дипе под сотню бакинских стоят МР>Это ведь гипербола?
Нет, это натурально так. Хотя, это конечно отдельный пример, некоторые чипы подорожали до 10-20 бакинских
МР>Неужто реально такая разница — 2 порядка? А чем хотя бы объясняется — чисто розница/опт?
Кризис производства микроэлектроники. На некоторые позиции, которые можно было в любом киоске купить, сейчас предзаказ на полгода
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Здравствуйте, vsb, Вы писали:
vsb>>Ну не знаю, я даже 10-летнию Idea с современной считаю несравнимой. А Github Codespaces для меня это просто космос, прорыв, фантастика, фильм из будущего. А если с 70-ми сравнивать, то это считай две разные цивилизации. Правда я в 70-е не жил, но подозреваю, тогда вообще на проводках программировали и жёсткие диски втроём носили самые сильные программисты.
PD>На проводках не программировали, для этого перфокарты были PD>Жесткий диск емкостью в 29 Мбайт (я не ошибся, мегабайт) мог перенести любой программист.
PD>Image: images
Блин, вот как раз второй я на ногу и уровнил себе. Не защелкнулся замок в крышке, когда вынимал его для замены.
Его потом на диски для телевизионных антенн отдали студентам, ибо погнулись нижние пластины.
Re[4]: Тенденции в развитии микроэлектроники и ПО :)
Здравствуйте, jamesq, Вы писали:
ЕМ>>И что из этого было технически невозможно в 70-е?
J>Хотя бы развитый GUI?
GUI в те времена вполне себе существовал — с управлением через трекбол, световое перо, или просто стрелки навигации. Не такой навороченный, как сейчас, но это чисто количественная разница, никак не объясняющая рост требований к ресурсам на несколько порядков.
J>дабы создавать навороченные GUI, нужно объектно-ориентированное программирование. Которое тогда только зарождалось.
Объектно-ориентированное программирование достаточно просто реализуется на любом языке, имеющем указатели и записи/структуры. Не так красиво и надежно, как на специализированных языках, но особой сложности в этом нет.
Re[6]: Тенденции в развитии микроэлектроники и ПО :)
Здравствуйте, netch80, Вы писали:
N>Этому подтяни вход к плюсу, этому не подтягивай, потому что будет постоянная утечка.
У этого метода умолчание для необязательного параметра — нуль, у того — 10, а еще у одного — пустая строка. У этого шаблона тип параметра по умолчанию — целый, у того — плавающий.
N>У этого питание и уровень единицы +5, у этого +3, у этого +1, у этого +12.
У этого языка параметры вызова передаются через стек, у того — через регистры, еще у одного — через динамическую память.
N>У этого нельзя заменить один параметр настройки, можно только всё переинициализировать с нуля, и во время этого процесса ничего не работает и на выходах херня.
Вот уж чего в софте сплошь и рядом.
N>Даже я, сам ничего не проектировавший, наслушался/начитался таких ситуаций под сотню.
Даже беглое гугление таких ситуаций в софте дает тысячи жалоб.
N>И ещё и отладка — логов не добавить, отладчиком не остановить
Это уже совсем какие-то древности. В любом микроконтроллере есть UART, через который можно выводить логи, а во многих — и JTAG, через который можно трассировать пошагово.
N>мышление железячников, особенно в области как управлять цифровыми элементами, это что-то за пределами цензуры.
Например?
N>Это ещё разработчики не привыкли, что рост железных ресурсов реально прекратился.
Они теперь и не привыкнут. Будут изобретать костыли и уверять, что при меньших ресурсах работать физически не сможет.
Re[4]: Тенденции в развитии микроэлектроники и ПО :)
Здравствуйте, Marty, Вы писали:
M>Число errata документов на на контроллеры STM32 исчисляется тысячами
А какой части разработчиков реально приходится их читать?
M>А типичный микроамперметр — покажет. Когда у нас в устройстве под полсотни плат, и как минимум на половине есть STMки со всякими периферийными чипами-датчиками, вопрос энергопотребления становится весьма заметным
Что за устройство с полусотней плат, в котором потребление долей миллиампера каждой платой становится заметным?
Re[4]: Тенденции в развитии микроэлектроники и ПО :)
Здравствуйте, fk0, Вы писали:
fk0>За методы программирования из 70-х нужно, считаю, нужно лишать QR-кода и отправлять куда-нибудь в Омск... Между нормальным программированием и поделками а-ля ранний юникс -- гигантская пропасть.
У Вас неверная информация. Ранний юникс (как и бОльшая часть юникса вообще) — это наколенные поделки энтузиастов лично для себя, которые по стечению обстоятельств становились достоянием публики. И в 70-х, и даже в 60-х было достаточно "нормального программирования".
fk0>Точно так же как в чипе появились сотни тысяч транзисторов, так же и объёмы ПО и сложность выросли на порядки.
Хохма в том, что сейчас полно чипов, в которых всего лишь десятки-сотни транзисторов. А откройте какой-нибудь Google Play — там полно откровенно примитивных софтов объемом в 10-20-50 Мб. Если поискать, то можно найти функционально эквивалентные (а то и более технически навороченные) объемом в 200-500-700 кб.
fk0>И точно так же готовые библиотеки/фреймворки легко применять как и микросхемы...
Их легко применять, если не смотреть, что получается в итоге, и как оно работает. А сколько Вы знаете микросхем, которые принципиально не умеют работать, не имея рядом других, строго определенных, микросхем?
fk0>Эти недовольные программисты может безнадёжно отстали от реальности в своих 70-х?
Если под "реальностью" понимать то, что хавает пипл, то да, безнадежно отстали.
Re[4]: Тенденции в развитии микроэлектроники и ПО :)
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Ни тогда, ни сейчас не было микроэлектроники, с которой должен был бы уметь работать каждый. Не нужно это было тогда и не нужно сейчас. С микроэлектроникой работают только те, кто имеет хоть какие-то познания в этой области.
Вот именно, что "какие-то". Чтобы накидать несложную схемку с датчиками и исполнительными устройствами для Arduino, а потом накидать скетч для управления всем этим, достаточно самых общих познаний, а получится не намного хуже, чем у профессионального разработчика. А ведь ATMega, по нынешним временам — очень простенький МК, где-то на уровне 80286. Если при таких же общих познаниях делать софт для десктопа или мобильника, то получится ужас — неимоверно толстый, и столь же тормозной.
PD>Есть ПО для профессионалов, и оно точно не стало хуже.
Это которое? Я знаю лишь несколько примеров. У большинства "софта для профессионалов" объемы и тормоза растут в несколько раз быстрее функциональности, удобства и надежности.
PD>Не хуже современный Линукс, чем RSX-11 или Unix 1990-х годов. Лучше.
Я не вникал глубоко в современный Линукс, но то, на что обращал внимание, представляло собой изрядный зоопарк — главным образом по причине разрозненности разработчиков. Тот же RSX-11 делала одна команда, поэтому он отличался изрядной стройностью.
PD>И Windows 11 внутри, не хуже Windows 95. Намного лучше.
Я бы сказал, что обе плохие. В 95 осталось много старого 16-разрядного кода, а в 10-11 накопилось много того, что наскоро приделывалось сбоку.
Re[2]: Тенденции в развитии микроэлектроники и ПО :)
Здравствуйте, L.K., Вы писали:
LK>Какое ПО было в 70-е? Текстовый редактор, электронная почта, игрушка-змейка и бэйсик? Это если говорить об IBM 5100 или Apple 1-2.
А зачем говорить о настольных ПК, которые в те времена считались просто игрушками, малополезными для серьезной работы?
LK>А сейчас цветные картинки, FullHD-видео, прямые трансляции, интерактивные сайты с яваскриптом.
При наличии достаточных вычислительных мощностей и объемов памяти, все это можно было сделать и в 70-е — примерно в сто-тысячу раз эффективнее. Собственно, и сейчас можно сделать, просто это мало кого интересует.
Re[7]: Тенденции в развитии микроэлектроники и ПО :)
Здравствуйте, Евгений Музыченко, Вы писали:
M>>Число errata документов на на контроллеры STM32 исчисляется тысячами
ЕМ>А какой части разработчиков реально приходится их читать?
Плюс минус — всем
M>>А типичный микроамперметр — покажет. Когда у нас в устройстве под полсотни плат, и как минимум на половине есть STMки со всякими периферийными чипами-датчиками, вопрос энергопотребления становится весьма заметным
ЕМ>Что за устройство с полусотней плат, в котором потребление долей миллиампера каждой платой становится заметным?
Любая самоходная телега нашего производства
Ну, и про доли мА ты загнул таки. Единицы мА, если не десятки
Здравствуйте, Евгений Музыченко, Вы писали:
M>>"Ваша прошивка ST-Link устарела и может не поддерживать некоторые возможности. Обновить?"
ЕМ>Может, или действительно не поддерживает?
Точно не помню, но меня как-то раз оно так поймало
Здравствуйте, Евгений Музыченко, Вы писали:
vsb>>для программиста это выглядит так: взял любой компьютер, зашёл на гитхаб-репозиторий, нажал Codespaces
ЕМ>И тут внезапно пропал интернет...
Современный программист без интернета программировать не может в любом случае.
Re[5]: Тенденции в развитии микроэлектроники и ПО :)
Здравствуйте, Евгений Музыченко, Вы писали:
N>>Новый процессор, SPI воткнули, I2C (для примера) убрали.
ЕМ>А старый одновременно перестали и выпускать, и поддерживать?
Здравствуйте, Евгений Музыченко, Вы писали:
ЕМ>Вот именно, что "какие-то". Чтобы накидать несложную схемку с датчиками и исполнительными устройствами для Arduino, а потом накидать скетч для управления всем этим, достаточно самых общих познаний, а получится не намного хуже, чем у профессионального разработчика. А ведь ATMega, по нынешним временам — очень простенький МК, где-то на уровне 80286. Если при таких же общих познаниях делать софт для десктопа или мобильника, то получится ужас — неимоверно толстый, и столь же тормозной.
На ардуинке делал скетч, чтобы шаговиком шагать. Получилось выжать шагов 200 в минуту.
На STMке с аппаратным таймером — выжал 5-6 тысяч в секунду, мог и больше, но мотор шаги стал пропускать
Здравствуйте, Евгений Музыченко, Вы писали:
ЕМ>Вот именно, что "какие-то". Чтобы накидать несложную схемку с датчиками и исполнительными устройствами для Arduino, а потом накидать скетч для управления всем этим, достаточно самых общих познаний, а получится не намного хуже, чем у профессионального разработчика.
Аналогом из мира софта будет программка, накиданная на дельфях или VB. Тоже достаточно самых общих познаний.
Она так же будет шевелиться, что-то делать полезное.
И тоже получится не намного хуже, чем у профессионального разработчика.
_____________________
С уважением,
Stanislav V. Zudin
Re[5]: Тенденции в развитии микроэлектроники и ПО :)
Здравствуйте, Евгений Музыченко, Вы писали:
ЕМ>Здравствуйте, jamesq, Вы писали:
ЕМ>>>И что из этого было технически невозможно в 70-е?
J>>Хотя бы развитый GUI?
ЕМ>GUI в те времена вполне себе существовал — с управлением через трекбол, световое перо, или просто стрелки навигации. Не такой навороченный, как сейчас, но это чисто количественная разница, никак не объясняющая рост требований к ресурсам на несколько порядков.
У меня на спектруме экран был 192 на 256 пикселов с глубиной 1 бит. = 6144 байт + цвета задавались на каждый квадратик 8x8 — это еще 768 байт итого 6912 байт
Сейчас у меня 2 монитора 3840 на 2160 с глубиной цвета 3 байта на пиксел = 49 766 400 байт
это в 7200 раз больше (!) — и это мы сравниваем с безумной по тем временам роскошью — графическим режимом.
В 90-е большая часть GUI работала в текстовом режиме
Здравствуйте, vsb, Вы писали:
vsb>Современный программист без интернета программировать не может в любом случае.
Я могу программировать без интернета, пока не возникнет проблемы, трудноразрешимой с имеющейся информацией. Для разрешения можно воспользоваться интернетом, но далеко не всегда там можно найти решение. Своими силами решение можно найти всегда, но это может потребовать неприемлемого времени.
Но во многих случаях таких проблем не возникает, и интернет может не потребоваться вообще.
Re[6]: Тенденции в развитии микроэлектроники и ПО :)
Здравствуйте, Marty, Вы писали:
ЕМ>>А старый одновременно перестали и выпускать, и поддерживать?
M>Выпускать — да, перестали. Такое бывает. M>Поддерживать — это как?
Например, разыскали старые версии по всем складам, и уничтожили их. Или в старой версии были глюки, с которыми ее было невозможно использовать, и они были исправлены одновременно с переходом на новую версию.
Re[4]: Тенденции в развитии микроэлектроники и ПО :)
Здравствуйте, Евгений Музыченко, Вы писали:
ЕМ>>>А старый одновременно перестали и выпускать, и поддерживать?
M>>Выпускать — да, перестали. Такое бывает. M>>Поддерживать — это как?
ЕМ>Например, разыскали старые версии по всем складам, и уничтожили их. Или в старой версии были глюки, с которыми ее было невозможно использовать, и они были исправлены одновременно с переходом на новую версию.
Здравствуйте, Евгений Музыченко, Вы писали:
M>>На ардуинке делал скетч, чтобы шаговиком шагать. Получилось выжать шагов 200 в минуту.
ЕМ>Как-то совсем уж мало, это чуть больше трех шагов в секунду, или пять миллионов команд на шаг. Там точно все было минимизировано?
Да, мало. Там, правда, ещё было сканирование матричной клавы, логика меню и дисплей 1602, но сути это особо менять не должно. Ну и само собой, всё было сделано на ардуиновских либах, ничего я там не оптимизировал.
А на STM — у меня всё своё было, три шаговика, с обсчётом перемещения по трем осям, с учетом ускорений, и выдавало 5-6 килогерц на каждый движек
Здравствуйте, Евгений Музыченко, Вы писали:
ЕА>>У меня на спектруме экран был 192 на 256 пикселов с глубиной 1 бит.
ЕМ>Вы действительно полагаете, что во времена спектрумов другой вычислительной техники не существовало?
Во времена поздних спектрумов — существовало. Когда он только появился — было сильно похуже
Здравствуйте, Marty, Вы писали:
ЕМ>>Вы действительно полагаете, что во времена спектрумов другой вычислительной техники не существовало?
M>Во времена поздних спектрумов — существовало. Когда он только появился — было сильно похуже
Вы тоже никогда не слышали об IBM 360/370, БЭСМ-6 и прочих серьезных системах?
Re[6]: Тенденции в развитии микроэлектроники и ПО :)
Здравствуйте, Marty, Вы писали:
M>Не понял, а причем тут какая-то поддержка?
При том, что софту часто требуется доработка при переходе на другое железо или версию ОС, хотя формально все совместимо. У большинства микросхем такой проблемы нет, поэтому и поддержка по факту не требуется.
Re[9]: Тенденции в развитии микроэлектроники и ПО :)
Здравствуйте, Евгений Музыченко, Вы писали:
ЕМ>>>Вы действительно полагаете, что во времена спектрумов другой вычислительной техники не существовало?
M>>Во времена поздних спектрумов — существовало. Когда он только появился — было сильно похуже
ЕМ>Вы тоже никогда не слышали об IBM 360/370, БЭСМ-6 и прочих серьезных системах?
Слышали. Чутка побыстрее, зато весили сотни кг и стоили тонны нефти
Здравствуйте, Евгений Музыченко, Вы писали:
M>>Не понял, а причем тут какая-то поддержка?
ЕМ>При том, что софту часто требуется доработка при переходе на другое железо или версию ОС, хотя формально все совместимо. У большинства микросхем такой проблемы нет, поэтому и поддержка по факту не требуется.
Да как бы не так. Те же STMки — вроде бы во многом совместимы между собой, но перепиливать из-под одной под другую — то ещё развлечение. И есть какой-нибудь SPL, которая вроде бы должна нивелировать различия, но, внезапно, в нецй имена одних и тех же по смыслу констант — немножко блджад разные. И вот когда ты вроде перепилил, и оно вроде бы даже собирается, внезапно обнаруживается, что на новом проце — новые баги, и идешь искать эррату и искать воркэраунды.
Я уж не говорю про какие-нибудь сенсоры по шине SPI/I2C — вроде одна буковка отличается, и шина та же, а работает всё по другому
Здравствуйте, Евгений Музыченко, Вы писали:
M>>всё было сделано на ардуиновских либах, ничего я там не оптимизировал.
ЕМ>То есть, проблема снова в софте. Сама по себе ATMega328 выдает 16 млн оп/с, для подобных задач этого достаточно по уши.
Я отвечал на
Вот именно, что "какие-то". Чтобы накидать несложную схемку с датчиками и исполнительными устройствами для Arduino, а потом накидать скетч для управления всем этим, достаточно самых общих познаний, а получится не намного хуже, чем у профессионального разработчика. А ведь ATMega, по нынешним временам — очень простенький МК, где-то на уровне 80286. Если при таких же общих познаниях делать софт для десктопа или мобильника, то получится ужас — неимоверно толстый, и столь же тормозной.
"накидать скетч для управления всем этим, достаточно самых общих познаний, а получится не намного хуже, чем у профессионального разработчика" — получится говно
Хотя на атмеге и фрезеры и 3д принтеры делают. Я, кстати, свой 3д станок сделал на сотке 24 мгц, не сильно быстрее атмеги, единственно, что у STM вроде периферия получше развита
Здравствуйте, Marty, Вы писали:
M>Чутка побыстрее, зато весили сотни кг и стоили тонны нефти
И как это соотносится с заявлениями о том, что с техникой и методами программирования 70-х было якобы принципиально невозможно большинство современных технологий и решений?
Re[11]: Тенденции в развитии микроэлектроники и ПО :)
Здравствуйте, Евгений Музыченко, Вы писали:
ЕМ>И как это соотносится с заявлениями о том, что с техникой и методами программирования 70-х было якобы принципиально невозможно большинство современных технологий и решений?
Если придраться к гую, то стоит вспомнить, что умел гуй 30 лет назад (про 70-е говорить нечего) и сейчас.
Благодаря современным мощностям и объемам памяти появилась возможность что-то предвычислять и перестраивать в фоне, пока пользователь пытается чего-то напечатать/нарисовать.
Всякий Intellicence, Autocomplete.
То, что раньше делалось в формате "запустил задачу и пошел курить" сейчас превратилось в настоящее интерактивное редактирование.
Т.е. сложность и возможности гуя выросли на несколько порядков.
Если раньше гуй был ориентирован на профи, требующий предварительного обучения, то сейчас всё значительно упрощается и сводит обучение к минимуму.
Правда, последние лет десять я что-то не вижу серьезной научной работы в гуестроении — всё больше дизайнеры косметику наводят.
Ну и повышение сложности неизбежно ведет к увеличению числа ошибок. Эта проблема применима ко всем отраслям — что к софту, что к железу.
_____________________
С уважением,
Stanislav V. Zudin
Re[12]: Тенденции в развитии микроэлектроники и ПО :)
Здравствуйте, Stanislav V. Zudin, Вы писали:
SVZ>стоит вспомнить, что умел гуй 30 лет назад (про 70-е говорить нечего) и сейчас.
Говоря о том, что гуй умеет сейчас, не стоит забывать, что изрядное количество свойств добавлено исключительно из эстетических целей. Они не ускоряют работу, не делают ее более надежной или безопасной, они просто забавляют и радуют глаз. Их появление стало возможным только из-за избытка дешевых ресурсов, раньше в них попросту не видели никакого смысла.
SVZ>Благодаря современным мощностям и объемам памяти появилась возможность что-то предвычислять и перестраивать в фоне, пока пользователь пытается чего-то напечатать/нарисовать.
Вы удивитесь, но это было и в 70-е. И параллельные процессы тогда тоже были.
SVZ>Всякий Intellicence, Autocomplete.
Autocomplete тогда делали в основном для командных строк. Вещей, подобных IntelliSense, не делали просто потому, что не было такого зоопарка в API и библиотеках, как сейчас. Для повседневной работы вполне хватало конспекта из нескольких десятков листов, для сложных вещей приходилось доставать из шкафа пару-тройку томов документации. А исчерпывающий справочник по системе команд PDP-11 вообще умещался на складной картонке, которую можно было носить в кармане.
SVZ>То, что раньше делалось в формате "запустил задачу и пошел курить" сейчас превратилось в настоящее интерактивное редактирование.
В 70-е было полноценное интерактивное редактирование в реальном времени. А в 80-е я чисто по приколу сделал для Д3-28 (это такой большой настольный программируемый калькулятор) в машинных кодах (даже не на ассемблере, которого там не было, и на голом железе, поскольку ОС там тоже не было) полноэкранный текстовый редактор с форматированием и печатью нескольких страниц на лист А4. Это не было запредельно сложной задачей — скорее баловством. Будь в этом необходимость — добавил бы туда и AutoComplete, и IntelliSense, делов-то.
SVZ>Т.е. сложность и возможности гуя выросли на несколько порядков.
Не выросли они на порядки. Максимум — в разы. Все основные идеи были придуманы очень давно, просто многие из них не были востребованы по причине малой полезности.
SVZ>Если раньше гуй был ориентирован на профи, требующий предварительного обучения
Это который гуй был так ориентирован?
SVZ>Правда, последние лет десять я что-то не вижу серьезной научной работы в гуестроении
А какие еще есть актуальные и нерешенные проблемы в обычным двумерном гуе? Серьезная работа начнется, когда появятся массовые устройства, управляемые движениями глаз, или вообще силой мысли.
— всё больше дизайнеры косметику наводят.
SVZ>Ну и повышение сложности неизбежно ведет к увеличению числа ошибок. Эта проблема применима ко всем отраслям — что к софту, что к железу.
Re[11]: Тенденции в развитии микроэлектроники и ПО :)
Здравствуйте, Евгений Музыченко, Вы писали:
M>>Чутка побыстрее, зато весили сотни кг и стоили тонны нефти
ЕМ>И как это соотносится с заявлениями о том, что с техникой и методами программирования 70-х было якобы принципиально невозможно большинство современных технологий и решений?
Элементарно. Глянул в вики про IBM 360 — там на всю машину 4 метра оперативы в топовых моделях и 10К kIPS — я так понял — это кило инструкции пер секунда. Ну это да — середина 60ых — начало 70ых, в 82ом году, когда спектрум выпустили, наверно было получше. На 4х метрах, конечно, и винда 95ая как-то работала (правда проц пошустрее нужен, раз так в десятки тыщ раз) — но и 95ую с её прямым Хэ с современными технологиями не сравнить.
Я тут LLVM собирал — сорцы гиг где-то занимают (3 гига, если считать с гитовой репой), пол дня компилятся, на выходе 120Гб только для одной конфигурации — платформа/дебаг|релиз. Просто не вижу, чего тут можно сравнивать
Здравствуйте, Евгений Музыченко, Вы писали:
SVZ>>стоит вспомнить, что умел гуй 30 лет назад (про 70-е говорить нечего) и сейчас.
ЕМ>Говоря о том, что гуй умеет сейчас, не стоит забывать, что изрядное количество свойств добавлено исключительно из эстетических целей. Они не ускоряют работу, не делают ее более надежной или безопасной, они просто забавляют и радуют глаз. Их появление стало возможным только из-за избытка дешевых ресурсов, раньше в них попросту не видели никакого смысла.
Это смешно. Сравни PCAD и Altium 19
SVZ>>Благодаря современным мощностям и объемам памяти появилась возможность что-то предвычислять и перестраивать в фоне, пока пользователь пытается чего-то напечатать/нарисовать.
ЕМ>Вы удивитесь, но это было и в 70-е. И параллельные процессы тогда тоже были.
Тогда был только PCAD. С кучей отдельных тулзей, которые надо было правильно запускать и перезапускать
SVZ>>Всякий Intellicence, Autocomplete.
ЕМ>Autocomplete тогда делали в основном для командных строк.
Потому что только для этого и могли. И то — тыкал я этот автокомплит для командных строк — для баша — много ума записать список опций в нужном формате в башевский конфиг не надо. Это конечно, автокомплит, но такой себе... И уж точно — не Intellicence
ЕМ>Вещей, подобных IntelliSense, не делали просто потому, что не было такого зоопарка в API и библиотеках, как сейчас. Для повседневной работы вполне хватало конспекта из нескольких десятков листов, для сложных вещей приходилось доставать из шкафа пару-тройку томов документации. А исчерпывающий справочник по системе команд PDP-11 вообще умещался на складной картонке, которую можно было носить в кармане.
А без этого зоопарка API и библиотек ничего и не было бы. Ты можешь и сейчас доки в шкафу хранить. Я вот купил печатный C++ Std, храню в шкафу. Чисто по приколу, потому что погуглить таки быстрее
SVZ>>То, что раньше делалось в формате "запустил задачу и пошел курить" сейчас превратилось в настоящее интерактивное редактирование.
ЕМ>В 70-е было полноценное интерактивное редактирование в реальном времени. А в 80-е я чисто по приколу сделал для Д3-28 (это такой большой настольный программируемый калькулятор) в машинных кодах (даже не на ассемблере, которого там не было, и на голом железе, поскольку ОС там тоже не было) полноэкранный текстовый редактор с форматированием и печатью нескольких страниц на лист А4. Это не было запредельно сложной задачей — скорее баловством. Будь в этом необходимость — добавил бы туда и AutoComplete, и IntelliSense, делов-то.
IntelliSense — это не сферический конь в вакууме, а автодополнение к вводимому на основе контекста. Не, ну для бейсика, в котором нет структур — может и сделал бы.
SVZ>>Т.е. сложность и возможности гуя выросли на несколько порядков.
ЕМ>Не выросли они на порядки. Максимум — в разы. Все основные идеи были придуманы очень давно, просто многие из них не были востребованы по причине малой полезности.
Не были реализованы по причине невозможности с теми ресурсами
SVZ>>Если раньше гуй был ориентирован на профи, требующий предварительного обучения
ЕМ>Это который гуй был так ориентирован?
PCAD, например. Мы его два семестра изучали. Правда, там гуя-то не особо и было. А сейчас Альтиум запустил, и за семестр можно материнку для современного пентиума сделать — у меня так знакомый сделал в качестве хобби, да далеко и тут ходить не надо — вон, koandrew тоже платы с плисами и пятыми ддр чуть ли на не террагерцных частотах как пирожки штампует
Здравствуйте, Marty, Вы писали:
M>Глянул в вики про IBM 360 — там на всю машину 4 метра оперативы в топовых моделях
По тем временам, такой объем памяти был реально огромным для кода, и достаточно большим — для большей части данных. К тем примерам ПО, у которых требования к памяти определяются реально имеющимся объемом данных, у меня никогда не было претензий. Претензии к тому, что объем и кода, и данных уже давно многократно превосходит все разумные оценки.
M>и 10К kIPS — я так понял — это кило инструкции пер секунда.
Это младшие модели.
На 4х метрах, конечно, и винда 95ая как-то работала (правда проц пошустрее нужен, раз так в десятки тыщ раз) — но и 95ую с её прямым Хэ с современными технологиями не сравнить.
Что именно Вы знаете в современных технологиях, для чего объективно недостаточно 95-й винды?
M>Я тут LLVM собирал — сорцы гиг где-то занимают (3 гига, если считать с гитовой репой), пол дня компилятся, на выходе 120Гб только для одной конфигурации — платформа/дебаг|релиз.
Не понял, для чего этот пример. Я могу сделать Hello, world, который будет занимать пять гигов в исходниках, компилиться сутки и давать два гига бинарников. В доказательство чего это можно будет использовать?
Re[13]: Тенденции в развитии микроэлектроники и ПО :)
Здравствуйте, Евгений Музыченко, Вы писали:
M>>Глянул в вики про IBM 360 — там на всю машину 4 метра оперативы в топовых моделях
ЕМ>По тем временам, такой объем памяти был реально огромным для кода, и достаточно большим — для большей части данных. К тем примерам ПО, у которых требования к памяти определяются реально имеющимся объемом данных, у меня никогда не было претензий. Претензии к тому, что объем и кода, и данных уже давно многократно превосходит все разумные оценки.
Да и наплевать. Я раньше на WTL писал, а сейчас на кути. На кути быыстрее. Правда, простая тулза, висящая в трее, не 300 Кб, а 15 метров, но и фик с ним
ЕМ>На 4х метрах, конечно, и винда 95ая как-то работала (правда проц пошустрее нужен, раз так в десятки тыщ раз) — но и 95ую с её прямым Хэ с современными технологиями не сравнить.
ЕМ>Что именно Вы знаете в современных технологиях, для чего объективно недостаточно 95-й винды?
Не большой спец в современных технологиях. Но и чтобы из новых процов и видях выжимать максимум, 95ой недостаточно. Можно, условно говоря, дописать её, тогда 10ка и получится
M>>Я тут LLVM собирал — сорцы гиг где-то занимают (3 гига, если считать с гитовой репой), пол дня компилятся, на выходе 120Гб только для одной конфигурации — платформа/дебаг|релиз.
ЕМ>Не понял, для чего этот пример. Я могу сделать Hello, world, который будет занимать пять гигов в исходниках, компилиться сутки и давать два гига бинарников. В доказательство чего это можно будет использовать?
Твой хелло ворд будет уметь современный C++ собирать, и предоставлять для него инструментарий, даст возможность для языкописателей ограничится написанием только фронт-энда?
Здравствуйте, Marty, Вы писали:
M>Это смешно. Сравни PCAD и Altium 19
Смешно — это считать, будто любой продукт определенной эпохи всегда сделан оптимально для технологий этой эпохи. Давайте сравним штатовские автомобильные движки 60-х, про которые "заглушите двигатель, иначе полный бак никогда не наберется", с движками 40-х, а потом с движками хотя бы 80-х. Когда в 60-е американцам говорили, что двигатель не должен столько жрать, они доказывали, что технически невозможно получить те же мощности при меньшем расходе. И что получилось в итоге?
M>Тогда был только PCAD. С кучей отдельных тулзей, которые надо было правильно запускать и перезапускать
Вы действительно искренне считаете, что тот зоопарк был исключительно потому, что не хватало скорости и памяти?
ЕМ>>Autocomplete тогда делали в основном для командных строк.
M>Потому что только для этого и могли.
Могли для чего угодно. Надобности особой не было.
M>А без этого зоопарка API и библиотек ничего и не было бы.
Чего именно не было бы, и почему именно?
M>IntelliSense — это не сферический конь в вакууме, а автодополнение к вводимому на основе контекста. Не, ну для бейсика, в котором нет структур — может и сделал бы.
И что же в 70-х мешало парсить в реальном времени сишный текст, кроме лени? Или Вы думаете, что это было запредельно сложно для тех времен?
ЕМ>>Все основные идеи были придуманы очень давно, просто многие из них не были востребованы по причине малой полезности.
M>Не были реализованы по причине невозможности с теми ресурсами
Не "невозможности", а "нецелесообразности". Тогда особо не было лишних ресурсов, которые нужно было забить хоть чем-нибудь, дабы показать результат. То, в чем была реальная необходимость, делалась, если это не было совсем уж затратным.
SVZ>>>Если раньше гуй был ориентирован на профи, требующий предварительного обучения ЕМ>>Это который гуй был так ориентирован?
M>PCAD, например.
Это проблема PCAD, а не гуя.
M>А сейчас Альтиум запустил, и за семестр можно материнку для современного пентиума сделать — у меня так знакомый сделал в качестве хобби, да далеко и тут ходить не надо — вон, koandrew тоже платы с плисами и пятыми ддр чуть ли на не террагерцных частотах как пирожки штампует
Все это можно без проблем сделать на железе и технологиях 70-х. Будет работать всего в несколько раз медленнее, а не на порядки, на которые с тех пор выросло быстродействие. И занимать на порядки меньше.
Re[14]: Тенденции в развитии микроэлектроники и ПО :)
Здравствуйте, Marty, Вы писали:
M>Да и наплевать. Я раньше на WTL писал, а сейчас на кути. На кути быыстрее. Правда, простая тулза, висящая в трее, не 300 Кб, а 15 метров, но и фик с ним
"Не плюй в колодец — вылетит, не поймаешь". Ибо сперва — "наплевать" и "фик с ним", а потом — "какого хера эта фигня не встает на мой пятилетний комп, а на трехлетнем требует апгрейда?".
M>Не большой спец в современных технологиях.
Возможно, тогда и уверенность суждений следовало бы снизить?
M>Но и чтобы из новых процов и видях выжимать максимум, 95ой недостаточно.
Единственное, чего в 95-й действительно недостаточно — это поддержки многопроцессорности. В принципе, она достаточно проста, но должна присутствовать во всем ядерном коде, включая сторонний. В NT она есть. А все остальное — вишенки на торте, ускорение сугубо отдельных процессов в отдельных приложениях.
M>Можно, условно говоря, дописать её, тогда 10ка и получится
В десятке нет ничего принципиально нового по сравнению с NT3.5 (начало 90-х). Если совсем немного подпилить старые NT, чтоб умели программировать современные северные/южные мосты на том уровне, что достаточен для их работы, опять же немного адаптировать драйверы железа, то разница в производительности составит 10-20% для обычных приложений, и в несколько раз — для тех, что используют поддержку в ОС особенностей железа вроде NUMA.
M>Твой хелло ворд будет уметь современный C++ собирать, и предоставлять для него инструментарий, даст возможность для языкописателей ограничится написанием только фронт-энда?
Не будет, конечно. Но и у LLVM и близко нет функциональности, для которой необходимы 120 Мб кода/данных.
Re[15]: Тенденции в развитии микроэлектроники и ПО :)
Здравствуйте, Евгений Музыченко, Вы писали:
M>>Это смешно. Сравни PCAD и Altium 19
ЕМ>Смешно — это считать, будто любой продукт определенной эпохи всегда сделан оптимально для технологий этой эпохи. Давайте сравним штатовские автомобильные движки 60-х, про которые "заглушите двигатель, иначе полный бак никогда не наберется", с движками 40-х, а потом с движками хотя бы 80-х. Когда в 60-е американцам говорили, что двигатель не должен столько жрать, они доказывали, что технически невозможно получить те же мощности при меньшем расходе. И что получилось в итоге?
1) А они доказывали?
2) А при тех технологиях можно было сделать намного лучше?
M>>Тогда был только PCAD. С кучей отдельных тулзей, которые надо было правильно запускать и перезапускать
ЕМ>Вы действительно искренне считаете, что тот зоопарк был исключительно потому, что не хватало скорости и памяти?
У тебя есть другие версии?
ЕМ>>>Autocomplete тогда делали в основном для командных строк.
M>>Потому что только для этого и могли.
ЕМ>Могли для чего угодно. Надобности особой не было.
Почему не было? И откуда она сейчас появилась?
M>>А без этого зоопарка API и библиотек ничего и не было бы.
ЕМ>Чего именно не было бы, и почему именно?
M>>IntelliSense — это не сферический конь в вакууме, а автодополнение к вводимому на основе контекста. Не, ну для бейсика, в котором нет структур — может и сделал бы.
ЕМ>И что же в 70-х мешало парсить в реальном времени сишный текст, кроме лени? Или Вы думаете, что это было запредельно сложно для тех времен?
Уверен. Более того, я думаю, в те времена даже думать о таких возможностях было из разряда фантастики
ЕМ>>>Все основные идеи были придуманы очень давно, просто многие из них не были востребованы по причине малой полезности.
M>>Не были реализованы по причине невозможности с теми ресурсами
ЕМ>Не "невозможности", а "нецелесообразности". Тогда особо не было лишних ресурсов, которые нужно было забить хоть чем-нибудь, дабы показать результат. То, в чем была реальная необходимость, делалась, если это не было совсем уж затратным.
Во-первых, я бы поспорил насчет возможности, но лень. Во-вторых — ну, сделай мне альтиум 19 на PC XT. Это я про целесообразность. Ты 50 лет на это потратишь, но так и не сделашь
M>>А сейчас Альтиум запустил, и за семестр можно материнку для современного пентиума сделать — у меня так знакомый сделал в качестве хобби, да далеко и тут ходить не надо — вон, koandrew тоже платы с плисами и пятыми ддр чуть ли на не террагерцных частотах как пирожки штампует
ЕМ>Все это можно без проблем сделать на железе и технологиях 70-х. Будет работать всего в несколько раз медленнее, а не на порядки, на которые с тех пор выросло быстродействие. И занимать на порядки меньше.
Только делать ты будешь в сотни раз медленнее, и работать оно будет также медленнее.
ЗЫ Я самоудаляюсь из этого спора, он не имеет смысла
Здравствуйте, Евгений Музыченко, Вы писали:
M>>Твой хелло ворд будет уметь современный C++ собирать, и предоставлять для него инструментарий, даст возможность для языкописателей ограничится написанием только фронт-энда?
ЕМ>Не будет, конечно. Но и у LLVM и близко нет функциональности, для которой необходимы 120 Мб кода/данных.
Вообще-то я про 120 Гб писал. Но я лишние obj/ilk/etc поудалял, стало поменьше. PDB очень много места занимают. В целом, конечно, в релиз пойдёт размером мегабайты, но эти гигабайты необходимы для нормальной работы с LLVMовскими либами в процессе разработки.
На твоей любимой IBM/360 что-то подобное за разумное время ну никак не собрать. Время сборки исчислялось бы тысячелетиями, если бы перфоленты быстро бы подвозили, в худшем же случае наше Солнце погасло бы быстрее
Здравствуйте, Евгений Музыченко, Вы писали:
ЕМ>И вот, когда на фоне всего этого смотрю на эволюцию ПО, так прям тоска берет.
Ну, понимаешь, те прекрасные микросхемы, о которых ты говоришь, они, по уровню сложности, если их сравнивать с программами, то они такие же простые, как студенческие курсовые. Понятно, что программу из нескольких тысяч строк, профессионал напишет абсолютно надежно, и со всеми положенными бантиками.
А вот когда сложность микросхем становится сравнимой с уровнем сложности настоящих программ, то проблемы вылезают вполне аналогичные.
Я помню в те времена, когда я работал в софтверной группе, которая была частью проекта по разработке достаточно сложного, по своим временам, чипа, с железной стороны вылезали достаточно занятные проблемы. Причем решались они, как всегда, одним и тем же путем: пусть программисты встанут на уши и придумают, как обойти аппаратную багу. Ибо ремонт аппаратной баги всегда включал перевыпуск чипа, а это очень долго и очень дорого.
Re[13]: Тенденции в развитии микроэлектроники и ПО :)
Здравствуйте, Евгений Музыченко, Вы писали:
SVZ>>стоит вспомнить, что умел гуй 30 лет назад (про 70-е говорить нечего) и сейчас.
ЕМ>Говоря о том, что гуй умеет сейчас, не стоит забывать, что изрядное количество свойств добавлено исключительно из эстетических целей. Они не ускоряют работу, не делают ее более надежной или безопасной, они просто забавляют и радуют глаз. Их появление стало возможным только из-за избытка дешевых ресурсов, раньше в них попросту не видели никакого смысла.
GUI хотело большинство, кто в принципе знал про существование подобных средств хотя бы из рекламы по телевизору. Но ресурсы не позволяли.
Сейчас всяких свистелок в гуе не так-то и много, наоборот, их сокращают.
SVZ>>Благодаря современным мощностям и объемам памяти появилась возможность что-то предвычислять и перестраивать в фоне, пока пользователь пытается чего-то напечатать/нарисовать.
ЕМ>Вы удивитесь, но это было и в 70-е. И параллельные процессы тогда тоже были.
Надо смотреть не на то, что доступно было 0.1%, а на то, что доступно было хотя бы 50% пользователей компьютеров (которых самих тогда было ничтожное количество). А там ресурсы были жесточайше ограничены. Младшие S/360, например, выпускались с памятью объёма 8KB. PDPшки первые получали ещё меньше. Дисплейная установка стоила как самолёт, остальные пользовались перфокартами (в лучшем случае). Apple II за 1300$ (тогдашних!) — игрушка для богачей, параллельности на ней не водилось. Windows 2.x с кооперативной многозадачностью — предел технологий 80-х для широкой публики.
Техника, которая в 70-е позволяла параллельно что-то запускать... да никто её не использовал для тех же CAD, например. Кроме редчайших случаев — не окупалось. Почитайте историю Intel, например. Микросхемы чертили вручную.
SVZ>>Всякий Intellicence, Autocomplete.
ЕМ>Autocomplete тогда делали в основном для командных строк.
В 70-х его не было. Теоретические работы появились в 80-х. Первые реальные реализации это уже 90-е. Один из первых примеров в мире Unix и вокруг, это не bash, по которому все знают эту фичу — это Cisco IOS командная строка. Её пример вдохновил на развитие подобных фич в B-шеллах (bash, zsh) и C-шеллах (tcsh). В мире Windows ещё на десяток лет позже.
В 70-х был хилый закос в виде возможности сокращать операторы (а то и принудительно сводить в одну букву, как в FOCAL). Но там это действовало без выбора и подсказки вариантов.
EM> Вещей, подобных IntelliSense, не делали просто потому, что не было такого зоопарка в API и библиотеках, как сейчас. Для повседневной работы вполне хватало конспекта из нескольких десятков листов, для сложных вещей приходилось доставать из шкафа пару-тройку томов документации. А исчерпывающий справочник по системе команд PDP-11 вообще умещался на складной картонке, которую можно было носить в кармане.
По любой ISA времён условно до 1980 можно было свести в одну картонку, и что?
А про зоопарк — почитайте-ка, например, справочник по макрам ввода-вывода OS/360. Не уместите вы это на одной картонке, как ни старайся. Вот там объективная сложность.
SVZ>>То, что раньше делалось в формате "запустил задачу и пошел курить" сейчас превратилось в настоящее интерактивное редактирование. ЕМ>В 70-е было полноценное интерактивное редактирование в реальном времени.
Где это оно такое было?
Даже на дисплейных комплексах какой-нибудь старшей PDP-11 нужно было вначале сохранить файл, и только тогда компилировать можно было.
EM> А в 80-е я чисто по приколу сделал для Д3-28 (это такой большой настольный программируемый калькулятор) в машинных кодах (даже не на ассемблере, которого там не было, и на голом железе, поскольку ОС там тоже не было) полноэкранный текстовый редактор с форматированием и печатью нескольких страниц на лист А4. Это не было запредельно сложной задачей — скорее баловством. Будь в этом необходимость — добавил бы туда и AutoComplete, и IntelliSense, делов-то.
Ты половинку 80-х уточни-то. Это явно не первая.
SVZ>>Т.е. сложность и возможности гуя выросли на несколько порядков. ЕМ>Не выросли они на порядки. Максимум — в разы. Все основные идеи были придуманы очень давно, просто многие из них не были востребованы по причине малой полезности.
Да. И сейчас придумывают много идей, которые полноценно реализуются ой не скоро. И что?
SVZ>>Правда, последние лет десять я что-то не вижу серьезной научной работы в гуестроении ЕМ>А какие еще есть актуальные и нерешенные проблемы в обычным двумерном гуе? Серьезная работа начнется, когда появятся массовые устройства, управляемые движениями глаз, или вообще силой мысли.
Ну вот.
The God is real, unless declared integer.
Re[7]: Тенденции в развитии микроэлектроники и ПО :)
Здравствуйте, Евгений Музыченко, Вы писали:
ЕМ>Здравствуйте, Евгений Акиньшин, Вы писали:
ЕА>>У меня на спектруме экран был 192 на 256 пикселов с глубиной 1 бит.
ЕМ>Вы действительно полагаете, что во времена спектрумов другой вычислительной техники не существовало?
Ну так я сравниваю сопоставимые системы, что у меня было на столе тогда и что сейчас.
Давайте сравним с другой. Какие параметры дисплеев там были?
Здравствуйте, Marty, Вы писали:
ЕМ>>Когда в 60-е американцам говорили, что двигатель не должен столько жрать, они доказывали, что технически невозможно получить те же мощности при меньшем расходе.
M>1) А они доказывали?
Научно, разумеется, не доказывали, но позицию занимали примерно такую же: "а где ты видел меньше? а ты сам сделай лучше!".
M>2) А при тех технологиях можно было сделать намного лучше?
Конечно, японцы это наглядно продемонстрировали. Иначе хрен бы они сумели занять изрядную часть штатовского авторынка.
ЕМ>>Вы действительно искренне считаете, что тот зоопарк был исключительно потому, что не хватало скорости и памяти?
M>У тебя есть другие версии?
Зачем версии, если есть очевидное объяснение? Во-первых, математика автоматической компоновки и разводки многослойных плат создавалась не одномоментно, а поэтапно. Во-вторых, в те времена никому просто не приходило в голову, что стоит тратить ресурсы на создание системы, с помощью которой плату профессионального уровня сможет делать каждый любитель (это касается и современных IDE, позволяющих накидать компонент на форму и получить заготовки кода). Компоновка/разводка платы тогда была далеко не самым затратным этапом производства.
ЕМ>>Могли для чего угодно. Надобности особой не было.
M>Почему не было?
Потому, что программы тогда было принято "писать", "составлять", "изготавливать", а не собирать из конструктора. По той же причине, например, сборники типовых рифм имели хождение лишь среди поэтов-дилетантов, а профессионалы считали ниже своего достоинства ими пользоваться.
M>И откуда она сейчас появилась?
Особой надобности и сейчас нет, просто в ситуации избытка ресурсов всегда делается множество вещей, обладающих сомнительной пользой, и некоторые оказываются востребованными.
ЕМ>>И что же в 70-х мешало парсить в реальном времени сишный текст, кроме лени?
M>думаю, в те времена даже думать о таких возможностях было из разряда фантастики
У Вас крайне примитивные представления о тогдашних возможностях.
M>ну, сделай мне альтиум 19 на PC XT.
Именно Altium 19 один-в-один на XT, разумеется, не сделать — он изначально сделан на технологиях, работающих только на достаточно новом железе и софте. А примерный функциональный аналог, который будет работать даже гораздо быстрее, чем код, непосредственно перенесенный туда, сделать можно, и даже не за десятки лет.
M>Только делать ты будешь в сотни раз медленнее
Не в сотни, максимум — в разы. Современные технологии программирования ускоряют в десятки-сотни раз разработку только типовых решений. Мало-мальски нетривиальные решения делаются не намного быстрее, чем раньше.
M>и работать оно будет также медленнее.
Ну разумеется, коли все нынешнее железо на порядки быстрее тогдашнего. Но, как я уже говорил — медленнее будет, но не в такой пропорции.
M>ЗЫ Я самоудаляюсь из этого спора, он не имеет смысла
Это потому, что Вы упорно принимаете [не]целесообразность за [не]возможность.
Re[16]: Тенденции в развитии микроэлектроники и ПО :)
Здравствуйте, Marty, Вы писали:
M>Вообще-то я про 120 Гб писал. Но я лишние obj/ilk/etc поудалял, стало поменьше.
А какой вообще смысл подсчитывать промежуточные, служебные данные? В них, кстати, тоже избыточность в разы и на порядки.
M>в релиз пойдёт размером мегабайты, но эти гигабайты необходимы для нормальной работы с LLVMовскими либами в процессе разработки.
Гигабайты не являются необходимыми. Единиц-десятков мегабайт хватило бы по уши.
M>На твоей любимой IBM/360
Она никогда не была моей любимой. Мне больше нравилась БЭСМ-6, но ее так и не довели до уровня 360/370 по универсальности железа и софта.
M>что-то подобное за разумное время ну никак не собрать.
Вы постоянно соотносите ресурсы, потребляемые сегодня, с имевшимися тогда. Это принципиально некорректно, поскольку известно, что бОльшая часть современного ПО многократно избыточна по ресурсам. Это примерно, как утверждать, что ЭВМ невозможно питать от батареи. Ту совокупность железа, что называлась "ЭВМ" в 70-е, действительно невозможно, а ту, что эквивалентна ей по возможностям — легко.
Хозяйке на заметку: в 70-е были реализованы компиляторы с Алгол-68, который по тем временам выглядел куда круче, чем сейчас C++20. И программы компилировались отнюдь не часами.
M>Время сборки исчислялось бы тысячелетиями, если бы перфоленты быстро бы подвозили
Почему именно перфоленты, а не "тысяча негров на переключателях"?
Re[2]: Тенденции в развитии микроэлектроники и ПО :)
Здравствуйте, Pzz, Вы писали:
Pzz>те прекрасные микросхемы, о которых ты говоришь, они, по уровню сложности, если их сравнивать с программами, то они такие же простые, как студенческие курсовые. Pzz>А вот когда сложность микросхем становится сравнимой с уровнем сложности настоящих программ, то проблемы вылезают вполне аналогичные.
Так в том-то и фишка, что в электронике "аналогичные проблемы" вылезают только на достаточно больших микросхемах, а в ПО почти каждая простая программа требует ресурсов, как самый навороченный софт в 90-е.
Re[14]: Тенденции в развитии микроэлектроники и ПО :)
Здравствуйте, netch80, Вы писали:
N>GUI хотело большинство
Я никогда не говорил, будто бы GUI не хотели. Его хотели, но сугубо в той части, что облегчает работу, а не услаждает взор.
N>Но ресурсы не позволяли.
Ресурсы позволяли делать адекватный GUI, и его делали.
N>Сейчас всяких свистелок в гуе не так-то и много, наоборот, их сокращают.
Что хорошо показывает степень их востребованности. Сперва народу было скучно работать с прямоугольными одноцветными элементами, и плавные формы, цветовые градиенты и анимация были восприняты на ура. Теперь народ насмотрелся на весь этот оживляж, и опять хочет чего-то другого. Не удобного, не эффективного, а просто другого.
N>Надо смотреть не на то, что доступно было 0.1%, а на то, что доступно было хотя бы 50% пользователей компьютеров (которых самих тогда было ничтожное количество).
О том и речь, что дорогие решения внедрялись только там, где это было целесообразно. Подход "давайте это сделаем просто потому, что можем" применяется только в ситуации переизбытка ресурсов.
N>Windows 2.x с кооперативной многозадачностью — предел технологий 80-х для широкой публики.
Да ладно, не было никаких проблем добавить туда и вытесняющую многозадачность, просто не было в том явной потребности. Винда внедрялась достаточно медленно, и довольно долго было неясно, взлетит она или упадет. Как взлетела, так и пошла доработка.
N>Техника, которая в 70-е позволяла параллельно что-то запускать... да никто её не использовал для тех же CAD, например. Кроме редчайших случаев — не окупалось. Почитайте историю Intel, например. Микросхемы чертили вручную.
Прежде всего потому, что для подобных изменений должна накопиться критическая масса знаний, опыта, технологий. И лишь потом — ресурсов для вычисления и хранения.
ЕМ>>Autocomplete тогда делали в основном для командных строк.
N>В 70-х его не было. Теоретические работы появились в 80-х.
Какие еще "теоретические работы"? Это отнюдь не высшие области науки, чтобы практическим реализациям непременно предшествовала теория. Такие вещи очень давно делались на банальной интуиции.
N>Первые реальные реализации это уже 90-е.
У Вас очень превратные представления. Мы с парнями чисто по приколу делали такое в 80-е, а на 360/370 оно делалось и в 70-е.
N>Один из первых примеров в мире Unix и вокруг, это не bash, по которому все знают эту фичу — это Cisco IOS командная строка. Её пример вдохновил на развитие подобных фич в B-шеллах (bash, zsh) и C-шеллах (tcsh).
Это в Unix-мире, который всегда развивался обособленно от остальных.
N>В мире Windows ещё на десяток лет позже.
Какой еще Windows? Это было в ряде сторонних интерпретаторов и в DOS, и в CP/M. Даже у ранних Apple было, если не ошибаюсь.
N>В 70-х был хилый закос в виде возможности сокращать операторы (а то и принудительно сводить в одну букву, как в FOCAL). Но там это действовало без выбора и подсказки вариантов.
Потому, что программу было принято сперва написать, и уже написанную — набирать в редакторе и пробивать на перфокарты/перфоленты. Дисплейное время было довольно дорого, сидеть за дисплеем часами, сочиняя программу, было роскошью. Но там, где такая возможность имелась (в компаниях, производивших ЭВМ и оборудование, исследовательских центрах, у инженеров, обслуживающих машины, у энтузиастов ночами и т.п.) еще в 60-х, главным образом из чистого интереса, делались и интерактивные системы ввода.
N>А про зоопарк — почитайте-ка, например, справочник по макрам ввода-вывода OS/360.
Да, у этих было много сложного. Но сам по себе подход сочинения программы непосредственно за компьютером тогда еще не созрел. Созрел бы раньше — тогдашних ресурсов хватило бы на многое из того, что появилось потом.
ЕМ>>В 70-е было полноценное интерактивное редактирование в реальном времени.
N>Где это оно такое было?
На тех же 360/370, на Burroughs, на БЭСМ-6, еще на нескольких советских машинах, не столь известных. На PDP мы этим пользовались в начале 80-х, а сделано было, судя по всему, в конце 70-х.
N>Даже на дисплейных комплексах какой-нибудь старшей PDP-11 нужно было вначале сохранить файл, и только тогда компилировать можно было.
Интерактивное редактирование не предполагает параллельной компиляции. А если бы она и потребовалась — в чем проблема реализовать? Сохранить файл в фоне, запустить компилятор параллельным процессом, получить от него таблицы идентификаторов, зависимости и прочее — не нужно для этого ни сверхбыстродействия, ни огромной памяти. Я до сих пор пользуюсь VS 2008 на трехгигагерцовом процессоре и SSD, так и у нее IntelliSense нередко притормаживает на несколько секунд — приходится ждать, пока прожует.
EM>> А в 80-е я чисто по приколу сделал для Д3-28 (это такой большой настольный программируемый калькулятор) в машинных кодах (даже не на ассемблере, которого там не было, и на голом железе, поскольку ОС там тоже не было) полноэкранный текстовый редактор с форматированием и печатью нескольких страниц на лист А4.
N>Ты половинку 80-х уточни-то. Это явно не первая.
87-й год, а какая разница-то? Машинка эта разработана в 70-е, в СССР ее стали делать в начале 80-х. Попади она ко мне году в 82-м — сделал бы и тогда, не вижу проблемы.
N>И сейчас придумывают много идей, которые полноценно реализуются ой не скоро. И что?
То, что для реализации большинства этих идей вполне достаточно имеющихся ресурсов. И реализация нередко была бы даже не очень дорогой, но хочется-то или за три копейки, или вообще бесплатно. Многие программы появились не потому, что "возможность объективно созрела", а лишь потому, что кому-то стало не лень напрячься и сделать.
ЕМ>>Серьезная работа начнется, когда появятся массовые устройства, управляемые движениями глаз, или вообще силой мысли.
N>Ну вот.
И что из этого объективно невозможно без гигабайт и гигафлопсов?
Re[8]: Тенденции в развитии микроэлектроники и ПО :)
Здравствуйте, Евгений Акиньшин, Вы писали:
ЕА>Ну так я сравниваю сопоставимые системы, что у меня было на столе тогда и что сейчас.
То есть, свой стол Вы полагаете наиболее репрезентативным источником?
ЕА>Давайте сравним с другой. Какие параметры дисплеев там были?
Тогда дисплеи были в основном текстовые (чисто графические были дороже, и гораздо менее востребованы). Например, VT52 — 80x24 символа, матрица символа — 7x7 (заглавные, прописные, спецсимволы, псевдографика). На нем делали полноценный GUI с меню, прокруткой списков и прочим, разве что управление было клавишным, как в ранних безмышовых редакторах под DOS. То есть, разница была чисто количественной, отнюдь не качественной.
Re[15]: Тенденции в развитии микроэлектроники и ПО :)
Здравствуйте, Евгений Музыченко, Вы писали:
ЕМ>И что же в 70-х мешало парсить в реальном времени сишный текст, кроме лени? Или Вы думаете, что это было запредельно сложно для тех времен?
В основном — нехватка памяти. И её быстродействие. На тогдашних машинках несложные С-программы компилировались минутами.
И из этого времени кодогенерация, собственно, занимала не так много времени. Так что я что-то не особо верю в autocomplete с учётом контекста даже на XT-шках.
А если мы говорим о 70х, то лучшие компьютеры того времени для многооконного гуя выдавали пару кадров в секунду.
Банальное перетаскивание окна с содержимым появилось в Win98, как часть windows plus pack. До этого все изменения размеров и положения выполнялись при помощи рамочки.
Потому, что быстродействия-с не хватало.
Читаем очевидцев:
The animations on the NOVA ran 3-5 objects at about 2-3 frames per second. Fast enough for the phi phenomenon to work (if double buffering was used), but we wanted "Disney rates" of 10-15 frames a second for 10 or more large objects and many more smaller ones. This task was put into the ingenious hands of Steve Purcell. By the fall of '73 he could demo 80 ping-pong balls and 10 flying horses running at 10 frames per second in 2½D.
ЕМ>>>Все основные идеи были придуманы очень давно, просто многие из них не были востребованы по причине малой полезности.
А ещё очень многие идеи были отложены до наступления Закона Мура:
I spent the rest of the conference calculating just when the silicon of the FLEX machine could be put on the back of the display. According to Gordon Moore's "Law", the answer seemed to be sometime in the late seventies or early eighties. A long time off—it seemed too long to worry much about it then.
ЕМ>Не "невозможности", а "нецелесообразности". Тогда особо не было лишних ресурсов, которые нужно было забить хоть чем-нибудь, дабы показать результат. То, в чем была реальная необходимость, делалась, если это не было совсем уж затратным. А то. Не было необходимости в WYSIWYG — не делали. Не было необходимости делать "navigate to definition" — не делали.
Необходимость — это такая интересная штука. Как-то ведь люди жили и без компьютеров, так? Эйфель, скажем, свою башню рассчитал без единого компьютера. Так что, скажем, в CAD-системах необходимости нет.
Другое дело, что с ними всё происходит заметно быстрее и дешевле.
Точно так же и все инструменты разработчика — от autocomplete до подсветки статуса тестов в gutter-е. Какие там "прогоны всех тестов, на которые может повлять это изменение, по нажатию правой кнопки мыши", о чём вы?
Получил свои 10 минут машинного времени — и будь счастлив, если тебе самому разрешили перфокарты загружать. Потому что если там ошибка, то можно быренько лишние дырки заклеить, и новые проколупать — и по новой запихать колоду в читалку. А если у тебя колоду оператор забрал — то всё, он при первой же ошибке её в сторонку отложит и чью-то другую задачу делать будет.
То есть пока у тебя ресурс машины стоит дорого, человеческое время не стоит ничего. Новых потребностей не появилось; просто цена реализации этих потребностей снизилась до приемлемого уровня.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[15]: Тенденции в развитии микроэлектроники и ПО :)
Здравствуйте, Евгений Музыченко, Вы писали:
N>>Но ресурсы не позволяли. ЕМ>Ресурсы позволяли делать адекватный GUI, и его делали.
Адекватный — это 320x200 с 4 цветами и неизбежно вырвиглазными шрифтами (в лучшем случае уложенными в матрицу 7*5)? Ну да, что-то передать в таком формате можно. Но "адекватным" гуём это можно назвать только в шутку (в лучшем случае).
N>>Сейчас всяких свистелок в гуе не так-то и много, наоборот, их сокращают. ЕМ>Что хорошо показывает степень их востребованности. Сперва народу было скучно работать с прямоугольными одноцветными элементами, и плавные формы, цветовые градиенты и анимация были восприняты на ура. Теперь народ насмотрелся на весь этот оживляж, и опять хочет чего-то другого. Не удобного, не эффективного, а просто другого.
Так вот — это (частичный) возврат типового гуя к уровню 1995-2000. Но не 1970-х. Между ними разница около 1000 раз по ресурсам всех видов. И то — размер экрана меньше 1600 пикселов по ширине сейчас уже в рамках неприличия, потому что фиг что отобразишь, 4096 уже норма, 8K на подходе в массы.
А на ресурсах 1970-х сейчас никто не согласится даже базовые вещи реализовывать.
N>>Надо смотреть не на то, что доступно было 0.1%, а на то, что доступно было хотя бы 50% пользователей компьютеров (которых самих тогда было ничтожное количество). ЕМ>О том и речь, что дорогие решения внедрялись только там, где это было целесообразно. Подход "давайте это сделаем просто потому, что можем" применяется только в ситуации переизбытка ресурсов.
Вот догонка мощностей GUI до уровня примерно 1024*768*truecolor это целесообразно.
N>>Windows 2.x с кооперативной многозадачностью — предел технологий 80-х для широкой публики.
ЕМ>Да ладно, не было никаких проблем добавить туда и вытесняющую многозадачность, просто не было в том явной потребности. Винда внедрялась достаточно медленно, и довольно долго было неясно, взлетит она или упадет. Как взлетела, так и пошла доработка.
Проблемы были: нормально такая многозадачность вместе с другими фичами типа автодетекта железа, построения дерева драйверов, фоновыми задачами по обслуживанию системы и т.п. — начинала хоть как-то работать на 2MB оперативки, более-менее нормально — на 4MB. Позволить такие ресурсы в массе это уже начало 90-х, а не 80-е.
N>>Техника, которая в 70-е позволяла параллельно что-то запускать... да никто её не использовал для тех же CAD, например. Кроме редчайших случаев — не окупалось. Почитайте историю Intel, например. Микросхемы чертили вручную. ЕМ>Прежде всего потому, что для подобных изменений должна накопиться критическая масса знаний, опыта, технологий. И лишь потом — ресурсов для вычисления и хранения.
То-то сейчас на колоссальных ресурсах делают мелкие поделки.
ЕМ>>>Autocomplete тогда делали в основном для командных строк. N>>В 70-х его не было. Теоретические работы появились в 80-х. ЕМ>Какие еще "теоретические работы"? Это отнюдь не высшие области науки, чтобы практическим реализациям непременно предшествовала теория. Такие вещи очень давно делались на банальной интуиции.
Ну да, для себя и двух коллег в предельно специфичном варианте.
N>>Первые реальные реализации это уже 90-е. ЕМ>У Вас очень превратные представления. Мы с парнями чисто по приколу делали такое в 80-е, а на 360/370 оно делалось и в 70-е.
Я не помню такого на 360/370. А то, что вы "с парнями чисто по приколу" делали, оно было как, умело хотя бы подсказать, каким нескольким командам соответствует данный префикс?
N>>Один из первых примеров в мире Unix и вокруг, это не bash, по которому все знают эту фичу — это Cisco IOS командная строка. Её пример вдохновил на развитие подобных фич в B-шеллах (bash, zsh) и C-шеллах (tcsh). ЕМ>Это в Unix-мире, который всегда развивался обособленно от остальных.
Не было никакого обособления, идеи свободно кочевали туда-сюда, особенно вокруг открытых систем, как Unix.
N>>В мире Windows ещё на десяток лет позже. ЕМ>Какой еще Windows? Это было в ряде сторонних интерпретаторов и в DOS, и в CP/M. Даже у ранних Apple было, если не ошибаюсь.
Расскажите, как именно оно там работало. А то ой сомневаюсь.
ЕМ>>>В 70-е было полноценное интерактивное редактирование в реальном времени.
N>>Где это оно такое было?
ЕМ>На тех же 360/370, на Burroughs, на БЭСМ-6, еще на нескольких советских машинах, не столь известных. На PDP мы этим пользовались в начале 80-х, а сделано было, судя по всему, в конце 70-х.
И как оно выглядело?
N>>Даже на дисплейных комплексах какой-нибудь старшей PDP-11 нужно было вначале сохранить файл, и только тогда компилировать можно было.
ЕМ>Интерактивное редактирование не предполагает параллельной компиляции. А если бы она и потребовалась — в чем проблема реализовать? Сохранить файл в фоне, запустить компилятор параллельным процессом, получить от него таблицы идентификаторов, зависимости и прочее — не нужно для этого ни сверхбыстродействия, ни огромной памяти.
Ну вот, видимо, только от уровня где-то 4MB стало хватать. До этого — нет.
EM>>> А в 80-е я чисто по приколу сделал для Д3-28 (это такой большой настольный программируемый калькулятор) в машинных кодах (даже не на ассемблере, которого там не было, и на голом железе, поскольку ОС там тоже не было) полноэкранный текстовый редактор с форматированием и печатью нескольких страниц на лист А4.
N>>Ты половинку 80-х уточни-то. Это явно не первая.
ЕМ>87-й год, а какая разница-то? Машинка эта разработана в 70-е, в СССР ее стали делать в начале 80-х. Попади она ко мне году в 82-м — сделал бы и тогда, не вижу проблемы.
Читаю: варианты исполнения: 16K, 32K, 128K.
В 70-е даже 32K в калькуляторе было неподъёмно.
N>>И сейчас придумывают много идей, которые полноценно реализуются ой не скоро. И что?
ЕМ>То, что для реализации большинства этих идей вполне достаточно имеющихся ресурсов.
Интересное обобщение. Но не вижу для него причин.
ЕМ>>>Серьезная работа начнется, когда появятся массовые устройства, управляемые движениями глаз, или вообще силой мысли.
N>>Ну вот.
ЕМ>И что из этого объективно невозможно без гигабайт и гигафлопсов?
Даже просто проанализировать движения глаз.
The God is real, unless declared integer.
Re[12]: Тенденции в развитии микроэлектроники и ПО :)
Здравствуйте, Marty, Вы писали:
M>Элементарно. Глянул в вики про IBM 360 — там на всю машину 4 метра оперативы в топовых моделях и 10К kIPS — я так понял — это кило инструкции пер секунда.
Тут что-то не то, 10kIPS это как раз самые младшие модели, память которых начиналась от 8KB. У топовых этих самых инструкций получалось под миллион.
M> Ну это да — середина 60ых — начало 70ых, в 82ом году, когда спектрум выпустили, наверно было получше. На 4х метрах, конечно, и винда 95ая как-то работала (правда проц пошустрее нужен, раз так в десятки тыщ раз) -
Скорее просто в тысячу от младших и раз в 20-50 от топовых.
M>Я тут LLVM собирал — сорцы гиг где-то занимают (3 гига, если считать с гитовой репой), пол дня компилятся, на выходе 120Гб только для одной конфигурации — платформа/дебаг|релиз. Просто не вижу, чего тут можно сравнивать
Вот это мне крайне подозрительно, потому что например во FreeBSD собирается по умолчанию clang, и там объём полного дерева компиляции всего мира в разы меньше, чем у тебя один LLVM. Скорее оно тебе таки на промежуточных билдах, а может и на окончательных, собирало все таргеты, какие вообще знает.
The God is real, unless declared integer.
Re[17]: Тенденции в развитии микроэлектроники и ПО :)
Здравствуйте, Евгений Музыченко, Вы писали:
ЕМ>Она никогда не была моей любимой. Мне больше нравилась БЭСМ-6, но ее так и не довели до уровня 360/370 по универсальности железа и софта.
БЭСМ-6 — тупая кривуля. Одно отсутствие целочисленной арифметики чего стоит (да, я знаю про режим "0 цифр после запятой"). 16-битное "окно в мир" там, где давно пора сделать было шире адрес. (Да, точно так же было на PDP-11, но PDP-11 заявлялась как мини- и микро-ЭВМ, а не полноценная!) Ну и вообще 100500 глупостей в системе команд, и вокруг...
Когда сравнивали возможности БЭСМ-6 и S/360 — 360ка выигрывала в несколько раз по объёму выходного кода и по удобству написания под неё. Да сейчас её какой-нибудь 8051 победит как лежачую.
Ностальгировать по этому смысла просто ноль целых фиг десятых.
ЕМ>Хозяйке на заметку: в 70-е были реализованы компиляторы с Алгол-68, который по тем временам выглядел куда круче, чем сейчас C++20. И программы компилировались отнюдь не часами.
"Круче" не конкретизируемый термин. Язык сам по себе безнадёжен.
The God is real, unless declared integer.
Re[16]: Тенденции в развитии микроэлектроники и ПО :)
Это очень сильно зависело от реализации компилятора. Если компилятор делался "по науке", в расчете на абстрактную бесконечную программу любой сложности, и независимо применял лексический и синтаксический анализ, трансляцию в промежуточный код, генерацию двоичного кода и т.п., использовал виртуальную память потенциально неограниченного объема для работы с любыми динамическими структурами, то он, разумеется, нещадно тормозил, главным образом на этой самой виртуальной памяти и переходах между слоями абстракции. А если его делали в расчете на типовые, наиболее часто встречающиеся программы, то мог успевать и за секунды.
S>И из этого времени кодогенерация, собственно, занимала не так много времени. Так что я что-то не особо верю в autocomplete с учётом контекста даже на XT-шках.
Для реализации autocomplete нет нужды прогонять по тексту полноценный синтаксический анализ, достаточно самого примитивного. Здесь очень хорошо работает "правило 80/20".
S>А если мы говорим о 70х, то лучшие компьютеры того времени для многооконного гуя выдавали пару кадров в секунду.
Гораздо больше, да и то в чистой, пиксельной графике. Которая для GUI вовсе не обязательна. Символьные дисплеи давали десятки операций в секунду.
S>Банальное перетаскивание окна с содержимым появилось в Win98, как часть windows plus pack. До этого все изменения размеров и положения выполнялись при помощи рамочки. S>Потому, что быстродействия-с не хватало.
Быстродействия не хватало не на перетаскивание, а на прогон всего каскада уведомлений и перерисовок после перемещения на каждые несколько точек. Просто прямоугольники со статическим содержимым даже на XT можно было таскать без задержек.
S>
S>The animations on the NOVA ran 3-5 objects at about 2-3 frames per second.
Это об анимации произвольных объектов, к чему это здесь? Мы вроде не обсуждали игры и мультики.
S>Не было необходимости в WYSIWYG — не делали.
WYSIWYG делали еще в 60-е. "Жопа есть, а слова нет".
Re[16]: Тенденции в развитии микроэлектроники и ПО :)
Здравствуйте, netch80, Вы писали:
N>Адекватный — это 320x200 с 4 цветами и неизбежно вырвиглазными шрифтами (в лучшем случае уложенными в матрицу 7*5)?
Адекватный — это соответствующий поставленной задаче. Не нужно оценивать всю индустрию по игрушке IBM PC.
N>размер экрана меньше 1600 пикселов по ширине сейчас уже в рамках неприличия, потому что фиг что отобразишь, 4096 уже норма, 8K на подходе в массы.
Из того, что все это существует, никак не следует, что оно является необходимым для тех целей, для которых используется, и без этого достижение целей якобы невозможно. Почувствуйте разницу между возможностью и комфортом.
N>А на ресурсах 1970-х сейчас никто не согласится даже базовые вещи реализовывать.
Да, только одни не согласятся потому, что это сложно и трудоемко, а другие — потому, что не понимают, как такое вообще возможно.
N>догонка мощностей GUI до уровня примерно 1024*768*truecolor это целесообразно.
1024x768 — целесообразно, а TrueColor — на фиг не нужно. В подавляющем большинстве GUI используются стандартные палитры, там 16 цветов хватит за глаза, для особых эстетов — 256.
N>нормально такая многозадачность вместе с другими фичами типа автодетекта железа, построения дерева драйверов, фоновыми задачами по обслуживанию системы и т.п. — начинала хоть как-то работать на 2MB оперативки
На каком основании Вы неразрывно связываете многозадачность со всем перечисленным? Сама по себе многозадачность может быть реализована очень экономно — есть множество различных реализаций, даже для простых микроконтроллеров с десятками килобайт памяти.
N>То-то сейчас на колоссальных ресурсах делают мелкие поделки.
Ну да — потому, что можно. Мне вот нужен формирователь сигнала сброса по включению питания, а готовой микросхемы или подходящего компаратора под рукой нет, зато есть десяток простейших МК, и очень подмывает сделать именно на нем.
ЕМ>>Такие вещи очень давно делались на банальной интуиции.
N>Ну да, для себя и двух коллег в предельно специфичном варианте.
Так я и не говорю, что все это уже тогда было близко к идеалу. Именно так — было несовершенно, ограничено, но таки работало. А большинство искренне считает, что переход на PC произошел непосредственно с перфокарт.
N>Я не помню такого на 360/370.
Оно и на ЕС работало, по понятным причинам.
N>А то, что вы "с парнями чисто по приколу" делали, оно было как, умело хотя бы подсказать, каким нескольким командам соответствует данный префикс?
Умело, оно перебирало команды при нажатиях управляющих клавиш. Я, честное слово, не понимаю, что Вас удивляет — это же голимый примитив, мы тогда почти всё писали на ассемблере, и отнюдь не считали, что реализуем что-то авангардное или сложное.
ЕМ>>>>В 70-е было полноценное интерактивное редактирование в реальном времени. N>И как оно выглядело?
Вы видели типичный визуальный текстовый редактор под DOS, работающий в текстовом режиме, типа MultiEdit/Lexicon? Вот так и выглядело, с поправкой на разрешение терминала, монохромность и способы управления отображением текста.
ЕМ>>Сохранить файл в фоне, запустить компилятор параллельным процессом, получить от него таблицы идентификаторов, зависимости и прочее
N>Ну вот, видимо, только от уровня где-то 4MB стало хватать. До этого — нет.
Да откуда Вы это взяли? Для компиляции программы в десяток килобайт исходника (вполне себе серьезная программа по тем временам, многие утилиты ОС такими были) хватало нескольких десятков килобайт памяти, какие мега байты?
N>В 70-е даже 32K в калькуляторе было неподъёмно.
И зачем Вы уперлись именно в калькулятор? Я привел пример создания достаточно сложной даже по современным меркам программы в голом машинном коде весьма примитивной машины, силами одного человека, за небольшой срок. В 70-е же хватало гораздо более мощной техники.
ЕМ>>И что из этого объективно невозможно без гигабайт и гигафлопсов?
N>Даже просто проанализировать движения глаз.
В мозгу это успешно делают десятки-сотни тысяч нейронов, имеющих быстродействие на несколько порядков ниже.
Re[18]: Тенденции в развитии микроэлектроники и ПО :)
Здравствуйте, netch80, Вы писали:
N>БЭСМ-6 — тупая кривуля.
Я правильно понимаю, что Вы не имели с нею дела, по крайней мере — в те времена, и оцениваете сугубо в сравнении с более новой техникой?
N>Одно отсутствие целочисленной арифметики чего стоит
А чего оно стоит? Кому конкретно оно мешало настолько, что они "даже кушать не могли"?
16-битное "окно в мир" там, где давно пора сделать было шире адрес.
Даже не 16-ти, а 15-ти. Но для большинства задач этого хватало (надеюсь, про явление локальности Вы в курсе?). Так же, как и сегментной организации памяти в 286 тоже хватало для большинства задач, но это было банально неудобно. Понимаете разницу между неудобством и невозможностью?
N>(Да, точно так же было на PDP-11, но PDP-11 заявлялась как мини- и микро-ЭВМ, а не полноценная!) Ну и вообще 100500 глупостей в системе команд, и вокруг...
Где именно было "100500 глупостей"? Отдельные глупости есть везде, уж в PC их считать устанешь. А те системы команд вообще никогда не испытывали многократных переделок.
N>Когда сравнивали возможности БЭСМ-6 и S/360 — 360ка выигрывала в несколько раз по объёму выходного кода и по удобству написания под неё.
По удобству — однозначно выигрывала, а по объему — лишь в том случае, когда на 360 имелась подходящая библиотека, встроенная в ОС. Самой большой слабостью БЭСМ-6 было то, что на ней не было единой программной системы. Где-то писали все свое, где-то стыковали разнородные программы через промежуточные носители, где-то делали универсальные системы вроде "Дубны". Но это были проблемы не самой техники, а организации разработки в СССР, где работы распылялись по организациям, и плохо управлялись.
N>Да сейчас её какой-нибудь 8051 победит как лежачую.
Это вообще к чему?
N>Ностальгировать по этому смысла просто ноль целых фиг десятых.
Мне совершенно не свойственна ностальгия по технике тех времен — разве что по самим временам. Мне досадно, когда люди теряют адекватное представление о ресурсах, реально потребных для решения той или иной задачи. Здесь очень уместно вспомнить классическую притчу Дейкстры о том, кто был "первым компетентным программистом".
N>"Круче" не конкретизируемый термин. Язык сам по себе безнадёжен.
А термин "безнадежен" — конкретизируемый? Алгол-68 "круче" C++ прежде всего в плане сложности его реализации, а отнюдь не удобства программирования или модности.
Re[13]: Тенденции в развитии микроэлектроники и ПО :)
Здравствуйте, netch80, Вы писали:
M>>Я тут LLVM собирал — сорцы гиг где-то занимают (3 гига, если считать с гитовой репой), пол дня компилятся, на выходе 120Гб только для одной конфигурации — платформа/дебаг|релиз. Просто не вижу, чего тут можно сравнивать
N>Вот это мне крайне подозрительно, потому что например во FreeBSD собирается по умолчанию clang, и там объём полного дерева компиляции всего мира в разы меньше, чем у тебя один LLVM. Скорее оно тебе таки на промежуточных билдах, а может и на окончательных, собирало все таргеты, какие вообще знает.
Ну то есть да, LLVM мне сам по себе не нужен, мне нужен clang и clang-tools (-DLLVM_ENABLE_PROJECTS=clang;clang-tools-extra), оно там в итоге много чего собирает
Здравствуйте, Евгений Музыченко, Вы писали:
ЕМ>Помнится, в 70-е бОльшую часть электроники делали на "рассыпухе", микросхем тогда было мало, в основном цифровая логика...
ЕМ>И вот, когда на фоне всего этого смотрю на эволюцию ПО, так прям тоска берет.
Ну, ПО тоже шагнуло довольно далеко. А главное шагнули процессы разработки. Если тогда ПО писалось одиночками или командами до 7 человек, то теперь над некоторым коробочным ПО работают тысячи человек одновременно. Я вообще не понимаю как у нас продукт собирается.
За это время в ПО вошли:
1. ООП.
2. ФП.
3. DSL.
4. Системы контроля (управления) версий (прошли 3 эволюции и стали распределенными).
5. Сборочные конвеер.
6. Виртуальные машины для тестирования и даже их фермы. У нас в компании тесты гоняются на тысячах виртуалок которые доступны всем в конторе.
7. Системы отслеживания ошибок (вроде TFS)
8. Системы планирования.
Появились мощные IDE поддерживающие интелиснс, рефакторинги, отладку (локальную, удаленную и даже дмпом).
Одних только языков программирования появилось несколько тысяч.
Далее виртуальные машины. Кроскомпиляторы.
Думаю электронщикам столько и не снилось. Да сами электронщики используют автомазированные системы проектирования. И не только они. Сейчас уже никакое производство без них не обходится.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[2]: Тенденции в развитии микроэлектроники и ПО :)
Здравствуйте, VladD2, Вы писали:
VD>Ну, ПО тоже шагнуло довольно далеко.
Блин, да не в том дело, насколько шагнуло. А в том, что развитие микросхем сопровождалось улучшением всех без исключения потребительских характеристик. А развитие ПО, помимо улучшения одних характеристик, сопровождалось ухудшением (и значительным) других. И если сейчас вдруг потребуется получить гораздо бОльшую производительность ПО на имеющихся мощностях, или сохранить имеющуюся на меньших, то подавляющее большинство разработчиков этого банально не сможет, и будет искренне утверждать, будто невозможно совершить чудо. А на тех, кто сможет, будут действительно смотреть, как на шаманов.
VD>Если тогда ПО писалось одиночками или командами до 7 человек
Это когда? С самого начала разработки ПО в середине прошлого века оно писалось тем количеством людей, которое или объективно требовалось, или имелось в наличии. Никаких ограничений не было никогда.
VD>теперь над некоторым коробочным ПО работают тысячи человек одновременно. Я вообще не понимаю как у нас продукт собирается.
Примерно так и работали советские НИИ. Несколько институтов, десятки-сотни отделов, сотни-тысячи человек, и почти никто не представлял себе продукта во всей совокупности. Для секретных разработок это было хорошо, а вот для всего остального... Потом, разумеется, каждый отдел спихивал ответственность за косяки на смежников.
VD>Да сами электронщики используют автомазированные системы проектирования.
Только электронщикам это позволяет делать многофункциональные, скоростные, надежные, и одновременно компактные и экономичные устройства, а вот автоматизация программирования пока работает в основном на bloatware.
Re[9]: Тенденции в развитии микроэлектроники и ПО :)
Здравствуйте, Евгений Музыченко, Вы писали:
ЕМ>Здравствуйте, Евгений Акиньшин, Вы писали:
ЕА>>Ну так я сравниваю сопоставимые системы, что у меня было на столе тогда и что сейчас.
а почему нет?
ЕМ>То есть, свой стол Вы полагаете наиболее репрезентативным источником?
ЕА>>Давайте сравним с другой. Какие параметры дисплеев там были?
ЕМ>Тогда дисплеи были в основном текстовые (чисто графические были дороже, и гораздо менее востребованы). Например, VT52 — 80x24 символа, матрица символа — 7x7 (заглавные, прописные, спецсимволы, псевдографика). На нем делали полноценный GUI с меню, прокруткой списков и прочим, разве что управление было клавишным, как в ранних безмышовых редакторах под DOS. То есть, разница была чисто количественной, отнюдь не качественной.
Гм, переход к графической системе с многооконностью и многозадачностью и разрешениям экрана, от которых не болят глаза вы называете количественным?
Re[19]: Тенденции в развитии микроэлектроники и ПО :)
Здравствуйте, Евгений Музыченко, Вы писали:
N>>БЭСМ-6 — тупая кривуля.
ЕМ>Я правильно понимаю, что Вы не имели с нею дела, по крайней мере — в те времена, и оцениваете сугубо в сравнении с более новой техникой?
Ну почему с более новой? CDC1604, с которой любят сравнивать. Те из линии PDP, которые были на 1965 (декларированный в википедии год старта разработки БЭСМ-6).
Даже S/360, у которой модели 20 и 30 вполне в том же классе, что БЭСМ-6.
N>>Одно отсутствие целочисленной арифметики чего стоит ЕМ>А чего оно стоит? Кому конкретно оно мешало настолько, что они "даже кушать не могли"?
Оно мешало тем, что толщина кода на всё, что не было непосредственно вычислениями с плавающей точкой, на ней становилось дороже в несколько раз. А так как даже просто подсчитать индексы в матрице это целочисленные вычисления, то подобная диверсия била по всему.
В IBM это поняли давно и сделали хотя бы систему команд универсальной с возможностью адаптации под конкретный стиль, но по крайней мере это отражалось в плюс-минус пяток раз по скорости. А у Лебедева что-то тяжело заклинило.
ЕМ>16-битное "окно в мир" там, где давно пора сделать было шире адрес.
ЕМ>Даже не 16-ти, а 15-ти. Но для большинства задач этого хватало (надеюсь, про явление локальности Вы в курсе?).
Если "локальность" это "у нас машина для численных расчётов, а всё остальное пофиг", то да, в курсе. Если что-то другое — уточните, какую именно из 100501 локальностей вы тут имеете в виду.
Ну а "большинство" задач в которых нельзя считать что-то размером больше чем 100x100 без жутких извратов... может, для 50-х это нормально, но уже в 70-х (а машина которую начали разрабатывать в 1965 целится таки на 70-е) это несерьёзно.
EM> Так же, как и сегментной организации памяти в 286 тоже хватало для большинства задач, но это было банально неудобно. Понимаете разницу между неудобством и невозможностью?
В сегментной организации можно хотя бы без регулярного напряга ОС обратиться к другому сегменту, просто загрузил номер и пошёл. А тут что — просить ОС каждый раз хлопать страницами? Или как там назывался аналог ОС?
N>>(Да, точно так же было на PDP-11, но PDP-11 заявлялась как мини- и микро-ЭВМ, а не полноценная!) Ну и вообще 100500 глупостей в системе команд, и вокруг...
ЕМ>Где именно было "100500 глупостей"? Отдельные глупости есть везде, уж в PC их считать устанешь. А те системы команд вообще никогда не испытывали многократных переделок.
А БЭСМ-6 что, испытывала? И тянула совместимость с МЭСМ? Под неё надо было всё переписать.
N>>Когда сравнивали возможности БЭСМ-6 и S/360 — 360ка выигрывала в несколько раз по объёму выходного кода и по удобству написания под неё.
ЕМ>По удобству — однозначно выигрывала, а по объему — лишь в том случае, когда на 360 имелась подходящая библиотека, встроенная в ОС. Самой большой слабостью БЭСМ-6 было то, что на ней не было единой программной системы. Где-то писали все свое, где-то стыковали разнородные программы через промежуточные носители, где-то делали универсальные системы вроде "Дубны". Но это были проблемы не самой техники, а организации разработки в СССР, где работы распылялись по организациям, и плохо управлялись.
Нет, как раз описывают не связанное с библиотеками — а именно код типа "перемножить матрицу на вектор".
Единственность аккумулятора — вообще самая первая глупость дизайна, которая приводит к тому, что операции загрузить в аккумулятор и выгрузить из него занимают больше всего остального. Для чего-то мелкого типа 8080 это нормально. Для полноценного компа уже некультурно.
N>>Да сейчас её какой-нибудь 8051 победит как лежачую. ЕМ>Это вообще к чему?
К логичности и сбалансированности системы команд.
Ладно, 8051 плохой пример, это не те масштабы... но вот в линии PDP (не обязательно PDP-11!) есть куда более интересные примеры. И даже CDC1604 (и похожие), с которой любят сравнивать БЭСМ-6...
N>>Ностальгировать по этому смысла просто ноль целых фиг десятых.
ЕМ>Мне совершенно не свойственна ностальгия по технике тех времен — разве что по самим временам. Мне досадно, когда люди теряют адекватное представление о ресурсах, реально потребных для решения той или иной задачи. Здесь очень уместно вспомнить классическую притчу Дейкстры о том, кто был "первым компетентным программистом".
Притча хорошая, но она не про ресурсы.
Если кому-то хочется посмотреть на использование ресурсов — сейчас под те же 8051 продолжают писать реальные шедевры. Или есть конкурсы по минимизации объёма, доходящие до "Pacman в 90 байт". Но при чём тут ужасы древнего дизайна?
N>>"Круче" не конкретизируемый термин. Язык сам по себе безнадёжен. ЕМ>А термин "безнадежен" — конкретизируемый?
Да, его можно спроецировать на оценку планов использования, на развитие или деградацию.
EM> Алгол-68 "круче" C++ прежде всего в плане сложности его реализации, а отнюдь не удобства программирования или модности.
Ну вот потому он и почти забыт — что его сложность была неоправданной.
Здравствуйте, AntoxaM, Вы писали:
ЕА>>>Ну так я сравниваю сопоставимые системы, что у меня было на столе тогда и что сейчас. AM>а почему нет?
Ну вот у кого-то в 70-е был москвич, а сейчас — тесла. Означает ли это, что мировой уровень автомобилестроения в 70-х определялся именно москвичом?
ЕМ>>То есть, свой стол Вы полагаете наиболее репрезентативным источником?
AM>переход к графической системе с многооконностью и многозадачностью и разрешениям экрана, от которых не болят глаза вы называете количественным?
Графические системы, многооконность и многозадачность были и тогда, они лишь не сочетались между собой в каждом утюге. Глаза у подавляющего большинства не болели. Где именно Вы видите качественный переход?
Это как если, опять же в сравнении с автопромом, объявить "качественным переходом" то, что нынче во многих автомобилях есть одновременно и кожаный салон, и навигатор, и электрические стеклоподъемники, а когда-то оно было лишь по отдельности.
Re[3]: Тенденции в развитии микроэлектроники и ПО :)
Здравствуйте, Евгений Музыченко, Вы писали:
ЕМ>Блин, да не в том дело, насколько шагнуло. А в том, что развитие микросхем сопровождалось улучшением всех без исключения потребительских характеристик. А развитие ПО, помимо улучшения одних характеристик, сопровождалось ухудшением (и значительным) других.
Так и ПО сопровождалось улучшением всех без исключения потребительских характеристик. Скажем MS SQL Server 6 в подметки не годится MS SQL Server 2019. Он стал быстрее, надежнее, научился использовать современные железки...
ЕМ>И если сейчас вдруг потребуется получить гораздо бОльшую производительность ПО на имеющихся мощностях, или сохранить имеющуюся на меньших, то подавляющее большинство разработчиков этого банально не сможет, и будет искренне утверждать, будто невозможно совершить чудо. А на тех, кто сможет, будут действительно смотреть, как на шаманов.
Ну, вот пример с MS SQL Server 2019 это твое утверждение опровергает. Так что обсуждать не чего, так как исходное утверждение ложно.
Вот только производительность не всегда бывает самой важной характеристикой ПО. Когда она нужна есть масса способов ее улучшить. Можно профилировать ПО. Можно более производительные алгоритмы реализовывать.
ЕМ>Это когда?
Цитирую твой текст:
Помнится, в 70-е бОльшую часть электроники делали
ЕМ>С самого начала разработки ПО в середине прошлого века оно писалось тем количеством людей, которое или объективно требовалось, или имелось в наличии. Никаких ограничений не было никогда.
Это вранье. В середине прошлого века ПО вообще не писалось. Тогда компьютеров еще не было. А вот в 70-е ПО писалось очень небольшими группами людей. Просто не было технологий позволяющих писать ПО даже сотнями программистов. ДОС был написан одиночкой. Над Эплами работали 2 человека. А это уже 80е. Я помню как ПО писалось в Госплане СССР. Его писали одиночки. Отлаживали чтением листингов. Загружали с перфокарт. Мрак! Никаких git-ов, TFS-ов и тому подобного еще не было. Железо было настолько медленным, что софт часто писали на ассемблерах и доводили до блеска.
ЕМ>Примерно так и работали советские НИИ.
Да ни хрена подобного. В те времена вообще сложного софта не было. У нас один ГУЁ сейчас сложнее всего софта, что был в Госплане СССР. Это факт.
ЕМ>Несколько институтов, десятки-сотни отделов, сотни-тысячи человек, и почти никто не представлял себе продукта во всей совокупности. Для секретных разработок это было хорошо, а вот для всего остального... Потом, разумеется, каждый отдел спихивал ответственность за косяки на смежников.
Да институтов то было дохера. Но даже компьютеров то в них было раз два и обчелся. Доступ к ним был по времени. Каждый писал свою мелкую программульку. Система учета зарплат уже была чем-то большим.
ЕМ>Только электронщикам это позволяет делать многофункциональные, скоростные, надежные, и одновременно компактные и экономичные устройства, а вот автоматизация программирования пока работает в основном на bloatware.
Мы уже выяснили, что твои заявления о ПО ложны. Мне кажется обсуждать тут не чего. Ты просто придумал себе миф и веришь в него. Меж тем софт, как и микросхемы, стал намного сложнее. Там где нужно он работает очень быстро. Но сот не отделим от железа. Ну, ежу понятно, что нельзя сделать софт для IBM PC который сможет быстро обрабатывать БД размером в несколько гигабайт. А на современном железе за просто. Весь объем памяти у PC-ки был жалкие 640 Кб да еще и с сегментным доступом. А сейчас все эти гигабайты можно тупо в память поднять. Да память с процессором быстрее в миллионы раз. Иногда быстрое железо позволяет писать менее эффектиный софт и при этом решать задачи. Ну, и фиг бы с ним. Как я уже сказал скорость не всегда самая важная характеристика.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[17]: Тенденции в развитии микроэлектроники и ПО :)
Здравствуйте, Евгений Музыченко, Вы писали:
N>>Адекватный — это 320x200 с 4 цветами и неизбежно вырвиглазными шрифтами (в лучшем случае уложенными в матрицу 7*5)?
ЕМ>Адекватный — это соответствующий поставленной задаче. Не нужно оценивать всю индустрию по игрушке IBM PC.
Не надо домысливать за других. Я судил по Apple II Вполне достойный зверь на середину 70-х (а не на начало 80-х, как IBM PC). И IBM PC — не игрушка, как бы некоторым ни хотелось это утверждать.
N>>размер экрана меньше 1600 пикселов по ширине сейчас уже в рамках неприличия, потому что фиг что отобразишь, 4096 уже норма, 8K на подходе в массы. ЕМ>Из того, что все это существует, никак не следует, что оно является необходимым для тех целей, для которых используется, и без этого достижение целей якобы невозможно. Почувствуйте разницу между возможностью и комфортом.
Почувствовал, да. По меркам военного коммунизма, конечно, работать можно и на ведре, когда всей еды чёрный хлеб с кипятком. Но если нужна нормальная эффективность работы, долговременной и без изматывающего напряга — то необходимы и нормальные средства, и я говорю как раз о минимуме этой нормы.
N>>А на ресурсах 1970-х сейчас никто не согласится даже базовые вещи реализовывать. ЕМ>Да, только одни не согласятся потому, что это сложно и трудоемко, а другие — потому, что не понимают, как такое вообще возможно.
Потому что вложены огромные затраты человеческого времени, которые можно было бы пустить на что-то другое?
N>>догонка мощностей GUI до уровня примерно 1024*768*truecolor это целесообразно.
ЕМ>1024x768 — целесообразно, а TrueColor — на фиг не нужно. В подавляющем большинстве GUI используются стандартные палитры, там 16 цветов хватит за глаза, для особых эстетов — 256.
Я даже на "safe" 216 тут соглашусь, раз так вы согласны с необходимостью адекватных размеров
Главное, чтобы не 16 (и тем более не меньше).
N>>нормально такая многозадачность вместе с другими фичами типа автодетекта железа, построения дерева драйверов, фоновыми задачами по обслуживанию системы и т.п. — начинала хоть как-то работать на 2MB оперативки
ЕМ>На каком основании Вы неразрывно связываете многозадачность со всем перечисленным? Сама по себе многозадачность может быть реализована очень экономно — есть множество различных реализаций, даже для простых микроконтроллеров с десятками килобайт памяти.
Потому что эти фичи в мире средних компьютеров требовались примерно одновременно.
N>>Ну да, для себя и двух коллег в предельно специфичном варианте. ЕМ>Так я и не говорю, что все это уже тогда было близко к идеалу. Именно так — было несовершенно, ограничено, но таки работало. А большинство искренне считает, что переход на PC произошел непосредственно с перфокарт.
Я так не считаю, и где вы нашли такое большинство — я не знаю. У многих не было доступа к СМ/ДВК/... но то, что заметная часть думает, ещё не значит, что большинство.
N>>Я не помню такого на 360/370. ЕМ>Оно и на ЕС работало, по понятным причинам.
Нет, непонятно. На каких работало и где? Если "по приколу", то это не в счёт — нужно в чём-то распространённом хотя бы за пределами пары ВЦ (кто там жаловался про проблемы единства софта для БЭСМ-6)?
N>>А то, что вы "с парнями чисто по приколу" делали, оно было как, умело хотя бы подсказать, каким нескольким командам соответствует данный префикс? ЕМ>Умело, оно перебирало команды при нажатиях управляющих клавиш. Я, честное слово, не понимаю, что Вас удивляет — это же голимый примитив, мы тогда почти всё писали на ассемблере, и отнюдь не считали, что реализуем что-то авангардное или сложное.
Хорошо, не вижу причины не верить — накулибинить можно что угодно даже на коленке. Мне тогда интересно другое — почему такое не было реализовано в каком-то широко распространённом средстве.
Я вижу, например, следующую причину: такая возможность требует большого потока данных в обе стороны. Система, которая больше затачивалась на "у нас 1000 терминалов на один процессор, и терминал передаёт только изменённые поля" (как в БТМД) — плохо сочеталась с такой интерактивной подсказкой.
Это как раз и говорит о том, что фича пошла в широкое распространение только там, где она перестала мешать остальному. Вы концентрируетесь на одном аспекте — а давайте его выпятим, и не важно, что в ущерб всему остальному.
Для сравнения — LISP придуман в 1958-м, но его железо не тянуло. Первые реальные эксперименты — конец 60-х. Первые более-менее промышленные использования — 70-е. Заметно массово — 80-е.
И так фактически со всеми открытиями в IT... делались на бумаге и только через много лет получали реализацию.
ЕМ>>>>>В 70-е было полноценное интерактивное редактирование в реальном времени. N>>И как оно выглядело? ЕМ>Вы видели типичный визуальный текстовый редактор под DOS, работающий в текстовом режиме, типа MultiEdit/Lexicon? Вот так и выглядело, с поправкой на разрешение терминала, монохромность и способы управления отображением текста.
Такое редактирование вообще-то появилось в 60-е, с первыми дисплеями. Это вы уже недооцениваете прогресс. Но: никто его не делал через передачу каждого символа и обратно. У дисплея было поле ввода, в котором и возились. Я в 80-е даже работал в таких "IDE" для ЕС 10xx. По нажатию Enter шёл сигнал к процессору, и тот мог отдать команду "передать изменённое" или "передать всё".
Соответственно, например, не было прокрутки в современном виде (любое листание это передача полного буфера туда-обратно).
И даже в убойно дорогих дисплеях были смешнейшие проблемы вида:
> One effect of the 2848 delay line was that if a heavy person walked next to the controller, or if it was mounted next to a vibration source (like an elevator), digital bits of screen images would be lost on all of the video displays, which would then be repeated continuously through the feedback loop until a new video display was transmitted to all of the connected terminals.
Сейчас не поймут
ЕМ>>>Сохранить файл в фоне, запустить компилятор параллельным процессом, получить от него таблицы идентификаторов, зависимости и прочее N>>Ну вот, видимо, только от уровня где-то 4MB стало хватать. До этого — нет. ЕМ>Да откуда Вы это взяли? Для компиляции программы в десяток килобайт исходника (вполне себе серьезная программа по тем временам, многие утилиты ОС такими были) хватало нескольких десятков килобайт памяти, какие мега байты?
Опять же, по суммарным характеристикам системы. Пожалуй, это надо было сказать с самого начала, тут уже я недоработал. Но системы с одним выпяченным фактором в ущерб всему остальному — практически не выживали.
N>>В 70-е даже 32K в калькуляторе было неподъёмно. ЕМ>И зачем Вы уперлись именно в калькулятор?
Ну вы ж Д3-28 вспомнили. Я тут говорю в контексте этого воспоминания.
EM> Я привел пример создания достаточно сложной даже по современным меркам программы в голом машинном коде весьма примитивной машины, силами одного человека, за небольшой срок. В 70-е же хватало гораздо более мощной техники.
Да, хватало. И применяли её под заметно другие цели, а иначе нифига не окупалось.
ЕМ>>>И что из этого объективно невозможно без гигабайт и гигафлопсов? N>>Даже просто проанализировать движения глаз. ЕМ>В мозгу это успешно делают десятки-сотни тысяч нейронов, имеющих быстродействие на несколько порядков ниже.
При этом чем дальше, тем больше находят, что один нейрон это суперсложная система с памятью, хитрыми алгоритмами суммирования и т.п.
Если вы вспоминаете те ранние концепции, по которым нейрон это было что-то вроде сумматора на несколько бит, то они уже давно неактуальны.
И вполне возможно, что если пересчитать производительность на единицы измерения как для компьютеров, те гигафлопсы будут в пределах одного-единственного нейрона. Мы только начинаем это реально изучать.
The God is real, unless declared integer.
Re[20]: Тенденции в развитии микроэлектроники и ПО :)
Здравствуйте, netch80, Вы писали:
N>>>Одно отсутствие целочисленной арифметики чего стоит ЕМ>>А чего оно стоит? Кому конкретно оно мешало настолько, что они "даже кушать не могли"?
N>Оно мешало тем, что толщина кода на всё, что не было непосредственно вычислениями с плавающей точкой, на ней становилось дороже в несколько раз.
Какая еще "толщина кода"? За счет чего "дороже в несколько раз"? Можете объяснить подробнее? Только имейте в виду, что Вы про эту систему команд лишь где-то отрывочно читали, а я непосредственно в ней программировал несколько лет.
N>А так как даже просто подсчитать индексы в матрице это целочисленные вычисления, то подобная диверсия била по всему.
У тех, кто "где-то что-то слышал", возможно, и била. У тех, кто работал с машиной, арифметические команды над целыми числами, не требующие выравнивания порядков и нормализации, выполнялись за то же время, что и логические — примерно 0.5 мкс.
N>В IBM это поняли давно и сделали хотя бы систему команд универсальной с возможностью адаптации под конкретный стиль
Я знал немало людей, одновременно работавших на уровне системы команд как с IBM/ЕС, так и с БЭСМ-6. Ни разу не слышал сколько-нибудь систематических жалоб на любую из них. Обе были достаточно комфортны в постоянной работе, и лишь при первом знакомстве каждая казалась неудобной. А Вы где черпаете сведения?
ЕМ>>Даже не 16-ти, а 15-ти. Но для большинства задач этого хватало (надеюсь, про явление локальности Вы в курсе?).
N>Если "локальность" это "у нас машина для численных расчётов, а всё остальное пофиг", то да, в курсе. Если что-то другое — уточните, какую именно из 100501 локальностей вы тут имеете в виду.
Я имею в виду принцип локальности, он один, и работает везде, в том числе и в численных расчетах. Про остальные 100500 я не в курсе, Вас не затруднит бегло перечислить хотя бы десяток?
N>Ну а "большинство" задач в которых нельзя считать что-то размером больше чем 100x100 без жутких извратов...
Да Вы, похоже, толком и не представляете, как это работает. Вам вообще приходилось делать на ассемблере/автокоде не короткие вставки для ЯВУ, а достаточно сложные законченные программы?
N>В сегментной организации можно хотя бы без регулярного напряга ОС обратиться к другому сегменту, просто загрузил номер и пошёл. А тут что — просить ОС каждый раз хлопать страницами?
Какая разница, кого просить — процессор или ОС? В 286 переключение сегментов тоже занимало далеко не один такт. Переключение страниц через ОС, конечно, работало медленнее, но и там, и там грамотное программирование заключалось в том, чтобы не делать этого без нужды.
N>>>Когда сравнивали возможности БЭСМ-6 и S/360 — 360ка выигрывала в несколько раз по объёму выходного кода и по удобству написания под неё.
N>как раз описывают не связанное с библиотеками — а именно код типа "перемножить матрицу на вектор".
Можно примеров, где это прям "в несколько раз"?
N>Единственность аккумулятора — вообще самая первая глупость дизайна, которая приводит к тому, что операции загрузить в аккумулятор и выгрузить из него занимают больше всего остального.
Где Вы взяли эту глупость? Концепция аккумулятора происходит от того самого принципа локальности, и оптимальный код как раз и отличается связанностью операндов между собой. Выполнение операций вразнобой — один из признаков плохого кода. Задач, в которых операнды группируются вокруг операций, значительно больше, чем тех, где много изолированных пар операндов.
N>в линии PDP (не обязательно PDP-11!) есть куда более интересные примеры. И даже CDC1604 (и похожие), с которой любят сравнивать БЭСМ-6...
Да почти в любой системе команд есть "интересные примеры". Но среди серийных машин нет примеров явно, бесспорно неправильных и неудобных систем команд. Если машина пошла в серию — значит, она была признана пригодной для большинства применений, на которые была ориентирована.
N>>>Ностальгировать по этому смысла просто ноль целых фиг десятых.
ЕМ>>Мне совершенно не свойственна ностальгия по технике тех времен — разве что по самим временам. Мне досадно, когда люди теряют адекватное представление о ресурсах, реально потребных для решения той или иной задачи. Здесь очень уместно вспомнить классическую притчу Дейкстры о том, кто был "первым компетентным программистом".
N>cейчас под те же 8051 продолжают писать реальные шедевры. Или есть конкурсы по минимизации объёма, доходящие до "Pacman в 90 байт".
Так и умельцы собирать кораблик в бутылке тоже не перевелись. А какая часть авторов этих шедевров в состоянии изготовить не яркий пример для конкурса, а достаточно сложную, полнофункциональную, серийную программу, с адекватным потреблением ресурсов, и за вменяемое время?
N>>>"Круче" не конкретизируемый термин. Язык сам по себе безнадёжен. ЕМ>>А термин "безнадежен" — конкретизируемый?
EM>> Алгол-68 "круче" C++ прежде всего в плане сложности
N>потому он и почти забыт — что его сложность была неоправданной.
Это отдельный вопрос. Вы скажите, каким образом эту сложность сумели реализовать (и не раз) те "древние люди", что работали с "ужасами дизайна", не используя ни ООП, и ФП, ни прочих страшных слов?
Re[4]: Тенденции в развитии микроэлектроники и ПО :)
Здравствуйте, VladD2, Вы писали:
ЕМ>>Блин, да не в том дело, насколько шагнуло. А в том, что развитие микросхем сопровождалось улучшением всех без исключения потребительских характеристик. А развитие ПО, помимо улучшения одних характеристик, сопровождалось ухудшением (и значительным) других.
VD>Так и ПО сопровождалось улучшением всех без исключения потребительских характеристик. Скажем MS SQL Server 6 в подметки не годится MS SQL Server 2019. Он стал быстрее, надежнее, научился использовать современные железки...
"Научился использовать современные железки" вообще не относится к этому сравнению.
"Быстрее" — точно быстрее, если сравнить на _одинаковом_ железе? Или просто всё вокруг стало быстрее, от процессоров до SSD?
ЕМ>>С самого начала разработки ПО в середине прошлого века оно писалось тем количеством людей, которое или объективно требовалось, или имелось в наличии. Никаких ограничений не было никогда.
VD>Это вранье. В середине прошлого века ПО вообще не писалось. Тогда компьютеров еще не было.
Давай ты всё-таки будешь ближе к фактам, потому что "враньё" тут однозначно в твоих утверждениях. (Отредактировал со смягчением формулировок.)
Компьютеры появились в 1940-х в виде, близком к современному. Первый компьютер на архитектуре "хранимой программы", обычно называемой фоннеймановской — EDSAC — сделан в 1949 — до середины века.
OS/360, тот проект, по мотивам которого написан знаменитый "Мифический человеко-месяц", стартовал в 1964 и закончен в основе в 1966 (хм, таки быстро). Читаем оттуда же у Брукса:
Мое профессиональное становление в вычислительной технике первоначально было связано с программированием, однако в период 1956–1963 годов, когда разрабатывались автономные управляющие программы и языки высокого уровня, я занимался
в основном архитектурой компьютеров.
То есть на 1956 уже можно отнести вполне себе разработку ПО.
Ну или для тебя 1956, 1966 уже не середина прошлого века — ну тогда начни писать на русском языке ;\ а то на каком это не середина века, мне непонятно.
VD> А вот в 70-е ПО писалось очень небольшими группами людей. Просто не было технологий позволяющих писать ПО даже сотнями программистов.
То есть ты Брукса вообще не читал. Я как-то раньше полагал, что без этой книги (хотя бы раз прочитать) качественный программист не может существовать.
Спойлер: над OS/360 работало больше тысячи человек — явно указано в книге. А то и больше:
С 1963 по 1966 год на ее проектирование, реализацию и написание документации было затрачено, вероятно, около 5000 человеколет.
5000/3 ~= 1667, а учесть неравномерность — в пике до 2000, наверно.
И технология такая была и есть — называется "человеческий разум" со вспомогательными технологиями типа "декомпозиция", "спецификация интерфейсов", "прототипирование" и ещё много других, известных сейчас. Может, для кого-то это и новость
Тут интересно то, что Брукс говорит про "грубую силу" — эффективность такого комбината, наверно, была на порядок-два ниже современных. Но основы были заложены именно тогда — анализ разработки данного проекта заложил всю программную индустрию на десятилетия (IBM не стала скрывать эти детали, к счастью).
VD> ДОС был написан одиночкой. Над Эплами работали 2 человека. А это уже 80е. Я помню как ПО писалось в Госплане СССР. Его писали одиночки. Отлаживали чтением листингов. Загружали с перфокарт. Мрак! Никаких git-ов, TFS-ов и тому подобного еще не было. Железо было настолько медленным, что софт часто писали на ассемблерах и доводили до блеска.
ЕМ>>Примерно так и работали советские НИИ.
VD>Да ни хрена подобного. В те времена вообще сложного софта не было. У нас один ГУЁ сейчас сложнее всего софта, что был в Госплане СССР. Это факт.
Это факт одного отдельно взятого Госплана, который тут скорее антипример.
Я видел работу (сам не работал — ещё был совсем мал) работу киевского НИИ цен (подчинён Госплану? Госснабу? уже неважно) и чуть меньше — НИИ нефтехимии в 1984-1986. Перфокарты — только для особых режимов. Диски для основного софта и данных. Ленты для переноса данных между участниками процесса (а иногда и диски — но тут хуже с совместимостью).
И у нас было две "IDE" для редактирования любых текстов на дисплеях (дисплеи были — 4 штуки 7066 на ЕС1022 в Ценах и 8(?) штук 7920 на ЕС1033 в Нефтехиме) и запуска системных команд — примерно как сейчас из vim можно запускать команды — питерская JEC и киевская Вектор. Вокруг была больше знаменита московская Primus, но у нас в тех двух точках её почему-то не было.
И это провинциальное ведомство. А уж центральный Госплан... В таком богатом ведомстве "загружать с перфокарт"... Ну или ты работал в каком-то дохлом НИИ подчинённом пятому помощнику заместителя третьего дворника — это вероятнее всего — и ваша работа реально никому не была нужна.
ЕМ>>Несколько институтов, десятки-сотни отделов, сотни-тысячи человек, и почти никто не представлял себе продукта во всей совокупности. Для секретных разработок это было хорошо, а вот для всего остального... Потом, разумеется, каждый отдел спихивал ответственность за косяки на смежников.
VD>Да институтов то было дохера. Но даже компьютеров то в них было раз два и обчелся. Доступ к ним был по времени. Каждый писал свою мелкую программульку. Система учета зарплат уже была чем-то большим.
Что общение софтом было слабым — факт — всё держалось на личных связях. Но всё остальное что ты пишешь — какой-то лютый гон с обобщением личного опыта на весь космос, который не подтверждается как минимум моими данными и наверняка ещё нескольких современников (вон интересно, что Privalov вспомнит).
ЕМ>>Только электронщикам это позволяет делать многофункциональные, скоростные, надежные, и одновременно компактные и экономичные устройства, а вот автоматизация программирования пока работает в основном на bloatware.
VD>Мы уже выяснили, что твои заявления о ПО ложны.
Они спорны, и я их обсуждаю с EM, но твой метод участия тут точно не сработает.
Здравствуйте, netch80, Вы писали:
N>"Научился использовать современные железки" вообще не относится к этому сравнению. N>"Быстрее" — точно быстрее, если сравнить на _одинаковом_ железе? Или просто всё вокруг стало быстрее, от процессоров до SSD?
Точно быстрее. Иначе все бы ставили MS SQL 6 на новое железо. Но сама по себе постановка вопроса не корректна. Для того чтобы задействовать возможности нового железа уже нужны новые версии софта. Например, MS SQL 6 просто не умел использовать память за пределами первых 2 Гб.
N>Компьютеры появились в 1940-х в виде, близком к современному. Первый компьютер на архитектуре "хранимой программы", обычно называемой фоннеймановской — EDSAC — сделан в 1949 — до середины века.
Первый компьютер и "писались программы" — это две большие разницы. Смягчать тут просто не чего. Первые компьютеры вообще программировались в машкодах и только своими авторами.
N>OS/360, тот проект, по мотивам которого написан знаменитый "Мифический человеко-месяц", стартовал в 1964 и закончен в основе в 1966 (хм, таки быстро).
Тебе придется признать, что 1966-й — это совсем не середина прошлого века. Это уже почти 70-й год о котором мы и говорил. И 70-м начался реальный прогресс в области разработки ПО. Шел довольно долго и только в 2010-х пришел к тому, что можно называть современным уровнем.
70-е года — это были года развития языков программирования и компиляторов. Писать софт большими командами тогда было невозможно просто из-за отсутствия необходимого дял этого ПО. Ну, или производительность у подобных команд была ниже плинтуса.
N>Читаем оттуда же у Брукса:
N>Мое профессиональное становление в вычислительной технике первоначально было связано с программированием, однако в период 1956–1963 годов, когда разрабатывались автономные управляющие программы и языки высокого уровня, я занимался
Я для тебя специально жирным выделил. И 1956-й — это уже тоже не совсем середина века.
N>То есть на 1956 уже можно отнести вполне себе разработку ПО.
К начальным стадям на которых не что не задумывались о разработке ПО тысячными коллективами, а думали о том как с машкодов съахать на ассмеблеры, а с них на высокоуровневые языки. Если просто посмотреть на языки тех времен, то сразу поймешь какое они были говно и что на них можно было делать.
И того компьтеры появлись где-то во второй половине 20го века. До 70-х годов шло их становление и разработка языков высокого уровня. Первая пародия на систему контроля версий была создана в 1972. Но это была локальная система для IBM-мовских мэйнфрэймов. Публично ее зарелизили только в 1977 г. Реальное их развитие началось где-то в 80-е. В это же время были придуманы ООЯ и т.п. Причем вещи вроде сборочных конвейеров были придуманы еще позже, так как на мэйнфрэймах они вообще не имели смысла. Эволюция тех же систем контроля версий проходила банально на моих глазах. Еще в середине 90-х это было сташное говно плохо работающее по стеи. О каких тысячах разработчиков можно говорить в таком случае? Сотня то уже упиралась в их качество, а нормально их использовать можно было только на коллективах из десятков человек. CVS — 1990. Subversion — 2004. GIT — 2005. Причем до народа тот же гит доехал куда позже. И даже сейчас, на объемах реального коммерческого продукта GIT дико тормозит. MS сделал даже специальную версию гита с виртуальной файловой системой, чтобы можно было использовать подход Монорепы.
N>Ну или для тебя 1956, 1966 уже не середина прошлого века — ну тогда начни писать на русском языке ;\ а то на каком это не середина века, мне непонятно.
Конечно! Середина это 1950 год в который в реальности просто не было компьютеров у людей. Их только только налаживали к выпуску. Ни о какой разработке больших систем и речи в те времена идти не могло. А 1966 — это уже почти 1970, который ни при каких условиях к середине 20го века не отнесешь. А главное, что то, что что-то появлись в 1966м не значит, что это что-то попало в общественное пользование.
N>Спойлер: над OS/360 работало больше тысячи человек — явно указано в книге. А то и больше: N>
N>С 1963 по 1966 год на ее проектирование, реализацию и написание документации было затрачено, вероятно, около 5000 человеколет.
IBM — это были пионеры, которые до этого еще на механических машинах умудрялись не хилые объемы данных обрабатывать. Не надо выдавать единичный случай за общую практику. Ну, и производительность труда у них была по нашим меркам (нашим временам) никакая. И было это так именно из-за отсутствия необходимого софта. Они в общем-то и родили предков этого самого софта. Первая система контроля версий как раз и была на коленке для OS/360 сделаны в 1972 году. А до этого они без них обходились. Причем это была внутренняя тула IBM, т.е. для всего мира она не существовала. А зарелизили они ее в 1977м году, т.е. практически в 80-х когда и пошло эволюционное развитие систем управления разработки софтом и не закончилось и по сей день.
Ну, и эти 5000 человеколет это не были именно часы тех кто над софтом работал. Они нагревали атмосферу! Архитекторы проектировали на бумаге. Техрайтеры печатали на печатных машинках с рукописей. Сикретутки вбивали перфокарты. Операторы печатали распечатки на принтерах, ставили одни пленки, снимали другие. Отдельные программисты писали подпрограммы и ставили их в очередь на запуск. Ну, и производительность труда соответствующая. По современным меркам это примитивная ОС создавалась не реально раздутым коллективом.
То что они сделали обычные фирмы стали повторять только через десятки лет. Я лично видел как писался код в Госплан СССР, так как мой отец там работал. Они про системы контроля версий и не знали. А когда у них появились первые Писюки они просто визжали от счастья, так как программы стало возможно компилировать, запускать и получить результат сразу, а не записавшись в очередь и получив распечатку на следующий день. Сраный писюк поднял производительность программиста в сотни раз, так как программирование стало интерактивным процессом.
Читая разных Бруксов ты даже представить не можешь как они там в реальности работали.
N>5000/3 ~= 1667, а учесть неравномерность — в пике до 2000, наверно.
А что это за "3"?
Ну, так нулевая эффективность. О чем я тебе и говорю. Пробовать то такими коллективами что-то тварить можно было. Но результат плачевный. По современнм меркам это мелкая система.
В общем, околонулевая, да. Были б у них современные средства сделали бы тоже самое в десятки, а то и сотни раз быстрее и проще.
N>И технология такая была и есть — называется "человеческий разум" со вспомогательными технологиями типа "декомпозиция", "спецификация интерфейсов", "прототипирование" и ещё много других, известных сейчас. Может, для кого-то это и новость
Я главное выделил. Вот тогда только декомпозиция и знали, а банальной системы контроля версий не было. Народ экспериментировал в области ЯП. Только только от машкодов ушли. Люди уже понимали, что, например, кодом нужно управлять, но как — было не известно. SCCS — ту самую систему контроля версий — разработали только для System/370. System/360 писали без нее. Естественно испытывали боль. Два программиста уже один исходник поправить не могли. Интерактивности разработки не было. Ты должен был отдать свою программу операторам и те поставят ее в очередь. А результат на распечатке, на следующий день (а то и через неделю, если тебе время не выделили).
N>Тут интересно то, что Брукс говорит про "грубую силу" — эффективность такого комбината, наверно, была на порядок-два ниже современных. Но основы были заложены именно тогда — анализ разработки данного проекта заложил всю программную индустрию на десятилетия (IBM не стала скрывать эти детали, к счастью).
Да основы наверно были заложены еще теми кто мануфактуры придумал в 14 веке, а так же Генри Форд, когда придумал конвейер. Но одно дело основы, а другое готовые методологии и софт. А мы то сравнивеем не пионеров, а говорим о разработке ПО как об индустрии.
N>Это факт одного отдельно взятого Госплана, который тут скорее антипример.
Да все так работали. Мой отец был начальником отдела. В подчинении у него было где-то 10-20 баб. Но ты думаешь они писали софт? Вот их когда человекочасы считали, то учитывали не только их но еще операторов машинного зала и прочих вахтеров (коими там милиция выступала). У них был WANG на котором наверное какую-то отчетность писали. У них потом ПК повились на которых эта орда баб развлекалась.
N>Я видел работу (сам не работал — ещё был совсем мал) работу киевского НИИ цен (подчинён Госплану? Госснабу? уже неважно) и чуть меньше — НИИ нефтехимии в 1984-1986. Перфокарты — только для особых режимов. Диски для основного софта и данных. Ленты для переноса данных между участниками процесса (а иногда и диски — но тут хуже с совместимостью).
Ну, к 1986му в Госплане уже писюки появились, а перфокарты действительно стали отходить. Но в 1981м, когда я ходил в первый класс, блин, еще во всю использовались и у нас дома в комнате родителей стоял Лейпциг (стенка мебели во всю стену) верхние шкафы которой были заставлены перфокартами. Потом я их в школу относил, чтобы из них делать разного рода карточки со словами и рисунками.
N>И у нас было две "IDE" для редактирования любых текстов на дисплеях (дисплеи были — 4 штуки 7066 на ЕС1022 в Ценах и 8(?) штук 7920 на ЕС1033 в Нефтехиме) и запуска системных команд — примерно как сейчас из vim можно запускать команды — питерская JEC и киевская Вектор. Вокруг была больше знаменита московская Primus, но у нас в тех двух точках её почему-то не было.
Дисплеи были, но почему-то их особо для ввода программ не использовали. Стояли себе рядом с машинным залом. На них даже световые перья были. Вот только сделать с их помощью было ничего не льзя. Так только ребенку по экрану поводить.
N>И это провинциальное ведомство. А уж центральный Госплан... В таком богатом ведомстве "загружать с перфокарт"... Ну или ты работал в каком-то дохлом НИИ подчинённом пятому помощнику заместителя третьего дворника — это вероятнее всего — и ваша работа реально никому не была нужна.
Я тогда не работал. Работал мой отец. Но точно знаю, что загружали именно с перфокарт. А дисплеи эти почеу-то простаивали.
Просто реальность такова, что все огромные коллективы (причем не только у нас, но и у них) в реальности грели воздух! А работали в реальности одиночки или коллективы из нескольких десятков человек. А далее пошла эра ПК и до мэйнфрэймов первые годы им было как до луны. Все сильно деградировало. Те же системы контроля версий изобретались по новой. CVS появился в 1990м году!
N>Что общение софтом было слабым — факт — всё держалось на личных связях. Но всё остальное что ты пишешь — какой-то лютый гон с обобщением личного опыта на весь космос, который не подтверждается как минимум моими данными и наверняка ещё нескольких современников (вон интересно, что Privalov вспомнит).
Нет, просто ты начитался Брукса и думаешь, что то что он рассказывает было везде и всегда. А он писал об истории развития компьютерной техники. О пионерах. О том как делали лутую херню за бешенные деньги! Но и ее покупали потому как другой не было. Наше развитие всегда шло с отставанием. Наши ЕС — это и были копипасщенные IBM-ы с отставанием лет на 5. А эти огромные коллективы ни хера не делали. Работали в них одиночки и мелкие группы. НИИ цен? Сейчас это даже звучит смешно. Задачу вычисления оптимальной цены невозможно решить и сейчас. А главное ее просто не надо решать. Надо просто повышать цены на то, что пользуется излишним спросом пока цена не уравновесит предложение. Коммунисты занимались лютой херней!
N>Они спорны, и я их обсуждаю с EM, но твой метод участия тут точно не сработает.
Нет, нет. Я пример привел. Он это утверждение четко опровергает. Значит утверждение ложно. Других вариантов нет.
То что сегодня не обязательно писать идеальное по производительности ПО не означает, что его не пишут. Это всего лишь вопрос выбора приоритетов. Если производительность важна и за это платят, то софт будет быстрым. За эти десятки лет изобретены более быстрые алгоритмы. Софт адаптирован к более быстрому железу (чтобы иметь возможность использовать его преимущества). При прочих равных я всегда выберу оптимальный по производительности подход. Вопрос лишь в том стану ли я тратить большие ресурсы на оптимизацию, если производительности и так хватает. На выписывание и оптимизации может уйти много времени. Зачем его тратить, если и у пользователя и более простое решение не взывает нареканий? А ты берешь какой-то частный случай и делаешь на его основе общий вывод — "Софт не становится лучше". Становится еще как! Просто не всегда быстродействие критерий качества.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[6]: Тенденции в развитии микроэлектроники и ПО :)
Чтобы не отвечать по каждому абзацу (слишком много текста):
1. Я говорил про возможность такой разработки сверхбольшим коллективом в принципе, что ты отрицал с начала, а ты — переключился на её эффективность по сравнению с нынешними средствами.
2. "Середина века" нельзя понимать как один момент, это период минимум в 20 лет.
Прочее попунктно:
N>>"Научился использовать современные железки" вообще не относится к этому сравнению. N>>"Быстрее" — точно быстрее, если сравнить на _одинаковом_ железе? Или просто всё вокруг стало быстрее, от процессоров до SSD?
VD>Точно быстрее. Иначе все бы ставили MS SQL 6 на новое железо. Но сама по себе постановка вопроса не корректна. Для того чтобы задействовать возможности нового железа уже нужны новые версии софта. Например, MS SQL 6 просто не умел использовать память за пределами первых 2 Гб.
Вот именно — само по себе расширение до 64 бит уже в чём-то ускоряет, а в чём-то замедляет. И 100500 других фишек, которые могут быть на пользу в новых условиях, но никак не ускоряют чисто в аппаратных операциях.
VD>Первый компьютер и "писались программы" — это две большие разницы. Смягчать тут просто не чего. Первые компьютеры вообще программировались в машкодах и только своими авторами.
А что по-твоему это "писалось в машкодах", как не ПО?
Или есть ты признаешь за ПО только то, что продавалось? Ну тогда так и уточняй с самого начала.
VD> Это уже почти 70-й год о котором мы и говорил. И 70-м начался реальный прогресс в области разработки ПО. Шел довольно долго и только в 2010-х пришел к тому, что можно называть современным уровнем.
А тем временем придумано ещё множество фишек, которые выстрелят реально только в ближайшие 10-20 лет. И что?
Наработка началась одновременно с появлением компьютеров. То, что Брукс завершил свои концепции в конце 60-х, какой-нибудь Кент Бек оформил TDD в 2004 (а сейчас мы скорее видим его "диалектическое отрицание на новом витке развития") — это верхушка айсберга, 1% от него.
Подпишись на публикации ACM и посмотри, что нового приходит сейчас. Уверяю — там много интересного
VD>70-е года — это были года развития языков программирования и компиляторов. Писать софт большими командами тогда было невозможно просто из-за отсутствия необходимого дял этого ПО.
Писали. В той же OS/360 было несколько компиляторов.
VD> Ну, или производительность у подобных команд была ниже плинтуса.
Да, многого не было. Но они смогли стартовать на этой базе и показать пример остальным. Производительность и сейчас сильно разная — например, если учесть, что ~99% кода в итоге уходит в никуда, это какая производительность? Что толку с того, что мы сейчас можем наклепать компилятор или ОС за неделю? Те были сделаны за 3 года и использовались в миллионах экземпляров. Может, это тогда производительность была выше?
VD>К начальным стадям на которых не что не задумывались о разработке ПО тысячными коллективами, а думали о том как с машкодов съахать на ассмеблеры, а с них на высокоуровневые языки. Если просто посмотреть на языки тех времен, то сразу поймешь какое они были говно и что на них можно было делать.
О, ты ещё Nemerle вспомни, как раз в тему приплести.;(
Да, языки уровня повыше ассемблера развивались медленно — соответственно уровню техники и типовым задачам. Научная мысль всегда шла чуть впереди задач. Мы все избалованы законом Мура, а до начала активного внедрения его результатов (считай, начало-середина 1970х) техника мало что позволяла.
VD>И того компьтеры появлись где-то во второй половине 20го века.
Совершенно неадекватное определение, которое выхолащивает всю суть. Я не могу принять такое "итого" даже за первичную основу.
VD> До 70-х годов шло их становление и разработка языков высокого уровня. Первая пародия на систему контроля версий была создана в 1972. Но это была локальная система для IBM-мовских мэйнфрэймов. Публично ее зарелизили только в 1977 г. Реальное их развитие началось где-то в 80-е. В это же время были придуманы ООЯ и т.п. Причем вещи вроде сборочных конвейеров были придуманы еще позже, так как на мэйнфрэймах они вообще не имели смысла. Эволюция тех же систем контроля версий проходила банально на моих глазах. Еще в середине 90-х это было сташное говно плохо работающее по стеи.
Последнее слово не расшифровал, но вот тут точно не надо судить о всей индустрии по продукции Microsoft. Если ты другого не видел, это проблема личного кругозора.
VD> О каких тысячах разработчиков можно говорить в таком случае?
Ты, насколько вижу, совсем не понимаешь проблемы разработки в такой среде. Она не в отсутствии как таковой какой-то системы контроля версий (кому нужна была — тот покупал). Проблема в том, что вся среда (не только слабость VCS, а и, например, нереальная цена средств рефакторинга) приводила к дороговизне применения "гибких" подходов, неподъёмной для большинства — и поэтому "водопадная" модель была единственной массово пригодной для крупных разработок. А дальше — практически лотерея с качеством предсказания требований к моменту завершения разработки.
VD> Сотня то уже упиралась в их качество, а нормально их использовать можно было только на коллективах из десятков человек.
И ещё раз: решалось человеческим умом и стандартными средствами вроде определения интерфейсов между компонентами.
Проектировать крупные системы любого рода к тому времени уже научились. Что плохо умели — предсказывать требования к моменту запуска в эксплуатацию. Но это и сейчас не умеют, поэтому решают проблему средствами Agile.
VD>IBM — это были пионеры, которые до этого еще на механических машинах умудрялись не хилые объемы данных обрабатывать. Не надо выдавать единичный случай за общую практику.
И сколько таких "единичных случаев" будет? Вот с ходу второй вспомнился (см. фото со стопкой распечаток). Покопаться — ещё десяток найдём. Это сравнимо с объёмом всей индустрии того времени. Может, проблема не в бобине?
VD> Ну, и производительность труда у них была по нашим меркам (нашим временам) никакая. И было это так именно из-за отсутствия необходимого софта. Они в общем-то и родили предков этого самого софта. Первая система контроля версий как раз и была на коленке для OS/360 сделаны в 1972 году. А до этого они без них обходились. Причем это была внутренняя тула IBM, т.е. для всего мира она не существовала. А зарелизили они ее в 1977м году, т.е. практически в 80-х когда и пошло эволюционное развитие систем управления разработки софтом и не закончилось и по сей день.
Да, железо стало массово тянуть применение таких средств (без часовых задержек).
VD>То что они сделали обычные фирмы стали повторять только через десятки лет. Я лично видел как писался код в Госплан СССР, так как мой отец там работал. Они про системы контроля версий и не знали. А когда у них появились первые Писюки они просто визжали от счастья, так как программы стало возможно компилировать, запускать и получить результат сразу, а не записавшись в очередь и получив распечатку на следующий день. Сраный писюк поднял производительность программиста в сотни раз, так как программирование стало интерактивным процессом.
Ну вот это сходится с тем, что предполагает EM — сколько народу получило такую возможность только с приходом PC. А я ещё школьником видел и СМ-4, и СМ-1420, и ДВК, которые ещё в начале 80-х были, и всякие "Агаты", и побочные ответвления типа Электроники-85... (да, большинство PDP-11 в разных вариациях...) Да, это Киев, не совсем село, но и не Москва. Повторюсь — твой отец (и ты?) работали в каком-то совсем странном месте, если эти средства прошли мимо вас...
VD>Читая разных Бруксов ты даже представить не можешь как они там в реальности работали.
Не надо высасывать из пальца то, чего ты не знаешь и не можешь знать. Могу. Я работал с бумагой и перфокартами.
Вот с перфолентами не довелось, но видел их вплотную
N>>5000/3 ~= 1667, а учесть неравномерность — в пике до 2000, наверно. VD>А что это за "3"?
Года (1963-1966). Как ты читаешь, что это не очевидно?
VD>Я главное выделил. Вот тогда только декомпозиция и знали, а банальной системы контроля версий не было.
И им хватало еженедельных (например) бэкапов на бумаге и лентах.
VD> Народ экспериментировал в области ЯП. Только только от машкодов ушли. Люди уже понимали, что, например, кодом нужно управлять, но как — было не известно. SCCS — ту самую систему контроля версий — разработали только для System/370. System/360 писали без нее. Естественно испытывали боль. Два программиста уже один исходник поправить не могли.
И они успешно обсуждали друг с другом как это решать. И даже получалось
VD> Интерактивности разработки не было. Ты должен был отдать свою программу операторам и те поставят ее в очередь. А результат на распечатке, на следующий день (а то и через неделю, если тебе время не выделили).
И сейчас есть задачи, над которыми надо так работать (какие-нибудь нейросети — оно считает неделю и после этого ты видишь, правильно ли подобрал параметры). И что, от этого они становятся нерешаемыми?
N>>Это факт одного отдельно взятого Госплана, который тут скорее антипример. VD>Да все так работали. Мой отец был начальником отдела. В подчинении у него было где-то 10-20 баб. Но ты думаешь они писали софт? Вот их когда человекочасы считали, то учитывали не только их но еще операторов машинного зала и прочих вахтеров (коими там милиция выступала). У них был WANG на котором наверное какую-то отчетность писали. У них потом ПК повились на которых эта орда баб развлекалась.
Тогда не понимаю, зачем им перфокарты. На них приносили данные?
N>>И у нас было две "IDE" для редактирования любых текстов на дисплеях (дисплеи были — 4 штуки 7066 на ЕС1022 в Ценах и 8(?) штук 7920 на ЕС1033 в Нефтехиме) и запуска системных команд — примерно как сейчас из vim можно запускать команды — питерская JEC и киевская Вектор. Вокруг была больше знаменита московская Primus, но у нас в тех двух точках её почему-то не было. VD>Дисплеи были, но почему-то их особо для ввода программ не использовали. Стояли себе рядом с машинным залом. На них даже световые перья были. Вот только сделать с их помощью было ничего не льзя. Так только ребенку по экрану поводить.
Значит, у вас почему-то не хотели ставить этот софт. Причины мне неизвестны, но он был — уж из трёх-то возможных источников можно было выбрать.
Или дисплеи поставили нерабочими (да, вполне верю).
VD>Просто реальность такова, что все огромные коллективы (причем не только у нас, но и у них) в реальности грели воздух! А работали в реальности одиночки или коллективы из нескольких десятков человек. А далее пошла эра ПК и до мэйнфрэймов первые годы им было как до луны. Все сильно деградировало. Те же системы контроля версий изобретались по новой. CVS появился в 1990м году!
CVS стал развитием RCS с принятием части идей из SCCS. RCS была сделана как упрощение SCCS для доступных средств. SCCS это, похоже, и есть та система, что ты говоришь про S/370.
Ничего не "изобреталось", использовались уже существовавшие идеи, хотя многое в деталях подновлялось (алгоритмы мержей, например, активно развиваются и сейчас).
Деградация была только у нас, потому что был тотальный перелом. У остальных шёл эволюционный процесс переноса существующих идей на новые технические средства, которые заполняли новую, неизвестную до того нишу. Вот что показательно это что именно новые ниши становились основными (PC это один пример, а мобилки, например, достаточно свежий).
Для примера: CP/M, а позднее MS-DOS, разрабатывались на эмуляторах на мейнфрейме
N>>Что общение софтом было слабым — факт — всё держалось на личных связях. Но всё остальное что ты пишешь — какой-то лютый гон с обобщением личного опыта на весь космос, который не подтверждается как минимум моими данными и наверняка ещё нескольких современников (вон интересно, что Privalov вспомнит). VD>Нет, просто ты начитался Брукса и думаешь, что то что он рассказывает было везде и всегда.
И снова странная приписка мне, что я думаю. Не надо так делать.
VD> А он писал об истории развития компьютерной техники. О пионерах. О том как делали лутую херню за бешенные деньги! Но и ее покупали потому как другой не было.
Эти "бешеные деньги" сравнимы со стоимостью того же железа. Всё это было дорого, да.
VD> Наше развитие всегда шло с отставанием.
Я не ориентируюсь на специфику СССР в этом обсуждении.
VD> Наши ЕС — это и были копипасщенные IBM-ы с отставанием лет на 5.
Ближе к 10, и что?
VD> А эти огромные коллективы ни хера не делали. Работали в них одиночки и мелкие группы. НИИ цен? Сейчас это даже звучит смешно. Задачу вычисления оптимальной цены невозможно решить и сейчас. А главное ее просто не надо решать. Надо просто повышать цены на то, что пользуется излишним спросом пока цена не уравновесит предложение. Коммунисты занимались лютой херней!
Вообще-то разумное планирование нужно везде и всегда, даже там, где в мелочах процветает рыночный подход. И весь мир так и делает (и США, и Европа, и Китай, и Россия, и Индия...) И есть ресурсы, для которых рыночное поведение недопустимо в условиях перекосов и дефицитов. Странно слышать от тебя предложение не управлять ценами вообще.
N>>Они спорны, и я их обсуждаю с EM, но твой метод участия тут точно не сработает. VD>Нет, нет. Я пример привел. Он это утверждение четко опровергает. Значит утверждение ложно. Других вариантов нет.
Что именно ты считаешь таким примером? Я не понял, тут слишком много разного.
VD> А ты берешь какой-то частный случай и делаешь на его основе общий вывод — "Софт не становится лучше". Становится еще как! Просто не всегда быстродействие критерий качества.
Ты меня явно с EM перепутал. И он говорил не о частных случаях, он говорил об общей картине (статистически значимой) так, как он её видит, с несколькими иллюстрациями.
Это принципиально. И вот насколько его видение адекватно — можно и нужно обсуждать, но не циклиться на примерах.
The God is real, unless declared integer.
Re[7]: Тенденции в развитии микроэлектроники и ПО :)
Здравствуйте, netch80, Вы писали:
N>1. Я говорил про возможность такой разработки сверхбольшим коллективом в принципе, что ты отрицал с начала, а ты — переключился на её эффективность по сравнению с нынешними средствами.
Мы говорили о прогрессе в разработке ПО. Ты заявил о том, что в середине века разрабатывали большие системы большим количеством людей. Но это враньё, так как середине века компьютеры только разрождались. Единственный пример — IBM доказывает ровно обратное. 5000 человеколет на то, что сейчас за 5 человеколет, а то и за один. Ни в 1950-м, ни в 1960-м компьютеров, в смысле массового явления, в мире еще не было. А стало быть серьезно о разработке больших систем говорить нельзя. Не было и никакого ПО для автоматизации разработки. Не было даже баз данных.
N>2. "Середина века" нельзя понимать как один момент, это период минимум в 20 лет.
Вообще-то середина века понятие четко детерминирована — это хх50 год. Но даже если обобщить это понятие до второй трети, она закончилась в 1965-м году и в это время опять таки компьютеры еще не вышли за пределы лабораторий. В СССР же первые серийные компьютеры появились вообще в середине восьмидесятых.
N>Вот именно — само по себе расширение до 64 бит уже в чём-то ускоряет, а в чём-то замедляет. И 100500 других фишек, которые могут быть на пользу в новых условиях, но никак не ускоряют чисто в аппаратных операциях.
Да не обязательно даже 64-бит. В 32битных версиях можно было задействовать 3-й Гб в Виндовс или расширенную помять. Но факт в том, что даже если ограничить память первыми двумя гигабайтами, MS SQL 7.0 переписали чуть ли не с нуля, что сильно увеличило его производительность. В MS SQL 6 тормозила даже компиляция запроса с дойном на 10 таблиц по схеме звезда. В MS SQL 7 с этим стал по лучше. В 2000 всякие проблемы исчезли. В общем, развитие шло как по пути улучшения алгоритмов, так и по пути улучшения взаимодействия с железом. Например, в одной из версий (уже не помню какой) появилась поддержка версионирования, что повысило многопользовательскую производительность. MS SQL 6 здесь уже просто сравнивать нельзя, так как в нем многопользовательские сценарии все приводили к блокировкам.
N>А что по-твоему это "писалось в машкодах", как не ПО?
Боль! Примерно как сроить компьютеры на механических вычислителя или на лампах. А переход от машкодов хотя бы к ассемблерам был грандиозным скачком сравнимым с переходом с механики на лампы или с ламп на полпроводники.
N>Или есть ты признаешь за ПО только то, что продавалось? Ну тогда так и уточняй с самого начала.
Мы говорили об индустрии разработке ПО и о средствах их разработки. Ты решил поддержать не выдерживающую критики, на мой взгляд, теорию Музыченко о том, что разработка ПО не развивалась как это было в области микросхем. Начал утверждать про какие-то мифические возможности разработки ПО средствами тысяч разработчиков в середине прошлого века. Но это ж чушь! Середина прошлого века — это точка в которой компьютеры стали появляться. Шла бурная эволюция, как и в микросхемах. Причем эволюция шла в сторону развития мэйнфреймов. А в 80 она пошла заново, так как от мэйнфреймов отказались и перешли сначала на ПК, а потом на их сети.
Люди учились писать софт от малого к большому. Нарабатывали технологии совместной разработки. В некоторых областях и сейчас дремучие 60-е прошлого столетия. Например, в C++ до сих пор нет модульной системы! А это язык, с дуру, повсеместно использует и приводит к дикому замедлению сборочного процесса. Но, конечно, есть и хорошие примеры. Почти все другие языки имеют те или иные модульные системы.
N>А тем временем придумано ещё множество фишек, которые выстрелят реально только в ближайшие 10-20 лет. И что?
Я таких фишек не видел. Много видел как люди не воспринимали прогрессивного. Но чего-то реально нового, что могло бы поднять скорость и качество разработки ПО радикально я не вижу. А я изучением нового как раз занимался не мало. Скорее будет долгая эволюция, которая будет приводить к небольшим улучшениям, которые накопишвись превзойдут текущий уровень.
N>И что?
И то. Это и есть прогресс. Не важно встрелят они или просто эволюционно улучшат положение дел — это прогресс, которые очень даже ощутим, если не звиздить как Троцкий, что "еще в середине прошлого века...".
N>Наработка началась одновременно с появлением компьютеров. То, что Брукс завершил свои концепции в конце 60-х, какой-нибудь Кент Бек оформил TDD в 2004 (а сейчас мы скорее видим его "диалектическое отрицание на новом витке развития") — это верхушка айсберга, 1% от него.
Да ничего Брукс не придумал в 60-х. Они базу создали. ГовноОС, если сравнивать ее с любой ОС из современного телефона. Эволюция разработки софта шла всю жизнь и идет сейчас. В те времена современные объемы кода были просто не мыслим. IBM просто обосрался бы, если бы попытался написать современную Windows 10 или Android 12 на том развитии софтостроения (даже если железо бы того позволяло). Собственно IBM и обосрался чуть позже, когда выпустил свои OS/2. В прочем его своим и назвать то нельзя, так как по сути там уже в базе была Windows. Брутфорс он не канает в наши времена.
N>Подпишись на публикации ACM и посмотри, что нового приходит сейчас. Уверяю — там много интересного
Спасибо, у меня есть чем заняться и чем развлекаться. В разработке софта тоже есть много нового.
N>Писали. В той же OS/360 было несколько компиляторов.
Говноязков. А потом все на С переписали. Ты путаешь индустриальную разработку и пионеров граничащих с исследовательской деятельностью. IBM сделал большой вклад в развитие софтостроения. Но кроме него в этом процессе принимало участие множество других компаний. И было это уже в 70-е, 80-е, 90-е, 00-е и даже в 10 и 20. Процесс идет до сих пор. Не так бурно как в начале, но идет.
VD>> Ну, или производительность у подобных команд была ниже плинтуса.
N>Да, многого не было. Но они смогли стартовать на этой базе и показать пример остальным. Производительность и сейчас сильно разная — например, если учесть, что ~99% кода в итоге уходит в никуда, это какая производительность?
А если глупостей не учитывать? Я что-то не заметил, чтобы мой код уходил в никуда. Если я даже его переписываю, но прошлая версия этого кода уже работала в релизной версии продукта. Иногда не долго, так как это тестовое использование (например, A/B-тестирование). Но все же несколько тысяч человек его использует.
N>Что толку с того, что мы сейчас можем наклепать компилятор или ОС за неделю?
Не можем. Точнее можем такое же говно как OS/360 для 1-2 железок. Но такое качество сейчас никому не нужно. Современная ОС — это огромныные кучи кода, большая часть из которой — драйвера.
N>Те были сделаны за 3 года и использовались в миллионах экземпляров. Может, это тогда производительность была выше?
Какими на фиг миллионами? Акстись! Миллоны — это сейчас. Выпуск IBM System/360 чуть не завалил саму IBM. Она тупо надорвалась. И выпустили они ее в 1964-м году, так что в реальности ее стали осваивать уже в третьей трети 20го века. И о какой-то там разработке масштабного ПО просто не приходилось говорить. Повторюсь сраный сорс-контрол был зарелизен IBMом в 1977м году!
70-е стали первой вехой в эволюции разработки ПО. А в итоге все эти мэйнфреймы пошли в помоечку, а сегодняшние суперкомпьютеры — это банальные кластеры серверов, т.е. по сути связка ПК. Вычислительные мощности одной современной топовой видеокарты сравнимы с вычислительными мощностями всех компьютеров 70-х, наверно.
N>О, ты ещё Nemerle вспомни, как раз в тему приплести.;(
А что мне его вспоминать то? Он и на сегодня по ряду свойств является передовым языком, а появился он только в 00-ых. Разные IBM-ы и Microsoft-ы тупо пока не дорасли до такого. Макросы для них это "слишком большая пушка" (точная цитата Хельсберга). Хотя отдельные фичи они за 20 лет переняли. И вот через 20 лет современный C# недотягивает до Nemerle 2003-го года.
N>Да, языки уровня повыше ассемблера развивались медленно — соответственно уровню техники и типовым задачам. Научная мысль всегда шла чуть впереди задач. Мы все избалованы законом Мура, а до начала активного внедрения его результатов (считай, начало-середина 1970х) техника мало что позволяла.
Закон мура на производительность уже давно не влияет, кстати. Транзисторы удваиваются, но общая производительность от этого линейно не растет. Казалось бы уже можно науку привлекать. Но процесс действительно идет медленно. Но мы то не об этом. Мы о том, что процесс шел и идет! От полупроводников тут особых отличий нет. Он был более бурным в 70-80, но идет и сейчас.
N>Совершенно неадекватное определение, которое выхолащивает всю суть. Я не могу принять такое "итого" даже за первичную основу.
Набором, совершенно адекватное, в отличии от утверждения, что в середине века что-то там делали большого объема.
Именно в середине века фактическое появление. В 60-х развивались архитектуры, ОС, параллельные вычисления, в 70-повявление зачатков софта для разработки ПО большими коллективами, в 80 крах мэйнфреймов и новая эволюция ПК, которые переизобретали все с нуля. Далее в развитие включилась масса народа и пошло стабильное эволюционное развитие. Сейчас этот процесс замедлился, но все же идет. То же железо до сих пор не предоставляет массового параллелизма (если не считать случаев суперкомпьютеров). А казалось еще в 70 об этом мечтали.
Вообще, все очень похоже на освоение космоса. Бурное развитие на энтузиазме. Угасание энтузиазма и переход в стадию постепенного эволюционного развития.
N>Последнее слово не расшифровал, но вот тут точно не надо судить о всей индустрии по продукции Microsoft. Если ты другого не видел, это проблема личного кругозора.
Я видел все. Но МС отличный представитель своего времени. Все развивались точно так же. Первые Макинтоши собирались на коленке из процессоров выдранных из каких-то там бытовых девайсов. Точно так же писались первые СБУД. Да еще в IBM придумали SQL и саму идею реляционной СУБД. Но их труд сдох вместе с мэйнфреймами. Да и звезд он с небе на хватал. А верх взяли разные Oracle и Sybase, которые в те времена были игрушками. Ну, а МС сумел развиться из компании состоящей из нескольких человек в мега-корпорацию.
Я вот тебе больше скажу. Я сейчас в Касперсом работаю. Сейчас флагманский продукт — Каспексий Антивирус для ПК — это огромная гора кода давно переставшая быть просто антивирусом, а начинался то он с утилитой которую Касперский написал в одиночку. И так было почти с любым ПО. ДОС написал одиночка и в последствии продал его МС. Оракл написал Лари Элисон с двумя приятелями. Было это в 1977-м. В последствии Оракл превратил в мегакорпорацию.
N>Ты, насколько вижу, совсем не понимаешь проблемы разработки в такой среде. Она не в отсутствии как таковой какой-то системы контроля версий (кому нужна была — тот покупал). Проблема в том, что вся среда (не только слабость VCS, а и, например, нереальная цена средств рефакторинга) приводила к дороговизне применения "гибких" подходов, неподъёмной для большинства — и поэтому "водопадная" модель была единственной массово пригодной для крупных разработок. А дальше — практически лотерея с качеством предсказания требований к моменту завершения разработки.
Ну, конечно, куда мне серому и убогому до понимания того как пишется большой софт.
Системы контроля версий и еще 100500 систем — это без чего разработка софта большого объема невозможны. Ну, или превращают разработку в мало эффективный АД. Конечно, это все инструменты. Но без них попросту нельзя. Производительность твоего труда снизится настолько, что ты завязнешь и тебя обойдут конкуренты.
Что по поводу водопад vs. агил, то мне кажется это надуманно. Я вот и не возьмусь сказать что у нас в итоге получается. Может это классический водопад, а может SCRUM со спринтами в полгода-год.
С одной стороны, у нас постоянный выпуск релизов на билдконвеере. Но с другой есть реальные релизы между которыми идет полноценный водопадный процесс. Ну, требования в виде огромных талмудов с кучей текста у нас нет. Но набор требований все же есть. Причем как в виде екселек, так и в виде экранов гуев (для гуевых фич). И пойди скажи что это, гибкий водопад или затянутый SCRUM. Постоянное тестирование и выпуск реализов по 2-3 раза в день как в агилах. Но полноценные и затяжные итерации с планированием, реализацией, тестирование и последующей поддержкой как в водопаде.
Вот декомпозиция она всегда рулит — да. Почти любая разработка сегодня — это добавление функционала к чему-то готовому и большому. А значит нужно вплетать новый код в уже имеющийся и при этом его не поломать. Отсюда вытекает необходимость в тестах или постоянном ручном тестировании (или и в том и в другом). Задача тестов — предотвратить регрессию. Но сами тесты — это зло, которое приходится терпеть. Ведь требуют время на поддержку и фиксируют реализацию (а значит препятствуют изменению кода). А идея TDD она, на мой взгляд, не сильно производительная.
А вот как изменять ПО без системы контроля версий, отладки дампов и прочих современных фич я действительно представить не могу. Ну, если ты пишешь код один и этот код работает только у тебя, то может без этого и можно обойтись. Но если у тебя есть хотя бы пара десятков коллег пишущих код, ты пузо надорвешь без таких систем.
N>И ещё раз: решалось человеческим умом и стандартными средствами вроде определения интерфейсов между компонентами. N>Проектировать крупные системы любого рода к тому времени уже научились. Что плохо умели — предсказывать требования к моменту запуска в эксплуатацию. Но это и сейчас не умеют, поэтому решают проблему средствами Agile.
Еще раз: IBM OS/360 — это детская игрушка по сегодняшним времена. 5000 человекочасов на нее — это немыслимый перерасход времени и средств. И все это из-за неумения создавать такие системы и отсутствия ПО поддержки разработки.
А с интерфейсами проблему научились решать довольно быстро. Хотя до модулей некоторые не дожили и по сей день.
Что до предсказания требований, то это, похоже, только в твоей голове имеющаяся проблема. У нас с этим проблем особо нет. Требования расписываются еще до разработки новой версии и полностью выполняются в процессе. Ну, разве что уточняются в процессе, так как формализация требований процесс недетерминированный и не автоматизированный, к сожалению. Программист всегда найдет что-то не описанное. Но в целом с требованиями проблем нет. А вот с определением сроков всегда проблема есть. Обычно люди сильно занижают сроки. Ведь редко когда видно все детали наперед. А черт кроется в деталях.
N>И сколько таких "единичных случаев" будет? Вот с ходу второй вспомнился (см. фото со стопкой распечаток). Покопаться — ещё десяток найдём. Это сравнимо с объёмом всей индустрии того времени. Может, проблема не в бобине?
Да вот он наверно один и есть. Еще параллельно работала Bell Labs (AT&T). Но они долгое время работали в стол (для внутренних нужд). Толпа нарастала уже потом, когда IBM и Bell Labs зарелизили свои системы. Unix появился в 1971м, например. Мы до сих пор это ощущаем, так как системное время унихах измеряется от 1970го года. Собственно в процессе работы над Unix родился один из самых успешных ЯП — C. А вот долгие заседания комитетов по Алголу ни хрена по сути не дали. Ну, разве что толкнули Вирта на создание другого довольно популярного языка — Паскаля.
N>Да, железо стало массово тянуть применение таких средств (без часовых задержек).
Да ладно! По тем времена они очень даже тянули. А на сегодня у нас, откровенно говоря, git не тянет. Даже с костылями от MS (GVFS) тормозит на наших объемах адски! В прочем, это скорее из-за новомодных Монорем.
N>Ну вот это сходится с тем, что предполагает EM — сколько народу получило такую возможность только с приходом PC. А я ещё школьником видел и СМ-4, и СМ-1420, и ДВК, которые ещё в начале 80-х были, и всякие "Агаты", и побочные ответвления типа Электроники-85... (да, большинство PDP-11 в разных вариациях...) Да, это Киев, не совсем село, но и не Москва. Повторюсь — твой отец (и ты?) работали в каком-то совсем странном месте, если эти средства прошли мимо вас...
Ты что-то там себе навыдумывал. СМ-1420 появилась в 1983-ем и была страшным говном. СМ-1420-1 с аж почти 2 мегами оперативки в 1985-м. А до людей это все доезжал еще позже. Ты еще расскажи мне историю, как на СМ-1420 (первого выпуска) работал коллектив из 100 человек. Не может и работали. Но выглядело это очень грустно. Каждому приходилось небольшой кусочек времени в дено, а то и в неделю.
Я вот сейчас вспоминаю сколько мой отец притаскивал домой бумаги в виде распечаток. Его одна отладочная сессия стоила государству, наверное, в сотню баксов.
В общем, ты как-то странно оцениваешь время и развитие. Вот появился СМ-1420 и все у всех он есть, все уже прогаммы коллективами в 1000 человек к нему разрабатывают. Но это же лажа. Говномашина с 128К оперативки работающая крайне медленно. Крайне дорогие носители памяти. Все это надо освоить. Переложить на программы то что раньше считали полуручным способом. Это все требовало времени. Наверно были те кто брался за все это большими коллективами, но они испытывали боль и имели крайне низкую эффективность. Потом люди тупо привыкли все делать по старым лекалам. Написать пару талмудов документации! Провести пару симпозиумов и конференций. А в итоге родить мышь.
N>Не надо высасывать из пальца то, чего ты не знаешь и не можешь знать. Могу. Я работал с бумагой и перфокартами.
Ну, и сколько сотен человек было в твоей команде?
N>Вот с перфолентами не довелось, но видел их вплотную
Я слава Богу с перфокартами только играл, а перфолентами только обматывался. Но по счастливому лицу отца сразу понял, что PC — это круто. Потому и учился программировать на них. Но все это я видел. И у мет сомнений, что с современными методами это все сравнивать нельзя. Между ними пропасть. Ваши агилы сталы возможны только потому, что железо стало это позволять. Я вот комичу код и через пару часов получаю релиз продукта, который прошел тесты и проверяется тестерами. А мой отец вставал в очередь. Получал распечатку на следующий день и все выходные ее просматривал (длинна у них порой была адская). А я из ни потом разную херню мастерил. У нас производительность труда несопоставимая.
N>И им хватало еженедельных (например) бэкапов на бумаге и лентах.
Если бы хватало, они бы их не создали. А они создали.
Понимаешь, можно все делать дико через жопу. Например, можно копать траншеи лопатами. При этом задействовать 5000 человек и вырывать траншею за неделю. А можно взять роторный экскаватор и одним человеком вырыть его за день. Но при усложнении задачи она просто перестает решаться. Крымский мост лопатой и киркой не построить. Такая же фигня с софтом. Можно без методологий, систем контроля версий, систем управления процессами, сборочных конвейеров, ферм тестирования, отладчиков дампов, удаленных отладчиков, виртуальных машин, современных безопасный ЯП и т.п. пробовать писать сложный большими коллективами. Но получаться будет так себе.
N>И они успешно обсуждали друг с другом как это решать. И даже получалось
Ну, вот между обсуждением и реальным решением лежит пропасть. Уверен, что прежде чем они создали VCS они несколько раз хлебнули говна в результате затирания кода и ручного мержа. Потом придумали дифилку. А затем и VCS. Вот и получилось, что с условного 1950-го до 1960-го было развитие вообще базовых вещей вроде перехода от машкодов к высокоуровневым ЯП и создание ОС. В 60 поперло базове развитие. К 1970-м что-то даже можно было использовать. А там началась эра ПК и все начлось сначал
N>Ты меня явно с EM перепутал. И он говорил не о частных случаях, он говорил об общей картине (статистически значимой) так, как он её видит, с несколькими иллюстрациями. N>Это принципиально. И вот насколько его видение адекватно — можно и нужно обсуждать, но не циклиться на примерах.
Ну, так я понимаю ты его теорию и защищаешь. Как по мне это просто не знание истории. Или не желание ее знать. За 70 лет прошел не хилый такой прогресс. Если Брукс увидел средства которые есть у нас сейчас и софт который мы сейчас создаем он бы офигел. Тут кто-то правильно заметил, что в 1988м бурам сел на автомате. Но это почти 90-й! И тогда это было чудом. А сейчас в любом сразном Боинге или Аэрбасе система автоматической посадки, которой хлопают разные дебилы при посадке.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[8]: Тенденции в развитии микроэлектроники и ПО :)
Здравствуйте, VladD2, Вы писали:
N>>1. Я говорил про возможность такой разработки сверхбольшим коллективом в принципе, что ты отрицал с начала, а ты — переключился на её эффективность по сравнению с нынешними средствами.
VD>Мы говорили о прогрессе в разработке ПО. Ты заявил о том, что в середине века разрабатывали большие системы большим количеством людей. Но это враньё, так как середине века компьютеры только разрождались.
И опять твоё странное понятие что считать серединой века и "враньё" всё что не входит в неё. Как-то сложно дискутировать при таком стиле оппонента.
VD> Единственный пример — IBM доказывает ровно обратное. 5000 человеколет на то, что сейчас за 5 человеколет, а то и за один. Ни в 1950-м, ни в 1960-м компьютеров, в смысле массового явления, в мире еще не было. А стало быть серьезно о разработке больших систем говорить нельзя. Не было и никакого ПО для автоматизации разработки. Не было даже баз данных.
Именно, что при тотальном отсутствии автоматизации — была произведена первая обкатка подходов в принципе — и сформулированы концепции, которые актуальны и сейчас, и будут оставаться актуальны ещё долго.
С твоим же подходом нужно отрицать, например, всю теорию численных расчётов за времена до формализации IEEE 754 — хотя управлять точностью расчётов умели ещё в древнем Вавилоне. Да, им это было в ~1000 раз дороже, чем нам сейчас с бумагой — но они это сумели.
VD> В СССР же первые серийные компьютеры появились вообще в середине восьмидесятых.
Моя твоя совсем перестать понимать. "Серийные" это какие? Смотрю в вики:
БЭСМ-2: 1958-1962, 67 штук.
М-20: 1959-1962, 20 штук.
БЭСМ-4: 1965-?, 30 штук.
БЭСМ-6, которую так хвалит ЕМ: 1967-1987, 355 штук.
ЕС-1030: 1973-?, 436 штук.
ЕС-1050: 1973-?, 87 штук.
ЕС-1022: 1975-?, 3929 штук.
М-220: 1968-1974, 810 штук (если с М-222).
Минск-32: 1968-1975, 2889 штук.
Наири: 1964-1970, 500 штук.
Какие "в середине восьмидесятых"? Это ты безнадёжно занёсся (смягчённо говоря), потеряв хоть какое-то понимание реальности (и всё время говоришь "враньё" на других).
VD> MS SQL 7.0 переписали чуть ли не с нуля, что сильно увеличило его производительность. В MS SQL 6 тормозила даже компиляция запроса с дойном на 10 таблиц по схеме звезда.
OK, ты замечательно выбрал ветряную мельницу для битья. А теперь сравни MS SQL 7 (а не 6, раз для тебя 7 так переписан с нуля) с современным.
Впрочем, я не разбираюсь в MS SQL на уровне дальше запустить сервис и нарисовать пяток таблиц, так что наверняка ты и тут какой-то пример найдёшь — но о чём это говорит?
Возьми что-то другое. Windows, Visual Studio...
N>>А что по-твоему это "писалось в машкодах", как не ПО? VD>Боль! Примерно как сроить компьютеры на механических вычислителя или на лампах. А переход от машкодов хотя бы к ассемблерам был грандиозным скачком сравнимым с переходом с механики на лампы или с ламп на полпроводники.
Тем не менее писали. И то, что результат сохранён, было ценнее, чем сложность написания. Если уж так считать, то революция произошла не на этом этапе, а когда появились 1) ассемблер который генерирует объектники вместо абсолютных бинарников и 2) линкер для создания бинарника из объектников (в современных терминах). Потому что без линкера хотя на Idris пиши — всё одно собирать и запускать это будет тяжело.
N>>Или есть ты признаешь за ПО только то, что продавалось? Ну тогда так и уточняй с самого начала. VD>Мы говорили об индустрии разработке ПО и о средствах их разработки. Ты решил поддержать не выдерживающую критики, на мой взгляд, теорию Музыченко о том, что разработка ПО не развивалась как это было в области микросхем.
Нет, я её не поддерживал. Я возражал против твоей откровенно неумеренной и фантастической критики на основе твоего глубокого невежества в истории, и продолжаю делать это и сейчас.
"Теория" EM содержит очень много преувеличений, но и здравое зерно в ней есть — надо только его аккуратно отделить, а не рубить бензопилой всё, как делаешь ты.
VD> Начал утверждать про какие-то мифические возможности разработки ПО средствами тысяч разработчиков в середине прошлого века. Но это ж чушь! Середина прошлого века — это точка в которой компьютеры стали появляться. Шла бурная эволюция, как и в микросхемах. Причем эволюция шла в сторону развития мэйнфреймов. А в 80 она пошла заново, так как от мэйнфреймов отказались и перешли сначала на ПК, а потом на их сети.
И снова ты не учитываешь множество промежуточных элементов истории, причём так, что нельзя иначе понять, что ты настолько невежественен, что не знаешь самых основ
Для сравнения: S/360 это 1964 год. А PDP-1 (один из первых серийных компьютеров тогдашнего класса "мини", а не "мейнфреймов" это 1958-й (в вики 1959-й)! Линия "мини" пошла очень рано параллельно "мейнфреймам". В 1970-х их уже было около десятка видов. Далее, Apple I это 1976, и он не первый в классе "микро" (вон, MCM/70 это 1973). Какие 80-е?
Может, ты начнёшь хоть иногда читать источники прежде чем изрекать утверждения "фантастического масштаба и фантастической же глупости" (c)?
VD>Люди учились писать софт от малого к большому. Нарабатывали технологии совместной разработки. В некоторых областях и сейчас дремучие 60-е прошлого столетия. Например, в C++ до сих пор нет модульной системы! А это язык, с дуру, повсеместно использует и приводит к дикому замедлению сборочного процесса.
И кого это волнует из пользователей софта?
N>>А тем временем придумано ещё множество фишек, которые выстрелят реально только в ближайшие 10-20 лет. И что? VD>Я таких фишек не видел.
Я ж говорю — сходи ACMовские журналы почитай
Мировой прогресс отражается в основном именно там.
Ну да, я понимаю, это ж платить надо. Бяда...
N>>Наработка началась одновременно с появлением компьютеров. То, что Брукс завершил свои концепции в конце 60-х, какой-нибудь Кент Бек оформил TDD в 2004 (а сейчас мы скорее видим его "диалектическое отрицание на новом витке развития") — это верхушка айсберга, 1% от него.
VD>Да ничего Брукс не придумал в 60-х. Они базу создали.
Да. Именно так это и делается. Создаётся база — в 10-100 раз дороже, чем потом можно было бы. Почитай труды, из которых возникло какое-нибудь дифференциальное исчисление. Ты просто ничего не поймёшь, а когда продерёшься — будешь в ужасе, как это громоздко и запутанно. Его потом вычищали лет 200 до современного состояния.
И тем не менее мы пользуемся их результатами.
Точно так же с OS/360 и Бруксом.
N>>Подпишись на публикации ACM и посмотри, что нового приходит сейчас. Уверяю — там много интересного VD>Спасибо, у меня есть чем заняться и чем развлекаться. В разработке софта тоже есть много нового.
Ну как хочешь.
N>>Писали. В той же OS/360 было несколько компиляторов. VD>Говноязков. А потом все на С переписали.
Для System/Z на C в основном не пишут. Продолжают писать на ассемблере ("high-level assembler", HLASM — у меня хороший знакомый на нём продолжает писать через прокладку в виде киевского GlobalLogic).
VD> Ты путаешь индустриальную разработку и пионеров граничащих с исследовательской деятельностью. IBM сделал большой вклад в развитие софтостроения. Но кроме него в этом процессе принимало участие множество других компаний.
Я с этим никогда и не спорил. Тем не менее, первый такой огромный проект оказал влияние на всех. Схожие по масштабу у конкурентов появились только через несколько лет.
Даже в 80-х были люди вроде Крэя не понимавшие ценности среды/инфраструктуры и ОС (на чём, по утверждениям многих, Крэй и погорел).
N>>Что толку с того, что мы сейчас можем наклепать компилятор или ОС за неделю? VD>Не можем. Точнее можем такое же говно как OS/360 для 1-2 железок. Но такое качество сейчас никому не нужно. Современная ОС — это огромныные кучи кода, большая часть из которой — драйвера.
N>>Те были сделаны за 3 года и использовались в миллионах экземпляров. Может, это тогда производительность была выше?
VD>Какими на фиг миллионами? Акстись! Миллоны — это сейчас. Выпуск IBM System/360 чуть не завалил саму IBM. Она тупо надорвалась.
Вначале — надорвалась. Потом — взлетела на этом так, что её пришлось осаживать административно.
В пике одновременно было около сотни тысяч. Для того мира это уже фантастика. Сейчас zSeries около 40 тысяч постоянно используемых.
Драйвера — да, с подходом стиля PC они такие нужны. С подходом IBM всё-таки проще.
VD> И выпустили они ее в 1964-м году, так что в реальности ее стали осваивать уже в третьей трети 20го века. И о какой-то там разработке масштабного ПО просто не приходилось говорить. Повторюсь сраный сорс-контрол был зарелизен IBMом в 1977м году!
Не вижу, из-за чего такой кипиш по поводу этого source control. Ну да, раньше его было неоптимально использовать.
VD>70-е стали первой вехой в эволюции разработки ПО. А в итоге все эти мэйнфреймы пошли в помоечку,
Расскажи это про помоечку самой IBM. Тысяч 40, повторюсь, живых установок только System/Z. Считай, с каждой по 2-3k$ в месяц минимум, если в лизинг (очень удобно, кстати). Где-то ещё столько же для софта. Не миллиарды, конечно, но достаточно. А ещё System/i, чуть поменьше количеством, но по деньгам может быть ещё больше.
То, что IBM, испугавшись возможности принудительного раздела, как AT&T, выделила рынок PC в отдельный сектор и отдала в Microsoft — стандартная сейчас конспирология, которую я считаю адекватной. В любом случае у неё огромный R&D сектор, патенты и прочее. Чьи HDD были лучшими в 90-х? IBM. Чьи люди придумали SSA, который в современных компиляторах? IBM. И 100500 других инноваций. Ну ты себе можешь думать, что они ничего не могут, на это и рассчитано — обмануть иванов родства не помнящих
VD> а сегодняшние суперкомпьютеры — это банальные кластеры серверов, т.е. по сути связка ПК. Вычислительные мощности одной современной топовой видеокарты сравнимы с вычислительными мощностями всех компьютеров 70-х, наверно.
Стандартный процессор IBM z15 — 12-ядерный (и 2 треда на ядро), 14 нм технология, out-of-order execution и прочие стандартные современные фишки... в одну систему ставятся до 240 процессоров. Память RAIM (как RAID, но на памяти; обычно — уровень 5 или 6). Для желающих — режим повторения каждой команды дважды, чтобы всякие горячие нейтрино не портили данные — Intel до такого в жизни не дорастёт, они даже ECC фиктивный делают, сколь их ни просят.
Каналы ввода-вывода со скоростями в гигабиты в секунду (если надо далеко — на оптике). Интеграция со всеми современными стандартами железа? Без проблем.
Стиль во всём специфический, да. Терминология своя. Учиться надо.
N>>Да, языки уровня повыше ассемблера развивались медленно — соответственно уровню техники и типовым задачам. Научная мысль всегда шла чуть впереди задач. Мы все избалованы законом Мура, а до начала активного внедрения его результатов (считай, начало-середина 1970х) техника мало что позволяла. VD>Закон мура на производительность уже давно не влияет, кстати. Транзисторы удваиваются, но общая производительность от этого линейно не растет.
Растёт. Мы тут на днях одну штуку тестировали... Corei 11-го поколения в 2 раза быстрее 4-го (Haswell) при даже меньшей частоте и лаптопе вместо десктопа. Не быстро растёт, да, но не остановился.
N>>Совершенно неадекватное определение, которое выхолащивает всю суть. Я не могу принять такое "итого" даже за первичную основу.
VD>Набором, совершенно адекватное, в отличии от утверждения, что в середине века что-то там делали большого объема.
VD>Именно в середине века фактическое появление. В 60-х развивались архитектуры, ОС, параллельные вычисления, в 70-повявление зачатков софта для разработки ПО большими коллективами, в 80 крах мэйнфреймов и новая эволюция ПК, которые переизобретали все с нуля.
"Крах мэйнфреймов" тут только в представлении советского человека, который ничего кроме двух крайностей не видел. Я продолжаю не понимать — ты что, в 80-х ни разу несчастную СМ-4 не видел? Да их на каждом углу в этих НИИ стояло.
В цивилизованном мире переход был плавным, с массой промежуточных этапов. Да, там была несовместимость (увы, или к счастью — у IBM даже кодировка своя), но перейти спокойно без напряга было тривиально. Ну и PC стали заполнять новые ниши, которых не было до их введения (как 10 лет назад смартфоны).
Ну и снова — пока для тебя "софт для разработки большими коллективами" это VCS, разумного обсуждения не будет.
VD> Далее в развитие включилась масса народа и пошло стабильное эволюционное развитие. Сейчас этот процесс замедлился, но все же идет. То же железо до сих пор не предоставляет массового параллелизма (если не считать случаев суперкомпьютеров).
А тебя HAC и все подходы по балансингу не устраивают? Хочешь всё в одной железяке?
N>>Последнее слово не расшифровал, но вот тут точно не надо судить о всей индустрии по продукции Microsoft. Если ты другого не видел, это проблема личного кругозора.
VD>Я видел все. Но МС отличный представитель своего времени. Все развивались точно так же. Первые Макинтоши собирались на коленке из процессоров выдранных из каких-то там бытовых девайсов. Точно так же писались первые СБУД. Да еще в IBM придумали SQL и саму идею реляционной СУБД. Но их труд сдох вместе с мэйнфреймами. Да и звезд он с небе на хватал. А верх взяли разные Oracle и Sybase, которые в те времена были игрушками.
DB2 продолжает работать и массово использоваться в самых ответственных местах (куда МС не допускают, не доверяют).
VD> Ну, а МС сумел развиться из компании состоящей из нескольких человек в мега-корпорацию.
Ну ещё бы — после того, как им создали все условия (сначала железо в виде готового концепта IBM PC, потом хитрым образом контракт на ОС через маму Гейтса...) Типовая накачка ресурсами нового проекта. Ещё бы он не выстрелил.
VD>Я вот тебе больше скажу. Я сейчас в Касперсом работаю. Сейчас флагманский продукт — Каспексий Антивирус для ПК — это огромная гора кода давно переставшая быть просто антивирусом, а начинался то он с утилитой которую Касперский написал в одиночку. И так было почти с любым ПО. ДОС написал одиночка и в последствии продал его МС.
Этот "одиночка" перекопировал CP/M чуть ли не 1:1 по заказу MS. А за CP/M стоял опыт не только его автора Гэри Килдалла, но и опыт DEC в виде RSX-11, из которой (убив несколько важных концепций) сделали CP/M. Перестань мучить сову.
Что там писал Касперский и кто ему помогал — тоже минимум натрое делить надо.
VD> Оракл написал Лари Элисон с двумя приятелями. Было это в 1977-м. В последствии Оракл превратил в мегакорпорацию.
Oracle — да, возможно. Тут деталей не знаю. Но остальные твои примеры не в тему.
N>>Ты, насколько вижу, совсем не понимаешь проблемы разработки в такой среде. Она не в отсутствии как таковой какой-то системы контроля версий (кому нужна была — тот покупал). Проблема в том, что вся среда (не только слабость VCS, а и, например, нереальная цена средств рефакторинга) приводила к дороговизне применения "гибких" подходов, неподъёмной для большинства — и поэтому "водопадная" модель была единственной массово пригодной для крупных разработок. А дальше — практически лотерея с качеством предсказания требований к моменту завершения разработки.
VD>Ну, конечно, куда мне серому и убогому до понимания того как пишется большой софт.
До понимания, какие проблемы у этого были в 1960-х — да, видимо, далеко.
VD>Системы контроля версий и еще 100500 систем — это без чего разработка софта большого объема невозможны. Ну, или превращают разработку в мало эффективный АД. Конечно, это все инструменты. Но без них попросту нельзя. Производительность твоего труда снизится настолько, что ты завязнешь и тебя обойдут конкуренты.
Темп конкуренции был ниже. Поэтому успели.
VD>Что по поводу водопад vs. агил, то мне кажется это надуманно. Я вот и не возьмусь сказать что у нас в итоге получается. Может это классический водопад, а может SCRUM со спринтами в полгода-год.
VD>С одной стороны, у нас постоянный выпуск релизов на билдконвеере. Но с другой есть реальные релизы между которыми идет полноценный водопадный процесс. Ну, требования в виде огромных талмудов с кучей текста у нас нет. Но набор требований все же есть. Причем как в виде екселек, так и в виде экранов гуев (для гуевых фич). И пойди скажи что это, гибкий водопад или затянутый SCRUM. Постоянное тестирование и выпуск реализов по 2-3 раза в день как в агилах. Но полноценные и затяжные итерации с планированием, реализацией, тестирование и последующей поддержкой как в водопаде.
Вопрос в длине минимального элемента. Если 2-3 раза в день — значит, очень гибкое. Это не мешает на верхнем уровне строить планы хоть на десятилетия.
Водопад 60-70-80-х это как раз когда сделал спеку и фидбэк через год, если повезёт.
VD>Вот декомпозиция она всегда рулит — да. Почти любая разработка сегодня — это добавление функционала к чему-то готовому и большому. А значит нужно вплетать новый код в уже имеющийся и при этом его не поломать. Отсюда вытекает необходимость в тестах или постоянном ручном тестировании (или и в том и в другом). Задача тестов — предотвратить регрессию. Но сами тесты — это зло, которое приходится терпеть. Ведь требуют время на поддержку и фиксируют реализацию (а значит препятствуют изменению кода). А идея TDD она, на мой взгляд, не сильно производительная.
За TDD само по себе я и не агитирую. Но на индустрию оно сильно повлияло.
VD>А вот как изменять ПО без системы контроля версий, отладки дампов и прочих современных фич я действительно представить не могу. Ну, если ты пишешь код один и этот код работает только у тебя, то может без этого и можно обойтись. Но если у тебя есть хотя бы пара десятков коллег пишущих код, ты пузо надорвешь без таких систем.
Да вот делали. Работало.
И сейчас можно. Только неудобно и таки в разы медленнее.
VD>Еще раз: IBM OS/360 — это детская игрушка по сегодняшним времена. 5000 человекочасов на нее — это немыслимый перерасход времени и средств. И все это из-за неумения создавать такие системы и отсутствия ПО поддержки разработки.
Ты уверен, что знаешь, что в неё входило тогда?
Ты знаешь все системные и пользовательские утилиты, например? Их было много.
Перерасход — очевидно, но ты его преувеличиваешь на порядок, похоже.
VD>А с интерфейсами проблему научились решать довольно быстро. Хотя до модулей некоторые не дожили и по сей день.
VD>Что до предсказания требований, то это, похоже, только в твоей голове имеющаяся проблема. У нас с этим проблем особо нет.
Это от цели софта зависит.
У меня на прошлой работе больше половины этого зависело от того, кто из кастомеров решится заплатить за какую фичу. В принципе этих фич 100500 можно придумать с ходу, но какие из них реально востребованы — слабо предсказуемо.
И в результате мы даже цифры выводили типа — 10-15% спеков заметно изменятся за пару лет, 50% — за десяток или даже чуть раньше.
В случае Касперского, похоже, проще. Не уверен, что всё понимаю, но очевидности типа "ой, Windows 11 анонсировали, бежим выяснять, что они сломали" не отличаются от такого же "ой, Windows 10 2204 анонсировали". Всё равно ломают и надо адаптироваться
ну а поток вирусов где-то постоянный.
Хотя, думаю, когда криптователи появились — это было неожиданностью.
N>>И сколько таких "единичных случаев" будет? Вот с ходу второй вспомнился (см. фото со стопкой распечаток). Покопаться — ещё десяток найдём. Это сравнимо с объёмом всей индустрии того времени. Может, проблема не в бобине?
VD>Да вот он наверно один и есть. Еще параллельно работала Bell Labs (AT&T). Но они долгое время работали в стол (для внутренних нужд). Толпа нарастала уже потом, когда IBM и Bell Labs зарелизили свои системы.
Да. Потому что железо подешевело. Но и до того — какой объём кода у VM/370? А у RSTS-E?
VD> Unix появился в 1971м, например.
Путём упрощения Multics до "подъёмного" объёма фич.
VD> Мы до сих пор это ощущаем, так как системное время унихах измеряется от 1970го года.
И оно там сдвигалось несколько раз. Могли себе позволить.
N>>Да, железо стало массово тянуть применение таких средств (без часовых задержек). VD>Да ладно! По тем времена они очень даже тянули. А на сегодня у нас, откровенно говоря, git не тянет. Даже с костылями от MS (GVFS) тормозит на наших объемах адски! В прочем, это скорее из-за новомодных Монорем.
Ну теперь представь себе скорость работы железа того времени на вашей монорепе
N>>Ну вот это сходится с тем, что предполагает EM — сколько народу получило такую возможность только с приходом PC. А я ещё школьником видел и СМ-4, и СМ-1420, и ДВК, которые ещё в начале 80-х были, и всякие "Агаты", и побочные ответвления типа Электроники-85... (да, большинство PDP-11 в разных вариациях...) Да, это Киев, не совсем село, но и не Москва. Повторюсь — твой отец (и ты?) работали в каком-то совсем странном месте, если эти средства прошли мимо вас...
VD>Ты что-то там себе навыдумывал. СМ-1420 появилась в 1983-ем и была страшным говном. СМ-1420-1 с аж почти 2 мегами оперативки в 1985-м. А до людей это все доезжал еще позже. Ты еще расскажи мне историю, как на СМ-1420 (первого выпуска) работал коллектив из 100 человек.
100 не видел. Десяток — видел. В 86-м, кажется. Не сильно позже. А в чём проблема, если хватало терминалов?
VD> Не может и работали. Но выглядело это очень грустно. Каждому приходилось небольшой кусочек времени в дено, а то и в неделю.
100 человек по часу в неделю... ну может быть, а зачем на неё 100 человек грузить?
Десять редактирующих и 2-3 запуска одновременно — вполне реально.
VD>Я вот сейчас вспоминаю сколько мой отец притаскивал домой бумаги в виде распечаток. Его одна отладочная сессия стоила государству, наверное, в сотню баксов.
Машинное время на таком звере стоило 15-20 рублей в час. По честному курсу (4-5 рублей за доллар, а не мифический 0.6) — получается 4$. Отладочная сессия это сколько часов?
VD>В общем, ты как-то странно оцениваешь время и развитие. Вот появился СМ-1420 и все у всех он есть, все уже прогаммы коллективами в 1000 человек к нему разрабатывают. Но это же лажа. Говномашина с 128К оперативки работающая крайне медленно. Крайне дорогие носители памяти. Все это надо освоить. Переложить на программы то что раньше считали полуручным способом. Это все требовало времени. Наверно были те кто брался за все это большими коллективами, но они испытывали боль и имели крайне низкую эффективность. Потом люди тупо привыкли все делать по старым лекалам. Написать пару талмудов документации! Провести пару симпозиумов и конференций. А в итоге родить мышь.
Такая инерция есть и сегодня. Но это мало о чём говорит.
Ну да, у меня, возможно, аберрация, что университет. Там народ быстрее реагировал, ну и задачи, в основном всякие расчёты, перенести проще (основная проблема — разница в плавучке — это то, что IEEE 754 стабилизировал).
N>>Не надо высасывать из пальца то, чего ты не знаешь и не можешь знать. Могу. Я работал с бумагой и перфокартами. VD>Ну, и сколько сотен человек было в твоей команде?
А при чём тут это?
N>>Вот с перфолентами не довелось, но видел их вплотную VD>Я слава Богу с перфокартами только играл, а перфолентами только обматывался. Но по счастливому лицу отца сразу понял, что PC — это круто.
Потому что личное.
И опять же, нам раньше доставался кафедральный ДВК в схожем режиме.
VD> Потому и учился программировать на них. Но все это я видел. И у мет сомнений, что с современными методами это все сравнивать нельзя. Между ними пропасть. Ваши агилы сталы возможны только потому, что железо стало это позволять.
Для мелких проектов они были всегда, неформализованно. Но мелкие и не были настолько нужны.
VD> Я вот комичу код и через пару часов получаю релиз продукта, который прошел тесты и проверяется тестерами. А мой отец вставал в очередь. Получал распечатку на следующий день и все выходные ее просматривал (длинна у них порой была адская). А я из ни потом разную херню мастерил. У нас производительность труда несопоставимая.
С таким подходом — естественно. А мы на ЕС-1022 в терминале правили код, запускали...
можно было и в файл заставить вывести и на терминале его просмотреть. Проблема — что в том же окне не получится, окна-то нет... поэтому чуть сложнее тривиального ляпа — таки печатали. За вечернюю смену можно было 3-4 цикла осилить нормально.
Сочувствую, что твоему отцу такого не давали, но такой режим со стокилометровой очередью уже ой был не обязательным.
N>>И им хватало еженедельных (например) бэкапов на бумаге и лентах. VD>Если бы хватало, они бы их не создали. А они создали. VD>Понимаешь, можно все делать дико через жопу. Например, можно копать траншеи лопатами.
Ты кэпствуешь о совершенно очевидном. Это и так понятно. Я говорю о принципиальной подъёмности. Проект сработал и обеспечил IBM баблом на десятилетия. ЧТД.
N>>Ты меня явно с EM перепутал. И он говорил не о частных случаях, он говорил об общей картине (статистически значимой) так, как он её видит, с несколькими иллюстрациями. N>>Это принципиально. И вот насколько его видение адекватно — можно и нужно обсуждать, но не циклиться на примерах. VD>Ну, так я понимаю ты его теорию и защищаешь.
1/10 от неё. Остальные 9/10 в моей позиции тебе померещились.
The God is real, unless declared integer.
Re[9]: Тенденции в развитии микроэлектроники и ПО :)
Здравствуйте, netch80, Вы писали:
N>Растёт. Мы тут на днях одну штуку тестировали... Corei 11-го поколения в 2 раза быстрее 4-го (Haswell) при даже меньшей частоте и лаптопе вместо десктопа. Не быстро растёт, да, но не остановился.
Здравствуйте, 4058, Вы писали:
N>>Растёт. Мы тут на днях одну штуку тестировали... Corei 11-го поколения в 2 раза быстрее 4-го (Haswell) при даже меньшей частоте и лаптопе вместо десктопа. Не быстро растёт, да, но не остановился.
4>Мне кажется Вы говорите про многопоток, т.к. для однопотока прирост в районе 30% (это еще с учетом, что boost-овые частоты подросли):
Здравствуйте, netch80, Вы писали:
N>"Научился использовать современные железки" вообще не относится к этому сравнению. N>"Быстрее" — точно быстрее, если сравнить на _одинаковом_ железе?
Да, будет быстрее на одинаковом железе.
Потому, что умеет применять новые оптимизации — от компиляции запросов в натив и до применения эвристик вроде "в джойне участвует verified foreign key, поэтому кардинальность результата точно известна заранее".
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[17]: Тенденции в развитии микроэлектроники и ПО :)
Здравствуйте, Евгений Музыченко, Вы писали:
ЕМ>В мозгу это успешно делают десятки-сотни тысяч нейронов, имеющих быстродействие на несколько порядков ниже.
Первичная зрительная кора, которая выполняет только самую начальную обработку картинки — около 300 миллионов нейронов.
Ад пуст, все бесы здесь.
Re[18]: Тенденции в развитии микроэлектроники и ПО :)
Здравствуйте, netch80, Вы писали:
N>И вполне возможно, что если пересчитать производительность на единицы измерения как для компьютеров, те гигафлопсы будут в пределах одного-единственного нейрона. Мы только начинаем это реально изучать.
На самом деле, вопрос уже неплохо изучен. Если не ударяться в теорию квантового сознания и прочую шизотерику, то вычислительная мощность среднего нейрона — около десятка килофлопс.
Ад пуст, все бесы здесь.
Re[19]: Тенденции в развитии микроэлектроники и ПО :)
Здравствуйте, Codealot, Вы писали:
N>>И вполне возможно, что если пересчитать производительность на единицы измерения как для компьютеров, те гигафлопсы будут в пределах одного-единственного нейрона. Мы только начинаем это реально изучать.
C>На самом деле, вопрос уже неплохо изучен. Если не ударяться в теорию квантового сознания и прочую шизотерику, то вычислительная мощность среднего нейрона — около десятка килофлопс.
А почему мозг настолько энергоэффективней современных чипов? Ведь энергоэффективней же, насколько я понимаю, на несколько порядков. В чём загадка, которую не могут перенести в кремний?
Здравствуйте, vsb, Вы писали:
vsb>А почему мозг настолько энергоэффективней современных чипов? Ведь энергоэффективней же, насколько я понимаю, на несколько порядков. В чём загадка, которую не могут перенести в кремний?
Принципы работы мозга совершенно другие, так что скопировать и перенести в кремний просто не получится. Компьютеры как они сейчас устроены были созданы для решения совершенно других задач и другими средствами.
Но на самом деле, есть и задачи, в которых кремний на многие порядки эффективнее. Собственно, те задачи, для которых компьютеры и проектировали — точные вычисления, например.
В общем — из шурупа получается очень неэффективный гвоздь.
Здравствуйте, Евгений Музыченко, Вы писали:
ЕМ>И вот, когда на фоне всего этого смотрю на эволюцию ПО, так прям тоска берет.
А что программа дурна
То заказчика вина
Изловить бы мудака
Да отвесить тумака
Ан нельзя никак
Ведь заказчик-то — мудак!
А у нас в айти испокон веков
Ну нет суда на мудаков
Из свежих диалогов. Есть большая система, в ней имеется собственная поддержка тикетов, запросов в поддержку вида "вы чего с меня деньги списали?". У тикета имеется история изменений, тема, ответственный, последующие действия, путь эскалации и ещё черт лысый, а в дополнение к нему — вычисляемый срок исполнения, сколько осталось дней на решение.
Тикеты отображаются в виде списка открытых, в виде глобального поиска — тоже списком, и в виде окошка деталей, работы с тикетом. Так вот во всех трёх местах используется разный способ вычисления, сколько осталось дней на решение тикета. Один и тот же тикет в очереди будет иметь 5 дней, в поиске 7, в деталях — 4.
На попытку вести разговор в сторону "почему программисты должны всякий раз догадываться, как именно должна работать система, и почему у нас нет документации, где будет написано — как именно следует вычислять вот эти дни, это не работа программиста, этим продакт менеджер должен заниматься", было отвечено нечто невнятное. А разговор вёл не кто-нибудь, а архитектор.
Значит, будут продолжать заниматься программисты, в меру своего непонимания системы, которой 30+ лет.
Re[9]: Тенденции в развитии микроэлектроники и ПО :)
Здравствуйте, netch80, Вы писали:
VD>>Системы контроля версий и еще 100500 систем — это без чего разработка софта большого объема невозможны. Ну, или превращают разработку в мало эффективный АД. Конечно, это все инструменты. Но без них попросту нельзя. Производительность твоего труда снизится настолько, что ты завязнешь и тебя обойдут конкуренты.
N>Темп конкуренции был ниже. Поэтому успели.
На стройку приехала комиссия. Глава комиссии видит бешено бегающего рабочего с пустой тачкой, спрашивает у прораба:
— Что он так носится?
— Так ускорение же.
— А почему тачка пустая?
— Грузить не успеваем.
— А почему вы мне об этом так спокойно говорите?
— Так гласность же.
Это всё, что я могу сказать о скоростной разработке для обхода конкурентов.
Re[2]: Тенденции в развитии микроэлектроники и ПО :)
Здравствуйте, Слава, Вы писали:
С>во всех трёх местах используется разный способ вычисления, сколько осталось дней на решение тикета.
У меня подобная хрень наблюдается на AliExpress. До недавних времен пользовался старой российской учеткой, язык в настройках всегда стоял английский, но это чудо упорно переходило на французский по геолокации, а уведомления на почту присылало то на английском, то на русском.
Теперь учетка французская, язык по-прежнему стоит английский. Интерфейс периодически съезжает не только на французский, но и на какие-то арабские языки, несколько раз почему-то съезжал на иврит. Уведомления приходят в основном на французском, но иногда — на английском.
Искать в этом хоть какую-то логику я перестал еще в те времена, когда поиск товаров у них стал работать по принципу "попробуем найти немного из того, что хоть как-то связано с запросом, остальное забьем хламом".
Re[21]: Тенденции в развитии микроэлектроники и ПО :)
Здравствуйте, Codealot, Вы писали:
vsb>>А почему мозг настолько энергоэффективней современных чипов? Ведь энергоэффективней же, насколько я понимаю, на несколько порядков. В чём загадка, которую не могут перенести в кремний?
C>Принципы работы мозга совершенно другие, так что скопировать и перенести в кремний просто не получится. Компьютеры как они сейчас устроены были созданы для решения совершенно других задач и другими средствами. C>Но на самом деле, есть и задачи, в которых кремний на многие порядки эффективнее. Собственно, те задачи, для которых компьютеры и проектировали — точные вычисления, например. C>В общем — из шурупа получается очень неэффективный гвоздь.
Почему? Нейросети уже много лет супер-активно развиваются. Те же TPU гугл проектировал конкретно для работы нейросетей. Почему они их не спроектировали так, чтобы они были эффективны?
Re[22]: Тенденции в развитии микроэлектроники и ПО :)
Здравствуйте, vsb, Вы писали:
vsb>Те же TPU гугл проектировал конкретно для работы нейросетей. Почему они их не спроектировали так, чтобы они были эффективны?
Они уже намного эффективнее в этой задаче, чем обычный процессор. Но не все сразу. Думаю, следующим шагом будут асинхронные вычисления. Потом, возможно, аналоговые.
