시간을 기록하다

우선 windows의 사용법이 아닌 LINUX 상에서의 사용법이며, windows에서는 icc가 아닌 icl이었던것 같다.일단 아래 링크를 따라가서 다운받자.
http://www.intel.com/cd/software/products/asmo-na/eng/340679.htm
사이트에 들어가 보면 알겠지만 인텔 컴파일러를 다운 받는 곳이다.
이곳으로 가서 비상업용 컴파일러를 받고. 받을때는 리눅스 용으로...만약 windows 사용자라면 windows 용으로 받으면 되겠다...

비상업용을 받을때는 이메일 주소 넣는게 있는데 그걸 쓰고나면 그 메일주소로 뭔가 하나 날아온다ㅋㅋㅋ
메일받고 열어보면 시리얼넘버가 쓰여져있는데 그걸 입력하거나 메일에 쓰여져있는 링크를 이용해서 사이트에 들어가면 다운받을 수 있다.

일단 다운 받으면 용량이 꽤나 큰데...내 경우엔 1G 정도되었다. 일단 다운 받은걸 압축 풀면 install.sh 파일이 있는데 이 파일을 이용해서 설치한다. 설치하던 중 내 경우에는 libstdc++5 가 안깔려 있어서 설치가 안된다길래...apt-get으로 먼저 설치하고 나서야 icc를 설치할 수 있었다.

기본적으로 설치후에는 icc 컴파일러가 어디에 설치되었는지 얘기해주는데 환경설정은 자동으로 안되는 것 같다. 그래서 나는 그냥 alias를 이용해서 사용하고 있음ㅋㅋㅋ 확인을 위해 우분투의 시스템 감시를 이용해서 cpu가 정말로 멀티로 동작되는지 확인을 위해 간단한 루프 두개를 만들어서 확인을 해보았다.

결과를 확인해보니 프로그램이 돌아가면서 계산량이 적어서인지 잠깐이지만 cpu를 나눠서 쓰고있다...오~~
(결과화면을 좀 더 그럴듯하게 보여주고 싶어서 소스코드에서 계산하는 범위를 비슷하게 바꿔서 좀 더 리얼하게 결과를 보여줘야겠다는 생각도 했으나...캡쳐하는데까지 걸리는 그 10여초의 시간이 의외로 귀찮아서 그냥 이 그림으로 올리게 되었다는....-_-;;;)

컴파일 명령은 아래와 같이 했다.

icc -openmp -o test test.c -no-multibyte-chars -static-intel

옵션 중에 -openmp 는 멀티 코어를 사용하기 위해 썼는데 프로그램 자체가 작아서 그런지 오히려 icc를 이용한 단일 코어의 속도가 더 빨리 나왔다;;; 나중에 데이터양이 큰 프로그램을 만들어서 멀티코어로 돌려봐야 좀 더 정확하게 확인 할 수 있을것 같다.

다른 옵션으로는 -no-multibyte-chars 와 -static-intel 을 사용했는데
-no-multibyte-chars 옵션을 안쓰면 컴파일에러가 나는데 왜그런지 모르겠다.
언어권이 달라서 그런건지...유니코드를 사용하면 그런건지 확인을 못해봤다. 이 부분은 누군가가 설명해주길 바라며ㅋㅋㅋㅋ

-static-intel 은 안써도 컴파일은 되는데 안쓰면 디폴트로 공유라이브러리를 쓰는것으로 판단된다. 나는 alias로 icc만 링크해서 쓰다보니 라이브러리 링크를 제대로 못해서인지 실행하면 제대로 안돌아간다. 그래서 그냥 static library를 쓰려고 일부러 옵션을 주었다. 실제로 static 라이브러리를 사용한다고 해도 실행파일의 용량이 3~400k 정도 늘어날 뿐이기 때문에 별 문제는 없을것으로 판단된다.

ps. 어느 정도 알게됐다 생각하면 앞에 새로운 벽이 있고, 다시 그 벽을 넘어섰다 생각하면 더 높은 산이 있고...그런게 프로그래머인가보다...ㅠ_ㅠ

크리에이티브 커먼즈 라이선스

이 저작물은 크리에이티브 커먼즈 코리아 저작자표시 2.0 대한민국 라이선스에 따라 이용하실 수 있습니다.

요즘 리눅스에서 프로그램을 짜다보니 항상 유니코드를 염두해두지 않으면 안되게 되었다. 그리고 이제는 오히려 유니코드를 사용하게 되면서 오히려 이식성 면에서 유니코드가 얼마나 좋은지를 느껴가고 있다.

"유니코드(Unicode)는 전세계의 모든 문자를 컴퓨터에서 일관되게 표현하고 다룰 수 있도록 설계된 산업 표준이다. 유니코드협회(Unicode Consortium)가 제정하며, 최신판은 2008년 4월에 공개된 유니코드 5.1이다."

위의 내용은 위키백과에서 유니코드를 검색하면 찾을 수 있는 내용이다. 이제까지 나는 유니코드에 대해 잘못 알고있었던 것 같다. 간혹 utf-8, utf-16, ...등과 같은 것들을 들었을 때 그것들(utf-8, utf-16...등)이 유니코드 인줄 알고 있었다. 하지만 유니코드와 utf-8등은 엄연히 다른 의미이다.

유니코드라는 것이 문자들이 저장되어 있는 문자 테이블이라면 utf-8등과 같은 것들은 이 유니코드 테이블에 대한 인코딩 방법이라 할 수 있다. 예전에 아스키문자는 1바이트로 한글(완성형)과 같은 문자는 2바이트로 처리했던 기억이 있는데, 그런 이유에서인지 유니코드라 하면 그냥 단순히 2바이트라고 생각하게 되었다. 물론 나 말고도 인터넷을 검색하다보면 그렇게 생각하는 사람이 많이 있다는걸 느꼈다.

