멀티코어/멀티쓰레드 CPU 성능의 허와 실... 블록

일단 인텔 i5-4670 CPU의 동작구조를 위와 같은 도식으로 그려봤습니다. 코어 4개가 각각 32KB로 할당돼 있는 명령어 캐쉬와 데이타 캐쉬로 연결돼 있고 그 L1 캐쉬는 각각 256KB의 L2 캐쉬로 연결돼 있으며 각 L2 캐쉬는 6MB의 L3 공유 캐쉬와 연결이 돼 있는 구조입니다. 물론 그 밑에 4GB 이상의 메인메모리가 있습니다.

여러분도 아시다시피 CPU는 한 클럭당 하나의 명령어를 처리하기 때문에 과거의 CPU는 아무리 클럭이 높아도 각각의 쓰레드(주: 윈도우 프로세스 처리 단위)를 시분할 개념으로 처리할 수밖에 없었습니다. 멀티코어로 돼 있다는 얘기는 한 클럭당 4개의 코어가 동시에 명령어를 처리할 수 있기 때문에 각각의 코어가 OS로부터 할당받은 쓰레드들을 한 클럭당 동시에 처리할 수 있음으로해서 멀티프로세싱 효과가 나타나는 것이지요.

위의 그림을 보시면 알겠지만 L1과 L2 캐쉬는 각 코어마다 할당돼 있기 때문에 L3캐쉬에서 넘어온 명령어들을 각각의 코어에서 독자적으로 처리할 수 있습니다. 문제는 L3 공유 캐쉬와 거기에 연결돼 있는 메인메모리입니다. 이 L3 공유 캐쉬와 메인메모리는 아무리 3.4Ghz 로 4개의 코어가 독자적으로 돌아간다고 하더라도 한 클럭당 하나의 데이타(주: 그게 명령어든지 데이타든지)만 상위캐쉬로 옮겨가기 때문에 병목 현상(코어가 차례대로 번갈아 가면서 데이타에 접근할 수밖에 없습니다)이 생길 수밖에 없습니다. 물론 CPU와 메인메모리를 제외한 주변장치의 병목현상은 아시다시피 훨씬 더 심각하구요.

제 이야기의 핵심은 공유캐쉬와 메인메모리에선 여전히 예전의 단일 CPU 처럼 시분할 개념으로 각각의 코어에게 데이타를 할당해 처리할 수밖에 없을 것이다란 점입니다. 각각의 코어가 L3 공유캐쉬와 메인메모리 로부터 동시에 데이타를 받아 처리할 수 있도록 하드웨어 설계가 돼 있지 않는 이상 이런 아랫단의 병목 현상은 어쩔 수 없이 발생할 거란 얘기지요. 왜냐하면 한 클럭당 모든 코어와 주변장치들이 한 프로세싱을 거치기 때문에...

여기에 멀티코어 프로세스들의 허와 실이 있다고 봅니다.

또하나, 예전의 단일 CPU인 펜티엄4 CPU도 그렇고 요사이 i7 같으면 쿼드코어에다 쓰레드만 두배로 했다는 하이퍼쓰레딩 기술을 사용했지만 여전히 코어는 전자는 한개, 후자는 4개이기 때문에 그 배가된 멀티쓰레드라는 것은 시분할로 OS가 처리하는 효과밖에 발휘하지 못할 거라는 겁니다. 엄밀히 말하면 멀티코어프로세싱 개념은 아닌 거지요.

여기까지 혹시 잘못된 내용이 있다면 덧글 바랍니다.

