2020년 2월 21일 금요일

프로그래머가 몰랐던 멀티코이 CPU 이야기

표지는 산뜻...
회사 책꽂이에 있는거 빌려다 봤다.

대체로 대학교때 배웠던 컴퓨터 아키텍쳐를 최신 버전으로 업데이트한 책이라고 할 수 있다. 초판 발행이 2010년이니 최근이라고 해 봐야 10년 전 얘기다.

일반적인 컴퓨터 아키텍쳐는 학교에서 대강 공부했다. B+인가 맞았던 기억이 나는데...
내가 잘 안다고 생각하는 과목은 B+ 따위나 맞고...

파이프라인이니 뭐니 하는 것들은 한 15년쯤 전에 어느 대학교 대학원의 공개 강의 영상으로 대충 개념만 배웠다. 곱셈기니 뭐니 이상한거는 다 패스하고 그냥 개념만... 뭐 내가 CPU를 설계할 거는 아니니까. 다만 강의 뒤쪽은 너무 복잡해서 이해를 못해서 넘어 갔는다. 멀티 프로세싱이나 뭐 그런 것들...

이 책에서도 그런거 좀 나오다가 메모리 캐시 뭐 이런 얘기 좀 하시고...
병렬 프로그래밍은 역시 개 어렵다... 라는 결론으로 훈훈하게 마무리.

뭔가 상세하게 설명한다기 보다는 그냥 이런 컨셉이다, 저런 컨셉이다, 예를 들면 이딴 식으로 돌아간다 하는 식으로 설명하기 때문에 전문적인 지식이 별로 없어도 읽는데는 지장이 없다. (이해하는데 지장이 없다고는 안 했다)

앞부분은 그냥 교양으로 주르륵 읽고, 뒷 부분은 좀 이해하면서 따라가느라 다소 시간이 걸렸다. 음... 그냥 자아 도취를 위한 '대충' 깊고 좁은 이야기 정도?

2020년 2월 15일 토요일

불평등의 대가, The Price of Inequality, 조지프 스티클리츠



1. 몇년 전에 산 책인지 기억도 안난다.
출판이 2013년이니 그 이후인 것은 알겠지만... 일단 문재인 정권 시절은 아니었고, 볼드모트-이름 부르기 싫은 그 사람의 시절도 아니었던 것 같다. 아마도 세 명의 대통령을 지나서 끝을 본 책인것 같은데...

2. 그래서 무슨 내용인지 잘 기억이 안난다. ㅡ,.ㅡ;
심지어 작년에 처음부터 다시 읽기 시작했는데도 기억이 안난다. 물론, 주제는 뻔하다. 큰 불평등에 큰 대가가 따른 다는 얘기.

3. 미국 얘기다.
남의 나라라 그런지 문화는 확실히 다르다. 책에서야 당연히 그렇겠지만 극단적인 사례 혹은 특징적인 사례만 소개가 되겠지만, 확실히 혈압 오르는 일은 많은 것 같다. 전에는 몰랐던 것 중에 하나로, 개인 파산을 하더라도 학자금 대출은 갚아야 한다고 한다. 물론 이 책이 거진 10년 가까이 지났으니 그 사이에 바뀌었을지 모르겠지만, 어떻게 저런 법이 만들어졌을까 싶다. 한국 법이야 말할 필요도 없지 않을까 싶은데, 아는게 없으니 패스. ㅡ,.ㅡ;

