인턴4주차_왜 벌써 4주차지?

오랜만에 글이나 좀 써볼까! 하고 들어와서 제목을 쓰려고 세 보니 벌써 4주차다.

이번주 주말이 벌써 4번째 주말이고, 그러고 나면 7월이 한주쯤 남는다...

뭐지..? 나 뭐한거지...?

 

1. Log 생성

 

여기서 내가 맡은 역할은 QFlex의 근간이 되는 Simflex의 log를 분석하는 Debugger를 만드는 것이다.

그러기 위해서는 일단 log를 생성해야 한다! 

근데 이게 생각보다 쉽지 않아 한주를 썼다.

 

깃허브랑 각종 시스템 권한들을 받고, 받고 보니 쓰기 권한이 없어서 다시 오피스 찾아가고, 컴파일 하고, 권한 문제나서 다시 찾아가고..ㅜㅜ

 

까먹을까봐 대충 정리해보면, Flexus를 실행시키기 위해서는 아래와 같은 폴더들이 필요하다.

/home/gaspar_name/specs
/home/gaspar_name/.runjob_tcl
/home/gaspar_name/results

 

만약에 flexpoint를 20개 만든다고 하면, 다음과 같은 방식으로 로그를 생성한다.

 

:: Trace Compile ::

make -j CMP.L2Shared.Trace

 

:: Timing Compile ::

make -j CMP.L2SharedNUCA.OoO

 

:: Trace Running ::

run_job -clobber -cfg cortex-a15-1core-1024kl2 -local -run trace -job trace-a15-1core-1024kl2 CMP.L2Shared.Trace nutch/1cpu

 

:: Flexpoint Generating ::

run_job -clobber -cfg cortex-a15-1core-1024kl2 -local -run flexpoint -ckpt-gen -postprocess "/home/parsacom/tools/flexus/postprocess_ckptgen.sh flexpoint 20 cortex-a15-1core-1024kl2" -job flexpoint-a15-1core-1024kl2 CMP.L2Shared.Trace nutch/1cpu

 

:: Timing Running ::

run_job -clobber -ma -cfg cortex-a15-1core-1024kl2 -local -run timing -job timing-a15-1core-1024kl2-$1 -state cortex-a15-1core-1024kl2 -postprocess " /home/parsacom/tools/flexus/postprocess.sh" CMP.L2SharedNUCA.OoO nutch/1cpu

 

이것저것 오류가 나긴 하지만, 다 권한 문제였고, 이렇게 하면 일단 실행이 된다.

하지만 아직 로그가 다 나오지 않는다..! 로그가 더 자세하게 찍히게 하기 위해 추가적으로 필요한 조치가 있다. 

 

 

/home/name/results/timing-a15-lcore-1024kl2-/spec2k_gcc/cortex-a15-lcore-1024kl2_000_001/  안에 있는 ./go.sh를 실행시키면 시뮬레이션이 replay 되는데, 이 때 Ctrl + C 를 눌러서 시뮬레이션을 멈추고, flexus.debug.set-severity vverb를 치고 나면, debug.out의 파일크기가 훅 커진다!

 

 

 

 

2. debug.out 파싱

 

debug.out 파일을 보면 엄청엄청 많은 로그들이 찍히는데, 그 중에 일단 필요한 라인만 골라야 한다. 

언어를 파이썬을 쓰는데, 음 어떻게 해야 되나 고민하다가 Regular Expression 을 쓰기로 했다. 

덕분에, 평소에 배워야지 배워야지 하던 RE 를 배울 수 있었다..ㅎㅎ

파싱한 데이터를 Class를 만들어서 잘 정리해 넣는다.

 

정리하고 나면, 다음과 같은 line class에 각종 정보가 저장된다. 대략 30초 동안의 로그에서 무려 7만개의 line 인스턴스가 생성된다.

 

