7회차 받아쓰기

Attendees 1 00:13 혹시 제 목소리 들리시나요?

Attendees 1 00:20 네 감사합니다.

Attendees 1 00:53 네 그럼 시작해 보도록 하겠습니다. 네 오늘은 모델 연구소 강남센터 사정상 이 온라인으로 진행을 하기로 했고요. 오늘은 이제 일곱 번째 시간으로 CPU, GPU, MPU 에 대한 간단한 소개를 해보도록 하겠습니다. 잠깐 저희가 지금까지 했던 거를 리케을 하면 지금까지는 이제 소프트웨어적인 것들에 대해서 주로 다뤘고요. 이제 하드웨어 대해서 다루는 거는 이번이 첫 시간이고 그리고 이제 다음 주에는 저희가 하고 있는 일들 관련돼서 잠깐 소개를 드리고 방해를 마무리를 할 생각입니다.

Attendees 1 01:37 네 오늘의 이제 주제는 CPU랑 GPU랑 MPU랑 이제 어떻게 다른가라고 하는 건데요. 제가 MPU가 어떤 건지 이제 여러 번 소개를 해 보는 강의를 했었는데 그게 생각보다 그렇게 쉽지는 않더라고요. 그래서 그런 경험들이 누적돼서 오늘은 좀 다른 각도로 한번 정리를 좀 해봤는데 일단 디테일로 들어가기 전에 프로세서 디자인에 대해서 그러니까 참 어떻게 보면 되게 다양한 그런 프로세서들이 있고 똑같은 종류의 프로세서에도 여러 가지 다양한 접근법들이 있고 그리고 컴퓨터 아키텍처를 대표하는 그런 학회들이 몇 개가 있는데 그런 데에서도 매년 이렇게 새로운 제안들이 나오는데 결국에 그 많은 것들의 핵심적인 질문은 어 이런 스트랙션 레이어 컴퓨팅이라고 하는 그런 큰 그런 세계에서 실제 그 맨 밑에 있는 트렌지스터부터 실제 개발자들이 바라보는 프로그램 랭귀지까지

Attendees 1 02:39 한 번에 쭉 연결되어 있는 게 아니라 중간에 굉장히 많은 다양한 그런 에티텍션 레이어를 통과를 하도록 되어 있는데 맨 밑에 있는 그런 하드웨어들이 어떻게 개발자들한테 노출이 되는가라고 하는 그런 과정에서 여러 가지 다른 접근법들이 있고 그런 것들이 어떻게 보면 프로세서를 디자인하는 데 있어서 저는 가장 중요한 질문이라고 생각을 합니다. 성능이 결국에 드러나는 거는 맨 밑에 있는 하드웨어고요. 실제 트랜지스터 단위는 너무 낮기 때문에 여기에서 제가 데이터 패스라고 부르는 맨 밑에 있는 이런 레이어에서 결국 성능이 결정이 되지만 그렇다고 해서 그 데이터 패스에 있는 모든 디테일들을 다 개발자한테 노출을 할 수는 없거든요. 결국에는 그런 것들이 약간 체계적으로 어느 단계에서는 추상화가 되어서 개발자들이 이해할 수 있는 형태까지 정리가 돼야 되는데 그게 과연 이제 어느 단계에서 이루어질 거냐라고 하는 것들이 어떻게 보면 가장 중요한 질문 중의 하나라고 생각을 할 수가 있습니다.

Attendees 1 03:36 여기 제가 이제 세 가지 옵션을 들었는데 첫 번째는 그 데이터베이스라고 하는 맨 밑에 있는 하드웨어의 복잡성을 실제 하드웨어에서 그냥 스트랙션을 해서 실제 굉장히 간단한 인스트럭션센 아키텍처만 노출을 하게 되는 이런 접근법들도 있고요. 또 다른 하나의 접근법들은 하드웨어에서의 복잡성은 그대로 노출을 하지만 이제 그런 것들이 실제 앱섹션이 되는 거는 컴파일러 수준에서 다 이루어지도록 하는 게 이 프로세서와 컴파일러 디자인의 의도일 수도 있는 거고 또 어떤 경우에는 결국에는 개발자가 결정을 해야 된다라고 생각을 하는 철학을 가지고 있는 그런 이제 스텝도 있어서 그런 경우에는 맨 밑에 있는 데이터베스의 굉장히 중요한 특성들이 개발자들에게 다 노출이 되고 그런 디테일들을 개발자들이 직접 컨트롤을 하면서 프로그래밍을 하는 이런 디자인들도 충분히 가능합니다.

Attendees 1 04:42 이게 이제 제가 말씀드린 이제 1번, 2번, 3번 단계이고요. 그래서 개발자들이 하드웨어 테일들을 알 필요가 없게 만드는 것 이런 것들이 실제 하드웨어에서 아니면은 컴파일러 단에서 일어날 수도 있고 실제 개발자들이 하나의 특성을 고려해서 짤 수 있도록 충분한 그런 밑에 있는 디테일들이 노출되는 그런 단계에 있어서는 저희가 이 프로그램 모델이라고 하는 것들을 제공을 해서 그런 모델을 통해서 개발자들이 하드웨어 특성을 잘 고려해서 짤 수 있도록 제공을 할 수도 있죠. 이런 관점에서 저희가 오늘은 레이턴시 하이딩이라고 하는 그런 측면에서 좀 다뤄보려고 하는데요 제가 슬라이드를 하나 까먹고 빼먹고 안 넣었나 싶기는 한데 한 가지 제가 이제 이야기를 추가를 하고 싶은 거는 그런데 이제 이런 애스트랙션 레이어가 왜 이렇게 많이 생기고 특히나 밑에 있는 하드웨어 딴에도

Attendees 1 05:35 이제 저희가 이제 보통 프로세서를 생각을 하면은 인스트럭션 셋 아키텍처라고 하는 걸로 이제 소프트웨어에 노출이 되게 되어 있는데 그것뿐만이 아니라 그 밑에 이제 데이터 페스와 인스트럭션 센 아키텍처가 왜 분리가 되어 있나라고 생각을 할 수가 있는데 이제 프로세서라고 하는 게 만들어진 지가 꽤 오래됐는데 특히 이제 무어의 법칙이라고 하는 것들이 계속 동작하던 그런 시절에는 트랜지스터 숫자가 뭐 18개월마다 2배씩 늘어났잖아요 결국에 그렇게 두 배씩 늘어나는 트랜지스터를 가지고 할 수 있는 여러 가지 일들이 있는데 결국에는 컴포넌트들이 더 많아져서 프로세서로 프로세서를 가지고 더 많은 일들을 처리를 하도록 이제 하드웨어들이 계속해서 이제 복잡해지고 커지게 되죠. 그렇게 복잡하고 커지게 되면서 데이터 베이스라고 하는 것들이 점점 더 복잡해지는데 거기에 있는 모든 디테일들을 다 소프트웨어한테 노출을 시키는 거는 그거는 너무 많은 양의 디테일들이 노출이 되게 되니까

Attendees 1 06:30 이제 그런 하드웨어 디테일과 그다음에 제 실제 그거를 소프트웨어들이 어떻게 활용을 하느냐라고 하는 그런 단계가 분리가 되기 시작했고 이 밑에 있는 컨트롤 로직과 데이터베이스를 합쳐서 저는 마이크로 아키텍처라고 부르고 있습니다. 마이크 아키텍처라고 하는 단어는 컴퓨터 아키스트나 아니면은 컴파일러를 하신 분들한테는 굉장히 친숙할 텐데 그 외에 이제 저 앱피섹션 상위에 있는 애플리케이션 단에서 일을 하시는 분들한테는 약간 생소한 개념일 수도 있긴 하지만 그런 인스트럭션 아키텍처 밑에 있는 그런 하드웨어 디테일들을 마이크로 아키텍처라고 생각을 하시면 됩니다.

Attendees 1 07:08 네 오늘은 그런 다양한 하드웨어들을 레이턴시 하이딩이라고 하는 측면에서 비교를 해볼 텐데요 저희가 결국 이제 비교를 하고 싶은 거는 MPU가 어떻게 GPU GPU와 다르냐라고 하는 그런 부분인데 서서히 이제 빌드업을 하기 위해서 이 레이턴시 하이딩이라고 하는 측면에서 있었던 그런 중요한 그런 아키텍처들을 한번 바라보고 서서히 이제 저희가 빌드업을 해보도록 하겠습니다.

Attendees 1 07:37 아마 다 아시겠지만은 잠깐 먼저 간단한 개념부터 정리를 하고 이제 넘어가면 레이턴시라고 하는 일은 하는 거는 어떤 일을 하는 데 걸리는 시간을 이제 레이턴시라고 할 수가 있고요. 그다음에트put이라고 하는 거는 실제로 어떤 일들이 얼마나 빠른 위로 빠른 속도로 처리가 되느냐라고 하는 단위라고 생각을 할 수가 있습니다. 보통 레이턴시가 짧으면 그러니까 하나의 테스크를 처리하는 데 걸리는 시간이 짧으면 당연히 뚝뚝 늘어나게 되어 있겠죠 그렇긴 하지만은 꼭 그렇지 않은 경우들도 있거든요. 지금 제가 이제 그림을 대충 이렇게 들여놨는데 맨 위에 있는 거는 실제 한 번에 하나의 테스크 밖에 처리를 할 수 없는 그런 상황이고요. 그런 경우에는 어떤 하나의 테스크를 처리하는 데 걸리는 시간이 그대로 트프에 직접적으로 영향을 주게 되겠죠. 하지만 저희가 여러 개의 테스크를 동시에 처리를 할 수 있다 어 라고 한다면은

Attendees 1 08:33 그런 테스크들을 얼마나 빠르게 새롭게 시작을 하느냐라고 하는 것들이 트을 결정을 하게 되고요. 물론 이렇게 여러 개의 테스크를 많이 동시에 처리할 수 있다라고 하는 거는 그 테스크 간에 디펜던스가 없어서 한 테스크가 다 끝나기 전에 다른 테스크를 시작을 할 수 있는 그런 상황을 가정할 수가 있겠죠. 이래서 레이턴시랑 트루풋이라고 하는 게 연관 관계가 있는 경우도 있긴 하지만은 또 꼭 그렇지 않은 그런 경우들도 발생을 하게 됩니다.

Attendees 1 09:03 이제는 이런 풋 레이턴시 트루풋 그다음에 레이턴시 하이딩 관련돼서 저희가 특히나 레이턴시 하이딩을 통해서 트루풋을 올릴 수 있는 여러 마이크로 아키텍처 기법들에 대해서 살펴보도록 하겠습니다. 제가 이게 잘못 들어와 있었군요. 네 이거 제가 맨 앞에 넣어놓는다고 해놓고 뒷부분에 넣어놨는데요 이 이야기는 제가 아까 한 이야기여서 이제 스킵은 하도록 하겠습니다. 일단 첫 번째로 인스트럭션 수준에서 어떻게 레이턴시 하이딩이 이루어지는가라고 하는 것부터 먼저 간단하게 다룰 텐데요 이 부분들은 아마 많은 분들이 알고 계시겠지만 저희가 스토리를 이제 빌드업하기 위해서 이 부분부터 좀 시작을 먼저 해볼게요. 컴퓨터 프로그램이 실제 프로세스에서 이제 수행이 되는 거는 인스트럭션들이 쭉 수행이 된다라고 생각을 할 수가 있고 그 하나의 인스트럭션들이 이제 수행되는 시간이 레이턴시라고 할 수가 있겠죠.

Attendees 1 09:57 인스트럭션들이 수용되는 그 시간이라고 하는 거는 모든 인스트럭션들마다 다 똑같을 수 있지만은 다를 수도 있는 거고 한 사이클에 끝날 수도 있지만 또 여러 사이클이 걸릴 수도 있는 거고 또 굉장히 길게 걸리는 그런 경우들도 있습니다. 인스트럭션 레벨의 파이프라인이라고 하는 거는 대표적으로 저희 이제 교과서에서 배웠던 그 대표적인 리스크인 맵스에서 도입이 된 이런 스테이지들로 나눠서 구성을 하는 게 가장 보편적인 방법인데 이제 인스트럭션이라고 하는 거는 어떤 프로그램이 인스럭션도 일종의 프로그램이라고 할 수가 있고요. 그 프로그램이 실제 이제 프로세스에서 수행이 되기 위해서는 보통 여러 가지 단계를 거치는데 일단은 인스트럭션 메모리에서 인스트럭션을 이제 뽑아오는 인스트럭션 패치라고 하는 단계가 있고 그 뽑아온 인스트럭션을 디코드를 해서 실제 하드웨어에서 돌리도록 하는 디테일들을 파악을 하는 그런 단계가 있고

Attendees 1 10:51 그 파악된 제를 가지고 실제 연산을 수행하는 엑스큐션 단계 그리고 필요하면 메모리 접근을 하는 메모리 단계 그리고 최종 결과를 메스터에 다시 쓰는 라이트 백 단계 이렇게 이제 다섯 개의 단계로 그 보통 맨 처음에 만든 그런 리스크 파이프라인 아키텍처는 이렇게 다섯 개의 단계로 나눠져 있었고 여기에서 이론적으로는 만약에 이런 인스트럭션들 사이에 depend던y가 없다라고 한다면 매 사이클마다 새로운 인스트럭션을 패치를 해서 수행을 할 수가 있겠죠 그런 경우에는 전체 인스트럭션 레이턴시는 길다 하더라도 이 하나의 파이프라인 스테이지 만 처리를 하면 또 다음 인스트럭션을 수행할 수 있기 때문에 이런 경우에는 5배의 트루풋을 늘리는 그런 효과를 볼 수가 있을 겁니다. 여기에서 한 가지 이제 재미있는 개념이 그런 인스적션이 디코드가 된다라고 하는 그런 개념인데

Attendees 1 11:43 디코드를 하는 방법들도 여러 가지가 있거든요 그니까 인코드를 하는 방법이 여러 가지 있으니까 가 디코드가 되는 방법도 여러 가지가 있겠죠 크게 보면은 버티컬하게 돼 있냐 아니면은 호라이젠틀하게 돼 있냐라고 이제 나눠볼 수 있는데 프라이진트를 한 경우에는 제가 나중에 설명을 드리도록 하고 먼저 이 버티컬 한 경우를 말씀을 드리면 보통 저희가 생각하는 리스크나 시스크 인스트럭션 셋이 다 어떻게 보면은 이제 다 버티컬하게 인코딩이 돼 있다고 생각을 할 수가 있어요. 각각의 빛들이 하는 역할들이 실제 하드웨어에서 하는 역할들이 인스트럭션 단계에서 다 노출이 되어 있는 게 아니라 그런 것들이 실제 맨 위에 있는 단계에서는 중첩이 되어 있고 그런 중첩이 되어 있는 것들을 디코드를 해서 풀어 헤치면 그러면 실제 데이터 유닛들을 컨트롤하는 진짜 시그널로 펼쳐지게 되는 이런 것들을 저희가 보통 버티컬 인코딩이라고 이야기를 할 수가 있어요. 이게 지금 제가 말한 이런 파이프라인과 어떻게 연결이 되냐면