4. 우석훈이 생각난다.
사람들의 소득 수준을 그래프로 펼쳤을 때, 정상적인 사회라면 다이아몬드 모양을 가지겠지만, 이제 점점 8자 형태를 가진다고 했다. 아마 88만원 세대 였던 것 같은데, 아닐지도.
여튼 그런 형태가 점점 진화(?)하다가 급기야는 상위 소득자와 하위 소득자가 완전히 분리가 되는 상태가 벌어지는 상태가 될 수 있다고 했는데, 다행?히 아직 그정도는 아닌 듯 하다. 그런데 고작 몇 %의 인구가 국토 절반의 땅을 소유하고 있는 상태가 된다면 '다행' 수준을 벗어난 것은 확실할 것 같다. 강철 군화에서는 끝내 노동자가 승리하여 새로운 세상에서 애버하드의 슬픈 이야기를 담담하게 기술하지만, 결국 어떻게 승리했는지는 단 한 글자도 나오지 않았다. 잭 런던도 앞날이 막막했으리라. 여기서 나오는 아스가드라는 도시는 상류 계급이 사는 동네다. 절대 하류층과 섞이지 않으며, 모든 것을 자급자족할 수 있는 도시. 하류층의 도전은 그 하류층에서 뽑은 경비병들이 막아주는 도시. 언뜻 하코넨이 생각나는 이런 설정들을 이제 더 이상 SF 또는 소설이 아니라 현실에서 보게 될 날이 멀지 않은 것 같다.

5.  갑자기 듄을 읽고 싶어진다.

6. 일단 이 포스트의 주제는 "불평등의 대가"니까...

7. (copyright로 추정컨데) 이 책은 2012년 즈음해서 미국에서 나온 것 같다. 2020년의 시각으로 보건데 진보 진영에서 봤을 때 이 책의 내용은 별로 새로운 것은 없다. 내 생각에 시대가 지났다기 보다는 지금의 진보 진영이 이 책의 기반 위에 서 있기 때문이 아닐까 싶다. 개인적인 입장에서 이 책을 보면서 다소 놀랬던 부분이 있는데, 다름 아닌 환경 문제다. 환경 문제를 일으키는 기업은 환경 훼손의 책임, 그리고 그 비용을 주변 사람들에게 전가하고 있다는 얘기다. 그리고 국가가 이를 묵인하는 것은? 잣같은 이야기다.

+1. 듄이 올해 (다시) 영화화된다고 한다.
https://namu.wiki/w/%EB%93%84(%EC%98%81%ED%99%94)

이 책이 포스트의 주제가 아니었지만...




2020년 2월 14일 금요일

Fucking LabView

LabView라는 프로그래밍 툴이 있다.

보기에 참 아름답다.

언어라고는 할 수 없는 것이 텍스트로 코딩을 하지 않고 컨트롤을 드래그/드롭하고 각 컨트롤을 선으로 연결하는 방식으로 프로그램을 만들기 때문이다. 물론 그림이 언어에 포함되는거 아니냐? 하면... 때려줄테다.

TIOBE에서 발표하는 2020년 1월 순위에서는 40위를 차지했다. Ada보다 한단계 낮고, Erlang보다 한단계 높은 순위다. 세상에 ML, Scheme, Haskell, TypeScript보다 높다니???

NI에서 만들었고, 1986에 처음 만들었다고 한다(위키피디아). 컨트롤 모양이 윈도하고는 약간 달라서 이상하다 싶었는데 처음에는 애플 매킨토시용으로 출시됐다고 한다. 뭔가 막 이해가 간다. 그래, 맥에서는 이렇게 프로그램을 할꺼야 하는 느낌이 든다.

이 개발도구의 용도는 명확하다.
요구사항이 명확히 정해져 있는, static한 환경을 자동화해야 하는 프로그램이 필요할 때, 바로 그 때가 LabView를 써야 할 때다.
다시 말하자면, 다음과 같은 경우에 LabView를 사용한다면 저주를 받을 것이다.
  • 객체처럼 인터페이스와 구현을 별도로 정의해야 하는 경우
  • 런타임에 동작이 바뀌어야 하는 경우
  • 프로그램이 큰 경우 (데이터가 큰 경우는 의외로 제법 성능이 좋다)
  • 하드웨어가 자주 바뀌는 경우
  • 정밀한 시간 제어가 필요한 경우: 일부 하드웨어가 추가되면 반대로 아주 정밀하게 시간 제어가 될 수 있겠지만 일반적으로는 시간 정밀도가 형편없이 떨어진다.
큰 일에는 큰 책임... 아니, 큰 모니터가 필요하다.

