EC ЭВМ и ДВК. Решение о клонировании IBM и PDP - причины и последствия

3-62> Еще раз - откуда берутся эти "сотые доли" если считаются изначально целые числа?

Намёк: а эти изначально целые числа часом никогда ни на что не делят?

3-62> Тут высказано мнение, что проблема "потери точности" возникает из-за операции деления чисел.
3-62> Кто с этим утверждением согласен?

не только операция сложения тоже может серьезно обрушить точность.

tarasv> ... Отсутствие мультиплексного канала мы уже обсудили.

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

Iva> не только операция сложения тоже может серьезно обрушить точность.

Еще интереснее.
Подробности можно узнать?

3-62> Еще интереснее.
3-62> Подробности можно узнать?

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

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

Ага. Есть флоат, но нет понимания.
Сдается мне - проблема в отсутствии понимания, а не в конечной разрядности слова.
Которое, в общем, легко обходится.

Ну а про деление - тут есть ли им обусловленная потеря точности?

3-62> Ну а про деление - тут есть ли им обусловленная потеря точности?

?

Запиши 1/3 без потери точности. В 8 разрядов.

Jerard> Запиши 1/3 без потери точности. В 8 разрядов.

И 1 и 3 могут быть записаны в 8 разрядов. Даже одновременно.
И у рациональных дробей нет потери точности.



Но относительно банковского софта и точности - а к какой точности вы стремитесь? Абсолютной?

Jerard>> Запиши 1/3 без потери точности. В 8 разрядов.
3-62> И 1 и 3 могут быть записаны в 8 разрядов. Даже одновременно.
3-62> И у рациональных дробей нет потери точности.


Дык, в десятичном виде, жи...

Татарин>> Возможно, под "Минск" нужны были буфера, я не вдавался в этот вопрос, я вообще говорил про другое: про то, что вносить буфера
tarasv> Про какие буфера идет речь?
Буфера ввода-вывода при устройстве.

tarasv> Убрать/добавить один что на ЕС что на БЭСМ будет стоить единицы процентов от потребительской конфигурации с периферией.
С периферией? Мне вот помнится, что даже ЕСовский АЦПУ был непростой (в смысле электроники) штукой.
Ну, оно и понятно, даже знакогенератор - это весьма ощутимая схема, если собирать её на транзисторах.

Татарин>> А задачи буферизации оставить на периферию.
tarasv> Если информация уже в ОЗУ машины, то почему бы ее оттуда не читать не напрягая ЦП?
Потому что ПДП - "бесплатная" штука только пока у тебя процессор развязан с памятью хотя бы кешем. Смысл "не напрягать ЦП", если у тебя ЦП стоит из-за того, что шина памяти занята?

tarasv> Чуть больше 130 строк в минуту. 78000 строк. За ночную у меня регулярно случалось в районе 100 листов распечаток. Если и погорячился то явно не на порядок.
100 листов выглядит уже куда более вменяемым.
Я не помню, сколько строк на листе, я помню ёмкость общую страницы (между перфорациями) что-то в районе 8 килосимволов.
100 листов распечаток - 80 килобайт. Но не 2 мегабайта же!

Татарин>> То самое предположение, при котором БЭСМ радикально выигрывает у ЕС, просто потому что у неё производительность на рубль выше (и да, ессно, выше и с учётом траты времени ЦПУ на печать).
tarasv> Это если Рунге Кутта считать. А у меня другие задачи были. "Дислокация судов и грузов на р. Днепр", лето, начала 80х. ЕС-1033 1Мб, 29Мб диски, ленты. Основной счет - 1 час маш. времени. БЭСМ-6, периферия та же от ЕСки, другой не завезли. Счет 12мин? Нет. 40 минут.
То есть, подожди-ка, на минуточку, ты сравниваешь на задаче с явно большим объёмом данных машину с 1Мб памяти и машину с объёмом памяти 192к?
И упрекаешь вторую в том, что затык у неё вовсе не в ЦП?