Attendees 1 12:39 저희가 실제 예를 들어서 리스크 인스트럭션인 애드를 한다라고 하면은 그 애드 단계에는 뭐 레지스터가 어떤 것들이 쓰이고 그다음에 에드가 되고 결과가 어디에 들어가는가 정도만 쓰이게 되는데 그렇다고 해서 그런 것들이 패치 단계 그다음에 디코드 단계, 엑션 단계, 메모리 right 단계 다음 right백 단계로 다 분리가 돼서 다른 필드에 들어있는 게 아니라 이제 더 컴팩트한 그런 포맷으로 인코드가 되게 돼 있거든요. 그 인스트럭션 표현을 하는 그런 빛 자체를 줄여서 인스트럭션 메모리 사이즈를 줄이기 위해서 이제 그런 식으로 표현이 되는데 보통 저희가 생각하는 모든 그런 아키텍처가 다 이런 식으로 버티컬하게 인코드가 돼 있다라고 생각을 할 수가 있습니다. 이거를 실제 아까 제가 말씀드린 그런 파이프라인드 아키텍처를 쭉 펼쳐서 그어보면 조금 더 명확하게 알 수가 있는데

Attendees 1 13:28 이게 이제 아까 말씀드린 그런 스테이지들이 이렇게 다섯 개로 분리가 돼 있는 거고요. 인스트럭션 메모리에서 제 인스트럭션을 들고 오면은 맨 처음에 있는 이 커다란 바가 어떻게 보면 디코딩을 하면서 이제 전개가 되는 그런 과정이고요 혹시 네 이렇게 보이죠 네 요 부분이 결국에는 이제 인스트럭션이 디코드가 되는 단계고 그 디코드가 돼서 여기 보면은 들어와서 이제 여러 개의 시그널로 이렇게 이제 분기가 되죠 이렇게 분기가 된 시그널들이 어떤 것들은 레지스터 파일로 들어가서 레지스터를 읽는 그런 효과도 내고 어떤 것들은 그 다음 스테이지로 또 전달이 돼서 그 다음 스테이지에 들어가는 인풋들로 들어간다든지 아니면 이런 ALU 같은 것들을 컨트롤 한다든지 또 어떤 것들은 그다음 스테이지에 가서 또 영향을 미치고 또 어떤 것들은 실제 이런 스 스테이지들에서 각각 어떤 다른 일들이 일어나야 되는가라고 하는 걸 컨트롤 하기도 하고

Attendees 1 14:27 아무튼 이런 전체적인 그런 과정들이 결국에는 저희가 뽑아온 인스트럭션과 그 상태에 있는 이 파이프라인에 있는 그 상태들의 결합으로 조합으로 해서 만들어지게 되죠. 이런 과정들이 소프트웨어로는 보이지는 않죠 이렇게 마이크로 아키텍처가 이렇게 생겼다라고 하는 것들을 저희가 인스트럭션 셋만 가지고는 알 수가 없고 그것들이 실제로 디코드가 돼서 펼쳐지게 되면 이런 하드웨어를 컨트롤하는 그런 시그널들로 전환이 됩니다. 이런 측면에서 이런 파이프라인드 아키텍처의 디테일들이 이렇게 소프트웨어에 노출이 되는 건 아니고 이거는 실제 하드웨어가 밑에서 자체적으로 처리를 하는 그런 최적화라고 생각을 할 수가 있죠.

Attendees 1 15:08 넘어가도록 하겠습니다. 네 혹시 이렇게 파이프라인드 아키텍처를 만들었을 때 항상 그러면은 이런 파이프라인 아키텍처가 그런 이상적인 성능을 보이느냐 그거는 경우마다 다른데요. 혹시 버블 내지는 파이프라인 스토리라고 하는 표현을 들으셨는지 모르겠는데 이제 그런 게 발생을 하게 되면 그 상태에서는 저희가 파이프라인을 채우지 못해서 사이클을 잃어버리게 되거든요 그게 발생할 수 있는 경우가 여러 가지가 있는데 그중에서 레지스터 들 간에 있는 간섭에 의해서 생기는 그런 헤저드가 있을 수 있는데 이런 경우 이런 경우에 제가 지금 여기 이제 보여드린 교과서에 나오는 간단한 파이프라는 아키텍처 같은 경우에는 바이패스 로직이라고 하는 것을 이용을 해서 아직 레지스터 파일에 저장되지 않은 데이터를 뒤에 있는 스테이지로 포드를 곧바로 이제 하도록 해가지고 그런 버브를

Attendees 1 16:07 없앨 수가 있습니다. 이런 측면에서 데이터 헤저드가 발생을 할 수 있는 상황인데 이것들을 더 복잡한 로직을 사용을 해서 해결을 했다라고 생각을 할 수가 있고요.

Attendees 1 16:24 항상 그런 건 아니고요. 브랜치 같은 경우가 특히 이제 대표적인 예인데 이 브랜치 같은 경우에는 왜 문제가 되냐면은 이 파이프라인의 맨 처음 시작 단계가 인스트럭션 패치고 인스트럭션 패치를 하기 위해서는 어떤 인스트럭션 메모리 상의 어떤 위치에 인스럽션이 있는지 저희가 이제 알아야지만이 패치를 할 수가 있는데 이제 그게 브랜치가 있게 되면은 결정을 하기가 어렵죠. 그래서 그걸 이제 브랜치가 실제 주소 내지는 컨디션이 해결이 될 때까지는 패치를 못하게 되죠. 그래서 생기는 그런 레이턴스가 있는데 그 레이턴시스는 완벽하게 하이딩을 할 수가 없어요. 왜냐하면은 스테이지가 많이 떨어져 있고 실제로 그 값이 발생하는 데까지 걸리는 시간이 굉장히 사이클이 걸리기 때문에 그런 경우에는 어쩔 수 없이 스톨이 생길 수밖에 없습니다.

Attendees 1 17:16 그걸 해결하기 위한 방법 중에 하나로 이제 믹스 같은 그런 아키텍처에서는 브랜치 딜레이 슬라이라고 하는 거를 넣고요 이제 브랜치 딜레이 슬렛에 들어있는 인스트럭션은 그 브랜치가 테이크를 하던지 그다음에 테이크를 하지 않던지 무조건 수행이 되도록 해놨죠 어떻게 보면 네 실제 저희가 그냥 프로그램 시퀀스를 하이레벨 프로그램 랭귀지에서 짰을 때는 그런 일은 없죠. 그냥 브랜치가 테이크를 하면 하는 거고 안 하면 안 하는 거지 그게 일단은 한 사이클을 기다렸다가 뭔가 수행을 하는 거를 저희가 하이 레벨 프로그램 랭귀지에서는 상상할 수 없는데 이제 이 믹스 아키텍처를 만든 사람들은 이런 브랜치 딜레이가 남는 것들을 저희가 회피를 하기 위해서 이제 프로그램 시멘틱을 그러니까 인스트럭션 아키텍처에 시멘틱을 바꿔서 브랜치가 taking이 되든 되지 않든 무조건 수용이 되는 인석션을 브랜치 다음에 넣어놓도록 해서 이제 그 버브를 없애는 그런 방법을 택하긴 했습니다.

Attendees 1 18:13 근데 이게 일단 약간 좀 복잡하기도 하고요 특히나 에샘블리 코딩을 한다라고 생각하면은 좀 복잡하기도 하고 그리고 컴파일러가 이런 딜레이 슬렛에 넣을 수 있는 인스트럭션을 못 찾는 경우들도 있고 특히나 파이프라인 데스가 늘어나서 브랜치 딜레이가 늘어나면 그런 것들을 다 이렇게 딜레이 슬랍 맛으로 해결하기에는 굉장히 어색한 그런 부분들이 있기 때문에 지금은 거의 쓰이지 않는 그런 기법이라고 생각을 할 수가 있습니다. 혹시 지금 단계에서 컴퓨터 아키텍처 수업을 처음 들어보지 않으신 분들은 약간 따라오기 어려울 수도 있을 것 같긴 한데 이런 브렌치의 레이턴이딩이 이런 브랜치 딜레이 슬러에 의해서 어떻게 해결되는지에 대해서 혹시 추가 설명이나 궁금하신 게 있는 분 계신가요? 네 그럼 다 잘 이해를 하셨다고 생각하고 넘어가도록 하겠습니다. 지금까지 저희가 어떻게 보면 이제 두 가지의 개념을 설명을 했는데요. 하나는

Attendees 1 19:11 인스uct션이 가지고 있는 레이턴시 자체를 이제 스테이지를 나눠서 한 스테이지가 끝나면 다음 번 인스석션을 수행을 할 수 있도록 파이프라이닝을 하는 그런 기법에 의해서 전체 인스트럭션을 하이딩을 하는 전체 인스트럭션의 레이턴시에 상당히 많은 부분을 하이딩을 하는 그런 파이프라이닝에 대해서 말씀을 드렸고 그다음에 두 번째는 파이프라이닝을 했을 과정 자체는 지금 수행되고 있는 인스트럭션이 그다음 인스트럭션이 수행되는 데 영향을 미치지 않아야지만이 이제 파이프라인이 가능한데 그게 이제 완벽하게 하이딩이 되지 않은 그런 경우가 발생을 할 수가 있고 그의 대표적인 경우가 브랜트라고 말씀을 드렸고 그럼 브랜치의 레이턴시를 그래도 최대한 잘 하이딩을 하기 위해서 믹스라고 하는 그런 아키텍처에서는 브랜치 블레이 슬라이라고 하는 기법을 써서 하이딩을 해보려고 했다라고 지금까지 설명을 드렸습니다.

Attendees 1 20:03 네 지금부터 계속 말씀드릴 거는 이렇게 어떻게 마이크로 아키텍처적으로 이렇게 발생할 수 있는 그런 레이턴시들을 하이딩을 해 나가는가라고 하는 것들을 쭉 이제 하나하나 제가 조금 더 설명을 해 드리려고 해요. 브랜치라고 하는 게 생각보다 굉장히 빈번하거든요 저희가 보통 인스럭션을 한 6번에서 7번 정도 수행을 하면 그중에 하나는 이런 브랜치가 이제 껴 있을 정도로 브랜치라고 하는 게 실제 저희가 인티저 프로그램이라고 불리는 예를 들어서 워드라든지 웹 브라우저라든지 하는 이런 인티저 프로그램에서는 브랜치가 굉장히 빈번하게 일어나는데 그런 브랜치가 있을 때마다 이런 레이턴시가 그대로 다 노출이 돼서 버블이 생기게 되면 당연히 성능이 문제가 발생을 하겠죠. 그래서 그걸 해결하기 위해서 가장 보편적으로 많이 쓰이고 있는 굉장히 유명한 장치가 브랜치 프레딕션이라고 하는 장치가 있어요.

Attendees 1 20:58 브랜치 프로젝션이라고 하는 게 프로젝트를 하는 거는 어떤 브랜치가 테이크를 할 건지 아니면 테이크를 하지 않을 건지라고 하는 걸 이 프로젝트를 하는 건데 브랜치의 어드레스라고 하는 것들도 사실은 굉장히 중요하거든요. 인스트럭션 패치가 있고 그다음에 인스트럭션 디코드가 있는데 내가 그다음에 뛸 그 브랜치의 어드레스가 어딘가 라고 하는 거는 적어도 인스트럭션이 디코드가 돼야지 파악을 할 수가 있어요. 근데 인스트럭션이 디코드가 끝난 다음에 그다음 브랜치를 저희가 이제 할 수 있다라고 한다면 이미 거기에 산 사이클은 먹게 돼 있거든요. 그러니까 브랜치의 그 법을 저희가 최대한 없애기 위해서는 그 법을 없애는 게 중요하고 그 법을 없애는 방법이 뭐냐면 여기 나와 있는 브랜치 타겟 버퍼라고 하는 걸 쓰는 건데 이 브랜치 타겟 버퍼라고 하는 거는 지금 내가 패치한 어드레스가 무엇인가에 따라서 이게 만약에 브랜치를 한다면 어디로 뛸 수 있다라고 하는 값을 캐싱을 해놓는 거예요.

Attendees 1 21:55 브랜치 타겟 버퍼에 만약에 지금 패치가 된 어드레스에 브랜치 타겟이 만약에 들어 있으면 그러면 만약에 브랜치 프로젝터에 의해서 브랜치가 일어날 거다라고 프로젝트가 된다고 한다면 그 주소를 이용해서 거기로 뛸 거라고 예상을 해서 그 주소를 다음 인스트럭션에 저희가 다음 사이클에 이 패치를 할 수가 있겠죠 이런 식으로 브랜치 타겟 버퍼라는 장치와 브랜치 프레릭터라고 하는 장치를 쓰면 그러면 브랜치가 어디를 뜰지라고 하는 것들을 예측을 하고 그 예측이 됐을 때 뜰 주소라고 하는 것들을 캐스팅을 해서 저희가 기다리지 않고 곧바로 예상하는 그런 주소에서 인스석션을 들고 올 수가 있습니다. 이제 플렉션이라고 하는 단어가 의미를 하듯이 이 프로젝션은 항상 언제나 맞지는 않고 브랜치 프로젝션이 히트를 할 수도 있고 이제 미스를 할 수도 있죠. 그 경우에 따라서 미스를 했을 때에는 그냥 지금까지 했던 일들을 버리고 그냥 다시 다른 어드레스로 패치를 해서 시작을 하면 그럼 되는 경우도 있고

Attendees 1 23:00 아니면 그 사이에 뭔가 많은 작업들이 이루어질 수 있는 그런 프로세스라고 한다면은 이제 그걸 리커버하는 그런 과정들도 표현할 수도 있습니다. 어쨌든 이런 식으로 아직 완벽하게 답이 뭔지 브랜치가 있을지 없을지 라고 하는 것들을 알지 못하지만 일단은 확률이 더 높은 쪽을 선택을 해서 쭉 수행을 나가는 거를 컴퓨터 아키텍처에서는 이제 스페큘레이션 스페큘레티브 엑스큐션이라고 부릅니다. 네 혹시 브랜드 프로젝션에 대해서 더 추가 설명이 필요하신 분 계신가요? 네 있으면 넘어가도록 하겠습니다. 지금까지 제가 이제 말씀을 드린 거는 그런 인스덕션 레벨에서 이제 파이프라인이 어떻게 이루어지느냐라고 하는 간단한 것들을 말씀드렸고요 파이프라이닝이라고 하는 게 말씀드렸고 근데 이제 파이프라인이 완벽하지 않기 때문에 버블이 생길 수 있고 하지만 그런 버블을

Attendees 1 23:50 최대한 줄일 수 있는 그런 장치들에 대해서 말씀드렸고 이제 레지스터들 값을 같은 경우에는 바이패스 로직이라고 하는 것들로 어느 정도 해결을 할 수 있다. 브랜치라고 하는 경우에는 딜레이 슬래시라고 하는 것도 있긴 하지만 지금은 보편적으로는 프로젝션이라고 하는 기술을 써서 거기서 발생하는 딜레이들은 최대한 스페큘레티브하게 하이딩을 하려고 한다라고 하는 말씀을 드렸어요. 이렇게 인스트럭션 수준에서의 파이프라인도 생각을 할 수가 있긴 하지만 또 이제 그것보다 상위 수준으로 점점 더 지금 올라가 보려고 하거든요. 프로그램 수행에 있어서 가장 성능을 높이는 데 중요한 것들은 반복돼서 일어나는 루이라고 할 수가 있고요. 까 보통 저희가 프로그램을 수행을 하면은 뭐 몇 분만 사이클이 아니라 엄청나게 많은 사이클 동안 이 프로그램들이 수행이 되잖아요. 근데 이게 만약에 반복되는 코드가 없다라고 한다면은 그러면은 엄청나게 많은 양의 코드가 필요