class Line:
    def __init__(self, parsed):
        self.LineNum = parsed.group('LineNum')
        self.Components = parsed.group('Components')
        self.Comp_line = parsed.group('Comp_line')
        self.Cycle = parsed.group('Cycle')
        self.MemMsg = parsed.group('MemMsg')
        self.Addr = parsed.group('Addr')
        self.Size = parsed.group('Size')
        self.Serial = parsed.group('Serial')
        self.Core = parsed.group('Core')
        self.DStream = parsed.group('DStream')
        self.Msg = parsed.group('Msg')

 

이렇게 생성된 line 인스턴스들을 이용해 쓰기 편한 debugger를 만드는 것이 여기서 두 달 동안 할 일이다.

 

 

 

 

3. 같은 Serial을 가진 것끼리 categorize

 

이제 여기서, 같은 Serial 을 가진 line들끼리 categorize해서 추적하면, 특정 Serial이 처리되는 과정의 Trace를 딸 수 있다. 

이걸 시각적으로(!!) 표현해 달라구 했다.

 

아니 터미널에서 도대체 뭘 어떻게 시각적으로 표현하나 했더니 박스랑 상자를(...) 만들어달라구 한다...

 

ㅎ...엄청난 노가다의 산물로, 다음과 같은 순서도를 터미널에 한땀한땀 그려내는 프로그램을 만들었다.

 

 

 

 

 

예를 들어, 241번 Serial을 가진 로그의 Trace를 분석해보면, 위 사진과 같이 출력된다.

 

사실 난 아무리 생각해도 오른쪽 꺼가 더 보기가 좋은 거 같다.... 

 

1. CacheImpl.cpp 파일의 170번째 Line에서 CacheController.cpp로 Load Request를 보내고,

2. CacheController.cpp 파일의 1010번째 Line에서 CacheController.cpp파일(같은 파일)로 또 다시 Load Request가 발생... 

 

이런식으로 해석할 수 있다.  왼쪽 그림처럼 4중으로 차곡차곡 호출했다가 다시 역순으로 Load Reply를 하며 올라가는 걸 볼 수 있다.

해당 Request에 관련된 주소값도 같이 나오고, Cycle number도 같이 나오기 때문에, 마지막에 CacheController.cpp에서 CacheImpl.cpp로 Load Reply를 하는데 3 Cycle이 소요되었고, 나머지는 전부 한 Cycle 안에 처리된 것도 알 수 있다.

 

저 왼쪽의 순서도 그리는게 생각보다 개ㅐㅐㅐㅐㅐ헬인게 항상 저렇게 예쁜 모양이 아닐 수 있다는 거다.

 

 

 

 

이거보다 더 복잡한 경우도 있는데... 일단 이것만 보더라도, 이건 미친짓이라는 걸 알수있다ㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋ

루프를 타는 경우도 있고, 분기가 나눠지는 경우도 있고... 두칸씩 점프해서 거슬러 올라가는 경우도 있고... 도저히 터미널에 화살표를 그려가지고는 해결할 수 없는 지경이 되었다.

 

그 와중에 사수님은 Cycle도 표시되면 좋을 것 같아! Load Request인지 Load Reply인지 Fetch Reply인지 MemMsg도 표시되면 좋을 것 같아! 

루프는 다른 화살표로 강조해 주면 좋겠어! 하는 요구를 하셔서... ㅎㅎㅎㅎ이건 좀 아닌 것 같았다.. 확장성 똥임

 

이미 출력을 한 상태에서 위로 올라가 재출력을 하는것(화살표가 중간에 뿅 뜨는 것)이 얼마나 거지같은 일인지 조금만 생각해봐도 알 수 있다...

더욱이 바로 위아래 박스만 연결되는 게 아니라 정말 화살표가 요리조리ㅎㅎㅎㅎ

 

그나마 트레이스를 보기 편하라고 한번에 다 출력하는게 아니라 엔터를 누를때마다 한 단계씩 애니메이션처럼 진행되도록 수정했지만...ㅎㅎㅎ 그래도 보다보면 머리아프다.

 

 

4. Analyze Pattern

 

