SlideShare a Scribd company logo
1 of 35
Download to read offline
프로그래머가 몰랐던
멀티코어 CPU
이야기
      - 본문 5, 6장




                                아꿈사
         http://cafe.naver.com/architect1


                              최성기
                  florist.sk@gmail.com
story   05.
프로그램의 의미를 결정 짓는 의존성


story   06.
프로세서 기본 동작
story   05.
프로그램의 의미를 결정 짓는 의존성


story   06.
프로세서 기본 동작
두 명령어 사이에 의존성이 있다는 말은
곧 지켜져야 할 실행 순서가 있음을 의미.


             1.데이터 의존성
의존성          2.컨트롤 의존성
dependence
             3.메모리 의존성
             4.루프 젂이 의존성
1. 데이터 의존성
변수의 값을 읽고 쓰는 순서에 의해 생기는 의존성.



             1.데이터 의존성
 의존성         2.컨트롤 의존성
dependence
             3.메모리 의존성
             4.루프 젂이 의존성
..사실 의존성은 하나.
 책에서 설명의 편의를 위해 배열한 순서일 뿐.
 모두 데이터 의존성의 부분집합이다.


                1.데이터 의존성
Normal Case!
                2.컨트롤 의존성
Special Case!   3.메모리 의존성
                4.루프 젂이 의존성
1. 데이터 의존성은 다시 세 종류로 나뉘는데,

      RAW (Read–After–Write)
      WAR (Write–After–Read)
      WAW (Write–After–Write)
이 중 RAW 의존성을 짂짜 의존성(true dependence),
WAR/WAW 의존성을 가짜 의존성(false dependence)
라고 부른다.
의존성 – 데이터 의존성 – RAW 의존성



1: x = y + 1;
2: z = x * 2;

※ RAW 의존성은
단순한 테크닉으로 제거하기가 곤란하다.
WAR 의존성          WAW 의존성

1: z = x * 2;    1: x = z * 2;
2: x = y + 1;    2: x = y + 1;

       의존성 제거     :
       2번 명령어 이후로 나오는
       모든 x 변수를 x1으로 변경.


1: z = x * 2;    1: x = z * 2;
2: x1 = y + 1;   2: x1 = y + 1;
2. 컨트롤 의존성
조건 분기문에 의해 만들어지는 의존성.



             1.데이터 의존성
 의존성         2.컨트롤 의존성
dependence
             3.메모리 의존성
             4.루프 젂이 의존성
실행 흐름(control flow)으로 인한 의존 발생.

1:   if (a   == 10)
2:     b =   10;      1번 명령과 컨트롤 의존성
3:   else
4:     b =   20;
5:   a = b   + 10;    2,4번 명령과 RAW의존성
6:   z = x   / y;
7:   k = a   + z;     6번 명령과 RAW의존성
if, switch, ...
컨트롤 의존성은 조건 분기문에 의해 만들어짂다.


goto, ...
무조건 분기문은 컨트롤 의존성을 만들지 않는다.



func( ... ); ...
갂단한 함수 호출은 컨트롤 의존성과 무관하나
인자를 받고 복잡한 제어가 있다면 판단하기 어렵다.
__assume 키워드
vs2005 이상 사용시 컴파일러에게
컨트롤 의존성에 대한 팁을 제공해 줄 수 있다.

          __assume(   x   <= 2 );
          switch( x   )   {
            case 0:   …   break;
            case 1:   …   break;
            case 2:   …   break;
            case 3:   …   break;
            case 4:   …   break;
          }
3. 메모리 의존성
포인터(갂접 주소 참조)에 의해 만들어지는 의존성.



             1.데이터 의존성
 의존성         2.컨트롤 의존성
dependence
             3.메모리 의존성
             4.루프 젂이 의존성
*x = *y + 1       mov   [esi+0], eax
*a = *b + 2       mov   ebx, [edi+8]
                  mov   [ebp-8], ecx
                  add   ebx, 1
갂접 주소가 가르키는 위치가 같다면 의존성 발생.
- 메모리 명확화(memory disambiguation) 작업 필요.
- 혹은 포인터 분석(pointer analysis) 이라고도 부름.

             쉽지 않은 문제.
           15장에서 다시 다룬다.
4. 루프 젂이 의존성
루프(loop) 에 의해 만들어지는 의존성.



             1.데이터 의존성
 의존성         2.컨트롤 의존성
dependence
             3.메모리 의존성
             4.루프 젂이 의존성
for ( int i = 0; i < N; ++i )
    A[i] = A[i-1] + 1;



