[02주차] 환경

 

- MMO Game Server

 : 고사양 필요 (가성비를 따져 저 사양의 여러 대로 동접을 올리지는 않음)

 : 많은 사람을 받을 수 있다 → 동접 UP → 재미 UP → 사용자가 더 몰림 → 수입 UP

 

 : CPU - 싱글 코어로는 동접 1000도 힘들다. 멀티 코어 사용 필수 

 : Memory - 128GB 이상 필요 (월드 정보, NPC/Monster 정보, 플레이어 정보 등)

 : Network - 여러 개의 네트워크 포트 필요

 

 : HW만 좋으면 되는가? → 하드웨어를 충분히 이용할 수 있는 프로그래밍이 필요

 : 하드웨어 지식 필요 → 하드웨어가 성능에 어떤 영향을 미치는지, 하드웨어의 성능을 최대한 이끌어내는 프로그래밍 등

 

 

 

- CPU

 : X86 계열, 서버용 CPU가 따로 존재함(Intel Xeon, AMD EPYC ..)

 : 64비트(16ExaByte 메모리 가) 와 멀티코어

 : 코어 개수, 클럭속도와 캐쉬 크기, 메모리 버스 대역폭이 중요

정내훈 교수님 강의자료

 

 : NOW (NUMA) - 메모리주소를 나눠 non 유니폼 메모리 억세스

 : OLD (UMA) - 모든 메모리를 읽을 때 속도가 같음

 ( CPU 개수가 많아질 수록 과거 방식에서는 성능의 한계 존재 )

 

 : 프로그래밍 시 int와 포인터의 크기가 달라지는 것을 주의한다. 리눅스만 long이 64비트.

 

 1) 멀티 프로세서

 : SMP

 : 빠른 네트워크 응답 속도와 처리 속도 개선을 위해 사용

 

 2) 멀티 코어

 : 발열에 막힌 CPU의 성능 향상 제한을 극복하기 위한 방법

 : 8~64개의 코어를 활용하도록 가능

 

 : 멀티 코어 VS 멀티 프로세서 → SW적으로는 차이가 없으나 HW적으로 메모리 접근 시 성능 차이 존재

 → 멀티 코어는 하나의 칩에 여러 개의 코어가 포함되어 같은 메모리 공유 / 멀티 프로세서는 여러 개의 독립 칩이 서로 통신해 작동하기에 각 프로세서는 자체 메모리 가짐

 → (멀티 코어) CPU의 개수 만큼 메모리 대역폭 증가, (멀티 프로세서) NUMA(Non Uniform Memory Access) 문제

 

: CPU의 발전

 1) 클럭 속도 증가 (~2000) : 발열의 한계 도래

 2) Clock 당 수행되는 명령어 개수 증가(IPC) : 아키렉쳐 개선, 파이프 라인 등, 캐시 용량 증가  / (한계) 한계 효용의 법칙

 3) 코어 개수 증가 (2005~) : 프로그램 작성 방식 변경

 

: 파이프 라인의 발전

 1) 파이프 라인이 무효화 되지 않는 한 프로그램은 실행됨 속도는 메모리 Read에 종속.

  (명령어가 많아도 메모리 read가 적으면 더 빠름)

 2) SIMD 명령어 발전 - 하나의 명령어로 여러 개의 실수 동시 계산

 3) 파이프 고도화에 따른 주의 

  - 파이프 라인을 리셋 시키면 손해가 너무 큼

  - 리셋 원인 : 시스템 콜, 분기 예측 오류, 인터럽트, 예외 → 시스템 콜 지양, if / switch 등 자제

  - stall 원인 : 캐시 리드 미스

 

 : Cache - 프로그램 실행 속도에 가장 큰 영향

  - 같이 쓰이게 되는 데이터는 묶음

  - 루프 안에서 사용하는 데이터는 캐쉬에 다 올라올 수 있도록

  - int 대신 short나 char을 사용 (더 많이 들어감)

 

 : 멀티 프로세서 프로그래밍 

 - 잘하면 성능 향상 n배, 못하면 성능 하락

 - lock 줄이기 (lock 자체도 오버헤드, 세마포어/컨디션 변수는 시스템 호출)

 - cache thrashing 주의 (캐시는 라인 단위로 움직임)

 

 : 서버 OS 종류

 - Unix 계열 (리눅스...) → 가격 저렴 & 유지 보수 어려움

 - 윈도우 계열 → 비싼데 유지 보수가 비교적 쉬움

 

 : 프로그램 최적

 - 꼭 필요한 일만 → new/delete  포함 시스템 호출 최소화

 - 좋은 알고리즘 사용 → O()

 - 메모리 복사 줄이기 → call by value 대신 call by reference / copy constructor 사용 회피

 - HW 영향 고려 → 캐시, 파이프라인

 - 멀티쓰레드 프로그래밍

 

 

