Здравствуйте, Евгений Музыченко, Вы писали:

N>>БЭСМ-6 — тупая кривуля.

ЕМ>Я правильно понимаю, что Вы не имели с нею дела, по крайней мере — в те времена, и оцениваете сугубо в сравнении с более новой техникой?

Ну почему с более новой? CDC6600, с которой любят сравнивать. Те из линии 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!) есть куда более интересные примеры. И даже CDC6600, с которой любят сравнивать БЭСМ-6...

N>>Ностальгировать по этому смысла просто ноль целых фиг десятых.

ЕМ>Мне совершенно не свойственна ностальгия по технике тех времен — разве что по самим временам. Мне досадно, когда люди теряют адекватное представление о ресурсах, реально потребных для решения той или иной задачи. Здесь очень уместно вспомнить классическую притчу Дейкстры о том, кто был "первым компетентным программистом".

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

N>>"Круче" не конкретизируемый термин. Язык сам по себе безнадёжен.
ЕМ>А термин "безнадежен" — конкретизируемый?

Да, его можно спроецировать на оценку планов использования, на развитие или деградацию.

EM> Алгол-68 "круче" C++ прежде всего в плане сложности его реализации, а отнюдь не удобства программирования или модности.

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

Здравствуйте, Евгений Музыченко, Вы писали:

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++ прежде всего в плане сложности его реализации, а отнюдь не удобства программирования или модности.

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