이것이 메모리 오버 헤드가 아닙니까?
예 아니요 어쩌면?
머신의 메모리 주소 범위와 스택에 묶을 수없는 방식으로 메모리의 위치를 지속적으로 추적해야하는 소프트웨어를 상상하기 때문에 이는 까다로운 질문입니다.
예를 들어, 사용자가 다른 음악 파일을로드하려고 할 때 음악 파일이 사용자가 버튼을 눌러로드하고 휘발성 메모리에서 언로드하는 음악 플레이어를 상상해보십시오.
오디오 데이터가 저장된 위치를 어떻게 추적합니까? 메모리 주소가 필요합니다. 이 프로그램은뿐만 아니라 메모리뿐만 아니라 오디오 데이터 청크를 추적 할 필요 가 어디 메모리에. 따라서 메모리 주소 (예 : 포인터)를 유지해야합니다. 메모리 주소에 필요한 저장 공간의 크기는 머신의 주소 범위와 일치합니다 (예 : 64 비트 주소 지정 범위의 경우 64 비트 포인터).
따라서 "예"의 일종이며 메모리 주소를 추적하기 위해 스토리지가 필요하지만 동적으로 할당 된 메모리의 경우이를 피할 수있는 것은 아닙니다.
이것은 어떻게 보상됩니까?
포인터 자체의 크기에 대해서만 이야기하면 스택을 사용하여 비용을 피할 수 있습니다. 예를 들어 컴파일러는 포인터의 비용을 피하면서 상대 메모리 주소를 효과적으로 하드 코딩하는 명령어를 생성 할 수 있습니다. 그러나 이것은 가변 크기의 대규모 할당에 대해이 작업을 수행하면 스택 오버플로에 취약하고 사용자 입력에 의해 구동되는 복잡한 일련의 분기 (오디오 예제에서와 같이)가 불가능한 경우도 있습니다 (오직 불가능하지 않은 경우). 위).
또 다른 방법은 더 연속적인 데이터 구조를 사용하는 것입니다. 예를 들어, 노드 당 두 개의 포인터가 필요한 이중 연결 목록 대신 배열 기반 시퀀스를 사용할 수 있습니다. 또한이 두 가지의 하이브리드를 롤링되지 않은 목록처럼 사용할 수 있습니다.이 목록은 N 개의 모든 인접 요소 그룹 사이에 포인터 만 저장합니다.
시간이 중요한 메모리 부족 애플리케이션에 포인터가 사용됩니까?
많은 성능이 중요한 응용 프로그램이 포인터 사용에 의해 지배되는 C 또는 C ++로 작성되므로 예, 매우 일반적으로 때문에, (그들은 스마트 포인터 나 같은 컨테이너 뒤에 수 있습니다 std::vector또는 std::string, 그러나 기본 메커니즘은 사용되는 포인터로 요약 동적 메모리 블록에 대한 주소를 추적합니다.
이제이 질문으로 돌아갑니다.
이것은 어떻게 보상됩니까? (두 번째 부분)
포인터는 일반적으로 백만 개 (64 비트 컴퓨터에서 측정 할 수있는 8 메가 바이트)처럼 저장하지 않는 한 더럽습니다.
Ben은 "거의"8 메가는 여전히 L3 캐시 크기라고 지적했다. 여기서 나는 총 DRAM 사용과 메모리 청크에 대한 일반적인 상대 크기의 관점에서 "정확하게"더 많은 포인터를 사용했다.
포인터가 비싼 곳은 포인터 자체가 아니라 다음과 같습니다.
동적 메모리 할당. 동적 메모리 할당은 기본 데이터 구조 (예 : 친구 또는 슬랩 할당 자)를 거쳐야하므로 비용이 많이 듭니다. 이것들은 종종 죽음에 최적화되어 있지만, 범용적이고 가변적 크기의 블록을 처리하도록 설계되었습니다.이 블록은 "검색"(가벼우면서도 일정한 시간 임에도 불구하고)과 비슷한 작업을 수행해야합니다. 메모리에서 연속 된 페이지의 무료 세트를 찾습니다.
메모리 액세스. 이것은 걱정하기에 더 큰 오버 헤드 인 경향이 있습니다. 처음으로 동적으로 할당 된 메모리에 액세스 할 때마다 강제 페이지 오류가 발생하고 캐시 누락으로 인해 메모리가 메모리 계층 아래로 이동하고 레지스터로 이동합니다.
메모리 액세스
메모리 액세스는 알고리즘 이외의 성능에서 가장 중요한 측면 중 하나입니다. AAA 게임 엔진과 같은 많은 성능 결정적인 분야는보다 효율적인 메모리 액세스 패턴 및 레이아웃으로 귀결되는 데이터 지향 최적화에 많은 에너지를 집중시킵니다.
가비지 수집기를 통해 각 사용자 정의 유형을 별도로 할당하려는 고급 언어의 가장 큰 성능 문제 중 하나는 메모리를 상당히 조각화 할 수 있다는 것입니다. 모든 객체가 한 번에 할당되지 않는 경우 특히 그렇습니다.
이 경우 사용자 정의 객체 유형의 백만 인스턴스 목록을 저장하는 경우 루프에서 순차적으로 해당 인스턴스에 액세스하면 메모리 영역이 서로 다른 백만 포인터 목록과 유사하므로 상당히 느려질 수 있습니다. 이 경우 아키텍처는 제거하기 전에 해당 청크의 주변 데이터에 액세스 할 수 있도록 정렬 된 큰 청크에서 더 높고 느리고 더 큰 레벨의 계층 구조에서 메모리를 페치하려고합니다. 이러한 목록의 각 객체가 개별적으로 할당되면 종종 각 후속 반복이 제거 전에 인접한 객체가 액세스되지 않고 메모리의 완전히 다른 영역에서로드되어야 할 때 캐시 누락으로 인해 비용을 지불하게됩니다.
이러한 언어에 대한 많은 컴파일러가 요즘 명령어 선택 및 레지스터 할당에서 실제로 훌륭한 일을하고 있지만 여기에서 메모리 관리에 대한 직접적인 제어가 부족하면 킬러가 될 수 있지만 (오류가 발생하기 쉽지는 않지만) 여전히 언어를 만들 수 있습니다 C와 C ++은 꽤 인기가 있습니다.
간접적으로 포인터 액세스 최적화
성능이 가장 중요한 시나리오에서 응용 프로그램은 종종 참조 청산 성을 향상시키기 위해 인접한 청크에서 메모리를 풀링하는 메모리 풀을 사용합니다. 그러한 경우, 노드의 메모리 레이아웃이 본질적으로 연속적이라면 트리 또는 링크 된리스트와 같은 링크 된 구조조차 캐시 친화적으로 만들 수 있습니다. 이는 간접적으로 참조를 역 참조 할 때 관련된 참조의 지역성을 개선함으로써 포인터 역 참조를보다 저렴하게 효과적으로 만들고 있습니다.
쫓는 포인터
다음과 같이 단일 연결 목록이 있다고 가정하십시오.
Foo->Bar->Baz->null
문제는 이러한 모든 노드를 범용 할당 자에 대해 별도로 할당하면 (한 번에 모두는 아님) 실제 메모리가 다음과 같이 다소 분산 될 수 있다는 것입니다 (단순 다이어그램).
포인터를 쫓기 시작하고 Foo노드에 액세스하면 다음 과 같이 메모리 영역에서 더 느린 메모리 영역에서 더 빠른 메모리 영역으로 청크를 이동하는 강제 누락 (및 페이지 오류)으로 시작합니다.
이로 인해 메모리 영역을 캐시하여 페이지의 일부에만 액세스하고이 목록 주위에서 포인터를 추적 할 때 나머지를 제거합니다. 그러나 메모리 할당자를 제어함으로써 다음과 같은 목록을 연속적으로 할당 할 수 있습니다.
... 따라서 이러한 포인터를 역 참조하고 포인트를 처리 할 수있는 속도를 크게 향상시킵니다. 따라서 매우 간접적이지만이 방법으로 포인터 액세스 속도를 높일 수 있습니다. 물론 배열에 연속으로 저장하면 처음에는이 문제가 발생하지 않지만 여기에서 메모리 레이아웃을 명시 적으로 제어 할 수있는 메모리 할당자는 연결된 구조가 필요한 날을 절약 할 수 있습니다.
* 참고 : 이것은 메모리 계층 구조와 참조 위치에 대한 매우 단순화 된 다이어그램이며 토론이지만 질문의 수준에 적합하기를 바랍니다.