제목없음.

테스트 환경
M/B: ASRock Z77 Extreme 4
SSD: Intel X25-M G2 80GB
외장 하드 케이스: ipTIME HDD 3025

좌상) XFast USB Turbo + native USB3.0
우상) XFast USB Normal + native USB3.0
좌하) XFast USB Turbo + ASMedia USB3.0
우하) XFast USB Normal + ASMedia USB3.0

유의미한 정도의 차이는 있네요. SSD를 포맷안하고 사용한지 얼추 2년여라 속도 편차가 심해서 4K/4K QD32는 거의 오차 범위인것 같습니다. 또 ASMedia 칩셋에서 나온 USB 3.0 포트는 벤치 상으로도 성능이 떨어지며, 실사용시는 체감이 확실히 될 정도로 차이가 있습니다.

참고로 G2 80GB를 native SATA2 포트에 장착하였을때 벤치 결과는 http://diskerr.egloos.com/2363399를 참고하시면 됩니다. 물론 메인보드가 다르고 비교적 SSD가 깔끔한 상태에서 테스트한 결과라 비교적 스펙에 가까운 수치로 잘 나왔음을 감안해야 합니다.

PROCESS_ATTACH 시점에서 DllMain 혹은 해당 호출 이전에 초기화되는 DLL의 전역 객체들의 생성자에서 예외를 던지면 안된다는 것은 당연한 사실인데, 이 예외를 외부로 전파하는게 아니라 내부적으로 올바르게 처리하는건 괜찮다고 알고 있었고, 실제로도 문제없이 동작한다.

그런데 VS2010 profiler는 저런 DLL을 링크하는 exe를 프로파일링 하려고 하면 런타임 라이브러리 injection이 실패했다면서 프로파일링이 안된다.

해결은 지연 로드된 DLL을 사용하거나 아예 예외를 던지지 않아야 하는데, 나는 내가 던지는게 아니라 boost::interprocess::named_semaphore가 내부적으로 던지고 받고 하는거라-_-;; (open_or_create로 생성하면 먼저 create 해보고 실패하면 예외를 던진 다음, 그걸 받아서 open 모드로 들어가는 구조임)

named_semaphore는 디폴트 생성자도 private이라서 생성자에서 초기화 안하면 동적으로 생성해야 하는데.. 생성자에서 동적 할당도 안되니까 무슨 쓰는 곳 마다 싱글턴 인스턴스 얻어오는 식으로 처리를 해야 하는 엽기적인 상황이 발생-_-;;

결국 문제가 되는 전역 객체 자체를 singleton으로 만들어서 메인 프로그램(exe)에서 function call을 할 때 생성되도록 수정해버렸지만 singleton으로 구현하기도 애매한 객체는 어쩔꺼여.

어쨌든 DllMain과 DLL 내의 전역 객체 생성자에선 조금이라도 코드가 들어갈 짓을 하면 안되겠다. 뭐, 하지 말란 짓은 안 했으니까~ 하고 별 생각없이 좀 복잡한 초기화 과정을 가진 전역 객체 하나 선언했다가 프로파일링 안되는 바람에 3시간 날렸다.-_-;; 선언하자마자 프로파일링 돌렸으면 바로 문제를 눈치챘을텐데 거의 프로젝트 초기부터 선언해놓고 쓰던 객체라 이게 문제일거라곤 상상도 못했다.   (생각해보니까 하지말란 짓을 안한건 아니다. interprocess가 Win32 API도 호출하는데 kernel32.dll 말고 다른 dll에 포함된 API를 호출할지 알게 뭐야-_-; 물론 동기화 객체들은 kernel32.dll에 있긴 하지만)

좀 귀찮다고 전역 변수 쓰려고 한 것 자체가 잘못이었나.. C++에선 설계고 뭐고 없이 단지 빠르게 프로토타이핑 할 때를 제외하고는 절대 전역 객체 따위 쓰지 않는데 아무래도 DLL은 내부 로직은 C++로 작성하더라도 인터페이스를 C 스타일로 작성하다보니 그 부분에서 전역 변수의 유혹이 좀 강하긴 하다.

요즘 회사 신규 프로젝트에 사용할 비디오 코덱 라이브러리를 정리하고 있는데,  아무래도 제품 특성상 H.264 디코딩 성능이 관건이다 보니 여러모로 신경을 쓰고 있다.

