이 가능한 L1 캐시 쓰기 최적화를 수행하는 CPU가 있습니까?


9

L1 캐시가있는 CPU가 쓰기를 수행하는 경우 일반적으로 데이터를 업데이트하는 것 외에 캐시가 데이터를 업데이트하는 경우 캐시가 해당 캐시 라인을 더티로 표시합니다. , 나중에 업데이트 된 데이터로 라인을 작성합니다.

한 가지 가능한 최적화 방법은 캐시가 쓰기의 내용과 캐시의 이전 내용을 비교하도록하는 것이며, 동일하면 해당 라인을 더티로 표시하지 마십시오. 캐시가 때때로 쓰기를 피할 수 있기 때문에 CPU 제조업체가이 논리를 수행하는 데 필요한 게이트 가치로 이것을 어떻게 볼 수 있는지 알 수 있습니다.

내 질문 :이 최적화를 수행하는 CPU가 있습니까?

내가 묻는 이유에 대한 배경 : 지속적인 메모리 액세스가 필요한 코드를 작성 중입니다. 즉, 캐시의 동작을들을 수있는 사람은 내가하고있는 일을 추론 할 수 없어야합니다. 내 액세스 중 일부는 쓰기 이며이 코드를 구현하는 명확한 방법으로 많은 쓰기가 이미 존재하는 동일한 데이터를 작성합니다. 데이터에 따라 쓰고있는 데이터가 같거나 같지 않을 수 있으므로 쓰기를 수행해야하며, 관계없이 동일한 작업을 수행하는 것이 중요합니다. CPU가 실제로 'no-change-write'를 쓰지 않고 최적화하면 캐시 동작이 내가하는 일에 따라 다를 수 있으며 이는 목표를 파괴합니다.

그렇다면이 방법으로 쓰기를 최적화하려고하는 CPU가 있습니까?


11
컴퓨터 과학에는 캐시 무효화, 이름을 잘 지정하는 것, 일대일 오류라는 두 가지 어려운 문제가 있다고합니다. 이것이 왜 첫 번째 까다로운 지에 대한 예입니다.
— 메이슨 휠러

@poncho는 "캐시의 동작을들을 수있는 사람은 내가하고있는 일을 추론 할 수 없어야한다"고 말합니다. 이제 일부 CPU가 데이터가 실제로 업데이트되지 않는 한 캐시를 무효화하지 않는이 "스마트 쓰기 저장"기능을 구현 한 경우 메모리 계층에서 CPU에서 한 단계 더 이동하면 트래픽 / 타이밍을 관찰 할 수 있습니다. 실제 쓰기와 더미 쓰기의 차이점. 이것이 당신이 걱정하는 것입니까?
— TheCodeArtist

@poncho 또한 실제 질문은 사용 정보를 유출시키지 않는 더 나은 권한 / 보안 모드를 구현하는 것입니다. 어쩌면 당신은 그걸 물어봐야합니까?
— TheCodeArtist

1
@TheCodeArtist : 공격 프로그램이 공유 캐시를 모니터링하도록하여 동일한 CPU의 다른 코어에서 실행되는 다른 프로그램에 의해 암호화 루틴을 공격 할 수있는 암호화 측 채널 공격이 게시되었습니다. 그러한 프로그램이 L1 캐시 라인이 플러시되었는지 여부를 잠재적으로 감지 할 수 있으므로 CPU가 논의중인 최적화를 수행하는 경우 관심있는 프로그램에 대한 정보를 추론 할 수 있다고 생각합니다. CPU 또는 OS를 수정하는 기능을 가정하지 않기 때문에 '보안 모드'에 대해 이야기하고 있지 않습니다.
— 판초

4
이것이 오늘날에도 사실이더라도 내일은 사실이라고 보장 할 수 없습니다.
— pjc50

답변:


4

몇 시간 동안 검색 한 결과이 특정 최적화를 사용하는 CPU를 찾을 수 없었습니다. 언급 된 대부분의 최적화는 일반적으로 읽기 / 쓰기 작업 및 데이터 액세스를 통한 적중 / 미스와 관련이 있습니다.

(페이지 7 및) https://cseweb.ucsd.edu/classes/fa14/cse240A-a/pdf/08/CSE240A-MBT-L15-Cache.ppt.pdf

