함수형 프로그래밍을 위해 설계된 CPU는 어떻게 다릅니 까?

CPU는 사람들이 암묵적으로 또는 명시 적으로 작성할 소프트웨어를 염두에두고 설계되었습니다.

명령어 세트 아키텍처의 디자인을 살펴보면 각 명령어가 명령형 스타일 명령을 인코딩한다는 의미에서 매우 "필수적"인 것 같습니다. 또한 현재의 명령어 세트 아키텍처는 프로그래머가 생성하는 코드 유형에 따라 부분적으로 진화 한 것으로 보입니다.

함수형 프로그래밍 스타일로 작성된 프로그램 만 실행한다는 것을 알고 CPU를 처음부터 새로 설계한다면, CPU가 기존 CPU와 어떻게 다르게 설계 될까요?

실제로 완료되었습니다 : https://en.wikipedia.org/wiki/Lisp_machine

FP에 대한 CPU 디자인의 한 가지 측면은 가비지 수집입니다. GC는 기능적 언어에 매우 중요합니다. 일반적인 구현에서는 GC가 포인터와 비 포인터 데이터를 구별 할 수 있어야합니다. 효과적으로, 그것은 데이터를 따라 여분의 비트를 저장하는 것을 의미합니다. 예를 들어, OCaml 정수는 32 비트 아키텍처에서는 31 비트이고 64 비트 아키텍처에서는 63 비트입니다. 정수 연산은 어색한 추가 이동 연산을 포함합니다. 다른 언어 (또는 다른 OCaml 데이터 형식)는 해당 추가 비트에 대한 전체 기계어를 낭비 할 수 있으므로 64 비트 정수에 128 비트를 사용합니다. 기본적으로 GC를 위해 설계된 CPU에는 65 비트 데이터 버스가 있지만 64 비트 산술이있을 수 있습니다.

즉, 많은 비 기능적 언어들도 가비지 콜렉션을 가지므로 각 아키텍처에서 이익을 얻을 수 있습니다.

염두에 두어야 할 또 다른 사항은 일반적으로 FP의 메모리 사용량이 명령형 프로그램보다 훨씬 더 흩어져 있다는 것입니다. 주로 배열을 사용하는 것이 자연스럽지 않기 때문입니다. 결과적으로, 이러한 프로그램은 인접한 메모리 청크를 캐싱함으로써 이익을 얻지 못합니다. 따라서 FP CPU는 다른 캐싱 전략을 사용할 수 있습니다.

Reduceron 과 그 후속 버전 인 PilGRIM ¹ 과 같이 거대한 스택을 사용하여 아무것도 변경하지 않거나 대규모 병렬 설정을 활용할 수 있습니다 .

처음에는 아무것도 변하지 않을 것이라는 성명은 굵은 것처럼 보이지만 CPU는 순차적이므로 효율성을 위해 사용 가능한 하드웨어를 사용하는 변환 프로세스 (컴파일)가 있습니다. 다른 아키텍처가있을 경우, 일부 작업이 더 빠를 수 있으며, 일부는 속도를 높이기 위해 해킹 트릭이 필요합니다.

차이를 만드는 아키텍처는 맵 작업과 목록이 더 빨리 실행되어야합니다 (전체 스토리가 아니라 효과를 보여주기에 충분합니다). 기본적으로 목록을 실행하기 위해 동적으로 변경되는 하드웨어를 만들 가능성이 없으므로 연속 메모리에 저장됩니다. 우리는 어떤 형태의 배열 표현을 고수합니다. 비 순차 설정으로 실행하기 위해 Reduceron으로 돌아갑니다. 따라서 연속 명령어를위한 하나의 중앙 처리와 병렬 처리를 효과적으로 지원합니다.

다른 점은 여러 함수를로드하고 프레임 저글링없이 실행할 수 있다는 것입니다. 그러나 함수에 여러 단위를 추가하면 메모리에 액세스 할 때 혼란을 초래할 수 있습니다.

kne의 대답에 추가하여 GC는 보조 프로세서로 실행하는 것이 유리하며 매우 깔끔한 기능입니다.

1 : PilGRIM은 Boeijink A., Hölzenspies PKF, Kuper J. (2011)에 잘 설명되어 있습니다. PilGRIM 소개 : 게으른 기능 언어를 실행하기위한 프로세서. 에서 : Hage J., Morazán MT (eds) 기능 언어의 구현 및 적용. IFL 2010. 컴퓨터 과학 강의 노트, vol 6647. Springer, Berlin, Heidelberg .

먼저 약간의 농담 : 100 % 기능성 프로그램을 실행하면 유용한 기능을 수행 할 수 없으므로 NOP 명령 만 있으면 충분합니다. (나는 화염 전쟁을 위해 이것을 연다).

따라서 IO에 대한 명령과 명령 프로그래밍에 대한 일반적인 지원이 필요합니다.

그렇지 않으면 사용 된 실제 언어에 부분적으로 의존합니다. 내 마음 위에 두 사람은 하스켈과 얼랭입니다.

나는 Haskell이 목록과지도를 지원함으로써 혜택을 얻을 수 있다고 생각합니다. 특정 하드웨어 메모리 매핑에서 목록을 지원하여 연결된 목록을 일련의 주소로 변환 할 수 있습니다. 첫 번째 요소는 주소 n에 있고, 두 번째 요소는 주소 n + 1에있을 수 있습니다. 목록에서 첫 번째 요소를 제거하려면 포인터 n을 변경하면됩니다. 마지막으로, n 포인터를 삭제하면 모든 메모리가 해제 될 수 있습니다. 지도는 연관 배열로 지원 될 수 있습니다. 검색 값을 입력하면 메모리 시스템이 항목을 반환합니다. 반복 검색이 필요하지 않습니다.

Erlang은 메시지 / 프로세스 지원 및 전체 상태의 테일 재귀를 활용할 수 있습니다. 메시지와 프로세스는 다양한 방식으로 지원 될 수 있으며, 한 예로는 매우 많은 양의 처리 코어가있을 수 있습니다. 테일 재귀는 메모리 컨트롤러가 상태를 훨씬 더 빠르게 복사 할 수 있다는 것을 알고 향상 될 수 있습니다. 아마도 많은 양의 데이터를 복사하지 않고 단순히 메모리 시스템 포인터를 수정하는 것입니다.