[고객센터] 프로그래머가 몰랐던 멀티코어 CPU 이야기 by 김민장

저의 허접한 졸저를 읽다가 발생한 모든 문제를 다루는 '고객센터'입니다. 질문, 의견, 잡담 모두 환영합니다.

아래에 한빛미디어 홈페이지에 있는 1쇄 오타를 제가 중요도에 따라 정리하여 엑셀/PDF로 만들었습니다. 정말로 사소하다 싶은 것은 몇 개 삭제하고, 오탈자 정도에 따라 별표 0개에서 3개까지 매겼습니다. 오타가 생각보다 많은 것은 변명의 여지가 없습니다. 거의 2년 반 정도 끈 책이다 보니 제가 수시로 원고를 굉장히 많이 고쳤습니다. 그러다보니 고쳐도 고쳐도 오타가 나왔네요.

1쇄 오타 목록(2010년 8월 8일 갱신): PDF 다운받기, 엑셀 다운받기

심심해서 이런 저런 이야기...

이 책은 직접적인 프로그래밍 지식을 키우는 것을 목표로 하지 않았습니다. 병렬 프로그래밍이나 멀티스레드 버그에 대한 이야기가 후반부에 나오지만, 병렬 프로그래밍은 이렇게 한다~ 라는 것을 가르쳐주지는 않습니다. 그보다는 최신 프로세서의 '작동 원리'를 앎으로써 프로그램을 만들 때 밑거름이 될 수 있는 지식을 전해 드리고 싶었습니다. 정말 컴퓨터 밑바닥에서 일어나는 작동 원리만 알면 멀티스레드/병렬프로그래밍도 쉽게 할 수밖에 없습니다(뻥 아닙니다). 그래서 바로바로 써먹을 수 있는 프로그래밍 지식보다는 당장에는 큰 도움이 안 되더라도 긴 시간을 두고서는 피가 되고 살이 될 수 있는 이야기를 써보고자 (아 손발이 오그라드는군요)했습니다. 안타깝게도 이런 내용은 보통 어렵고 따분하고 지루하죠.

또, 최신 CPU에 적용된 알고리즘이 얼마든지 일반 소프트웨어에서도 성능을 높이는데 적용 가능하다는 것을 알려 드리고 싶었습니다. 특별히 (1) 프로세서가 어떻게 온갖 병렬성을 얻어내어 프로그램을 빠르게 처리하려고 하는가, (2) 어떻게 프로그램의 행동을 관찰하여 미래의 행동을 예측해 성능을 높이는가, 이런 알고리즘에 집중해 설명하려고 노력했습니다. 정말이지, 이 책은 하드웨어 책이 아닙니다. 그냥 디지털 하드웨어는 결국 프로그래밍 언어로 표현 가능한 알고리즘을 실행시키는 장치라는 사실만 알면 됩니다. 거짓말 조금 보태, 이것만 알아도 CPU 작동 원리는 이해할 수 있습니다.

그렇지만, 제가 아무리 쉽게 쓰려고 노력은 했지만, 그래도 많은 분이 어렵다고 평을 해주셨습니다. 저도 동의합니다. 이 책은 출퇴근하는 지하철이나 침대에 느슨히 누워 대충 읽을 내용은 솔직히 아닙니다. 그렇지만, 더도 말고 덜도 말고 새로운 프로그래밍 언어를 배우듯이, 알고리즘/자료구조 책을 보듯이만 하시면 별 내용 없잖아? 라고 생각하실 수도 있습니다. 가볍게 읽을 내용 보다는 한 문장 한 문장 생각을 깊이 해야 할 때가 많은, 어떻게 보면 교과서적인 책입니다. 그래서 책 제목을 좀 잘못 지었다는 생각이 드네요. "프로그래머가 몰랐던 멀티코어 CPU 작동 원리"로 했어야...

우리나라의 컴퓨터 전문서 시장은 매우 작습니다. 음악 시장에 비유하면 딱 클래식/하드코어 재즈입니다. 일반 소설/인문사회 베스트 셀러가 걸그룹이나 일반 가요라면, 컴퓨터 분야는 클래식과 아주 비슷합니다. 인기 베스트셀러 책은 하루에도 2천 권씩 팔린다고 합니다. 아마 소녀시대가 새 음반을 내면 이 정도로 팔리겠죠? 그런데 클래식 음반계는 몇천 앨범만 팔려도 잘 팔았다고 합니다. 인터넷 서점 중 가장 큰 yes24의 베스트 셀러의 판매 지수는 단위가 수십 만을 훌쩍 넘습니다. 그런데 컴퓨터/인터넷 분야는 1등을 해도 5~6만, 그것도 입문서이죠. 제 책은 가까스로 판매 지수 1만을 넘었습니다!! (...) 음악 시장에 비유하자면 제 책은 클래식 중에서도 인기 있는 쇼팽 음악이 아닌 마치 정격 음악 같은 주제일지도 모릅니다.

그럼 모든 분에게 감사드리면서...

