Computer Architecture 1 - ISA & Performance

 

1. Instruction Set Architecture

ISA(Instruction set Architecture) : hardware/software interface. – 소프트웨어와 하드웨어 사이를 이루고 있는 층. 컴파일러가 번역한 Machine code와 그 기계어가 실행되는 HW 바로 그 사이이다. 즉, 기계어의 각 instruction이 실제 하드웨어에서 어떤 일을 하는지 이어주는 것이라고 생각하면 된다. 이는 Low level detail을 숨김으로써 user에게 복잡함을 줄여준다.

이를 달리 말하면 Abstraction 이라 하는데,  실제 implement는 어떻게 되는지 모르지만 사용하는 방법만 가지고 사용할 수 있게 하는 것이다. 사용자가 작동원리를 모르고도 원하는 작업을 할 수 있게 도와준다. 또 다르게 생각하면, 사용하는 입장의 인터페이스가 동일하면 내부구조가 바뀌어도(버그를 잡거나, 개선하거나 등등) 사용자는 어려움 없이 원하는 동작을 사용할 수 있다는 말이다. 따라서 모든 IT업계에서 가장 필수불가결한 구조이다. 단, 발전을 저해하는 하나의 요소가 될 수도 있다. 왜냐하면 항상 동일한 interface를 사용하는 것만을 유저가 더 선호하기 때문이다.

 

High level language(HLL) : 사람에게 친숙 <->low level language(LLL) : 컴퓨터에게 친숙.

->high level로 써진 것 = application software.

Complier가 HLL을 machine code로 변환해줌.

HW위에 operating system(OS)가 돌아가며 application software에 리소스를 제공하고, I/O, 메모리를 조절하는 등의 일을 함.

HLL : productivity(생산성 : 사람입장에서 쓰기 쉽고 빠른 것. 단, 프로그램 실행속도까지 빠르지는 않음)., 서로 다른 언어들은 서로 다른 문제를 해결하는데 효율적임.

일반적으로 machine language와 assembly language는 1대 1 대응이 가능하다.( 왜냐하면 machine language에서 instruction 부분을 빼서 글자로 적은 것이 assembly code 이므로)

HLL은 더 작은 instruction들로 나누어지므로 aseembly lang과 machine code는 HLL보다 훨씬 많은 양이 된다.(일일이 구현해야하므로)

CPU마다 아키텍처가 다르므로 사용되는 assembly language도 다르다(아키텍쳐, 어셈블리어, 기계어 모두 CPU 마다 각각 다름) 그러나 앞서 자바에서 배운 것처럼, 자바는 JVM이 각 cpu에 알맞은 complie을 미리 해 놓는다(ISA를 구성함). 따라서 사용자 입장에서는 동일한 JVM을 확인할 수 있다.

 

컴퓨터의 5구조 : Datapath, control(CPU), memory, I/O.

코드가 실행되는 과정 : 코드를 컴파일 -> ISA로 각 알맞은 cpu 아키텍쳐에 맞게 변환. Input은 memory를 통해 cpu로 들어오고 datapath에서 원하는 프로세스를 한 다음(control by controller) 다시 memory로 나간다. 데이터 I/O는 반드시, 모두 memory를 통해서 이루어진다.

Machine code = HW에 내릴 instruction으로 구성됨.

 

2. Performance

Algorithm(Datastructure, coding skill) – executed operation(HLL) 개수를 결정. Programing lang/compiler/architecture(ISA) – 한 operation 마다 실행되는 machine instruction의 수를 결정. Processor/memory system – 각 instruction이 실행되는 속도를 결정. I/O system/OS – I/O operation의 실행 속도를 결정.

Response time/Latency / execution time : 한 개의 일을 하는데 걸리는 시간

Throughput : 단위 시간 당 하는 일의 양.

이를 통합하여, 일이 끝나는 시간이 퍼포먼스를 정의할 수 있다. 그러려면 주어진 일의 양을 정의하는 것이 중요하다.

따라서 더 빠른 cpu를 사용하면 response time이 줄어들고(개선), throughput 도 많아진다(좋음). 그러나 cpu를 더 많이 추가하면 throughput은 많아진다. 그러나 response time의 경우 일을 어떻게 정의하는가에 따라 달라질 수 있다. 만약 많은 일이 있어서 cpu가 일을 나눠서 하거나, 하나의 일이라도 멀티코어를 support 하는 경우에는 response time도 개선될 수 있다. 그러나 하나의 프로그램이 하나의 cpu에서만 돌아가는 경우에는 그렇지 않다.

따라서 Performance = 1/executionTime 으로 정의하면 일이 끝나는 시간을 중점적으로 보고 performance를 정의. 따라서 X가 Y보다 n배 빠르다 에서 n=executionTime(y))/(executionTime(x))이다.(역수이므로)