Ну... эээ... ладно. А что ты хочешь этим сказать? Если это контрпример моим словам в цитате, то в чём этот контрпример?
ЕС-1033 это машина на ДВА поколения моложе БЭСМ-6. И она - со всеми наворотами, собранная на микросхемах уже в другой технологической эпохе, имея более навороченную и дорогую периферию, имея в 3 раза больше памяти на требовательной к памяти задаче, - считает медленнее, чем БЭСМ?
Но почему это хорошо для ЕС?
Почему, кого и как это может убедить в том, что цена вычислений на рубль у ЕС была ниже?

tarasv> Что делать? Сбалансировать БЭСМ по вводу/выводу и памяти. Как? Смотрим эту задачу, но ближе к концу 80х. Я конечно уже не оператор, но общаюсь со старыми приятельницами. ЕС1046 - 15 мин. Она чутка быстрее БЭСМ-6 но не это важно. Важно что 8Мб ОЗУ на микросхемах. Отдавали 6Мб под задачу. И вишенка на тортик - диски и каналы в 3 раза быстрее.
Экспериментально твёрдо установлено, что быть богатым и здоровым лучше, чем бедным и больным. Хорошо, я с тобой полностью согласен: ввод-вывод у БЭСМ можно и нужно было улучшать (да, блин, там всё можно и нужно было улучшать).
Сама эта тема началась с того, что сторонники ЕС заявили: нет, там всё было так плохо, что нужно было сжечь под корень и начать копировать ИБМ с закладыванием отставания на 3-10 лет и внедрением полной зависимости от американской разработки железа и софта.

Могла ли БЭСМ служить как основа для дальнейшего развития и улучшений? Ну да, могла. Было так что и куда улучшать (с сохранением совместимости снизу вверх)? Было. Нужно было закладывать отставание много большее, чем в момент решения по ЕС? Нет, не нужно, и даже сам вопрос "нужно ли сделать своей стране хуже?" не мог бы возникнуть как абсурдный, если б мы не говорили про страну с КПСС.
Ну, собссно, вот и весь нехитрый тезис-то.

Если ты это говоришь к тому, что у БЭСМ была 15-бит адресация, то это совершенно несерьёзно. Есть десятки способов расширить адресуемое пространство без потери совместимости, что и было продемонстрировано на развитии той же самой БЭСМ позже.

tarasv> Большая часть ИБМ была арендованная и гоняли их весьма интенсивно. Начальнику ИТ надо показывать рентабельность.
НЯЗ, нет.
Но вот я как раз и веду к тому, что в экономической реальности СССР множество мелких машин довольно хорошо разменивались на одну большую с выгодой в цена/производительность. Даже если где-то по географическим причинам большая машина недоиспользовалась бы, общая цена системы из множества серийных, отлаженных, не просто совместимых, а даже одинаковых машин была бы меньше.

СССР гораздо меньше, чем буржуины, нуждался в линейке машин (аргумент сторонников ЕС). То есть, мог получить огромные выгоды на НИОКР и производстве от унификации (например, выпуская специфичные для БЭСМ микросхемы).
А там, где нужна была именно смена размерности, там, как показала практика, "линейка ЕС" оказалась полностью бесполезной (и пришлось городить СМ). Сразу по куче причин, часть из которых была на уровне концепции и была вполне себе предсказуема в момент принятия решения по ЕС.

>За весь СССР не скажу, но в ВЦ главка речфлота где я работал было три смены в навигацию и две остальное время.
Именно так. Я слышал именно такие рассказы. СССР не хватало не машин, а вычислительной мощи.
И задача "дать стране мегафлопсы" - это совершенно иная задача, отличающаяся от "поставить по ЭВМ в каждую бухгалтерию" (которая при решении первой спокойно решалась бы в эволюционном порядке).