Attendees 1 24:45 근데 그렇게 많은 양의 코드를 보통 짜지 않고 대부분의 시간은 똑같은 코드를 반복해서 수행을 하는데 프로그램 프로세서가 대부분의 시간을 쓴다고 볼 수 있고 그 대표적인 경우가 룹이고요. 그런 면에 있어서 룩들을 얼마나 빠르게 가속을 할 수 있냐라고 하는 것들이 당연히 굉장히 중요하다고 생각을 할 수 있습니다. 이런 룹의 가속이라고 하는 측면에서 또 어떤 장치들이 고안이 됐나라고 하는 것들을 두 가지 경우로 나눠서 말씀을 드리도록 하겠습니다. 말씀드린 것처럼 이제 루이라고 하는 거를 이제 빨리 돌리는 게 굉장히 중요하다라고 하는 걸 말씀을 드렸고요. 은 실제 이제 이거 같은 경우에는 저 BLT라고 하는 게 컨디셔널 브랜치라고 생각을 한다면 여기 있는 BLT라고 하는 게 이제 컨디셔널 브랜치라고 생각을 한다면 이 룹은 순차적으로 수행을 하고 이 컨디셔널 브랜치가 해결이 돼야지만이 그다음 이터레이션을 둘 수 있기 때문에

Attendees 1 25:38 기본적으로는 순차적으로 수행할 수밖에 없는 그런 누비라고 생각을 할 수가 있습니다. 그런데 이 룹을 만약에 저희가 인스적션 수준에서 파이프라이닝을 했듯이 이 수준에서도 만약에 저희가 이렇게 파이프라이닝을 할 수가 있다면 그러니까 레이턴시를 하이딩을 할 수 있다면 그러면 이제 이런 룩들도 이제 가속이 가능하겠죠 이런 것들이 언제 가능하냐면 이런 루들 간의 depend던스가 굉장히 약해서 룹의 이터레이션이 끝나기 전에 그 이터레이션을 현실적으로는 수행을 할 수 있다라고 한다면은 충분히 가능한 이야기가 되겠죠. 저희가 짜는 많은 룩들이 사실은 그런 특성을 가지고 있어서 이렇게 성능을 뽑아낼 수 있는 그런 여지가 충분히 있는 그런 룩들이긴 합니다. 그런데 그게 그렇게 쉽지만은 않아요. 아까도 제가 맨 처음에 보여드린 예제 자체에서도 여기 있는 컨디셔널 브랜치가 해결이 돼야지만이 그다음 인터레이션을 이제 수행을 할 수 있다라고 말씀드렸는데

Attendees 1 26:35 이런 컨트롤 플로라고 하는 게 있고 특히나 이제 루에 베이스라고 보통 컴파일러에서는 표현을 하는데 이런 백의 주의가 해결되지 않은 상태에서는 이제 원래 이 원칙적으로는 그 다음 인터레이션을 수용할 수 없는 게 하나가 있고 두 번째는 그 다른 이터레이션의 인스uct션 사이에 있는 폴스 depend던c라고 생각을 할 수가 있어요. 특히나 이제 레지스터 숫자가 제한이 되어 있고 이런 파이프라인이라고 하는 걸 생각을 하지 않고 그냥 이렇게 룩을 한다고 한다면은 그럼 똑같은 레지스터에 읽고 쓰고 하는 것들 사이에는 이런 depend던스가 생길 수밖에 없거든요. 그러니까트로 depend던스라고 보통 컴파일러나 아키텍처를 하는 사람들이 부르는 거는 실제로 값이 계산이 되고 그것들이 쓰이는 그 사이에 있는 관계는 그 값이 정말로 계산이 돼야 되기 때문에 정말 또 디펜던스가 있다라고 생각을 할 수가 있고요. 그게 아니라 그 값을 저장해 놓은 장치가 하필이면 겹쳐서 생기는 그런 디펜던스를

Attendees 1 27:29 이제 포스 depend던스라고 보통 이제 불러요. 그러니까 포스 depend스 부르는 이유는 만약에 더 많은 저장 공간이 있어서 그 값을 똑같은 저장 공간을 쓰지 않고 했다고 한다면은 그러면 그 계산들 사이에는 디펜던스가 없기 때문에 중첩이 이제 해결이 될 수 있다라고 하는 측면에서 이제 포스 디펜던스라고 부릅니다. 정확하게 이런 같은 경우에는 이터레이션끼리 실제 계산상으로 봤을 때 디펜드할 수가 없긴 하지만 쓰고 있는 스토리지 자체가 겹치기 때문에 빠르게 수용을 할 수 없는 그런 일들이 발생할 수도 있죠. 용주 님께서 루에서 에드와이 할 때랑 sl II AI가 동시에 s1을 s를 해도 괜찮을까요? 이게 제가 사실 이 예제는 이런 파이프라이닝이 잘 되는 예재를 그냥 찾은 건 아니고

Attendees 1 28:18 이걸 제가 그냥 그리고 싶지가 않아 가지고 인터넷에 아무 룸이나 찾아서 넣어놓은 거거든요. 그래서 지금 정확하게 제가 이 룹이 어떻게 동작하는지는 모르겠지만은 중첩이 가능한 룹인지 아닌지는 나중에 잘 모르겠습니다. 이 부분에 대해서는 그래서 제가 지금 대답을 해 드리긴 어려울 것 같아요. 죄송한데 이 질문은 저도 이 코드를 잘 모르기 때문에 스크 하도록 할게요. 하지만 개념적으로 봤을 때 어쨌든 제가 말씀드리는 거는 레지스터가 이제 제한이 되어 있기 때문에 어쩔 수 없이 그 똑같은 레지스터가 다른 목적으로 쓰이게 되는 거고 다른 목적으로 이제 쓰이게 되는 거고 그거 이제 대표적인 예가 루들이 있을 때 이터레이션 간에 실제로 완벽하게 다른 계산이다 할지라도 그게 똑같은 레지스터들을 쓰기 때문에 계산이 등톱되는 것 같은 그런 포스 dependence가 발생을 하게 돼 있다라고 하는 거죠.

Attendees 1 29:13 해결책은 컨트롤 플로 같은 경우에는 제가 인스덕션 레벨 파이프라이닝에서 말씀드렸던 브랜치 프로덕션으로 이제 해결을 하면 되고요. 그다음에 이런 for dependence 같은 경우에는 레지스터를 re네이밍을 함으로써 해결을 할 수가 있는데 이 문제는 시 시셜 시멘틱을 가정하고 있는 그 일반적인 프로세스 같은 경우에는 하드 소프트웨어적으로는 이런 룩을 네임을 할 수 있는 이터레이션마다 다른 레지스터를 쓰도록 하는 그런 방법 자체를 만들고 있진 않죠 네 그래서 이론적으로는 저희가 중첩을 할 수 있긴 하지만 이걸 소프트웨어적으로는 사실은 중첩을 시한 시멘틱을 가지고 있는 그런 프로세스에서는 표현하는 거는 불가능하다고 생각을 할 수가 있습니다. 하지만 이제 하드웨어적으로는 얼마든지 가능해요. 이제 하드웨어적으로는 실제 하드웨어들이 그런 아키텍처적인 레지스터가 아니라 실제 피지컬한 레지스터를 아키텍처적인 레지스터보다 훨씬 더 많이 가지고 있고

Attendees 1 30:09 실제 계산이 올 때마다 그런 로지컬한 아키텍처적인 레지스터를 다 다른 레지스터들에 매핑을 하고 그 대신에 그걸 사용하는 그런 레지스터들이 잘 어사이드 되어 있는 그런 피지컬 레지스터를 선택을 해서 값을 읽어 올 수 있도록 저희가 트레킹을 할 수 있다고 한다면은 실제 아키텍처 적으로 노출이 되어 있는 레지스터보다 훨씬 더 많은 그런 피지컬 레지스터를 쓸 수가 있죠. 네 이제 그런 개념들을 사용해서 이제 리네이밍을 하는 것들도 가능하고 거기에 이제 브랜치 프레릭션이라고 하는 것들도 가능 이제 같이 넣어놓으면 결과적으로는 이런 원래 들어있던 시퀀셜한 코드를 리네이밍 그다음에 브랜치를 없애면서 이런 오른쪽에 있는 실제 순수하게 계산이 표현되어 있는 그래프로 전환을 할 수가 있어요.

Attendees 1 30:56 그렇게 되면 이런 경우에는 실제 시퀀셜하게 인스트럭션을 수행을 하는 게 아니라 디펜던스가 해결되어 있는 모든 인스럭션들은 다 한꺼번에 수용을 할 수 있기 때문에 패러럴 프로세싱이 가능해진다고 생각을 할 수가 있습니다. 혹시 이 그림에 대해서 더 설명이 필요하신 분 계실까요? 데이터 플로 그래프라고 하는 개념에 대해서 다들 익숙하신가요?

Attendees 1 31:21 넘어가도록 하겠습니다. 어쨌든 아까 말씀드린 것처럼 이제 시퀀셜 코드라 할지라도 그것들을 실제 하드웨어가 수행을 할 때에는 그것보다 더 많은 레지스터를 가지고 있고 내가 쓸 레지스터가 뭐다라고 하는 것들을 계속해서 미네이링을 하면서 트래킹을 해서 실행을 하기 전에 다른 레지스터를 쓰도록 저희가 처리를 해놓고 실제 수행 자체는 그래프 같은 이런 형태로 콘셉트얼하게 생략을 해서 병렬로 아웃오브 오더를 수행할 수 있도록 저희가 충분히 만들 수가 있습니다. 이런 것들을 아웃오브 프로세서라고 하고요. 실제 이제 펜티엄이라든지 지금 저희가 사용하는 대부분의 CPU들이 다 이런 아우더보드 프로세서를 기법을 사용을 하고 있다라고 생각을 하시면 됩니다. 이렇게 되면 결과적으로 어떤 일이 생기냐면 루 레벨에서의 파이프라인이 만들어지게 되는데요. 그러니까 예를 들어서 저희가 첫 번째 이터레이션과

Attendees 1 32:14 두 번째 이터레이션 세 번째 이터레이션을 매 두 사이클마다 수행을 할 수 있다라고 한다면은 그러면 제가 이렇게 오랜색으로 표현을 해 본 그런 부분들이 매 사이클마다 반복되는 것처럼 보이거든요 근데 반복되는데 그게 여기에서 보면은 이 부분이 첫 번째 스테이지에 해당하는 거고요 파이프라인에 그다음에 요 부분이 파이프라인의 두 번째 스테이지에 해당을 하는 거고 그다음에 이 부분은 세 번째 스테이지에 해당을 하는 거고 아까 저희가 봤던 그런 인스트럭션 레벨의 파이프라인에서 보이는 것과 그런 굉장히 비슷한 그런 파이프라인 스테이지가 루 레벨에서 형성이 돼서 반복해서 수행이 되는 그런 형태의 패턴을 저희가 볼 수가 있습니다. 여기에서 이제 진부 님께서 하드웨어에서 데이터 플로 그래프 자료 구조를 유지를 하는 건가요? 네 그렇죠. 이게 이제 아도보드 프로세서를 보면은 레지스터 리네이밍을 하고 레조베이션 테이블이라고 하는 게 있어서 거기에서 실제로

Attendees 1 33:15 아키텍처 레스터보다 많은 피지컬 레지스터를 유지를 하고 거기에 이제 태깅을 해서 어떠한 인스트럭션이 어떤 피지컬 레지스터의 값을 쓸 건지 그다음에 그 상태에서 다른 인스트럭션들을 패치를 할 때 현재 어떤 아키텍처 레지스터가 어떤 피지컬 레지스터에 매핑이 돼 있냐라고 하는 것들을 그 테이블을 뒤져가지고 그 값을 빼놔서 이제 읽는 레지스터가 악텍트 레지스터에서 피지컬 스이 레지스터로 다시 리네임을 해주도록 돼 있어요. 동쪽으로 그런 그래프를 그런 테이블과 태그를 이용해서 계속해서 만든다라고 생각을 할 수가 있거든요 제 그게 이제 하드웨어적으로 데이터 플로우를 그래를 자료 구조를 한다라고 생각을 할 수가 있습니다. 명령어 윈도우 단위로 데이터 플로 그래프가 유지가 된다고 보면 될까요? 그렇죠 여기서 이제 명령어 이제 윈도우라고 하는 것들이 어떻게 보면은 쭉 수행이 된 인스트럭션들을 이제 스트림으로 생각을 한다면은

Attendees 1 34:07 아직 처리가 되지 않은 내지는 처리가 되고 있는 그런 인스트럭션들을 저희가 명령어 이 윈도우라고 생각을 할 수가 있고 그 명령어 윈도우에 들어있는 인스럭션들에 대해서는 제가 방금 말씀드린 그런 하드웨어적인 자료 구조 장치를 통해서 데이터 플로 그래프를 만들어 놓고 있는 상태라고 생각을 하면 되죠. 그리고 거기에서 실제 인스트럭션들이 수행이 다 돼서 빠져나가게 되면 데이터 플로 그래프에서 그 부분이 지워지게 되는 거고 그 부분을 또 이제 저 새로 들어온 인스트럭션들이 채워서 계속 데이터 플로 그래프가 인스트럭션이 수행이 될 때마다 변한다라고 생각을 하시면 됩니다. 네 좋은 질문입니다. 네 이게 이게 이 파이프라인 된다라고 하는 게 직관적으로 잘 이해가 되실지는 잘 모르겠는데 결과적으로 이런 이터레이션을 이제 중첩을 하게 되면 아까 저희가 인스트럭션 레벨 패럴리즘 인스트럭션 레벨 파이프라인에서 봤던 그런 스테이지가 있는 것처럼 결국에 룹이 이제 여러 개의 스테이지로 쪼개지게 되고

Attendees 1 35:07 다른 스테이지에 있는 여러 룩들이 동시에 수행이 되는 그런 형태가 되는 거고 거기에서 실제로 반복되는 부분들만 딱 잘라보면 똑같은 코드가 결국에는 반복해서 수행이 되는 것처럼 보이게 되죠. 아우더보드 프로세스에서 정확하게 이런 일이 일어난다고 볼 수가 없기는 해요. 그러니까 아우더보드 프로세스 같은 경우에는 정확하게 이런 식으로 똑같은 인스트럭션이 매번 이렇게 돈다라고 이해를 할 수가 없긴 하지만은 결과적으로 이제 효과가 이런 직접적인 효과가 개념적으로 난다라고 이해를 하면 됩니다. 이 그림에서 세 번째 루프의 바디만 새 인스트럭션이 밀려서 설명해 드린 의도와 다른 그림처럼 보이는 것 같습니다. 그런가요? 그렇네요. 네 죄송합니다. 네 그림을 제가 조금 잘못 그렸지만 잘 파악을 해 주셔서 감사하고요. 이거는 끝나고 스템을 하도록 할게요. 하지만 네 이 버그를 찾으신 걸로 봐서는 제가 의도하는 건 잘 파악을 하시고 하고 계신 것 같습니다. 네 감사합니다.