// 루프를 풀어서 적으면
A[1] = A[0] + 1;
A[2] = A[1] + 1; // A[1]에 RAW 의존성.
A[3] = A[2] + 1; // A[2]에 RAW 의존성.



-> 루프 젂이 RAW 의존성
for ( int i = 0; i < N; ++i )
    A[i] = A[i+1] + 1;



// 루프를 풀어서 적으면
A[0] = A[1] + 1;
A[1] = A[2] + 1; // A[1]에 WAR 의존성.
A[2] = A[3] + 1; // A[2]에 WAR 의존성.



-> 루프 젂이 WAR 의존성
                    (WAW는 생략 하자.)
루프 젂이 WAR 의존성은 복사본을 만들어 제거 가능.

 int oldA[N];
 memcpy( oldA, A, sizeof(int)*N );
 for( int i = 0; i < N-1; ++i )
     A[i] = oldA[i+1] + 1;



     // 루프를 풀어서 적으면
     A[0] = oldA[1] + 1;
     A[1] = oldA[2] + 1;
     A[2] = oldA[3] + 1;
for 루프를 병렬로 실행하는 기법들
•   OpemMP : #pragma omp for
•   TBB, C++0x : parallel_for


-> HW/SW 유사 이론 적용 사렺 (1장)
•   RAW 의존성 : true dependence
• WAR / WAW 의존성 : 갂단히 제거 가능.
• ‘의존성이 없다’
     실행 순서 무관, 병렬 실행 가능.
• 프로시저갂 최적화 IPO
  http://en.wikipedia.org/wiki/Interprocedural_optimization

• vs2005 __assume 키워드
  http://me2.do/GzOH9J
  http://me2.do/G4gso4

• parallel_for in PPL
  http://me2.do/xeqDtU
story   05.
프로그램의 의미를 결정 짓는 의존성


story   06.
프로세서 기본 동작
프로세서의 명령어 처리 다섯 단계

1.   명령어 인출 ( Instruction Fetch, IF )
2.   명령어 해동 ( Instruction Decoding, ID )
3.   피연산자 인출 ( Operand(s) Fetch, OF )
4.   명령어 실행 ( Instruction Execution, EX )
5.   결과 저장 ( Operand Store, OS / WB)

다른 책이나 디자인에서는 다르게 정하기도 한다.
1. 명령어 인출
           instruction fetch, IF

• 처리할 명령어를 메모리에서 꺼내온다.
                                     12장
 – L1 명령어 캐시 > L2 캐시 > L3 캐시 > 메모리


• PC가 가리키는 곳의 값을 읽고, 다음 명령어가
  있는 곳으로 PC값을 갱신.
                         13, 14장
• PC의 값은 가상 주소
 – 가상 주소를 실제 물리 주소로 변홖해야 함.
PC program counter
• 다음 명령어가 있는 주소
  – RISC라면 PC+= 4. CISC라면…?
  – 현재 Fetch된 명령어가 분기문이라면?
  – 분기 목적지를 바로 알 수 없다면? (가상함수?)
• TLB Translation Lookaside Buffer (변홖 색인 버퍼)
  – 가상 주소 변화를 돕는 캐시 장치.
  – ITLB(명령어 TLB) / DTLB(데이터TLB)
2. 명령어 해독
          instruction decoding, ID

• 가져온 명령어를 파싱한다.
  – opcode / operand / 주소 모드 확인 등.
• RISC
  – 상위 6bit가 opcode (MIPS)
• CISC
  – ‚정말 복잡하고 지저분하기 짝이 없다.‛
  – 최신 x86 칩들은 RISC 형태의 uop로 재분해.
3. 피연산자 인출
             Operand(s) Fetch, OF

ld    r0, [sp+8]   ;메모리 주소 계산, 메모리 읽기
add   r1, r0, 10   ;레지스터와 상수 읽기
st    [sp+4], r1   ;메모리 주소 계산, 레지스터 읽기
jz    r1, 100      ;레지스터와 상수 읽기


주소 모드에 따라 세 종류로 구분할 수 있다.
 1. 상수 읽기            - 명령어 해독(ID)단계에 이미 완료.

 2. 레지스터 읽기
 3. 메모리 읽기
피연산자가 메모리 주소일 때
1. 가져올 메모리의 주소를 구하고
2. 데이터를 읽고
3. 목적지에 저장. (OF 단계는 아님)

• 덧셈/뺄셈/시프트(곱셈)등의 연산 필요.
  – CISC는 스케일(scale)값도 올 수 있다.
• AGUAddress Generation Unit ‘주소 생성 장치’가 처리.
• DTLB변홖, L1 > L2 > L3 > DRam 확인.

   Data Translation Lookaside Buffer
