From 87decba528a855e81d7d343b53a8c8821b493259 Mon Sep 17 00:00:00 2001 From: klapaucius Date: Sun, 30 Jun 2024 23:27:32 +0500 Subject: [PATCH] june --- compilers.md | 216 ++++++++++++++++++++++++++++++++++++++++++++++++++- index.md | 2 + 2 files changed, 217 insertions(+), 1 deletion(-) diff --git a/compilers.md b/compilers.md index 324d392..6e17312 100644 --- a/compilers.md +++ b/compilers.md @@ -27,6 +27,13 @@ - [Russell](#russell) - [Poly](#poly) - [Воспроизведение](#воспроизведение) + - [Живые ископаемые](#живые-ископаемые) + - [Насколько "мини" может быть мини-MAC?](#насколько-мини-может-быть-мини-mac) + - [Жерар Юэ](#жерар-юэ) + - [Лоуренс Полсон](#лоуренс-полсон) + - [PSL](#psl) + - [Le Lisp](#le-lisp) + - [Cambridge ML](#cambridge-ml) - [Литература](#литература) @@ -889,12 +896,195 @@ map[integer,integer](proc(x:integer)integer(x+y), Мэттьюз использует компактные замыкания-массивы, как и Карделли. Так что, как и в VAX ML, все локальные значения - неизменяемые, изменять можно только ячейку в куче. Функциональные значения - указатели на эти компактные замыкания, что требует двойной косвенности ссылок на функцию, что Мэттьюз считает существенным недостатком. Но ничего лучше пока что не придумал. Главное отличие имплементаций, по видимому - сборщик мусора. Сборщик мусора у имплементации Poly на Паскале не копирующий, как у VAX ML, и вообще не перемещающий, как в первых имплементациях Лиспа. Собирает фрагменты кучи в список свободных. С не самыми лучшими последствиями для скорости аллокации и сборки. В отличие от Карделли, Мэттьюз не считает свой интерактивный компилятор необычным. Но, наверное, на эту оценку повлияло то, что по крайней мере один такой компилятор уже был. -Как и в компиляторе Карделли, в компиляторе Мэттьюза делается не много оптимизации, но Мэттьюз, как и Карделли, заявляет, что все работает "приемлемо быстро" для интерактивной работы. И не приводит никаких измерений производительности. Что "приемлемо быстро" значило в случае VAX ML мы знаем благодаря Йонссону с Августссоном. Но что это значило в случае имплементации Poly на Паскале мы не знаем точно. Наш старый знакомый Гордон и будущий важный герой нашей истории Паульсон оценивают [Gord82] его производительность как высокую. Но это по сравнению с LCF/ML. Не очень высокая планка. +Как и в компиляторе Карделли, в компиляторе Мэттьюза делается не много оптимизации, но Мэттьюз, как и Карделли, заявляет, что все работает "приемлемо быстро" для интерактивной работы. И не приводит никаких измерений производительности. Что "приемлемо быстро" значило в случае VAX ML мы знаем благодаря Йонссону с Августссоном. Но что это значило в случае имплементации Poly на Паскале мы не знаем точно. Наш старый знакомый Гордон и будущий важный герой нашей истории Полсон оценивают [Gord82] его производительность как высокую. Но это по сравнению с LCF/ML. Не очень высокая планка. Оптимизатор (для начала - инлайнер) Мэттьюз решил писать на Poly после того, как перепишет компилятор на Poly. Да, в отличие от Карделли, Мэттьюз собирался делать компилятор, компилирующий самого себя. Причем компилятор должен был стать функцией, доступной в REPL, как в Лиспах или POP-2. Он даже начал это делать, переписав на Poly лексер и генератор кода, но не успел переписать до того, как закончил работать над своей диссертацией [Matt83] в 83-ем году. Работать над компилятором он, правда, не прекратил, но это уже другая история. Смогли ли имплементировать Russell? В своей диссертации Мэттьюз пишет, что еще нет. Но существенно позднее Russell был таки имплементирован [Boeh86]. По видимому, на C [Boeh88]. Слишком поздно, чтоб оказаться в числе первых компиляторов ФЯ. Эту имплементацию авторы тоже сравнивают с имплементацией ML Карделли (Боэм один из пользователей это компилятора), но сходство между этими компиляторами меньше, чем между компилятором Карделли и компилятором Мэттьюза. Например, имплементаторы Russell не используют более современный подход с компактными замыканиями-массивами, которые планировал использовать Стил в Rabbit и которые использовал Карделли. Вместо этого имплементаторы Russell размещают в куче фреймы стека, как делали имплементаторы Interlisp в 70-е. На имплементацию ФЯ компилятор Russell не оказал значительного влияния. Разве что через использование консервативного сборщика мусора Боэма-Демера-Уизера [Boeh88], который происходит от рантайма Russell для Motorola 68K и является той самой работой, которой Боэм как раз известен. Сборщик Боэма подходит для имплементации ФЯ еще меньше, чем сборщик в имплементации Мэттьюза, но, как не странно, будет использоваться для имплементации ФЯ. Так что на этом мы прощаемся с языком Russell и его имплементацией. А к Poly и компилятору Мэттьюза мы еще вернемся. +## Живые ископаемые + +> ML, который используется в Nuprl достаточно близок к оригиналу. +> Кристоф Крейц, Система разработки доказательств Nuprl, версия 5, 2002г. [Krei2002] + +До сих пор мы рассказывали о новых компиляторах, появившихся в 80-е годы. Но не смотря на то, что 70-е не были такими же успешными для имплементаций ФЯ, что-то было сделано и в те годы. Что-то, что можно доделать, улучшить и использовать. Например, имплементация LCF/ML, транслирующая ML в Kbcgs 70-х. + +### Насколько "мини" может быть мини-MAC? + +В 1962-ом в Стенфорде появился новый профессор: Джон МакКарти. Как мы помним, он ушел из МТИ в Стенфорд как раз перед тем, как проект MAC получил много денег. В Стенфорде МакКарти сделал доклад на физическом факультете о Лиспе. В надежде на то, что физики будут использовать Лисп для символьных вычислений. И новый герой нашей истории пропустил этот доклад. +Энтони Хирн (Anthony C. Hearn), физик-теоретик, закончил Университет Аделаиды, Австралия. Защитил диссертацию в Кембриджском университете в 1962-ом. В Стенфорде он начал работать в том же году, что и МакКарти. Но пропустил его доклад про Лисп. Но один из тех, кто доклад не пропустил, посчитал что Лисп может заинтересовать Хирна и посоветовал ему поговорить с МакКарти. Что Хирн и сделал [Hear2005]. +И МакКарти убедил Хирна использовать Лисп, сделав предложение, от которого Хирну было очень сложно отказаться. Если Хирн будет использовать Лисп, то МакКарти даст ему доступ к компьютеру для работы. Но если Хирн не хочет использовать Лисп - он может продолжать искать или выпрашивать машинное время самостоятельно. И как мы выяснили в предыдущей части, для многих героев нашей истории это было совсем не легко. +Так что Хирн стал писать систему компьютерной алгебры REDUCE на Лиспе. Название "REDUCE" - это (анти?) шутка. Системы компьютерной алгебры того времени производили неудобно большие результаты. Хирн посчитал, что будет смешно, если система будет называться в честь операции, которую она не делает. +Хирн описал систему в 68-ом году. Над этой первой версией он работал в Стенфорде, где он проработал до 69-го года. С перерывом в 64-65гг на год работы в лаборатории Резерфорда в Англии. С 69-го до 1980 Хирн работал в Университете Юты, где он написал REDUCE 2. +Из обстоятельств выбора Лиспа Энтони Хирном можно предположить, что он не особенно любил Лисп. И действительно, он писал REDUCE 2 на RLISP, одном из тех языков, которые должны были прикрывать лисповость Лиспа. Вроде MLISP на котором писали LCF. + +``` +EXPR PROCEDURE MAPCAR(X, FN); + IF NULL X THEN NIL + ELSE FN CAR X . MAPCAR(CDR X, FN); +``` + +Но Хирн, в отличие от авторов LCF, недолюбливал Лисп более обычным и менее полезным для развития ФП образом. Так что RLISP, в основном, заменял лисповый синтаксис на другой не самый удачный синтаксис, а не исправлял проблемы Лиспа того времени с типизацией и поддержкой ФП. +RLISP - это не полноценная имплементация языка, а только фронтенд для компилятора Лиспа. Какого компилятора? +REDUCE принципиально отличался от проектов по созданию систем компьютерной алгебры, которые мы обсуждали ранее. И даже от Мини-MAC Мики, создававшего систему переписывания кода Бурсталла с Дарлингтоном. Их разработчики могли себе позволить разработку специальных имплементаций Лиспа или лиспообразного языка, как авторы SCRATCHPAD, а то и выбирать или даже создавать железо для них, как авторы Macsyma. REDUCE был, по большему счету, проектом одного человека, продемонстрировав насколько "мини" может быть мини-MAC. До конца 70-х разработчик REDUCE не мог создавать или даже выбирать ничего из этого. На какой машине будет работать REDUCE? Какой компилятор Лиспа будет её собирать? Это как повезет. +И, как обычно в то время, на всех машинах Лиспы стали разными, и отличались как принципиальными фичами, так и множеством мелких деталей. Но проблему различия Лиспов в мелких деталях было решить проще, чем проблему различий ML-ей, NPL-ей или SASL-ов. Один Лисп можно сделать похожим на другой написав набор функций. Решить проблему принципиальных отличий можно было выбрав некий минимальных их набор, пересечение множеств фич многих Лиспов. +Именно это Хирн и сделал. В 69-ом и 79-ом годах он описал [Hear79] такой диалект - Standard LISP [Padg88] и написал слои совместимости со многими другими Лиспами. И использовал его для имплементации RLISP и REDUCE. Так что, в отличие от MACSYMA и SCRATCHPAD, REDUCE худо-бедно работал на многих системах. +И крах какой-то одной из этих систем не создал бы для REDUCE такого кризиса, какой создал PDP-10-апокалипсис для MACSYMA и LCF. В прошлой части мы уделили достаточно внимания лихорадочным попыткам лисперов спасти MACSYMA. И авторы LCF не могли себе позволить предпринять ни одной из них. LCF, как и прочие проекты, произошедшие от Эдинбургской исследовательской программы, был ближе к написанию REDUCE ограниченными средствами, чем к осваивающим бесконечные деньги проектам золотого века Лиспа вроде MACSYMA. И разработчики LCF могли попытаться использовать наработки прочих спасающихся с PDP-10 и не только. Тем же самым способом, который использовал создатель REDUCE Хирн. И попытались. + +### Жерар Юэ + +Многие участники спасения LCF, правда, хотели спасти не столько LCF, сколько LCF/ML и использовать его для написания и/или скриптования своего доказателя. Новый герой нашей истории Жерар Юэ (Gérard Huet) как раз один из них. +В 1969 Юэ получил дипломы от Национальной высшей школы аэронавтики и космоса (Ecole Nationale Supérieure de l’Aéronautique et de l’Espace) и Сорбонны. Защитил диссертацию в 1972 в Кейс-Вестерн-Резерв университете, Огайо (Case Western Reserve University) [Huet]. В том же 1972 году он начал работать в исследовательском институте Inria, название которого в те времена еще было акронимом INRIA (до 1980 - IRIA, Institut (National) de Recherche en Informatique et en Automatique). +В 1979 в INRIA получили компьютер Honeywell с MULTICS [MULTICS1]. Помните те стоящие десятки миллионов долларов 2023-го года компьютеры, про которые мы писали в первой части? Для которых и в 70-е годы существовали конфигурации, на которых могли бы работать компиляторы ФЯ. И мы точно знаем, что могли бы как раз благодаря Юэ, в числе прочих. Стараниями которых компилятор ФЯ на такой машине заработал. Правда, уже не в семидесятые. +В 70-е в INRIA поддерживали связи с Эдинбургом [MacQ15], и в 80-81 годах Юэ заинтересовался LCF/ML. Осенью 1981-го года Юэ переписал [Nuprl94] код LCF со Stanford LISP на родственный MacLISP для Multics. Тот самый Лисп, который имплементировали в 70-е для одной из неудачных попыток спасения Macsyma. И который дожил до 81-го года благодаря тому, что Бернард Гринберг написал на нем EMACS, ставший популярным у пользователей Multics. В декабре 81-го версия этой имплементации ML была 1.2, все основные изменения были впереди, в 82-ом году. + +### Лоуренс Полсон + +В 82-ом году, не позднее марта, Юэ уже работал над слоями совместимости для того, чтоб LCF могли компилировать разные компиляторы Лиспа, не только Maclisp [LCF92]. Во-первых, в INRIA было множество разных машин. В том числе и Лисп-машины, и, конечно, VAX-11. Все это можно и нужно использовать. Так что LCF в INRIA мог повторить все три попытки MACSYMA спастись с тонущего PDP-10. Во-вторых, у нового коллеги Юэ по спасению LCF есть доступ только к VAX-11. Тот может повторить только одну из них и не ту с которой начал Юэ. +Как мы уже писали в предыдущих главах, один из авторов и первых пользователей LCF - Майкл Гордон - с 81-го года работал в Кембридже, где он хотел продолжать использовать LCF. И SERC (Science and Engineering Research Council) выделил средства на продолжение работы над LCF. Один научный сотрудник должен был работать в Эдинбурге под руководством Милнера, этим научным сотрудником были сначала Дэвид Шмидт (David Schmidt), а после него Линкольн Уоллен (Lincoln Wallen). Они не сделали существенного вклада в имплементацию LCF/ML. Второй научный сотрудник числился в Эдинбурге, но работал под руководством Гордона в Кембридже [Gord2000]. Этим научным сотрудником в 82-83гг. был очередной новый герой нашей истории - Лоуренс Полсон (Lawrence Charles Paulson) и вот он как раз существенный вклад в имплементацию LCF/ML сделал. Полсон - математик, в 77-ом закончил Калтех (California Institute of Technology) и в 81-ом защитил диссертацию по компьютерным наукам в Стенфорде [Paul22] [Paul23]. Работать над LCF в Кембридже он начал в феврале 1982. +Юэ и Полсон работали над кодом LCF совместно, но не параллельно, а последовательно. Юэ работал над кодом примерно месяц, отправлял Полсону код на магнитной ленте по почте. Тот работал примерно месяц и отправлял ленты назад и так далее. В свободные от написания кода месяцы Полсону несколько ездил во Францию, в INRIA, где совещался с Юэ. Также Полсон установил контакты с университетом Чалмерса в Гетеборге, в котором в это время работали над портированием LCF на Franz LISP и VAX-11 независимо. +В те месяцы, когда Полсон работал над кодом - он работал на единственном на весь департамент VAX-11/750. И этот дефицит машинного времени Полсон называет основной причиной для медленного написания кода [Paul22]. VAX-11/750 - это более новая, дешевая и медленная машина из той же линейки, что VAX-11/780. Но, хотя-бы, в данном случае с 4Мб памяти. +Полсон один из многих первых пользователей ML, которые описывают его фичи как "чудеса". На Полсона наибольшее впечатление произвел параметрический полиморфизм. Производительность ML, правда, совсем не была чудесной. +То, что ML не работал на современных распространенных машинах с большой памятью - было только одной из двух главных проблем ML. Разработчики доказателей хотели его использовать, но не могли из-за того, что он был имплементирован как медленный интерпретатор. Поэтому, как мы выяснили в прошлой части, 10KLOC LCF было написано на Лиспе и только 1KLOC на ML [LCF77], причем заметной долей этой тысячи строк были просто обертки для функций, написанных на Лиспе. +Поэтому в июле 82-го, в версии 2.3 [Nuprl94] [HOL88] Жерар Юэ модифицировал транслятор Локвуда Морриса [Huet15], который генерировал из ML интерпретируемый LISP. Он сделал из него генератор LISP-кода для компиляции. Как мы выяснили в прошлой части, из-за разных видов видимости, не всякий код давал одинаковые результаты в интерпретаторе и после компиляции. +Но этот код и после компиляции работал так же медленно как интерпретируемый [Paul22b]. Ведь, как мы выяснили в предыдущей части, компиляторы Лиспа того времени не могли скомпилировать лисповые "лямбды". Тело лямбды было сериализованным кодом, который интерпретировался. И транслятор ML в Лисп-код генерировал множество таких "лямбд". +Но когда пришла очередь Полсона работать над кодом - он решил эту проблему. Тут, по всей видимости, пригодились контакты с университетом Чалмерса, ведь там Йонссон с Августссоном уже придумали как избавиться от лямбд: с помощью лямбда-лифтинга. Так что Полсон применил [Paul22b] эту технику имплементации ленивых ФЯ к имплементации энергичного ФЯ. Также Полсон решил генерировать специализации для разных применений каррированных функций, чтоб лямбд от которых нужно избавляться лифтингом было еще меньше. +Улучшенный Полсоном компилятор попал в версию 3.1 [Nuprl94] [HOL88]. Эта версия, судя по заметкам в коде, [Nuprl94] еще существовала в разных вариантах для разных систем, но версия 3.2 от первого октября 82-го называют "портируемой" [Nuprl94] [HOL88]. +Какое-то время систему можно было собирать Maclisp и Лиспом для Лисп-машин под названием ZetaLisp [Huet86]. Но Лисп-машины и мэйнфреймы не пользовались особой популярностью у имплементаторов доказателей и в дальнейшем остались слои совместимости для трех Лиспов для обычных машин. Все три претендовали на хорошую портируемость и поддержку нескольких платформ, но не все соответствовали этим претензиям. +Первым из трех был, естественно, Franz LISP - первая работающая имплементация Maclisp-образного Лиспа для VAX-11, появившаяся еще в 70-е, о которой мы писали в предыдущей части. Другие два Лиспа немного новее. + +### PSL + +Долгое время проект REDUCE не мог себе позволить разработку собственной имплементации Лиспа, но в конце 70-х ситуация изменилась. Создание компилятора явно стало гораздо более осуществимой задачей и появилась масса новых компиляторов. Одним из которых была и имплементация Standard LISP - Portable Standard LISP (PSL). В университете Юты Хирн нашел единомышленника. Мартин Грисс (Martin Griss) физик, закончил Технион в 67-ом, защитил диссертацию в Иллинойсском университете в Урбане-Шампейне в 71-ом, после чего проработал десять лет в Университете Юты [Griss]. Вместе с Гриссом, Хирн стал работать над компилятором. +И хотя первые экспериментальные компиляторы для разных платформ они смогли написать еще в конце 70-х, но первый компилятор для VAX-11 появился только через годы, когда большая часть выбиравших Лисп для VAX-11 уже выбрала Franz LISP. +PSL [Gris82] компилирует сам себя. Для имплементации рантайма используется низкоуровневое подмножество языка под названием SYSLISP, оперирующее значениями машинных типов. Обратите внимание, что это не тот способ, которым решал проблему портируемости Franz LISP и родственный PSL Cambridge LISP, с которым сравнивали Ponder в предыдущих главах. Cambridge LISP был имплементирован на не связанном с Лиспом языке системного программирования. Только не на C, как Franz LISP, а на BCPL. Как мы помним, авторы Franz LISP объясняли свои успехи выбором такого подхода, но, по всей видимости, то, что они сделали работающий LISP на VAX-11 так быстро объясняется предприимчивостью Фейтмана. +В отличие от авторов Franz LISP, получивших доступ к VAX-11 осенью 78-го года, разработчики PSL получили свой VAX 11/750 только в конце лета 81-го. Серьезная работа над VAX PSL началась в октябре того же года. Первая версия PSL для VAX, которым можно было пользоваться (по крайней мере, по мнению её авторов) - V2 - была готова уже в конце ноября 81-го [Gris82]. +Для этой системы и прочих систем с большим адресным пространством разработчики PSL написали копирующий сборщик мусора. Утверждают, что написали за день. Копирующий сборщик на более медленном VAX-11/750 с в четверо большей кучей работал в 2.5 раз быстрее, чем предыдущий сборщик, больше оптимизированный для того, чтоб система умещалась в кучу PDP-10 (DEC-20). Что все равно означало паузы в одну секунду. +PSL V3 был готов уже в декабре все того-же 1981-го года и генерировал код сравнимый по скорости с тем, который производил Franz LISP. В следующем году эти результаты были улучшены. +Первую рабочую станцию с MC68K разработчики PSL получили в конце 81-го и первый, еще не особенно хорошо оптимизированный кодогенератор для этого процессора был готов ко времени доклада [Gris82] о PSL на конференции в августе 82-го (вышел первоначально как отчет в мае). В этом докладе имплементаторы говорят про то, что начали распространять ленты с VAX PSL для тестирования, после которого собираются сделать первый официальный релиз. +Заявляется, что PSL быстрее, чем Franz LISP, но бенчмарки не особенно разнообразные + +| | tak 18 12 6 | +| :----------------- | :---------: | +| PSL int | **1.00** | +| PSL generic | 3.70 | +| Franz LISP int | 1.47 | +| Franz LISP generic | 14.5 | +| C | 1.88 | + +``` +PSL int +░░░░░░░ +PSL generic +░░░░░░░░░░░░░░░░░░░░░░░░░░ +Franz LISP int +░░░░░░░░░░ +Franz LISP generic +░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░ +C +░░░░░░░░░░░░░ +``` + +Нам, конечно, нужно осторожнее делать далеко идущие выводы из скорости выполнения функции `tak`. Как обстояли дела с реальными программами? VAX PSL достиг достаточной зрелости, чтоб собрать REDUCE - серьезную программу, ради которой все это и делалось, только в мае 82-го. И на VAX её производительность не с чем сравнивать. Но есть с чем сравнить на DEC-20. Скомпилированный PSL `tak` на DEC-20 быстрее, чем скомпилированный MacLisp, не говоря уже про LISP 1.6. Но скомпилированный PSL REDUCE в полтора раза медленнее, чем REDUCE, скомпилированный LISP 1.6. +Но, конечно, нужно осторожнее делать далеко идущие выводы из сложностей с имплементацией систем компьютерной алгебры и их производительностью. Если требования к памяти у них похожи на требования компиляторов ФЯ того времени, то скорость работы может быть ограничена, например, плохой имплементацией больших целых чисел, которая совсем не важна для имплементации ФЯ. + +### Le Lisp + +Третий Лисп, компилирующий новый LCF, создавался по соседству с ним. Но мог бы и не появиться, если б имплементаторы первых двух работали быстрее. +В 1981 в INRIA стартовал проект по созданию системы для разработки интегральных схем под названием LUCIFER [Chai83]. Руководил проектом Жан Вюийемен, уже поучаствовавший в нашей истории в главе про изобретение ленивости. В начале 70-х он доказывал, что корректная имплементация рекурсии в частности и ЛИ вообще требует ленивости. +Разработчики LUCIFER посчитали, что разрабатывать систему лучше на Лиспе, а точнее на каком-нибудь из Лиспов MacLisp семейства. +Но есть проблема: система должна была работать на рабочих станциях, микрокомпьютерах с процессорами Motorola 68K. А разработчики Лиспов MacLisp семейства, как мы выяснили в предыдущей части, обычно не особенно интересовались поддержкой таких машин. В этой же части выясняется, что те немногие, что интересовались, а именно разработчики Franz LISP, все продолжали интересоваться, но ничего кроме VAX-11 пока как следует не поддерживали. Да, они похвалили [Fate81] себя за выбор подходов, хорошо подходящий для портирования на новые машины, но пока не спешили портировать. Только в октябре 1982-го Фейтман напишет в рассылке Franz LISP [Franz38] о том, что Кейт Скловер (Keith Sklower) и Кевин Лэйер (Kevin Layer) работают над версией для MC68000, но первую работающую версию начнут распространять только с конца мая 1983. К этому времени разработчики Le Lisp так привыкли, что Franz LISP не портируют, что писали об этом не "до сих пор не портировали", а "так никогда ни на что и не портировали". +Да, это несколько неожиданно. Мы уже привыкли к тому, что в 80-е годы многие имплементаторы языков программирования пытаются сделать много чего. И, в отличие от годов 70-х, часто успешно. И от тех, с кого, по большому счету и начались эти перемены к лучшему, можно было бы ожидать великих свершений. Которых пока что не было. С тем, почему так вышло мы постараемся разобраться в следующей главе. +Позднее [Chai84], разработчики LUCIFER оценили и Standard LISP с PSL. Принадлежность к семейству MacLisp не была такой уж обязательной и они предполагают, что могли бы использовать PSL. Но в конце 80-го и начале 81-го годов, когда они выбирали Лисп, PSL для нужных им платформ тоже еще не был готов. +Так что в INRIA решили написать собственную имплементацию Лиспа из MacLisp семейства - Le Lisp. Написать преимущественно на Лиспе и коде виртуальной машины LLM3. Да, именно тем способом, на ошибочность которого авторы Franz LISP списывали проблемы с разработкой NIL их соперниками из МТИ. +Le Lisp использовал опыт и идеи из VLISP, предыдущей имплементации над которой работал Жером Шаю (Jérôme Chailloux). Так что уже осенью 1981 Le Lisp заработал на рабочей станции с процессором Motorola, а к осени 1982-го был готов порт на VAX-11. В последующие годы процесс портирования виртуальной машины на новый компьютер был отработан настолько, что требовал только месяц работы. +Производительность тоже получилась хорошей. Похоже, что проблемы NIL были в чем-то другом. Компилятор и интерпретатор Le Lisp даже оптимизировали хвостовую рекурсию во многих случаях. Да, это Лисп из MacLisp семейства и, следовательно, язык с "динамической" видимостью. И, как мы помним, Стил и Сассман писали, что у таких языков принципиальные проблемы с оптимизацией хвостовой рекурсией, но имплементаторы Le Lisp придумали [Sain84] несколько трюков. +В отличие от большинства лисперов, авторы Le Lisp любили измерять производительность тем же бенчмарком, что и авторы ФЯ: + +| | fib 20 | +| :-------------- | :------: | +| Le Lisp (opt) | **1.00** | +| Le Lisp | 5.42 | +| Franz Lisp (1) | 9.17 | +| Franz Lisp (2) | 23.3 | + +``` +Le Lisp (opt) +░░░░ +Le Lisp +░░░░░░░░░░░░░░░░░░░░░░░ +Franz Lisp (1) +░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░ +Franz Lisp (2) +░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░ +``` + +`Le Lisp (opt)` - это компиляция в такой код, который уже нельзя использовать совместно с интерпретатором, все должно быть скомпилировано. +`Franz Lisp (1)` в этом бенчмарке - результат, измеренный Августссоном и Йонссоном, а `Franz Lisp (2)` - имплементаторами Le Lisp. Возможно, что это разные версии. Но также возможно, что это разные настройки компиляции. То, что при разных настройках стирания проверок во время выполнения у лиспов можно получить разные результаты на таком простом коде - это нормально. Но, конечно, то, что авторы Le Lisp выбрали именно такие - подозрительно. +Естественно, такой разницы не видно при сравнении более интересного кода. А именно сематического интерпретатора, написанного на ML и интерпретирующего ФП-код, вычисляющий числа Фибоначчи и пары разных имплементаций унификации: + +| | fib 15 | fib 20 | unif1 | unif2 | +| :--------- | :------: | :------: | :------: | :------: | +| Le Lisp | **1.00** | **1.00** | **1.00** | **1.00** | +| Franz Lisp | 1.44 | 1.02 | 1.52 | 1.42 | + +``` +Le Lisp +░░░░░░░░░░░░░░░░░▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓░░░░░░░░░░░░░░░░░░ +Franz Lisp +░░░░░░░░░░░░░░░░░░░░░░░░░▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓░░░░░░░░░░░░░░░░░░░░░░░░░ +``` + +но превосходство над Franz LISP все равно достигнуто. + +### Cambridge ML + +Не смотря на все эти победы над Franz LISP, он все равно остался самым популярным Лиспом для VAX-11 и для компиляции нового LCF. И немногие измерения [Maun86] производительности использовали именно Franz LISP. + +| | fib 20 | +| :------- | :------: | +| VAX ML | **0.34** | +| LML | 0.63 | +| Franz ML | 1.00 | +| Poly | 1.22 | +| LCF/ML | 31.5 | + +`Franz ML` - это неофициальное название сочетания нового транслятора с Franz LISP бэкендом. Кембриджцы называли новую версию эдинбургского доказателя Cambridge LCF, а компилятор, который можно было собрать отдельно от доказателя - Cambridge ML. В INRIA чаще просто ML с указанием версии, в данном случае это ML V6.2. +`LCF/ML` - это интерпретатор, порт LCF/ML 77 на VAX-11, сделанный в университете Чалмерса + +``` +VAX ML +░ +LML +░░ +Franz ML +░░░ +Poly +░░░░ +LCF/ML +░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░ +``` + +и график только для компиляторов: + +``` +VAX ML +░░░░░░░░░░░░░░░░░░░░░░░░░░░░ +LML +░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░ +Franz ML +░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░ +Poly +░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░ +``` + +Гордон пишет [Gord2000], что производительность по сравнению с интерпретатором увеличилась на неназванных бенчмарках в 20 раз. Полсон называет имплементацию "наконец-то пригодной для использования". +Итак, к осени 82 был готов еще один компилятор ML. Не первый компилятор ML, но первый компилятор LCF/ML. Его авторы, пока что, не стали делать существенных изменений в языке. В отличие от Карделли и Йонссона с Августссоном. +Гордон с Полсоном, правда, считали, что получившийся улучшенный транслятор в Лисп - это только временное решение, и ожидается, что его заменит компилятор Карделли или даже Poly. Они писали, что не хотят разрабатывать имплементации ML они хотят ML использовать [Gord82]. +Но имплементаторы доказателей пока не спешили использовать VAX ML и Poly. Для чего пока что было много причин. Например, у Cambridge ML был интероп с Лиспом, а VAX ML еще не имел даже ввода-вывода и единственным видом интеропа было написание нового примопа. +Так что транслятор в Лисп будут разрабатывать и дальше, сразу несколько разработчиков доказателей. В том числе и добавлять фичи в ML. Но первый форк Cambridge ML произошел до этих первых существенных изменений языка. Осенью 1983, версия 4.3 этой имплементации ML использовали имплементаторами доказателя Nuprl (читается new pearl). Nuprl разрабатывался в Корнеллском университете как и Russell. Ни разработчики Russell, ни разработчики Nuprl не хотели делать ФЯ похожим на HOPE, так что LCF/ML в Nuprl дожил до начала XXI века практически в первозданном виде. +В отличие от них, почти все прочие наши герои хотели делать свои ФЯ похожими на HOPE, но это уже другая история. + ПРОДОЛЖЕНИЕ СЛЕДУЕТ Литература @@ -911,6 +1101,8 @@ map[integer,integer](proc(x:integer)integer(x+y), [Boeh86]: Hans-Juergen Boehm and Alan Demers. 1986. Implementing RUSSELL. In Proceedings of the 1986 SIGPLAN symposium on Compiler construction (SIGPLAN '86). Association for Computing Machinery, New York, NY, USA, 186–195. doi:10.1145/12276.13330 [Boeh88]: Boehm, H.-J., & Weiser, M. (1988). Garbage collection in an uncooperative environment. Software: Practice and Experience, 18(9), 807–820. doi:10.1002/spe.4380180902  [Boeh12]: Ханс Боэм https://archive.is/20121203003033/http://www.hpl.hp.com/personal/Hans_Boehm/ +[Chai83]: J. Chailloux, J.M. Hullot, Jean-Jacques Levy, J. Vuillemin. Le systeme LUCIFER d'aide a la conception de circuits integres. RR-0196, INRIA. 1983. +[Chai84]: Jérome Chailloux, Matthieu Devin, and Jean-Marie Hullot. 1984. LELISP, a portable and efficient LISP system. In Proceedings of the 1984 ACM Symposium on LISP and functional programming (LFP '84). Association for Computing Machinery, New York, NY, USA, 113–122. doi:10.1145/800055.802027 [Card80]: Luca Cardelli, The ML Abstract Machine. https://smlfamily.github.io/history/Cardelli-ML-abstract-machine-1980.pdf [Card82a]: EDINBURGH ML by Luca Cardelli, March, 1982. A README file accompanying the distribution of Cardelli's ML Compiler for VAX-VMS. https://smlfamily.github.io/history/Cardelli-Edinburgh-ML-README-1982_03.pdf [Card82b]: Luca Cardelli, Differences between VAX and DEC-10 ML. March, 1982. https://smlfamily.github.io/history/Cardelli-mlchanges_doc-1982_03.pdf @@ -933,9 +1125,20 @@ map[integer,integer](proc(x:integer)integer(x+y), [Fair82]: Fairbairn, Jon. Ponder and its type system. Technical Report Number 31 University of Cambridge, Computer Laboratory UCAM-CL-TR-31 November 1982 DOI: 10.48456/tr-31 https://www.cl.cam.ac.uk/techreports/UCAM-CL-TR-31.pdf [Fair85]: Fairbairn, Jon. Design and implementation of a simple typed language based on the lambda-calculus. No. UCAM-CL-TR-75. University of Cambridge, Computer Laboratory, 1985. doi:10.48456/tr-75 [Fair86]: Jon Fairbairn, A new type-checker for a functional language, Science of Computer Programming, Volume 6, 1986, Pages 273-290, doi:10.1016/0167-6423(86)90027-4 +[Fate81]: Fateman RJ. Views on transportability of lisp and lisp-based systems. InProceedings of the fourth ACM symposium on Symbolic and algebraic computation 1981 Aug 5 (pp. 137-141). +[Franz38]: Franz Lisp Opus 38.93 https://github.com/krytarowski/Franz-Lisp-Opus-38.93-for-4.3BSD-Reno +[Gris82]: Martin L. Griss, Eric Benson, and Gerald Q. Maguire. 1982. PSL: A Portable LISP System. In Proceedings of the 1982 ACM symposium on LISP and functional programming (LFP '82). Association for Computing Machinery, New York, NY, USA, 88–97. doi:10.1145/800068.802139 +[Griss]: Martin Griss, Biography https://martin.griss.com/bio.htm [Gord80]: Michael Gordon, Locations as first class objects in ML. https://smlfamily.github.io/history/Gordon-ML-refs-1980.pdf [Gord82]: Mike Gordon, Larry Paulson, 1982-11-03 in Polymorphism Vol 1 part 1 Jan 83 +[Gord2000]: Gordon M. From LCF to HOL: a short history. In Proof, language, and interaction 2000 Jul 24 (pp. 169-186). +[Hear79]: J. Marti, A. C. Hearn, M. L. Griss, and C. Griss. 1979. Standard LISP report. SIGPLAN Not. 14, 10 (October 1979), 48–68. doi:10.1145/953997.953999 +[Hear2005]: Hearn, Anthony C.. “REDUCE: The First Forty Years.” Algorithmic Algebra and Logic (2005). +[HOL88]: HOL88 https://github.com/theoremprover-museum/HOL88 [Holm98]: Holmevik, Jan Rune. "Compiling Simula: A historical study of technological genesis." (1998) https://staff.um.edu.mt/jskl1/simula.html +[Huet]: Gérard Huet, biography https://gallium.inria.fr/~huet/biography.html +[Huet86]: Huet, G. (1986). Theorem proving systems of the Formel project. In: Siekmann, J.H. (eds) 8th International Conference on Automated Deduction. CADE 1986. Lecture Notes in Computer Science, vol 230. Springer, Berlin, Heidelberg. doi:10.1007/3-540-16780-3_138 +[Huet15]: Gérard Huet, Thierry Coquand and Christine Paulin. Early history of Coq, September 2015 https://coq.inria.fr/refman/history.html [Hugh82]: Hughes, John. Graph reduction with super-combinators. PRG28. Oxford University Computing Laboratory, Programming Research Group, 1982. [Hugh82b]: R. J. M. Hughes. 1982. Super-combinators a new implementation method for applicative languages. In Proceedings of the 1982 ACM symposium on LISP and functional programming (LFP '82). Association for Computing Machinery, New York, NY, USA, 1–10. DOI:10.1145/800068.802129 [Hugh83]: Hughes, Robert John Muir. "The design and implementation of programming languages." Ph. D. Thesis, Oxford University (July 1983) (published as Technical Monograph PRG-40 September 1984). @@ -946,19 +1149,30 @@ SIGPLAN '84: Proceedings of the 1984 SIGPLAN symposium on Compiler construction [John85]: Johnsson, T. (1985). Lambda lifting: Transforming programs to recursive equations. In: Jouannaud, JP. (eds) Functional Programming Languages and Computer Architecture. FPCA 1985. Lecture Notes in Computer Science, vol 201. Springer, Berlin, Heidelberg. doi:10.1007/3-540-15975-4_37 [John95]: Thomas Johnsson. Graph reduction, and how to avoid it. In Electronic Notes in Theoretical Computer Science Volume 2, 1995, Pages 139-152 DOI:10.1016/S1571-0661(05)80191-4 [Joy86]: Joy, William N., Susan L. Graham, Charles B. Haley, Marshall Kirk McKusick, and Peter B. Kessler. "Berkeley Pascal User’s Manual Version 3.1− April 1986. +[Krei2002]: Kreitz, Christoph. "The Nuprl Proof Development System, Version 5: Reference Manual and User’s Guide." Department of Computer Science, Cornell University (2002) +[LCF77]: Code for LCF Version 5, Oct 1977 https://github.com/theoremprover-museum/LCF77 +[LCF92]: cambridge lcf 1.5 (25-AUG-92) https://github.com/kohlhase/CambridgeLCF [Lieb81]: Lieberman, Henry, and Carl Hewitt. "A Real Time Garbage Collector Based on the Lifetimes of Objects" AI Memo No. 569A October, 1981. [MacQ82]: D. B. MacQueen and Ravi Sethi. 1982. A semantic model of types for applicative languages. In Proceedings of the 1982 ACM symposium on LISP and functional programming (LFP '82). Association for Computing Machinery, New York, NY, USA, 243–252. doi:10.1145/800068.802156 [MacQ14]: Luca Cardelli and the Early Evolution of ML, by David MacQueen. A paper presented at the Luca Cardelli Fest at Microsoft Research Cambridge on Sept. 8, 2014. [MacQ15]: MacQueen, David B. The History of Standard ML: Ideas, Principles, Culture https://www.youtube.com/watch?v=NVEgyJCTee4 [Matt83]: Matthews, David Charles James. Programming language design with polymorphism. No. UCAM-CL-TR-49. University of Cambridge, Computer Laboratory, 1983. [Matt85]: David C. J. Matthews. 1985. Poly manual. SIGPLAN Not. 20, 9 (August 1985), 52–76. doi:10.1145/988364.988371 +[Maun86]: Mauny, M., & Suárez, A. (1986). Implementing functional languages in the Categorical Abstract Machine. Proceedings of the 1986 ACM Conference on LISP and Functional Programming - LFP ’86. doi:10.1145/319838.319869 [McKus]: Marshall Kirk McKusick. A BERKELEY ODYSSEY: Ten years of BSD history. [Miln93]: Frenkel, Karen A. and Robin Milner. “An interview with Robin Milner.” Commun. ACM 36 (1993): 90-97. DOI:10.1145/151233.151241 [Miln2003]: interview with Robin Milner, held in Cambridge on the 3. September 2003 http://users.sussex.ac.uk/~mfb21/interviews/milner/ [Modula3]: MODULA-3 authors https://www.cs.purdue.edu/homes/hosking/m3/reference/authors.html +[MULTICS1]: https://www.multicians.org/benchmarks.html#INRIA [Mycr80]: Mycroft, A. (1980). The theory and practice of transforming call-by-need into call-by-value. In: Robinet, B. (eds) International Symposium on Programming. Programming 1980. Lecture Notes in Computer Science, vol 83. Springer, Berlin, Heidelberg. doi:10.1007/3-540-09981-6_19 [Mycr16]: Alan Mycroft, Mini CV https://www.cl.cam.ac.uk/~am21/minicv.txt [Nebe83]: Nebel, B. (1983). Ist Lisp Eine ‘Langsame’ Sprache?. In: Neumann, B. (eds) GWAI-83. Informatik-Fachberichte, vol 76. Springer, Berlin, Heidelberg. https://doi.org/10.1007/978-3-642-69391-5_3 +[Nuprl94]: Nuprl 3.2 (26-MAY-94) https://github.com/owo-lang/nuprl-3 https://web.archive.org/web/20220630143027/http://www.cs.cmu.edu/afs/cs/project/ai-repository/ai/areas/reasonng/atp/systems/nuprl/0.html +[Padg88]: Padget, Julian. "Three Uncommon Lisps." In First International Workshop on Lisp Evolution and Standardization. 1988. +[Paul22]: Lawrence Paulson. Memories: Edinburgh LCF, Cambridge LCF, HOL88 https://lawrencecpaulson.github.io/2022/09/28/Cambridge_LCF.html +[Paul22b]: Lawrence Paulson. Memories: Edinburgh ML to Standard ML https://lawrencecpaulson.github.io/2022/10/05/Standard_ML.html +[Paul23]: Lawrence Paulson. Curriculum Vitae https://www.cl.cam.ac.uk/~lp15/Pages/vita.pdf +[Sain84]: Emmanuel Saint-James. 1984. Recursion is more efficient than iteration. In Proceedings of the 1984 ACM Symposium on LISP and functional programming (LFP '84). Association for Computing Machinery, New York, NY, USA, 228–234. doi:10.1145/800055.802039 [Sait82]: N. Saito. ML System on Vax Unix. README for Saito’s Unix port of VAX ML, March 1982. [SERC83]: DISTRIBUTED INTERACTIVE COMPUTING NOTE 781 https://www.chilton-computing.org.uk/acd/pdfs/dic/dic781.pdf [Thom76]: Christopher Mark Thomson. The Run-Time structure of an ALGOL 68 Student Checkout Compiler. Master's thesis, Department of Computing Science, University of Alberta, 1976. diff --git a/index.md b/index.md index 489fd6f..795f6b0 100644 --- a/index.md +++ b/index.md @@ -12,6 +12,8 @@ --------------------------- +[Обновление 2024-06-30](compilers.md#живые-ископаемые) + [Обновление 2024-05-29](compilers.md#чайники-рассела) [Обновление 2024-04-29](compilers.md#еще-ортогональнее)