В альтернативной истории, где ЕС не случилось бы, БЭСМ тиражировались бы и совершенствовались как линейка "старших" машин, а "Мински"/"Уралы" сели бы в нишу младших, заняв бы и нишу будуших СМ. Ничего нереального тут нет.

tarasv> В 1963м БЭСМ-6 существовала в основном на бумаге. И я принципиально не брал дрюкер от Роботрон, а только советские принтеры раз уж мы с БЭСМ сравниваем.


tarasv> Это что за технически безграмотные фантазии? Реализация устройств ВВ в 360 полностью отгорожена от деталей реализации ЦП и памяти и это единственное правильное решение. Подумай почему, я уже рассказывал. Впрочем можно и повторить. У машин семейства 360 шина памяти может быть 8, 32, 64 и 128 бит. А шина процессора 8 или 32 бита или две 32 и 64.
Нет. Это было ошибкой. И опять же, спорить тут ты не можешь, потому что индустрия неизбежно пришла к единственно верным решениям (впрочем, они очевидны).

Как ты подключаешь современную периферию?
У тебя есть стандартный USB-диск.
У тебя есть машина, процессор, который ни-че-го не знает про USB.
И у тебя есть контроллер USB, который дружит ничего не знающую об USB машину с USB-диском.
Да, сейчас (в последние 10-15 лет) это уже не так очевидно из-за технологии позволившей утолкать два компонента в одну микросхему, но и сейчас ты при отсутствии нового интерфейса USB 3.2 в старом компе берёшь плату с шиной актуальной для этого компа и втыкаешь в этот комп.

Три компонента: машина, периферия и контроллер между ними. Причём, контроллер специфичен для машины, но не входит в её стандарт. "Немножко голая" БЭСМ-6 выглядит выгоднее для перехода к такой прогрессивной схеме, чем ИБМ/360. Не из-за своей навороченности, а наоборот - из-за примитива. В простой машине ты можешь выкинуть ненужное. В более сложной-дорогой-производительной - добавить.

tarasv> ...Тут на удачу подворачивается ЕС, из нее вытаскивают кусок, немного чертят и паяют, ставят между каналами БЭСМ и ВЗУ и проблема рассасывается.
Собссно, так и должно было всё решаться.
Только, уж ессно, при нормальном развитии событий не на уровне пользователей, а на уровне КБ, выпускающих совместимые машины.

Собссно, вот вся эта бодяга про "о ужас, что делать с БЭСМ, если в мире выпускают столько хорошей периферии для ИБМ!" - полная техническая бессмыслица. При желании на уровне КБ это элементарно решаемый вопрос... да даже и не вопрос совсем.

tarasv> Если бы. Не было. И быть не могло в СССР в 1965 году МС с 36 и 48 диодами.
Почему же?

Татарин>> Потому что валюта - и есть самое что ни на есть целое. В реальности нет дробных копеек.
tarasv> Моя компания платит налог в 8.8% от доход который предварительно обложена налогом на оборот в 13%. Эффективная ставка налога 9.944%. Успехов тебе в бухгалтерских вычислениях на типе данных с двумя знаками после запятой.
А думаешь, я таких расчётов не делаю? Никаких проблем: беру децимал и провожу вычисления.
А вот BCD, в котором ты прописал точность, тебя тут никак не спасут. Потому что либо ты изначально СИЛЬНО перезаложился на размерность своих чисел, либо порежешь результат сильнее, чем даже... гм... на целых.
И ты подожди иронизировать: я вот всё посчитаю в децимал (считанные рабочие переменные) и обратно приведу, и проведу кучу таких вычислений за время, пока ты выполнишь одно BCD-деление.