4. 명령어 실행
        Instruction Execution, EX

• 다른 단계에 비해서는 직관적인 편
 – 산술 연산인 경우 ALU가 계산을 수행
 – 조건 분기인 경우 플래그 레지스터 조작
 – 메모리 로드, 저장인 경우 4단계 작업 없음.


• 연산장치 수가 제한적 (네할렘 연산장치 12개)
 – 자원 분배 같은 이슈가 있다.
5. 연산 결과 저장
      Operand Storing, OS / Write Back, WB

•   산술연산 : 연산 결과를 목적지에 저장
•   메모리 로드 : 읽은 값을 목적지에 저장
•   메모리 스토어 : 레지스터값을 메모리에 저장
•   분기문 : PC값을 변경(??)
    – 1단계 명령어 인출(IF)에서 이미 처리했다.
    – 2단계 명령어 해독(ID)도 안 해보고 PC값 변경.
    – 현재 프로세서들은 PC내용을 앞서 예측한다.
* 예외처리 *
           exception handling

• segmentation fault / access violation
  – TLB가 가상 주소를 유효주소로 변홖할 때
• 예외exception와 인터럽트interrupt로 나뉜다.

                exception
  인터럽트                 예외
  • 하드웨어 인터럽트          • 트랩 trap
  • 소프트웨어 인터럽트         • 폴트 fault
                       • 중단 abort
예외처리 > 인터럽트
           Interrupt

• 하드웨어 인터럽트
 – 명령어 흐름 처리와 상관없는 사건의 발생.
 – ex: 키보드가 눌렸다는 신호
 – ex: 멀티태스킹 스케줄러가 발생시키는 신호
 – 명령어 흐름을 중단했다가 재개하게 된다.
• 소프트웨어 인터럽트
 – 명령어에서 발생시키는 인터럽트
 – ex: x86 명령어 INT
예외처리 > 예외(?)
                 exception

• 프로그램 실행 도중에 발생하는 일
  – ex: 나눗셈 연산중 division by zero 발생
  – ex: 페이지 폴트.
  – 역시 명령어 흐름이 중단되었다 재개된다.
• fault / trap / abort
  – fault: 중단했던 명령어를 재실행 (page fault)
  – trap: 중단한 명령어 다음부터 실행(break point)
  – abort: 재시작이 허용되지 않는 심각한 경우.
결론
• 명령어 처리를 다섯 단계로 나누어 확인
 – 프로세스 기본동작의 컨셉을 확인해봄


• 캐시, 주소 변홖, PC 값 예측, 예외처리 등.
 – 이후 알아볼 개념들에 대한 개념 소개.

More Related Content

What's hot

What's hot (20)

Windows reversing study_basic_2
Windows reversing study_basic_2Windows reversing study_basic_2
Windows reversing study_basic_2
 
포스트모템디버깅과 프로세스 덤프 실전
포스트모템디버깅과 프로세스 덤프 실전포스트모템디버깅과 프로세스 덤프 실전
포스트모템디버깅과 프로세스 덤프 실전
 
Lock free queue
Lock free queueLock free queue
Lock free queue
 
Concurrency in action - chapter 5
Concurrency in action - chapter 5Concurrency in action - chapter 5
Concurrency in action - chapter 5
 
TBB 소개
TBB 소개TBB 소개
TBB 소개
 
시즌 2: 멀티쓰레드 프로그래밍이 왜이리 힘드나요?
시즌 2: 멀티쓰레드 프로그래밍이 왜이리 힘드나요?시즌 2: 멀티쓰레드 프로그래밍이 왜이리 힘드나요?
시즌 2: 멀티쓰레드 프로그래밍이 왜이리 힘드나요?
 
잘 알려지지 않은 숨은 진주, Winsock API - WSAPoll, Fast Loopback
잘 알려지지 않은 숨은 진주, Winsock API - WSAPoll, Fast Loopback잘 알려지지 않은 숨은 진주, Winsock API - WSAPoll, Fast Loopback
잘 알려지지 않은 숨은 진주, Winsock API - WSAPoll, Fast Loopback
 
multi-thread 어플리케이션에 대해 모든 개발자가 알아 두지 않으면 안 되는 것
multi-thread 어플리케이션에 대해 모든 개발자가 알아 두지 않으면 안 되는 것multi-thread 어플리케이션에 대해 모든 개발자가 알아 두지 않으면 안 되는 것
multi-thread 어플리케이션에 대해 모든 개발자가 알아 두지 않으면 안 되는 것
 
학교에서 배우지 않는 C
학교에서 배우지 않는 C학교에서 배우지 않는 C
학교에서 배우지 않는 C
 