말했다시피 LabView는 컨트롤과 와이어로 프로그램을 만들기 때문에 텍스트 기반으로 만들어진 수없이 많은 개발 도구의 도움을 받지 못한다. 이때문에 발생하는 일에는 어떤 것들이 있을까?
  • Diff가 안된다: 두 소스(?)의 차이점을 확인할 수 있는 방법이 없다. 
  • 버전 관리가 어렵다: 소스(?)를 열었다 아무 수정 없이 그냥 저장해도 파일이 바뀌는 경우가 종종 있다. 거의 매일 새로운 리비전이 생긴다는 뜻이다. 물론 두 리비전 사이의 차이점은 확인할 수 없다.
즉, 만들어진 코드는 관리될 수 없다는 뜻이다.

그림으로 코딩을 하다보니 대체로 엔지니어들도 성향이 비슷하다. 코드에 (함수 호출과 같이)깊이를 더하는 방법이 (sub-VI라고) 있기는 하지만 거의 사용하지 않는다. 그래서 대부분은 깊이가 0인 프로그램이 만들어지고, 그 결과는 위 그림처럼 아주 큰 모니터가 필요하다. 참고로 저 UI는 확대/축소가 되지 않는다. 4k 해상도를 지원하는 노트북에서 일한다면 독수리 같은 시력이 필요할 것이다. 휠을 이용해 상하 스크롤은 되지만 일반적으로 사용하는 shift-스크롤을 이용한 좌우 스크롤은 없다. 프로그램에서 데이터 플로는 왼쪽에서 오른쪽으로 흘러가는데 그것을 지원하는 스크롤 기능이 없다.

배포판을 만드는 일은 또 다른 개발이다.

잘 돌아가던 프로그램이라 하더라도 배포판, 즉 하나의 exe로 만들면 안돌아가는 일이 부지기수다. c/c++에서 디버그 버전과 릴리즈 버전의 차이는 비교도 안된다. 굳이 비교하자면 c 코드를 c++ 컴파일러로 빌드하는 정도의 느낌이 든다.

음... 그래도 졸라 많이 쓰이는 도구니까 어따 써야 할지 좀 생각해봤다.

졸라 똑똑한 박사급 연구원들이, 그러니까 거의 모든 알고리즘이 머리 속에 있어서 그냥 구현만 하는 되는 정도의 두뇌를 가진 분들께서, 이미 완성된 연구를, 논문이 있긴 하지만 (돌대가리 행정 주의자들에게) 굳이 그걸 컴퓨터를 돌려서 가시적인 결과물을 보여줘야 할 때 사용하는 도구 되겠다.

혹은 사무실에서 일반 사무직원들이 엑셀을 사용하듯 일반 프로그래머들이 어쩌다 가끔 번인됐을 때, 등받이에 어깨죽지를 붙이고, 엉덩이는 의자 끄트머리에 간신히 걸친 상태에서, 몸은 컴퓨터 모니터와 90도 각도로 옆으로 틀어놓은 방향으로, 종종 다리는 책상이건 어디건 위에 올려놓은, 딱 그 상태로 앉아서(누워서?) 키보드 따위는 손은 고사하고 눈으로도 보고 싶지 않은 그런 심리적 상태에 있을 때, 간신히 마우스 클릭만 가능할 때, 그럴 때 사용할 수 있는 도구 되겠다.

많이 사용되는 산업용 용도라면... 공장에서 필요한 일이 빼박으로 딱 정해졌을 때, 바로 그 때 사용할 수 있을 것 같다. 그러니까 "우리 회사에 적당한 하드웨어 엔지니어와 펌웨어 엔지니어가 있다면 그냥 custom 하드웨어와 펌웨어로 만들었을텐데, 우리 회사엔 그런 엔지니어가 없으니 좀 비싸더라도 산업용 PC에 상용 계측 장비(카드류)를 꼽고 프로그램을 짜서 넣어야 겠다." 이럴 때 쓰면 되겠다. 그 이상은 프로그램 관리 비용이 기하급수적으로 커진다.

국내의 수많은 LabView 엔지니어들의 명복을 빈다.
(나보다 월급은 많겠지...)



flex와 bison으로 파서 만들기(1)

