| 비록 궤도 진입에 실패하긴 했지만(궤도 수정을 위해서 위성 수명이 줄긴 하겠지만) 첫술에 배부르랴.. 첫 발사에 이정도면 충분하다고 개인적으로는 생각합니다. 이번 기회가 우주산업 발전에 큰 이바지를 하길 기원합니다. 공대생 화이팅 ㅜㅜ ----- 수정 ------ ps. 나로호 위성에는 자체 추진제가 없다는군요.. 이런 안습..  (0)  (0) |
       
일단 현재 서버가 제공하는 모든 기능을 관리하는 서버 툴은 완료... 그런데 클라이언트가.... (0) (0) |
 요놈의 UI 때문에 서버 만드는것 보다 최소 두배는 시간이 더 걸리는듯 ㄱ- 그냥 네트워크 모듈을 다시 만들고 패킷 구조체 변환 노가다를 하는 일이 있더라도 C#으로 할 껄 그랬나... (0) (0) |
 중간에 두과목이 서로 시간표가 바뀐걸 모르고 수강신청 하다가 좀 어버버 하긴 했지만 무사히 마쳤다. 인공지능이 두렵구만... |
| 요즘과 같은 다중코어 시대의 컴퓨터의 CPU 활용도를 쭉쭉 끌어올리기 위해서는 동시성을 잘 활용해야한다. 그런데 다들 아시다시피 스레드를 이용하여 공유 메모리를 접근 하기 위해서는 해당 메모리를 다른 스레드에서 접근하지 못하도록 동기화 객체로 묶어야한다. 이런 동기화 행위 자체가 성능은 그렇다치더라도 생산성을 너무나도 크게 해친다. 싱글 스레드 프로그램과 같이 그냥 대충 짜다간 데드락 걸리기 십상이다. 구조 설계하는데도 애로사항이 꽃핀다. 위에서 말한 데드락을 회피하기 위한 단방향 접근 방식 설계가 필수이고 생산성을 올리기 위해 동기화 객체 사용을 자동화 할려고 해도 쉬운게 아니다. 전날 술이라도 먹고 아침에 해롱한 상태로 코딩이라도 했다간 지옥을 맛보게 될터이니 말이다. 프로그래머 정신력을 제물로 성능을 이끌어내는 것이라 할 수 있으며 이로써 성능이 올라가는거야 좋긴 하지만 효율이 너무 떨어진다. 코드 한줄 짜더라도 신경쓸게 너무 많고 싱글 스레드에 비해서 문제점이 바로 드러나지도 않고 나중에 들어나더라도 단박에 찾기도 힘들다. 오히려 이러한 사항들 때문에 멀티 스레드 프로그래밍을 하는 진입장벽이 높아지긴 하지만... 밥그릇 챙기기에 대한 대가로 치자면 귀찮은걸 싫어하고 반복적인걸 싫어하고 숟가락만 얹으면 되는걸 좋아하는 게으른 프로그래머로써는 여간 신경 쓰이는게 아닐수 없다. 그래서 나온게 intel TBB나 OpenMP와 같은게 있긴 하다. 서버 프로그래밍을 하면서 이런 해악에 좀더 숟가락만 얹고 싶어하는 욕망이 샘솓기 때문에 어느새 정신차리고 보면 저런 라이브러리와 비슷한 행동을 하는 패턴으로 설계를 하는 본인을 본다. 그러다보니 이미 잘 차려진 밥상을 그냥 지나치기는 좀 아깝다. STL도 멀티스레드에 최적화된 자료구조가 아니다보니 접근시 동기화 기준을 전체 컨테이너 기준으로 동기화가 진행되어야 하다보니 성능도 좀 안습니다. 대부분 멀티 스레드 프로그래밍에서 연산은 읽기가 주되다보니 어쩌다 가끔 쓰기하는 경우와 동기화 하기 위해서 매번 락을 걸어야하는 부분도 성능을 떨어뜨리는 요인이 된다. 그래서 많은 접근이 필요한 부분은 read-write lock으로 구성을 하여 성능을 꾀하긴 하지만 이런것 또한 일일히 신경을 써줘야하고 컨테이너의 일부 원소만 접근 할 때도 전체를 동기화 해야하는 사실은 변함이 없기 때문에 근본적인 해결은 되지 못한다. 그런면에서 intel TBB와 OpenMP를 보자면 OpenMP는 멀티스레드에 최적화된 자료구조를 제공하진 않는다. 단지 컴파일러 레벨에서 코드에 명시된 블럭을 멀티 스레드로 빼주는 역할을 하고 해당 코드 블럭을 수행하는 스레드간에 동기화를 보장해주는 정도 밖에 안된다.(이부분은 OpenMP를 본지가 오래되서 요즘은 어떤지 모르겠지만 아직까지 Visual studio에서 지원하는 OpenMP 버전이 그대로인걸 보면 별반 다를건 없다고 생각한다.) 그와 반대로 intel TBB는 자체 자료구조를 제공한다. OpenMP와 같은 코드 단위 병렬화를 하지는 않고 라이브러리이기 때문에 템플릿을 이용하여 코드블럭의 병렬화를 지원하긴하지만 OpenMP에 비하자면 좀 쓰기가 거시기 하다. 간편하게 병렬화가 안되고(OpenMP의 컴파일러 지시자를 이용하는 방법보다) 클래스를 만들고 이를 이용하여 템플릿으로 작성을 해야하기 때문에 솔직히 OpenMP에 비해서 코드 흐름 면에서는 영.. 꽝이다. 하지만 c++ x0가 나오고 익명 함수나 클로저를 그대로 쓸 수 있다면 또 다른 이야기가 될 수 도 있다. 그렇기 때문에 코드 블럭은 OpenMP를 이용하여 병렬화 시키고 자료구조는 intel TBB를 이용하여 동기화 시킨다면 뭔가 궁합이 잘 맞아 떨어지지 않을까 생각도 해보긴 한다. 소프트웨어 트랜젝션 메모리(STM)라는 것이 존재하긴 하지만 아직까지 만능이 될수는 없고 싱글 스레드 프로그래밍과 같이 대충 짜도 될 정도의 라이브러리가 존재하는건 아직 못봤다. 그런다고 직접 구현하기에는 배보다 배꼽이 크다. 하드웨어 트렌젝션 메모리가 구현이 된다면 운영체제 레벨에서 지원을 해주는 그날이 올 때 이런 문제점과 안녕을 고할수 있을지 모르겠지만... 아직까지는 넘사벽이고.. 현존하는 라이브러리를 이용한다면 intel TBB + OpenMP 조합이 괜찮지 않을까 싶다.(어디까지 추측이며 시도 해보진 않았다) 그렇지만 이 둘도 만능은 아니기에 일반적인 해법이 될 수는 없다. 결론은.. 아.. 멀티 스레드 프로그램하기 짱나 (0) (0) |
|
댓글을 달아 주세요