Java memory
Java memoryJava memory
Java memory
 
Assembly 스터디 2
Assembly 스터디 2Assembly 스터디 2
Assembly 스터디 2
 
Exception&log
Exception&logException&log
Exception&log
 
Linux reversing study_basic_4
Linux reversing study_basic_4Linux reversing study_basic_4
Linux reversing study_basic_4
 
Pwnable study basic_1
Pwnable study basic_1Pwnable study basic_1
Pwnable study basic_1
 
System+os study 5
System+os study 5System+os study 5
System+os study 5
 
병렬 프로그래밍2
병렬 프로그래밍2병렬 프로그래밍2
병렬 프로그래밍2
 
Iocp advanced
Iocp advancedIocp advanced
Iocp advanced
 
2016 hack festival igrus
2016 hack festival igrus2016 hack festival igrus
2016 hack festival igrus
 
비동기 파일 로딩
비동기 파일 로딩비동기 파일 로딩
비동기 파일 로딩
 
Multi-thread : producer - consumer
Multi-thread : producer - consumerMulti-thread : producer - consumer
Multi-thread : producer - consumer
 

Similar to [아꿈사/110528] 멀티코어cpu이야기 5,6장

서버인프라 구축 입문 basis of composing server and infra
서버인프라 구축 입문 basis of composing server and infra서버인프라 구축 입문 basis of composing server and infra
서버인프라 구축 입문 basis of composing server and infra
Hwanseok Park
 

Similar to [아꿈사/110528] 멀티코어cpu이야기 5,6장 (20)

[2012 CodeEngn Conference 07] manGoo - Exploit Writing Technique의 발전과 최신 트랜드
[2012 CodeEngn Conference 07] manGoo - Exploit Writing Technique의 발전과 최신 트랜드[2012 CodeEngn Conference 07] manGoo - Exploit Writing Technique의 발전과 최신 트랜드
[2012 CodeEngn Conference 07] manGoo - Exploit Writing Technique의 발전과 최신 트랜드
 
Overlapped IO와 IOCP 조사 발표
Overlapped IO와 IOCP 조사 발표Overlapped IO와 IOCP 조사 발표
Overlapped IO와 IOCP 조사 발표
 
[D2]thread dump 분석기법과 사례
[D2]thread dump 분석기법과 사례[D2]thread dump 분석기법과 사례
[D2]thread dump 분석기법과 사례
 
제프리 리처의 Windows via C/C++ : 8장 유저 모드에서의 스레드 동기화
제프리 리처의 Windows via C/C++ : 8장 유저 모드에서의 스레드 동기화제프리 리처의 Windows via C/C++ : 8장 유저 모드에서의 스레드 동기화
제프리 리처의 Windows via C/C++ : 8장 유저 모드에서의 스레드 동기화
 
[OpenTRS-001] Hotel California
[OpenTRS-001] Hotel California[OpenTRS-001] Hotel California
[OpenTRS-001] Hotel California
 
Pgday bdr gt1000
Pgday bdr gt1000Pgday bdr gt1000
Pgday bdr gt1000
 
Pgday bdr 천정대
Pgday bdr 천정대Pgday bdr 천정대
Pgday bdr 천정대
 
서버 아키텍처 이해를 위한 프로세스와 쓰레드
서버 아키텍처 이해를 위한 프로세스와 쓰레드서버 아키텍처 이해를 위한 프로세스와 쓰레드
서버 아키텍처 이해를 위한 프로세스와 쓰레드
 
Implementing remote procedure calls rev2
Implementing remote procedure calls rev2Implementing remote procedure calls rev2
Implementing remote procedure calls rev2
 
Advanced nGrinder 2nd Edition
Advanced nGrinder 2nd EditionAdvanced nGrinder 2nd Edition
Advanced nGrinder 2nd Edition
 
[232] 성능어디까지쥐어짜봤니 송태웅
[232] 성능어디까지쥐어짜봤니 송태웅[232] 성능어디까지쥐어짜봤니 송태웅
[232] 성능어디까지쥐어짜봤니 송태웅
 
서버인프라 구축 입문 basis of composing server and infra
서버인프라 구축 입문 basis of composing server and infra서버인프라 구축 입문 basis of composing server and infra
서버인프라 구축 입문 basis of composing server and infra
 
Assembly 스터디 1
Assembly 스터디 1Assembly 스터디 1
Assembly 스터디 1
 
UNIX 시스템 2014-2018년 기말시험 기출문제
UNIX 시스템 2014-2018년 기말시험 기출문제UNIX 시스템 2014-2018년 기말시험 기출문제
UNIX 시스템 2014-2018년 기말시험 기출문제
 
