ubuntu / embeded 환경에서 STL / boost 사용
안녕하세요 여러분, 저는 이제 막 linux와 embeded 환경에 도전하려 하는 초보 개발자입니다. (부서 이동으로 인해..)
제목과 같이 ubuntu / embeded 환경에서 STL 및 boost 사용이 어떤 영향을 주는지 궁금합니다.
windows PC 환경에서는 무턱대고 boost / stl을 사용하고 있었는데, 새로운 부서로 옮기고 나니 STL을 쓰지 말라고 하는군요. (하지만 현실은 꽤 많이 사용 중이더라는..)
stl을 사용 제한한 이유는 아래와 같습니다.
1. binary가 50%쯤 커진다?
2. 디버깅이 어려워진다.
3. 느리다.
저는 boost와 STL은 단짝이라고 생각하고 있어서 점점 슬퍼지고 있습니다. boost 또한 공식 도입된 것이 아니라서 사용이 불투명합니다.
곧 개발을 시작해야 하는데..
솔직히 STL / boost 에 익숙해져서 (아직 많이는 모르지만) 사용하고 싶은 마음이 간절합니다.
반박을 위한 정리를 해보자면,
1번. 이건 할 말이 딱히 없네요.. 요즘 시스템이 좋아져서 크게 영향이 없지 않을까 생각도 해보는.. (현재 개발중인 embeded에서는 1G 메모리 사용 중이더라는..)
2번. 이것도 사실 딱히 할 말이 없긴 하네요.. Visual Studio만 사용해봤는데, 여기서도 한 번씩 어려움이 있으니.. (특히 boost) linux에서는 어떨지..
3번. STL은 일반화 개념으로 알고 있어서 속도가 느린 것은 어느 정도 예상하는데, 어중간한 코딩 실력으로는 안정화된 품질을 보장하면서 STL의 속도를 뛰어넘기가 쉽지는 않은 것 같습니다.
신규 프로젝트에 개발환경을 바꿔보자고 제안하려 하는데 미리 경험해보신 여러분들이 계시다면 고견을 듣고 싶습니다.
물론 전체 프로젝트는 아니고, 제가 맡은 팀에 한해서 적용 제안해보려 합니다. (C++11과 함께)
많은 의견 부탁드립니다~
어렵네요.
2008년 기준으로 테스트한 결과 입니다. 요즘은 어떤지 확인해봐야 합니다.
- 속도 성능 문제
배열 > ATL MAP (VC2005) > STL Port 5.2 dll > 나머지
- stl 이 C++ 컴파일러에 포함되어 있습니다.
여기서 컴파일 테스트하기 수월합니다.
http://en.cppreference.com/w/cpp/container/array
- boost 는 잘 모르겠네요. 사용해본적이 없어서...
- 디버깅 문제
vc2008 부터는 stl 디버깅을 지원해줄겁니다.
- 용량문제
STL Port 5.2 DLL 로 별도 설치
성능을 평가한 통계 그래프가 몇가지 보이네요.
unordered_map
http://www.google.co.kr/search?q=unordered_map&hl=ko&gbv=2&prmd=ivns&source=lnms&tbm=isch&sa=X&ved=0ahUKEwj3-_zs5__JAhWHFaYKHUNtCDQQ_AUIBQ
http://kldp.org/search/google?cx=partner-pub-6651292044448473%3Ajz430d1s80g&cof=FORID%3A11&query=unordered_map&op=%EC%B0%BE%EA%B8%B0&hl=ko&safe=medium&form_build_id=form-8g2_JQsfenul_PNwwxYm-JY9-EadTQaNy4LhRK63UI0&form_token=be902466bc2772dc392ec174534b1d96&form_id=google_cse_searchbox_form
boost map
http://www.google.co.kr/search?q=boost+map&hl=ko&gbv=2&prmd=ivns&source=lnms&tbm=isch&sa=X&ved=0ahUKEwiBkrD7y67JAhVnI6YKHZV6BAQQ_AUIBQ
----------------------------------------------------------------------------
젊음'은 모든것을 가능하게 만든다.
매일 1억명이 사용하는 프로그램을 함께 만들어보고 싶습니다.
정규 근로 시간을 지키는. 야근 없는 회사와 거래합니다.
각 분야별. 좋은 책'이나 사이트' 블로그' 링크 소개 받습니다. shintx@naver.com
제안을 해봤는데
Boss 께서는 STL의 성능저하를 이유로 거절하시네요.
시간만 되면 Case별로 조사라도 해보고 싶은데... 항상 느린 것도 아닐텐데 근거없이 무턱대고 제안하기도 어렵고 난감하네요.
그런데 왜 STL이 성능저하의 문제가 있는건가요???
그런데 왜 STL이 성능저하의 문제가 있는건가요???
글쎄요...
딱히 근거자료를 제시하시는 것은 아니어서 저도 잘 모르겠네요.
하다못해 sort의 경우에도 수량에 따라 quicksort와 mergesort를 동적으로 사용하는 것으로 알고 있어서 일반적인 코딩보다 빠른 것으로 알고 있는데..
특히나 C++11 STL의 경우 emplace_back 같은 기능으로 불필요한 복사에 의한 비용도 줄일 수가 있고..
"보통의" 프로그래머가 만든 코드가 STL보다 뛰어나려면 너무나 많은 노력이 필요할 것이라는게 제 추측입니다.
자료없이 논의하려니 좀 난감한 부분이 있긴 하네요. 틈날때 조금씩이라도 비교 자료를 모아봐야겠다는..
code-bloating은 요새 워낙 컴파일러가
code-bloating은 요새 워낙 컴파일러가 좋아져서 크게 차이나지 않는데다가, STL을 안쓰면 결국 컨테이너를 직접 만들어서 써야할텐데 직접 만든 컨테이너가 STL 컨테이너보다 성능이 확연히 나을 것 같지는 않아보입니다.
gcc의 경우 std::sort()에 introsort( https://en.wikipedia.org/wiki/Introsort )를 사용하는데 worst case O(n logn) 알고리즘을 직접 짜다가 쓰느니 그냥 std::sort()를 쓰는게 생산성 면에서도 좋아보이구요.
아마도 윗분이 다루는 언어가 C가 메인이고 C++98 이전의 오래된 C++ 이미지를 갖고 있는 것 아닐까요?
감사합니다.
새로운 사실을 알게 되었네요. introsort라니.. 들어보지도 못했었네요.
제 생각으로도 kukakya님 말씀대로일 것 같습니다.
제가 결정권자라고 하더라도 새로운 것(C++11이 새로운 지는 정말 의문이지만...)을 받아들이기에 충분한 자료와 검증이 없는 상태에서는 쉽사리 바꾸기가 어려울 것 같습니다.
좀 더 공부해봐야겠네요.
그렇다면 C++98과 C++11은...
그럼 혹시 C++98을 C++11으로 올려보신 분 계실까요?
새로운 버전을 사용하기 위해 단점 또한 고려해봐야 할 것 같은데, 제가 여태 경험한 바로는 단점에 대한 내용은 없어서..
개발 환경을 바꾸는 데 노력이 많이 들까요?
그리고 어차피 하위 문법들은 모두 지원할텐데, 반드시 고려해야 할 사항 같은게 있을지..
(stl의 경우 set에서 const_iterator만 지원한다던가.. 사실 이게 맞는 것 같지만)
이번에는 제가 조사된 자료가 없어서 변경 제안이 관철되긴 어려울 것 같고, 다음에라도 시도해보기 위해 조금씩 공부해보려 합니다.
기존의 개발자들이 가장 큰 고려
기존의 개발자들이 가장 큰 고려 사항이죠.
C++11의 도입을 제안했다가 압도적 다수로 거절된 적이 있어서.
공부하기 싫으면 개발자를 하지 말던지...
흠..
한 사람이 쓰게 되면 다른 사람도 공부해서 써야 하는 것이 문제겠네요.
그런데 어차피 모듈별로 컴파일을 달리 하면 팀 내에서의 문제가 아닐까 생각하는데
C++11 보다는 C++14로 진행하시는 것이 더
C++11 보다는 C++14로 진행하시는 것이 더 나을 것 같습니다. gcc도 차기 버전인 6.0에는 -std=gnu++14가 디폴트가 된다네요. (https://gcc.gnu.org/gcc-6/changes.html)
C++98을 C++14로 변경하는데 가장 큰 걸림돌이 컴파일러 버전인데, gcc나 clang 최신 버전을 쓰시면 C++14 feature들이 거의 다 구현되어 있지만 VS의 경우 닷넷을 밀고 있기 때문인지 C/C++이 찬밥이라 C++14 구현이 아직 덜 된 부분이 있습니다. (http://en.cppreference.com/w/cpp/compiler_support)
ABI compatibility도 고려하셔야하는데, 한 예로 std::list<>::size()의 time complexity requirement가 O(n)에서 O(1)으로 변경되어 std::list<>의 크기 자체가 달라졌습니다. 따라서 공유 라이브러리의 함수 인자로 std::list<>를 넘기실 경우 공유 라이브러리까지 전부 다 recompile해야합니다. gcc의 stdc++는 dual abi를 지원하고 있어서 어느 정도 해결이 가능한데 VS는 제가 쓰고 있지 않아서 잘 모르겠네요.
크로스플랫폼까지 고려하신다면 또 하나 고려할 점이 있는데 같은 container/algorithm이라도 STL 구현체에 따라 성능이 달라질 수 있습니다. 표준에 time complexity requirement가 주어지긴 하지만 절대적인 성능의 지표가 아니다보니 구현체에 따라 퍼포먼스 차이가 있을 수 있어서 이 부분은 사용 중인 환경에서 테스트를 해보시는 것이 좋을 것 같습니다.
C++11 (혹은 14)의 단점은 없을까요? 전부
C++11 (혹은 14)의 단점은 없을까요?
전부 rebuild 해야 한다는 것 말고는...
그럼 선택하지 않을 이유가 없을 것 같은데..
(위에서 말씀하신 것 처럼 코드를 공유하면 공부를 해야 한다는 것 외에는)
모든 valid C++03 코드가 valid
모든 valid C++03 코드가 valid C++14(또는 C++11) 코드가 되는 것이 아니라서 검증이 필요하다는 것이 단점이라면 단점입니다. (http://stackoverflow.com/a/6402166/1030861)
테스트케이스가 잘 작성되어있다면 일단은 컴파일러 플래그에 C++14를 추가해보시는게 어떨까요? auto 와 r-value reference만으로도 C++14를 사용하기에 충분하다고 생각합니다.
댓글 달기