W A Critique of Common Lisp napisanym przez Rodneya A. Brooksa i Richarda P. Gabriela ze Stanforda w 1984 roku omówiono niektóre decyzje projektowe zachowane przez komitet normalizacyjny Common Lisp. Chociaż większość dyskusji pozostaje aktualna, istnieją dwa stwierdzenia odnoszące się do technologii dostępnej w tym czasie i mogą być dziś fałszywe.
Te dwa stwierdzenia to:
Zbyt wiele kosztów języka zostało odrzuconych z napomnieniem, że „każdy dobry kompilator” może się nimi zająć. Nikt jeszcze nie napisał - i prawdopodobnie nie będzie bez ogromnego wysiłku - kompilatora, który wykonuje ułamek oczekiwanych sztuczek.
Ponieważ jestem nowicjuszem Common Lisp, a nawet uczniem, nie jestem w stanie być bardziej szczegółowy niż autorzy. Wydaje się, że twierdzą, że w kilku aspektach języka wbudowana jest duża ogólność i elastyczność, co sprawia, że pisanie dobrego kompilatora jest dość trudne.
We WSPÓLNYM LISPie nieco za dużo kontroli nad arytmetyką zmiennoprzecinkową. I z pewnością, chociaż można uzyskać prawidłowe zachowanie programu intensywnie zmiennoprzecinkowego, wydajność może się znacznie różnić.
O ile rozumiem, wydaje się, że pisanie wydajnego kodu numerycznego we wspólnym Lisp jest możliwe, ale trudniejsze niż musi być.
To było trzydzieści lat temu. Jak powinienem dziś traktować to stwierdzenie, jeśli chcę pisać programy Common Lisp dla jednej ze wspólnych implementacji wolnego oprogramowania (CLISP, SBCL i in.)?
źródło
Odpowiedzi:
Artykuł jest interesujący na wiele sposobów.
Najciekawsze jest to, że autorzy sfałszowali artykuł z 1984 r. Zaledwie dwa lata później w 1986 r. Brooks i Gabriel opracowali wysoce optymalizujący kompilator Lisp i sprzedawali go od wielu lat z sukcesem: Lucid Common Lisp (PDF).
Obsługa tego kompilatora Lisp jest nadal dostępna z LispWorks : teraz nazywa się Liquid Common Lisp .
Optymalizacje kompilatora Liquid CL są udokumentowane w Rozdziale 3 Zaawansowanego Podręcznika Użytkownika : Optymalizacja programów Lisp .
Kilka aplikacji komercyjnych zostało napisanych i wdrożonych w Lucid CL. Na przykład w moim rodzinnym mieście pierwszy system informacji o transporcie publicznym dla HVV (Hamburger Verkehrsverbund) został wdrożony przy użyciu Lucid CL na stacji SUN SPARC. Był dostępny publicznie na dworcach kolejowych za pomocą dużego ekranu dotykowego oraz w call center.
Lucid CL odniósł sukces, ponieważ jego kompilator w trybie produkcyjnym stworzył szybkie aplikacje Common Lisp, głównie na platformy Unix / RISC.
Brooks i Gabriel piszą o Lucid Common Lisp w 1986 roku:
W ten sposób właśnie wdrożyli to, co Krytyka wspólnej Lisp uważała za trudne lub niemożliwe.
Obecnie bardziej zaawansowane wdrożenia przeprowadzają wiele optymalizacji, ale sprzęt jest także ponad 1000 razy szybszy niż w 1984 roku. VAX 11/780 miał wtedy jeden MIPS (milion instrukcji na sekundę), a maszyna Lisp była również w ten zakres. Motorola 68000 miała częstotliwość taktowania 8 MHz.
Krytyka dotycząca wydajności zmiennoprzecinkowej i ogólnie różnej wydajności jest nadal aktualna, ale odzwierciedla to wybór implementatorów. Niektóre implementacje nie są opracowywane jako kompilatory o wysokiej wydajności. Ich głównym celem może być przenośność, kompaktowość lub coś innego, a zatem mają one różne cele wdrożenia.
Jako użytkownik / programista nie trzeba pisać przenośnego kodu i używać wszystkich dziesięciu obecnie obsługiwanych systemów Common Lisp. Użyj implementacji, która najlepiej odpowiada problemowi z aplikacją.
źródło
Kiedy ten artykuł został napisany w 1984 r., Komputer z 1 megabajtem pamięci RAM i 20 megabajtowym dyskiem twardym, zdolny do siedzenia na twoim biurku, był wielkim problemem. Oczywiście powstają spory dotyczące praktyczności języka tak wysokiego poziomu, jak Lisp na sprzęcie, który spartan. Postępy w technologii sprzętowej i kompilatorowej, które nastąpiły od tego czasu, znacznie ułatwiły pisanie i uruchamianie programów Lisp, niezależnie od jakichkolwiek nieefektywności liczbowych, które mogą występować w języku.
Programiści często handlują wydajnością obliczeniową w celu zwiększenia wydajności programowania. Lisp może być wolnym językiem (w niektórych implementacjach, ale także w innych językach), ale ma również zasłużoną reputację do szybkiego rozwoju, a wiele programów nie wymaga wysoce zoptymalizowanej infrastruktury do wykazywania odpowiedniej wydajności.
Wybór implementacji Lisp może znacznie wpłynąć na profil wydajności twoich programów. Na przykład CLISP chętnie przyznaje, że „Jeśli twój kod jest silnie numeryczny, możesz preferować CMUCL”. Kilka nowoczesnych implementacji Lisp (i schematu) pozwala określić podpowiedzi typu numerycznego, co zwiększy wydajność numeryczną.
Krótko mówiąc, sytuacja jest dziś znacznie lepsza niż wtedy.
źródło