그러나 이것이이 최적화를 수행 할 수 없다는 것을 의미하지는 않습니다. 일반적으로 CPU 캐시 라인의 크기에 프로그래밍 방식으로 액세스 할 수 있습니다. 캐시 레지스터의 현재 값에 액세스하는 것도 가능하지만 그렇게하는 것은 다소 위험합니다. 나쁜 시간에 잘못된 레지스터에 액세스하면 실행중인 프로그램과 관련된 레지스터를 조작 할 수 있습니다. 또는 읽으려는 행의 내용을 실수로 수정할 수 있습니다.

레지스터 캐시에서 현재 값 얻기

또한 모든 이론적 솔루션에는 일정 형태의 소프트웨어 구현 (어셈블러)이 필요합니다. 내가 찾은 가장 가까운 것은 캐시 조작이 가능한 ARM 아키텍처와 관련이 있습니다. 이 외에도 원하는 CPU의 캐시 라인 크기를 알아야합니다. 캐시 내용을 메모리의 보조 위치에서 줄 크기 단위로주의해서 읽고 레지스터에 쓰려고하는 데이터 (또는이 경우 L1 캐시 줄)와 비교할 수 있습니다.

CPU 캐시 내용 읽기

여기에서 동일한 재 작성을 방지하는 소프트웨어 기반 시스템을 고안 할 수 있습니다. 이것은 약간 단순화되었지만 솔루션은 존재하는 모든 CPU에 적용 가능해야하기 때문입니다.

캐시 일관성과 관련된 다른 가능성은 다음과 같습니다.

acche 일관성에 대한 Wikipedia 기사의 관련 구절

이 문제와 관련하여 내 관심을 끈 주요 요점은 스나 핑 설명이었습니다.

이는 캐시 컨트롤러가 두 번째 마스터가 주 메모리의 위치를 ​​수정할 때 자체 메모리 위치 사본을 업데이트하기 위해 주소와 데이터를 모두 감시하는 메커니즘입니다. 캐시가 사본을 가지고있는 위치에서 쓰기 조작이 관찰되면, 캐시 제어기는 자신의 스 나프 메모리 위치의 사본을 새로운 데이터로 갱신합니다.

다시 말해서, 이미 메커니즘이있을 수 있습니다. 제안한 최적화에 사용되지 않을 수도 있습니다. 읽기 / 쓰기 비교를 수행 한 소프트웨어를 구현해야합니다.


캐시 레지스터의 현재 값에 액세스하는 것도 가능하지만 그렇게하는 것은 다소 위험합니다. 허, 말이되지 않습니다. CPU 레지스터를 의미합니까? 컴파일러에서 생성하거나 직접 작성한 asm 코드는 레지스터를 사용하여 작동중인 값을 보유합니다.
— Peter Cordes

소프트웨어에서 이것을 구현하려는 경우 컴파일러가 if (mem != x) { mem = x; }대신 코드를 생성하도록하십시오 mem = x;. 쓰기는 다른 스레드 읽기를 방해하므로 다중 스레드 프로그램에서 공유 캐시 라인에 대한 최적화 일뿐입니다.
— Peter Cordes

1
"snarfing"은 이것과 아무 관련이 없습니다. 그냥 수동 스누핑입니다. CPU 캐시는 MESI를 사용 하므로 코 히어 런트 라이트 백 캐시를 가질 수 있습니다.
— Peter Cordes

@PeterCordes 내 답변이 불쾌감을 느끼면 사과드립니다. 그러나 그 문제에 대해 나보다 더 통찰력이있는 것 같습니다. 그렇다면 왜 스스로 질문에 대답하지 않습니까? 내 답변은 분명히 귀하의 표준에


3

L1 캐시에 쓰는 것은 매우 시간이 매우 중요한 작업입니다.

똑같은 데이터를 다시 쓰는 것은 다소 드문 것 같습니다. 이 특별한 경우에 속도를 높이는 최적화는 전체적으로 많은 속도를 얻지 못할 것입니다.

반면,이 최적화에는 캐시 메모리에 대한 모든 단일 쓰기에서 이전 데이터와 새 데이터를 비교해야합니다. 이를 악화시키는 것은 기록 할 때 실제로 데이터를 사용할 수 있어야한다는 것입니다!