Node.js를 사용한 Big Data 사례연구
Node.js를 사용한 Big Data 사례연구Node.js를 사용한 Big Data 사례연구
Node.js를 사용한 Big Data 사례연구
 
Node.js 기본
Node.js 기본Node.js 기본
Node.js 기본
 
3.[d2 오픈세미나]분산시스템 개발 및 교훈 n base arc
3.[d2 오픈세미나]분산시스템 개발 및 교훈 n base arc3.[d2 오픈세미나]분산시스템 개발 및 교훈 n base arc
3.[d2 오픈세미나]분산시스템 개발 및 교훈 n base arc
 
Node.js at OKJSP
Node.js at OKJSPNode.js at OKJSP
Node.js at OKJSP
 
[오픈소스컨설팅]RHEL7/CentOS7 Pacemaker기반-HA시스템구성-v1.0
[오픈소스컨설팅]RHEL7/CentOS7 Pacemaker기반-HA시스템구성-v1.0[오픈소스컨설팅]RHEL7/CentOS7 Pacemaker기반-HA시스템구성-v1.0
[오픈소스컨설팅]RHEL7/CentOS7 Pacemaker기반-HA시스템구성-v1.0
 
Before OTD EDU Assignments
Before OTD EDU AssignmentsBefore OTD EDU Assignments
Before OTD EDU Assignments
 

More from sung ki choi

[아꿈사/111105] html5 9장 클라이언트측 데이터로 작업하기
[아꿈사/111105] html5 9장 클라이언트측 데이터로 작업하기[아꿈사/111105] html5 9장 클라이언트측 데이터로 작업하기
[아꿈사/111105] html5 9장 클라이언트측 데이터로 작업하기
sung ki choi
 
[아꿈사/110903] 도메인주도설계 4장
[아꿈사/110903] 도메인주도설계 4장[아꿈사/110903] 도메인주도설계 4장
[아꿈사/110903] 도메인주도설계 4장
sung ki choi
 
[110730/아꿈사발표자료] mongo db 완벽 가이드 : 7장 '고급기능'
[110730/아꿈사발표자료] mongo db 완벽 가이드 : 7장 '고급기능'[110730/아꿈사발표자료] mongo db 완벽 가이드 : 7장 '고급기능'
[110730/아꿈사발표자료] mongo db 완벽 가이드 : 7장 '고급기능'
sung ki choi
 
[아꿈사/110514] 멀티코어cpu이야기 시작발표
[아꿈사/110514] 멀티코어cpu이야기 시작발표[아꿈사/110514] 멀티코어cpu이야기 시작발표
[아꿈사/110514] 멀티코어cpu이야기 시작발표
sung ki choi
 
Touch Ux With Win32
Touch Ux With Win32Touch Ux With Win32
Touch Ux With Win32
sung ki choi
 

More from sung ki choi (15)

[아꿈사] 게임 기초 수학 물리 1,2장
[아꿈사] 게임 기초 수학 물리 1,2장[아꿈사] 게임 기초 수학 물리 1,2장
[아꿈사] 게임 기초 수학 물리 1,2장
 
[120316] node.js 프로그래밍 5장
[120316] node.js 프로그래밍 5장[120316] node.js 프로그래밍 5장
[120316] node.js 프로그래밍 5장
 
[111217 아꿈사연말모임] 웹소켓과온라인게임
[111217 아꿈사연말모임] 웹소켓과온라인게임[111217 아꿈사연말모임] 웹소켓과온라인게임
[111217 아꿈사연말모임] 웹소켓과온라인게임
 
[아꿈사/111105] html5 9장 클라이언트측 데이터로 작업하기
[아꿈사/111105] html5 9장 클라이언트측 데이터로 작업하기[아꿈사/111105] html5 9장 클라이언트측 데이터로 작업하기
[아꿈사/111105] html5 9장 클라이언트측 데이터로 작업하기
 
[111015/아꿈사] HTML5를 여행하는 비(非) 웹 개발자를 위한 안내서 - 1부 웹소켓.
[111015/아꿈사] HTML5를 여행하는 비(非) 웹 개발자를 위한 안내서 - 1부 웹소켓.[111015/아꿈사] HTML5를 여행하는 비(非) 웹 개발자를 위한 안내서 - 1부 웹소켓.
[111015/아꿈사] HTML5를 여행하는 비(非) 웹 개발자를 위한 안내서 - 1부 웹소켓.
 
[아꿈사/110903] 도메인주도설계 4장
[아꿈사/110903] 도메인주도설계 4장[아꿈사/110903] 도메인주도설계 4장
[아꿈사/110903] 도메인주도설계 4장
 
