CPU 아키텍처는 절차 상 런타임에 편향되어 있습니까?

Rust와 같은 동시 런타임에서 성능을 향상시키기 위해 CPU를 변경할 수있는 변경 사항이 있습니까? 예를 들어, 동시 런타임에 도움이되는 분기 예측 구현 또는 캐시 크기가 변경 되었습니까?

현재 CPU 디자인이 C와 같은 절차 적 런타임에 더 최적화 될 수 있다는 인상을 받았습니다. 대신에 동시 런타임에 최적화하려고한다면 CPU가 어떻게 달라 집니까?

불가피하게, 분기 코드는 절차 코드를 분석하는 연구 논문에서 도출 된 일반화를 기반으로 구현되었습니다. 동시성 추상화가 기존 분기 예측 알고리즘에 악영향을 미치는 런타임에 중요한 작업 세트를 추가하는지 궁금합니다. 예를 들어, for 루프에서 예측하는 것이 한 가지이지만 분기의 대상이 항상 새로운 메모리 부분 (그래픽, 텍스트 등) 인 경우 항상 캐시 미스가되고 분기가 발생하지 않습니다. 아직 다루지 않았기 때문입니다.

내용은 항상 RAM에 있지만 내용이 사용되는 것보다 작은 크기 순서로 분기되므로 캐시에로드 된 후에도 여전히 어리석은 질문 일 것입니다 ...하지만 여전히 거기에 있습니다 절차 적 런타임에서 캐시 및 분기 예측 변수에 저장된 컨텍스트에 대해 관찰 가능한 시간 경계 여야하며, 이는보다 병렬화 된 환경에서 추상화 경계로 나타납니다. 궁금합니다. 이러한 경계가 준수 되었습니까? 어떤 연구 논문도 이것을 분석 했습니까?

CPU 아키텍처는 동시 코드보다 절차 코드쪽으로 편향되어 있습니까? 또는 현대 CPU가 고도의 동시성 언어가 겪지 않는 충분히 범용 적인가?

현대 컴퓨터 아키텍처는 다이 영역의 비용과 전력 소비에 대비하여 컴파일러가 생성 한 코드의 품질을 향상시키려는 목적으로 설계되는 경우가 더 많습니다. 런타임 라이브러리는 효율적인 방식으로 실행되어야하는 컴파일 된 코드의 특정 인스턴스입니다.

오랫동안, 대부분의 아키텍처의 대상 언어는 "C"언어였습니다. 이것은 그 언어가 하드웨어에 대해하는 겸손한 요구와 그것이 거의 보편적 인 시스템 프로그래밍 언어가되었다는 사실을 반영합니다 (Sorry Rust and Go, 당신은 C를 이길 수있는 먼 길을 가졌습니다).

그 결과 새로운 언어는 종종 C와 동등한 의미로 정의되어 현재 컴퓨터에는 없을 수있는 프로세서 기능이 필요하지 않게됩니다.

최신 컴파일러와 잘 어울리는 프로세서의 대가는 해당 컴파일러의 코드가 제대로 실행되고 프로세서가 경쟁력을 가질 수있는 기회가 있다는 것입니다. 여기서 실패 비용은 프로세서를 시작하기 전에 파산합니다. 부정적인 측면의 두 가지 사례는 인텔의 iAPX-432와 Itanium입니다. 둘 다 컴파일러 (Ada와 C)와 매우 열악한 관계를 유지하면서 제품이 실리콘과 소프트웨어 간의 비난 게임으로 바뀌지 못했다.

의심의 여지가 없습니다.

특히, C99가 암시하는 통신 모델은 공유 메모리입니다. 보다 진보 된 동시 언어에는 Rust에서와 같이 메시지 전달 채널과 같은보다 풍부한 통신 모델이 있습니다.

최신 CPU 아키텍처에는 공유 메모리에 대한 명시적인 하드웨어 지원이 있습니다. 특히, MESI와 같은 캐시 일관성 프로토콜은 실제 게이트 및 와이어에서 구현됩니다. 메시지 전달에 대한 아이디어가 CPU에 익숙하지 않더라도 프로세스 간 메시지 전달에 대한 실제 지원은 없습니다. 최신 PCI-e 버스는 메시지 전달을 사용하여 공유 메모리를 에뮬레이션하는 반면 CPU 프로세스는 공유 메모리를 사용하여 메시지 전달을 에뮬레이션해야합니다!