Attendees 1 36:10 네 이게 이제 그 인텔의 코어라고 하는 아키텍처의 그림을 인터넷에서 찾아가지고 이제 그려놓은 건데 제 이게 제가 방금 말씀드린 그런 동쪽으로 데이터 프로그래프를 만들어서 수행을 하는 그런 엔진 그다음에 여기 보면 여기에서는 리오도 버퍼 라고 표현이 되어 있는데 그 리오도 버퍼가 아까 제가 말씀드린 그런 레지스터 리네임이 되고 실제 이제 다 다이나믹하게 데이터 플로그래프를 태깅을 하면서 유지를 하는 그런 장치라고 생각을 하시면 됩니다.

Attendees 1 36:48 제가 지금부터 이제 설명을 드릴 거는 이거와 이제 똑같은 효과를 이제 하드웨어가 그런 데이터 플로 그래프를 만들어서 하드웨어적으로 처리를 하는 게 아니라 미리 소프트웨어적으로 처리를 해서 그 결정된 대로 하드웨어가 동작만 하게 되는 그런 방식으로 이 똑같은 방식으로 루페널하게 파이프라인을 만들어서 하는 그런 기법에 대해서 제가 좀 설명을 드리려고 해요. 네 그리고 이게 제가 아까 말씀드릴 나중에 말씀드린 GPU와 MPU의 차이와 저는 굉장히 유사하다라고 생각을 합니다. 예 아까 말씀드린 것처럼 만약에 저희가 룸을 파이프라인 된 형태로 이제 수행을 하고 싶다라고 한다면 그러면 이거를 아까처럼 복잡하게 하드웨어적으로 다이나믹한 그런 데이터 플로 그래프를 만들어서 그걸 또 힙하기 위한 여러 가지 복잡한 장치를 만들어서 하는 게 어떻게 보면 굉장히 복잡한 일인 것 같거든요. 특히나 제가 아직 디테일은 말은 하지 않았지만

Attendees 1 37:47 브랜치 프로덕션이라고 하는 걸 이야기를 하면서 만약에 브랜치가 브랜치 프로덕션이 틀리면 어떤 경우에는 리커버를 해야 된다고 말씀을 드렸잖아요. 그런 경우가 이렇게 어그레시브하게 특히나 그 아까 이제 명령어 윈도우라고 표현을 한 명령어 윈도우도 굉장히 키워가지고 여러 가지 인스트럭션들을 한꺼번에 굉장히 많이 패치를 해서 최대한 어레스브하게 패럴하게 수행을 하겠다라고 하는 그런 경우에는 실제로 브랜치가 리졸브가 되지 않은 상태에서 굉장히 많은 일들을 진행을 해요. 네 그러다가 만약에 브랜치가 내가 프레딕트 한 대로 일어나지 않는다라고 한다면 그런 것들을 다 롤백을 해야 되거든요 네 그런 복잡한 그런 롤백을 하기 위한 그런 장치까지 다 생각을 해서 만들어야 되기 때문에 사실은 이렇게 아웃오브 오더로 데이터 플로우 그래프를 만들어 가지고 수행을 하는 것 자체의 디자인 자체가 굉장히 복잡할 수밖에 없습니다.

Attendees 1 38:40 결국은 이제 의도하는 건 이 룹을 파이프라인 된 형태로 만약에 수행을 하는 효과를 보고 싶다라고 한다면은 그러면 한 가지 다른 얼터너티브는 아키텍처 자체가 이런 파이프라인 된 룹을 잘 인스적션으로 받아들일 수 있도록 되어 있고 이제 소프트웨어적으로 룸을 이렇게 파이프 한다는 형태로 이미 만들어가지고 하드웨어한테 전달을 하고 하드웨어는 아까 제가 말씀드렸던 그런 복잡한 과정을 처리를 하는 게 아니라 이미 소프트웨어가 잘 만들어 놓은 파이프라인을 그대로 수행을 하게 된다고 한다면 그럼 하드어 장치는 훨씬 더 간단하고 엑스큐션 자체도 굉장히 더 효율적일 수도 있긴 하겠죠. 이게 이제 처음부터 룩을 그렇게 만들어서 지금 제가 이제 그려놓은 그림대로 이렇게 쭉 그냥 반복해서 하드웨어는 수행을 하게 된다고 한다면은 훨씬 더 그런 간단한 장치로도 똑같은 효과를 볼 수가 있을 겁니다.

Attendees 1 39:35 그게 이제 VLW라고 하는 아키텍처라고 할 수가 있어요. 그러니까 VLW라고 하는 아키텍처는 아키텍처에서 그림상으로만 본다면은 아도 보드 프로세서가 가지고 있는 거랑 사실 비슷하거든요 이렇게 여러 개의 펑션 유닛들이 병렬로 처리를 할 수 있도록 갖춰져 있고 그리고 그런 값들을 저장을 하고 그다음에 읽고 할 수 있는 그런 장치가 있는데 여기에서 이제 좀 한 가지 특이한 점은 이렇게 펑션 유닛들이 굉장히 많게 되면 그러면 이런 것들이 다 하나의 레지스터 파일에 물리게 되는 게 복잡하거든요. 그러니까 레지스터 파일에는 읽고 쓰는 이런 포트라고 하는 개념들이 있는데 이런 포트 숫자가 많으면 많아질수록 레지스터 파일 의 구조 자체가 굉장히 복잡해지기 때문에 이렇게 펑션 UI 늘어나게 되면 모든 레지스터 모든 그런 펑션 UI 하나의 레지스터 파일에 묶여 있을 수가 없어요. 그래서 결과적으로는 이제 이렇게

Attendees 1 40:28 이렇게파션이 될 수밖에 없다라고 하는 것들 그다음에 파티션이 되어 있는 것들 간에는 레지스터 파일을 통해서 이제 통신을 하는 게 아니라 다른 이런 인터커넥트가 있어서 그런 것들을 통해서 이제 커뮤니케이션을 해야 되는 그런 약간 복잡한 일들이 일어날 수가 있기는 합니다. 어쨌든 이렇게 저희가 패럴 하게 수행할 수 있는 그런 구조를 가지고 있고 그리고 그걸 시퀀셜 프로그래밍을 하는 게 아니라 그냥 익스프리스하게 패럴하게 프로그래밍을 하는 거죠. 아까 제가 이제 그려놓은 그 그림이 좀 어쨌든 약간 틀린 게 있을 수 있긴 하지만은 여기서 보면은 여러 인스트럭션들이 결국에는 동시에 수행이 되는 거거든요 이런 경우에는 하나 둘 세 개의 인스트럭션들이 이제 하나 둘 이 3 개의 인스트럭션들이 수행이 되고 그다음 사이클에는 다른 세계의 인스트럭션들이 수행이 돼서

Attendees 1 41:16 6개로 구성되어 있는 파이프라인이 결국 이제 매번 이렇게 반복되는 그런 형태를 가지고 있는데 여기에서 중요한 건 이렇게 익스프리스하게 인스트럭션 자체가 패러럴 하게 프로그램이 돼 있다라고 하는 거죠. 네 이런 것들을 실제 하드웨어를 컨트롤하기 위한 그런 인스트럭션들이 굉장히 길다라고 해서 베리롱 인스트럭션 워드라고 하는 그런 용어를 사람들이 쓰고 있습니다. 그래서 이제 명시적으로 하드웨어들이 각 사이클에 어떤 일을 해야 되는가라고 하는 것들을 표현을 할 수 있도록 해놓고 이런 것들을 중첩을 시켜서 보면 실제 이 파이프라인 되어 있는 것과 같은 그런 똑같은 효과를 볼 수가 있죠. 이게 이제 호라진탈 인코딩이라고 생각을 할 수가 있는데요. 이제 제가 아까 버티컬 인코딩이랑 그다음에 호라진털 인코딩하고 이제 제가 설명을 드렸는데 그 차이는 뭐냐 하면 버티컬 인코딩은 실제 하드웨어 리들이 해야 되는 그런 일들 자체가 약간 이제 디코딩 인코딩이 돼 있어서 그런 것들을 쭉 펼쳐놔야

Attendees 1 42:12 실질적으로 어떤 데이터 유닛들에 가서 어떤 일을 할까라고 하는 것들이 판별이 되는 그런 인코딩이라고 한다면은 VW 같은 경우에는 실제 펼쳐져 있는 하드웨어들에 맞게 똑같이 인스석션들이 이제 펼쳐져 있는 거죠. 그러니까 실제로 이제 하드웨어들들이 동시에 어떤 다른 일들을 해야 되느냐라고 하는 것들을 다른 부분에 있는 데이터베이스의 다른 부분에 있는 하드웨어들이 그 사이트에 어떤 일을 해야 되는가라고 하는 것들을 명시적으로 다 소프트가 만들어가지고 내놓은 이런 것들을 저희가 이제 호리존탈 인코딩이라고 생각을 할 수가 있습니다. 버티컬 인코딩하고 호레전 인트하고 완전히 분리가 됐다라기보다는 일단은 하이 레벨에서는 호레젠틀하게 이렇게 인코딩이 되어 있어서 병렬로 처리를 하는 것들을 익스프레스하게 표현을 할 수가 있고 하지만 그 각각의 단위에서는 다시 버티컬 인코딩이 돼 있어서 다시 어떤 디코딩의 과정을 통해서 더 복잡한 하드를 컨트롤하는 그런 그런

Attendees 1 43:05 명령어로 다시 이제 분기가 될 수도 있긴 하겠죠. 그래서 이 두 개가 완벽하게 분리가 된다라기보다는 하이러키클하게 쓸 수도 있다라고 생각을 하시면 됩니다. 어쨌든 중요한 차이점은 포레젠터 인코딩에서는 하드웨어 디테일 자체가 그런 이제 소프트웨어한테 그대로 노출이 돼 있어서 그 디테일을 이해를 한 컴파일러 내지는 프로그래머가 명시적으로 거기에 맞도록 코딩을 해 준다라고 하는 게 이 큰 차이가 있는 잡죠 이런 기법들이 만들어진 지는 꽤 오래됐어요. 이게 지금 제가 아까 말씀드린 그런 파이프라인을 만들어내는 그런 가장 대표적인 알고리즘이 이제 모듈러 스케줄링이라고 하는 그런 컴파일러 기법이 있는데 그 모줄로 스케줄링이라고 하는 알고리즘이 사실 굉장히 아름다운 그런 알고리즘인데 그 알고리즘을 밤 라우라고 하시는 분께서 만들었고 그 개념을 처음 만드신 건 1980년대라고 알고 있는데 그런 것들을 잘 정리를 해서

Attendees 1 44:00 논문으로 쓰신 거는 휴럽 패커드 랩에 계실 때 1999년 92년에 이제 발표를 했습니다. 이게 워낙 잘 만들어져 있어서 이런 비슷한 형태의 구조를 가지고 있는 거의 대부분의 아키텍처들이 결국에 이런 모듈러 스케줄이라고 하는 그런 알고리즘을 써서 트 파이프라이닝을 하게 되어 있습니다. 네 이거는 제가 자세히 설명을 드리진 않을 텐데 이제 아까 데이터 플로 그래프를 만들어서 하드웨어적으로 이제 그런 서택트를 만들어 가지고 처리를 하는 그런 복잡한 장치가 있었듯이 그런 비슷한 일들을 이 소프트웨어적으로 컴파일러가 하도록 되어 있고 그걸 하기 위한 그런 여러 가지 콘셉트들을 이분이 디자인을 하셨고 그 자체가 워낙 잘 만들어져 있어서 대부분의 사람들이 이런 틀을 그대로 써서 소프트웨어 파이프라인이라고 하는 알고리즘을 컴파일러로 구현을 하고 있습니다. 이런 VW가 최근에는 리컴프블 프로세서라고도 이제 부르는데요. 이 리컴프블 프로세서라고 이제 부르는 이유는

Attendees 1 44:58 호레젠틀하게 이제 만약에 프로세서가 인코딩이 돼 있다라고 한다면은 그 하드웨어에서 다른 부분들의 디테일들이 이제 프로그램에게 제 노출이 되어 있고 그런 다른 부분들을 컨트롤 하는 것 자체가 어떻게 보면 하드웨어를 리컴퓨어라고 하는 거라고 생각을 할 수가 있어서 VW가 리컨 플러블 아키텍처라고도 불리기도 합니다. 어떻게 보면 굉장히 익스트림하게 더 분산이 되어 있고 더 많은 디테일들이 노출되어 있는 그런 형태의 VW를 리컨 플러블 프로세서라고도 부를 수가 있죠. 그리고 최근 나오는 많은 그런 mfu들이 이런 닉컴 블 아키텍처의 개념에 맞춰가지고 지금 디자인이 되어 오고 있습니다. 사실 이제 제가 지금 룸 레벨에서의 파이프라이닝을 접근을 하는 두 가지 다른 방법을 말씀을 드렸고요. 하나는 아도보보드 프로세서에서 동쪽으로 데이터 플로 그래프를 만들어서

Attendees 1 45:51 결과적으로는 이런 중첩 효과를 만들어내는 그런 장치들에 대해서 말씀을 드렸고 참고로 이제 그 전반적인 과정 자체를 토마슬로라고 하는 분이 1960년대에 처음 디자인을 하셨고요. 그래서 사람들이 지금은 토마스 알고리즘이라고 부르고 있습니다. 이런 아우도 보드 프로세서에서는 하드웨어가 동쪽으로 이런 자연스러운 효과를 아까 말씀드린 토마토 알고리즘이라고 하는 걸 써서 만들어내고 있고 viw에서는 이 소프트웨어가 정적으로 컴파일을 해서 똑같은 효과를 낼 수 있다라고 하는 그런 측면을 말씀을 드렸습니다. 네 혹시 제가 전달하고자 하는 그런 주요 포인트가 잘 전달이 되는지는 잘 모르겠는데요. 어쨌든 루이라고 하는 게 있고 이 반복적으로 수행을 하고 대부분의 프로그램은 이 룹을 수행하는 데 시간을 주기 때문에 이 룹을 잘 빠르게 하는 것들이 굉장히 중요한 목표인 거고 그룹에서도 이터레이션마다의 메이턴스라고 하는 게 있고 그거를 더 빠르게

Attendees 1 46:49 레이턴시를 하이딩을 하기 위해서 이제 파이프라인과 비슷한 그런 효과를 만들어야 되는데 그거를 이제 하드웨어적으로도 만들어낼 수가 있고 그다음에 소프트웨어적으로 만들어낼 수도 있고 이 소프트웨어적으로 만들게 하기 위해서는 하드웨어적으로 그런 파이프라이닝에 쓰이는 재료들을 만들어 놓고 그 재료들을 어떻게 컨트롤할 것인가라고 하는 디테일들은 인스덕션 세에도 노출을 해서 그 노출되어 있는 컨트롤들을 소프트웨어가 컴파일러가 만들어서 그대로 하드웨어가 따라서 실행만 하면 되는 이런 형태로 저희가 소프트웨어적으로도 처리를 할 수 있다라는 말씀을 드렸고요. 그리고 이제 그렇게 됐을 때의 장점은 뭐냐 하면 하드웨어가 훨씬 더 간단해진다는 장점이 있죠 하면 훨씬 더 간단해지고 그다음에 두 번째는 동쪽으로 그걸 처리를 한다라고 생각한다면 동쪽으로 사실 굉장히 많은 다양한 그런 스케줄이라든지 추적할 수 있는 그런 옵션들이 있을 수 있는데 그걸 하드웨어에서 다 고려를 해서