덧글

  • whiterock 2010/07/21 11:42 # 삭제 답글

    감사히 잘 보고 있습니다. :)
  • lqez 2010/07/21 12:30 # 삭제 답글

    저도 감사히 잘 보고 있습니다. 다음 책이 기대되네요.
  • 김민장 2010/07/21 12:55 # 답글

    ㅋㅋ 제가 책 사줘서 감사하다능;;
  • 박신구 2010/07/21 13:19 # 삭제 답글

    책 재미있게 보고 있습니다.
    예전에 학교 교재로 보던 어셈블리 언어 책보다.
    훨씬 쉽게 이야기 해주셔서 감사합니다.
  • 김민장 2010/07/22 12:47 #

    감사합니다.. 흑흑..
  • drvoss 2010/07/21 13:27 # 삭제 답글

    좋은책 써 주셔서 감사합니다. 그런데 윗 댓글의, 다음책이 기대 되네요? 라는말은 다음 책 저술하고 계신가요?
  • 김민장 2010/07/21 13:30 #

    아니요; 졸업해야해서 당분간 헛짓 거리는 절대 없어요~ ㅎㅎ 아이템은 몇 개 있습니다;;
  • bluegene 2010/07/21 16:27 # 삭제 답글

    정말 재미있게 봤습니다. :)
    (말씀하신대로 이쪽은 몇천권만 팔리면 나름 팔린 것이 더군요;;)
  • 김민장 2010/07/22 12:46 #

    그래도 입문서 시장에서 대박내면 큰 돈(!)을 번다고 합니다 ㅎㅎ
  • hongyver 2010/07/22 08:00 # 답글

    책 지루하지 않게 재밌게 읽고 있습니다.
    예전 인사이드 머신 읽다가 난해하고 지루해서 읽다 말았는데 이 책읽고 다시 읽어 봐야겠습니다.
  • 김민장 2010/07/22 12:43 #

    감사합니다. 저도 인사이드 머신을 벤치마킹(?)했었습니다. 그 책으로 기본 구조를 이해하기는 좀 벅찬 것이 사실입니다. 일단 구성이 너무 뒤죽박죽이지요. 비순차 실행 같은 것은 그냥 '펜티엄', '펜티엄 프로'를 설명하면서곁다리로 설명할 내용이 아닌데 좀 통찰력있는(...) 설명이 약간 부족했고요. 전반적으로 특정 프로세서를 예로 들어 설명하다보니 전공자가 아닌 사람에게는 쉬운 책이 아닙니다. 기본 컴구조만 이해하면 인사이드 머신은 꽤쉽게 이해하실 수 있습니다 ^^
  • 소드피시 2010/07/22 12:14 # 답글

    전 병렬처리에 관심이 좀 있었어서 그런지 책이 술술 잘 넘어가고 있습니다~
    머리속에 들어는 있지만 설명하라면 막 꼬이고 있던 내용들이
    책 읽고나니 훨씬 깔끔하게 정리되는것 같아 매우 좋습니다!!
  • 김민장 2010/07/22 12:46 #

    휴~ 잘 넘어간다고 하시니 다행입니다.
  • 하용호 2010/07/22 17:23 # 삭제 답글

    그간 블로그글들을 늘 재밌게 읽어왔습니다.
    요 잠시 정신 놓고 살다가 오랜만에 왔더니 이런 좋은 책을 내셨군요.
    당장 주문하러 가야겠습니다.
  • 김민장 2010/08/03 12:44 #

    감사합니다!
  • CECRI 2010/07/26 02:17 # 삭제 답글

    저도 컴퓨터 구조시간에 배웠던 것들이 스믈스믈 기억나는게 재밌네요 ㅎㅎ 본문에 우리나라 컴퓨터 전문서 시장이 작다고 하셨는데 반물리학도 입장에서 물리학 전문서 시장이 딱 컴퓨터 전문서 정도만 되도 엄청 좋을것 같아요 ㅎㅎ 사실 따지고 보면 우리나라 전문서 시장중에 거의 제일 크지 않을까 싶긴 하지만 본문은 다른 나라를 염두해 두신 것이겠죠? ^^
  • 김민장 2010/08/03 12:44 #

    맞습니다. 물리학에 비하면 컴퓨터는 양반이죠. 아마 전문서 시장 중에서 가장 클 것 같네요.
  • dyanoa 2010/07/26 20:50 # 삭제 답글

    저도 감사히 잘보고 있습니다 ㅎㅎ
  • 김민장 2010/08/03 12:44 #

    감사합니다!!
  • wallis 2010/07/28 13:09 # 삭제 답글

    책 나오자마자 구입했고,
    어려운 내용을 쉽고 편하게 써주셔서 잘 보고 있습니다.
    한권으로 끝내지 마시고 후속작들도 써 주셨으면 좋겠습니다.
  • 김민장 2010/08/03 12:43 #

    졸업하고 나면 몇 개 더 써볼까 생각만 하고 있습니다 ㅎㅎ
  • pizon 2010/08/03 10:28 # 삭제 답글

    오옷~ 이제 책 받았네요 블로그도 항상 잘 보고 있는데, 이런 책까지 내주셔서 감사합니다~ 책도 읽기 편한 사이즈로 잘 빠졌네요 잘보겠습니다!!
  • 김민장 2010/08/03 12:43 #

    감사합니다 흐흑..
  • chadr 2010/08/08 19:16 # 삭제 답글

    안녕하세요. 좋은책 잘 읽고 있습니다. :)
    책을 읽던 중 오타가 있는 것 같아서 댓글을 답니다.
    229페이지의 2~3라인에서 "그 결과 L1캐시로의 접근 패턴은 시간적 지역성이 L1보다 낮다" 에서 "그 결과 L2 캐시로의 접근 패턴" 으로 수정이 되어야하지 않을까 합니다.
  • 김민장 2010/08/08 21:01 #

    감사합니다. 맞습니다. L2 캐시로의 접근 패턴이 맞네요. 흑...
  • 2010/08/11 21:59 # 답글 비공개

    비공개 덧글입니다.
  • 김민장 2010/08/14 18:59 #

    안녕하세요. 반갑습니다. 임베디드시스템 과정에 계시는군요~
  • 진흙달러 2010/08/31 17:14 # 삭제 답글

    이 책 보면서 열심히 공부하고 있습니다. 아직 앞쪽 부분 공부중인데, 컴퓨터 구조 시간에 사실 지루해서 자느라(...) 수업을 제대로 안 들었었는데 훨씬 머리에 잘 들어오네요. 잘 보겠습니다
  • 김민장 2010/09/30 19:01 #

    감사합니다.
  • madee 2010/09/30 17:40 # 삭제 답글

    책 잘 읽고 있습니다. 평소에 컴퓨터 구조에 대해 좀더 잘 알고 싶다는 생각은 하고 있었지만
    도무지 어떤 책이 좋은지, 쉽게 잘 이해가 되는지 ... 이책 저책 찾다가 쉬운 책 위주로 몇 번 보긴 했는데
    얕은 내용 만큼이나 깊이있는 내용을 이해하기가 어려웠는데.
    이 책은 읽으면 읽을수록 좋은 책을 샀다는 생각이 들었습니다.
    배경지식이 학과 수업시간에 들었던 것 뿐이라 많지 않아서 그런지 (수업시간에도 다 이해를 한게 아니어서 ㅜㅜ)
    조금 어려운 내용들이 처음에는 머릿속에 잘 안들어오긴 했지만
    읽어갈수록 재밌고 집중이 잘 되더라구요.
    블로그에 와보니 글을 이해가 잘되도록 잘 쓰시는거 같네요 :)
    이제 반정도 읽은거 같은데 블로그 들른 김에 좋은 책에 대한 감사인사나 한번 하구 갑니다.
    책을 또 쓰실 생각이 있으시다니 저도 기대가 되네요. 앞으로도 좋은 책 부탁드려요ㅎ
  • 김민장 2010/09/30 19:02 #

    감사합니다. 나름 쉽게 쓴다고 저는 굉장히 노력했는데;; 주제 자체가 관심있는 사람을 제외하고는 어렵게 느껴질 수밖에 없는 내용인지라 한계가 있는 것 같습니다. 아무쪼록 도움이 된다고 하니 저도 기쁘군요~
  • 문우식 2010/10/05 17:18 # 삭제 답글

    저에게 또 하나의 깊은 통찰력을 안겨주는 책이었습니다.
    잘 읽었습니다. 감사합니다.
  • 김민장 2010/10/21 11:53 #

    혹시 책 쓰신 문우식님? 저도 쓰신 디자인패턴 책 잘 봤어요 ㅎㅎ
  • djin 2010/10/21 11:30 # 삭제 답글

    책 잘 보고 있습니다. 감사합니다.
  • 김민장 2010/10/21 11:52 #

    감사합니다;;
  • trip2me 2010/11/26 13:28 # 삭제 답글

    감사합니다. : )
  • limetok 2010/11/26 19:24 # 삭제 답글

    안녕하세요.
    컴공과 3학년에 재학중인데, 제가 cpu 아키텍처에대해 관심이 많아서 이리저리 찾아보다가
    이 책을 구매하게되었습니다.
    너무 기다리기 어려워서 서점 달려가서 방금 사왔습니다.

    다름이아니라 수업을 들으면서 짧은 수업에
    더 궁금하고 부족한 부분을 채우고자 제가 단독으로 수업시간에 발표를 하기로 했습니다.

    멀티코어에 대해서 설명을 하려고하는데 중간중간에 삽입된 자료들을 혹시 구할수 있을까요?
    전부가 아닌 대여섯개의 도표같은걸 발표할때 프리젠테이션에 넣을려고하는데

    아무튼 책 정말 괜찮습니다. 컴공과라면 기본적으로 알아야 할것들을 너무 쉽게 설명해주셧습니다.
    특히 컴퓨터 구조에 도움이 되는 책입니다.
  • 김민장 2010/11/26 21:34 #

    안녕하세요. 메일로 주시면 더 자세히 알려드리겠습니다. 메일 주소는 art.oriented gmail 입니다.
  • windily 2010/12/20 17:40 # 답글

    책이 다들 Blog2Book시리즈에 비하면 두꺼운 편이네요.
    이 시리즈 책도 이것으로 3번째입니다. 내용도 참 만족스러워요.
    종이질은 살짝(?).

    좋은책 내주셔서 감사합니다. (^^)
  • novice 2011/01/05 10:11 # 삭제 답글

    책 보면서 많은 생각을 할 수 있었습니다. 마음에 불도 지펴주셨습니다. ㅋ
    감사합니다~~
  • 보물~ 2011/03/11 23:04 # 삭제 답글

    여기에 있는 글들 읽다가 감동 받아서 ~ 책 구입했습니다.~~~
    추가적으로.
    프로그래밍을 잘하고 싶은데, 어떤 책을 사면 좋을지 추천좀 해주셨으면합니다.
    이글 보면 꼭 답변좀 주세요~~ 수고하세요

    forceant@naver.com <-- 여기로 답변 주시면 감사하겠습니다.~^^
  • seso 2011/03/17 19:13 # 삭제 답글

    안녕하세요 책을 읽다가 궁금해서 한번 와봤습니다^^

    책 내용이 정말 너무 좋더라구요~ 제가 궁금해 하던 많은 것들이 풀리는 느낌 ㅎㅎ

    책 내용을 정말 쉽게 잘 써주셔서 다른 paper를 볼때 도움이 많이 될 것 같습니다^^

    후속편으로 더 최신의 내용과 더 깊은 내용을 넣어서 써주시길 기대하겠습니다^^

    더 깊고 자세한 내용이 많다면 10만원 주고 책을 사더라도 전혀 아깝지 않을 것 같아요~

    후속편 꼭 써주세요~~^^
  • kunix 2011/05/20 14:23 # 삭제 답글

    책의 오타 발견 : 176쪽의 병렬 컴퓨터의 개념에서 2번째줄에 병령 컴퓨터가 있군요..
  • 김민장 2011/05/22 09:31 #

    감사합니다. 다음 3쇄에 수정이 될 겁니다 ㅎㅎ
  • silver 2011/06/20 02:07 # 삭제 답글

    가볍게 읽으려고 구입했다가 공부하는 자세로 읽고 있습니다
    대학 컴퓨터구조 강의보다 이책이 더 나은 것 같습니다
  • reipin 2011/07/03 15:03 # 삭제 답글

    반도체 분야를 전공하는 학생입니다. :) 어제 책을 사서 끝까지 쭉- 읽었는데 한가지 오류가 있는 것 같아서 글을 남깁니다.
    Story_03(45페이지)에서 RTL에 대한 설명이 나왔는데, RTL은 언어가 아니라 추상화 단계를 뜻하는 것으로 알고 있습니다. RTL은 Register Transfer Level의 약자이구요. Verilog와 같은 하드웨어 설계 언어(HDL)에서는 RTL로 표현할 수 있고 논리게이트 레벨로도 표현할 수 있고, 심지어는 트랜지스터 레벨로도 가능합니다.
  • 김민장 2011/07/03 15:21 #

    지적 정말 감사합니다. 3쇄가 조만간 나올 것 같은데 거기서 틀린 부분을 수정하도록 노력하겠습니다. http://en.wikipedia.org/wiki/Register-transfer_level 이거이군요. 완전히 다른 내용이네요;
  • 김민장 2011/07/05 18:29 #

    이미 3쇄가 나갔네요;; 3쇄가 다 팔리기에는 2년이 걸릴 것 같으니 한빛 사이트에 등록하겠습니다.
  • 김동영 2011/08/02 11:28 # 삭제 답글

    안녕하세요. 3쇄 책을 오늘 사서 이제 2장까지 읽었습니다.
    멀티 코어에 대해서 꼭 알고 싶었는데, 이에 관련된 책을 내주셔서 정말 감사합니다.
    왠지 두근두근 하네요 ㅎㅎㅋ

    근데, 중요한 것은 아니지만, 30 페이지 5째줄에 "함수호출규약(calling convections)"라고 되어있는데요.
    이게 아무래도 convections가 아니라 convention이 되는게 맞는 것 같습니다.
  • 김민장 2011/08/02 13:48 #

    3쇄에도 아직 오타가... 정말 감사합니다. 함수호출대류가 되어버렸네요. 출판사에 말해서 다음 쇄(언제 나올지 모르겠지만) 고치도록 하겠습니다.
  • 김민성 2011/08/08 18:04 # 삭제 답글

    아무런 기대없이 어제 서점에 갔다가 2장까지 읽어 본 후 충동 구매를 했군요.
    좋은 책을 만나서 너무 감사했습니다. 게다가 한글책을 이렇게 보다니... 마저 읽고 난 후 감상평을 남겨야 겠죠... : )
  • 김민장 2011/08/08 21:29 #

    책 구매해주셔서 감사합니다. 그것도 서점에서 직접 사시다니!
  • 궁금 2011/08/08 21:28 # 삭제 답글

    바보 같이... /4+1 을 /(4+1)로 읽었습니다. 난독증 환자
  • 김민장 2011/08/08 21:29 #

    괜찮습니다 ㅎㅎ
  • 2011/08/08 21:39 # 삭제 답글 비공개

    비공개 덧글입니다.
  • 김민장 2011/08/08 21:48 #

    네 맞습니다. 그런데 저도 1GB 페이지 지원에 대해서는 자세히는 잘 모릅니다;
  • 김동영 2011/08/09 16:52 # 삭제 답글

    책 재밌게 잘 읽었습니다. 개인적으로 GPU 가지고, 컴퓨터 그래픽스를 연구하던 학생이라서 더 흥미로웠던 것 같습니다. ^^

    오타를 하나 더 찾았는데요. 242 페이지 마지막 문단 6번째 줄에 다음과 같은 문장이 있습니다.

    "분기 예측에 대해 이야기하기 전에 분기문이 정확히 복습해보자."

    단순 실수 같기는 한데요. 다음과 같이 고치는게 맞을 것 같습니다.

    "분기 예측에 대해 이야기하기 전에 분기문을 정확히 복습해보자."

    그럼 졸업 잘 하시기를 바라구요. 다시 한 번 좋은 책 읽게 해주셔서 감사합니다. ^^
  • 김민장 2011/08/09 23:26 #

    지적 감사합니다. 1쇄를 사보셨나 보군요 ㅠ 2쇄 부터는 지적하신 오류 다 고쳐졌답니다. 감사합니다.
  • 김동영 2011/08/10 10:53 # 삭제 답글

    저는 2011년 6월 3일 발행 3쇄를 샀습니다. 아직 출판사에서 에러타 반영이 안 됐나보네요 ㅎㅎㅋ
  • 김민장 2011/09/22 19:06 #

    뒤늦게 댓글 답니다. 저도 얼마 전에 알았는데 아직 3쇄에 모든 오류가 다 수정되지 않았더군요. 정말 죄송하다는 말씀밖에;; 출판사에서 약간 혼선이 있었던 것 같습니다. 4쇄에서는 다 잡고 나갈 듯 합니다.
  • namhyung 2011/09/22 15:31 # 답글

    좋은 책 잘 읽었습니다. 컴퓨터 구조에 대한 여러 이슈들을 알기 쉽고 간략하게 정리해 주셔서 큰 도움이 되었습니다. 저도 3쇄를 구해서 읽었는데 오류로 의심되거나 건의드리고자 하는 사소한 부분들이 몇몇 있어서 확인도 할 겸 답글로 남겨볼까 합니다.
  • namhyung 2011/09/22 15:35 #

    232 페이지에서 캐시 미스의 네 가지 이유에 대해 소개한 직후에 "앞의 3C 캐시 미스"라고 언급한 부분이 있는데, 제가 알기로는 위의 네 경우가 모두 알파벳 C로 시작하는 단어이므로 4C 라고 불렀던 것 같고 이 중 앞의 세 경우를 말씀하신 것 같은데 (맞나요?) 가능하다면 (좀 더 친절하게) 이에 대한 설명이 추가되는 것이 더 나아 보입니다.
  • namhyung 2011/09/22 15:39 #

    326 페이지에서 '상수 전파 (constatnt propagation)'라는 최적화 기법에 대한 설명이 나오는데, 제가 알기론 상수 전파는 말 그대로 변수에 상수값이 대입된 경우에 사용되는 기법이고, 이 경우는 변수 대입이므로 '복사 전파 (copy propagation)'가 알맞은 표현이라 생각됩니다.
  • namhyung 2011/09/22 15:41 #

    346 페이지의 Worker 스레드/함수에서 호출하는 함수는 mandel()이 아닌 Mandelbrot()가 되어야 하지 않을까요?
  • namhyung 2011/09/22 15:44 #

    348 페이지에서 '정적(static) 변수'라는 표현을 사용한 후에 그 아래에서는 '스태틱 변수'라는 표현을 사용하셨는데 가능하다면 한 가지로 통일하는 것이 더 좋을 것 같습니다. 또한 소스 18-7의 5번 줄에서 temp 변수는 정적 변수이므로 1, 2번 줄의 경우와 같이 주석을 달아서 표시하는 것이 맞지 않을까 생각해 봅니다.
  • namhyung 2011/09/22 15:49 #

    349 페이지에서 '[3] 또는 Story 19에서 자세히 읽을 수 있다.'라는 부분은 Story 20으로 수정되어야 할 것 같습니다. 또한 이 부분은 데이터 '사본화'에 대한 설명인데 이를 위한 기법으로 알고 계시듯이 TLS (Thread Local Storage)가 사용하기도 쉽고 '가짜 공유' 문제도 피해갈 수 있으므로 매우 유용한만큼 이에 대한 간략한 소개가 추가되는 것이 좋을 것 같습니다.
  • namhyung 2011/09/22 15:54 #

    이건 정말 사소한 문제인데 369 및 370 페이지의 소스 코드에서 구조체/클래스의 멤버 지정 연산자 (->)가 화살표 기호로 자동?변환되어 있습니다.
  • 김민장 2011/09/22 22:32 #

    지적 정말 감사합니다. 제가 책을 보고 확인하고 댓글 드릴께요.
  • 김민장 2011/09/23 16:08 #

    지적 다시 감사드리고 4쇄 혹은 전자책으로 나올 수 있으니깐 거기서는 아마 반영이 되도록 하겠습니다.

    1. 3C는 말씀대로 코히런스 빼고 나머지 3개가 맞습니다. 저는 학부 시절에 3C만 배워서 무심코 그렇게 써버렸네요. 학부 수준에서는 코히런스 프로토콜을 안 배우는 경우가 많아서 (그 시절에는 멀티코어도 없었고;) 그랬습니다. 보통은 말씀대로 4C로 하는 것이 맞습니다.

    2. 맞습니다. 상수전파가 아니라 복사 전파가 맞습니다. 큰 실수이네요.

    3. 맞습니다. Mandelbrot을 줄여서 mandel함수로 쓰다보니 오타가;

    4. 좋은 지적입니다. 그렇게 고치는 것이 좋겠습니다.

    5. Story 19는 오타가 맞고 20으로 고쳐야겠네요. TLS도 대안이 당연히 됩니다만, 매우 엄밀히 말하면 TLS의 구현에 따라 다를 수가 있습니다. 매우 간단하게 TLS를 구현해버린다면 false sharing이 일어날 수도 있습니다. 물론 Windows/Pthread의 구현에서는 그럴 일이 전혀 없습니다.

    6. 제가 지금 2쇄까지만 가지고 있습니다. 그래서 ->가 화살표 기호로 바뀌었다는 것은 확인이 안 되네요. 1쇄/2쇄에는 ->가 잘 나와있습니다. 혹시 그림 19-3의 thd->proc_info 이 부분에서 ->가 ?로 바뀌었다는 이야기인가요? 출판사측에 확인 후 수정되도록 할께요.
  • 김민장 2011/09/26 04:25 #

    아, 다시 보니 -> 말씀을 제가 잘못 이해했군요. 네, -> 이것이 화살표로 자동 변환이 되었군요;; 그림으로 넣다보니 그렇게 된 것 같은데 일정 보폭도 아니고 소스 코드 형식으로 들어간게 아니다 보니 그렇게 된 듯 합니다.
  • 토파즈 2012/04/06 18:51 # 삭제 답글

    오래전에 사 보았던 책인데
    파x즈와 함께 도움이 많이 되었습니다.
    오탈자도 좀 보이긴했지만 그것보다
    얻은 도움이 컸습니다. 학부 3학년인데
    보았던 내용이 쏠쏠하게 나오네요.ㅎㅎㅎ
  • DJ™ 2012/07/03 17:48 # 삭제 답글

    chapter 12, 캐시에서 L1-I$가 예외적으로 write-through policy를 쓴다고 하셨는데
    현재 나오는 CPU들도 해당사항인가요?

    구글링을 해봤는데 인텔의 경우 코어2듀오 이후로 L1-I$, D$ 모두 write-back policy를 사용한다고
    되어있어서 이렇게 질문드려봅니다.
  • 김민장 2012/07/03 21:24 #

    안녕하세요.

    먼저 제가 정확하게 책에서는 "예외적으로 L1 명령어 캐시는 흔히 라이트 쓰루를 쓴다." 라고 적었네요. '흔히'라는 부사에 유의해야 합니다. 제가 '흔히'와 같은 한정사를 쓴 이유는 L1 I$가 반드시 WT가 아니면 안 되는 당위성이 있는 것은 아니기에 그렇게 한 것이었습니다. 책 쓸 때 이런 한정사 하나하나에 의미를 내포하며 적었습니다.

    그렇지만 최신 CPU에 대한 내용은 저도 업데이트를 해야하니 정보 알려주신 점에 대해 감사의 말씀드립니다. 혹시 C2D 이후 L1I가 WB 쓴다는 이야기를 어디서 찾으셨는지 링크 알려주시면 고맙겠습니다. 저는 잘 못 찾겠네요.

    그런데 AMD Bulldozer는 L1 전체가 WT를 쓰기도 합니다.
    http://www.realworldtech.com/bulldozer/8/
    http://www.behardware.com/articles/833-4/amd-bulldozer-architecture.html

    AMD는 L3가 exclusive 형태로 작동하니까 (작동 방식을 파고 들면 굉장히 복잡) 좀 다른 방식을 택하는 것 같기도 하네요. 참고로 인텔/AMD L3가 있는 구조에서 L2 캐시는 inclusive/exclusive가 아닌 non-inclusive를 쓰는데 이 작동 방식이 각 구현마다 조금씩 다 다릅니다. 따라서 write 정책도 반드시 무엇이어야 한다는 당위성이 있는 것은 아니고 각 CPU 구조마다 일반 예상과는 다른 정책을 쓸 수도 있습니다.
  • DJ™ 2012/07/03 23:14 # 삭제

    불도저가 L1전체가 WT가 된건 저도 얘기를 들었던 것이라...
    제가 봤던 문서의 링크를 드리겠습니다.

    http://www.bioperf.org/Pra07.pdf

    해당 pdf파일 21쪽에 보시면 테이블이 있는데 C2D의 L1캐시 스펙을 보면
    Code and Data: 32 KB X 2, 8 way, 64–byte cache line size, write-back
    이라고 명시되어 있습니다. CPU-Z를 통해서 쓰기정책을 제외한 모든 사항은 직접 확인했습니다.

    아무래도 명령과 데이터캐시 둘 다를 의미하는 것 같은데 제가 잘못 이해한건가요?
  • 김민장 2012/07/04 00:22 #

    에, 석사 논문이군요. 이 친구도 어디 대충 자료 수집해서 적은 거니 신뢰성이 낮습니다. L1D가 WB인 걸 그냥 L1I하고 구분없이 썼을 확률이 매우 높습니다. 그리고 논문을 대충 읽어보니 WB/WT 성능 테스트가 있는데 저 논문 쓴 저자가 돌린 SPEC CPU2006 벤치마크에서 self-modifying code는 없습니다. 고로 L1I가 WT이던 WB이던 성능 차이는 거의 없습니다. 제가 어떻게 인텔에 있는 사람에게 물어서 확인은 할 수 있습니다. 결과 나오면 다시 알려드리죠.
  • 김민장 2012/07/04 01:41 #

    약간 어투가 석사논문이라 무시하는 것 같은데;; 다른 논문에 씌여진 숫자도 보니까 대략 인터넷에서 수집해서 돌린 거 같네요. 그러니 저 도표의 내용에 너무 의존하지 않는 것이 좋을 듯 합니다.
  • DJ™ 2012/07/04 02:42 # 삭제 답글

    흠.. 그렇군요.. 아무리 검색해봐도 프로세서 내부 정보다보니 잘 나오지가 않더라구요..
    모 하드웨어 사이트의 코멘트에서 최근 L1캐시는 죄다 WB정책을 쓴다길래 무슨 말인가해서
    검색해보던 도중에 의문이들어 여쭤보았습니다 ㅎㅎ

    바쁘실텐데 답변 감사합니다. 결과도 알수있다면 좋겠네요 ㅎ
  • 김민장 2012/07/04 03:45 #

    http://www.intel.com/content/dam/doc/manual/64-ia-32-architectures-optimization-manual.pdf

    Table 2-5를 보시면 Sandy Bridge의 I$는 그냥 read only라서 아예 write policy 자체가 없네요. L1 캐시가 언뜻 보기에는 I$, D$가 붙어있는 것 같지만 보통 상당히 다른 위치에 있죠. I$는 fetch 이전에 있는 거고 D$는 다른 곳에 있고. 이 정도면 정리가 된 것 같군요.
  • jongi 2012/08/22 12:19 # 삭제 답글

    안녕하세요. 책 114쪽에 보면 파이프 라인 단계를 나누면, 단계 별로 해야 할 일의 양이 줄어들어, 더 빠른 클럭 속도를 얻을 수 있다는 구절이 있습니다. 암기식으로 읽다가, 이번에 천천히 생각하면서 읽다보니 이해가 가질 않아서 질문을 하게 되었습니다. 각 단계별로 2클럭이 걸리고, 4단계 파이프라인으로 구성되어 있다고 가정하면, 1 명령어를 처리하는데 8 클럭이 소요됩니다. 그런데, 이 파이프라인 단계를 8단계로 나눈다고 가정하고, 단계별로 소요되는 클럭 수도 반으로 줄어서 1클럭으로 줄어든다고 가정할 때 1 명령어를 처리하는데 걸리는 클럭 수는 변함없이 8 클럭이 됩니다. 물론 처리량은 늘어나겠지만, 파이프라인을 잘게 나눈다고 더 빠른 클럭 속도를 얻을 수 있다는 문장은 여전히 이해가 되질 않습니다. 따로 검색을 해 보아도 시원하게 해결되지 않네요.
  • DJ™ 2012/08/22 22:56 # 삭제

    각 단계가 나눠지면 각 단계별로 해야할 일감이 줄어듭니다.

    예를들면 어떤일을 하는데 4분이 걸리고, 그 단계가 4단계로 되어있다 치면 하나의 단계를 거쳐가는데 1분이라는 시간이 필요합니다. 하지만 그 단계가 8개로 2배 더 세분화된다면? 하나의 단계를 수행하는데는 1분이 아니라 30초만 있으면 됩니다. 이렇게 여유가 생긴다는건 클럭 속도가 두배 상승할 수 있는 여지가 생긴단 말입니다.

  • 김민장 2012/08/23 01:44 #

    대신 댓글 남겨주셔서 감사합니다 ㅎㅎ

    가장 긴 파이프라인의 단계가 클럭 속도를 좌우합니다. 예를 들어, 파이프라인이 4단계이고 각 단계가 0.8초, 1초, 1.2초, 0.8초 걸린다고 합시다. 그러면 클럭 속도는 1.2초에 맞춰집니다.

    만약 각 단계를 두 단계로 더 쪼갤 수 있다고 하면, 0.4, 0.4, 0.5, 0.5, 0.6, 0.6, 0.4가 되고 클럭을 0.6초에 맞출 수 있으니 두 배 상승할 수 있죠. 물론 이론적으로 말입니다. 그림 10-5를 보면 관련 내용이 있습니다. 파이프라인 깊이(단계 수)를 늘리면 클럭 속도는 증가합니다 (물론 로그곡선처럼 점점 포화가 됩니다). 그런데 시스템 성능은 어느 시점 이후로는 나아지지가 않죠.

    클럭속도가 중요했던 펜티엄 4시절에는 파이프라인 단계를 30단계까지 해서 속도를 올렸는데 그러다보니 발열이 감당이 안 되었죠. 요즘은 대부븐 15여 단계 정도로 줄었습니다.

  • jongi 2012/08/23 14:16 # 삭제

    DJ/김민장/ 두 분 답변 감사드립니다. 설명해 주신 문장 하나 하나는 이해했었는데, 그것이 왜 처리량이 늘어나는 것이지 클럭 속도가 올라가는 것인지를 이해 못했는데, 지금은 이해가 가는 듯 합니다. 예를 들어, 4단계 파이프라인으로 구성되어 있고, 각 단계 별로 500us, 1000us, 300us, 750us 지연속도가 발생한다면, 이 경우 1000us 맞추어져서 1명령어를 처리하는데는 4000us 초가 걸립니다. 이것을 단순화 시키면 대략 1초당 250명령어를 처리한다고 할 수 있고, 250hz로 표시 할 수 있습니다. 이것을 8단계로 나누면 일의 양이 줄어들어, 가장 오래 걸리는 지연시간이 400us 일 수 있으므로 1명령어를 처리하는데, 3200us 초가 걸리고, 역시 단순화 시키면 대략 1초당 312명령어를 처리하게 되고, 312hz로 표시할 수 있습니다. 즉, 250hz에서 312hz로 클럭 속도가 증가한다고 할 수 있습니다. 제가 이해하는 과정이 맞는 것인가요?
  • 김민장 2012/08/24 13:15 #

    네, 맞습니다. 파이프라인을 잘게 하는 건 critical path의 길이를 줄여 그 만큼 클럭 속도를 높이게 해서 throughput 을 높이는데 있죠. 파이프라인이 가득차면 매 사이클마다 명령어를 완성시킬 수 있으니 이득이죠. 반면 명령어 하나의 레이턴시를 줄이는 건 아니고요. 또, 말했듯이 파이프라인 깊이도 너무 깊으면 부작용이 많이 나오니 (예를 들어, 분기예측 실패의 비용) '적절한' 깊이를 찾아야 합니다.
  • 요다 2013/03/22 17:02 # 삭제 답글

    책 내용과 직접적으로 관련된 내용은 아닌데 멀티코어에서의 캐시 관련 내용을 읽다가 궁금한 점이 있어서 질문 드립니다.
    멀티코어 관련해서 항상 coherence 문제를 많이 얘기 하는데요.. 그보다 앞서서.... 만약 코어 별로 실행되는 쓰레드.. 혹은 태스들의 address space 가 다르다면 공유 캐시를 access 할시 문제가 발생하지 않나 싶어서 질문드립니다.
    만약 공유캐시가 logical 캐시라고 가정한다면 각 코어별로 access 할 수 있는 공유캐시 영역을 분할 하지 않은 이상 다른 address space를 갖는 쓰레드들에 의해 같은 논리주소가 엑세스된다면 충돌이 나지 않나 싶어서요
  • 김민장 2013/03/22 17:46 #

    맞습니다. 캐시 코히런스는 같은 내용을 읽을 때나 생기는 문제죠. 각 스레드가 모두 독립된 주소 공간에서만 작동한다면 당연히 공유되는 캐시도 없고 그 사이에는 캐시 코히런시 트래픽이 발생하지 않도록 해야죠. MESI 프로토콜 같으면 쓰기가 이뤄져도 Exclusive 상태가 되므로 코히런시 신호를 안 보내도 됩니다. 그런데 뒷 부분에 말씀하신 논리 캐시 이야기는 잘 이해가 안 가네요. 논리 캐시 같은 개념은 없습니다. 대신 각 코어 별로 빠르게 접근 할 수 있는 로컬 캐시(혹은 뱅크)는 있을 수 있습니다. 보통 LLC는 캐시 크기가 커서 타일 구조로 하는데 각 코어에 가까운 곳에 먼저 배치가 되는 건 가능한 것으로 알고 있습니다.
  • 요다 2013/03/25 12:49 # 삭제

    답변 감사합니다.

    제가 말한 logical 캐시는 캐시 라인 인덱싱이 논리주소를 사용하여 이루어지는 캐시를 말하는 거였습니다.
    즉 캐시가 프로세서와 MMU 사이에 있는 경우의 캐시를 말하는 거였구요... 캐시가 MMU랑 메인 메모리 사이에 있으면 물리 주소를 사용하여 인덱싱이 이루어지니까 physical 캐시라고 하던데 널리 사용되는 용어는 아니였나봅니다.

    질문 드렸던 것은 LLC가 physical 캐시라면 상관 없을 것 같은데 logical 캐시여서 논리주소를 사용하여 인덱싱이 이루어진다면 각 코어별로 실행되는 쓰레드가 독립적인 address space를 갖게 될때 같은 논리 주소여도 다른 물리주소로 매핑 될 수 있으니 문제가 되지 않을 까 하는 것이 였습니다.
  • 김민장 2013/03/25 14:12 #

    첫번째 단락에 언급하신 내용은 PIPT, VIPT, VIVT에 대한 내용입니다. {Physically, Virtually} Indexed {Physically, Virtually} Tagged. 제 책에는 아마 못 적었고요. 찾아보시면 관련 내용 많이 나옵니다. 실제 프로세서에서 PIPT를 쓰는지 VIPT를 쓰는지 저도 잘 모릅니다. 따라서 인덱싱과 태깅을 일단 구분해서 생각해야 하지만 질문하신 내용과는 사실 별 상관이 없습니다.

    질문하신 내용에 대해 답변 드리면...

    일단 질문하신 내용에 기술적인 모호함과 오류가 있습니다. 만약, 하나의 프로세스 내에 여러 스레드가 작동되는 상황이라면 (OpenMP나 pthread) 주소 공간은 동일합니다. 만약 공유 데이터가 있으면 얘들은 당연히 같은 논리 주소이고 같은 물리 주소로 매핑이 됩니다. 캐시가 뭐가 되었던 간에 상관 없습니다.

    이번에는, 만약, 정말 멀티 프로세스 상황을 말씀하신 거라면, 예를 들어, MPI 같은 상황이라면, 프로세스는 각자 자신만의 주소 공간을 가지고 독립적으로 관리합니다. 따라서 두 독립적인 주소 공간을 갖는 프로세스(말씀드렸듯이 스레드는 말이 되지 않습니다)가 같은 논리 주소가 있더라도 그건 아무런 의미가 없는 우연입니다. 고로 같은 논리 주소여도 다른 물리 주소로 매핑이 됩니다. 같은 프로그램을 띄어도 요즘은 ASLR로 가상 주소는 수시로 바뀝니다. 참고로 이 상황에서 캐시는 아무런 연관이 없습니다. VIPT, PIPT, VIVT 뭐가 되었던 프로그래머는 생각할 필요가 전혀 없습니다. 하드웨어가 알아서 할 일입니다.

    한편, 두 프로세스가 공유 메모리를 만들어 놓고 (memory-mapped file 혹은 shmem) 사용할 수도 있습니다. 이 때는 이 공유 메모리에 대해서 두 프로세스가 동일한 논리 주소를 보게 됩니다. shmem 같은 함수로 포인터를 얻는 과정이 운영체제가 그걸 보장합니다. 그리고 얘들은 당연히 같은 물리 메모리에 매핑이 되겠죠. 역시, 여기서도 캐시의 인덱스/태깅 종류는 아무런 상관이 없습니다.
  • 요다 2013/03/25 16:53 # 삭제

    서로 다른 프로세스에서 파생된 쓰레드를 말하는 거였습니다.
    뭐 그냥 별개의 서로다른 프로세스라고 해도 상관없습니다.
    답변해주신 내용에서 2번쨰 내용에 해당하는 시나리오였는데...

    답변에 하드웨어가 알아서 할 일이라고 하셨는데.. 그러니까 어떻게 알아서 하는지 궁금해서 질문 드렸던 겁니다.
    프로그래머의 관점이 아니라 하드웨어 아키텍쳐 관점에서 봤을 떄 PIPT가 아닌 이상 인덱싱 되는 캐시라인이 어느 코어에서 실행되고 있는 태스크의 address space에 속하는지 파악할 수 있는 매커니즘이 필요하다고 생각했고 그런 매커니즘이 있다면 공유캐시를 갖는 멀티코어 시스템에서 추가적인 아키텍쳐는 무엇인지...

    아니면 통상 LLC 는 PIPT로 구현을 하는지.. 에 대한 궁금점이 생겨서 질문 드린거였습니다.


  • 김민장 2013/03/26 01:41 #

    http://en.wikipedia.org/wiki/CPU_cache#Address_translation 여기에 보면 설명 잘 나와있습니다. TLB 처럼 프로세스 아이디나 address space ID가 필요합니다. 제 생각에 LLC는 PIPT로 구현이 될 것 같습니다.
  • 미칸아빠 2013/05/21 03:31 # 답글

    제 생에 최고의 컴퓨터 책 중 하나입니다.
    저는 C++개발자인데 감히 Effective C++보다 이 책을 더 높이 평가 합니다.
    빨리 영문번역이 되길(Kindle version) 기대합니다.
  • 공대소년 2013/05/24 14:29 # 답글

    정말 우연히 들리게 되었는데...책에서 많은 도움을 받을 수 있을 것 같아서 바로 지르러 갑니다. :3
    제가 부족한 부분이 밀집되어있네요. +_+!!
  • zepp 2013/11/25 17:58 # 삭제 답글

    47page 에 부동소수점 계산시 1.3은 2진수 순환소수로 표현되어 실수데이터 처리시 오류가 있다고 설명해주셨는데요
    잘 이해가 되지 않아서, 문의 드립니다.

    숫자 1.3 을 수기로 계산하게 되면 1.11 인데, 이것을 (float)1.3 을 2진수로 변환은 정확하지만, (double)1.3 을 2진수 변환시에는 순환소수가 발생한다는 의미로 생각해도 무방한지 궁금합니다.

    실제 코드에서, 1.3 으로 넘겨받은 숫자가 1.299999xxx 로 표현되어 실제 계산값이 차이가 날 때, 넘겨받은 숫자에 대해서 사용하지 않는 소수점 자리에서 반올림해서 해결하고 있는데요, 혹시 다른 방법이 있을까요?

    또한 책에 1.5를 2진수로 표현하면 정확하게 1.1이 된다고 하셨는데, 1.1이 아니라 1.101 인데요, 혹시 오탈자인지요..
  • 김민장 2013/11/25 20:01 #

    안녕하세요. 뭔가 2진수로 바꾸는 방법을 잘못 하신 것 같은데요. 1.3은 2진수로 변환을 하면 1.0100110011... 순환소수가 되고, 1.5는 2진수로 정확하게 1.1입니다. 따라서 1.3을 float이던 double이던 IEEE로 표기하면 1.2999x 같은 것이 나옵니다. 계산은 아래에서 확인해보세요.

    http://www.wolframalpha.com/input/?i=convert+1.5+to+base+2
    http://www.wolframalpha.com/input/?i=convert+1.3+to+base+2
  • zepp 2013/11/26 07:20 # 삭제 답글

    아 미안합니다. 제가 2진수 소수점 계산 방법을 잘못 알았던거 같네요.
    확인 감사드립니다.

    마지막으로 한개만 더 가르침을 주십시오.^^
    실제 수치계산상 나타났던 현상인데, 제가 잘 처리하고 있는건지 긴가 민가 해서요.

    1.3 이라는 숫자를 double 형 변수에 값을 넘겨 받아서 소수점 2째자리 부터 버림해서 계산할 때
    1.299999 라는 수로 인식해서, 결국 1.2 라는 값으로 계산한 경우가 있었습니다. 숫자는 1.3이 아니었습니다만, 예제로 말씀드립니다.

    부동소수점 오류로 생각되는데요, 그래서 둘째 자리에서 반올림 후에 계산하도록 코드를 수정했습니다.
    double/float 를 사용할 때, 이렇게 자리제한을 해서 사용해야 하는 것인지 궁금합니다.
  • 김민장 2013/11/26 07:55 #

    굳이 컴퓨터의 부동소숫점이 아니더라도 일반적인 수학에서도 내림/오름/반올림으로 인한 오류는 있고 반드시 어떤 걸 써야 한다는 정답은 없겠죠. 예를 들어, 핸드폰 요금 청구서를 보면 원 이하 단위는 버림으로 하기도 하고요. 그래도 보통은 유효숫자 기준으로 몇몇 유효숫자 아래는 반올림을 한다, 그러면 적당하지 않을까 생각합니다. 소숫점 2째자리 이후라기 보다는 유효숫자 기준으로 말하는게 합리적이라고 봅니다. 근데 저도 요즘은 소숫점 다루는 계산을 잘 안해서 제가 드리는 말씀이 좋은 건지 잘 모르겠네요.
  • 아폴로 2014/02/18 14:08 # 삭제 답글

    덕분에 좋은 내용 많이 알게 되었습니다. 고맙습니다.^^
  • Robert 2014/04/28 13:19 # 삭제 답글

    저도 정말 감사히 보고 있습니다.
    고맙습니다.
  • 2014/10/06 00:53 # 삭제 답글 비공개

    비공개 덧글입니다.
  • 김민장 2014/10/06 14:23 #

    안녕하세요. 레지스터 리네이밍을 할 때 어떤 자료구조가 필요합니다. 명령어에 있는 논리 레지스터를 물리 레지스터에 매핑을 해야 하는데, 이 자료구조가 말씀하신 문맥을 이해합니다. 앞서 어떤 명령어가 어떤 레지스터에 write를 한다는 정보 등이 담겨있는 것이죠. Register Alias Table 같은 녀석이 이런 자료구조 중 하나입니다.
  • 정종채 2016/04/14 14:37 # 삭제 답글

    재미있게 읽었던 책이었는데
    해당 사이트에 게시되어 있는 글들을이 좋아 읽어보다가 책을 쓰신 분이었더군요.ㅎㅎ
댓글 입력 영역