Execution time을 측정하는 방법 : Elapsed time(=total response time, 프로그램이 시작하고 끝날 때까지 걸리는 총 시간. 그러나 이는 I/O나 OS, idle time 등등 원하는 processing time 이외에도 측정하는 것들이 많다.), CPU time ( 오로지 cpu가 processing하는 시간만 오롯이 측정하는 것, user CPU Time / System CPU time – 각각 cpu가 내 프로그램을 실행하는 시간, OS가 내 프로그램을 돌리기 위해 사용하는 시간(OS는 어쩃든 cpu에서 계속 돌아가므로)-내 프로그램에 I/O로 넣은 파일을 읽는 등…). 컴구 수업에서는 user time만 중점적으로 봄.

 

CPU clocking : clock = 1010101010….을 일정한 주기로 내뱉는 기기. 어떤 digital HW라도 가지고 있다. 한 주기(1과 0)가 도는데 걸리는 시간 = clock period(1 cycle of clock). 일반적으로 데이터를 쓰는 과정은 clock period boundary에서 발생.

Clock frequency(clock rate) = cycles per second. 4.0GHZ = 4*10^9번의 cycle이 1초마다 일어난다는 의미. 반대로, clock period는 한 clock cycle이 걸리는 시간이므로 clock frequency의 역수이다. 즉, 1/clock frequency = clock period. 따라서 4.0GHZ는 0.25nano second의 period를 갖는다.

MIPS(million instruction per second = average numbers of instruction per second) 로도 performance는 알 수 없다. 왜냐하면 프로그램이 몇 개의 instruction을 만드는지 모르기 때문이다. 따라서 실제 시간을 측정하는 것 외에는 performance를 측정할 수 없다. MIPS = number of instruction count/execution time = clock rate / (CPI * 10^6) – 10^6은 단위가 milion이라서 붙음.

CPU time(needed for my program)=Cpu clock Cycle(used by my program) * Clock cycle time = cpu clock cycle/ clock rate : performance. 따라서 performance를 증가시키기 위해서는 clock cycle number을 감소, clock rate을 increase하는 법이 있다. 그러나 clock rate / cycle count는 서로 연결되어 있기 때문에 이 둘 사이의 trade off를 고려해야 한다. Clock이 커지면, clock cycle의 양도 증가한다.

Instruction count = determined by program, ISA, compiler.

Average CPI(Clock-cycles Per Instruction) : CPI는 한 개의 instruction을 돌리는데 필요한 사이클의 수. 서로 다른 instruction은 서로 다른 cycle이 필요함. Instruction mix : 내가 돌리는 프로그램에서 실행하는 instruction의 종류와 반복 횟수. 따라서 각 연산에 필요한 instruction의 수와 그 연산의 반복 횟수를 곱해서 나온 값을 평균 취해야 평균 CPI를 구할 수 있다. 예를 들어 복사/더하기/곱하기 연산이 각각 1,2,3 instruction count가 필요하고, 각 연산을 500, 600,600번 반복한다면 total clock cycle은 3500이다. 여기서 Avg CPI를 계산해보면 총 clock cycle을 instruction count로 나누어 구하는 3500/1700이 된다.

Clock cycle(needed for my program) = Instruction count(of my program) * Average cycles per instruction(of my program). (instruction mix에 절대적으로 의존하므로 “my program”을 추가)

따라서 CPU time = instruction count * Avg cycles per instruction = Instruction count * Avg CPI / clock rate.

실제로 어떤 연산(instruction)이 얼마나의 cycle이 걸리는지는 오롯이 hardware organization에 의해 변화한다. 따라서 하드웨어도 CPI에 영향을 미친다.

Clock(GHz)는 일정이상 올라가기 힘들다(현재도 2~3GHz). 왜냐하면 power는 frequency * V^2 * capacity load에 비례하기 때문에 frequency를 너무 올리면 power를 엄청 잡아먹게 되고, 배터리/전력을 너무 많이 사용하게 된다. 따라서 Voltage를 줄이려는 노력을 하여 배터리가 더 오래가게 된다. 그러나 1V 이하로 1/0을 구분하려면 digital 적인 floating 때문에 1과 0을 구분하기 어려워진다. 따라서 voltage를 줄이는 것은 한계가 있다. 어쩃든, 전력(power)에 의해 frequency를 올리기는 어렵다. 추가적으로 작아진 동시에 동일한 전력 혹은 더 많은 전력을 사용하기 때문에 heat/cooling 이 더 어렵게 되어서도 성능을 올리기 어려워진다. 따라서 multiprocessor가 대두 되었다.(multi core microprocessors). 그러나 실제적으로 원하는 프로그램을 멀티코어 프로세서에 나누어 연산하기 쉽지 않기 때문에 원하는 성능 개선은 미미하다.(병렬 연산을 지원하도록 프로그램을 짜고 분산하여야 한다. (Load balancing / communication / synchronize)

앞서 performance를 나타내는 것은 결국 프로그램 코드를 어떻게 짜느냐가 좌우한다. 그래서 이를 획일화 하여 비교할 수 있게 한 것이 SPEC benchmark(Standard Performance Evaluation Corp)이다. (SPEC CPU, SPEC Power, SPEC Int…. 등등). Common set of program to measure performance.

결국 종합하면, Performance는 얼마나 많은 시간이 걸리느냐로만 알아낼 수 있다.