tarasv> И еще, у меня все ходы записаны. Объясни мне как у тебя сочетается "S/360 г**но, надо было биты адресовать, это была бы грандиозная экономия памяти" с "S/360 г**но, надо не байты адресовать, а два слова взять если одного не хватает"?
Так вот как раз идеально сочетается. Если у тебя задача с кучей данных - используй целые не-в-слово. Если у тебя задача нормально помещается в память и требует скорости - используй "Х-словную" арифметику.
BCD же берёт худшее из двух подходов: лишние траты памяти при сниженном быстродействии. BCD-арифметика такова даже при поддержке со стороны железа.
Плотная, не-в-слово упаковка данных при поддержке железа (две инструкции загрузки-сохранения) берёт лучшее из двух миров: и лучше использует память, и почти так же быстра. Без поддержки железом числа выборной двоичной разрядности заметно медленнее пословной арифметики, но всё равно сильно быстрее BCD. Некоторое преимущество (не всегда и не везде!) BCD по скорости может быть только если BCD поддержана железом, а плотная упаковка - нет. По эффективности использования памяти BCD сильно проигрывает в любом случае без вариантов, и тут спорить вообще не о чем.

tarasv> Мне постоянно приходится объяснять тебе то что ты по идее должен знать сам прежде чем врубать режим "о солнцеликая БЭСМ-6". Точность плавучки БЭСМ 12 значащих цифр. Точность BCD - любая, сколько надо столько и будет. Чтото запрещает взять 8 байт чтобы получить 15 значащих? Ничто не запрещает. Аналогично ничто не запрещает положить зарплату в 3 байта, а тов. Итого в 4. Хотя какой он нам товарищ, он гражданин.
Ты постоянно объясняешь то, что все понимают, игнорируя обсуждаемый вопрос и перепрыгивая с неудобных для себя моментов на всем понятное. По крайней мере, для меня выглядит так.

Во-первых, BCD - это бОльший расход памяти: из 4-х бит ты используешь 3 с копейками. Четверть память ты сливаешь сразу. Вот просто так, потому что BCD.
Во-вторых, у тебя нет "любой" точности. У тебя есть точность "любая заранее заданная", а это (особенно, при делениях и умножениях) штука сложная. У тебя даже товарищ Итого может внезапно!(тм) остаться без части зарплаты, если перед ним возникнет не 10 фамилий, как обычно, а 50. Ты говорил о возможности сделать ошибку? Так тут у тебя для ошибок простор неограничен, и да, ты не зря вспоминал (а потом сразу забыл ) КОБОЛ.
В-третьих, ещё раз: а какая у тебя практическая нужда иметь более 12 знаков мантиссы? Ты знаешь много финансовых расчётов с такой точностью? Приведи практический пример валютных вычислений с 15 значащими цифрами? Даже банки при вычислениях редко оперируют такой точностью.

И, наконец, в-четвёртых. Да, в теории "мы будем использовать столько знаков, сколько надо" звучит неплохо. Вроде как экономия памяти, которой очень мало. Но на практике это выливается во что? В загрузку части величины, проведением арифметики, BCD-коррекцию, запоминание переноса, загрузку следующей части и т.п. В смысле загрузки ЦП эта "компактная запись" (на треть больше требуемого!) числа в памяти обходится бешено дорого, и в момент вычислений ты всё равно работаешь со словами.
Ты хочешь записать 3-хзначное число? Ты потратишь 2 байта. И вот тебе ещё четверть потраченой памяти сверху. В 2-байтном целом, которое хранит до 65535 (5-значное, в десятичных знаках) знаковое число ты хранишь 3-хзначное. Это экономия памяти! Это успех!
А теперь распиши (грубо) процедуру BCD-деления одного 9-значного (чтобы в слово не влезало) на другое: сколько операций ты на это потратишь? На машине-то, которая делает в секунду всего-то их миллион от силы?

Но ладно, вот тебе простой вопрос: если ты так экономишь память (согласен, бывают случаи), то запиши те же целые произвольной битности по битовым маскам компактно, игнорируя границы между словами (чем никто не пользуется сейчас, бо такая предельная экономия памяти считается неактуальной); почему нет? В операциях ЦП это прям ещё и дешевле будет (только экстракция-запись чисел в/из компактного вида чуть дороже), особенно, если чуть сложнее арифметика пойдёт. Допустим, сложить-то зарплату гражданину Итого можно... а вот взять от неё сложный процент в BCD и поделить на всех? Вот тут и начинается машинный секс: то, что машина сделала бы в одну операцию, ты заставляешь её делать туда-сюда-обратно дико сложным способом.
Ну а в потраченной памяти так и вообще праздник какой-то (даже в т.н. "компактной записи", с посимвольной-"зонной" это уже народные гуляния с фейерверками).