Attendees 1 47:44 만들기에는 굉장히 복잡한 하드웨어를 만들어야 되기도 하고 또 시간도 오래 걸릴 수가 있거든요. 그런 것들을 컴파일 다음에 이제 하게 되면 훨씬 더 다양한 옵션들을 다 고민을 해서 만들 수가 있기 때문에 더 최적화되어 있는 그런 코드를 만들어낼 수 있다라고 하는 것들도 소프트웨어적으로 처리를 했을 때의 장점이라고 생각을 할 수가 있습니다. 그 반대로 이제 단점도 있는데요 특히나 아까 제가 말씀드렸던 일반적인 인티저 프로그램들 브랜치가 굉장히 많은 인티저 프로그램들에서는 굉장히 큰 단점이 있어요. 왜냐하면 아까 이제 제가 브랜치라고 하는 게 매 다섯 여섯 인스트럭션마다 한 번씩 나온다라고 했는데 모듈로 스케줄링 그다음에 루 파이프라이닝이라고 하는 게 굉장히 아름답게 동작을 하기 위해서는

Attendees 1 48:30 사실 브렌치가 루 안에 들어 있으면 그렇게 되지 않거든요. 그 브렌트 안에 있게 되면은 어느 쪽으로 어떤 일들이 일어날지 모르기 때문에 그런 이제 디펜던스 문제가 굉장히 복잡하게 돼서 이런 소프트 파이프라인을 하기가 굉장히 까다로워져요. 또 이제 그런 경우에는 그런 브렌치를 없애기 위해서 프리디케이션이라고 하는 기법을 또 도입을 할 수가 있고 그러면 이제 브랜치들이 없어진 형태의 그런 플랫한 코드가 되고 그 과정에서는 또 저희가 소프트웨어 파이프라이닝을 할 수가 있습니다. 네 뭐 이런 것들 그다음에 캐시가 일어났을 캐시가 캐시 미스가 있을 때는 그럼 어떻게 할 것이냐라고 하는 어떤 그 제가 말씀드리고 싶은 포인트는 인티저 프로그램 같은 경우에는 동쪽으로 저희가 일어나는 이벤트들이 굉장히 다양하게 많기 때문에 그런 동적인 것들을 컴파일 땅에 다 고려를 해서 처리를 하는 게 굉장히 복잡할 수 있거든요.

Attendees 1 49:16 그런 것들 때문에 이런 인저 프로그램 저희가 보통 인체를 프로세스에 돌리는 이런 프로그램 같은 경우에는 동쪽으로 처리를 하는 게 정적으로 컴파일러가 하는 것보다는 훨씬 더 효과적인 것 같긴 합니다. 하지만 모든 그런 이제 소프트웨어들이 다 그런 특징을 가지고 있지 않기 때문에 또 이런 VRW 같은 특징에 잘 맞는 그런 소프트웨어들도 분명히 있고 그런 경우에는 이런 장치들을 쓰는 게 훨씬 더 효율적일 수가 있겠죠. 여기 관경 님께서 질문하신 게 네 GCN이 뭔지는 잘 모르겠는데요. 제가 VLW를 MP의 특성으로 가져오면 컴파일러가 복잡해서 GPU GPU 같은 기능을 구현하기 어렵지 않을까요? 그런 것들에 대해서 조금 말씀을 드리도록 할게요. 네 그리고 이거는 디섹션에서 말씀을 드리면 좋을 것 같고 다문님께서는 VW 프로세서에 동작시킬 소프트웨어를 만들기 위해 지정된 랭이지가 있는지요? 아니면 컴파일러에 의해 지정 가능한지요?

Attendees 1 50:17 이제 제가 아까 말씀드렸던 그런 인티저 프로그램이라고 불리는 보통 인텔 프로세서에서 돌리는 그런 프로그램들 같은 경우에는 이거를 c나 스플플이나 자바나 이런 언어가 아니라 다른 언어로 짜는 건 사실 굉장히 어렵거든요. 그래서 만약에 그런 거를 타겟을 한 v 프로세스를 만든다라고 한다면은 이제 그렇게 작성되어 있는 프로그램들을 처리를 하는 게 굉장히 중요하기 때문에 신나 세플플 같은 랭귀지를 지원을 해야 되고 제 그런 경우에는 시퀀셜하게 짜져 있는 그런 프로그램을 그렇게 이제 패널럴하게 파이프라인을 해서 처리를 할 수 있도록 하는 그런 기법들을 컴파일러적으로 구현을 해야겠죠. 이가 답이 됐는지는 잘 모르겠지만 이 정도로 답을 할 수가 있을 것 같고 정우 님 같은 경우에 VRW 구조에 맞지 않는 코드의 경우에는 버블이 발생하거나 할 수 있을 것 같은데

Attendees 1 51:05 별도로 처리를 해 주는 방법이 없죠 네 왜냐하면 하드웨어적으로 간단하게 만들기 위해서 이제 VW라고 하는 게 도입이 됐는데 그게 이제 실제 소프트웨어적으로 그런 충분하게 병렬성을 찾을 수 없다라고 한다면 그건 화대적으로도 사실 보완을 해 줄 수 있는 방법은 없습니다. 네 그러기 위해서는 프로그램 자체를 다시 짠다든지 아니면 더 고도화되어 있는 컴파일러를 쓴다든지 하는 그런 방법도 있겠죠 제가 아까 말씀드린 것처럼 특히나 이제 룹 같은 경우에 특히나 인스터 프롬 같은 경우에 룹 안에도 이프덴 에스분도 많고 여러 가지 브랜치들이 있는데 이제 그런 경우에도 스케줄이 잘 되기 위해서 페디케이션이라고 하는 그런 기법을 사용을 해가지고 그런 경우에도 법을 만들지 않고 소프트 파이핑을 잘 할 수 있는 그런 하드웨어 장치들이 VW 아키텍처 인제 반영이 되기도 합니다. 네 그런 식으로 처리를 한다고 생각하시면 되는 거고요.

Attendees 1 51:59 tpu나 텐서코어의 시스톨릭 어레이 하드웨어 블랙 프로그래밍의 VW가 유리할 거예요. 시스톨릭 어레이는 VLW와는 또 굉장히 다른 형태라고 생각을 하시면 돼요. 이건 더욱더 극단적으로 어떻게 보면은 프로그래머빌리티 측면에서는 굉장히 제약이 크지만 하드웨어적으로는 굉장히 효율적인 그런 이런 것들은 또 가지고 있는 프로그램 모델이 지금 제가 말씀드렸던 VW와는 또 굉장히 다릅니다.

Attendees 1 52:29 지금까지 인스덕션 레벨에서의 파이프라이닝 그다음에 룸 레벨에서 이제 파이프라인을 이 말씀을 드렸고요. 지금부터 이제 트레드 레벨 파이프라이닝에 대해서 말씀을 드릴 거고 이게 이제 GPU 하고 굉장히 밀접하게 연관되어 있는 그런 부분들입니다. 네 이제 이쪽으로 넘어가기 전에 이제 실제 GPU가 탄생을 했던 시점으로 잠깐 돌아가서 이야기를 하면서 빌드업을 해보려고 하는데요. 저는 이제 대학을 90년대에 다녔고 그리고 90년대에 다니면서 인텔 프로세서들이 계속 세대마다 나오는 걸 보고 사실 그런 거에서 굉장히 매력이 느껴져서 제가 이제 컴파일러라고 하는 컴파일러 아텍처라고 하는 걸 저희 전공으로 삼아서 공부를 했는데 그런 굉장히 어떻게 보면은 CPU나 이런 프로세서 디자인을 하는 사람들한테는 정말 재미있는 그런 시기가 1990년대에 있었어요. 여기서 보면은 그때 이제 클락 사이클도 매 이제 인텔 프로세서 제너레이션이 올라올 때마다 엄청나게 올라가고 그리고 새로운 아키텍처적인 그런 개념들도

Attendees 1 53:29 굉장히 잘 반영이 돼서 엄청나게 빠른 속도로 프로세서가 진보를 했던 그런 시절이 1990년에서 2000년 사이에 있었고 그 당시에 많은 그런 구조적인 그런 개선들은 인스덕션 수준에서 어떻게 해서 중첩을 잘 할 것인가 그러니까 제가 아까 말씀드렸던 하나 인스트럭션을 처리하는 데 있어서 어떻게 스테이지를 나눠서 할 것인가라고 하는 거랑 그다음에 여러 개의 인스적션들을 결국엔 어떻게 이제 동참을 해가지고 할 거라 할 것인가라고 하는 이런 문제들을 다 종합적으로 다 포함을 해서 인덕션 레벨 패럴이 할 수가 있는데 이런 인덕션 패럴 한 프로세서를 디자인을 굉장히 열심히 했던 그런 시대가 있었습니다. 봅시다. 네 근데 이제 그게 2000년이 되면서 어느 정도 동료가 되죠 그니까 펜티엄 4라고 하는 그런 프로세서가 굉장히 상실적인 그런 프로세스였는데 펜티엄 3가 나올 때까지 인텔이 굉장히 성공적이었고 그 똑같은 성공 방정식을 한 번 더 적용을 해서

Attendees 1 54:31 굉장히 어그레시브하게 파이프라이닝을 하고 그래서 클락 프린커스를 높이고 그다음에 아더보드 프로세서를 더 복잡하게 만들어서 이속션 레벨 패럴럴리즘을 더 극도로 추구를 하려고 했던 프로세서가 이제 팬텀프라고 할 수 있는데 결국에는 그런 클라 프리퀀시를 너무 무리하게 올려서 발열 문제가 발생을 해서 인텔이 정말 대대적으로 실패를 한 대표적인 프로세스가 펜테포라고 할 수가 있습니다. 이제 그게 여기 나온 게 이제 디나드 스케일링이라고 하는 게 있는데 이제 디나드 스케일링이라고 하는 게 결국에는 이 파워에 관련되어 있는 이 그런 것들인데 그 이제 실제 저희가 트랜지스터 자체를 더 조그맣게 만들어서 집적을 해낼 수가 있긴 하지만 그게 이제 파워가 빠져나가는 거는 트랜스터가 집적이 된다라고 하는 거에 과 꼭 비교를 하지 않고요. 이 트랜스터가 집적이 되면서 더 많은 여력이 발생하는 크 프리퀀스가 올라가게 되면은

Attendees 1 55:24 열 밀도가 점점 더 올라가게 되는데 그 열 밀도가 올라가는 것들을 더 이상 해결할 수가 없게 되면은 그러면 칩이 타겠죠. 네 이제 그런 현상들이 이 당시에 이제 발생을 하게 되고 그런 현상들을 이제 계속적으로 해결할 수가 없어서 이런 클락 프리퀀스를 높이는 게임은 2000년대에 이제 중단이 되게 됩니다. 네 그때 이제 어떤 일이 일어나냐면 인터넷이 생기게 되고 그다음에 서버 시장이 굉장히 커지게 되고 하면서 이런 패럴하게 실행을 할 수 있는 것들을 하나의 인스트럭션 스트림 안에서 인스트럭션 레벨 패러리즘을 꼭 이제 뽑아낼 필요가 없이 여러 개의 그런 테스크들을 여러 개의 그런 큰 테스크들을 점점 더 많이 병렬로 처리를 할 있는 그런 프로세스가 훨씬 더 중요해지는 그런 시점이 되기도 해서 인텔은 인스덕션 레벨 패럴리즘에서 멀티코로 넘어가서 이제 멀티 트레이딩

Attendees 1 56:14 아키텍처로 이제 넘어가는 그런 트랜지션을 성공적으로 하게 되죠. 그래서 지금도 그 기조가 그대로 유지가 돼 있어서 인터넷 프로세서들이 2000년대 이후에는 점점 많은 그런 코어들을 담고 담는 그런 프로젝트들을 쭉 출시를 해오고 있습니다. 그게 이제 제가 말씀드렸던 2000년대 인텔이 지나왔던 변곡점이라고 생각을 할 수가 있어요. 이건 트레드 레벨 패러럴 한 그런 트레드 레벨 패러럴 한 그런 아키텍처가 특히나 그런 서버 시장에서 이제 왜 중요하냐라고 하냐면 이 결과적으로 제 아키텍처의 하락을 좀 생각을 하면은 맨 위에 이제 연산을 해주는 실제 제 연산지가 있고요. 그리고 그 밑에 온친 메모리가 이제 캐시 특히나 스피 같은 경우에는 캐시가 이제 이렇게 있게 되고 그리고 이제 오침 메모리 이제 d램이 있게 되는데 여기에서 이제 실제 현대 모든 프로세서들이 가지고 있는 가장 큰 퍼포먼스 문제는 옵침 메모리로 가는 벤드위스라고 할 수가 있어요. 밴드위스 내지는 레이턴시라고 할 수 있어요.

Attendees 1 57:18 제 이거를 메모리 월이라고 부를 만큼 그 문제가 심각하고 요거를 어떻게 잘 극복을 하느냐라고 하는 게 굉장히 이제 프로세서 디자인을 하는 데 있어서 굉장히 큰 그런 문제들이었습니다. 네 메모리 월이라고 하는 것들은 1994년에 제가 알기로는 가장 처음 등장을 한 것 같고요. 이런 메모리 월을 가장 효과적으로 해결할 수 있는 방법 중에 하나 잘 알려져 있는 게 이제 멀티 드레딩이에요. 멀티트레이딩이 왜 그러면은 메모리 월 문제를 해결할 수 있는 가장 효과적인 방법 중에 하나냐면 제 이런 경우에는 사실 이제 밴드리스보다는 이제 레이턴스가 문제가 되는 상황인데 내가 가져와야 할 데이터가 온칩 메모리에 없는 경우에는 그럼 이제 집에 있는 d램에서 가져와야 되는데 그 디램에 대한 어세스 하는 데 걸리는 사이클이 굉장히 길거든요 그럼 그거를 되게 긴 사이클을 어떤 특정한 트레이드가 진행을 못하고 스토리 될 수밖에 없잖아요

Attendees 1 58:20 근데 만약에 저희가 처리할 수 있는 스레드가 충분히 많으면 그러면 그 쓰레드는 스톨릭에 놔둬두고 다른 스레드를 수행을 하게 되면 되죠. 다른 스레드가 이제 수행을 하다가 마찬가지로 걔도 집에 있는 메모리를 접근을 해야 되면 그럼 더 이상 진도를 나갈 수가 없게 되고 이 스톨이 되는데 그 사이에 첫 번째 스레드에 있던 메모리가 만약에 d램으로부터 리턴이 되어 왔다라고 한다면은 그 스레드를 다시 시작을 하면 되는 거고 아니면 더 많은 스레드가 또 있어서 또 다른 스레드를 또 이제 수행을 하면 또 마찬가지로 수행이 되다가 또 메모리가 이제 스토리 되면 또 기다리고 있고 그럼 첫 번째 내지는 두 번째 게 또 다시 풀리면서 수행을 할 수가 있고 어떻게 보면 커뮤니케이션과 실제 이제 메모리에 대한 접근이 이렇게 반복적으로 트레드마다 일어나게 되는데 새로운 트레드가 그러니까 트레드 숫자가 많으면 많을수록

