window 에서 명확하게 동적 메모리 사용하는 방법에 대해서 익히기. svnet.h 를 사용할 것인가. 아니면 단순하게 .so 파일만 사용할 것인가. sbr 보면 svnet.h 는 없고, 단순하게 .so 만 사용하므로 이것이 가능해 보인다. sbr 빌드 하는 것 리눅스에서 스스로 해보도록 합니다. 가장 쉬운 함수 하나 찾아서 사용해보도록 합니다. 어떤 cmake 를 기반으로 할 것인지 먼저 확인합니다. so 파일만 불러서 사용하도록 하는것을 시도합니다. 이것이 안되면 어디가 안되는지 찾아봅니다. 될 것 같은데. 현재 단순하게 usr/include, usr/lib 에 복사하는 방법은 되지 않습니다. svnet.h 는 불러오는 것 같은데, 그럼 이것 말고 .so 파일을 그 폴더 내에서 동적으로 로드할 수 있게 할 수 있을까? 해봅시다. 동적 라이브러리 사용하는 방법에 대해서 먼저 익히도록 합니다. 그리고 .so 파일과 .h 의 관계를 분명하게 알아냅니다. 리눅스내에서
|
library 사용범 왜 라이브러리가 필요한지, 어떤 종류가 있는지 어떻게 작성할 수 있는지 알아봅니다. 사용하는지에 대해서 이야기할 것. http://enst.tistory.com/entry/%EB%A6%AC%EB%88%85%EC%8A%A4-%EB%9D%BC%EC%9D%B4%EB%B8%8C%EB%9F%AC%EB%A6%AC-%EB%A7%8C%EB%93%A4%EA%B8%B0-%EB%B0%8F-%EC%82%AC%EC%9A%A9 라이브러리 특정한 코드 함수 혹은 클래스를 포함하고 있는 컴파일된 파일입니다. 라이브러리를 만드는 이유는 자주 사용되는 특정한 기능을 main 함수에서 분리시켜 놓음으로써, 프로그램을 유지 디버깅을 쉽게하고 컴파일 시간을 좀 더 빠르게 할 수 있습니다. 라이브러리화 해두면 해당 라이브러리만 다시 컴파일 시켜서 main 함수와 링키 시켜주면 됩니다. 라이브러리에도 그 쓰임새에 따라서 여러가지 종류가 있으며, 정적라이브러리 공유라이브러리 동적라이브리가 있습니다. 구분되어지는 특징은 적재 시간이 됩니다. 정적 라이브러리 .o의 단순한 모음입니다. 보통 .a 의 확장자를 가집니다. 컴파일시 적재되므로 유연성이 떨어집니다. 공유라이브러리 프로그램이 시작될 떄, 동적라이브러리 공유라이브러리가 프로그램이 시작될 때 적재되는 반면 이것은 프로그램 시작 중 특정한 때에 적재되는 라이브러리입니다. 플러그인 모듈 등을 구현할 때 적하밥니다. 설정파일 등에 읽어들인 라이브러리를 등록시키고 원하는 라이브러리를 실행시키게 하는 등의 매우 유연하게 작동하는 프로그램을 만들고자 할 때 유용합니다. |
프로그램들의 덩치가 커지는 문제는 유연성 문제에 비하면 그리 큰 문제가 되지는 않을 것 입니다. 라이브러리 만들고 사용하기. 2개의 파일을 활용합니다. gcc -c mysum.c ar rc libmysum.a mysum.o 프로그램을 컴파일 하기 위해서는 라이브러리의 위치와 어떤 라이브러리를 사용할 것이지를 알려줘야 합니다. 라이브러리의 위치는 -L 옵션을 이용해서 알려줄 수 있으며, -l 옵션을 이용해서 어떤 라이브러리를 사용할 것인지를 알려줄 수 있습니다. 만약에 사용할 라이브러리가 표준 라이브러리 디렉토리 경로에 있다면, -L 을 사용하지 않아도 된다. 표준라이브러리 디렉토리는 경로는 /etc/ld.so.conf 에 명시되어 있습니다. 정적 라이브러리 상태로 컴파일한 프로그램의 경우 컴파일시에 라입러리가 포함되므로 라이브러리를 함께 배포할 필요는 없습니다. |
공유라이브러리 제작 사용. 라이브러리 제작 방법에만 차이가 날 뿐입니다. mysum.c 를 -fPIC 옵션을 주어서 오브젝트 파일을 만들고, 다시 gcc를 이용해서 공유라이브러리르 제작합니다. 만들어진 라이브러리를 적당한 위치로 옮기고, ln 을 이용해서 컴파일러에서 인식할 수 있는 이름으로 심볼릭 링크를 걸어줍니다. 컴파일 방법은 정적 라이브러리를 이용한 코드의 컴파일 방법과 동일합니다. 공유 라이브러리는 실행시에 라이브러리를 적재함으로 프로그램을 배포할때는 공유라이브러리도 함께 배포되어야 합니다. 그렇지 않을 경우 공유라이브러리를 찾을 수 없다는 메시지를 출력하면서, 프로그램 실행이 중단될 것 입니다. 동적 라이브러리의 사용. 일반 공유라이브러리를 그대로 쓰며, 동적라이브러리르 호출하기 위한 방법상의 차이만 존재할 뿐입니다. dlopen 은 동적라이브러리르 적재하기 위해서 사용됩니다. 첫번째 아큐먼트 filename은 /usr/my/lib/libmysum.so 와 같이 적재하기 원하는 라이브러리의 이름입니다. 만약 적재시킬 라이브러리의 이름이 절대경로로 지정되어 있지 않을경우에는 LD_LIBRRARY_PATH 에 등록된 디렉토리에서 찾고, 여기에서도 찾지 못할 경우 /etc/ld.so.cache 에 등록된 디렉토리 리스트에서 찾게 됩니다. dlopen이 성공적으로 호출되면 해당 라이브러리에 대한 handle 값을 넘겨 줍니다. flag 는 RTLD_LAZY와 RTLD_NOW 중 하나를 정의할 수 있습니다. 정의되지 않은 심볼을 해결, dlerror는 dl 관련함수들이 제대로 작동을 수행하지 않았을 경우 에러메시지를 되돌려줍니다. dlopen, dlsym, dlcolser, dlopen 중 마지막 호출된 함수의 에러메시지를 되돌려줍니다. dlsym 은 dlopen 을 통해서 열린 라이브러리를 사용할 수 있도록 심볼값을 찾아줍니다. 심볼이라고 하면 좀 애매한데, 심볼값은 즉 열린라이브러리에서 본인이 실제로 ㅗ출할 함수의 이름이라고 생각하면 됩니다. handle 은 dlopen에 의해서 반환된 값입니다. symbol은 열린 라이브러리에서 본인이 실제로 부르게 될 함수의 이름입니다. dlsym 의 리턴값은 dlopen 으로 열린 라이브러리의 호출함수를 가르키게 됩니다. 리턴값을 void * 형으로 되어 있는데, void 형을 사용하지 말고 호출함수가 리턴하는 형을 직접 명시하도록 합니다. 물론 동적 라이브러리를 사용하기만 한다고 해서 이러한 기능이 바로 구현되는 것은 아니다. plug-in 의 효율적인 구성을 위한 표준화된 API를 제공하고 여기에 맞게 Plug-in 용 라이브러리르 제작해야만 할 것입니다. 동적라이브러리를 이용해서 plug-in 방식의 확장이 가능하도록 프로그램을 다시 만들어 보도록 할 것 입니다. 동적 라이브러리를 사용해보도록 하겠습니다. |
정리하기 공유 라이브러리. 처음에 mysum.c , mysum.h 를 만들고 이를 사용할 main 파일인 print_sum.c 를 만듭니다. 그런 다음에 object 파일을 만들 때 -fPIC 옵션을 넣어줍니다. gcc -fPIC -c mysum.c ( .c 파일로 만들어 줍니다. ) 다음 만든 mvlibsum.so 을 /usr/lib 으로 옮겨줍니다. 그 다음에 /etc/ld.so.cahce 를 업데이트 하기 위해서 ldconfig 를 사용합니다. 다음으로 gcc -o main main.c lmy_lib 을 사용해서 실행파일을 만들어줍니다. .so 파일을 만드는 것까지는 동일합니다. 동적 라이브러리 그 라이브러리를 사용할 응용프로그램을 컴파일합니다. 단 이때 동적 라이브러리를 사용하기 위한 과정을 거칩니다. |
okay 동적 라이브러리 사용하는 방법을 알았습니다. 리눅스에서 5번까지 즉 폴더까지 옮기고 ldconfig 를 실행해주어야 합니다. 공유 라이브러리는 실행시 라이브러리를 적재함으로 프로그램을 배포할때는 공유라이브러리도 함께 배포되어야 합니다. 그렇지 않을 경우 다음과 같이 공유라이브러리를 찾을 수 없다는 메시지를 출력하면서 프로그램 실행이 주단됩니다. error while loading shared libraries: libmysub.so: cannot open shared object 오류메시지를 발견했다면, libmysub.so 가 시스템에 존재하는지 확인해 봅니다. 만약 존재하는데도 위와 같은 오류가 발생한다면 이는 LD_LIBRARY_PATH 나 /etc/ld.so.conf 에 라이브러리 패스가 지정되어 있지 않을 경우입니다. 이럴때는 LD_LIBRAY_PATH 환경 변수에 libmysub.so 가 있는 디렉토리를 명시해주거나, /etc/ld.so.conf 에 디렉토리를 추가시켜주면 됩니다. export LD_LIBRARY+PATH=$LD_LIBRARY_PATH:/usr/my/lib okay cat /usr/lib >> /etc/ld.so.conf ldconfig ldconfig 를 실행하면 /etc/ld.so.conf 의 파일을 참조하여서 /etc/ld.so.cache 파일이 만들어지고, 프로그램은 ld.so.cache 의 디렉토리 경로에서 해당 라이브러리가 있는지 찾게 됩니다. http://enst.tistory.com/entry/%EB%A6%AC%EB%88%85%EC%8A%A4-%EB%9D%BC%EC%9D%B4%EB%B8%8C%EB%9F%AC%EB%A6%AC-%EB%A7%8C%EB%93%A4%EA%B8%B0-%EB%B0%8F-%EC%82%AC%EC%9A%A9 |
그렇다면 지금 가지고 있는 .so 파일을 이용해서 내부의 함수를 가져와서 사용하는 방법을 해야하는 것인가. 아니면 svnet.h 를 포함시키는 방법을 알아야하는 것인가. svnet.h 는 어디서 연결되어 있는지 알아봅니다. |
현재 가지고 있는 문제점이 무엇인지 분명하게 하기. catkin 에서 .so 파일을 불러들이는 방법에 대해서 알아보도록 합니다. |
pointer 에 대해서 예제 한번 확인하기. |
업계 동향도 조사해서 어떻게 돌아가는지 명확하게 파악하기. 할일이 하나씩 늘어나는 구나, 어떻게 사용하는지를 명확히 알아야지 좋지. 센서 융합 기반 정밀 측위 시스템과 자율 주행 기술 http://web.yonsei.ac.kr/hgjung/Ho%20Gi%20Jung%20Homepage/Publications/2015/월간자동화기술(센서%20융합%20기반%20정밀%20측위%20시스템과%20자율%20주행%20기술).pdf 센서 융합 기반 정밀 측위 시스템 기존에 사용되던 GPS, IMU와 함께 환경 인식 센서와 정밀 지도를 융하하여 자차의 위치를 추정하는 방식을 사용합니다. 그 예로 구글의 자율주행 자동차는 전파항법, 관성항법과 더불어 veloyne lidar의 infrared reflectivity를 기반으로 생성해 높은 정밀 지도를 사용한다. 반면, 양산 가능한 센서들만을 사용해서 자율주행을 수행한 다임러의 경우 정밀 측위를 위해서 전파항법, 관성항법과 더불어 스테레오 카메라와 미리 생성해 놓은 정밀 지도를 사용합니다. 전파항법, 야간, 전천후 하에서도 무선 전파를 이용하여, 측위, 항해 등을 위한 항법, 위성 간 또는 무선국 간 동기화가 매우 중요합니다. 관성 항법 장치는 잠수함, 항공기, 미사일 등에 장착하여 자기의 위치를 가지하여 목적지까지 유도하기 위한 장치입니다. 자이로스코프에서 방위 기준을 정하고, 가속도계를 이용하여 이동 변위를 구합니다. 처음 있던 위츠를 입력하면 이동해도 자기의 위치와 속도를 항상 계산해 파악할 수 있다. 아건후나 전파 방행의 영향을 받지 않는 장점이 있지만, 긴 거리를 이동하면 오차가 누적되어 커지므로 GPS나 능동 레이다 유도 등에 의한 보정을 더해 사용하는 것이 보통입니다. 자차의 위치를 추정하는 측위 기술은 최근 관심이 높아지고 있는 자율 주행 자동차와 첨단 운전자 보조 시스템에 반드시 필요한 기술입니다. 절대 위치를 제공하고, 위치오차가 누적되지 않는다는 장점이 있지만, 전파 수신 상황에 따라 위치 정밀도가 좌우된다는 한계를 가집니다. Inertial Measurement Unit 활용하는 관성항법 방식이 활용되고 있습니다. 짧은 주행 거리에서 정밀한 상대 위치를 제공한다는 장점을 갖지만, 누적 기반 위치 추정 방법의 한계로 인해 시간이 지속됨에 따라 오차가 지속적으로 증가한다는 한계. 센서 융합 기반 정밀 측위 시스템은 기존에 사용되던 GPS, IMU와 함께 환경 인식 센서(카메라, lidar)와 정밀 지도를 융합하여 자차의 위츠를 추정하는 방식을 사용합니다.
자동차가 달릴 수 있는 길의 상세한 정보를 간직한 정밀지도가 그 주인공. 도로정보를 포함할 뿐 아니라, 기존 지도보다 10배 이상 정밀해 실제 도로와 10cm ~ 20cm 이하의 오차를 갖는 지도를 말합니다. 현재 내비는 도로와 차량의 이동 방향 정도만 인식 가능, 일반 차선의 폭은 3m, 고속도로는 3.5m인데 차량이 큰 트레일러의 경우 폭의 길이가 2.5m 라이다 전자기파를 발사한다. 물체에 맞고 되돌아온 전자기파를 측정해 물체와의 거리가 얼마나 덜어져 있는지를 측정합니다. 위성위치확인시스템(GPS)와 함께 관성항범장치(INS)도 탐재. 지도의 기본값을 정부 차원에서 제작하는 일이 필요합니다. 구체적인 표준이 없어 기업, 연구소별로 각기 다른 정밀지도를 구축해 활용하고 있습니다. http://news.mk.co.kr/newsRead.php?no=137921&year=2017 |
인공지능 기술을 구현하기 위해 빅데이터와 플래솜도 중요하지만 이를 빠르게 연산처리하기 위한 하드웨어 기술이 뒷밤치돼야 합니다. Central rpocessing unit 을 넘어 Graphic Processing Units 처럼 고속 연산 처리가 가능한 범용적인 하드웨어가 등장한 것, 세 번쨰는 연구자들과 기업들이 꾸준히 연구 성과. 머신 러닝은 기존 데이터의 패턴을 기반으로 스스로 학습하는 형태의 알고리즘. 머신러닝을 위한 데이터가 방대해지고 복잡해지면서 인공지능은 예측에 필요한 양질의 데이터만 수집하기 위한 심층적인 학습이 필요, 딥러닝 기술은 지도 학습에 기반한 인공신경망의 진화된 기술로 보다 심층적인 학습을 할 수 있습니다. 반도체 업계에서는 GPU, FPGA, ASIC를 중심으로 인공지능에 최적화된 하드웨어를 개발하기 위한 움직임이 일어나면서 변화의 시기에 놓여져 있습니다. 컴퓨터 연산 기술에 있어서 인텔은 고성능 CPU를 생산해 왔고, 이를 바탕으로 PC 프로세서 시장뿐 아니라 서버 시장에서도 독점적인 지위를 누려오며 반도체 업계의 1위. 무어의 법칙 마저도 점차 한계를 드러내고 있다. PC 게임용 그래픽카드로 유명한 엔비디아는 인공지능으로 인해 GPU의 급격한 매출액 증가로 상승세를 타고 있습니다. 개인용 컴퓨터에서 원활한 게임속도를 지원하는 용도로 사용되어 왔던 GPU가 높은 컴퓨팅 연산능력을 필요로 하는 인공지능의 데이터 처리를 지원하기 위한 도구로 각광. 그렇다면 인공지능에서 CPU와 GPU의 연산능력은 어떤 차이점이 있을까. 코어는 프로세서가 동시에 풀 수 있는 문제의 수라고 볼 수 있습니다. 즉 CPU는 직렬처리에 최적화된 몇 개의 코어로 구성돼 명령어가 입력된 순서대로 순차적으로 데이터를 처리합니다. 반면 GPU는 CPU에 비해 훨씬 더 많은 코어를 탑재. 여러 명령어를 동시에 처리할 수 있도록 병렬처리에 최적화된 프로세서 입니다. GPU 컴퓨팅은 엔비디아가 C언어 기반 GPU 프로그래밍 언어인 쿠다라는 기술을 공개하면서 본격적으로 확산됐습니다. 12개의 GPU가 2000개의 CPU에 맞먹는 딥러닝 성능을 발휘한다는 사실을 발견하였습니다. 이미지넷에 출전한 알렉스가 들고 나온 알렉스넷은 기존의 시스템과 매우 달랐다. 인간의 뇌 구조를 본딴 인공신경망 모델인 나선형 신경망을 사용해 심층 신경망을 구현한 것으로, 기존의 기계 학습법을 더욱 발전시킨 딥러닝 이었습니다. 2015년 이미지넷 경진대회에서는 마이크로소프트팀이 GPU를 활용해 인간의 오류율인 5%보다 낮은 96% 이상의 정확도를 기록했습니다. 딥러닝을 구현하기 위해 방대한 데이터가 필요, 데이터 센터 구축이 필수적입니다. 데이터센터에서 사용되는 에너지 대부분을 차지하기 때문, 발생률을 감소시키면 덩달아 운영 비용을 절감할 수 있습니다. 하드웨어 측면에서 인공지능은 고도의 연산 처리도 중요하지만, 데이터센터의 에너지를 절감시킬 수 있는 반도체 칩 기술 또한 요구되고 있습니다. 특정한 용도에 맞도록 제닥된 주문형 반도체인 ASIC는 빠른 속도와 높은 에너지 효율의 특성을 지니고 있어 인공지능 전용 칩으로 각광받고 있습니다. Application-Specific Integrated Circuits. 대표적으로 2016년 상반기 구글은 딥러닝에 활용하기 위해 텐서 프로세싱 유닛이라는 ASIC를 자체적으로 개발. 데이터 기반 사업과 데이터 센터 내 효율성을 높이기 위해 사용하기 시작했습니다. 클라우드 컴퓨팅 플랫폼(GCP)에 1202개의 인텔 제온 프로세서와 엔비디아의 GPU 사용. 구글 데이터 센터 2015년 미국 36만 가구가 1년간 쓸 수 있는 양. ASIC 외에도 프로그래밍과 재설정이 가능한 비메모리 반도체의 일종인 FPGA 역시 높은 유연성 때문에 대용량 데이터 처리에 적합합니다. 데이터 센터 프로세서에 FPGA를 같이 쓰면 전력 감소에 많은 도움을 주게 됩니다. 프로그래밍과 재설정이 가능한 비메모리 반도체 FPGA 최근 FPGA가 부상하는 이유 중 하나는 범용 프로세서의 성능 향상이 한계에 달했기 떄문. CPU와 병렬도 작동하므로 전체 시스템의 혼란이나 병목현상 없이 추가적인 컴퓨팅 파워로 사용할 수 있기 때문. FPGA는 ASIC보다 초기 개발 비용이 저렴하고, 원하는 작업을 더 빠르게 처리할 수 있다. 재프로그래밍 가능한 FPGA는 칩을 번역 작업에 ㅚ적화해 사용하다가, 칩 회로 구성을 다시 설정해 가상비서 서비스에 맞춰 쓸 수 있습니다. FPGA는 인텔이나 AMD가 만드는 범용 프로세서와 특정 장비 전용으로 개발하는 주문형 반도체의 특성을 합쳤다는 평가. ASIC보다 느리고 복잡한 설계에 적용할 수 없다고 여겨집니다. 인텔의 경쟁사들은 인텔의 FPGA 제품을 사용할 수 없으니 자일링스와의 거래를 할 수 밖에 없다. 마이크로소프트가 데이터 서버에 FPGA를 탑재시킨 캐터펄트 프로젝트는 이미지 인식, 자연어 처리, 머신러닝 등 인공지능 관련 서비스를 강화하기 위한 전략. |