Блин, я не верю своим глазам: я вынужден доказывать проблемность BCD!
То, что очевидно всем уже полвека.

Единственное преимущество BCD - совместимость с "человеческим" представлением чисел и, соотвественно, простота ввода-вывода. Удобнее брать прямо десятичные знаки с перфокарт или телетайпа, удобнее печатать результат из памяти. Но и только.

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

tarasv> Самые обычные. Твое предложение поддерживает два типа данных - NN.2 и плавучка. Остальное эмуляцией.
Да. Собссно, все сейчас так и делают.
Собссно, BCD на сложной арифметике для любого размера чисел отличных от (размерслова*2) - это тоже эмуляция. Только более сложная. Даже с железной поддержкой.

tarasv> Потому что очень мало серьезных применений где железную реализацию на десяток-сотню логических элементов нельзя заменить микропроцессором. А они сейчас дешевле пыли.
Серьёзных-то как раз я, пожалуй, найду, а вот радиолюбителям - да. У самого такая же история: поставить один корпус PIC16F84 (закупленых когда-то пачкой за копейку) в том же ДИП-корпусе проще, чем даже два корпуса ТТЛ-логики. А самое смешное, что она ещё и будет меньше жрать.
Но вот "у взрослых" рассыпуха ещё повсеместно встречается.

3-62>> Еще раз - откуда берутся эти "сотые доли" если считаются изначально целые числа?
Fakir> Намёк: а эти изначально целые числа часом никогда ни на что не делят?
В контексте - нет.

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

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

Татарин> А теперь распиши (грубо) процедуру BCD-деления одного 5-значного на другое: сколько операций ты на это потратишь? На машине-то, которая делает в секунду всего-то их миллион от силы?
У меня всегда было большое подозрение, что микрокод этой операции сначала переводит БЦД в нормальное двоичное, делит, а потом - обратно.
Говоришь, ПДП мешает процу работать? А ты прикинь, сколько тактов занимает такое деление. Память простаивает!

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

Татарин>> ...у тебя в какой-то может возникнуть опасная иллюзия, что "и так сойдёт".
pokos> Чтобы отринуть иллюзии малхут, евреи придумали "банковское округление".
- Сколько стоит капля сока?
- Нисколько.
- Таки накапайте стаканчик.

В сложных вычислениях и больших потоках стаканчик "трохи для банка, трохи для себе" набегает очень быстро.

Татарин>> А теперь распиши (грубо) процедуру BCD-деления одного 5-значного на другое: сколько операций ты на это потратишь? На машине-то, которая делает в секунду всего-то их миллион от силы?
pokos> У меня всегда было большое подозрение, что микрокод этой операции сначала переводит БЦД в нормальное двоичное, делит, а потом - обратно.
Долой подозрения. Так и есть.
Не знаю, как в С/360, но в х86 бинарно-десятичная коррекция вынесена в отдельные команды - отдельно для сложения/вычитания, отдельно для деления, отдельно для умножения. Причём, для деления, НЯП, нужно запускать отдельную коррекцию до операции.

Но заметь, это только для случаев, когда у тебя операнд влезает в слово (то есть, до-8-десятичных-знаков величина). Если больше, ты будешь отдельно иметь дело с переносами всех видов. И коррекциями после них.

Многословные операции а-ля децимал в сравнении - просто суперэффективность. Ну а операция над единичным словом - так и ваще.