엄청 고인물스러운 도구이긴 하지만 flex와 bison으로 간단한 파서를 만드는 작업을 해 보자.
flex와 bison은 정의된 문법에 따라 텍스트 파일을 처리하는 c/c++ 코드를 생성해준다.
컴파일러 이론을 야매로 공부해서 LL(1)이니 뭐니 하는 얘기는 잘 모르겠고, 그냥 도구 사용법 정도를 익힌 상태라 남들 알려줄 정도는 아니고, 어쩌다 가끔씩 쓸 때 참고하려고 쓴다.

c/c++에서 c#으로 갈아탄지가 몇년 되다 보니 c#으로 출력하는 도구는 없을까 좀 찾아봤는데, 몇 개가 보인다. 몇 년전에는 잘 안보이더니 이번에 찾으니 많이 나오네.

1. Java
https://www.eclipse.org/Xtext/
자바쪽에서는 xtext라는 이클립스 기반의 도구가 있다. 상당히 멋지게 동작하는 것 같다. lex와 yacc 처럼 분리된 것이 아니라 xtext 파일 하나로 전부 처리하는 것 같다.

2. LLLPG
http://ecsharp.net/lllpg/2-simple-examples.html
2016년 이후 업데이트가 안된 것 같은데, 좀 약해보인다. 제목 그대로 simple lexer 정도로 보인다. 끝 부분의 질문이 마음에 든다.
Think twice: Do you really need a parser generator?
3. GOLD Builder
http://goldparser.org/builder/index.htm
2015년까지 업데이트 된 것 같은데, 확실히는 모르겠다. Windows 7까지만 나온걸 보니 그 정도에서 멈춘거 같다. 사용해보고 쓸만하면 빨리 백업을 받아놔야 할 듯.

4. Coco/R for C#
http://ssw.jku.at/Coco/#Docu
계속해서 업데이트 되는 분위기이다. nuget으로도 배포되니 괜찮은 듯 하다. C# 뿐만 아니라 Java, C++, F#, VB.Net, Delphi, Swift 등등으로 코드를 생성해준다. 적당히 쓰는 데에는 좀 공부가 필요할 것 같다.

5. ANTLER
https://www.antlr.org/
겁나 유명한 놈인거 같다. 끝판왕이랄까? 그런데 공부해야 할 내용이 좀 될 것 같다. 문법은 그래도 좀 익숙한 형태라 아주 어렵지는 않을 것 같다. 주로 툴 사용법에 대해 삽질하는 것들이 많을 것 같다.


일단 flex와 bison으로 c/c++ 파서를 한 번 만들어보고, 똑같은 것을 antler로 다시 한 번 만들어봐야 겠다.

파서는 LIN Description FIle을 처리하는 놈을 만들어보려고 한다.
사양은 다음 링크에서 받을 수 있다. 
https://www.cs-group.de/wp-content/uploads/2016/11/LIN_Specification_Package_2.2A.pdf

전체를 다 처리하는 것을 글로 쓰기에는 귀찮으니 일부만 처리하도록 해야겠다.

대략 다음과 같은 순서로 하지 않을까 싶다.

<flex & bison>
1. flex & bison 설치
2. 개발 환경 구성
[...생각 중...]

포스트 올리는 대로 링크를 업데이트하도록 하겠다.

첫 날 너무 많은 걸 하면 안된다.

2020년 2월 8일 토요일

오랫만에 lex와 bison(yacc)를 써봤다.

소시적, 전자과 주제에 어이없지만 공룡책인지 드래곤책인지 하여튼 그 책으로 컴파일러를 처음 공부하기 시작했다.

공룡이나 드래곤이나... 생각했지만, 내가 떠올렸던 건 공룡이 아니라 용이었다.
공룡책은 대체로 운영체제 거시기 그 책을 지칭한다. 디테일은 소중한 것이다.

쥐뿔도 모르면서 마구잡이로 책을 읽던 시절이다. 물론 생각해보면 그때 배운게 제일 많기는 하다. 어이없게도 원서로 읽어서 한 2/3은 뭔소린지 모르고 넘긴 것 같다. 1/3이라도 배운게 어디냐.

