Super Scalar Extracting Yet More Performance - Super Pipelining: 파이프라인에서 파이프 스테이지를 늘릴수록, 클락 레이트를 올릴수록 성능이 좋아진다. 클락 레이트는 가장 오래 걸리는 스테이지에 맞춰야한다. 가장 오래걸리는 것을 쪼개는 것이 중요하다. 이에 따라 파이프라인의 깊이를 늘리는 것이 중요하다. - Super Scalar: 한 사이클에 하나보다 더 많은 명령어를 패치하고 실행한다. 매 파이프라인마다 하나가 아닌 여러개의 명령어가 돌아가는 구조를 의미한다. - Super Scalar를 하면 CPI가 1보다 낮아질수도 있다. Instruction pipeline superscalar - 여러개의 명령어를 패치하는 것을 확인할 수 있다. - 연산하는 것..

Control Dependence 1. Predicated Excution - control dependence는 브랜치때문에 발생한다. - 타겟 어드레스를 보고 Backward, Forward를 하는 방법이 있었다. - branch prediction도 사용한다. - 위의 내용을 모두 사용해서 성능을 높이기 위해 노력한다. 이때 control-flow instructions을 제거하는 방법이 있다. 이는 MIPS ISA에는 없다. - ARM은 ISA를 다음과 같이 디자인했다. condition에 4비트를 사용해서 브랜치 명령어를 줄인다. 예제) - 브랜치를 없애고 이를 condition으로 바꿔서 실행할 것인지 말 것인지를 확인한다. 이를 통해 원래는 control 디팬던시가 있었지만 이를 데이터 디팬..

Project Management 탑다운에 기반한 내용이기에 최근 소프트웨어 개발 방법론인 Agile과는 다른 면이 있어 논란의 여지가 있을 수 있다. - Project Planning 이전의 단계이지만 WaterFall 방식과 Agile 방식의 차이점이 너무 크기 때문에 이를 중심으로 Project Management를 설명하고자 한다. 1. Ice break - 프로젝트는 시작된다고 해서 모두 성공하는 것은 아니고, 망해가는 프로젝트를 통해 교훈을 얻을 수 있다. 이후 이러질 Project Planning을 하는 것이 매우 어렵고 WaterFall 방식과 Agile 방식의 차이점도 매우 크고, man-month라고 하는 투입되는 사람에 대해 차이점이 있다. 또한 프로젝트가 망해가는 것에 대한 특징을 ..

HTTPS and SIP - HTTPS는 웹브라우저와 웹서버의 통신을 지배하고 있다. - transport layer로 얘기를 하기도 한다. - 로그인 -> 세션의 채팅방 -> 음성통화나 화상통화 가능. 이러한 음성 전화나 화상통신은 IP based인 SIP을 사용한다. instance messanger, 줌 등의 핵심 기술이다. Textbook of HTTPS Chapter HTTP: The Definitive Guide - 프로그래밍 랭귀지에 HTTP가 들어갈만큼 일반화된 기술이다. 1. HTTP 1.x 1) Web Client and Servers - 웹브라우저를 띄우면 이는 웹 클라이언트가 되고 HTTP를 사용해 웹브라우저가 동작한다. - 정보를 요청하는 자는 웹 클라이언트, 정보를 제공하는 자는..

- 브랜치가 존재할 때 이를 어떻게 처리해줘야하는가 - 브랜치 예측을 잘 해야한다. - 브랜치 예측을 하기 위해서 아래의 세 정보가 필요하다. 1. 패치한 명령어가 브랜치인지 아닌지 확인 2. 조건에 따라 어디로 가는가 (branch direction): taken이나 not taken이냐 3. taken인 경우 어디로 가야하는가. - 타겟 어드레스가 프로그램 실행 과정에서 남아있게된다. 이를 이용해서 예측에 사용하자는 개념이다. 이를 BTB에 저장한다. - 타겟 어드레스를 저장하는 공간을 BTB를 부른다. 이는 메모리에 올리자니 접근 시간이 오래걸리고 레지스터에 넣자니 공간이 부족하다. 이에 따라 효율적으로 저장하기 위한 공간인 캐쉬에 저장한다. 그림 - 아래 박스(Cache of Target Addr..

Software Evolution 소프트웨어 출시 이후 나타나는 버그를 개선해 업데이트하는 과정 0. Software change 1) Software change란? - 해당 챕터에서 기저에 놓여있는 개발 방식은 top-down, waterfall 방식이다. - 소프트웨어는 출시 이후에 끝나는 것이 아니라 놓친 부분이나 새로운 피쳐의 등장, 비즈니스 환경의 변화 등등에 의해 새로운 기능이나 피쳐, 성능에 대한 부분, 기타 등등은 반드시 필요할 수 밖에 없다. 이는 소프트웨어의 변화를 이끈다. - 테스트는 프로그램이 완벽하다는 것을 증명하진 않는다. 이는 테스트 과정에서 걸러내지 못한 것을 이끌어내곤 한다. 이는 소프트웨어의 변화를 이끈다. - 하드웨어의 변화가 소프트웨어의 변화를 이끌수도 있다. 가상화..