우선 S/W 코덱으로 IPP 6.1의 UMC 샘플 H.264 디코더를 기본으로 하고 H/W 가속 디코더로 Quick Sync Video (이하 QSV) 를 활용할 수 있는 Intel Media SDK (이하 MSDK) 기반 디코더를 하나 만들고 있다. 물론 여기서 만들었다는건 당연히 상위 어플리케이션에서 공통된 API로 사용할 수 있도록 wrapper를 만든다는 의미이다.-_-; 아직까지 H.264 S/W 디코더를 ipp나 FFMPEG보다 빠르게 만들 자신은 없다. (그럴 자신이 있으면 여기서 이러고 있지 않겠지)

글이 길어 일단 한번 접고...


본문 보기

대학, 대학원을 졸업하고 개발자로 프로그래밍을 계속하면서 느끼는 거지만, 확실히 JAVA가 잘 설계된 언어같긴 하다.

원래 개발자 초년차까지만 하더라도 자바는 괜히 어려운 것도 없고 못하는건 없지만 할 수 있는 것도 없는 언어, 즉 언어적 자유도가 C/C++에 비해 매우 뒤쳐진 언어라는 선입견(?)이 있었다. C/C++의 태상상 한계 때문에 존재하는 언어적 결함 조차도 멋져 보일 때가 있었으니까. 쉽게 말하자면 "이 정도는 어려워야 공부하는 맛이 있고 일반인이랑 차이가 나지!" 이 정도?

그런데 C/C++로 일을 오래 하면 할 수록 자바가 부럽다.

아무리 나쁜 짓이라고 교육받아도, 그 나쁜 짓이 일정의 단축과 오늘의 칼퇴근을 보장해 준다면, 그게 내년의 야근으로 연결될지라도 하게 되고야 마는게 개발자의 습성(!) 같다. 당장 그런 사람을 욕하던 나마저도 무의식적으로 그런 코드를 만들어내고 있으니까.

그런 의미에서 자바는 나쁜 짓 자체를 못하도록 제약을 많이 걸어놨으니 매우 훌륭한 언어지.

남미쪽 은행 표준 규약때문에 회사 제품과 맞물려 돌아가는, 일종의 SI 프로그램을 짠 바가 있다.
3년전 자기 팀 제품 조차 제대로 이해하지 못하는 신입사원이던 나에게 한테 던져준 것이라 쉽게 생각했었는데(?) 의외로 이것 덕에 올라가는 매출도 있고, 영업쪽에서 관심이 많아서 계속 업데이트를 하고 있다.

그러나 3년전 처음 시작할 때 부터 팀 내의 일과 겹쳐서 바쁜 와중이라 코드를 쳐발랐더니, 그 뒤로는 쳐바르지 않고서는 코드를 짤 수가 없게 되었다. 아니, 다 변명이고 내가 조금만 부지런했다면 이런 사태를 충분히 막을 수는 있었겠지..

그때 당시에 코드를 쳐바른건 이해를 할 수 있다. 당시 한달 보름 정도 하루 4-5시간 자고 나머진 회사에서 일만 하다가, 겨우 일이 끝나서 남들은 칼퇴하는데 나는 이거때문에 또 2주 밤샘했다. 사람이라면 안쳐바르고 버틸 수 있겠는가?-_-; 하지만 그 뒤에  리팩토링을 하지 않은건 진짜 큰 잘못이다.

오늘도, 최근 마음이 많이 쓰이는 일도 있고, 퇴사한 사람이 싸놓은 똥치우느라 신경이 날카로워 있던 차에 하기 싫은걸 억지로 해야하니.. 그냥 대충 쳐발랐다.-_-; 물론 리팩토링도 하지 않을거다. 지금 하긴 너무 귀찮다 [...]

당초 일정 잡을때 생각했던 UI와 기능은 절반도 구현하지 않고.. 코드도 별 죄책감없이 전역 변수를 남발했고
특정 상황에서 쓰레드 세이프 하지 않을 가능성이 있음을 짐작하고서도 그 부분을 자세히 살펴볼 생각은 하지 않고 [ 특정 상황이 안 일어나길 바라며 ] 프로그램을 짰다.


그리고 집에 와서 맥주 한 캔 마시고 생각해보니까 죄책감을 느낀다.


역시 난 다른 사람을 욕할 자격이 없어. 제대로 할 수 있는 능력이 있고 없고를 떠나서, 그렇게 하지 않는 것 자체가 문제인걸.

&

그러고보니 이글루에도 오래간만에 포스팅이다. 프로그래밍 & 컴퓨터 관련으로 좋은 글을 많이 남겨보려고 했는데 내공도 짧을 뿐더러.. 내 실력은 대학원 졸업 이후 발전이 없는 것 같다.

다 내 게으름 때문인 것 같다.

병역특례가 끝나고, 이직을 하게 된다면 나는 내 이력서에 무엇을 쓸 수 있을까?