우선 유니코드의 인코딩은 utf-8, utf-16, ucs2, ucs4 등의 다양한 방식이 있다. ucs2와 utf16 계열은 모든 문자를 2바이트로 인코딩한다. 이렇게 모든 문자를 2바이트로 표시하면 영어권이나 한글, 한자, 일본어 등이 표현 가능하다. 하지만 한글 고대어 등의 2바이트 범위를 넘어가는 문자코드는 표현할 수 없게된다. 그래서 ucs4와 같이 문자를 4바이트로 인코딩하는 방법이 있는 것이다. 4바이트를 사용하면 대부분(아마도 모든 문자가 다 들어갈듯...)의 문자를 표현할 수 있지만 영어권(아스키문자만 있으면 되는) 문자를 사용하는 애들이 보기엔 엄청난 낭비가 될듯ㅋㅋㅋ(내가 시킨일이 아니야-0-)
그래서 나온것이 utf-8 인것같다. 뒤에 8이 붙어 있다고해서 1바이트(8비트)만을 사용하는 인코딩 방식은 아니며, utf-8은 가변적인 인코딩 방식이다. 즉 U+0000 ~ U+007F 까지의 문자들은 그대로 1바이트로 표기하면서(기존의 아스키 문자열도 그대로 호환), U+007F보다 큰 범위의 문자들은 그 범위에 따라 각각 2바이트, 3바이트, 4바이트로 인코딩 되는 것이다.

아래 표는 위키백과에 나와있는 표를 베껴왔습니다(꾸벅).

Unicode 범위	UTF-8 이진표현
U+000000-U+00007F	0xxxxxxx (1바이트 : ASCII와 동일한 범위)
U+000080-U+0007FF	110xxxxx 10xxxxxx
U+000800-U+00FFFF	1110xxxx 10xxxxxx 10xxxxxx (3바이트 : 한글)
U+010000-U+10FFFF	11110xxx 10xxxxxx 10xxxxxx 10xxxxxx

이러한 가변적인 인코딩 방식으로 낭비를 줄일 수 있고, 한글의 경우도 utf-8을 사용하면 여러가지로 이점이 있다. 특히 언어처리(NLP)를 하는 사람에게는 프로그래밍할 때 모든 문자를 유니코드로 변환한 뒤에 문자에 대한 처리를 한다면 인코딩방식에 독립적인 프로그램을 만들 수 있을 것이라 생각되며, 실제로도 그렇다.

 

크리에이티브 커먼즈 라이선스

이 저작물은 크리에이티브 커먼즈 코리아 저작자표시 2.0 대한민국 라이선스에 따라 이용하실 수 있습니다.

STL에서 자주 사용하게 되는 컨테이너. 그리고 그 컨테이너를 사용할 때 해당 컨테이너 안에 몇개의 원소들이 있는지 알기 위해 사용하는 size() 함수.

이제까지 별 생각없이 사용했던 size() 였으나 얼마 전에 size() 의 구현 방식을 알게되고 난 뒤로는 앞으로는 좀 더 신경써서 써야되겠다고 생각했다. "Effective STL"이라는 책에서 말하길 size의 구현 방식은 컨테이너 안의 원소에 대해 하나씩 모두 갯수를 세도록 되어 있다는 것...-0-

그 전까지는 size()의 구현이 컨테이너에 새로운 원소를 추가할 때 마다 어떤 count를 증가시키도록 되어 있어서 size() 는 단순히 그 count를 반환해 줄 것이라 생각했었는데 splice() 라는 함수와의 충돌로 인해(뭐...꼭 이것만이 아니더라도 다른 요인들도 있었겠으리라 생각되지만) 일반적으로 size()의 구현은 모든 원소의 갯수를 하나씩 세는 것으로 되어 있다는 얘기였다...OTL
뭐...결국 책에서의 얘기는 만약 size()==0 과 같은 문장을 사용할 때는 size() 대신 empty() 를 쓰라는 얘기ㅋㅋ 어찌되었건 프로그램을 짜다보면 컨테이너 안의 원소 갯수를 세어야할 경우가 생기게 되는건 어쩔 수 없는 일이고 만약 갯수가 0개인지 아닌지를 확인하기 위한 것이라면 empty()쓰라는 것이다.

물론 size()의 수행시 Associated Container(우리말로는 대부분 연관컨테이너로 번역하는듯)는 대부분 균형트리의 형태로 구현되어 있으니 O(logN)의 복잡도를 가지겠지만 List와 같은 Sequential Container(왜 이넘은 그냥 시퀀스컨테이너로 번역하는건지...차별하나??)의 경우 O(N)의 복잡도를 갖게 될 수 있다는 소리;;
뭐...데이터양이 수백~수천의 수준에 머무르는 프로그램이라면 이런건 신경쓸 필요도 없겠지만 수백만이상의 데이터를 다루게 된다면 이 차이는 확실히 프로그램 성능에 영향을 미치게 될 것 같다.
내가 여기서 뻔뜩하고 스친 생각은...이제까지 별 생각없이 써왔던 size()==0 이라는 문장이 오쉣~ 이었다는거...-_-;;

ps. 가끔씩 하드웨어가 발전하면 이런건 걱정할 것 없다고 말하는 분들이 있는데...그러면 나는 이런말을 해주고 싶다. 그런 시대가 왔을 때는 우리가 처리해야할 데이터가 수백만~수천만 수준의 단위가 아닌 수백억~수천억의 수준이면 어떻게 할거냐고...-_-;;

크리에이티브 커먼즈 라이선스

이 저작물은 크리에이티브 커먼즈 코리아 저작자표시 2.0 대한민국 라이선스에 따라 이용하실 수 있습니다.