여튼 이렇게 그린 박스와 화살표들이 있을 때, 대략 7천개의 Serial 을 Trace를 해보다 보면 비슷한 순서도를 가지는 경우가 많다. 

따라서, 총 몇가지 패턴이 존재하는지를 파악하고, 전체 Serial 들을 이 Pattern에 맞게 분류하는 작업을 하였다.

 

이 때 얼마나 같은 것들을 같은 패턴으로 볼 것인지가 관건인데, Component (파일이름, ex. CacheImpl.cpp) 와 해당 Component 안에서의 Line Number, 그리고 화살표가 같으면 같은 패턴으로 보기로 했다. 우선 Cycle이나 Address, MemMsg들은 고려하지 않는다!

 

평소에 잘 안쓰던 파이썬으로 이런 걸 짜다보니 파이썬 문법에 익숙해져서 좋앗다....ㅎ..

 

 

4-2. Address Pattern

 

지금까지는 Serial Number를 기준으로 순서도를 그리고 Pattern 을 분류했다면, 이번에는 다시 맨 처음 Line으로 돌아가서 Address를 기준으로 Trace를 따고 Pattern을 분류하는 작업을 했다. 사실 코드는 비슷해서 단순 반복 작업ㅎㅎ

 

이를 통해 특정 주소에 관여하는 Serial이 무엇인지를 알 수 있고, 특정 주소에서 어떤 일이 일어나는지 시간순으로 추적할 수 있게 된다. 

 

 

5. Error Detection

 

같은 패턴으로 묶인 Serial들을 보면, 모두 같은 순서도 그림을 가지게 되는데, 이 때 각 박스를 이동하는 화살표, 즉 한 instruction을 처리하는데 소요된 Cycle의 평균값을 구해, 만약 특정 Serial의 instruction에서 Cycle 소요가 선형정규화에서 Outlier라고 판단되면, Error로 의심해 볼 수 있다는 아이디어이다. 

 

코딩코딩코딩...

 

 

 

RESULT

여기까지 했을 때가 7월 12일, 그러니까 도착한 지 정확히 2주가 지났을 때다. 

첫 주는 내내 권한 설정 받고, Log 파일 만들어 내는 데 시간을 버렸기 때문에... 사실 별 거 없는 작업인데 시간을 너무 썼다고 생각했다.

 

매주 팀별 세미나가 있는데, 일주일 간 자기가 한 걸 발표하는 연구진행현황 같은 자리다.

 

뭔가 한 건 이것저것 있는데 영어로 설명하기가 참 난감...하고 말도 안나오고ㅠㅠㅠ그냥 어버버어버버 로그파일 뽑아서 디버깅 하고 있어요... 하고 뭉뚱그려 설명했다.

결국 듣다가 답답했는지 사수님이 대신 다시 다 설명해주심ㅎㅎㅎㅎ

 

ㅋㅋㅋㅋ뻘하게 웃겼던건ㅋㅋㅋㅋ여기 사람들은 정말 여유롭게 일하는 데, 그에 맞춰 나도 한국에서 하던거의 80% 정도의 업무강도로 연구를 햇다.

 

그런데 팀장님이 자! 그럼 우리 뉴 인턴은 이런이런걸 해보자! 하시면 사수님이 Actually she already does that... 

???Awesome! Then let's do ~~~ 하면 다시 사수님이 She already does that, too... 를 다섯번쯤 반복하다가, 팀장님이 그냥 하고 싶은거 다음주까지 하고 보여달라고 하셨닼ㅋㅋㅋㅋㅋ

 

일주일만에 도대체 뭘 한거냐고 어썸 퍼펙 쿨 하시는데.....엄....뿌듯하긴 하지만 사실 객관적으로 봐도 빡세게 하면 이틀쯤 걸릴 일이었던 것 같은데... 

한국인들의 업무속도와 강도가 유럽이랑 차원이 다르구나 느꼈다... 

 

유럽 복지국가 짱짱 스위스 짱짱