그거 대강 보고 이러저러 하다가 flex & bison를 봤다. (기억에는 lex & yacc를 본거 같은데... 책장을 보니 flex & bison이 있더라는...) 덕분에 아직도 종종 이상한 포맷의 파일을 만나면 파서를 만들고 있다. 물론 내가 쓰는 파일들이 아주 흔하지는 않지만 그래도 어디 분야에서는 표준 또는 표준에 가까운 것들이라 잘 찾아보면 어딘가에 누군가가 만들어놓았을 가능성이 크지만, 검색이라는 것이 그렇다. 남들거는 한 방에 찾지만, 정작 내가 필요한 것은 삼일 밤낮을 뒤져도 안나온다. 검색 이틀 째를 맞이하면 슬슬 '이거 그냥 내가 만들었으면 벌써 만들었겠다' 하는 본전 생각이 든다. 물론 어림 반푼어치도 없는 소리다. 실제로 만들어보면 기본 동작이 일주일이고, 정리 좀 하면 한달이다. 그렇다고 계속 검색만 할 수는 없으니 뭐든 적당히 하고, 적당히 포기할 줄 알아야 한다.



보통 오라일리 책은 동물 표지를 사용하지만 공룡책이나 드래곤책, 마법사책과 달리
오라일리의 책은 대부분 표지의 동물 이름으로 불리지 않는다. 이유는 간단하다.
이 책을 '새 책'이라고 부를 수 없기 때문이다. 그렇다고 이 책을 니코바르 비둘기 책
(Nocobar Pigeon)으로 부르기에는.... 딱히 비둘기 책으로 부르기도....

lex와 yacc(bison)은 c/c++만 지원한다. c/c++을 주로 사용하던 때에는 뭐 별다른 필요를 못 느꼈지만 c#으로 옮겨간지 몇년 되니까 c# 코드를 직접 만들어주는 녀석들이 있었으면 좋겠다는 생각을 했다. 그런데 적당히 돌아가는 legacy 코드를 굳이 c#으로 다시 작성할 필요는 없으니 그냥 설렁설렁 넘아가는 중이었다.

이번에 some/ip에 관련된 일을 시작하면서 다시 파서가 필요하게 되었다. vsomeip 라이브러리에서 사용하는 IDL을 읽어와야 한다. 오픈 소스 라이브러리인데 리눅스 플랫폼에서 c/c++로 빌드된다. 그런데 코드 생성기는 자바, 이클립스 플러그인 등으로 만들어졌다. 딱 보니 설치하는데에만 2주는 걸릴 것 같다. 암도 걸릴 것 같다. 그냥 파일 포맷 찾아서 파서 만들면 훨씬 빨리 끝날 것 같다. 같았다.

IDL 파일은 확장자 *.fidl을 사용한다. franca IDL의 약자다. *.fdepl도 있다. deploy에 관련된 정보가 있어서 이놈도 같이 처리해야 한다. fidl 파일 포맷은 어렵지 않게 찾았다. language specification도 있고, 심지어 EBNF로 기술된 문서도 있다. 순조로왔다. 그런데  fdepl 파일 포맷은 잘 안보인다.

그러다가 고객사에서 온 *.fid, *.fdepl 파일을 받았다. 헉?! 파일 내용이 검색했던 내용과 다르다. 이런 썅썅바.

파일 포맷에 대한 문서는 없는 것 같았다. 포기했다. 하지만 vsomeip 라이브러리는 *.fidl 파일과 *.fdepl 파일로 소스코드를 생성해주는 툴이 있으니 그 툴 어딘가에는 파서가 있을 것이다. 찾아보았다. 이클립스 애드온이니 자바로 되어 있는 정도는 뭐 당연한거라고 생각했다. 자바 코드라고 해도 딱히 놀라지는 않았을 것이라는 얘기다. 그정도는 마음의 준비를 했다는 얘기다.