- HW 영향 고려

 1) 시스템 Call

// System Call
volatile long long tmp = 0;

DWORD WINAPI ThreadFunc(LPVOID lpParam) {
    auto start = high_resolution_clock::now();
    for (int j = 0; j < 10000000; ++j) {
        tmp += j;
        SwitchToThread(); // 현재 스레드를 양보하고 다른 준비된 스레드에게 CPU를 양도
    }
    auto duration = high_resolution_clock::now() - start;
    cout << "Time " << duration_cast<milliseconds>(duration).count();
    cout << " msec\n";
    return 0;
}

int main() {
    auto start = high_resolution_clock::now();

    HANDLE hThread = CreateThread(NULL, 0, ThreadFunc, NULL, 0, NULL);
    if (hThread == NULL) {
        cerr << "Failed to create thread." << endl;
        return 1;
    }

    WaitForSingleObject(hThread, INFINITE); // 스레드가 종료될 때까지 기다림

    CloseHandle(hThread);

    auto duration = high_resolution_clock::now() - start;
    cout << "RESULT " << tmp << endl;
}


// No system call

int main()
{
	volatile long long tmp = 0;
	auto start = high_resolution_clock::now();
	for (int j = 0; j < 10000000; ++j) {
		tmp += j;
		this_thread::yield();  // !!
	}
	auto duration = high_resolution_clock::now() - start;
	cout << "Time " << duration_cast<milliseconds>(duration).count();
	cout << " msec\n";
	cout << "RESULT " << tmp << endl;
}

 

system call

no system call

 

 시스템 콜이 있는 경우 결과가 확연히 늦는다.

 

 2) Cache Miss

constexpr int CACHE_LINE_SIZE = 40;

int main() {

	for (int i = 0; i < 20; ++i) {
		const int size = 1024 << i;
		char* a = (char*)malloc(size);
		unsigned int index = 0;
		int tmp = 0;
		auto start = high_resolution_clock::now();
		for (int j = 0; j < 100000000; ++j) {	// !!
			tmp += a[index % size];	// !!
			index += CACHE_LINE_SIZE * 11;	// !!
		}
		auto dur = high_resolution_clock::now() - start;
		cout << "Size : " << size / 1024 << "K, ";
		cout << "Time " << duration_cast<milliseconds>(dur).count();
	}
}

 

 

 3) Pipelining stall

constexpr int T_SIZE = 100000000;
short rand_arr[T_SIZE];

int abs2(int x)  // !!
{
    int y = x >> 31;
    return (y ^ x) - y;
}

int main(int argc, char** argv)
{
    for (int i = 0; i < T_SIZE; ++i) 
    	rand_arr[i] = rand() - 16384;
    int sum = 0;
    
    auto start_t = high_resolution_clock::now();
    for (int i = 0; i < T_SIZE; ++i) 
        sum += abs(rand_arr[i]);
    auto du = high_resolution_clock::now() - start_t;
    cout << "[abs] Time " << duration_cast<milliseconds>(du).count() << " ms\n";
    cout << "Result : " << sum << endl;
    
    sum = 0;
    start_t = high_resolution_clock::now();
    for (int i = 0; i < T_SIZE; ++i) 
        sum += abs2(rand_arr[i]);
    du = high_resolution_clock::now() - start_t;
    cout << "[abs2] Time " << duration_cast<milliseconds>(du).count() << " ms\n";
    cout << "Result : " << sum << endl;
}

 

pipeline stall

 

 

 : pipeline stall - 컴퓨터의 파이프라인에서 발생하는 지연 현상

 : 위에서는 분기 예측의 실패로 지연이 일어날 수 있음 (abs 함수 내에서)