Attendees 1 59:10 실제 메모리를 그 메모리 스토리 일어났을 때 다른 트레드가 실행이 돼서 컴퓨테이션을 계속해서 진행을 할 수가 있어서 이제 이런 중첩 효과가 커뮤니케이션과 메모리 사이에 메모리 접근 사이에 일어날 수가 있게 되죠. 그래서 이제 이런 스레드가 많게 되면 이런 메모리 레이턴시를 굉장히 효율적으로 잘 효과적으로 잘 하이딩을 할 수가 있습니다. 이 부분이 제가 잘 설명이 됐을까요? 혹시 더 설명이 필요한 분이 계세요? 근데 이건 GPU에서도 많이 나오는 개념이라 제 생각에는 많은 분들이 잘 이해를 하실 수 있으리라고 생각을 하는데 CPU 같은 경우에는 이거를 이제 하는 방법이 이제 두 레벨이 있는데 하나는 실제 이제 멀티코어 코어 숫자를 늘려서 할 수도 있고요. 그다음에 두 번째는 한 코 안에서도 로지컬한 프레드를 여러 개를 동시에 처리를 할 수 있도록 만들어놔서

Attendees 1 59:57 이렇게 하하게 피지컬한 코어가 늘어남으로써 그다음에 하나의 코어가 지원할 수 있는 그런 버틀 코어가 또 늘어남으로써 이렇게 만들어낼 수가 있겠죠. 최영주님께서 OS에서의 스케줄링 알고리즘도 컴파일러에서의 스케줄링 알고리즘 을 사용을 할까요? OS에서의 스케줄링 알고리즘은 콤팔레의 스케줄링 알고리즘과는 좀 많이 다른 것 같습니다. 그래서 그 사이에 그런 아비오스한 그런 미사성은 일단 없긴 한 것 같아요. 이제 이제 싱글 트레디드 프로그램 같은 경우를 이제 멀티 트레디드 프로그램으로 가속화해 주는 그런 컴파일러 같은 경우에는 이제 알고리즘들이 좀 비슷할 수 있긴 하지만 일반적으로는 저는 굉장히 다른 두 종류의 스케줄이 문제라고 생각이 됩니다. 이렇게 인텔 프로세서가 디나드 스케일링 디날리 스케일링의 이제 벽에 부딪히면서 멀티코어로 이전이 되고

Attendees 1 1:00:51 그다음에 멀티 트레이딩으로 이 메모리 레이턴시를 하이딩을 하고 하는 이런 일을 정리를 하던 그런 똑같은 시기에 이제 GPU도 나오게 되고 이제 그래픽스 프로세서가 이제 픽스 펑션에서 프로그래밍 디바이스로 변신을 하게 되거든요 그런 시점이 한 2000년대쯤에 일어났다고 생각을 하시면 되고요. 결과적으로 GPU라고 하는 거는 그래픽스가 가지고 있는 그 픽셀 단위 내지는 어떤 트라이앵글 삼각형 단위의 그런 굉장히 많은 엄청나게 많은 어번던트한 패럴리즘 메시브한 그런 패럴리즘이 있다라고 생각을 하고 그런 것들을 잘 활용을 하기 위해서 멀티 트레딩이라고 하는 것을 통해서 메모리 레이턴시를 해결을 하면서 훨씬 더 많은 그런 트레드를 한 번에 처리를 할 수 있는 그런 효율적인 구조로 만들어지게 됩니다.

Attendees 1 1:01:39 CPU랑 GPU랑 이제 비교를 해보면 컴퓨팅 댄스티가 일단 다르고요 한 번에 처리할 수 있는 트레드의 숫자가 다르고 또 이제 그런 것들이 가능해진 게 컴플롤 자체가 훨씬 더 간단해요. 이 CPU 같은 경우에는 아까 제가 말씀드린 아웃오브 오더 프로세싱이라든지 어떤 싱글 스레드 내에서의 퍼포먼스가 제 올리기 위한 그런 굉장히 많은 부가적인 그런 장치가 있었다라고 한다면 GPU는 하나의 테스크 하나의 스레드는 오래 걸려도 되니까 그 대신에 여러 개의 세를 한꺼번에 잘 처리를 할 수 있도록 그니까 트풀에 엄청나게 효과적으로 잘 최적화가 되어 있는 그런 아키텍처를 선택을 하게 되고 굉장히 GPU랑 CPU랑 굉장히 극명하게 다른 길을 걷게 됩니다. 거기에 이제 결정적으로 이런 이제 페이더 프로그램 이로부터 이제

Attendees 1 1:02:29 셰이더 프로그래밍으로부터 이제 시작을 했던 그런 GP의 진화가 결정적으로 딱 이제 완성이 되는 그런 시점이 이제 쿠다라고 하는 게 이제 정의가 되면서였는데요. 이제 쿠다는 이제 그런 쉐이더라고 하는 게 만들었을 때 만들었던 그런 아키텍트적인 개념을 잘 정리를 해서 이걸 소프트웨어적으로 소프트웨어가 이해할 수 있는 그 프로그램 모델로 잘 정리를 한 게 이제 쿠다라고 생각을 하시면 되고요. 아키텍처적으로는 이런 장치도 있긴 했지만은 그게 쿠다로 잘 정리가 된 건 한 2007년쯤 되는 것 같아요. 이 쿠다가 나오면서 엠비디아는 싱글 인스럭션 멀티플 레드라고 하는 그런 프로그램 모델을 제시를 하죠. 그게 그냥 싱글 프로그램 멀티플 데이터 내지는md라고 하는 것들하고 그렇게 크게 다르지는 않기는 한데 이제 그런 특성들을 엠비디아 GPU가

Attendees 1 1:03:19 제 설계를 한 그런 메모리 레이턴시 하이딩을 위한 특별한 장치에 더 특화된 이름으로 만든 게 SMT simt라고 생각을 하시면 됩니다. 그래서 이제 뭐 트레드 블록이라는 개념이 있고 지금 현재도 쓰이고 있는 이런 웹이라고 하는 그런 개념들이 있고 이제 이런 웹들을 잘 수행을 하기 위한 그런 이제 멀티프로세서 구도를 가지고 있죠. 아키텍처적인 그런 개념은 그런 굉장히 많은 쓰레드가 있는 것이 그러니까 프로그래머가 코다를 활용을 해서 굉장히 많은 쓰레드를 이제 이런 라고 하는 프로그램 모델로 작성을 하게 되고요. 그러면 그런 것들이 개념적으로는 다 인디뷰하게 이제 수행이 되도록 수용이 되는데 그런 캐스미스라든지 하는 그런 것들이 이제 발생을 하면 그 일들은 포킹이 되고 하지만 대안으로 돌릴 수 있는 트레드가 굉장히 많기 때문에 그런 대안의 트레드들이 대신에 이제 돌다가

Attendees 1 1:04:13 만약에 크리스미스가 났던 그런 원래 스레드의 크리시미스가 이제 해결이 되면 그 스레드가 다시 선택이 돼서 수행이 돼서 이제 다음 단계로 넘어가고 또 그러다가 만약에 또다시 캐시 닉스가 난다든지 하면 또 기다리고 그 사이에 또 다른 사이드가 테이크오버에서 또 수행을 하고 하는 이제 그런 구조로 전반적으로 설계가 되어 있습니다. GPU는 이제 o 하이딩 레이턴시라고 할 만큼 이런 메모리 레이턴시의 문제를 방금 말씀하신 그런 심트라고 하는 그런 아키텍처를 가져가면서 해결을 잘 했었죠. 지금 나오는 그런 GPU들은 사실 이렇게 190 2000년에서 2010년 사이에 정의가 됐던 그런 그래픽스 을 기준으로 생각을 해서 만들었던 그런 아키텍처랑은 저는 굉장히 많이 달라진 것 같아요. 그래서 지금 여기서 이야기할 제가 지금 하는 이런 지표에 갖는 특성들이 지금도 다 그대로

Attendees 1 1:05:10 유지가 되는지 안 되는지 라고 하는 것들은 GP 인터널들이 다 공개가 되지 않아서 잘 모르겠지만 머신 러닝의 특성에 맞게 또 변모를 하고 있으면서 또 올 오버 하이딩 레이턴시라고 하는 이런 측면에 있어서는 제 생각에는 많은 부분들은 또 이제 설계가 달라지고 있지 않나 그런 생각이 들기도 합니다. 하지만 어쨌든 교라고 하는 게 처음 만들어졌을 때는 이런 철학을 가지고 만들어졌고 이런 철학에서 만들어진 그 큰 틀은 지금도 유지가 잘 되고 있다라고 생각을 합니다. 아시겠지만은 원래 DP를 만들었을 때는 머신 러닝을 가지고 생각을 하고 만들지는 않았지만 머신 러닝에도 굉장히 잘 맞아 있기 때문에 머신러닝 붐이 일어나면서 엠비디아도 엄청나게 성장을 하게 되고 그거에 맞춰서 MB디아 GPU가 가지고 있는 컴퓨팅 코페스트도 엄청나게 올라가고 있는 그런 상황이죠.

Attendees 1 1:05:57 근데 거기에 이제 컴퓨팅 커페스티가 점점 올라가는 것 만큼 메모리 밴드위스는 아직 따라오지 못하고 있고요. 물론 이제 메모리 인터페이스 기술도 굉장히 빠르게 발전을 해서 새로운 기술들도 계속 나오고 있고 눈 부시게 발전을 하고 있긴 하지만은 엠비디아가 그 컴퓨팅 댄스티를 직접을 해내는 속도에는 지금 못 맞추게 있고 그 사이에 있는 캡은 아직도 점점 더 벌어지고 있는 그런 상황이라고 생각을 할 수가 있습니다. 다만 지금 나온 이제 블랙웰 같은 경우에는 거의 이런 게임의 끝에 온 게 아닌가라고 하는 느낌이 들 정도로 굉장히 많이 나가 있는 상황이기도 하고요. 그다음에 딥스 이런 일들이 일어나면서 계속 이렇게 엄청나게 괴물처럼 많은 컴퓨팅을 넣은 이런 팁들이 필요하게 될 것인가 아니면 이 정도 선에서는 극단이 멈출 것인가 아니면 오히려 내 스케일 백을 할 것인가라고 하는 것들은 좀 봐야겠지만 어쨌든 지난 10년 동안의 MBD아 행보를 보면은

Attendees 1 1:06:55 계속 인텔이 스케일업을 했듯이 계속 MBD아들 스케일 업을 해오고 있는 이런 상황입니다. 메모리 레이턴시를 해결하기 위해서 bpu가 그니까 엠비디아가 선택을 한 건 프로그램 모델은 굉장히 간단하게 하고요. 그러니까 레이턴시 하이딩이 꼭 필요하고 그런 레이턴시 하이딩을 하기 위한 여러 가지 복잡한 그런 장치가 있고 이런 것들은 사실 코다 프로그래밍을 통해서 개발자들한테 노출이 되진 않고요. 대신에 개발자들한테 이런 식으로 프로그래밍을 해 놓으면 굉장히 많은 트레드가 만들어지게 될 거고 하드웨어가 알아서 그걸 잘 분배를 해가지고 트리을 내놓을게 라고 이제 이제 계약을 맺는 거죠. 코다를 통해서 이런 방식으로 처리를 하는 게 머신러닝에 있어서는 꼭 잘 맞는 거냐라고 하는 것들에 대해서는 저를 포함을 해서 많은 사람들이 의문점을 가지고 있긴 합니다.

Attendees 1 1:07:54 그런데 그게 이제 아까 말씀드렸지만은 지금 최신 나오고 있는 이런 프로세서들은 엠비디아가 가지고 있던 원래 구조가 가지고 있던 그런 한계들을 이렇게 저렇게 이제 극복을 또 해 나가는 거 같아서 여기 나온 것처럼 이 mbdi의 GPGP 그런 적인 방법들이 머신 러닝에 잘 맞지 않는 게 아니냐라고 하는 말들이 사실 어떤 상황인지는 저도 잘 이해를 하기가 어려운 것 같아요. 하지만 어쨌든 간에 그 선택 자체가 원래 했던 그 선택 자체가 머신 러닝에 정말로 잘 적합하다라고 하는 것들에서는 의문이 있습니다. 이제 그런 이제 하드웨어적으로 복잡한 장치들을 사용을 해서 소프트웨어는 소프트웨어들은 오히려 이제 그런 디테일들을 고민할 필요 없이 만든 장치가 이제 GPU라고 한다면 이제 그거를 아오 프로세서가 있지만 거기에 이제 반대되는 개념으로 똑같은 문제를 소프트 쪽으로 풀려고 하는 그런

Attendees 1 1:08:49 viw 내지는 컴퓨터 프로세스가 있듯이 마찬가지로 이제 머신 러닝에 있어서도 GPU의 이제 그런 소프트웨어적으로 처리를 하는 그런 프로세스들이 요즘에 나오는 MPU들이라고 저는 생각을 하고요. MPU를 뭐라고 하나로 꼭 집어서 말할 수 없지만은 가지고 있는 공통적인 특징은 제 생각에는 그거인 것 같습니다. 이런 메모리 레이턴시나 밴드리스를 최대한 활용하기 위한 그런 장치들을 하도적으로 이제 가두는 게 아니라 소프트웨어들에게 노출을 해서 소프트웨어가 그런 점을 충분히 잘 반영을 해서 컴파일러가 내지는 이 프로그래머가 반영을 해서 프로그램을 하도록 하는 게 MPU들이 가지고 있는 가장 큰 특징이라고 생각을 할 수가 있습니다. MPU 구조는 그럼 어떻게 돼 있냐 다시 이 그림으로 가면 사실 이 전반적인 그림 자체는 제 생각에는 GPU든 아니면은 MPU든 비슷비슷한 것 같거든요. 아까 비슷한 그림을 그렸었는데 맨 위에 이제 계산을 할 수 있는 유닛들이 있고

Attendees 1 1:09:43 그리고 온치 메모리가 있고 당연히 이 사이에 데이터를 전송하기 위한 어떻게 설계가 돼 있는지 모르겠지만은 인터커넥트가 있고 티브로 이제 나가는 거는 굉장히 비싸고 그래서 이제 여기 벽돌로 표시를 했고요. 그다음에 이제 밑에 있는 d램이 있고 하는 이런 전반적인 구조들은 다 비슷한데 여기에서 이제 MPU들이 가지고 있는 가장 큰 특징은 이런 온티 메모리들이 다 캐수가 아니라 스크립트 메모리고요 그다음에 스크립트 패드 메모리의 값을 넣고 빼고 하는 이런 모든 과정들은 다 bma라고 하는 것들로 익스비슷하게 이제 프로그래밍이 되도록 되어 있다라고 하는 점들이 많은 엠피들이 가지고 있는 공통적인 특성이라고 생각을 할 수가 있고요. 이제 거기서 끝나는 게 아니라 그런 각각의 유닛들 여기서 있는 컴퓨테션 융크뿐만이 아니라 실제 메모리 값을 옮기기 위한 이런 dma들도 다 하드웨어들한테 소프트웨어적으로 다 노출이 되는 거죠.