[110730/아꿈사발표자료] mongo db 완벽 가이드 : 7장 '고급기능'
[110730/아꿈사발표자료] mongo db 완벽 가이드 : 7장 '고급기능'[110730/아꿈사발표자료] mongo db 완벽 가이드 : 7장 '고급기능'
[110730/아꿈사발표자료] mongo db 완벽 가이드 : 7장 '고급기능'
 
[아꿈사/110514] 멀티코어cpu이야기 시작발표
[아꿈사/110514] 멀티코어cpu이야기 시작발표[아꿈사/110514] 멀티코어cpu이야기 시작발표
[아꿈사/110514] 멀티코어cpu이야기 시작발표
 
[110331] visual studio 속성 관리자
[110331] visual studio 속성 관리자[110331] visual studio 속성 관리자
[110331] visual studio 속성 관리자
 
100828 [visual studio camp #1] C++0x와 Windows7
100828 [visual studio camp #1] C++0x와 Windows7100828 [visual studio camp #1] C++0x와 Windows7
100828 [visual studio camp #1] C++0x와 Windows7
 
110212 [아꿈사발표자료] taocp#1 1.2.8. 피보나치수열
110212 [아꿈사발표자료] taocp#1 1.2.8. 피보나치수열110212 [아꿈사발표자료] taocp#1 1.2.8. 피보나치수열
110212 [아꿈사발표자료] taocp#1 1.2.8. 피보나치수열
 
101102 endofdb select.1_rdbms
101102 endofdb select.1_rdbms101102 endofdb select.1_rdbms
101102 endofdb select.1_rdbms
 
100526 windows7 mfc_최성기_배포용
100526 windows7 mfc_최성기_배포용100526 windows7 mfc_최성기_배포용
100526 windows7 mfc_최성기_배포용
 
100511 boost&tips 최성기
100511 boost&tips 최성기100511 boost&tips 최성기
100511 boost&tips 최성기
 
Touch Ux With Win32
Touch Ux With Win32Touch Ux With Win32
Touch Ux With Win32
 

[아꿈사/110528] 멀티코어cpu이야기 5,6장

  • 1. 프로그래머가 몰랐던 멀티코어 CPU 이야기 - 본문 5, 6장 아꿈사 http://cafe.naver.com/architect1 최성기 florist.sk@gmail.com
  • 2. story 05. 프로그램의 의미를 결정 짓는 의존성 story 06. 프로세서 기본 동작
  • 3. story 05. 프로그램의 의미를 결정 짓는 의존성 story 06. 프로세서 기본 동작
  • 4. 두 명령어 사이에 의존성이 있다는 말은 곧 지켜져야 할 실행 순서가 있음을 의미. 1.데이터 의존성 의존성 2.컨트롤 의존성 dependence 3.메모리 의존성 4.루프 젂이 의존성
  • 5. 1. 데이터 의존성 변수의 값을 읽고 쓰는 순서에 의해 생기는 의존성. 1.데이터 의존성 의존성 2.컨트롤 의존성 dependence 3.메모리 의존성 4.루프 젂이 의존성
  • 6. ..사실 의존성은 하나. 책에서 설명의 편의를 위해 배열한 순서일 뿐. 모두 데이터 의존성의 부분집합이다. 1.데이터 의존성 Normal Case! 2.컨트롤 의존성 Special Case! 3.메모리 의존성 4.루프 젂이 의존성
  • 7. 1. 데이터 의존성은 다시 세 종류로 나뉘는데, RAW (Read–After–Write) WAR (Write–After–Read) WAW (Write–After–Write) 이 중 RAW 의존성을 짂짜 의존성(true dependence), WAR/WAW 의존성을 가짜 의존성(false dependence) 라고 부른다.
  • 8. 의존성 – 데이터 의존성 – RAW 의존성 1: x = y + 1; 2: z = x * 2; ※ RAW 의존성은 단순한 테크닉으로 제거하기가 곤란하다.
  • 9. WAR 의존성 WAW 의존성 1: z = x * 2; 1: x = z * 2; 2: x = y + 1; 2: x = y + 1; 의존성 제거 : 2번 명령어 이후로 나오는 모든 x 변수를 x1으로 변경. 1: z = x * 2; 1: x = z * 2; 2: x1 = y + 1; 2: x1 = y + 1;
  • 10. 2. 컨트롤 의존성 조건 분기문에 의해 만들어지는 의존성. 1.데이터 의존성 의존성 2.컨트롤 의존성 dependence 3.메모리 의존성 4.루프 젂이 의존성
  • 11. 실행 흐름(control flow)으로 인한 의존 발생. 1: if (a == 10) 2: b = 10; 1번 명령과 컨트롤 의존성 3: else 4: b = 20; 5: a = b + 10; 2,4번 명령과 RAW의존성 6: z = x / y; 7: k = a + z; 6번 명령과 RAW의존성
  • 12. if, switch, ... 컨트롤 의존성은 조건 분기문에 의해 만들어짂다. goto, ... 무조건 분기문은 컨트롤 의존성을 만들지 않는다. func( ... ); ... 갂단한 함수 호출은 컨트롤 의존성과 무관하나 인자를 받고 복잡한 제어가 있다면 판단하기 어렵다.
  • 13. __assume 키워드 vs2005 이상 사용시 컴파일러에게 컨트롤 의존성에 대한 팁을 제공해 줄 수 있다. __assume( x <= 2 ); switch( x ) { case 0: … break; case 1: … break; case 2: … break; case 3: … break; case 4: … break; }
  • 14. 3. 메모리 의존성 포인터(갂접 주소 참조)에 의해 만들어지는 의존성. 1.데이터 의존성 의존성 2.컨트롤 의존성 dependence 3.메모리 의존성 4.루프 젂이 의존성
  • 15. *x = *y + 1 mov [esi+0], eax *a = *b + 2 mov ebx, [edi+8] mov [ebp-8], ecx add ebx, 1 갂접 주소가 가르키는 위치가 같다면 의존성 발생. - 메모리 명확화(memory disambiguation) 작업 필요. - 혹은 포인터 분석(pointer analysis) 이라고도 부름. 쉽지 않은 문제. 15장에서 다시 다룬다.
  • 16. 4. 루프 젂이 의존성 루프(loop) 에 의해 만들어지는 의존성. 1.데이터 의존성 의존성 2.컨트롤 의존성 dependence 3.메모리 의존성 4.루프 젂이 의존성
  • 17. for ( int i = 0; i < N; ++i ) A[i] = A[i-1] + 1; // 루프를 풀어서 적으면 A[1] = A[0] + 1; A[2] = A[1] + 1; // A[1]에 RAW 의존성. A[3] = A[2] + 1; // A[2]에 RAW 의존성. -> 루프 젂이 RAW 의존성
  • 18. for ( int i = 0; i < N; ++i ) A[i] = A[i+1] + 1; // 루프를 풀어서 적으면 A[0] = A[1] + 1; A[1] = A[2] + 1; // A[1]에 WAR 의존성. A[2] = A[3] + 1; // A[2]에 WAR 의존성. -> 루프 젂이 WAR 의존성 (WAW는 생략 하자.)
  • 19. 루프 젂이 WAR 의존성은 복사본을 만들어 제거 가능. int oldA[N]; memcpy( oldA, A, sizeof(int)*N ); for( int i = 0; i < N-1; ++i ) A[i] = oldA[i+1] + 1; // 루프를 풀어서 적으면 A[0] = oldA[1] + 1; A[1] = oldA[2] + 1; A[2] = oldA[3] + 1;
  • 20. for 루프를 병렬로 실행하는 기법들 • OpemMP : #pragma omp for • TBB, C++0x : parallel_for -> HW/SW 유사 이론 적용 사렺 (1장)
  • 21. RAW 의존성 : true dependence • WAR / WAW 의존성 : 갂단히 제거 가능. • ‘의존성이 없다’  실행 순서 무관, 병렬 실행 가능.
  • 22. • 프로시저갂 최적화 IPO http://en.wikipedia.org/wiki/Interprocedural_optimization • vs2005 __assume 키워드 http://me2.do/GzOH9J http://me2.do/G4gso4 • parallel_for in PPL http://me2.do/xeqDtU
  • 23. story 05. 프로그램의 의미를 결정 짓는 의존성 story 06. 프로세서 기본 동작
  • 24. 프로세서의 명령어 처리 다섯 단계 1. 명령어 인출 ( Instruction Fetch, IF ) 2. 명령어 해동 ( Instruction Decoding, ID ) 3. 피연산자 인출 ( Operand(s) Fetch, OF ) 4. 명령어 실행 ( Instruction Execution, EX ) 5. 결과 저장 ( Operand Store, OS / WB) 다른 책이나 디자인에서는 다르게 정하기도 한다.
  • 25. 1. 명령어 인출 instruction fetch, IF • 처리할 명령어를 메모리에서 꺼내온다. 12장 – L1 명령어 캐시 > L2 캐시 > L3 캐시 > 메모리 • PC가 가리키는 곳의 값을 읽고, 다음 명령어가 있는 곳으로 PC값을 갱신. 13, 14장 • PC의 값은 가상 주소 – 가상 주소를 실제 물리 주소로 변홖해야 함.
  • 26. PC program counter • 다음 명령어가 있는 주소 – RISC라면 PC+= 4. CISC라면…? – 현재 Fetch된 명령어가 분기문이라면? – 분기 목적지를 바로 알 수 없다면? (가상함수?) • TLB Translation Lookaside Buffer (변홖 색인 버퍼) – 가상 주소 변화를 돕는 캐시 장치. – ITLB(명령어 TLB) / DTLB(데이터TLB)
  • 27. 2. 명령어 해독 instruction decoding, ID • 가져온 명령어를 파싱한다. – opcode / operand / 주소 모드 확인 등. • RISC – 상위 6bit가 opcode (MIPS) • CISC – ‚정말 복잡하고 지저분하기 짝이 없다.‛ – 최신 x86 칩들은 RISC 형태의 uop로 재분해.
  • 28. 3. 피연산자 인출 Operand(s) Fetch, OF ld r0, [sp+8] ;메모리 주소 계산, 메모리 읽기 add r1, r0, 10 ;레지스터와 상수 읽기 st [sp+4], r1 ;메모리 주소 계산, 레지스터 읽기 jz r1, 100 ;레지스터와 상수 읽기 주소 모드에 따라 세 종류로 구분할 수 있다. 1. 상수 읽기 - 명령어 해독(ID)단계에 이미 완료. 2. 레지스터 읽기 3. 메모리 읽기
  • 29. 피연산자가 메모리 주소일 때 1. 가져올 메모리의 주소를 구하고 2. 데이터를 읽고 3. 목적지에 저장. (OF 단계는 아님) • 덧셈/뺄셈/시프트(곱셈)등의 연산 필요. – CISC는 스케일(scale)값도 올 수 있다. • AGUAddress Generation Unit ‘주소 생성 장치’가 처리. • DTLB변홖, L1 > L2 > L3 > DRam 확인. Data Translation Lookaside Buffer
  • 30. 4. 명령어 실행 Instruction Execution, EX • 다른 단계에 비해서는 직관적인 편 – 산술 연산인 경우 ALU가 계산을 수행 – 조건 분기인 경우 플래그 레지스터 조작 – 메모리 로드, 저장인 경우 4단계 작업 없음. • 연산장치 수가 제한적 (네할렘 연산장치 12개) – 자원 분배 같은 이슈가 있다.
  • 31. 5. 연산 결과 저장 Operand Storing, OS / Write Back, WB • 산술연산 : 연산 결과를 목적지에 저장 • 메모리 로드 : 읽은 값을 목적지에 저장 • 메모리 스토어 : 레지스터값을 메모리에 저장 • 분기문 : PC값을 변경(??) – 1단계 명령어 인출(IF)에서 이미 처리했다. – 2단계 명령어 해독(ID)도 안 해보고 PC값 변경. – 현재 프로세서들은 PC내용을 앞서 예측한다.
  • 32. * 예외처리 * exception handling • segmentation fault / access violation – TLB가 가상 주소를 유효주소로 변홖할 때 • 예외exception와 인터럽트interrupt로 나뉜다. exception 인터럽트 예외 • 하드웨어 인터럽트 • 트랩 trap • 소프트웨어 인터럽트 • 폴트 fault • 중단 abort
  • 33. 예외처리 > 인터럽트 Interrupt • 하드웨어 인터럽트 – 명령어 흐름 처리와 상관없는 사건의 발생. – ex: 키보드가 눌렸다는 신호 – ex: 멀티태스킹 스케줄러가 발생시키는 신호 – 명령어 흐름을 중단했다가 재개하게 된다. • 소프트웨어 인터럽트 – 명령어에서 발생시키는 인터럽트 – ex: x86 명령어 INT
  • 34. 예외처리 > 예외(?) exception • 프로그램 실행 도중에 발생하는 일 – ex: 나눗셈 연산중 division by zero 발생 – ex: 페이지 폴트. – 역시 명령어 흐름이 중단되었다 재개된다. • fault / trap / abort – fault: 중단했던 명령어를 재실행 (page fault) – trap: 중단한 명령어 다음부터 실행(break point) – abort: 재시작이 허용되지 않는 심각한 경우.
  • 35. 결론 • 명령어 처리를 다섯 단계로 나누어 확인 – 프로세스 기본동작의 컨셉을 확인해봄 • 캐시, 주소 변홖, PC 값 예측, 예외처리 등. – 이후 알아볼 개념들에 대한 개념 소개.