로드 히트 스토어

Load-Hit-Store

Load-Hit-Store(LHS)는 스토어 조작의 타겟이 된 메모리 로케이션이 로드되는 CPU의 데이터 의존관계입니다.올바른 값을 취득할 수 있도록 CPU는 스토어가 완료될 때까지 기다려야 할 수 있습니다.여기에는 예를 들어 L1 캐시 왕복이 수반되며, 이 기간 동안 파이프라인의 대부분 또는 전부가 정지되어 성능이 현저하게 저하됩니다.예를 들어 (C/C++):[1]

인트 느리다(인트 *a, 인트 *b) {     *a = 5;     *b = 7;     돌아가다 *a + *b; }

여기서 언어 규칙은 컴파일러가 포인터가 다음과 같이 가정하는 것을 허용하지 않습니다. a그리고.b다른 메모리 위치를 참조합니다.따라서 일반적으로는 최종 추가(또는 이 단순한 예에서는 반환값을 12로 사전 계산)하기 위해 저장된 값을 레지스터에 유지할 수 없으며 첫 번째 메모리 위치에서 적어도 값을 새로고침하는 코드를 방출해야 합니다.*a유일한 현실적인 대안은 테스트앤브런치입니다a그리고.b이 경우 올바른 반환값은 14이지만 포인터가 동일하지 않으면 상당한 오버헤드가 발생하며 함수 인라인에 의해 최적화가 활성화됩니다.

다음 연락처로 전화하면slow에 대해 같은 주소로 작성됩니다.a그리고.b메모리 저장소와 메모리 부하 사이에는 데이터 의존성이 있습니다.slow일부 CPU 설계(데스크탑 또는 노트북용 범용 프로세서 등)는 복잡한 스토어 투 로드 포워딩에 상당한 양의 다이 공간을 할당하고 있습니다.이것에 의해, 오퍼랜드의 네이티브 얼라인먼트등의 적절한 상황에서는, 캐시의 라운드 [2]트립을 기다릴 필요가 없어집니다.다른 CPU(임베디드 디바이스나 비디오 게임 콘솔용 등)는 덜 정교하거나 심지어 최소한의 접근방식을 사용할 수 있습니다.또, 퍼포먼스에 중요한 코드의 부하에 의한 빈번한 격납을 피하기 위해서, 또는 퍼포먼스 최적화시에 그것들을 삭제하기 위해서, 소프트웨어 개발자에 의존합니다.미니멀리즘 어프로치에서는 스토어 대 로드 의존성에 의해 스토어 버퍼의 플래시가 강제되어 파이프라인이 정지합니다.이것에 의해, 높은 퍼포먼스 비용으로 정확한 계산 결과를 얻을 수 있습니다.

레퍼런스

  1. ^ "Archived copy". Archived from the original on 2021-01-20. Retrieved 2017-10-23.{{cite web}}: CS1 maint: 제목으로 아카이브된 복사(링크)
  2. ^ Wong, Henry (9 January 2014). "Store-to-Load Forwarding and Memory Disambiguation in x86 Processors". {{cite journal}}:Cite 저널 요구 사항 journal=(도움말)