메모리 뱅크 벡터 프로세서에서의 메모리 액세스 충돌 조건

Question

컴퓨터 아키텍처 (정량적 접근법 5ed)에 대한 Hennessy-Patterson의 저서에 따르면 다중 메모리 뱅크가있는 벡터 아키텍처에서는 다음 조건이 충족 될 경우 뱅크 충돌이 발생할 수 있습니다 5ed에서 페이지 279) :

은행 (수) 메모리 충돌이 경우에 발생할 것이기 때문에 은행의/최소 공배수 (수, 보폭)

그러나, 내가 대신 LCM의 GreatestCommonFactor해야한다고 생각 < 은행 바쁜 시간, 유효한 은행 번호은 바쁜 시간보다 적습니다. 실효적인 뱅크 수를 말하자면 8 개의 뱅크와 2 개의 보폭이 있다고 가정 해 봅시다. 효과적으로 4 개의 뱅크가 있습니다. 왜냐하면 메모리 액세스가 4 개의 뱅크에서만 정렬되기 때문입니다 (예를 들어 액세스가 모두 짝수, 0부터 시작하여, 은행의 출입은 0,2,4,6)으로 늘어납니다.

실제로이 수식은 그 바로 아래에 주어진 예에서도 실패합니다. 총 메모리 대기 시간이 12 클럭 사이클 인 6 개의 클럭 사이클의 사용 시간을 가진 8 개의 메모리 뱅크가 있다고 가정하면 1의 스트라이드로 64 요소 벡터로드를 완료하는 데 얼마나 걸리나요? - 여기서는 12 + 64 = 76 클럭 주기로 시간을 계산합니다. 그러나 메모리 뱅크 충돌은 주어진 조건에 따라 발생하므로 분명히 한 사이클 당 하나의 액세스를 가질 수 없습니다 (방정식에서 64 개).

잘못되었거나 틀린 공식이이 책의 다섯 가지 버전에서 생존 할 수 있습니까? (있을 법하지 않음)?

Answer 1

GCD (은행, 보폭)가 입력되어야합니다. 그것에 대한 귀하의 주장은 정확합니다.

몇 가지 다른 진보를 위해 이것을 시도해보고 은행 수에 대해 = b = 8을 얻으십시오.

# generated with the calc(1) function 
define f(s) { print s, "  | ", lcm(s,8), " | ", gcd(s,8), " | ", 8/lcm(s,8), "  | ", 8/gcd(s,8) }` 

stride | LCM(s,b) | GCF(s,b) | b/LCM(s,b) | b/GCF(s,b) 
1  | 8  | 1  | 1  | 8  # 8 < 6 = false: no conflict 
2  | 8  | 2  | 1  | 4  # 4 < 6 = true: conflict 
3  | 24 | 1  | ~0.333 | 8  # 8 < 6 = false: no conflict 
4  | 8  | 4  | 1  | 2  # 2 < 6 = true: conflict 
5  | 40 | 1  | 0.2  | 8 
6  | 24 | 2  | ~0.333 | 4 
7  | 56 | 1  | ~0.143 | 8 
8  | 8  | 8  | 1  | 1 
9  | 72 | 1  | ~0.111 | 8 

x   >=8  2^0..3  <=1   1 2 4 or 8 

B/LCM은 (들, b) 항상 < = 1이므로, 항상 충돌을 예측한다.

저는 GCF (일명 GCD)가 지금까지 보았던 스트라이드 값을 올바르게 생각한다고 생각합니다. 스트라이드가 모든 은행을 통해 액세스를 분배하지 않으면 b/GCF (s, b)가 알려주는 것만 문제가됩니다.

---

스트라이드 = 8은 항상 동일한 뱅크를 사용하여 최악의 경우 여야합니다. 따라서 두 표현식 모두 8/8 = 1로 뱅크 사용량/복구 시간보다 짧아서 충돌을 정확하게 예측합니다.

물론 stride = 1이 가장 좋은 경우입니다 (통화 중 시간을 숨길 은행이 충분한 경우 충돌이 발생하지 않음). gcd (8,1) = 1은 충돌을 정확하게 예측하지 않습니다 (8/1 = 8, 6 이상). lcm (8,1) = 8. (8/8 < 6이 참) 충돌을 잘못 예측합니다.