데이터베이스 시스템 구현 과정 노트: 프로그램 성능 향상

1. 프로그램의 성능 향상
1. 디스크 (Disk) 가 메모리 (Memory) 보다 느 린 것 은 아니다.
원리: Memory 의 랜 덤 액세스 (random access) 는 많은 시간 을 소모 해 야 합 니 다. 수량 급 은 약 500 + cycle 입 니 다. 즉, 매번 랜 덤 액세스, CPU 는 시간 등 데 이 터 를 메모리 에서 읽 어야 합 니 다.디스크 를 한 번 에 읽 는 시간 이 메모리 보다 훨씬 느 리 지만 순서대로 읽 으 면 시스템 은 자동 으로 다음 데 이 터 를 L2 cache 에 미리 읽 고 L2 에서 CPU 까지 의 시간 은 하나의 cycle 만 필요 합 니 다.즉, 디스크 순서 로 대량의 데 이 터 를 읽 고 overhead 를 무시 하면 cycle 한 그룹의 데이터 속도 에 도달 할 수 있 습 니 다. 만약 에 하 드 디스크 속도 가 5G / s 라면 노점 속도 도 기본적으로 5G / s 에 달 합 니 다.물론 이것 은 하 드 디스크 데이터 저장 구조 와 도 관련 이 있 습 니 다. 하 드 디스크 는 평행 으로 액세스 할 수 있 는 디스크 가 많 습 니 다. 가로 로 데 이 터 를 저장 하면 다음 데 이 터 를 동시에 읽 을 수 있 습 니 다.데이터 가 세로 로 같은 디스크 가 존재 한다 면 안 됩 니 다. 그러나 두 번 읽 는 사이 의 다른 코드 cycle 이 충분 하 다 면 시간 을 절약 할 수 있 습 니 다. (그러나 메모리 의 랜 덤 액세스, 두 번 읽 는 사이 에 충분 한 코드 가 끼어 있어 도 시간 낭 비 를 피 할 수 있 습 니 다)
응용 예: 디스크 에 있 는 데 이 터 를 링크 에 순서대로 읽 습 니 다. (배열 을 넣 지 않 는 것 은 데이터 길 이 를 모 를 때 가 있 기 때 문 입 니 다) 다음 에 읽 을 수 있 도록 필요 할 때 디스크 에서 직접 읽 는 것 이 좋 습 니 다.
2. 조건문 은 운행 속 도 를 크게 낮 춘 다.
원리: Architecture 를 배 웠 을 때 조건 부 (branch, 순환 조건 포함) 를 실행 할 때 시스템 이 일정한 수량의 명령 을 미리 읽 어서 속 도 를 올 려 야 하기 때문에 조건 부 블록 에 대한 추측 (즉, if 블록 에 들 어 갔 는 지, else 블록 에 들 어 갔 는 지 추측 하 는 것) 을 해 야 합 니 다. 만약 에 그 조건 부 를 실 행 했 을 때 추측 이 잘못된 것 을 발견 하면미리 읽 은 명령 을 모두 돌려 주 고 정확 한 부분 을 다시 실행 합 니 다.결 과 는 이전의 cycle 시간 을 낭비 하고 명령 도 메모리 에서 읽 었 습 니 다. 명령 포인터 가 바 뀌 었 으 니 새로운 주소 에서 명령 을 기 다 려 야 합 니 다 (즉, 무 작위 로 읽 기, 500 cycle 이 필요 합 니 다).따라서 우 리 는 조건문 을 사용 하거나 예측 오 류 를 피해 야 한다.또한, 조건 부 구문 블록 에 대한 추측 (branch predicate) 은 처음으로 else 부분 에 들 어 갈 것 이 며, 실행 할 때마다 predicate table 을 기록 하여 다음 에 데이터 참조 로 예측 할 수 있 도록 합 니 다. 어떤 전략 으로 추측 하 는 지 는 시스템 에서 결정 합 니 다.
응용 예: 다음 문 구 를 쓰 는 것 은 순 전 히 시간 을 낭비 하 는 것 이 고 직접 num = 0 이다.잘 됐 네.

if(num != 0)  
    num = 0;

