EEP 76: Priority Messages - в Erlang/OTP 28.0. Криво и неполно, но лёд начал крошиться. Поздравляем с опозданием на 15-20 лет по сравнению с тем, когда это действительно надо было сделать. До полноценной реализации ждать ещё примерно столько же?
CHESS выглядит прикольно. Иногда приходилось делать такие тесты, но очень несистематически и локально. Правда, боюсь, что если рандомизировать всё, то половина будет вылетов во всяких rtld и libc, а их лечить обычно не дело разработчика целевого приложения;\
По совковому словарю - да, может быть. Именно таких "инженеров" тогда и выпускали миллионами. Это из той же оперы, что "Нет, тётя Роза - старший экономист!"
А вот автор статьи, конечно, слегка идеалистичен, но пытается вернуться к истокам. "Инженер (от лат. – хитроумный, остроумный, изобретательный) –создатель некоторых военных машин во втором веке, а впоследствии – творец всяких хитроумных устройств" (источник). И мне его позиция всяко ближе.
Нэймспейсы не особо относятся к ООП. Вполне можно их реализовать без ООП.
Я и не говорил такого. Я говорил о том, что полезно перетащить из C++. Хотя сейчас скажу, что неймспейсы таки косвенно имеют отношение к ООП: как и класс, это средство структурирования.
Приватные поля элементарно решаются без ООП, путем определения методов доступа в том-же модуле, где определена структура.
А как данные привязать к каждому конкретному объекту?
Потрясающий пример как не надо делать. Начиная с того, как не задетекчен случай полного вырождения в вычисление самим компилятором, с отсутствия вариаций по опциям компиляции... Впрочем, автор всегда отличался... мнэээ... оригинальным мышлением и пониженной самокритичностью, так что я не удивлён.
Не обязаны. Можно написать пачку статических процедур, сложить их всех в один класс, вызывать из статического main(), а максимум данных собрать в примитивные типы и их массивы.
Аргументация вывернута с ног на голову, именно из-за того, что 68k не стал ширпотребом, он и оставался дорогим, а не наоборот.
Вы переоцениваете вклад больших партий. Есть объективная цена производства - та самая, которая по расширенному закону Мура падала экспоненциально - и она не давала слишком быстрых результатов.
Интересно, сколько бы стоил 80286, если ибеме не выбрало бы себе 8088 чуть пораньше? Я думаю -- бесконечность, т.е. до него вообще не дошло бы.
Хороший вопрос. Возможно, Intel бы умер или ушёл чисто в производство памяти. Что именно IBM дала жизнь линии x86 - не вижу причин спорить с этим.
Но то, что я говорю - что x86 не был настолько плох на общем фоне, а m68k, например, соответственно не настолько лучше остальных, чтобы его проигрыш создал трагедию.
Как интересно получается: в том, что loop только с cx, сдвиги только с cl и умножения-деления только с dx/ax -- люди не путались, а в абсолютно равноправных 8+8 регистрах путались.
Да. Это не мой тезис. Я тоже немного удивлён. Но если такое приписывают создателю PDP-11, наверно, это соответствует общему пониманию в те времена.
Напоминаю, что вокруг - в среднем и нижнем ценовом сегменте - были чуть ли не тотально архитектуры на один аккумулятор, потому что иначе было дорого. S/360 с её почти равноправными регистрами, кроме старших моделей, стоивших миллионы, была сделана на микропрограммных автоматах, и равноправность регистров эмулировалась на микропрограммном уровне. На этом фоне уже 8 честных регистров PDP-11 (хоть, опять же, напрямую использованных в АЛУ только в старших моделях) было прогрессом.
За 10 лет после этого (считаем до 1979-1981) упаковка в формат микропроцессора только усилила давку по ресурсам. 8008, 8048, 8080, 6502 - один аккумулятор. 6800 - два почти равноправных аккумулятора - это нечто особенное, так больше никто не делал. Чуть более высокий сегмент, PDPшки все кроме 11-й - тоже один аккумулятор во главе. Граница до честных почти равноправных регистров как в PDP-11, S/360, S/370 - это было очень существенно.
Насколько этот стиль влиял на всех - не мне судить, я тогда только в детский сад ходил. Но если вокруг были почти везде одноадресный мир - это не могло не влиять.
Тут бы послушать более детально воспоминания тех, кто всё это проектировал.
И компиляторы наверное ВООБЩЕ не занимались распределением регистров, фигачили всё через один? (хотя для 8086 -- охотно поверю).
Занимались, но очень плохо по сравнению с нынешним уровнем. Сейчас только толковый спец в тонкостях архитектуры сможет систематически обгонять компилятор по качеству кода. Тогда - мог любой, кто знал ассемблер, и вопрос был только в объёме работы.
Но 8086 у нас офигенно ортогональный при этом. Выглядит как попытки манипуляции.
Ваши приписки про "офигенно ортогональный" и домыслы про манипуляцию прошу оставить при себе.
Конечно индиректные адресации в 68020+ чуть усложнили декодинг, но во1 в любом коде (уж я-то видел кучи кода под 68к) они используются редко
И что, от этого их свалили бы на микрокоманды, а остальное - на полноценный автомат? Я конечно не спец по OoO, но мне кажется, что это было бы сильно сложно. А поддерживать всю эту хрень таки надо было бы.
Итого -- проблема техническая, причём не требующая хай-перфоманс решения любой ценой.
А вот тут я сильно не уверен. Полноценный OoO на старте был чудовищно дорог в разработке. Intel вытянул его, по слухам, только с государственной помощью, получив заказ на 4e8$$ "за красивые глаза". И это при том, что меньше всяких индиректных, автодекрементных и прочих адресаций. С ними шансы вытянуть разработку, мне кажется, нулевые. Опять же, есть поле для раскопок.
Откуда кстати сразу можно сделать вывод, что уровень инженеров, выдумывавших ibm pc был настолько низок. что они ниасилили бы даже 8255 подключить к 68000.
Уровень у них был как раз очень хорошим. Задачу вложить в минимум аппаратных средств всё что нужно они отработали почти идеально. Лучше них только Возняк был с Apple II, там вообще шедевры инженерного строения.
Рассказы про "больше периферии под 8086" явно не соответствуют историческим фактам. А вот то, что 68000 в 1979 только анонсировался, в 1981 начали производить (а первые версии всегда проблемны), а вот для 8088 был к моменту опытных прототипов IBM PC уже второй источник от AMD - вот это то, что как раз повлияло.
Ну так напишите побольше. И чего-нибудь сложное, где регистров перестанет хватать. Или где массивчики за 64к вылезут.
Опять же, тут надо сравнивать с 386 - где нет проблем с переходом за 64KB. Хотя в huge режиме в 8086 их тоже не очень было:)
"Сложное, где регистров перестаёт хватать" - таких задач было достаточно мало. Опять же напоминаю про качество компиляторов.
Наверное имелось ввиду, что адресация не стала 32-битной? Ну так и не должна, процессор то 16-битный.
Здесь нет однозначной связи. System/360 Model 30 имела 8-битное АЛУ, шины вокруг него, исполняла всё однобайтными порциями. При этом у неё был полный набор 32-битных операций арифметики, и 24-битный адрес (когда младшие модели продавались с 4KB памяти и это уже стоило чудовищных денег, это было реально дофига). Позже, Z80 имел 4-битное АЛУ, но работал в основных командах с 8-битными данными, в части с 16-битными.
А вот то, что одним сегментом нельзя было адресовать больше 64KB, и вообще сегментация защищённого режима в 80286 - который был урезанной версией выбредка кого-то из отцов Intel, пытавшимся ещё что-то получить от мёртворожденного iAPX432 - это тут более существенно. В плюс Мотороле то, что они сразу попытались использовать плоский режим, без этих извращений - и тут не было потерь в скорости.
Однако по сравнению с 8086 и 8088 количество адресных линий возросло с 20 до 24
Только из-за ограничений стиля это было сильно неудобно. Полноценное использование началось уже с 386.
Ага, давайте сравнивать 68000 из 1979 с 80386 из 1985
Нет, ниже было в подробностях - сравнивать нужно диапазон 68010 - 68030.
Хотя вы можете сравнить и 8086 с 68000, конечно. 68000 на три года позже (реальные продажи - 1981), так что к IBM PC он катастрофически опоздал.
То есть выяснили, что страничное MMU в 68k появилось за 3 года до 386.
А в S/370 оно появилось на ≈10 лет раньше, и что? А сколько стоило то MMU, вы таки посмотрели? Ещё удвоить цену процессора? Соответственно, сильное сокращение рынка. Аналогичный пример был с 8087, пока в 386-е не начали вкладывать FPU блок - его ставили только в специализированные машины.
А давайте ещё регистры посчитаем. 8 штук D и 7 штук (не считая стека) A. А в х86 ВСЕГО 7 регистров. Или это не считается?
С количеством регистров - я безусловно согласен, их в 2 раза больше (или 2.5, как считать). Вопрос в том, насколько это влияло на удобство работы кода - в те-то времена. Когда разрабатывалась PDP-11, например, в ней не захотели делать больше 8 регистров, потому что люди путались в таком количестве. Компиляторы стали заметно продвинутее только где-то с середины 1990х, потому что начала разрабатываться теория в современном виде, до этого они были совершенно топорными. Это требует серьёзного рассмотрения, была ли польза с тех 16 (15, неважно).
А вот то, что сейчас ностальгически вспоминается то, чего не было - якобы полная ортогональность - это факт бесспорный.
Тогда становится неясно зачем амд добавило r8..r15 регистры, наверное дураки были
Когда именно AMD их добавила? Это было на 10 лет позже. Для индустрии в те времена это чудовищный промежуток, поменялось практически всё. Про компиляторы я уже говорил, см. выше. Уже набрался опыт и с RISC-процессорами сразу нескольких архитектур, и SSA начали вводить. А вот на 1979 такое было критически мало где, я с ходу только S/370 вспомнил.
Насколько я помню, в 68060 команды не могли продолжаться, только заново переисполняться. Ну и в x86 можно найти ужасы, типа rep movsb. И ничего -- живут как-то, на "микрокоде" дешифруют и исполняют. Так что это плохой аргумент -- технические проблемы вполне решаемые для OoO.
То, что я говорю, это не техническая проблема, после того, как зафиксировали то, чего фиксировать не надо было.
68060 вышел в 1994, это уже был закат. Тут надо уточнить историю, возможно, они ввели несовместимое изменение, но уже опоздали. Факт то, что мозговой заклин на супер-CISC, когда его времена давно ушли, мог - и скорее всего он в первую очередь и погубил - не только m68k, но и другие архитектуры той разработки - в первую очередь VAX.
А вы сколько килобайт кода собственноручно написали для 68к?
Мало. Считайте, один. Но на объективность это не влияет. У меня нет никакой повышенной любви к архитектуре x86 - можете погуглить, какими словами я её ругаю. Но то, что из-за меньшего количества CISC-like наворотов она оказалась более подготовленной к повороту в сторону OoO и RISC - чисто объективный факт, не признавать его нельзя.
Я предпочитаю называть два основных стиля ООП - "активные объекты" и "пассивные объекты". В случае Simula/etc. имеем первый. В случае C++, Java, C#, тысячи их - второй. Да, они разные.
В Эрланге же у вас появляется класс gen-Server, который из которого создается процесс (объект).
Почему-то все говорят про gen_server, хотя там ещё есть вариантов, вплоть до того, что писать весь код процесса самому (ну смысл не так чтобы, сплошной закат солнца вручную, но можно). Похоже, этот рассказ идёт из одного и того же источника.
Статья 1999 года. С Java 1.2 - когда ещё даже базовый JIT толком не был отработан. С основным источником задержек в виде замены примитивных типов на "ящики", ещё и генерализованные до предела. Когда никто из грамотных не предлагал всерьёз переводить математику на такой стиль (хм, сейчас уже вроде можно, если осторожно.) При том, что с тех пор в эту сферу за почти 30 лет вложены огромные средства для оптимизации и ускорения, а теория и практика далеко шагнула вперёд.
Извините, это или злая и неумная шутка, или вы совершенно не владеете проблемным доменом.
И к теме, как писать - a+b или a.plus(b), это имеет отношение только в контексте такой же древней явы, но никак не ООП в целом.
Может и при выполнении. Но тут начинает сильно зависеть от языка, компилятора и прочего.
Простейший пример - если вы записали c=a*b, где все участники - матрицы, вполне возможно, что при размерах матриц миллион на миллион среда сама раскинет это на 100 компов в кластере. А вам не надо было писать все итерирования строк-столбцов, вы просто попросили результат - произведение матриц.
Обычно же говорят о более сложных случаях - когда таки расписываете действия, но явно показываете, что побочных эффектов нет (ну кроме очевидных для рантайма, затрат времени, загрязнения кэшей и всё такое).
Единственный объективный минус ООП это его низкая производительность. Например, инструкция x = a + b в десятки раз быстрее чем x = a.plus(b)
Чтобы было в десятки раз, надо делать динамическую диспетчеризацию в рантайме, по имени метода. А зачем весь ООП сводить к этому?
В C++, например, a+b внутренне превращается в a.operator+(b) или operator+(a,b), где operator+ - такое имя функции, аналогичное вашему plus. А дальше выполняется обычный себе код соответствующей операции (например, для complex это два примитивных сложения, для real и imag части).
Так что "десятки раз" - сказки, и, хм, интересно их происхождение. Поделитесь.
Все остальное от неумение его готовить, но тут как говорится "просто у тебя нормального мужика не было".
Что ООП не всегда уместно - факт. Но его хаятели очень преувеличивают недостатки.
По мнению этих голов, вероятно, да. Но зачем на них ориентироваться?
EEP 76: Priority Messages - в Erlang/OTP 28.0. Криво и неполно, но лёд начал крошиться. Поздравляем с опозданием на 15-20 лет по сравнению с тем, когда это действительно надо было сделать. До полноценной реализации ждать ещё примерно столько же?
CHESS выглядит прикольно. Иногда приходилось делать такие тесты, но очень несистематически и локально. Правда, боюсь, что если рандомизировать всё, то половина будет вылетов во всяких rtld и libc, а их лечить обычно не дело разработчика целевого приложения;\
По совковому словарю - да, может быть. Именно таких "инженеров" тогда и выпускали миллионами. Это из той же оперы, что "Нет, тётя Роза - старший экономист!"
А вот автор статьи, конечно, слегка идеалистичен, но пытается вернуться к истокам. "Инженер (от лат. – хитроумный, остроумный, изобретательный) –создатель некоторых военных машин во втором веке, а впоследствии – творец всяких хитроумных устройств" (источник). И мне его позиция всяко ближе.
Я и не говорил такого. Я говорил о том, что полезно перетащить из C++. Хотя сейчас скажу, что неймспейсы таки косвенно имеют отношение к ООП: как и класс, это средство структурирования.
А как данные привязать к каждому конкретному объекту?
Это альтернатива, известная изначально, но пригодная далеко не всегда. "Перешли" - некорректный термин.
Потрясающий пример как не надо делать. Начиная с того, как не задетекчен случай полного вырождения в вычисление самим компилятором, с отсутствия вариаций по опциям компиляции... Впрочем, автор всегда отличался... мнэээ... оригинальным мышлением и пониженной самокритичностью, так что я не удивлён.
Не обязаны. Можно написать пачку статических процедур, сложить их всех в один класс, вызывать из статического main(), а максимум данных собрать в примитивные типы и их массивы.
Но результат будет однозначно неудобен.
Вы переоцениваете вклад больших партий. Есть объективная цена производства - та самая, которая по расширенному закону Мура падала экспоненциально - и она не давала слишком быстрых результатов.
Хороший вопрос. Возможно, Intel бы умер или ушёл чисто в производство памяти. Что именно IBM дала жизнь линии x86 - не вижу причин спорить с этим.
Но то, что я говорю - что x86 не был настолько плох на общем фоне, а m68k, например, соответственно не настолько лучше остальных, чтобы его проигрыш создал трагедию.
Да. Это не мой тезис. Я тоже немного удивлён. Но если такое приписывают создателю PDP-11, наверно, это соответствует общему пониманию в те времена.
Напоминаю, что вокруг - в среднем и нижнем ценовом сегменте - были чуть ли не тотально архитектуры на один аккумулятор, потому что иначе было дорого. S/360 с её почти равноправными регистрами, кроме старших моделей, стоивших миллионы, была сделана на микропрограммных автоматах, и равноправность регистров эмулировалась на микропрограммном уровне. На этом фоне уже 8 честных регистров PDP-11 (хоть, опять же, напрямую использованных в АЛУ только в старших моделях) было прогрессом.
За 10 лет после этого (считаем до 1979-1981) упаковка в формат микропроцессора только усилила давку по ресурсам. 8008, 8048, 8080, 6502 - один аккумулятор. 6800 - два почти равноправных аккумулятора - это нечто особенное, так больше никто не делал. Чуть более высокий сегмент, PDPшки все кроме 11-й - тоже один аккумулятор во главе. Граница до честных почти равноправных регистров как в PDP-11, S/360, S/370 - это было очень существенно.
Насколько этот стиль влиял на всех - не мне судить, я тогда только в детский сад ходил. Но если вокруг были почти везде одноадресный мир - это не могло не влиять.
Тут бы послушать более детально воспоминания тех, кто всё это проектировал.
Занимались, но очень плохо по сравнению с нынешним уровнем. Сейчас только толковый спец в тонкостях архитектуры сможет систематически обгонять компилятор по качеству кода. Тогда - мог любой, кто знал ассемблер, и вопрос был только в объёме работы.
Ваши приписки про "офигенно ортогональный" и домыслы про манипуляцию прошу оставить при себе.
И что, от этого их свалили бы на микрокоманды, а остальное - на полноценный автомат? Я конечно не спец по OoO, но мне кажется, что это было бы сильно сложно. А поддерживать всю эту хрень таки надо было бы.
А вот тут я сильно не уверен. Полноценный OoO на старте был чудовищно дорог в разработке. Intel вытянул его, по слухам, только с государственной помощью, получив заказ на 4e8$$ "за красивые глаза". И это при том, что меньше всяких индиректных, автодекрементных и прочих адресаций. С ними шансы вытянуть разработку, мне кажется, нулевые. Опять же, есть поле для раскопок.
Уровень у них был как раз очень хорошим. Задачу вложить в минимум аппаратных средств всё что нужно они отработали почти идеально. Лучше них только Возняк был с Apple II, там вообще шедевры инженерного строения.
Рассказы про "больше периферии под 8086" явно не соответствуют историческим фактам. А вот то, что 68000 в 1979 только анонсировался, в 1981 начали производить (а первые версии всегда проблемны), а вот для 8088 был к моменту опытных прототипов IBM PC уже второй источник от AMD - вот это то, что как раз повлияло.
Опять же, тут надо сравнивать с 386 - где нет проблем с переходом за 64KB. Хотя в huge режиме в 8086 их тоже не очень было:)
"Сложное, где регистров перестаёт хватать" - таких задач было достаточно мало. Опять же напоминаю про качество компиляторов.
Угу, спасибо за поправку.
В смысле, от этого сквозной проезд потерялся? Это не должно влиять.
Здесь нет однозначной связи. System/360 Model 30 имела 8-битное АЛУ, шины вокруг него, исполняла всё однобайтными порциями. При этом у неё был полный набор 32-битных операций арифметики, и 24-битный адрес (когда младшие модели продавались с 4KB памяти и это уже стоило чудовищных денег, это было реально дофига). Позже, Z80 имел 4-битное АЛУ, но работал в основных командах с 8-битными данными, в части с 16-битными.
А вот то, что одним сегментом нельзя было адресовать больше 64KB, и вообще сегментация защищённого режима в 80286 - который был урезанной версией выбредка кого-то из отцов Intel, пытавшимся ещё что-то получить от мёртворожденного iAPX432 - это тут более существенно. В плюс Мотороле то, что они сразу попытались использовать плоский режим, без этих извращений - и тут не было потерь в скорости.
Только из-за ограничений стиля это было сильно неудобно. Полноценное использование началось уже с 386.
Нет, ниже было в подробностях - сравнивать нужно диапазон 68010 - 68030.
Хотя вы можете сравнить и 8086 с 68000, конечно. 68000 на три года позже (реальные продажи - 1981), так что к IBM PC он катастрофически опоздал.
А в S/370 оно появилось на ≈10 лет раньше, и что?
А сколько стоило то MMU, вы таки посмотрели? Ещё удвоить цену процессора? Соответственно, сильное сокращение рынка. Аналогичный пример был с 8087, пока в 386-е не начали вкладывать FPU блок - его ставили только в специализированные машины.
С количеством регистров - я безусловно согласен, их в 2 раза больше (или 2.5, как считать). Вопрос в том, насколько это влияло на удобство работы кода - в те-то времена. Когда разрабатывалась PDP-11, например, в ней не захотели делать больше 8 регистров, потому что люди путались в таком количестве. Компиляторы стали заметно продвинутее только где-то с середины 1990х, потому что начала разрабатываться теория в современном виде, до этого они были совершенно топорными. Это требует серьёзного рассмотрения, была ли польза с тех 16 (15, неважно).
А вот то, что сейчас ностальгически вспоминается то, чего не было - якобы полная ортогональность - это факт бесспорный.
Когда именно AMD их добавила? Это было на 10 лет позже. Для индустрии в те времена это чудовищный промежуток, поменялось практически всё. Про компиляторы я уже говорил, см. выше. Уже набрался опыт и с RISC-процессорами сразу нескольких архитектур, и SSA начали вводить. А вот на 1979 такое было критически мало где, я с ходу только S/370 вспомнил.
То, что я говорю, это не техническая проблема, после того, как зафиксировали то, чего фиксировать не надо было.
68060 вышел в 1994, это уже был закат. Тут надо уточнить историю, возможно, они ввели несовместимое изменение, но уже опоздали. Факт то, что мозговой заклин на супер-CISC, когда его времена давно ушли, мог - и скорее всего он в первую очередь и погубил - не только m68k, но и другие архитектуры той разработки - в первую очередь VAX.
Мало. Считайте, один. Но на объективность это не влияет. У меня нет никакой повышенной любви к архитектуре x86 - можете погуглить, какими словами я её ругаю. Но то, что из-за меньшего количества CISC-like наворотов она оказалась более подготовленной к повороту в сторону OoO и RISC - чисто объективный факт, не признавать его нельзя.
Это не ООП-стиль, а процедурный (он же императивный). ООП ортогонально императивности или функциональности.
Я предпочитаю называть два основных стиля ООП - "активные объекты" и "пассивные объекты". В случае Simula/etc. имеем первый. В случае C++, Java, C#, тысячи их - второй. Да, они разные.
Почему-то все говорят про gen_server, хотя там ещё есть вариантов, вплоть до того, что писать весь код процесса самому (ну смысл не так чтобы, сплошной закат солнца вручную, но можно). Похоже, этот рассказ идёт из одного и того же источника.
Статья 1999 года. С Java 1.2 - когда ещё даже базовый JIT толком не был отработан. С основным источником задержек в виде замены примитивных типов на "ящики", ещё и генерализованные до предела. Когда никто из грамотных не предлагал всерьёз переводить математику на такой стиль (хм, сейчас уже вроде можно, если осторожно.) При том, что с тех пор в эту сферу за почти 30 лет вложены огромные средства для оптимизации и ускорения, а теория и практика далеко шагнула вперёд.
Извините, это или злая и неумная шутка, или вы совершенно не владеете проблемным доменом.
И к теме, как писать - a+b или a.plus(b), это имеет отношение только в контексте такой же древней явы, но никак не ООП в целом.
Может и при выполнении. Но тут начинает сильно зависеть от языка, компилятора и прочего.
Простейший пример - если вы записали c=a*b, где все участники - матрицы, вполне возможно, что при размерах матриц миллион на миллион среда сама раскинет это на 100 компов в кластере. А вам не надо было писать все итерирования строк-столбцов, вы просто попросили результат - произведение матриц.
Обычно же говорят о более сложных случаях - когда таки расписываете действия, но явно показываете, что побочных эффектов нет (ну кроме очевидных для рантайма, затрат времени, загрязнения кэшей и всё такое).
Почему только "отчасти"?
Чтобы было в десятки раз, надо делать динамическую диспетчеризацию в рантайме, по имени метода. А зачем весь ООП сводить к этому?
В C++, например, a+b внутренне превращается в a.operator+(b) или operator+(a,b), где operator+ - такое имя функции, аналогичное вашему plus. А дальше выполняется обычный себе код соответствующей операции (например, для complex это два примитивных сложения, для real и imag части).
Так что "десятки раз" - сказки, и, хм, интересно их происхождение. Поделитесь.
Что ООП не всегда уместно - факт. Но его хаятели очень преувеличивают недостатки.
Там было "примерно 100 долларов. Так что 640kB было какой-то несбыточной цифрой на те времена (4100 долларов..."
Кажется, форматтер символы доллара понял как ограничители формулы.