역시, 메트릭스는 옳다. '무엇을 상상하든 그 이상을 볼 것이다.' 4편을 기다려주긴 한다만, 죽은 네오 살리는 것 보다는 콘스탄틴2를 좀 만들어주면 안되겠나 하는 생각이 든다. 지금 시대에 누가 키아누리브스를 보고 네오를 생각하겠나? 존윅이라고 하겠지.

무엇을 상상하든 존윅을 볼 것이다. (원본)
파서 관련된 코드는 찾았다. 며칠 걸렸다. 자바는 아니었다. *.xtext라는 확장자였다.

*.fidl 파일을 파싱하는 모듈은 여기 있고:
https://github.com/franca/franca/blob/master/plugins/org.franca.core.dsl/src/org/franca/core/dsl/FrancaIDL.xtext

*.fdepl 파일을 파싱하는 모듈은 여기 있다:
https://github.com/franca/franca/blob/master/plugins/org.franca.deploymodel.dsl/src/org/franca/deploymodel/dsl/FDeploy.xtext


음... 자바 바닥은 블랙홀과 같아서 뭐든지 다 있지만 들어가면 못 나온다. 굳이 이클립스 애드온을 사용해서 *.xtext 파일로 파서를 돌려보고 싶지는 않다. 파일 내용을 보니 그다지 어려운 것은 아니다. xtext 파일 포맷 따위 공부하지 않아도 알 것 같다. BNF나 regular expression 대충 퉁치면 될 것 같다. 샘플이랑 맞춰봐도 대강 비스무레 하다.

*.fdepl 파일을 처리하기위해 yacc 파일을 만들었고, 삽질을 좀 하다가 요령이 생겼다. 별다른 요령은 아니고, 그냥 xtext에 정의된거 그대로 만드는 거다. 생각하지 말자. 그냥 1:1 변환으로... *.fidl도 그냥 적당히 만드는 중이다.*.fdepl 파일은 샘플까지 다 파싱이 잘 되는 것을 확인했다 .

물론 구문을 파싱하는 것과 그것을 읽어서 어떤 처리를 해주는 것은 하늘과 땅 차이다. 말도 안되게 크지는 않지만 그냥 대충 퉁칠만큼 작지는 않다는 뜻이다. 이건 또 별도의 작업을 해야 할 일이다.

적당히 끝나는 시점이 보일 무렵, 아마도 삐딱한 전세계 모든 프로그래머들이 느끼는 그 시점이 왔다. 근데 뭐 다른 방법은 없나? yacc(bison)를 썼다는 것은 c/c++로 코드가 나오니까, 정작 내가 c#을 쓰려면 한 번 더 고생을 해야 한다는 얘기다. 그냥 바로 c# 코드를 생성해주는 yacc는 없을까? 프로젝트 처음 시작할 때는 없었다. 다시 검색해봤다. 많이 나온다.

음... 코로나 바이러스가 구글 데이터 센터를 감염시킨게 틀림없다. 시공간을 뚫고 이세계 인터넷에 접속됐다. 여튼 몇 가지를 찾아서 링크를 남긴다. 코로나 바이러스가 완전 퇴치되면 이 링크는 아마 접속되지 않을 것 같으니 미리 미리 코드랑 바이너리를 다운받아놔야 겠다. 이세계인지 어떻게 아냐교? 이쪽 사이트 바이너리가 Windows XP 또는 Windows 7 타깃이다.

1. LLLPG
http://ecsharp.net/lllpg/2-simple-examples.html

LL(x) 이런 골머리 아픈 표기법은 공룡/드래곤책으로 끝인줄 알았는데 LLLPG라니...

2. GOLD Parsing System
http://goldparser.org/builder/index.htm
GOLD Mining System인줄...
찾은 것 중에서는 젤 깔끔한 놈인 듯한데... 써봐야 알겠지...
뭔가 완성됐다는 느낌이 드는 놈이다.

3. Coco/R for C#
http://ssw.jku.at/Coco/#Docu
이놈도 뭔가 완성된 느낌이다. 홈페이지에는 금광 시스템보다는 좀 문서가 적긴 한데, 사용자 수는 더 많을 듯한 느낌이다.

다음 프로젝트는 c#으로 해야지...
다시 오지 않을 다음 프로젝트...