덧글

  • PFN 2014/06/17 10:14 # 답글

    이 병신은 무슨 분야를 들여다 보든 뻘소리밖에 안싸네
  • asdf 2014/06/17 10:32 # 삭제 답글

    ㅋㅋㅋㅋㅋㅋㅋ 그래서 지금 i5같은 다중코어 쓰는놈들이 병신이고 거지같이 아톰 CPU에 불법 XP쓰는 내가 천재다 ㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋ
    참 글 쓸때마다 이렇게 까이는것도 진짜 실력이라고 봐야지
    그러면 평생 혼자 아톰에 불법 XP잡고 딸딸이나 신나게 치던가. 밸리에 다른사람들은 i3 i5 잘만 쓰던데.

    이제 학교나 관공서 컴들도 i3나 i5달고 윈7 박아서 나오는데다 구형 xp컴 시절보다 속도역시 훨씬 빨라졌는데 정부는 병신이라 그 잘난 XP 불법으로 못쓰고 전부 윈7으로 바꾸고 있겠구만 ㅋㄷㅋㄷ
  • 래칫 2014/06/17 10:43 # 답글

    그래서 지금 멀티코어 쓰는인간들 다 병신이라 이말?

    크으... 이분 최소 발전이 뭔지 모르시는분
  • 루루카 2014/06/17 10:51 # 답글

    저, 죄송한데 이제 그만 하시면 안 될까요? 이제는 보기가 참 딱해요.

    잘못된 내용에 대한 지적을 해달라고 하셨는데, 참 어려운게 제대로 된 내용이 거의 없고 CPU 아키텍쳐부터 붙들고 설명해야 할 판이라서...
    일단, Pipeline이라는 개념을 조금 보시는 것도 흥미로우실 것 같고, 그보다도 캐쉬가 무엇인지부터 좀 확인하시면 어떨까 싶네요.
  • 래칫 2014/06/17 10:52 #

    그걸 하시는분이면 이런 개소리를 하실리가 없져!
  • 루루카 2014/06/17 10:55 #

    솔직히 인간적으로 이제 좀 안돼보여요.

    아주 극히 일부는 그나마 정상적인 발언까지도 몰아서 그냥 다 씹히는 것도 그렇구요.
  • 다져써스피릿 2014/06/17 11:12 #

    줏어들은 용어는 많은데 그 용어들이 정확히 뭘 의미하는지 모르고 혼자만의 상상의 논리를 펼치는게 장기인 사람인지라.............
  • 흠... 2014/06/17 11:05 # 삭제 답글

    현대 CPU가 저렇게 간단할 것 같으면 착각이죠.
  • 흠... 2014/06/17 11:13 # 삭제

    그리고 캐쉬레벨의 병목은 한 64코어짜리 매니코어 CPU라면 모를까 일반적인 듀얼, 쿼드코어에서는 전혀 걱정할게 아닌데 쓰잘데 없는 걱정을 하고 계시네요.
  • WeissBlut 2014/06/17 11:07 # 답글

    이분 최소 타임리프 능력자
  • 다져써스피릿 2014/06/17 11:13 # 답글

    이번엔 제가 총대를 매지요.

    팝콘 팔아요~~~ 나쵸 팔아요~~~~~ 콜라 사이다 파워에이드 팔아요~~~~~~~~~~
  • ff 2014/06/17 11:14 # 삭제

    치킨없어요?
  • 다져써스피릿 2014/06/17 11:16 #

    치킨 있습니다~~~ 양념치킨 크리스피치킨 케이준스파이스치킨 다 있어요~~~~~~~~
  • asdf 2014/06/17 11:34 # 삭제

    페퍼로니 피자에 콜라 라지 사이즈 콜!
  • 미망인제조기 2014/06/17 11:38 #

    나쵸를 주시오~
  • animelove 2014/06/17 11:45 #

    족발 삽니다
  • 래칫 2014/06/17 12:46 #

    보쌈사요
  • 긁적 2014/06/17 17:16 #

    오직 치느님!!!
  • 디베스테이터 2014/06/17 19:23 #

    아저씨 햄버거 없어요?
  • 무명병사 2014/06/19 22:59 #

    살사소스하고 나쵸랑 사이다 주세요~
  • 인간참 2014/06/17 11:26 # 삭제 답글

    http://run.iptime.org/blrun/

    전공이 전산이라는 사람이 이런 헛소리를 하고 있으니 아직까지 제대로 밥벌이를 못하지
  • 루루카 2014/06/17 11:38 #

    일단 전자 계산학과 컴퓨터 공학은 다르고, 컴퓨터 하드웨어나 물리적 구조를 잘 알기는 어려울 수도 있어요.
  • 다져써스피릿 2014/06/17 11:44 #

    잘 모르는 거 자체는 문제가 안 되죠. 사람인 이상 모르는게 있는건 당연한 거니까요.
    문제는 자기가 잘 모른다는 것을 인지 못(안) 하면서 전문가인양 행세를 하고 억지주장을 펼친다는 점.
  • Sakiel 2014/06/17 13:19 #

    이 양반 말하는 거 보면 전공이 전산일 리가 없습니다...설령 전공이 전산이라도 제대로 된 커리큘럼을 거쳤을거 같지가 않습니다..
  • 긁적 2014/06/17 17:18 #

    아니;; 모르는 건 죄가 아니죠. 컴과 졸업했어도 뭐 공부 안 했으면 모를 수도 있죠.
    근데 모르는 게 밝혀졌을 때 하는 행동이 (.....)
  • D 2014/06/17 11:31 # 삭제 답글

    잘못된 내용 지적해도 듣지 않을거면서 왜 지적해달라고 하는건지 모르겠다.
  • WeissBlut 2014/06/17 11:38 #

    +1
  • 긁적 2014/06/17 17:18 #

    +1
  • 이젤론 2014/06/17 18:01 #

    +1
  • 무명병사 2014/06/19 23:00 #

    + 1
  • k 2014/06/17 11:33 # 삭제 답글

    댁은 이글루 접지 않는 한 사람취급 해 주는 댓글 받기 힘듬
  • 2014/06/17 11:36 # 삭제 답글

    솔직히 말합시다. 손님 물건빼고는 전부 고물 아톰 쓰는거 아니면 이정도 상상력 나오기 힘들거든요? 직접 자기가 쓰는 제품 중에 다중 코어에 i5급 이상 윈7 사양 만족하면서 xp랑 윈 7속도 비교해서 윈7이 쓸데없이 버벅인다는거 영상으로 증명좀 해보쇼. 저번부터 무슨 아톰 넷북에 싱글코어급 제품 얘기만 꺼내면서 xp가 우월하다 그러다가 불법 xp쓰는거 자랑하면서 개털린거 말고도 굳이 i5급이 병목현상으로 싱글코어보다 느리다는걸 증명을 해서 보여줬음 하는데
  • 희망의빛™ 2014/06/17 11:45 #

    없는 말 만들어내지 마시죠. 전 인텔 i5급이 싱글코어보다 병목 현상이 더 많다는 말 안했습니다. ㅡ_ㅡ
  • asdf 2014/06/17 12:03 # 삭제

    본문만 보면 멀티 프로세싱이 병목현상으로 실제 속도보다 훨씬 느리게 나오는 사기 제품이다 이런식의 뉘앙스를 풍겨놓고 뭔 소립니까?

    물론 CPU와 메인메모리를 제외한 주변장치의 병목현상은 아시다시피 훨씬 더 심각하구요.

    사기칩니까? 지금? 싱글코어 까면 싱들싱들 합니까?
  • 래칫 2014/06/17 12:47 #

    반박불가잼ㅋㅋㅋ
  • 긁적 2014/06/17 17:23 #

    희망의 빛 // 아니 그럼 병목현상은 왜 언급한거임? 설명 좀.
    멀티 스레드 돌리면 데드락 문제가 있음. 그러니까 멀티스레드 돌리지 말자? 이건 아니고.

    본인이 허와 실 드립을 쳤으면 허가 뭐고 실이 뭔지를 이야기해야지. 인텔 씨퓨 설계자들이 머리가 나빠서 저런 구조를 채택했겠냐. 도대체 뭐가 '허'라는건지.

    그냥 본인한테 문제가 있다고 생각하시면 모든 게 해결됩니다 -_-
  • 희망의빛™ 2014/06/17 19:54 #

    전 싱글 코어 이후 멀티 코어가 어떤 장점이 있고 어떤 효용성이 있는지 그걸 짚고 싶었을 뿐입니다. 그리고 한계는 무엇인지 그런 것들이요.
  • 우라늄 2014/06/17 20:35 #

    희망의빛 // 근데 그 장단점 죄다 틀렸는데요?
    그리고 멀티 프로세싱과 멀티 스레딩은 완전히 별개의 용어입니다.

    또한 메모리에 대한 접근은 동일 주소에 대한 동시 접근에 대한 블록인 것이지 한 코어가 메모리에 접근하면 다른 코어는 메모리에 접근 못하고 그런개념이 아닙니다.

    읽기 락, 쓰기 락, 읽기 쓰기 동시 락 그런 개념들이 대체 왜 생겼는데요?

    그러니까 여기다 이런글 쓰시기 전에 운영체제 내부 구조 및 설계 원리라고 Wiliam stallings 씨가 쓰고 조유근씨가 번역 감수한 책 있으니 그거 한번 읽고 오세요.
  • 희망의빛™ 2014/06/19 13:53 #

    제가 언제 멀티코어와 멀티쓰레딩이 같다고 했습니까? 쓰레딩은 본문에도 적었지만 윈도우 프로세스 처리단위 아니던가요? 보통 쓰레드는 여러개 만들어 운영체제가 코어한테 시분할(Time Sharing)로 배분하잖아요. 그리고 메모리에 있는 데이타는 여러개의 코어들이 클럭당 동시에 접근할 수 없는 건 사실이지요.
  • 우라늄 2014/06/17 22:26 #

    본문부터 하나씩 짚고 넘어가겠습니다.
    각각의 코어가 OS로부터 할당받은 쓰레드들을 한 클럭당 동시에 처리할 수 있음으로해서 멀티프로세싱 효과가 나타나는 것이지요. - 여기선 여러개의 작업을 동시에 수행한다는 의미로 멀티 프로세싱을 쓰신것 같군요.

    왜냐하면 한 클럭당 모든 코어와 주변장치들이 한 프로세싱을 거치기 때문에 - 프로세싱이 아니라 프로세스라 생각하고, 말씀하신 이 문장은 멀티 프로세싱이 아닙니다. 하나의 코어가 한 클럭을 돌때 주변 모든 디바이스의 제어권을 가져간다니요? 이를 방지하기 위해 말씀하신 하스웰 시리즈cpu상에 버스와 스트리머들이 이미 내장되어 있습니다. 하드드라이브같은 자원을 사용할때 코어가 요청하면, 코어랑 하드와 1:1로 바로 통신이 이뤄지는 것이 아니라, 요청을 쌓고, 정리하는 버스가 데이터를 가져오는동안 코어는 자신이 실행하던 스레드를 멈추고 (이경우엔 입출력 블록) 다른 스레드로 흐름을 옮기는겁니다. 그러니 님이 말씀하신 병목현상같은 일이 일어나지 않도록 이미 모든게 다 준비가 완료된 상태라는겁니다.

    각각의 코어가 L3 공유캐쉬와 메인메모리 로부터 동시에 데이타를 받아 처리할 수 있도록 하드웨어 설계가 돼 있지 않는 이상 이런 아랫단의 병목 현상은 어쩔 수 없이 발생할 거란 얘기지요. - 이해를 돕기위한 이전 문장에 대한 해설입니다.
    하드웨어 적인 설계의 결함으로 인해 멀티코어로 운영체제를 돌려봤자, 멀티 프로세싱을 제대로 지원하지 못한다. 라고 하신게 맞나요? 근데 어떡합니까. 다중코어 하드웨어가 나온지 한두해가 지난것도 아니고, 이러한 문제들을 해결하기 위해 나온것이 바로 CPU 캐쉬와, http://ko.wikipedia.org/wiki/%EB%8C%80%EC%B9%AD%ED%98%95_%EB%8B%A4%EC%A4%91_%EC%B2%98%EB%A6%AC 대칭형 다중처리라는 개념인데요.
    이미 하드웨어적인 설계가 완료된 상태에 그에 맞춰 사용할 수 있는 소프트웨어가 윈도우라인업 기중 윈도우 비스타 이상의 운영체제란 말입니다.

    멀티쓰레드라는 것은 시분할로 OS가 처리하는 효과밖에 발휘하지 못할 거라는 겁니다. 엄밀히 말하면 멀티코어프로세싱 개념은 아닌 거지요 -
    제가 가장 이해가 안가는 문장이 이겁니다. WINAPI상에서 멀티스레드라는 용어는 하나의 프로세스에 여러개의 스레드를 이용한 프로그래밍 방법을 얘기하는겁니다. http://msdn.microsoft.com/ko-kr/library/y6h8hye8.aspx
    여기서 님이 멀티 쓰레드라고 사용하신 단어는 문맥상 아무리 봐도 멀티 프로세싱으로 밖에 생각되지 않습니다.
    msdn에서 멀티스레드와 멀티 프로세스로 검색하시면 마이크로 소프트가 어떻게 생각하시는지 바로 알수 있을테니 이쪽을 참고하시면 되겠군요. 왜 궂이 윈도우를 기준삼냐고 여쭤보신다면... 여태까지 이 블로그에서 제가 댓글을 달고 트랙백을 달았던 모든 내용들이 윈도우즈와 관련된 내용들이었기 때문에 당연히 그에 초점이 맞춰져 있을거라 생각했다고 답변 드리겠습니다.


    그리고 메모리에 있는 데이타는 어러개의 코어들이 클럭당 동시에 접근할 수 없는 건 사실이지요 - 애초에 CPU 내부구조가 그렇게 못하도록 막아놓은겁니다.
    cpu의 작동속도보다 메모리 입출력 속도가 훨씬 느리다는걸 알고 계실겁니다.
    그렇다면 각 코어에서 메모리 입출력을 요청하고 1:1통신이라 작업을 변경할수도 없어 값이 돌아올때까지 하염없이 기다리는게 빠를까요, 아니면 요청때리고, 기다리는동안 다른 쓰레드로 후딱 전환해서 작업을 진행하는게 훨씬 더 좋을까요. 이를 cpu 내부에서 자체적으로 관리하고, 동일한 주소에 대한 접근이 동시에 발생하지 않도록 하기위해 메모리 락이라는것이 도입되었다 이말입니다.
  • 희망의빛™ 2014/06/18 09:09 #

    1. 제 얘기는 1번지점(cpu)-2번지점(메인메모리)-3번지점(하드드라이브) 이 있다면 1번과 2번 사이에 클럭이 발생하면서 데이타를 교환할 때 2번지점과 3번지점 사이에도 클럭이 발생하면서 데이타를 교환할 것이라는 거죠. 전 그걸 클럭이 발생했을 때 한 프로세싱(처리)을 거친다고 표현했는데 1번지점과 2번지점 사이에 빠르게 데이타를 교환하더라도 2번지점과 3번지점 사이의 데이타 교환이 느리고 병목현상이 생길 때 전자 지점에서 아무것도 못하고 대기하고 있는 건 아니다라는 말씀에 동의합니다.

    2. 이렇게 주변장치는 cpu나 메모리가 데이타를 교환하는 것보다 훨씬 느리기 때문에 병목현상이 있는 것이다라고 이해하면 될 것 같습니다. 실제로 예전에 IDE 방식의 CD-ROM 써보셨는지 모르겠지만 말씀하신 지점(CPU 같은)에서 독립적으로 다른 일을 처리할 수 있었던 게 아니라 CD-ROM이 동작할 때는 이 작업 때문에 CPU 사용률이 100% 올라가 다른 일은 일절 할 수 없던 경우도 있었지요.

    3. 그리고 쓰레딩이라는 개념은 여러개의 쓰레드를 한개의 코어에 할당하든지 몇 개의 코어에 나눠서 할당하든지 전자는 시분할로 그 쓰레드를 처리할 것이고 후자는 멀티프로세싱으로 처리할 것이라는 점을 말씀드린 겁니다.

    4. 또 말씀하신 메모리 데이타로 접근이 어려울 때 프로세스가 다른 일(or 쓰레드)을 처리할 것이다란 사실엔 동의합니다. 하지만 메모리 접근에 병목이 생겼으니 그 작업의 한계는 분명 있을 것이겠죠.
  • 우라늄 2014/06/18 14:41 #

    1. 적어도 용어는, 상호간의 불필요한 오해와 잘못된 단어 선택으로 인한 개념의 곡해를 막기 위해서라도
    기술서적에서 가장 일반적으로 사용되는 사례를 기준으로 작성해 주시기 바랍니다. 특히나 이쪽분야에 비슷비슷하게 생겨먹은 단어들이 실제로는 안드로메다와 지구사이만큼 큰 거리를 두고 있는 경우도 많잖습니까?

    2. 님이 생각하시는 병목이라는것이 정확히 어떤 개념인지 알고 싶습니다.
    단순히 프로세스가 메모리 작업이나, 디바이스 작업을 요청하고 블록상태로 빠지는것을 병목이라 할리는 없을텐데, 님이 병목현상이 일어난다고 말하는 기준 자체가 무엇인지 그에 대해 (반드시 레퍼런스를 곁들여) 자세히 설명좀 해주셨으면 좋겠습니다.
    저는 병목현상에 대해 이미 다양한 해결방법이 존재한다고 말씀 드렸고, 하드웨어상으로 안되면 소프트웨어상으로(운영체제상에서) 병목현상을 눈에 띄지 않는 수준으로 없앨수 있다. 라고 얘기했는데, 그냥 느리니까 병목이다 라고만 말씀하시니, 왜 그런지에 대해서 설명해 주셔야 한다고 생각합니다.

    3. IDE 저도 써봤습니다. 아버지께서 설계관련 일을 하시기에 제가 5살무렵부터 집에 컴퓨터가 있었고, ms도스에서부터 윈도우 3.1, 95, 98, xp, 비스타, 7, 8까지 어지간한 운영체제는 다 겪어봤습니다.(다행히 me의 경우 아버지가 회사에서 써본 소감상, 이건 도저히 못써먹을 물건이라고 집에 가져오지도 않으셨습니다.)
    근데 그건 지나치게 과거의 얘기 아닌가요? 우린 지금 현재 시판되고, 곧 개발이 완료될 하드웨어를 대상으로 논의를 하는 중이고 클릭 실수로 존재하지도 않는 a 드라이브에 접근하느라 컴퓨터가 10초도 넘게 드르륵드르륵 거릴 필요도 없는 컴퓨팅 환경에서 인터넷을 하는데 그 당시의 병목현상을 지금시대에 대입한다는게 옳지 않다는 생각은 안드시나요?
  • 희망의빛™ 2014/06/18 15:50 #

    그래서 제가 사용한 용어가 이해가 안되시나요? 무슨 표준 용어를 사용하라고 그렇게 강요를 하시는지... 전 그런거엔 관심없고 CPU 동작원리에만 관심이 있습니다. 그리고 공유캐쉬와 메인 메모리의 병목 현상은 이미 다 여러번 다 말씀드렸기 때문에 더 이상 말씀드리지 않겠습니다만 다시한번 설명드리자면 공유캐쉬와 메인메모리는 어차피 멀티코어가 시분할로 접근하는 것이기 때문에 병목 현상이 생긴다는 것을 말씀드렸던 것입니다. 혹 여기에 대하여 이견이 있으신 건 아니시겠죠? 그리고 자꾸 병목 현상이 주변장치에서 일어나지 않는다고 주장하시니 IDE 장치를 예를 들어 설명했던 거구요. 생각해 보세요. 연탄 나르기를 밑에서 위쪽으로 몇명의 사람이 죽 늘어서 옮기는데 어떤 사람은 한번에 10개씩 나르고 다른쪽 사람은 한번에 1개씩 나른다면 당연히 병목 현상이 생기지 않겠습니까? 전 그런 원리를 말씀드렸던 겁니다. 또다른 예를 들자면 하드에 수십기가 바이트의 데이타를 카피하는데 느린 하드가 동작할 때 CPU는 물론 말씀하신대로 다른 연산을 할 수도 있겠지만 그때도 카피되는 데이타가 시분할로 쓰레드 처리가 되지 않으면 멀티코어는 제대로 다른 일을 처리할 수 없을 겁니다. 왜냐하면 카피되는 데이타도 메모리를 거쳐 CPU가 나르는 것일테니까요. 이 단순한 원리를 제가 친절히 설명한 것이었는데 왜 딴죽을 못걸어 난리인지 모르겠습니다.
  • 루루카 2014/06/18 16:49 #

    희망의빛™ 씨,
    자꾸 IDE라는 용어를 예로 들어 강조하시고 대용량 파일 복사 병목(CPU 점유)을 말씀하시는데, 그 전에 DMA라는 것에 대해서 한 번 찾아보기실 바랍니다.
    그리고 용어라는 것의 표준이 중요한 이유는 자신이 가진 생각을 상대에게 전달할 때 어떠한 표준 프로토콜로서 서로 오해가 없이, 또한 용어로 정의된 부분에서는 부연 설명 없이 원활한 의사소통을 위해서임에도 그런건 관심없다고 하신다면, 그건 상대와 의사소통을 하지 않겠다는 의미밖에 안 됩니다.
    가령 통신을 하는데, 표준 프로토콜을 무시하고 자신만의 데이터를 전송하면 그건 통신이 불가능해지겠지요?
  • 다져써스피릿 2014/06/18 16:56 #

    최소한 전문가를 자처하고 싶으면 용어는 제대로 쓰셔야죠. 사과를 배라고 하고서 "비슷하게 생겼고 내가 무슨 얘기하는지 다 이해할테니까 오케" 이러면 대체 누가 전문가라고 인정해주겠습니까.
  • 우라늄 2014/06/18 17:40 #

    그리고 자꾸 병목 현상이 주변장치에서 일어나지 않는다고 주장하시니 IDE 장치를 예를 들어 설명했던 거구요.
    이렇게 말씀하셨는데, 압니다. 병목현상자체는 우리가 매번 운영체제를 부팅할때마다 겪는 현상이니 주변장치에 의해 병목현상자체가 발생할 수 있다는것은 인정합니다.
    그러나 단순히 운영체제의 부팅시 발생하는 병목현상만 가지고 얘기를 하려 한다면 제가 이렇게 길게 글을 썼겠습니까?

    하지만, 운영체제의 시작은 지금 말하고 있는 프로세스, 스레드, 코어와 관련된 부분과는 거리가 동떨어져 있습니다.
    제가 말씀드리고자 하는 바는, 특정 프로세스가 특정 주변장치의 사용을 요청할때 그것이 다른 프로세스에 전혀 영향을 주지 않는 방향으로 운영체제가 설계 되었고, 또 그렇게 작동한다는 사실입니다.

    먼저, 한가지 짚고 넘어가겠습니다.
    님이 말하는 병목현상은, 주 기억장치나 캐쉬나 주변장치등 어느곳에서 병목현상이 발생할 때 그걸 실행시킨 하나의 프로세스만 영향을 받는게 아니라 전체 코어가 모두 다 영향을 받으니 제대로 된 멀티프로세싱을 지원하는것이 아니다 라는 말인가요?

    일단은 이렇게 이해하고 진행하겠습니다.

    더불어, CPU의 동작원리에 관심있다고 하셨는데,
    그렇다면 지극히 당연히도 그 CPU에서 프로세스가 실제로 어떻게 처리되는지도 관심을 가지셔야죠.

    자 그러면 님이 본문에서, 그리고 댓글에서 누차 강조한 전역 캐쉬와 주 기억장치인 RAM 에 의해 병목현상이 발생하고 모든 코어가 일을 처리하지 못해 버벅거릴 수 있다. 라는 주장이 어째서 잘못되었는지, 레퍼런스와 같이 설명해 드리도록 하겠습니다.

    일단 이 링크를 읽어보시기 바랍니다.
    http://en.wikipedia.org/wiki/CPU_cache#Cache_entries
    https://www.google.co.kr/url?sa=t&rct=j&q=&esrc=s&source=web&cd=8&ved=0CGwQFjAH&url=http%3A%2F%2Ffaculty.washington.edu%2Flcrum%2FTCSS372AF09%2F5_Cache.ppt&ei=i0qhU8CfEs2PuATYgILABQ&usg=AFQjCNGiYnNV-mwKD5Omvyo9ui5Oh-xajg&sig2=NGigLkfIVRqVKJex45UE3w&bvm=bv.69137298,d.dGc&cad=rjt
    하단 링크는 ppt 링크입니다. 클릭시 주의.
    그래도 영어 단어도 쉽고, 내용도 친절하게 잘 설명되어 있으니 가급적 읽어보시는걸 추천합니다.

    일단 옛날의 컴퓨터는 cpu 내에 캐쉬가 없었습니다. 그렇기 때문에 연산장치는 주 기억장치와 직통회선으로 소통을 했어야 했고, 어차피 멀티프로세스 그런건 존재하지도 않는 시절이었기에 이러한 방식은 큰 문제가 없었습니다.
    그러나 시대가 점점더 발전하고, 기기 주변의 장치들이 복잡해지고, 증가하고, 고속화되고, 다양해짐으로써 하나의 회선으로 모든걸 처리하는것은 ....
    But, this would be very costly
    네, ppt에 나와있듯이 엄청난 비용이 소모되었습니다.

    그래서 공학자들은 cpu 내에 캐쉬 메모리를 추가하기로 했습니다. 어차피 한번 실행시킨 프로세스는 상당기간동안 메모리 안에 살아 있으니까, 장치에서 프로그램을 읽어오고나 종료하고 메모리를 해제시키는 시간을 다소 희생시키더라도 캐쉬를 도입해 프로그램 자체를 좀더 빠르게 만들자.

    네, 캐쉬를 도입함으로써 병목이 생긴것이 아니라, 병목을 해결하기 위해 캐쉬를 도입한 것입니다.
    물론 이것 자체도 완벽하지 않습니다. 네트워크 인터럽트, 파일 입출력 등 주변기기를 사용하는 연산행위는 그 행위의 특성상 언제 발생할지 모른다 라는 엄청나게 커다란 문제가 존재하거든요.
    하지만 이러한 노력 자체가 완전히 헛된것은 아닙니다.

    님은 예시로 10명이 순차적으로 연탄을 나르는것과 한명이 혼자서 연탄을 나르는 것으로 설명하셨는데,
    이게 아닙니다.

    기존의 캐쉬가 존재하지 않던 cpu가 10명이 순차적으로 연탄을 나르는 것이라면,
    현재의 컴퓨터 구조는 4명이 차에서 연탄을 내리고(명령어를 처리하고) 전문가 한명이 배달 주소별로 연탄 갯수를 기입하고(메모리 컨트롤러와 같은 장치 컨트롤러) 전문가 한명이 주소별로 기입되고 분류된 연탄더미를 지게에 지고 한번에 마을 앞까지 옮기고(요청의 전송), 나머지 전문가 4명이 각집에 연탄을 배달(실제 요청의 처리)하는 구조 라는겁니다.

    각각의 역할이 구조적으로 완벽하게 분리되어 있으니, 각 단계에서 병목 현상이 일어나더라도 그에 전혀 지장을 받지 않고 작업을 진행할수 있는 구조가 되었단 말입니다.
    자, 예시로 연탄을 집앞까지 옮기는 도중 한 사람이 중간에 넘어져서 배달이 중단되었다고 해봅시다.(장치의 오류로 인한 작업 중단)
    님이 말씀하신 10명이 동시에 나르는 구조라면, 순차적으로 나르던 중간에 문제가 생겼으니 모든 작업이 중단되어야 하겠죠. 다시 다른 집까지 (다른 명령의 수행까지) 순서를 복구하는데도 시간이 많이 걸릴테고요.
    98 시절 a드라이브에 디스크를 넣지 않은채 더블클릭 했을때 발생하는 문제를 생각하면 되겠군요.
    그럼 제가 말씀드린 경우는 어떨까요.
    각 집에다 연탄을 배달하던 4명중 한명이 중간에 다쳐서 움직이지 못하더라도, 다른 장치와의 통신도, 연탄을 내리는 사람들도, 연탄을 분류하는사람도, 연탄을 마을까지 옮기는 사람도 모두 정상적으로 작업을 하고 있겠죠?

    더불어 이런 장점도 있습니다.
    님이 말씀하신 열명이 나란히 서서 연탄을 나르는 것은 연탄을 단 한장 나르더라도 어떻게든 열사람이 모두 순서대로 서서 연탄을 옮기고 다시 원위치로 복귀하는, 엄청난 낭비가 뒤따라야 하지만,
    제가 말씀드린 방법은 어떤가요, 연탄을 마을로 옮기는 사람 하나, 마을에서 집 앞으로 배달하는 사람 하나.
    딱 두명만 움직이면 충분하잖아요?

    또한, 파일 복사에 의한 병목현상에 대해 말씀하셨는데,
    http://ko.wikipedia.org/wiki/%EC%A7%81%EC%A0%91_%EB%A9%94%EB%AA%A8%EB%A6%AC_%EC%A0%91%EA%B7%BC
    윗분이 말씀하신대로, 파일 복사에 의한 보조기억장치의 읽고 쓰기에 대한 병목현상은 발생할 수 있어도, cpu에서 파일을 바이트 단위로 읽어오고, 다시 그걸 디바이스에 전달하는 복잡한 과정자체가 위의 DMA(직접 메모리 접근) 방식의 특허권리 해제로 인해 해결된 상태입니다.

    주변장치의 데이터는 장치 컨트롤러에 의해 로컬 버퍼로 이동한다. 그러나 전송할 데이터가 많은 경우, 많은 양의 데이터의 이동으로 인한 부담이 커지는데 이러한 문제를 해결하기 위해 DMA를 이용한다. 장치 컨트롤러가 데이터의 한 블록을 이동시키는데 이 과정에서 DMA로 인해 CPU의 개입이 필요없게 된다. CPU에서는 데이터 이동이 완료되었다는 단 한 번의 인터럽트만 발생한다. 데이터가 전송되는 동안 CPU는 다른 작업을 수행할 수 있게 되어 효율성이 높아진다.

    이제 좀 이해 되시나요?

    그럼 파일 이동 과정이 표시되는것은 무엇이냐? 이건 운영체제상에서 실제 디바이스의 파일 입출력 내역을 조회할 수 있기 때문입니다. 단지 그게 평상시에는 사용자의 눈에 겉으로 드러나지 않을 뿐이죠. (써보셨을리 없겠지만) 윈도우 8 환경에서 작업 관리자에 들어가시고 대용량 파일 복사작업을 수행해 보시면 파일 입출력 그래프와 cpu 점유율 그래프가 완전 따로 노는것을 손쉽게 확인하실 수 있을겁니다.
    7에서는 입출력 그래프가 표시되어있지 않아 정확한 확인은 어렵지만, 크게 다르지 않을거라 생각합니다.

    이쯤되면 이해 되셨습니까?
    제발 이젠 멀티코어에서 캐쉬를 사용함으로써 병목현상이 발생한다! 그러니 멀티코어는 한계가 있다! 라는 주장을 그만봤으면 좋겠습니다.
  • 우라늄 2014/06/18 17:43 #

    아, 한가지 빼먹었네요.

    우리가 지금 사용하는 컴퓨터라는 물건은 컴퓨터를 틀고나서부터 끌때까지 처음부터 끝까지 항상 풀로드 쌩쌩 돌릴 것을 상정하고 만든 물건이 아닙니다.
    알지못하는 시점에 한계치 까지 부하가 걸릴수도 있지만, 아무런 할일 없이 탱자 탱자 놀고 있을 수 도 있다. 라는것을 가정하고 만들어진 물건입니다.
    서버를 돌리는 컴퓨터라면 그럴수 있기야 하지만,
    그러면 서버용 컴퓨터를 사야지 왜 클라이언트 용을 사나요.
  • 희망의빛™ 2014/06/19 13:43 #

    컴퓨터의 동작원리를 전체적으로 잘 설명해 주셨네요. 잘 읽었습니다. 전 CPU 캐쉬가 메모리 병목현상을 해결하기 위해 생겼다고 했지 그것 때문에 병목현상이 생겼다고 말한적 없습니다. 그리고 DMA에 대해서 말씀하셨는데 저도 그 기술이 처음 출현했을 때 언뜻 듣기는 했습니다. 제가 우라늄님이 제시해 주신 문서를 보고 이해하기론, "CPU가 데이타를 어디에서 어디로 옮기라고 명령하면 DMA 컨트롤러가 하드에 있는 데이타를 메모리로 옮기고 그때 CPU는 다른 일을 할 수 있으며 일정량의 데이타가 메모리로 옮겨지면 CPU가 그 데이타를 정확히 어디로 옮길지 알려주고 그때 DMA 컨트롤러는 그걸 직접 메모리에서 하드로 다시 옮겨주는 역할을 한다" 라고 이해했습니다. 그거 맞지요? 물론 이때 다른 쓰레드가 돌더라도 메모리 접근은 CPU(or 운영체제)가 시분할로 처리할 것이겠구요.

    근데 한가지 의문점이 드는게 예전에 UDMA DVD-RW에서 CPU 병목현상이 생겼던 건 왜 그랬던건지 모르겠네요 이제보니... 분명 하드는 UDMA가 잘 동작하는것 같았는데 DVD-RW는 전혀 그렇지 않았거든요. 하드와의 병목현상 때문일까요?
  • 우라늄 2014/06/19 12:03 #

    하드에서 작동하는데 cdrom 에선 작동안한다... 라는 것은
    알려주신 정보만으로는 파악이 힘듭니다.

    바이오스에 따라 cdrom 의 udma 설정이 기본이 off로 지정된 경우도 있고, cdrom 엔 애초에 udma 가 지원되지 않는 메인보드를 쓰는 경우 등 생각할수 있는 경우의 수 자체가 워낙 많거든요.

    dma에 대해 다시 한 번 설명 드리면,
    일단 dma 는 어떤 컨트롤러나 장치가 아니라, 장치 컨트롤러에서 사용하는 기법입니다.

    메모리에서 하드로 1GB 짜리 통짜 파일을 넘긴다고 봅시다.

    그러면 cpu는 하드의 장치 컨트롤러에 파일의 저장이 시작된다고 알리고, 파일 핸들을 넘겨줍니다.
    하드 장치 컨트롤러는, 받은 핸들위치부터 자신이 알아서 파일을 기록하기 시작하고, 매 블록(하드드라이브의 포맷에 따라서 512바이트 혹은 그 이상의 크기가 될 수 있습니다.) 마다 cpu를 향해 (정확히는 파일 전송을 요청한 프로세스에) '지금 n번째 블록 들어갔다!' 라고 메시지를 보냅니다.

    댓글에 적으신 내용과 약간 다른 부분이 있어서 보충 설명을 적었습니다.


    더불어, 전 CPU 캐쉬가 메모리 병목현상을 해결하기 위해 생겼다고 했지 그것 때문에 병목현상이 생겼다고 말한적 없습니다.
    라고 말씀하셨는데,
    이 L3 공유 캐쉬와 메인메모리는 아무리 3.4Ghz 로 4개의 코어가 독자적으로 돌아간다고 하더라도 한 클럭당 하나의 데이타(주: 그게 명령어든지 데이타든지)만 상위캐쉬로 옮겨가기 때문에 병목 현상(코어가 차례대로 번갈아 가면서 데이타에 접근할 수밖에 없습니다)이 생길 수밖에 없습니다. 물론 CPU와 메인메모리를 제외한 주변장치의 병목현상은 아시다시피 훨씬 더 심각하구요.
    여기선 분명히 L3 공유 캐쉬로 인해 병목현상이 발생한다고 말씀하셨기에 캐쉬의 병목현상에 대해 제가 얘기했던 것이고요.

    아래 리플에 어떤분이 다신
    http://www.parkoz.com/zboard/view.php?id=over_freeboard&page=1&sn1=&divpage=6&sn=off&ss=on&sc=off&select_arrange=headnum&desc=asc&no=17252
    파코즈 링크에 들어가시면 님이 올리신 i시리즈 cpu의 작동방식에 댓글로 길고 친절하게 설명되어 있으니 이쪽을 확인하시는게 훨씬 더 정확할 겁니다.
  • 희망의빛™ 2014/06/19 14:06 #

    제 이전 덧글 중에 "왜냐하면 카피되는 데이타도 메모리를 거쳐 CPU가 나르는 것일테니까요." 이 부분이 DMA의 기능을 놓고 봤을 때 잘못 전달된 내용일 수 있겠네요. CPU가 나르는게 아니라 저장장치에서 CPU 통제로 메모리를 거쳐 날라진다는 표현이 더 정확할 것 같습니다. 링크하신 cpu 작동 방식은 지금 읽고 있습니다.
  • 악의곰푸우 2014/06/17 12:19 # 답글

    캐시를 쓰는 이유가 버스의 경합을 줄이자는 것 포함입니다.
  • 희망의빛™ 2014/06/17 12:28 #

    아 그렇군요. 버스의 폭은 일정한데 그 안에서 소통하는 데이타는 많고 다양하니까 캐쉬를 사용하는 이유도 되겠네요. 버스 내에서 데이타의 소통을 원활하게 하기 위해서 캐쉬를 사용하는 것이겠죠. 좋은 말씀 감사합니다.
  • 넉터 2014/06/17 13:08 # 삭제 답글

    그만큼 캐시 효율이 높다는 것이지요.
    말씀하신 내용에 의하면, 그냥 L1 캐시를 메모리처럼 늘여서 사용하는 방법이 베스트라고 생각이 드는데,
    일단 비싸죠. Memory hierarchy 를 사용하는 첫 이유는 바로 비용입니다. 아마 그런 CPU가 나오면 왜이리 비싸냐고 글 쓰실지도 모르겠네요.
    그리고 또 다른 이유로는 두 코어 간 데이터 공유 메커니즘도 또다른 오버헤드 비용으로 듭니다. 사실 이부분도 상당히 큰 비용이지요. 이부분은 결국 본문의 내용과 같은 맥락인데, 코어 하나 당 대용량 캐시를 두어도 여전히 해결되지 않는 문제입니다.
    참고로, Dual port ram과 같이 입출력 포트가 여러개인 메모리도 존재하기는 합니다. 다만, 이렇게 되면 coherence 유지 비용은 올라가겠지요. 그게 하드웨어로 구현되든, 소프트웨어로 구현되든.

    정리하면, 말씀하신 내용이 고려가 되고 되어서 나온 구조가 현재의 모습이라는겁니다.
  • 넉터 2014/06/17 13:09 # 삭제

    좀 더 사족을 붙여보겠습니다.
    캐시 효율이 높다는 이야기를 적은 이유는
    캐시 효율이 그만큼 높기 때문에 메모리까지 갈 확률도 그렇게 높지 않고, 결국 말씀하신 문제가 발생할 확률도 걱정할 정도로 높지는 않다는 이야기가 됩니다.
    이 부분은 아키텍쳐적인 영향도 있지만 소프트웨어 프로그래머의 최적화도 한 몫을 합니다. 최대한 캐시 효율을 높이게 프로그램을 작성하는 것이지요.
  • 식용달팽이 2014/06/17 13:43 # 삭제 답글

    일단 아직도 이러고 사는 이 분에게 존경을 표합니다. 이만큼 욕 들어 먹었으면 그만할 법도 한데... 무한 체력이네 ㅎㅎㅎ

    그리고 멀티코어 개념에서 하드웨어적인 부분보다 더 중요한 건 OS나 프로그램에서 각 코어에 얼마나 적당량의 데이터를 효율적으로 분배해 주느냐에 있습니다.

    맥 OSX과 iOS에서는 그 부분을 해결하기 위한 Grand Central Dispatch가 있는 거고... 윈도는 그 부분만큼은 약하죠. 프로그래머가 알아서 멀티코어 지원을 짜야 하니...

    좀 글 같은 거 올리시려거든 공부 좀 하고 올리면 안 됩니까? 컴퓨터 관련 전공도 안 하고 취미 삼아 컴퓨터 보는 나보다도 모르는 게 안쓰러워 그럽니다.
  • 우라늄 2014/06/17 13:53 # 답글

    님. 솔직히 까놓고 말해서 이런글 진짜 병신같아요.

    지금 님 글 읽어보면 이건 아무리 봐도 병목, 캐쉬, 쓰레드, 선점, 분할에 대해 용어자체를 제대로 모르고 있다고 밖에 생각 안되거든요?

    어차피 저 올해 졸업이라 운영체제 과목 책은 딱히 볼일 없을듯 하니 주소 불러주심 제가 2학년때 수강한 과목 전공서적 한권 보내드릴테니 제발 그거 읽고 이딴글좀 쓰지 마세요.
  • 우라늄 2014/06/17 13:59 # 답글

    진짜 운영체제 과목 각잡고 B 나올정도만 공부해도 다 알수 있는 내용을 뭘 내가 깨달은게 진리다! 라는식으로 혼자 신나서 북치고 장구치고 하시는거죠?

    거기다, 이런 기술적 내용에 마땅히 따라와야 하는 레퍼런스는 다 어따 팔아먹었습니까?
    실험결과라도 있나요?

    하다못해 위 두개라도 있으면 몰라도 이것조차 없는 님 글은 그냥 산업폐기물이에요. 가치가 없다고요.
  • 오오 2014/06/17 14:53 # 답글

    CPU만드시는 분들이나 개발자 분들이 그렇게 돌대가리는 아닌데...
  • MH 2014/06/17 15:06 # 삭제 답글

    이걸 해결해서 팔아먹는겁니다...... 아... 인텔에서 멋져보이는 파란색 아키텍쳐책 무료로 보내주니까 그거 신청해서 보세요. 물론 전공교재는 다 읽고나서- _-;; 캐쉬에 대해 쓰신글 보니까 교재부터 정독하셔야 할 필요성이 보이긴 합니다.
  • 나인테일 2014/06/17 15:07 # 답글

    모바일까지 그 전기 쳐먹는 멀티코어를 다 가고 있으니 퀄컴도 애플도 인텔도 다 병신이군요. 엉엉.
    뭐? 삼성은 코어가 8개라고?ㅋㅋㅋㅋㅋ
  • ㅇㅇ 2014/06/17 16:15 # 삭제 답글

    밸리에서 이건 뭔 병신인가 하고 들어와봤더니 컨셉인가보네요... 낚임
  • 긁적 2014/06/17 17:14 # 답글

    ㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋ
    아놔 진짜 병먹금원칙을 깨게 만들 정도의 병신력이네. 인정.

    지역성이라고는 들어본거냨ㅋㅋㅋㅋ
    ps : 쟤 수준에서라면 객체지향의 특성상 지역성이 약화되어가고 있다는 이야기를 하려낰ㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋ
  • jei 2014/06/17 17:24 # 삭제 답글

    이양반 아직도 이러고 노는군

    제발 공부좀하고 올리시죠?? 검색으로 찾아보기만해도 저딴 개소리 안할텐데 검색할 생각 자체가 없는건지 아님 일부러 이러는건지 참
  • 발로 한다 2014/06/17 19:30 # 답글

    우와... 이렇게 컴퓨터에 해박하시니 분명 컴퓨터 관련 직종에서 오랜 경력 쌓으시고 높은 연봉 받으시겠죠?
  • IEATTA 2014/06/17 22:29 # 답글

    암만 봐도 블레이드처럼 어글 유발한다음 나오는 정보가지고 책 쓸거 같은데...
  • 윤소정 2014/06/17 22:47 # 답글

    ☆★8코어 엑시노스 최강 병신이랍니다 이글 내려주세요☆★
    ☆★8코어 엑시노스 최강 병신이랍니다 이글 내려주세요☆★
    ☆★8코어 엑시노스 최강 병신이랍니다 이글 내려주세요☆★
    ☆★8코어 엑시노스 최강 병신이랍니다 이글 내려주세요☆★
    ☆★8코어 엑시노스 최강 병신이랍니다 이글 내려주세요☆★
    ☆★8코어 엑시노스 최강 병신이랍니다 이글 내려주세요☆★
    ☆★8코어 엑시노스 최강 병신이랍니다 이글 내려주세요☆★
    ☆★8코어 엑시노스 최강 병신이랍니다 이글 내려주세요☆★
    ☆★8코어 엑시노스 최강 병신이랍니다 이글 내려주세요☆★
    ☆★8코어 엑시노스 최강 병신이랍니다 이글 내려주세요☆★
    ☆★8코어 엑시노스 최강 병신이랍니다 이글 내려주세요☆★
    ☆★8코어 엑시노스 최강 병신이랍니다 이글 내려주세요☆★
    ☆★8코어 엑시노스 최강 병신이랍니다 이글 내려주세요☆★
  • Sakiel 2014/06/17 22:50 # 답글

    그냥 하는 말인데, 전공자들이라면 다들 가지고 있는 공룡책 하나 정돈 사서 읽어보고 얘기하셨으면 좋겠습니다. 요새 한글판 번역 잘 돼 있어요..
  • 에리카 2014/06/17 23:09 # 삭제 답글

    이런 분들도 공대인데 저도 공대 가면 안될까요? 상경계열 너무 힘드네요.
  • ChristopherK 2014/06/17 23:30 # 답글

    그냥 ARM 싱글 쓰시면 되겠네. 저전력에 싱글코어니까..
  • 달세뇨 2014/06/18 00:05 # 답글

    CPU가 캐시에서 데이터를 읽어오는게 아니라
    캐시가 CPU에게 데이터를 전해주는 마술
  • 달세뇨 2014/06/18 00:06 # 답글

    그리고 저기 대체 Graphics 4600은 왜 들어가있는지? L1,L2, L3 캐시가 내장 그래픽 극딜이라도 하나요?
  • 희망의빛™ 2014/06/18 09:13 #

    메인 메모리 까지 묶어서 HD 그래픽과 연계시키기 위해 편의상 그랬습니다.
  • 란에드린 2014/06/19 11:51 # 답글

  • 희망의빛™ 2014/06/19 17:15 #

    글 잘 읽었습니다.

    링버스를 읽고 의문점이 든 게 4개 코어에 동시에 먹히는 클럭이 발생할 때 과연 링버스에 올라온 L3 캐쉬에 있는 데이타가 각각의 코어나 내장 HD 그래픽 GPU에 어떻게 할당돼 들어가느냐겠느냐 하는 의문점이 생기더군요. 결국 L3 캐쉬의 링버스 구조라는 게 L3 캐쉬 안에 들어있는 각각의 데이타가 링 위의 서로 다른 공간에 놓여 있으며 여기에 들어있는 데이타를 요청한 멀티코어나 CPU 내장 그래픽 쪽으로 데이타를 건네주는 방식이란 얘긴데 이건 결국 클럭을 매번 발생시키면서 링버스를 순환(쉬프트)시키는 식으로 링버스 구조를 구현했다는 이야기겠죠. 결국 클럭을 먹일 때마다 쉬프트된 위치에 따라서 각 코어가 데이타를 집어서 처리할 수 있는 일치도는 올라갈 수도 떨어질 수도 있다는 이야기네요. 물론 L3 캐쉬로부터 데이타를 가져온 코어는 그 이후부터 독립적으로 데이타를 동시에 처리할 수 있는 거구요. 결국 멀티 코어도 클럭이 높아야지 쉬프트 할 수 있는 빈도는 올라갈 것이고 L3 캐쉬와 연결된 링버스에서 집어올 수 있는 일치도에 따라 멀티코어 효과가 높아질 수도 낮아질 수도 있는 거네요.

    그리고 두번째 하이퍼쓰레딩은 좀 의아심이 듭니다. 사실 하이퍼쓰레딩을 사용할 때 스케줄링 오버헤드가 발생할 것 같으면 OS에서 코어들에게 쓰레드를 분배하여 처리하면 될 것을 뭐하러 하이퍼쓰레딩을 만들었느냐는 겁니다. 즉 안쓰이는 레지스터나 회로를 OS 단에서 사용해 처리하면 될 것을 왜 하이퍼쓰레딩이란 개념을 만들었나 하는 점입니다.

    마지막으로 CPU가 한 클럭당 하나의 명령어를 처리한다는 것은 예전의 16bit나 32bit CPU 시절의 이야기라는 얘긴데 요샌 64bit 멀티코어 CPU가 도입됐으니까 각 코어에 64bit 레지스터가 여럿 들어있을 것이 분명하니 한번에 처리할 수 있는 명령어는 늘어났다는 이야기인 것 같네요. 하지만 OS 업그레이드로 데이타나 인스트럭션 명령어가 64bit 로 늘어난다면 레지스터 수가 한정돼 있으니 처리할 수 있는 명령어 갯수도 줄어들 수밖에 없을 겁니다.
  • 우라늄 2014/06/19 16:08 #

    이제 점점더 전공수준을 넘어가기에,
    이부분의 설명의 경우는 저도 부족한 부분이 상당부분 있을 수 있습니다.

    더불어 제가 주로 삼는 분야가 문어발인 경향이 있고, 개중 대다수가 로우레벨보다는 하이레벨의 어플리케이션의 구현과 관련되 있기에 이쪽은 확실하게 이렇다 라고 답을 내리지 못합니다.

    그리고 두번째 하이퍼쓰레딩은 좀 의아심이 듭니다. 사실 하이퍼쓰레딩을 사용할 때 스케줄링 오버헤드가 발생할 것 같으면 OS에서 분배하는 쓰레드를 코어들에게 분배하여 처리하면 될 것을 뭐하러 하이퍼쓰레팅을 만들었느냐는 겁니다. 즉 안쓰이는 레지스터나 회로를 OS 단에서 사용해 처리하면 될 것을 왜 하이퍼쓰레딩이란 개념을 만들었나 하는 점입니다.

    이때문에 한때 인텔의 하이퍼쓰레딩이 하이퍼쓰레기라고(...) 불리기도 했습니다.

    광고 문구상으로는 하나의 코어가 실제로 두개의 코어처럼 행동한다! 라고 했지만, 알고봤더니 게임같이 cpu 처리량 혼자 다 잡아먹고도 더 처묵하는 프로세스가 오히려 느려지는 현상이 발견됬기 때문이죠.
    요새는 처음 하이퍼 쓰레딩이 처음 나왔을때 만큼은 아닌 것으로 알고 있습니다.
    검색해보니, 성능상에 정말 많은 발전이 이뤄져, 동영상 인코딩이나, 연산이 많은 작업에선 확실한 이점을 나타낸다는듯 하네요.
    http://www.coolenjoy.net/bbs/cboard.php?id=27&no=39128&page=1&num=36953&board=27&ss=0&sc=0&sn=0&keyword=&qa=0&ga=&cat=0&vote=0

    더불어 OS는, 어느정도 표준화가 따라야 하는 프로그램입니다. 같은 64비트라 하더라도, 샌디브릿지와 아이비브릿지의 명령어셋과 처리 방식에 다소 차이가 있지만, 똑같은 운영체제가 정상적으로 작동하는 것 처럼, cpu의 자율에 연산을 맡겨야 하는 부분이 존재할 수 밖에 없다고 볼 수 있을겁니다.

    마지막으로 CPU가 한 클럭당 하나의 명령어를 처리한다는 것은 예전의 16bit나 32bit CPU 시절의 이야기라는 얘긴데 요샌 64bit 멀티코어 CPU가 도입됐으니까 각 코어에 64bit 레지스터가 여럿 들어있을 것이 분명하니 한번에 처리할 수 있는 명령어는 늘어났다는 이야기인 것 같네요. 하지만 OS 업그레이드로 데이타나 인스트럭션 명령어가 64bit 로 늘어난다면 레지스터 수가 한정돼 있으니 처리할 수 있는 명령어 갯수도 줄어들 수밖에 없을 겁니다.

    64비트 자료형을 기준으로 대략적으로 설명 드리면,
    64비트 덧셈 연산을 32비트 명령어 셋으로(32비트 OS 상에서) 처리하면 하위 32비트의 연산, 상위 32비트의 연산, 자리올림 총 세번의 덧셈을 수행하고, 메모리에 4번 접근해야 합니다. (cpu 레지스터 셋에 따라 다소 차이가 있을 수 있습니다.)
    그러나 64비트 환경으로 이를 연산하면 단 두번의 메모리 접근, 단 한번의 덧셈 연산만으로 이를 처리가 가능합니다.
    대충 보더라도 수행시간이 1/2에서 1/3사이 정도로 단축된다고 할 수 있습니다.
    32비트에서 64비트로 업그레이드 한다는 것은, 단순히 문자셋을 64비트로 올린다 그런 개념이 아니라, 한번에 2배의 데이터를 한꺼번에 처리하고, 64비트에 맞춰 설계된 아키텍처를 100% 활용한다는 것을 의미합니다.

    또한 이게 cpu 연산 파이프 라인과도 연관된 내용이기도 한데,
    cpu의 명령어는 한 클럭당 한 명령어가 바로 처리되는 것이 아닙니다.
    http://nerve.tistory.com/52
    위의 링크의 이미지는 대략적인 모식도를 나타낸 것으로, 예제로 든 i5 시리즈의 파이프 라인과는 전혀 다른 내용임을 인지 바랍니다.

    이런식으로, 하나의 연산도, 각 단계로 나눠져 진행되고, 그에 따라 작동하는 회로와 작동하지 않는 회로가 분리되어 있기에, 동시에 여러개의 명령어를 하나의 코어에서 처리가 가능하다는 얘기 입니다.

    어떻게 명령어를 처리하는데 작동하는 회로와 작동하지 않는 회로로 분리가 가능하냐. 라는 질문에 대해서는....
    http://ko.wikipedia.org/wiki/%EA%B0%80%EC%82%B0%EA%B8%B0
    cpu자체가 이러한 회로가 눈으로 보일지 않을 정도로 빽빽하게 밀집해 있어서 각 부분별로 담당하는 내용이 전해져 있다... 라고밖에 설명할 길이 없네요.
    이부분은 다른 전문가의 도움이 필요합니다.

    이제, 이부분과 연관지어 1번문단을 설명하자면,
    기존의 관념, 그러니까 cpu 의 1 클럭이 전체 디바이스작동의 기준이 된다 라는 생각은 더이상 맞지 않다는 겁니다.
    거기다 말씀하신 내용과는 약간 다른방식으로 링버스가 작동합니다.
    링버스는, 클럭에 따라 데이터가 쉬프트 되는 어떤 컨트롤러를 지칭하는 것이 아니라, 서울 외곽순환고속도로 위의 차량과 같이, 각 데이터는 목표하는 장소를 향해 링버스 위를 타고 곧장 흘러가는 겁니다.
    http://avenuel.tistory.com/1379
    여기에 보시면 링버스의 작동방식에 대한 이미지를 확인하실 수 있습니다.
    추가로 cpu를 향해 전송되는 데이터도, cpu가 링버스 위에서 데이터를 뽑아 올리는(가져오는) 것이 아니라, 링버스와 연결된 TD(이것이 뭐의 약자인지 모르겠네요) 에 전달된 데이터를 다시 들고오는 방식이라 볼 수 있습니다.
  • 우라늄 2014/06/19 16:12 #

    아, 한가지 빼먹었네요,

    64비트 레지스터에선 32비트 명령어 두개를 두개처리할수 있을테니 분명 속도가 두배 나올거야.
    라고 생각하고 계신듯 한데...

    문제는 전혀 그렇지 않습니다.

    64비트 레지스터에는 입력받은 값이 32비트든, 16비트든, 8비트든, 1비트 T | F 값이든 상관없이 반드시 한번에 하나만 처리가 가능합니다.
  • 희망의빛™ 2014/06/19 17:08 #

    ㅋㅋ 레퍼런스 해주신 문서는 꼭 예전 '컴퓨터 구조' 란 책을 들여다 보는 느낌이네요. 어쨌든 부연 설명 고맙습니다. 레지스터와 주변 회로 이야기를 종합해 보면 64bit 레지스터는 64bit 까지의 데이타를 한 클럭당 한번만 넣고 빼낼 수 있고 다른 레지스터 역시 다른 회로에 존재하면서 동시에 값이 더해지고 빼지고 하는 식으로 동작해서 몇개의 명령어를 한 클럭에 처리할 수 있다는 이야기인가요? 상당히 복잡한 매커니즘을 단순하게 정리해 봤는데 맞을랑가 모르겠네요. ^^;

    그리고 링버스 구조 설명하신 거는 저로선 도저히 이해가 안가는 부분이네요. 컴퓨터가 클럭에 맞춰 동작하는 디지털 기기라고는 하지만 근본적인 매커니즘은 아날로그라서 그런지 저로선 그 대목은 이해가 안갑니다 솔직히... ㅋㅋ 어떤 단순한 매커니즘이 있을 거 같은데 제가 말씀드린 방식이 아니라고 하니 저로선 그게 무엇인지 디게 궁금해 지기도 합니다.

    맞어 그리고 파이프라인은 레지스터를 이용해 명령어를 효율적으로 처리하는 방법 같은데 상당히 복잡해 보입니다. 여러단계의 처리과정을 거친다는 사실이 중요한 내용인 것 같습니다. 그래서 최신 CPU들의 동작 매커니즘을 이해하는 게 어려운가 봅니다. ㅡ_ㅡ;
  • 우라늄 2014/06/19 17:14 #

    네, 대충 그렇다고 생각하시면... 될겁니다 아마도... 한번에 여러개의 명령어를 중첩하여 실행시키는 구체적인 원리가 어떻게 되는지는 이건 제가 영어 원문을 봐도 해석이 힘든 부분이라...

    하기야, 누구나 이걸 대충 훑고서 바로 이해할 정도로 내용이 쉽다면, 이런걸 만들려고 박사학위 따고 외계인 고문 시킬 필요도 없겠지만요

    더불어 최신 cpu에서 32비트 xp를 쓰는것이 최신 cpu를 혹사시키는 이유는.... 64비트로 표현해야 할 자료형을 32비트로 쪼개고 - 다시 연산하고 - 64비트로 합치는 번거로운 작업을 수행하기 때문입니다. (그밖에도 최신 cpu의 명령어셋을 제대로 지원 못한다던가.. 등등등 여러 문제점이 존재합니다.)
    64비트가 안쓰일것 같지만, 가장 쉽고 단순한 사례가 하나 있죠.
    파일 용량, 하드디스크.
    32비트로는 약 2,000,000,000(signed 기준) 까지, 그러니까 약 2기가가 한계입니다. 물론 여기에 페이지 할당과 같은 내용이 들어가면 좀더 커지긴 하지만, 각 파일은 페이지 할당같은것이 들어가지도 않으니까 정말 64비트를 쓰지 않고는 표현할 방법이 없다고 봐야겠죠.

    링버스의 경우, 고속도로를 이용하는 퀵서비스를 생각하시면 괜찮을듯 합니다.
    코어에서 요청이 있으면 L2 캐쉬를 통해 링버스에 요청을 보내고, 목적지는 해당하는 값을 담아 다시 링버스에 값을 보내면, 값은 링버스를 따라 쭉 돌다가 목적지에 도착하면 알아서 들어가는 방식 이라는 것이죠.
  • 적왕슈리 2014/06/19 18:18 # 삭제 답글

    .....대충 여기저기서 읽어본 내용을 본인이 알고 있는 한정적 지식에 맞춰서 이해한 다음 그걸 그대로 글로 적으니까, 이런 일이 벌어지는 겁니다. 더군다나 본인이 가진 지식중에서도 이미 옛날CPU들에서나 적용될 법한 지식이 지금도 변함없이 통용될 것처럼 이해하고 있으니 추가되는 정보들에 대해서도 제대로된 정보 습득이 될리가 없습니다.

    링버스를 알고 싶나요? 이곳에서 사람들에게 물어봐서 알려고 하지 말고 좋게 전공서적이나 전문자료를 찾아서 한번이라도 제대로 읽어보세요. 가능하면 영어 원문으로 된 것으로요. CPU의 구조를 알고 싶나요? 전공 서적 읽으세요. 컴공정도면 다들 최소한 기본으로 보는 공룡서적만 해도 파이프라인에 대한 기초 개념은 나옵니다. 요즘 씨피유들의 변화를 알고 싶나요? 인텔이나 AMD같은 회사들의 주요 프레젠테이션 자료나 그것에 대해 분석해놓은 해외전문 자료들을 꼼꼼히 보시고, CPU제조사 들이 제공하는 데이터시트화일들이라도 한번 더 들여다 보세요.

    인터넷에서 한글로 남이 써놓은 자료나 대충 추려내서 번역해놓은 잡다한 자료들 읽고 뭔가를 이해하려 하지 말고 전공서적이나 전문자료를 통해 지식을 습득하세요. 그래야 CPU는 무조건 한클럭당 하나의 명령어를 처리한다는 등의 시대착오적인 엉뚱한 이야기가 안나올 수 있습니다.
  • 희망의빛™ 2014/06/21 20:52 #

    그렇게 완벽하게 알아보고 글을 쓰면 정말 좋겠지만 그러면 시간이 너무 오래 걸리고 힘들겠지요. 저는 어느 하나 주제를 정하고 그걸 사유의 과정을 통해서 파헤치는 스타일이라 인텔 직원이 와서 토론을 해줘야 완성이 된답니다. 물론 저도 필요하면 레퍼런스를 찾아보지만 미흡한 부분이 많고 그 부분은 토론을 통해서 수정해 나가야 하겠지요. 저도 허무맹랑한 망상을 글로 적는 건 아니니까요. 좋은 충고 고맙습니다. ^^;
  • k 2014/06/22 03:45 # 삭제

    토론이 아니라 가르침을 듣는거겠지
  • ad 2014/10/15 00:29 # 삭제 답글

    성순리제 합니다
  • 덕분에.. 2014/11/04 13:16 # 삭제 답글

    쓰레기 글에 달린 뎃글 덕에 많은 공부가 되었습니다. 감사합니다. 이 글은 쓰레기지만 뎃글이 좋네요. 뎃글때문이라도 이글은 안지우는게 좋다고 봅니다.
  • 메닉 2014/12/14 10:06 # 삭제 답글

    저는 이런 글 전혀 나쁘지 않다고 생각합니다. 모두가 컴퓨터 전공자도 아니고 잘 알 수는 없기 때문입니다.
    다만 문제의 요지는 본문 글을 읽어보면, 마치 논문을 작성중인 연구원이 새로운 이치를 깨닫고 세상에 알리는 듯한
    늬앙스의 느낌이 들어서 논란이 되는 것 같은데, 저를 포함해서 대다수가 컴퓨터에 대해서 정확히는 모른다고 생각합니다.
    저도 댓글 보고 오히려 공부가 되었네요.
    다만 저 같은 경우 기사 이상 급 컴퓨터 관련 자격증도 여러 개 보유중이고, 프로그래밍도 해봤고
    컴퓨터 사용한지 20년이 훨씬 넘지만 어디가서 컴퓨터 가지고 왈가불가는 절대 안합니다.
    하지만 이런 태도와 용기 분명이 좋습니다. 비판하시는 분들도 계시지만 맹목적인 비판보다는 지적과 보완을 해주는 게 소통이라고 생각됩니다. 우리 사회가 망가지는 이유중에 하나가 무조건 남을 깍아내리고 비판만 할 뿐, 정확한 지적이나 충고는 안하는 문화가 있기 때문에 오늘날 국회의원들이나 사회전반적인 문제가 생긴다고 생각합니다.
  • 전박 2015/04/19 12:22 # 삭제 답글

    요즘 cpu는 한 사이클에 한개의 명령어를 처리하는게 아니라 다수의 명령어를 처리 합니다.
    cpu 내부 명령어들이 많이 발전해와기때문에 ...
    대표적으로 SSE fpu 등 여러 유닛이나 명령어들이 존재함.
  • 안식 2015/09/22 09:40 # 삭제 답글

    글은 개인의 짐작을 쓰셨네요
    덧글을 통해서 많이 배우고 갑니다.
  • 케르베로스 2015/10/05 15:20 # 삭제 답글

    병렬 컴퓨터(Parallel Computer)의 이론과 실제를 모두 경험했던 제가 볼 때 본글 쓴 이의 지적은 유효합니다. 본글 쓴 이가 그린 그림은 병렬 컴퓨터 이론에서는 Synchronous PRAM(Parallel Random Access Machine) Model이라고 얘기합니다. 저는소싯 적에 병렬 컴퓨팅을 전공했고 실제 병렬 컴퓨터 Sequent machine에서 병렬 프로그래밍까지 해봤던 사람입니다. 멀티 코어 CPU라는 것도 알고 보면 병렬컴퓨터의 초미니 버전이라고 볼 수 있습니다. CPU p개 짜리 병렬컴퓨터를 사용한다고 처리 속도가 반드시 p배로 빨라지지는 않습니다. 여러가지 제약이 따릅니다. 동일 자원이나 인접한 자원에 액세스할 가능성이 높은 프로세스들일수록 Interprocess communication이 증가하게 되고 이는 최악의 경우 p개의 cpu가 싱글 cpu로까지 퇴화하는 퍼포먼스를 보여줍니다. 동일한 자원이나 인접한 자원에 접근할 가능성이 극히 낮은 프로세스들끼리 동시에 돌아간다거나 아니면 동일 자원이나 인접한 자원에 접근한다 하더라도 상호 충돌의 소지가 없게 아주 정교하게 분배 처리가 가능한 문제를 p개의 다중 CPU에 분배해서 처리한다면 p배의 speedup을 가져올 수는 있습니다. 하지만 그런 문제는 극히 제한되어 있고, 일반적인 경우에는 아예 이론적으로도 p배의 speedup이 불가능한 경우가 대부분입니다.

    80~90년대에 한 때 병렬 컴퓨터 제조회사들이 꽤 생겨났던 적이 있습니다만 지금은 왜 다 망하고 없을까요? 대표적인 회사가 바로 Sequent사입니다. 병렬 컴퓨팅의 본질적 한계와 실제적 오버헤드를 극복하지 못해서입니다. 본질적인 한계란 병렬 컴퓨팅 이론 분야에서 판가름이 나버린 것을 두고 하는 말입니다. 싱글 CPU에서 O(f(n))의 시간으로 풀 수 있는 문제를 p 개의 CPU를 사용한다고 해서 O( f(n) / p)의 시간으로 풀 수는 없다는 게 밝혀져 있습니다. 사실 유치한 수준의 문제를 제외하면 컴퓨팅 이론과 실제에서건 마주치는 대부분의 문제는 p배의 speedup을 이룰 수 없는 문제가 대부분입니다. 예를 들어 n개의 숫자의 단순 합산은 p배의 speedup이 가능하지만, n개의 숫자를 크기 순으로 정렬하는 문제는 그렇지 못합니다. 이는 기술적인 제약이 아니라 문제의 수학적 성격의 차이로 인한 한계입니다. 마치 NP-complete 클래스의 문제에 대해 Polynomial time 알고리즘이 없는 것과 비슷합니다. 다음으로 기술적 제약으로는 이론적으로 p배의 speedup이 가능한 문제일지라도 실제 병렬컴퓨터에서는 인접한 메모리 주소에 접근할 경우 아무리 신박한 캐싱/파이프라이닝 알고리즘과 기술을 적용해도 p배의 speedup을 달성하지 못하기 때문입니다.

    그러면 인텔의 멀티코어 CPU들은 어떻게 된 걸까요? 인텔은 p개의 코어를 사용한다고 해서 p배의 speedup을 보장하지는 않습니다. 인접하지 않고 상호 충돌의 소지가 없는 자원들에 따로 따로 접근해서 처리하는 경우 최고 p배의 속도가 날 수 있는 아키텍쳐를 제공하는 것 뿐입니다. 그것을 제대로 활용하는 문제는 전적으로 프로그래밍 을 하는 측에 떠넘기고 있는 겁니다. 동일 자원 또는 인접 자원에 동시 접근해서 생길 수 있는 각종 문제들은 전적으로 프로그래밍 - 그것이 OS이건 응용 프로그램이건 - 의 책임으로 넘기고 있는 겁니다. 예) deadlock. mutual exclusion, synchronization 문제 등.

    병렬 프로그래밍이나 분산 프로그래밍은 말이 쉽지 실제에서는 너무도 어려운 작업입니다. 프로그래머 직군의 극극극소수도 안된다고 봐도 됩니다. 그러면 인텔의 멀티코어 CPU들은 어떻게 활용되고 있을까요? 인접한 자원에 접근할 가능성이 아예 없는 프로세스들이나 작업 순서에 영향을 받지 않는 게 확실한 프로세스들을 동시 처리하는 데에나 사용되고 있는 게 정확한 현실입니다. 그리고 멀티코어를 제대로 지원하는 프로그램은 극소수입니다.

    그래서 인텔의 멀티코어 CPU는 CPU 기술이 정점에 달해가면서 인텔이 내놓은 막바지 시장 전략으로 약간의 눈속임 성격이 있다고 볼 수 있습니다.
  • 희망의빛™ 2015/10/05 17:07 #

    그렇군요. 장문의 덧글 잘 읽었습니다. 포스트와 관련한 병렬 컴퓨팅의 허와 실에 대해서 말씀해 주신 듯 합니다.
  • 아니근데 2015/10/05 16:01 # 삭제 답글

    질문자의 질문과 댓글에 대처하는 자세가 훌륭한편이라고 생각하는데 왜들 이렇게 비아냥 대시는지 모르겠네요..
    다른대서 싸지른 똥이있나..?
    그나저나 여기 댓글 단 사람들 츤데레 만렙찍은거같네요
    욕하면서도 대답들은 잘해주시네요
    근데 몇몇 분들은 질문이랑은 전혀 상관없는 내용으로 아는척하면서 질문자 까내리는게 우습네요
    질문자 반에 반도 모르는거같은데
    솔직히 공룡책 다봐도 충분히 들법한 생각인데 말이져
    맞는 말이기도 하구요
  • 희망의빛™ 2015/10/05 17:09 #

    ^^; 드물게 이런 글도 보게 되네요.
  • 포켓토이 2015/11/19 14:01 # 삭제 답글

    흠 다른걸로 인터넷 검색하다가 이런 엉뚱한 글에 들어오게 되다니..
    근데 댓글이 재미있어서 저도 몇글자 남깁니다.
    사실 희망의빛님이 가진 의문은 아주 합리적인 것입니다. 비매너 댓글들은 무시하세요.
    제가 보기엔 댓글단 사람중에도 제대로 된 전공자는 거의 없는 것 같은데..
    제가 근본적인 답을 드리겠습니다. 희망의빛님이 지적하신 부분은 모두 정확합니다.
    다만 실제 CPU가 연산하면서 메모리에 접근한다는게 의외로 높은 비중이 아니라는게
    문제겠지요... 이건 컴파일된 어셈블리 소스를 보면 간단하게 이해할 수 있습니다.
    메모리에서 데이터를 읽거나 쓰는 경우는 아주 드뭅니다. 한 10줄에 한줄 정도?
    대부분의 코드는 레지스터에 있는 데이터를 이리저리 가공하는겁니다.
    게다가 메모리에서 데이터를 읽고 쓰는 경우도 높은 확률도 스택에 있는 데이터에 접근하는겁니다.
    이런 식으로 로컬라이징된 데이터는 캐쉬 히트 확률이 매우 높을 수 밖에 없습니다.
    캐쉬 히트를 안하려면 힙에 있는 데이터에 수시로 접근해야 하는데 보통 그런 식으로 프로그램을
    만들지 않습니다. 보통은 스택에 있는 변수로 복사해와서 사용하죠. 아니 애초에 컴파일러가
    알아서 메모리 접근 횟수를 최소화하는 방향으로 최적화해줍니다.
    실제로 CPU의 캐쉬 히트 확률은 보통 80%를 넘어간다고 합니다. 5번 메모리 접근을 시도하면
    실제로 하는건 1번뿐이라는거죠...
    정리하자면
    1) 애초에 메모리에 접근하는 일 자체의 비율이 낮다
    2) 프로그래밍 스킬과 컴파일러 최적화로 원래 낮은 비율을 더욱 낮출 수 있다.
    3) 1)과 2)에 걸러지지 못하고 메모리 접근을 한다고 해도 80% 이상 확률로 캐쉬에 데이터가 있어서
    구지 메모리까지 가지 않는다
    그러다보니 메모리 접근에서 병목 현상이 발생해도 그게 전체 성능 저하에 미치는 영향은
    미미할 수 밖에 없는 것입니다. 물론 캐쉬 히트율을 극단적으로 떨어뜨릴 수 있도록 메모리
    여기저기를 막 읽고 써대는 프로그램같은걸 만들면 성능 저하가 꽤 일어나겠지요.
    그리고 케르베르스님 댓글도 그리 정확하지는 않은게.. 어차피 모든 슈퍼컴퓨터는 병렬컴퓨터입니다.
    그리고 멀티코어 활용에 관한 기술은 상당 수준에 이르렀습니다. 가깝게는 얼마 전에 구글에서
    발표한 GO언어가 있겠지요. GO언어는 언어 차원에서 멀티 쓰레드를 자연적으로 사용할 수 있게
    하기 위해 최적화된 언어입니다. 저도 써봤는데 상당합니다. 지금은 멀티코어를 사용하기 위해
    프로그래머가 상당히 노가다를 해야하지만 GO언어가 보급되면 그것도 옛날 얘기가 될 것입니다.
  • 희망의빛™ 2016/07/25 15:37 #

    좋은 말씀 감사드립니다. 저도 많은 도움이 되었습니다. ^^; CPU가 캐쉬에서 데이타를 가져오지 메모리에 까지 가서 접근해 가져오는 일이 그리 많지 않다는 말씀이군요. 하지만 브라우저 몇개를 띄워놓고 보면 메모리가 금방 다 꽉차긴 하더라구요. ^^;
  • 포켓토이 2015/11/19 15:57 # 삭제 답글

    아 그리고.. 애초에 여러개의 코어를 모두 100%로 돌리는 일 자체가 쉽게 발생하질 않아요.
    특별한 류의 과학적 계산 프로그램같은거면 모를까
    뭔가 입력이 있고 거기에 반응해서 출력을 내놓는 모양의 프로그램은 CPU를 100% 사용한다는게
    불가능에 가깝습니다. 당장 윈도우 작업관리자를 열어서 CPU사용량을 보세요.. 100%로 올라가는
    경우가 있기는 한건지...
    애초에 병목이 문제가 될려면 모든 코어가 100%로 빈틈없이 일하고 있어야 의미가 있는건데
    애초에 코어들이 한 50% 정도씩만 돌고 있다면? 서로서로 노는 틈에 메모리에
    접근하면 되는데 무슨 병목이 의미가 있겠습니까..
    그러면 CPU 클럭이 높아봤자 무슨 의미가 있냐고 생각할 수 있는데 이건 CPU의 성능을 평가할때
    2가지 기준이 있기 때문입니다. 쓰루풋과 리스폰스 타임입니다. 예를 들면 1+1을 한번 계산했을때
    결과를 내놓기까지 걸리는 시간이 리스폰스 타임이고 연속으로 1+1을 반복계산할때 1초에 몇번이나
    계산할 수 있느냐가 쓰루풋이죠. 클럭이 높으면 당연히 둘다 높아지는데 병목으로 영향받는건
    쓰루풋뿐입니다. 리스폰스타임은 CPU사용률이 100%가 되기 전엔 병목으로 영향을 받지 않습니다.
    그리고 설사 모든 CPU코어가 100%로 일하고 있다고 해도 병목은 많은 지장을 주지 않습니다.
    왜냐면 이전 댓글에도 썼지만 CPU코어가 돌고 있다고 해도 보통의 경우 메모리 억세스를 하는
    opcode의 양은 10% 이하입니다. 90%의 나머지 시간동안은 메모리에 접근하지 않습니다. 즉?
    메모리에 접근하는 타이밍이 서로 틀리면 당연히 병목은 발생하지 않겠죠.
    코어A와 B가 있을때 설사 둘다 100%로 돌고 있더라도 A가 메모리 접근을 안하고 있을때
    B가 메모리 접근을 하면 병목은 발생하지 않는겁니다.
    병목이 발생하려면 정확하게 동시에 메모리 접근을 시도해야 하는데... 당연히 확률이 낮겠죠?
    이런 저런 이유로 인해서 지적하신 병목 문제는 사실상 영향을 별로 안끼치는겁니다.
    뭐 그렇더라도 문제가 아닌건 아니고.. 사실 수많은 다른 노력들로 인해서 문제의 영향력이
    줄어서 그렇죠. 메모리 병목은 병렬 프로그래밍에서 가장 큰 문제죠.
  • 2016/07/13 15:17 # 삭제 답글 비공개

    비공개 덧글입니다.
  • 아는만큼 보인다 2016/12/28 09:12 # 삭제 답글

    아주 좋은 글이군요
    멍청이들이 개거품 물던데
    글의 요지도 모르는거지요

    글의 요지는 시피유가 지아무리 좋아도 주변장치 메모리나 저장장치에서 병목현상 일어날수 밖에 없다는 거죠
    모르는 바보들은 그걸 이해못하는거죠 모르는 바보들은 SSD놔두고 HDD에 원도우 설치하겠다는거죠

    또 모르는 바보들은 구형 다중코어 제온이 좋다고 구형 DDR3 쓸놈들이죠
    멍청이들은 특정 프로그램에서나 빠르면 되니 전체 처리량을 모르는거죠

    아마도 앞으로 기술이 발전하면 메모리라는 개념이 없어질껍니다 캐시라는 개념도
    저장장치가 그만큼 속도가 발전할것이니깐





  • 아는만큼 보인다 2016/12/28 09:17 # 삭제 답글

    멍청이들이 많은 사회는 똑똑한 사람이 바보로 보일수가 있습니다

    외눈박이 동네가 가면 두눈가진 분이 한쪽눈을 감아야됩니다
    그리고 다른 생각을 가졌다고 틀렸다고 몰아가는 인터넷 댓글 문화가 사라져야 됩니다

    멍청이들이 고어텍스 좋다고 다입고 다니면 나도 입고 다녀야 되나 싶기도 하고
    멍청이들이 제온좋다고 하면 나도 제온 써야 되나 싶기도 하고
    선입견과 편견이 무서운 거죠 더군다나 무지한 인간들은 그럴꺼다 추측의 선입견으로 가득차 있으니
    두눈으로 뜨고도 못보는 거죠





  • 조현병윤찬이 친구냐 2018/07/01 20:57 # 삭제

    조현병 윤찬이 옹호하는 병신이 있네.
댓글 입력 영역
* 비로그인 덧글의 IP 전체보기를 설정한 이글루입니다.


웹로그 검색