great code 라는 책에 대한 평가와 어셈블리에 대한 평가
글쓴이: gurugio / 작성시간: 수, 2008/09/03 - 10:20오전
고급 언어가 어떻게 어셈블리로 변환되는지
어떻게 기계가 동작하고 어떻게해야 빠르고 효율적인 코드를 만들 수 있는지를
다루고 있는 책이 몇권 있지만 저는 great code, binary hacks 라는 책을 가지고 있습니다.
great code는 올해 안으로 읽으려고 계획한 책이구요.
그런데 이 great code의 아마존 서평과 강컴 서평을 보면 평가가 아주 다릅니다.
아마존에서는 대부분이 4~5개의 별을 주었고
강컴에서는 2~3개를 주었습니다.
저는 이 차이가 국내와 국외에서 바라보는 로우 레벨 프로그래밍의 관점 차이라고 생각합니다.
코딩에 급급하거나 혹은 제품 생산만을 목표로 하는 개발과
ART가 되고자하는 개발은 확실히 다르다고 생각합니다.
고급언어로서 HASKELL이나 LISP 등 완전한 추상화를 추구하는 언어로의 개발이 아니고
또 최소한 컴퓨터 상에서 컴퓨터가 동작하는 원리를 이용한 개발을 한다면
로우 레벨에 대한 이해가 있어야겠지요.
.. 물론 꿈같은 이야기이지요. 오늘도 코드 생산에 허덕이는, 코드 생산에도 막막해하는 저에게는요.
댓글
어떻게 보면 조엘 온
어떻게 보면 조엘 온 소프트웨어에도 잘 나와 있듯이 경제적인 문제와 밀접한 연관이 있다고 봅니다. 다양하고 많은 수의 고객이 사용하는 패키지 프로그램이나 VM(ex. JVM, CLR), Compiler(최종 기계어를 생성하는)같은 시스템 프로그래밍을 하는 곳에서는 로우 레벨한 지식이 매우 많이 필요하니 그에 대한 수요가 많겠지만, 좋은 성능보다는 일단 동작하는 제품을 빠르게 만들어야 하는 곳에서는 그런 수요가 적겠죠.
아무래도 우리나라의 경우는 전자에 해당하는 경우가 적기 때문에 이런 현상이 발생하는게 아닐까요? 물론 우리나라도 로우 레벨한 수요가 점점 증가하고 있다고 생각합니다. 시스템 소프트웨어를 만드는 곳도 늘어나는 것 같고, 더구나 임베디드 시장이 활성화 되면서는 더 그런 것 같구요.
개인적으로는 "현대" 컴퓨터 동작을 잘 이해하려면, asm과 씨를 어느 정도 수준까지 이해해야 된다고 생각합니다. "컴퓨터로" 문제를 푸는 방법 뿐만이 아니라, "컴퓨터가" 어떻게 문제를 푸는지도 알고 있는게 좋습니다. 저도 한 때는 파이썬이 최고고 딴 거 다 필요 없다고 생각했던 적도 있지만, 지금 생각해 보면 참 무식했었단 생각이 듭니다. 지금도 무식하긴 마찬가지 입니다만 ;;
물론 고급 언어로 개발하면서 이런 문제들을 항상 일일이 고려해야 한다는 뜻은 아닙니다 ;;
동의합니다.
개인적으로
우리나라 사람의 성향이 너무 목적 지향적이 아닌지 생각이 종종듭니다.
밑에서부터 체계적으로 하나씩 준비해 가는게 소흘한 경우를 봅니다.
목적은 이루고도 그 하부는 하나도 우리께 아닌경우가 너무 많죠.
번역서의 한계일수도..
C 언어를 high-level assembler라 부르는 무리 중 한 명으로서..
하드웨어에 대한 이해가 효과적 프로그래밍을 위해 필수적이라는 데는 동감하지만,
그와는 별개로 great code 에 대한 개인적인 평가는 그닥 좋지는 않습니다.
저는 1권 번역본을 잠깐 본 적이 있는데, 너무 편협한 관점에서 섣불리 판단하는 것인지 모르겠지만
일단 책 편집이 너무 안습이고.. 내용도 너무 과거의 하드웨어를 다루고 있더군요.
기본 개념을 잡는다는 면에서는 과거의 하드웨어라 해도 유용할 수 있지만,
그럴거면 차라리 MIX나 DLX 처럼 기본적인 가상의 아키텍처인 경우가 더 깔끔하지 않을까 합니다.
저는 오히려 제대로 된 한글 교과서가 없는 것이 더 안타깝네요.
아참.. 제가 1권/2권에
아참.. 제가 1권/2권에 대한 구분은 안해놨네요.
저도 1권은 목차만 보고 사지도 않았습니다.
학생들이 보기에는 적당할 것 같지만 개발자로서는 별로였습니다.
저자가 쓴 Art of assembly를 본 사람으로서
2권부터의 내용은 굉장히 기대를 하고 있었는데요
역시 조금식 내용이 깊어지는 것 같습니다.
----
세상을 바꾸는 것은 단 한 사람. 오직 하나님의 사람뿐이다.
http://www.asmlove.co.kr
http://blog.naver.com/gurugio
어셈블리를 잘
어셈블리를 잘 안다고 코드가 돌아가는 원리까지 잘 안다고 보기는 좀 그렇습니다. 실제로 어셈블리로 코드를 작성하다보면 가독성이 굉장히 안좋아지고 c에서는 1줄에 표현되는 간단한 것들이 어셈블리에선 10줄까지도 될 수 있죠.
하지만 어셈블리를 알아야지만 할 수 있는 것들도 있습니다. :)
MMX, SSE, SSE2, SSE3, SSE3+, 3DNow 뭐 이런 streaming instruction 을 이용한 코드 최적화 같은 것들이 그 중요한 예가 될 수 있겠죠.
사실 코드가 돌아가는 원리를 알고 싶으시면 컴퓨터 구조나 컴파일러 이론을 공부해보시는게 더 좋을거에요. 다만 국내에선 이런 것들에 워낙 관심 없다 보니 -_-; 잘 나온 책 찾는 건 정말 어려울거에요.
--
오랫동안 꿈을 그리는 사람은 그 꿈을 닮아간다...
http://mytears.org ~(~_~)~
나 한줄기 바람처럼..
오랫동안 꿈을 그리는 사람은 그 꿈을 닮아간다...
http://mytears.org ~(~_~)~
나 한줄기 바람처럼..
오오~
혹시 SSE3, SSE4 쪽에 대해서 잘아시는 지요 ?
이미지 프로세싱 을 하려는데 이걸쓰면 4배가량 빨라진다고 메뉴얼에 써있지만..
내공이 부족해서인지..어떻게 짤지 감도 안잡힙니다.
도움을 구합니다. 분야은 alpha blending 입니다.
1. 컴파일러(VC8) 에 SSE4 옵션준것과 직접 intrinsic 으로 짜는것과 성능차이가 많은가요?
LISP 사용자모임
http://cafe.naver.com/lisper
방송기술 개발업체
http://playhouseinc.co.kr
스트리밍
스트리밍 인스트럭션을 사용해서 최적화를 해주는 컴파일러는 많지 않습니다. 그런 부분은 어쩔 수 없이 손으로 해야죠.
알파 블렌딩 같은 영역이라면 SSE 보다는 OpenGL 쪽이 훨씬 빠를 지도 모르겠습니다만 MMX/SSE 로도 말씀하신 정도의 속도 향상은 가능할 것으로 보입니다.
알파 블렌딩이라면 a*x1 + (1-a)*x2 정도일텐데 SSE 부터는 부동소숫점 연산 4개 정도는 한꺼번에 해낼 수 있거든요. 자세한건 인텔 메뉴얼을 보세요. -_-;;
뭐 간단하게 코드는 아래와 같은 형식이 되겠네요.
1. 픽셀 값 4개를 읽어옴
2. 읽어온 값을 float 으로 변환
3. 알파값 4개를 읽어옴
4. float 으로 변환한 픽셀값 과 알파값 4개를 한꺼번에 연산
5. 연산된 결과를 unsigned char 로 변환
6. 변환된 값을 메모리에 쓰기
참고로 위에서 번호를 메긴 하나하나는 어셈블리 명령어 하나에 해당됩니다.
--
오랫동안 꿈을 그리는 사람은 그 꿈을 닮아간다...
http://mytears.org ~(~_~)~
나 한줄기 바람처럼..
오랫동안 꿈을 그리는 사람은 그 꿈을 닮아간다...
http://mytears.org ~(~_~)~
나 한줄기 바람처럼..
오오..
간결하지만 길을 보여주시는 답변 감사합니다..
그래서 인텔 메뉴얼을 봤더니.
곱하기 명령어가 문제가 됩니다.
곱하기는 32bit * 32bit -> 64bit 인 명령어만 있더군요..
이 예기는 결국 128bit 레지스터에 결과를 담아야되니.
동시에 처리할수 있는 곱하기는 2개가 한계라는게 아닐까요? 조언좀..
그리고 SSE4부터는 blend 라는 명렬어 자체가 있던데..이거 혹시 써보셨나요?
주절주절 두서없는 질문 죄송합니다.
magingax@gmail.com 으로 답변주시면 감사드릴께요..
LISP 사용자모임
http://cafe.naver.com/lisper
방송기술 개발업체
http://playhouseinc.co.kr
메뉴얼에 그렇게
메뉴얼에 그렇게 써있다면 그런거겠죠. blend 라는 명령어가 생겼으면 메뉴얼을 보고 적용시켜보면 되지 않을까요.
참고로 메뉴얼을 제대로 보셨다면 single precision (32-bit float) 의 곱하기 명령어는 다음과 같습니다. 말씀하신거랑은 다르네요.
그리고 메일주소를 남기시면서, 이 곳으로 답변해주시면 감사드릴께요. 라고 해봐짜 메일로 수고스럽게 답변해주는 사람은 거의 없을겁니다.
--
오랫동안 꿈을 그리는 사람은 그 꿈을 닮아간다...
http://mytears.org ~(~_~)~
나 한줄기 바람처럼..
오랫동안 꿈을 그리는 사람은 그 꿈을 닮아간다...
http://mytears.org ~(~_~)~
나 한줄기 바람처럼..
펌웨어 레벨에
펌웨어 레벨에 가까운 임베디드 환경에서 작업하고 있습니다.
Great Code 1, 2권을 모두 읽었는데 1권보다는 2권을 더 추천하구요,
로우레벨에서 보자면 정말 훌륭한 책 맞습니다. ^^
실무에서 힘들게 배웠던 내용들이 이 책에 그대로 나와있습니다.
읽은지 한참되긴 했지만,
제 입장에서는 신입 사원으로 일 배울 때 읽으면 좀 더 도움이 많이 되는 책이라고 생각해요.
임베디드 외의 업계에서는 생산성 향상을 위해 고급 언어와 추상화만 지향하는 분위기지만
그렇다고 해도 저 아래쪽에서도 무슨 일이 일어나고 있는지 아는 것이
일반 개발자와 고급 개발자의 차이가 아닐까 합니다.
(그렇다고 뭐 제가 고급이란 얘기는 아니고.. 초급이라고 벗어났으면.. ㅠㅠ)
#kill -9 world
그 책을 본것은 아니지만요...
asm 자체보다는 컴퓨터구조 자체를 아는것이 더 좋을것 같습니다만...
(CPU구조의 기본적 이해 및 RISC, super scalar, VLIW 이해랄까요?)
뭐 사실...좀 하위레벨쪽 제외하면 컴파일러의 최적화가 잘 이루어지고 있는 상황이라서...
asm자체는 잘 안쓰게되죠. 물론, 특화된 asm을 inline으로 쓰기는 합니다. (SSE가 가장 큰 예제겠군요.)
------------------------------------------
Let`s Smart Move!!
http://kalstein.tistory.com/
------------------------------------------
Let`s Smart Move!!
http://kalstein.tistory.com/
저도 오프
저도 오프 토픽이지만, 일반적인 x86기반의 PC에서의 개발만 놓고 본다면 크게 필요성 같은 것을 못 느꼈지만,
펌웨어를 위시한 임베디드 분야에서는 어셈블리를 모르고서는 시간을 까먹는 게 되는 경우가 많더군요.
특히 성능 좋은 컴파일러를 쓰다 보면 코드 최적화에 의한 버그를 보게 되는데,
이런 경우에는 코드가 어떻게 변환이 됐는지 어셈블리 코드를 봐야만 문제의 실마리를 찾을 수 있겠지요.
c가 high level assembly라고는 하지만 생성되는 바이너리와 1:1 변환이 아닌이상 assembly 일 수 는 없겠지요.
임베디드라면 디버깅 시간을 줄이기 위해서라도 최소한 assembly 코드에 대한 리딩 능력이 있어야 할 듯 합니다.
높이 날다 떨어지면.
아푸다 ㅡ,.ㅡ
높이 날다 떨어지면.
아푸다 ㅡ,.ㅡ
흐음;
전 무척 괜찮다고 생각하며 봣었는데..
윗분 말씀을 보다보니..
학생에게 적합한 책이라 그런것일지도 잘 모르겠네요.
======================================
솔직함은 배려의 측면에서 보면 양날의 칼이다.
댓글 달기