"IronPython 실행 중" 저자는 IronPython이 CPython과 달리 Jit 및 프레임 워크 자체에서 특정 최적화 기능을 활용하므로 CPython이이를 활용할 수 없다고 말합니다. 결과적으로 IronPython은 CPython보다 잠재적으로 빠릅니다. 특히 멀티 스레딩 시나리오의 경우.IronScheme이 해석 또는 컴파일 되었습니까? .NET Framework 최적화의 이점이 있습니까?
IronScheme은 이러한 최적화의 이점을 줍니까? 그것은 인터프리터 (컴파일러가 아님)입니까, 인터프리터입니까? Lisp의 특성이기 때문에 인터프리터입니까? Lisp과 같은 유연성을 제공하도록 해석되어야합니다. 인터프리터 인 경우 지터의 최적화를 통해 이익을 얻을 수 있습니까?
IronPython (IronScheme을 기반으로하는 DLR의 첫 번째 글자처럼) IronScheme은 IL 수준까지 컴파일됩니다.
IronScheme에 해석 된 부분이 없습니다 (런타임 심볼 검색을 호출하지 않는 한). DLR의 'branch'에서 모든 것을 추출 했으므로 사용되지 않고 코드 풋 프린트 (DLR의 약 25 % 만 사용했는데 나머지는 파이썬 중심이었습니다).
리플렉터 .NET에서 ironscheme.boot.dll 어셈블리를 볼 수 있습니다 (IL 모드를 사용하는 것이 좋음, C#은 이상하게 재구성되는 경향이 있으며 경우에 따라 명백히 잘못 될 수 있음). 이 전체 어셈블리는 IronScheme에 의해 컴파일됩니다. 런타임에서 생성 된 코드를 보려면 훨씬 더 까다 롭습니다.
이와 같이 이것은 JIT의 모든 이점을 가지고 있으며 DLR에서 더 많은 Scheme 중심으로 만들기위한 최적화를 통해 IronPython보다 일반적으로 성능이 뛰어났습니다 (좋은 18 개월 전 IronPython은 그 이후로 많은 개선이 있었지만, IronScheme은 Scheme을 사용하는 경우조차도 몇 가지 요소가 더 빠르다는 것을 알았습니다.
또한 IronScheme의 기초로서 .NET 프레임 워크를 최대한 활용하고 상호 운용성을 개선하려고 시도했습니다. vectors, byte-vectors, binary-ports 및 hash-tables과 같은 것은 모두 우리가 알고 있고 사용하는 일반적인 .NET 클래스를 기반으로합니다. 각각, object[], byte[], Stream 및 Hashtable이다.
감사합니다. Leppie. –