Re[17]: Тенденции в развитии микроэлектроники и ПО :)
От: netch80 Украина http://netch80.dreamwidth.org/
Дата: 01.01.22 10:05
Оценка: 80 (1)
Здравствуйте, Евгений Музыченко, Вы писали:

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.
 
Подождите ...
Wait...
Пока на собственное сообщение не было ответов, его можно удалить.