에 커먼 리스프의 비판 1984 년 로드니 A. 브룩스와 스탠포드에서 리처드 P. 가브리엘에 의해 작성, 커먼 리스프의 정규화위원회에 의해 유지 몇 가지 디자인 결정이 논의된다. 대부분의 논의는 유효하지만 현재 사용 가능한 기술을 언급하는 두 가지 진술이 있으며 오늘날에는 틀릴 수도 있습니다.
이 두 문장은 다음과 같습니다.
‘모든 좋은 컴파일러’가 처리 할 수 있다는 훈계로 언어 비용이 너무 많이 들었다. 아직까지도 많은 노력을 기울이지 않았을 것으로 예상되는 트릭의 일부를 수행하는 컴파일러는 아직 아무도 작성하지 않았습니다.
나는 일반적인 Lisp 초보자이거나 심지어 견습생이기 때문에 저자보다 더 구체적 일 수는 없습니다. 그들은 언어의 여러 측면에 큰 일반 성과 유연성이 내장되어있어 좋은 컴파일러를 작성하는 것이 매우 어렵다고 말합니다.
COMMON LISP에서는 부동 소수점 산술에 대해 너무 많은 제어가 이루어졌습니다. 부동 소수점 집약적 프로그램의 올바른 동작을 달성 할 수는 있지만 성능은 크게 다를 수 있습니다.
내가 아는 한, Common Lisp에서 효율적인 숫자 코드를 작성하는 것이 가능하지만 이전보다 더 어려운 것으로 보입니다.
이것은 30 년 전이었습니다. 일반적인 자유 소프트웨어 구현 중 하나 (CLISP, SBCL et al.)에 대해 Common Lisp 프로그램을 작성하려는 경우 오늘이 진술을 어떻게 고려해야합니까?
답변
이 논문은 여러 가지면에서 흥미 롭습니다.
가장 흥미로운 부분은 이것입니다. 저자들은 2 년 후인 1984 년부터 1984 년부터 논문을 위조했습니다. Brooks와 Gabriel은 고도로 최적화 된 Lisp 컴파일러를 개발하여 몇 년 동안 상용화했습니다 : Lucid Common Lisp (PDF).
이 Lisp 컴파일러에 대한 유지 보수는 여전히 LispWorks 에서 사용 가능 합니다. 이제는 Liquid Common Lisp 라고 합니다.
Liquid CL의 컴파일러 최적화는 고급 사용자 안내서 : Lisp 프로그램 최적화 의 3 장에 설명되어 있습니다.
Lucid CL에는 여러 상용 응용 프로그램이 작성되고 배포되었습니다. 예를 들어 고향에서는 HVV (Hamburger Verkehrsverbund)의 첫 대중 교통 정보 시스템이 SUN SPARCstation에서 Lucid CL을 사용하여 배포되었습니다. 대형 터치 스크린을 사용하는 기차역과 콜센터에서 대중에게 제공되었습니다.
Lucid CL은 프로덕션 모드 컴파일러가 주로 Unix / RISC 플랫폼을 위해 빠른 Common Lisp 응용 프로그램을 만들었 기 때문에 성공했습니다 .
Brooks와 Gabriel은 1986 년 Lucid Common Lisp에 대해 다음과 같이 쓰고 있습니다.
동적으로 리 타게팅 가능한 컴파일러는 다양한 Lisp 구현을위한 쉬운 컴파일을 수행 할 수있는 수단 인 것으로 나타났습니다. Lisp 시스템을 다양한 컴퓨터로 포팅하는 수단; 공통 소스에서 다양한 컴퓨터에 대한 고품질의 고성능 코드를 생성하는 도구입니다.
따라서 그들은 일반 리스프의 비평 이 어렵거나 불가능하다고 주장한 것을 구현했습니다 .
요즘에는 고급 구현이 많은 최적화 작업을 수행하고 있지만 하드웨어는 1984 년보다 1000 배 이상 빠릅니다. VAX 11/780에는 MIPS (초당 백만 명령)가 있고 Lisp Machine도있었습니다. 그 범위. Motorola 68000의 클럭 속도는 8MHz입니다.
부동 소수점 성능 및 일반적으로 변하는 성능에 대한 비판은 여전히 유효하지만 이는 구현 자의 선택을 반영합니다. 일부 구현은 고성능 컴파일러로 개발되지 않았습니다. 그들의 주요 초점은 이식성, 콤팩트 함 또는 다른 것이므로 다른 구현 목표를 가지고 있습니다.
사용자 / 개발자로서 이식 가능한 코드를 작성 하고 현재 지원되는 10 개 이상의 Common Lisp 시스템을 모두 사용하도록 강요받지는 않습니다 . 응용 프로그램 문제에 가장 적합한 구현을 사용하십시오.
답변
이 문서가 1984 년에 쓰여졌을 때, 책상에 앉을 수있는 1MB의 RAM과 20MB의 하드 드라이브를 가진 컴퓨터는 큰 문제였습니다. 당연히, Lisp가 스파르타의 하드웨어에있는 것처럼 언어의 실용성에 대한 분쟁이 발생할 것입니다. 그 이후로 발생한 하드웨어 및 컴파일러 기술의 발전으로 인해 언어에 존재하는 수치 적 비 효율성에 관계없이 Lisp 프로그램을보다 쉽게 작성하고 실행할 수있었습니다.
프로그래머는 종종 프로그래밍 효율성을 위해 계산 효율성을 거래합니다. Lisp는 느린 언어 일 수 있지만 (일부 구현에서는 다른 언어도 가능) 빠른 개발로 명성이 높으며, 많은 프로그램에서 적절한 성능을 발휘하기 위해 고도로 최적화 된 인프라가 필요하지 않습니다.
Lisp 구현을 선택하면 프로그램의 성능 프로필에 크게 영향을 줄 수 있습니다. 예를 들어 CLISP는 “코드가 너무 큰 숫자 인 경우 CMUCL을 선호 할 수 있습니다”라고 즉시 인정합니다. 몇 가지 최신 Lisp (및 체계) 구현을 통해 숫자 유형 힌트를 지정할 수 있으므로 숫자 성능이 향상됩니다.
요컨대, 상황은 오늘날보다 훨씬 나아졌습니다.