또한 첫 번 째 로 들 어 갈 문장 블록 을 else 부분 에 두 고 다 층 적 인 if - else 문장 을 피해 야 한다.

for(int i=0; i<100; i++){  
    if( i != 0)  
        ; //nothing to do  
    else //i   0,           
        Initialization();  
    if( i == 99)// 99                 
         Finalize();  
} 

3. 초보 자 코드 는 가장 빠 른 속 도 를 얻 을 수 있다.
원리: 사람들 이 시스템 을 설계 할 때 프로그래머 가 멍청 한 방식 으로 코드 를 쓴다 고 가정 하기 때문에 프로그래머 에 게 밑바닥 실현 을 이해 하고 시스템 에 적응 하 는 교묘 한 코드 를 쓰 도록 요구 할 수 없다.그러므로 무늬 를 바 꾸 어 똑똑 한 코드 를 쓰 지 마라. 사실은 멍청 한 방법 보다 느 릴 지도 모른다.이것 은 프로 그래 밍 에서 매우 유명한 이론 KISS 입 니 다. Keep it simple as stupid. 다른 배열 의 순서 로 읽 으 면 가장 빠 른 속도 (하나의 cycle 한 마디) 를 얻 을 수 있 습 니 다. 시스템 은 자동 으로 다음 데 이 터 를 미리 읽 습 니 다. 일부 문 구 를 실행 하지 않 기 위해 아래 표 시 를 계속 바 꾸 지 마 십시오 (index). 특히 배열 의 역순 으로 읽 는 것 은 매우 느 립 니 다. 매번 무 작위 액세스 와 같 습 니 다.(미리 읽 은 것 은 모두 필요 하지 않 고 캐 시 를 차지 하기 때 문 입 니 다) 이 수업 을 배 운 후부 터 저 는 배열 을 매우 좋아 합 니 다. 한 번 은 제 가 사용 하 는 데이터 구 조 를 링크 에서 배열 로 바 꾸 었 고 운행 시간 은 2 시간 여 에서 1 시간 도 안 되 는 것 으로 바 꾸 었 습 니 다.
응용 예:

int sum = 0;  
for(int i=0; i<100; i++){  
    if(a[i] >= 0)//      if(a[i] <0) i++;      index     
        sum += a[i];  
}  

4. 다 중 스 레 드 동기 화 를 피하 고 new 와 delete 대상 을 오 가 는 것 을 피한다.
원리: 동기 화 코드 를 실행 할 때 시스템 은 실행 중인 스 레 드 에 모든 시간 을 배정 하 는 것 이 아니 라 다른 스 레 드 가 실 행 될 때 특정한 token 에 계속 접근 하여 실행 권한 이 있 는 지, 이 token 이 풀 릴 때 까지 매우 시간 이 걸 리 는 작업 입 니 다. 따라서 다 중 스 레 드 동기 화 를 사용 하지 않도록 해 야 합 니 다. 두 스 레 드 에서 읽 지 않도록 해 야 합 니 다.같은 데 이 터 를 작성 합 니 다. 물론 이것 은 어떤 상황 에서 쉽게 할 수 있 는 것 이 아 닙 니 다. 추천 하 는 방법 은 정보 교환 을 전문 적 으로 처리 하 는 종 류 를 채널 로 만 드 는 것 입 니 다. (동기 화 범 위 를 최대한 낮 추 는 것 입 니 다)또는 읽 기와 쓰기 가 필요 한 데이터 블록 을 서로 다른 부분 으로 나 누 어 서로 다른 스 레 드 에 따로 할당 합 니 다. 예 를 들 어 1000 길이 의 정렬 이 필요 한 배열 을 네 개 로 나 누 어 각각 스 레 드 250 = = 을 처리 한 후 합 칩 니 다. new 와 delete 를 오 가 는 것 을 피 하 는 것 도 동기 화 를 피 하 는 것 입 니 다. 특정한 스 레 드 new 와 delete 대상 은 모든 스 레 드 를 기다 리 고 시간 을 소모 합 니 다. 추천 하 는 방법 입 니 다.예, delete 할 대상 을 전문 적 인 클래스 로 관리 하고 다음 에 필요 할 때 그 중에서 분배 합 니 다. 정말 필요 하지 않 을 때 까지 delete 합 니 다.