일반적으로 최신 CPU에서는 그렇지 않습니다. 기록 될 데이터는 예를 들어 여전히 계산되고있을 수있다. 캐시는 계속 진행할 수 있으며, 필요한 경우 캐시 라인을로드하고, 계산이 완료되기 전에도 캐시 라인을 수정 된 것으로 표시합니다. 캐시 라인의 실제 수정을 제외하고 모든 장부 보관을 이미 수행 할 수 있습니다. 새로 작성된 결과와 이전 캐시 라인 데이터를 비교하려면 불가능합니다.

예를 들어, C 코드가 있으면 [i] = x / y; x / y 나누기는 대부분의 CPU에서 수행하는 데 시간이 오래 걸립니다. 그러나 결과를 [i]에 저장하는 데 필요한 대부분의 작업은 분할이 끝나기 오래 전에 발생했습니다. 유일하게 누락 된 것은 8 개의 결과 바이트를 캐시 라인으로 이동하는 것입니다. 캐시 라인을 비우는 작업은 분할이 완료 될 때까지 자동으로 대기합니다. [i]를 읽는 연산은 분배기에서 바로 결과를 얻도록 경로 재 지정 될 것입니다.


일관성을 위해 MESI를 사용하는 캐시는 여전히 RFO를 수행 할 수 있지만 일단 준비된 데이터가 동일하게 비교 된 경우 해당 행을 수정 된 대신 독점 상태로 두십시오. 하드웨어에서 수행되지 않는 실제 이유는 데이터가 캐시에 커밋 할 때 추가 캐시 읽기 비용이 발생하기 때문에 (더러운 비트의 선택적 설정으로) 일종의 원자 적 읽기 / 비교 / 쓰기주기가 필요하기 때문입니다. 파이프 라인 구현.
— Peter Cordes

1

가능한 한 가지 최적화 방법은 캐시가 쓰기의 내용과 캐시의 이전 내용을 비교하도록하는 것입니다. 동일한 경우 줄을 더티로 표시하지 마십시오.

CPU가 캐시에 무언가를 쓰는 데 필요한 시간을 두 배로 늘리지 않습니까? 때문에 각 캐시 라인 쓰기는 이제 무료가 아닌 비교 작업, 동반됩니다.

따라서 실제로 최적화는 이제 매우 모호한 요소, 즉 평균 소프트웨어가 동일한 데이터로 캐시 가능한 메모리를 몇 번 다시 작성하는지에 따라 달라집니다.


이 비교는 CPU 논리 내에서 구현됩니다. 추가 CPU 작업이 필요하지 않지만 신호 시간이 증가하여 문제가 될 수 있습니다.
— ziggystar

@ziggystar 글쎄, 나는 하드웨어 마스터가 아니지만 모든 것이 비용이 따른다는 생각에 익숙해졌다. 캐시 라인과 작업을 비교합니다. 빠를 수도 있습니다. 그러나 이것은 여전히 ​​비용입니다. 그리고 나는 구현 자들이 지불하지 않기로 결정했다고 생각합니다. 생각하고 측정 한 후에도 가능합니다.
— Vladislav Rastrusny

1
그러나 비용은 게이트 수의 증가에 불과한 시간에 대해 이야기하고 있습니다.
— ziggystar

1
@ ziggystar : 이것은 더 많은 문이 아닙니다. 데이터가 캐시로 전송되면 일반적으로 데이터 전송 프로세스는 캐시 라인을 수정 된 것으로 표시 할 수 있습니다. 이 "최적화"를 사용하면 이전 데이터와 새 데이터가 모두이 게이트를 통과해야 지연이 발생하며 캐시 만 무효화 될 수 있습니다. 이 모든 것을 하나의 프로세서 주기로 짜야합니다. 그렇지 않으면 캐시 라인에 쓰는 데 갑자기 두주기가 걸립니다. 그리고 이제는 상황을 좀 더 복잡하게 만들기 위해 8 개의 연속 단어를 캐시 라인에 쓸 때 어떤 일이 발생하는지 고려하십시오.
— gnasher729

1
그리고 이러한 각 쓰기는 캐시 라인의 수정 여부에 대한 결정을 지연시킵니다. 따라서 두 번째 쓰기가 발생하면 캐시 라인은 수정 여부 (아직)를 알지 못합니다. 재미있을 것입니다.
— gnasher729
당사 사이트를 사용함과 동시에 당사의 쿠키 정책과 개인정보 보호정책을 읽고 이해하였음을 인정하는 것으로 간주합니다.
Licensed under cc by-sa 3.0 with attribution required.