CPU 성능 향상 기법

성능에 대해 논할 때는 성능이란 무엇인지 정의하는 게 중요하다 하셨다.
cpu에 있어 성능이랑 무엇일까? 속도, 병렬처리, 정확성 등이 있을 수 있다.
백엔드를 개발함에 있어, 속도, 병행처리, 정확성 향상은 사용자에게 좋은 경험을 주고 더 많은 사용자를 수용할 수 있도록 돕기에 매우 중요하다.

빠른 cpu를 위한 설계 방법

빠른 CUP를 설계하기 위한 기법으로는 클럭, 멀티코어, 멀티쓰레드가 있다. 우선 클럭, 코어, 쓰레드가 무엇인지에 대해 알아보자.

클럭

지속적으로 학습했듯이, 박자에 맞춰 춤을 추는 것처럼 클럭에 맞춰 CPU가 명령어 사이클을 반복하고 다른 부품들은 이에 따라 동작한다.

클럭 속도의 단위 헤르츠(Hz)이다. 헤르는 1초에 몇 회인지를 나타낸다. 실제 본인이 사용중인 cpu의 성능은 아래와 같다. 각각 스펙과 실제 수치를 캡처한 것이다. (기본 스펙)
(실제 사용)

스펙에 나온 기본 클럭이 1.6GHz, 터보 클럭은 4.2GHz이며, 실제 클럭은 0.9GHz이다. 실제 클럭이 너무 낮게나와 놀랐지만, CPU가 자체적으로 온도, 전력, 코어 수 등을 고려하여 클럭 속도를 조정한다고 한다. 터보 클럭은 최대로 클럭 속도를 조정했을 때를 의미한다.

클럭 속도를 높인다면 컴퓨터는 빠르게 동작할 것이다. 하지만 앞서 말했듯 온도, 전력 등의 부작용이 생길 수도 있다. 따라서 클럭 속도만으로 CPU 성능을 높이는 것에는 한계가 있다. (여담으로, 최근 이슈가 되고있는 초전도체가 실용화가 된다면 발열 문제가 줄어들어 클럭 속도를 높여 엄청 빠른 CPU가 등장할 수도 있다.)

코어와 멀티코어

현대에 코어가 의미하는 바는 전통적으로 CPU가 의미하는 바와 같다. ALU, 레지스터, 제어장치를 포함하고 있는 연산장치이다. 현대적인 의미에서 CPU는 여러 코어를 포함하는 연산장치이다.

(오늘날의 CPU 이미지)

위 이미지처럼 여러 개의 코어를 포함하는 CPU를 멀티코어라고 한다.

그렇다면, 코어를 증가시키면 빠른 속도를 기대할 수 있을까? 일반적으로는 빠른 속도가 나오겠지만 무조건 그렇진 않을 것이다.

위 이미지처럼 작업에 비해 너무 많은 코어가 있다면 비효율적일 것이며 작업에 비해 너무 적은 코어가 있다면 속도가 느릴 것이다. 따라서 작업의 수에 맞는 적당한 코어가 필요하며 이들을 효율적으로 분배하는 것이 연산속도에 있어 중요하다.

(다른 걸 설명하는 이미지이지만, y축을 성능 x축을 코어의 수로 생각하면 의미가 유사하다.)

스레드

스레드의 사전적인 의미는 실행 흐름의 단위이며, 프로그램 실행의 최소 단위로 알고있었다.

하드웨어적인 의미
스레드는 코어에 들어오는 명령어를 처리하는 가장 작은 단위의 부품이다.

멀티 스레딩은 하나의 코어 안에서 여러 스레드로 여러 명령어를 동시에 실행하는 것을 의미한다. 실제로 동시에 실행하는 것은 아니며 아주 빠른 속도로 번갈아 실행하여 동시에 실행하는 것과 유사하게 한다. 이는 두 개의 팔만 이용함에도 여러 개의 공을 돌리는 것처럼 보이는 저글링과 유사하다.

소프트웨어적인 의미
하나의 프로그램은 여러가지 기능을 동시에 수행될 수 있어야한다. 예를 들어,게임 프로그램에서는 타이머, 스킬 쿨타임, 미니맵 등 여러 정보를 표현하는 기능들이 있다. 스레드는 이처럼 하나의 프로그램이 여러 기능을 실행하기 위해 *프로세스의 자원들을 공유하여 사용하는 개체이다.

(프로세스는 프로그램이 os에 의해 cpu 할당 메모리 할당받은 개체이다.)

스레드는 명령어 처리를 위해 프로세스의 자원인 CPU와 메모리를 공유한다. 하지만, 공유하지 않는 독립적인 영역들도 있는데 CPU에서는 레지스터 세트(PC, SP 등)가 그러하다. 스레드는 하나의 CPU인 것처럼 명령어를 처리하기에 논리 프로세서라고도 한다.

유명한 비유

CPU, 코어, 쓰레드를 설명할 때 유명한 비유로 드는 것이 음식점이다. CPU는 음식점, 코어는 요리사, 쓰레드는 가스레인지이다.

명령어의 빠른 처리가 요리사가 많으면, 가스레인지가 많으면 요리를 빠르게 내올 수 있는 것과 유사하다.

명령어 병렬 처리 기법