Attendees 1 1:10:43 그 이게 벽멸로 돌아가는 개별적으로 프로그램 되고 벽멸로 돌아갈 수 있는 이런 프로그래머블 한 유닛으로 이 소프트웨어한테 이렇게 다 노출이 된다고 생각을 하시면 됩니다. 서 이런 것들이 하나하나 이렇게 다 노출이 되고 그 노출되어 있는 아키텍처 디스크립션을 바탕으로 해서 이 커맨드를 잘 만들어서 하드어한테 던져주면 이 커멘드 프로세서라고 하는 게 중간에 끼어 있어서 어떤 프로세서들은 이런 게 없을 수도 있긴 하겠지만 일반적으로는 아마 제 생각에는 있을 거라고 생각을 하고 받아서 이런 것들을 각각 거기에 맞는 하드웨어에 잘 뿌려주고 그 뿌려준 하드웨어들을 이렇게 분산되어 있는 형태로 그러니까 공간적으로 분산되어 있는 형태로 각자 알아서 잘 처리를 하게 되는 이런 일반적인 특성을 MP들이 저는 가지고 있다라고 생각을 합니다. 하드웨어 파이프라이닝과 소프트웨어 파이프라이닝의 차이를 간략하게 정리를 해 주실 수가 있나요? 이게

Attendees 1 1:11:45 뭐죠? 룸 레벨에서의 파이프라인을 말씀드릴 때 제가 아웃오브 프로세서가 실질적으로 파이프라이닝 효과를 만들어내는 것과 viw에서 소프트웨어적으로 파이프라인을 만들어서 하드웨어가 그대로 실행하는 것에 대한 차이를 제가 아까 설명을 드렸는데 혹시 그거는 잘 이해를 하셨나요? 우주님

Attendees 1 1:12:24 하드웨어 파이프라인과 소프트웨어 파이프라인의 차이를 간략하게 다시 말씀을 좀만 드리고 다시 돌아오면 네 앞으로 다시 돌아가 볼게요. 제 생각에는 그거를 이해를 하시는 게 좀 중요한 것 같아서 다시 돌아가면 아웃오브 프로세서 그러니까 하드웨어적으로 파이프라인을 효과를 내겠다라고 했을 때에는 그 루 자체를 파이프라인이 되어 있는 형태로 작성을 하도록 프로그래머들한테 요청을 하지 않아요. 그냥 룹은 그냥 시퀀셜하게 이렇게 짜라고 이제 하는 거고요. 이 부분은 혹시 전달이 잘 됐나요? 영주님 하드외적인 파이프라인과 소프트웨어 파이프라인의 가장 큰 차이는 이런 파이프라인을 만들어내는 거를 하드웨어가 하느냐 아니면 소프트웨어가 하느냐의 차이인 거고요. 이제 하드웨어가 하게 될 때에는 하드웨어는 그 일은 하드웨어 하기 때문에 소프트웨어한테는 파이프라이닝을 해서 만드는 게 아니라 그냥 훨씬 더 간단하게 프로그래밍을 하라고 이제 하는 거고요. 네 시다. 이게 여기였나 네 이렇게 그냥

Attendees 1 1:13:46 간단하게 프로그래밍을 하라고 하는 거고요. 이 프로그램을 이렇게 짤 때에는 프로그래머가 이것들이 중첩이 돼서 수행이 될 거라고 생각을 할 수도 있긴 하지만 굳이 그렇게 생각을 하지도 않아도 돼요. 많은 이런 룩들이 사실 이런 중첩이 자연적으로 이루어지게 사실 짜지게 되어 있어서 그런 것들은 생각하지 않고 이렇게 짜는 거고 하지만 실제 이 프로그램의 시멘틱 상으로 봤을 때는 이런 것들이 이제 이렇게 시퀀셜하게 수행이 되는 프로그램인 것처럼 보이는 거죠. 네 그런데 이것들을 이런 중첩을 내기 위한 효과를 근데 만들어 내고 싶다 라고 했을 때에는 했을 때에는

Attendees 1 1:14:39 네 이게 제가 계속 왔다 갔다 하는 게 좀 불편하긴 한데 네 하는 데 있어서는 제가 말씀드린 이런 몇 가지 해결해야 될 기술적인 난관들이 있거든요 그중에 하나가 컨트롤 플로우라고 하는 게 있었고요. 다른 하나가 다른 이터레이션에 있는 인스석션끼리 사이에 메지스터 중첩이 일어나서 생기는 문제 이런 문제들이 아까 제가 있다라고 말씀을 드렸어요. 그래서 이런 문제들이 있기 때문에 어떻게 보면 인혀런트하게는 중첩이 가능한 누구일지 모르지만 이런 방해 요소들이 있어서 있는 그대로는 중첩을 하기가 어렵죠. 네 웅주 님 여기까지도 잘 따라오셨나요? 네 그래서 해결하려고 이제 그걸 이제 브랜치 프로젝션하고 그다음에 하드웨어적으로 레지스터 리네이밍을 해서 데이터 플로그래프를 만드는 이 두 가지 방식으로 이제 해결을 하는 거죠. 네 그 해결을 한 게 결국에는 여기 그림에 제가 적어놨는데 시퀀셜 코드가 있으면 여기서 룸이니까 계속해서 다시 반복을 할 거다라고 저희가 잘 브런치 플렉션을 하면

Attendees 1 1:15:47 room을 언롤 하는 것 같은 그런 효과가 나죠. 그러면 이제 그게 이제 아까 다른 분께서 아까 말씀하셨던 그런 그 인스트럭션의 윈도우라고 하는 게 생기게 되는 거고요. 그 윈도우에 들어 있는 인스트럭션들에 대해서는 레지스터가 중첩되어 있는 효과를 캔스를 시켜서 이런 그래프 형태로 저희가 뽑아낼 수가 있어요. 이 그래프 형태로 뽑아내는 거는 실제로는 아키텍처 한 레지스터보다 훨씬 더 많은 피지컬 레지스터를 쓰고 그 피지컬 한 레지스터가 여기 있는 애지 하나에 해당을 한다고 생각을 하면 되고요. 들어왔을 때 이런 어떤 아키텍처 레지스터가 어떻게 피지컬 레스터에 매핑이 되는가라고 하는 것들을 잘 트래킹을 하면서 쭉 만들어내게 되면 결과적으로는 이런 그래프를 동적으로 만들어낼 수가 있고요. 이 동쪽으로 이렇게 만들어진 그래프를 소플로지컬 오더로 그냥 수행을 하게 되면 원래 원래 이제 룸을 수행하는 거랑 똑같거든요

Attendees 1 1:16:40 그니까 a, b, c가 여기서 보면은 인풋이 없잖아요 그러니까 얘네 셋은 지금 기다리는 게 없기 때문에 수행을 하면 되고 얘네 셋이 이제 수행이 되게 되면 그다음 단계로 더하기나 빼기나 이런 연산들이 있는데 이런 애들도 얘네들이 없게 되면 또 디펜던스가 없기 때문에 수행을 하게 되고 이런 식으로 이제 토폴로지컬 오더의 순서대로 수행을 할 수가 있게 되고 그런 경우에는 여러 인스석션들이 다 어베일러을 해줄 수가 있기 때문에 병렬로 처리를 할 수 있는 그런 구간들이 생기게 되죠. 여기까지도 혹시 설명이 됐을까요? 근데 이게 결국에는 어떤 일이 일어난 거랑 똑같냐면 이터레이션이 시작되기 전에 다음 이터레이션을 시작을 하는 거랑 사실은 똑같은 일이에요 똑같은 일이고 그다음에 실제 얼마큼 이게 빠르게 수행을 할 수 있냐라고 하는 건 사실

Attendees 1 1:17:39 얘들 이 이터레이션에서 일어나는 일들과 이 이터레이션에서 일어난 일들 사이에 어떻게 디펜던스 관계가 있냐라고 하는 거에 의해서 결정이 되는데 그것들은 이제 아까 그 다이나믹 그래프를 그려내면서 동적으로 판단이 되게 되는 거고요. 결과적으로 을 수행을 하게 되면 그러면 이 여러 개의 룩들이 하나의 그런 인스트럭션 wind더에가 들어와 있어서 중첩이 돼서 수행이 되는데 각각의 룩들이 다른 스테이지에 있는 일들을 수행을 하게 되는 거고 그 다른 스테이지들을 쭉 이제 이런 식으로 옆으로 펼쳐서 연결을 해 보면 이게 이게 이제 이 인스 이 룹 이터레이션은 맨 마지막 스테이지를 수행을 하고 있고 이 이터레이션은 뒤에서 두 번째 스테이지를 수행을 하고 있고 세 번째 이터레이션은 첫 번째 스테이지를 수행을 하고 있고 다른 스테이지에 있는 하나의 인스트럭션들 다른 스테이지에 있는 여러 룩들이 동시에 묶여서 수행이 되는 그런 형태라고 생각을 하면 되고

Attendees 1 1:18:40 루비다 보니까 이런 일들이 이렇게 뭉태기로 뭉태기로 반복적으로 일어나는 것과 그런 거의 비슷한 효과가 동쪽으로 제가 방금 드린 아웃오브 프로세서를 수행을 하게 되면 이루어지고 있다라고 생각을 할 수가 있는 거죠. 정확하게 이렇게 동작은 하지 않을 수도 있기는 해요. 하지만 결과적으로 일어나는 효과는 이런 효과다라고 저희가 해석을 할 수가 있습니다. 이게 이제 하드웨어적으로 파이프라인이 일어나는 과정이죠. 여기까지는 혹시 설명이 됐나요? 네 그러면 넘어가서 결과적으로 이제 이 룹을 파이프라인 된 형태로 결국 이제 수행을 하고 싶다라고 한다면은 그러면 아예 더 명시적으로 이렇게 저희가 프로그램을 기술을 할 수가 있으면 그러니까 인스트럭션 이제 프로세서가 소용해야 되는 인스트럭션 아예 저희가 이런 형태로 이제 만들어낼 수 있으면 그럼 이것만 그냥 반복해서 수행을 하면 되잖아요 그러면은 아까 다이내믹하게 복잡하게 처리를 해서 룸을 중첩한 거랑 똑같은 효과가 날 거 아니에요 여기 이거는

Attendees 1 1:19:52 납득이 되시나요? 네네 그러면 그런 이게 이제 스트 파이프라인 거죠. 그러니까 하드웨어가 결정을 하는 게 아니라 아예 소프트웨어가 이런 모든 관계들을 고려를 해서 프로그래머가 하든 아니면 컴파일러가 하든 해서 아예 명시적으로 나는 이렇게 파이프라인 스테이지를 다른 부분에 있는 것들을 합쳐 가지고 이거를 반복해서 수행함으로써 파이프라인 효과를 만들어낼 거야라고 하는 플랜을 이 소프트웨어가 다 만들어 가지고 만들어 놓고 하대원은 하대원은 이제 그런 복잡한 스케줄링을 하는 복잡한 서켓틀링은 다 빼놓고 그 대신에 소프트웨어가 준 대로만 수행을 하면 되는 거죠. 그래서 소프트가 준 대로 수행을 하는 그 주는 명령어가 대충 이렇게 생겼다라고 해서 이제 베이롱 인스트럭션 워드라고 표현을 했습니다. 여기에서 네 그리고 이제 마지막 단계로 그러면 이런 이런 실제로 파이프라인 효과를 내는 이걸 어떻게 만들어내냐

Attendees 1 1:21:14 라고 하는 게 오늘 이제 제가 설명을 충분히 드릴 수는 없긴 하지만 이런 이제 소프트웨어 파이프라이닝이라고 하는 컴파일러 기법들이 있는 거고 그게 이제 가장 대표적인 그 소프트웨어 파이프라이닝 기법이라고 하는 게 이 모듈러 스케줄링이라고 하는 그런 기법들이 있고요. 네 그래서 어쨌든 그런 기법들을 사용하면 c로 짜여져 있는 그런 시퀀셜 프로그램에서 루 부분을 잘 스케줄링을 해가지고 여러 이프레션이 중첩이 되어 있는 부분들을 한꺼번에 돌릴 수 있는 그런 커널 반복해서 수행을 하면 되는 그런 커너를 컴파일러가 소프트웨어로 합성을 해내고 이제 그거를 이제 하드웨어한테 그대로 던져주면 하드웨어는 그걸 그냥 반복해서 수행만 하게 되면 이 파이프라인 되어 있는 룸을 수행하는 것과 똑같은 효과를 볼 수 있는 거죠. 제 생각에는 이 정도로 설명할 수 있을 것 같은데 은주 님 약간 좀 이해가 되셨나요?

Attendees 1 1:22:10 네 알겠습니다. 그럼 옹주님께서 질문하신 거는 된 것 같고 선우님께서 말씀하신 쿠다에서 예를 들면 스트림 블록 트레이드를 고려해서 커버를 작성하는 게 파이프라인이고 작성된 커널 내에 대한 리소리는 별로 8가지 하는 차이 찍는다고 볼 수가 있을 것 같 그렇지는 않죠 왜냐하면 그렇게 생각할 수도 있기는 한데 일단은 제가 오늘 말씀드리려고 하는 이런 포인트에 대해서는 다 선호님께서 말씀하신 거는 쿠다에서는 그냥 스트림 블락 트레드 결국엔 이제 스트림과 블락과 트레드가 결국에는 격멸로 돌 수 있는 트레드라고 생각을 하면 이런 애들이 그냥 격멸로 돌면 돼라고 하는 명세만 던지는 거죠. 근데 디테일하게 언제 누가 뭘 어떻게 중첩해서 돌릴 건가라고 하는 것들은 그거는 이제 엠비디아 GPU가 안에서 해결을 하잖아요. 네 그런 의미에서는 실제로 그런 프레드들 간에

Attendees 1 1:23:08 레이턴시 하이딩을 위한 패러럴 파이프라이닝을 해내는 건 사실은 하드웨어적으로 처리가 되는 것 같아요. 제 생각에는 저는 그렇게 이해가 됩니다. 선원님에 대한 질문에 그렇게 답을 하고 그러면 님께서 따로 as샘블리 단에서 구현된 게 있을까요? 이게 어떤 말씀인지 잘 네 세미님. 네 님 질문은 제가 이해를 못해서 지금 답을 어샘블리어가 따로 있죠 그러니까 VLIW에서 사용하는 에샘블리어가 따로 있겠죠 네 만약에 그게 질문이라면 그런 것 같고요. 동생님께서 소프트웨어적으로 dma를 노출하셨다고 하는데 dma 대어폭을 수동적으로 직접 관리하는 게 아니라 여러 최적화 기법 같은 거를 사용을 해서 관리한다는 이야기인가요? 예를 들면 GPU에서 데이터 전송과 계산을 오래 픽하는 케이스 같은 방법들로 대여 폭을 효율화하는 건가 이제 MPU에서 말씀을 하시는 거죠 종수님 아까 지금 네 아까 이 질문이 저는 선우님께서 하신 질문하고 저는 되게 비슷한 질문이라고 하는데

