cpu bound vs io bound

버스트(Burst)

어떤 현상이 짧은 시간 안에 집중적으로 일어나는 일.

 

CPU 버스트(Burst)

프로세스가 CPU에서 한번에 연속적으로 실행되는 시간. (즉, time splice 동안 프로세스의 명령어들이 연속적으로 실행된 시간)

 

I/O 버스트(Burst)

프로세스가 I/O 작업을 요청하고 결과를 기다리는 시간.

 

프로세스의 인생은 CPU Burst와 IO Burst의 연속  

프로세스는 위 그림과 같이 CPU Burst 작업과 I/O 작업, 이 2가지 작업만을 번갈아 가면서 실행하게 되고, 실행이 끝이 난다. 

 

대부분의 프로세스는 CPU Burst 8ms 내로 끝이 난다.

 

CPU bound 프로세스

CPU Burst가 많은 프로세스.

CPU Bound 프로세스의 예시

1. 동영상 편집 프로그램

-> 동영상 편집 프로그램은 CPU 작업을 요구하는 명령어들이 많기에 CPU Burst가 매우 커진다.

고로, 해당 프로그램을 실행 시, CPU의 사용률이 급격하게 올라간다.

2. 머신러닝 프로그램

-> 엄청난 연산을 필요로 하기 때문에 CPU Burst가 매우 커진다.

고로, 해당 프로그램을 실행 시, CPU 사용률이 급격하게 올라 간다. 

-> 어떤 프로그램을 실행 시, CPU가 8,90%의 사용률을 보이고 있다면, 해당 프로그램이 CPU Bound 프로세스일 가능성이 있다. 

 

I/0 Bound 프로세스

I/O Burst가 많은 프로세스.

 

I/O Burst 프로세스의 예시

(일반적인) 백엔드 API 서버 : API 서버는 일반적으로 Request를 클라이언트가 네트워크를 통해서 요청을 하면, DB 서버

나 Cache 서버에게 데이터를 가져와서, Response해준다. 

네트워크를 통해 데이터를 주고 받는 것도 I/O 작업이며, 이 API 작업은 네트워크를 통한 작업이기에 I/O Burst가 굉장히

클 수 밖에 없다. 

(구현한 API의 특성에 따라서는 I/O Bound가 크지 않을 수 있기 때문에, 보험을 들기 위하여 "백엔드 API 서버"라는 단어 앞에 "일반적인"이라는 단어를 넣었다.)

 

퀴즈

Q. 듀얼 코어 CPU에서 동작할 CPU bound 프로그램을 구현한다면 몇 개의 스레드(Thread)를 쓰는 게 좋을까요??

예를 들어, 사진 10만개를 읽고, 그 중 사람이 있는 사진을 추출하는 프로그램을 만들고자 할 때, 스레드(Thread)를 1000천

개 씩이나 많이 만들면 빨리 처리가 될까?

무조건 스레드(Thread)를 많이 만들면 좋은 걸까???

A. 우선, 스레드(Thread)를 많이 만든다고 하여서 꼭 성능이 좋아지는 것은 아니다. (아래에서 구체적으로 설명함)

CPU Bound 프로세스에 몇 개의 스레드(Thread)를 할당하면 좋은지에 대해서는 Goetz라는 사람이 최소한의 가이드 라인

을 제시하였다.

CPU Bound 프로세스의 스레드(Thread) 수 = (CPU/코어의 개수)[+1] ( CPU/코어의 개수에서 1개의 Thread를 더 추가할

수도 있고 안 해도 된다. )

 

스레드를 많이 생성한 경우

하나의 프로세스를 4개의 Thread로 분할을 해서 성능이 1/4만큼 좋아질 것 같지만, 그렇지 않다. 

그 이유는 바로 Context Switching에 의한 CPU 오버헤드 때문이다.(아래에서 설명)

스레드를 아무 생각없이 많이 생성을 하게 되면, Context Switching이 무지하게 오버헤드를 만들어 냄으로 오히려 성능이 저하가 된다.

스레드의 수 = cpu/코어의 개수

스레드가 2개밖에 없어서 스레드가 4개인 경우에 비해 성능이 안 좋을 것 같지만, Context Switching이 덜 일어나므로 성능이 오히려 더 좋게 나온다. 

 

 

I/O Bound 프로그램은 스레드 몇개로 구현이 적절할까??

CPU Bound 처럼 특정한 가이드라인이 없다.

여러 상황에 맞춰서 적절한 스레드 수를 개발자가 찾아야 한다.