CPU는 여러 장치들이 상호작용하여 명령어를 수행한다. 이 때, 작업을 수행하지 않고 대기중인 장치들이 존재하게 되는데 이러한 대기 중인 장치를 최소화하고 모든 장치들이 동작을 수행할 수 있도록 하는 기법을 명령어 병렬 처리 기법이라고 한다.

명령어 파이프라인

명령어는 일반적으로 아래 4가지 단계로 나누어 볼 수 있다.

• 명령어 인출(Instruction Fetch)
• 명령어 해석(Instrction Decode)
• 명령어 실행(Execution Instruction)
• 결과 저장(Write Back)

CPU는 겹치지 않는 단계들을 동시에 실행할 수 있다는 특성이 있다. 명령어 파이프라인은 아래 그림처럼 여러 명령어들을 단계가 중복되지 않는 선에서 동시에 실행하는 기법이다.

파이프라인 위험

CPU는 대부분의 경우 명령어 파이프라인을 통해 성능 향상을 이뤄내지만, 그렇지 않은 경우도 존재한다. 이처럼 성능 향상에 실패하는 경우를 파이프라인 위험이라고 한다.

데이터 위험

명령어 1: R1 = R2 + R3
명령어 2: R4 = R1 + R5

와 같은 상황, 명령어 2는 명령어1이 완료된 이후에야 수행이 가능하며, 이 때 명령어 파이프라인은 동작할 수 없다.

제어 위험

위 그림처럼 다음에 실행할 명령어의 주소가 갑작스럽게 분기되어, 진행중인 파이프라인이 활용되지 못하는 경우이다.
다음 번지를 예측하는 분기 예측이라는 기술도 있으며, 이 역시 예측을 실패했을 경우 위험이 있다.

구조적 위험
서로 다른 명령어들이 같은 장치를 사용하려할 때 발생한다.

슈퍼스칼라

같은 명령어 단계도 동시에 실행하는 기술이며, 이것이 가능한 프로세서를 슈퍼스칼라 프로세서라고 한다.

이론적으로는 파이프라인 개수에 비례에 속도가 빨라지나, 파이프라인 위험이 높아 이를 고려한 설계가 중요하다.

비순차적 명령어 처리

데이터 위험과 같이 의존성이 필요해 이전 명령어의 완료를 기다려야 하는 경우 해당 명령어의 실행을 뒤로 미뤄 명령어 대기를 줄이는 방법이다.

CISC와 RISC

효율적인 파이프라이닝을 위한 명령어 구조가 있다. 이에 대해 알기 위해선 ISA가 무엇인지, CISC, RISC가 무엇인지에 대해 알아야 한다.

ISA (Instruction Set Architecture)

우리가 프로그래밍을 통하 작성한 고수준 코드는 컴파일러에 의해 기계어로 변환되어 HW에 의해 실행된다. HW가 실행할 수 있는 명령어 집합을 ISA라고 하며, 컴파일러는 이에 맞도록 고수준 코드를 기계어로 번역한다.

ISA는 CPU마다 다르고, CPU에 해당하는 컴파일러를 선택해서 번역해야 한다. x86 기반(Intel, AMD) 끼리는 같은 프로그램을 사용할 수 있지만 ARM 기반(M1)은 호환이 되지않는 경우가 이에 해당한다. 간혹 보면 M1에서 Intel 컴파일러를 사용하여 성능이 느렸다는 글들을 볼 수 있는데 이는 M1에서 x86 기반 프로그램을 실행할 수 있는 애뮬레이터(Rosseta)를 지원하기 때문이다.

CISC (Complex Instruction Set Computer)

복잡한 명령어 집합을 사용하는 컴퓨터이다. x86, x86-64(64bit) 등을 의미한다. CISC는 복잡한 대신 강력한 기능이 있는 명령어들을 활용한다. 이러한 명령어들은 형태나 크기가 다양한 가변 길이 구조이다.

이러한 명령어들의 사용으로 메모리를 절약할 수 있으나, 명령어의 크기와 실행시간이 상이하고 여러 클럭에 걸쳐 실행되는 경우도 있어 파이프라인에 비효율적이다.

RISC (Reduced Instruction Set Computer)

파이프라이닝은 현대 CPU의 성능최적화에 핵심 기술이다.
RISC는 CISC에 비해 규격화되어있고, 1클럭 내외로 처리되는 작은 명령어로 이루어져 있어 파이프라이닝에 유리하다.

정리

특징	CISC	RISC
종류	복잡하고 다양함	단순하고 적음
길이	가변 길이	고정 길이
주소 지정방식	다양함	다양하지 않음
처리 필요 클럭	여러 개	1개 내외
파이프라이닝 효율	낮다	높다

그럼에도 CISC를 사용했던, 사용하는 이유는 무엇일까?

a3을 구해야 한다면 CISC의 경우 세제곱을 구하는 기능을 활용하면 되지만 RISC는 곱셈을 3번 진행해야한다. (정확하진 않고, 비유로만 받아들이면 좋겠다.) 이는 손수 코드를 작성해야 했던 초기에 메모리 사용을 아낄 수 있다는 점과 더불어 큰 메리트 였을 것이다.

그러다보니 많은 시스템에서 CISC 기반이 많아져 이제와서 RISC기반으로 변경하기에는 어려움이 있을 것이다.

또한, CISC-RISC 모두 상대의 장점을 닮아가며 구분이 불분명해지고 있기에 굳이 RISC 기반으로 변경하지 않는 것으로 보인다.