В «Критике общего лиспа», написанной Родни А. Бруксом и Ричардом П. Габриэлем из Стэнфорда в 1984 году, обсуждаются некоторые конструктивные решения, оставленные комитетом по нормализации общего лиспа. Хотя большая часть обсуждения остается в силе, есть два утверждения, которые относятся к технологии, доступной в то время, и могут быть ложными сегодня.
Эти два утверждения:
Слишком много затрат на язык было опровергнуто предупреждением о том, что «любой хороший компилятор» может позаботиться о них. Никто еще не написал - и вряд ли сделает это без огромных усилий - компилятор, который выполняет лишь часть ожидаемых уловок.
Поскольку я новичок в Common Lisp или даже ученик, я не могу быть более конкретным, чем авторы. Кажется, они утверждают, что во многих аспектах языка заложена большая универсальность и гибкость, что делает написание хорошего компилятора довольно сложным.
В ОБЩЕМ ЛИСПе было слишком много контроля над арифметикой с плавающей точкой. И, конечно, хотя правильное поведение интенсивной программы с плавающей запятой может быть достигнуто, производительность может сильно отличаться.
Насколько я понимаю, кажется, что написание эффективного числового кода в Common Lisp возможно, но сложнее, чем должно быть.
Это было тридцать лет назад. Как мне относиться к этим утверждениям сегодня, если я готов написать программы на Common Lisp для одной из распространенных реализаций свободного программного обеспечения (CLISP, SBCL и др.)?
источник
Ответы:
Статья интересна во многих отношениях.
Самая интересная часть заключается в следующем: авторы сами сфальсифицировали статью 1984 года, всего два года спустя, в 1986 году. Брукс и Габриэль разработали высокооптимизирующий компилятор Lisp и в течение нескольких лет продавали его с большим коммерческим успехом: Lucid Common Lisp (PDF).
Обслуживание этого компилятора Lisp по-прежнему доступно от LispWorks : теперь оно называется Liquid Common Lisp .
Оптимизация компилятора Liquid CL описана в Главе 3 Расширенного руководства пользователя : Оптимизация программ на Лиспе .
Несколько коммерческих приложений были написаны и развернуты в Lucid CL. Например, в моем родном городе первая информационная система общественного транспорта для HVV (Hamburger Verkehrsverbund) была развернута с использованием Lucid CL на станции SUN SPARC. Он был доступен для публики на вокзалах с большим сенсорным экраном и в колл-центре.
Lucid CL был успешным, потому что его компилятор рабочего режима создавал быстрые приложения Common Lisp, в основном для платформ Unix / RISC.
Брукс и Габриэль пишут о Lucid Common Lisp в 1986 году:
Таким образом, они только что реализовали то, что «Критика Общего Лиспа» провозглашало трудным или невозможным.
В настоящее время более продвинутые реализации проводят много оптимизаций, но аппаратное обеспечение также в 1000 раз быстрее, чем у нас в 1984 году. Тогда VAX 11/780 имел одну MIPS (миллион инструкций в секунду), и машина Lisp также была в этот диапазон. Моторола 68000 имела тактовую частоту 8 МГц.
Критика в отношении производительности с плавающей запятой и вообще разной производительности все еще остается в силе, но это отражает выбор разработчиков. Некоторые реализации не разрабатываются как высокопроизводительные компиляторы. Их основным направлением может быть мобильность, компактность или что-то еще, и поэтому у них разные цели реализации.
Как пользователь / разработчик, он не обязан писать переносимый код и использовать все десять + поддерживаемых в настоящее время систем Common Lisp. Используйте реализацию, которая лучше всего подходит для проблемы приложения.
источник
Когда эта статья была написана в 1984 году, компьютер с 1 МБ ОЗУ и 20 МБ жестким диском, который мог сидеть на вашем столе, был большой проблемой. Естественно, возникнут споры по поводу практичности языка такого высокого уровня, как Лисп на аппаратном спартанском языке. Достижения, достигнутые с тех пор как в аппаратном обеспечении, так и в технологии компиляции, значительно упростили написание и выполнение программ на Лиспе, независимо от числовой неэффективности, которая может присутствовать в языке.
Программисты часто обменивают вычислительную эффективность на эффективность программирования. Лисп может быть медленным языком (в некоторых реализациях, как и другие языки), но он также имеет заслуженную репутацию для быстрой разработки, и многим программам не требуется высокооптимизированная инфраструктура для обеспечения адекватной производительности.
Выбор реализации Lisp может сильно повлиять на профиль производительности ваших программ. Например, CLISP с готовностью признает, что «Если ваш код сильно числовой, вы можете предпочесть CMUCL». Несколько современных реализаций Lisp (и Scheme) позволяют вам указывать числовые подсказки типов, что увеличивает числовую производительность.
Словом, сегодня ситуация намного лучше, чем была тогда.
источник