Attendees 1 1:24:13 그니까 엠비디아 GPU도 에이 싱크로너스 카피 같은 게 생기면서 어떻게 보면 소프트웨어적으로 dma가 노출이 됐다고 생각할 수도 있거든요. 그리고 최근에는 텐서 코어를 위한 어 싱크너스 카피 이제 들어서면서 이런 DNA가 소프트웨어적으로 노출이 됐다라고 생각을 할 수가 있기는 한데 근데 그 어떤 프레드 특정한 테스크가 있을 때 그 테스크에서 이런 dma DNA라고 하는 서브 테스크가 필요하다라고 하는 건 명세를 할 수 있기는 한데 그런 애들이 되게 여러 개가 많이 있었을 어떤 순서 관계로 이루어질까라고 하는 것들에 대한 컨트롤은 사실 명시적으로는 없다고 생각을 할 수가 있죠. 그냥 이렇게 돌 수 있는 트레드들이 그냥 굉장히 많아 라고만 이제 GPU를 쓸 때에는 이제 명시를 하는 거고요. 그런데 그거를 이제 MPU다 특히나 되게 익스트림하게 거의 대부분의 그런 수행 디테일들을 다 소프트웨어가 만들어준 플랜에 의존을 하는 그런 MPU다

Attendees 1 1:25:11 라고 한다면 제가 다시 원래 설명하고 있던 쪽으로 가게 된다면 여기에 있는 이런 dma들이 결국에는 이렇게 프로그래밍이 되는 거거든요

Attendees 1 1:25:35 이렇게 프로그래밍이 되는 거거든요. 그러니까 그냥 VRW 프로세서에서 쭉 펼쳐져 있는 펑션을 읽듯이 돌아가게 되고 결국에 걔네들 사이에서 누가 먼저 일어나는 일들은 다 소프트웨어 플랜을 만들듯이 만약에 MPU를 가지고 똑같은 일을 한다라고 한다면 프로그래머가 하든 아니면 컴파일러가 하든 하나의 트레드에서 이제 일어나는 그 각각의 단계들을 다 분리를 하고요. 그다음에 그 분리를 한 그런 테스크들이 실제로 어떤 하드웨어에서 돌아갈 건가라고 하는 것들도 다 명시를 하고 그런데 그러면 그런 것들이 어떤 순서로 일어날 건가라고 하는 것들도 다 명시를 해서 그 순서대로 일어나도록 디펜던시 체인을 만들어주고 그렇게 만들어진 전체적인 플랜 자체를 그냥 던져주는 거예요. 그러면 하드웨어는 더 이상 복잡하게 생각하지 않고 그냥 그 플랜을 굉장히 간단하게 기계적으로 처리만 각자 알아서 하면 되는 거죠.

Attendees 1 1:26:40 그러니까 다른 애들이 어떻게 생겼고라고 하는 것들에 의해서 글로벌한 디시전을 내려서 뭔가 스케줄링을 하는 그런 작업들이 전혀 없이 각자 소프트웨어가 명시한 대로만 수행을 하게 되는데 다만 이런 그러니까 예를 들어서 어떤 테스크는 계산을 여기서 하고 근데 그 계산을 하기 위한 데이터는 에런을 dma를 써서 해야 되고 나중에 그 결과는 다시 l원으로 l2로 내렸다가 l2에서 DM으로 또 다시 내려야 되고 라고 하면은 이 세 개의 하드웨어를 써서 하나의 테스트를 한다라고 한다면은 그 서브 텍스트들 사이에 신도 관계는 있잖아요 그 이제 그런 순서 관계도 명시가 돼서 그 관계를 지키면서 수행을 하기 위한 최소한의 간섭이 있긴 하지만 그런 것들을 제외하고는 모든 플랜들은 소프트웨어가 된다라고 하는 거죠. 네 그런 점에서 어떻게 보면은 MBDR GPU하고 mq하고는 차이가 나게 돼요.

Attendees 1 1:27:43 네 권준아 님은 혹시 리니어나 시니어 레이어에서 일반적으로 동시 처리할 수 있는 계산 플로우가 뭐가 있을까요? 네 그러니까 리어나 아니면은 예를 들어 맨멀이다라고 한다면은 그 맨멀 자체가 굉장히 크게 되면 그거를 하드웨어에 한 번에 다 때려가지고 멤버를 한 동시에 처리를 할 수는 없거든요. 결국에는 그걸 다 파일로 쪼개서 조그만 메몰로 다 쪼갠 다음에 걔네들을 스케줄링을 해서 처리를 해야 돼요. 그렇게 생각을 하면은 이렇게 동시에 처리할 수 있는 굉장히 많은 그런 작은 메몰들이 생기게 되고 이제 걔네들의 이제 계산 플로우가 만들어지게 되겠죠. 네 주나 님 질문은 네 이렇게 이야기하면 되는 것 같습니다. 일단 질문하는 질문을 받는 단계로 넘어가면서 대충 다 설명이 된 것 같긴 한데 어쨌든 이제 제가 설명을 하려고 했던 것들은 대충 이렇게 생겨 있는 이런 아키텍처가 있다 라고 한다면 이런 아키텍처가 실제로 어떻게 구성되어 있는지라고 하는 그런 디테일들이 이렇게 횡적으로

Attendees 1 1:28:46 횡쪽으로 이렇게 펼쳐놓고 생각하면은 각각 인디펜던트하게 프로그래밍이 되는 유니들로 다 이렇게 노출이 된다라고 생각을 하면 되는 거고 이런 럴 그런 면에 있어서는 아까 제가 이제 말씀드렸던 것과 똑같은 그런 하이어 호라진탈 인코딩에 가까운 그런 인스석션 셋 아키텍처를 갖고 있다고 생각을 할 수가 있고요. 그리고 이제 모델이 그래프로 주어지게 되면 그러면 이제 그 하나하나의 노드들도 다 별도의 계산이긴 하지만 또 여기에 있는 하나하나의 그 논들도 굉장히 큰 계산을 하는 경우가 많기 때문에 그런 것들도 다 이제 조그마한 그런 노드들로 계산들로 다 이제 쪼개게 돼서 아키텍처적인 디테일들을 전반적으로 다 고려를 한 컴파일러가 종합적인 판단을 해서 그것들을 실제 각 하드웨어 인력들이 해야 될 일로 다 이제 쪼개서 플레닝을 만든 다음에 그거를 이제 실제 던져주면 MPU가 이제 수행을 하게 되는 셈인 거죠.

Attendees 1 1:29:42 그러니까 GPU 같은 경우에는 이런 일들에 대한 디테일들은 이제 가리고 그냥 하나의 스레드가 어떻게 생겼고 그런 애들이 몇 개가 있고 하는 그 정도의 명세만 딱 던져주면 그러면 이제 그런 것들을 다 쪼개 가지고 처리를 하고 하는 이런 과정들은 다 이제 하도적으로 처리가 된다고 친다면 그렇게 GPU에서는 하드웨어에서 하는 그런 결정들을 다 소프트웨어가 해서 다 결정된 상태의 명세를 만들도록 하는 게 이제비유라고 생각을 하시면 됩니다.

Attendees 1 1:30:14 네 그래서 일단은 제가 그러면은 이제 쓰레드 레벨 패럴리즘에 에서의 레이턴시이 등에 대한 내용을 정리를 해보면 메모리 월이라고 하는 굉장히 중요한 그런 아키텍처적인 문제가 있고 이 메모리 레이턴시를 하이딩 또는 메모리 밴디스를 최대한 잘 활용하는 게 굉장히 중요한데 CU가 인텔이 핀트 4로 상징이 되는 그런 클락 스피드의 게임이 끝나가던 그런 시절에 다행히 이제 인텔은 잘 이제 멀티코로 트렌지션을 해서 특히나 이제 멀티컬을 통해서 멀티 트레딩을 통한 메모리 레이턴시이딩이라고 하는 것들을 적극적으로 이 CPU에서도 활용을 하기 시작했고요. 그거 이제 똑같은 시대에 GPU에서는 쉐이더라고 하는 셰이더 프로그래밍이라고 하는 니즈에 의해서 프로그램을 한 그런 GPU가 또 등장을 했는데 쉐이더 같은 경우에는 팩스 셰이더도 있고 그다음에 제 버텍스 셰이더도 있는데 이제 이런 애들 같은 경우에는 굉장히 많은 어벤던트한 그런 패러럴리즘이 있어서 이제 GPU 구조는 엄청나게 많은 양의 그런 이제

Attendees 1 1:31:21 인디펜던트한 계산들을 잘 처리를 하기 위한 그런 구조를 만들었는데 거기에서도 마찬가지로 이런 메모리 레이턴시를 하이딩을 하는 이슈들이 당연히 굉장히 중요했고요 데 그 대신에 GP 같은 경우에는 하나 하나의 스레드 자체의 성능은 중요하지 않았기 때문에 그런 아도 보더 엔진이라든지 하는 그런 것들은 다 빼버리고 하나의 트레드만 봤을 때는 굉장히 간단한 그런 사드지만은 그런 트레드들을 굉장히 많이 잘 때려 박을 수 있도록 하는 효율적인 그런 구조 그다음에 레이턴시를 잘 하이딩 할 수 있는 그런 스케줄링 기법 이런 것들을 잘 집접을 해서 만든 게 그럼 GPU고 그런 구조가 머신러닝과 잘 맞아서 엠비디아가 지금 머신러닝 세계에서 굉장히 각광받고 있는 그런 AI 가족들은 잘 자리를 잡았고요. 그럼 이제 GPU에 대비해서 지금 나오고 있는 새로운 AI 가속 기사들이 만든 MPU라고 하는 거는 저희가 이제 룸 레벨 패럴리즘에서 아도보드 프로세스와 vl를 비교했듯이

Attendees 1 1:32:17 똑같이 이런 레이턴시 하이딩을 트레드 레벨에서 할 수 있는 것처럼 보이는 그런 장치들을 제안을 이제 만들고 있는데 그 이제 GPU 같은 경우에는 프로그래머들에게는 그 디테일들은 걱정하지 말고 그냥 어떤 패럴한 답들이 있는지만 표현을 해 주면 그 디테일들은 이제 GPU가 알아서 처리를 하도록 되어 있는 반면에 MPU들은 그 밑에 있는 하드웨어 디테일들을 다 이제 노출을 해서 그것까지 다 고려를 해서 하나의 스레드를 실제 조그만 테스크들로 쪼개고 그 조그만 테스트들 간에 모든 상관 관계를 이제 컴팔러가 플레인을 해가지고 던져주면 수행을 하는 이런 구조로 되어 있다라고 생각을 하시면 됩니다. 그래서 정리를 하자면 아까 제가 그림을 이제 그려놓은 것처럼 룸레벨 페널리즘에서 아오브 프로세스와 VLIW 라는 이런 하드웨어적인 그 다음 소프트웨어적인 이런 기법들이 이제 대치가 됐듯이 마찬가지로 머신 러닝 세계에서도 GPU와 MPU가 똑같은 그런

Attendees 1 1:33:19 기질적인 측면에서 이런 대치가 있다라고 생각을 하시면 됩니다. 네 그래서 제가 오늘 준비한 내용은 다 끝냈고요. 네 혹시 질문이 더 있으면 몇 가지 더 받고 오늘 좀 마무리를 하면 좋을 것 같은데요 네 오늘은 어쨌든 이렇게 마무리가 되고 그리고 이제 다음 시간에는 이런 것들을 다 종합적으로 해서 지금 저희가 리벨리에서 하고 있는 있는 일들에 대해서 간단하게 오벼비를 드리고 그리고 이제 강의는 마치게 되고 그럼 이 강의 후에 어떻게 할 건가라고 하는 그런 부분들에 대해서 여러분들에게 말씀을 드리는 그런 시간이 될 것 같습니다. 네 양 님께서 VLW라이크 MPU는 어떻게 레이턴시 하이딩을 하나요? GPU는 메모리 때문에 스터를 걸리면 다른 트레이드를 사용할 수 있는데 MPU의 경우 소프트웨어가 런타임의 메모리 스토를 알 수가 없지 않을까요? 아까 말씀드린 것처럼 여기 지금 보면 이런 아키텍처 디테일들이 MPU 컴파일러한테 인풋으로 이제 전달이 돼야 되거든요 거기에 보면은

Attendees 1 1:34:25 어떤 컴퓨팅 유닛들이 있고 그다음에 이런 메모리를 옮기기 위한 유닛들은 뭐가 있고 그다음에 레이턴시는 얼마나 걸리고 기타 등등 이런 디테일들이 다 컴파일러한테 전달이 되고요. 그럼 컴파일러는 그 그런 걸 통해서 메모리 스토 그니까 메모리 때문에 어떤 테스크들이 기다려야 되는 그런 경우가 최대한 발생하지 않도록 스케줄링을 하겠죠 그리고 메모리 스토리가 어쩔 수 없이 생기게 되면 그 구간을 다른 컴퓨팅으로 잘 메꿔가지고 어쨌든 유틸라이제이션을 잘 확보를 하는 그런 스케줄링을 만들어내는 게 이 MP 컴파일러의 가장 핵심적인 역할이라고 생각을 할 수가 있겠죠. 소프트웨어가 런타임의 메모리 스토를 그래서 안다고 생각을 해야 되는 거고요. 그 이제 알 수 있는 예측을 할 수 있는 그런 이유는 아키텍처 자체가 소프트가 만든 플랜을 그대로 수행을 하도록 되어 있는 그런 아키텍처이기 때문에 그냥 네 이런 아키텍처적인 디테일을 만들어서 플랜을 그렇게 만들어 놓으면 그 플랜대로

Attendees 1 1:35:28 하드웨어가 이제 수행을 하는 거니까 그런 측면에서는 소프트웨어가 메모리 스토이 어떻게 일어날까라고 하는 것들을 잘 예측을 할 수 있는 그런 구도라고 생각을 하시면 됩니다.

Attendees 1 1:35:47 제 생각에는 버티컬 인코딩일 것 같기는 해요. 그러니까 지금 지금은 많이 바뀌어서 모르겠지만 옛날에 이제 쿠다만 있었을 때에는 쿠다 하나랑 하나가 작은 리스크라고 생각하시면 되거든요. 예 그래서 그런 측면에 있어서는 이게 트레드 멀티 트레딩이라고 하는 것들이 돼 있어서 네 뭐 그건 좀 특이하긴 하지만 하나 하나의 트레딩에 대한 기술은 그냥 리스크 인스덕션과 굉장히 비슷한 형태였었습니다. 네 인스덕션이 디테일이 공개가 로우 레벨로 안 돼 있긴 하지만은 PTX 레이어도 있기도 하고 무엇보다도 이제 그 위에 있는 코다 레벨과 그다음에 실제 코다에 들어가는 코다 코어의 제 특성 이런 것들은 공개가 돼 있었기 때문에 mbdi의 GPU는 쿠라 코어 같은 거만 이 아니라 버트 클린 코딩으로 분류를 하는 게 맞는 것 같아요. 텐서코어는 어떻게 돼 있는지는 잘 모르겠습니다. 네 혹시 질문이 더 있으면은 답을 하고 없으면 오늘 마무리를 하도록 할게요.

Attendees 1 1:36:49 네 그럼 여기서 오늘은 마치고 네 다들 네 좋은 시간 보내시고 또 다음 주에 또 뵙도록 하겠습니다. 네 감사합니다.