Татарин>> Собссно, как "создатели ЕС" взаимодействовали с разработчиками ИБМ/360? Да никак! Кто из ИБМ приезжал в СССР грозить пальчиком на тему "никакой отсебятины в реализации кода хх хх!"? Да никто!
Татарин>> Задача прогибания разработчиков ЕС под американские стандарты решалась КПСС.
Iva> потому что цель была в краже и использовании софта ИБМ. И нужно было, чтобы он без проблем шел на новых ЭВМ. а всякая отсебятина убивала эту задачу на корню.
Iva> Это не баг, а фича.
Ну дык!

Что и привело к тому, чему привело. И ни к чему другому привести не могло, и даже татарское иго тут совершенно не при чём. Проблема в конкретном решении в высоких кругах коммунистов.

Я бы даже сказал, что при таких вводных и при наличии КПСС русские сработали даже неплохо. Ессно, катастрофа. Но строго в рамках вводной: отставание строго в пределах стратегии, и не более.
Другое дело, что к 90-м стратегия перестала работать в принципе... отдельный уже разговор это.

Iva> в 70-х годах в ФРГ посадили программиста.
Iva> банковская программа считала с точностью до сотых долей пфенинга, а дальше сотые отбрасывала.
Iva> он дописал программу, чтобы она эти сотые перечисляла ему на счет. В итоге за несколько месяцев получил около 70К марок.
Это совершенно иная история, очень даже запросто (и даже скорее всего) этот программист работал как раз с BCD.

Татарин>> Там, где не копировали - всё было нормально с темпами разработки, даже при бюджетах в 10-100 раз меньших. Чтоб новых примеров не плодить - БЭСМ-6-то сделали? Работала ведь? Нормальная машина. И другие сделали, и другие бы сделали, и другие бы работали, да и работали вполне.
Iva> вы опять про железо. А про софт?
И с софтом то же самое, только лучше.
Более того, бОльшая часть "бесплатного" (а скажем прямо - ворованного) софта была СССР не нужна (а значительная часть даже вредила). Примерно как сейчас Микрософт "мирится" с воровством Виндовс (а на самом деле в низком сегменте даже поощряет его), потому что это укрепляет власть стандарта и уничтожает альтернативы на корню.

Так вот СССР сделал себе это харакири добровольно. Власти страны убили свою отрасль даже не за деньги... а просто так.

Iva> Даже принятие решения на самом верхнем уровне не дало единообразия
Потому что на самом верхнем уровне КПСС не приняла решение о единообразии, а приняла решение о копировании.
Разница - радикальная, и она потом как раз и сказалась.

Jerard> Дык, в десятичном виде, жи...

А кто заставляет в десятичном-то?
Дурь?

Jerard>> Дык, в десятичном виде, жи...
3-62> А кто заставляет в десятичном-то?
3-62> Дурь?

а в двоичной что будет все не так, как в десятичной?

Iva> а в двоичной что будет все не так, как в десятичной?

Железке в двоичном виде считать значительно проще и удобней. Так как для неё это — естественное представление данных.

Sandro> Железке в двоичном виде считать значительно проще и удобней. Так как для неё это — естественное представление данных.

не важно. переводя 1/3 что в двоичную, что в десятичную - ты число обрезаешь. и дальше начинается накопление ошибки при вычислениях.

Sandro>> Железке в двоичном виде считать значительно проще и удобней. Так как для неё это — естественное представление данных.
Iva> не важно. переводя 1/3 что в двоичную, что в десятичную - ты число обрезаешь. и дальше начинается накопление ошибки при вычислениях.
Да. И либо ты ведёшь арифметику дробей, либо купируешь эту проблему ростом точности вычислений.

Любое позиционное представление чисел вынуждает тебя мириться с некоей конечной ошибкой. Изначально вопрос был поставлен (tarasv) так, что представление валюты в BCD каким-то образом может эту ошибку устранить. Это, конечно, не так.

Более того, более компактное честное-двоичное (против двоично-десятичного) при равном расходе памяти даёт меньшую ошибку округления.