새로운 GNU binutil linker
ELF 포맷에 대해서만 제대로 링크하고, 아직 beta 수준의 성숙도를 보이고 있다는(적어도 저자가 메일링리스트에 쓴 정보로는) 링커가 등장했다.
빌드 과정은 크게 전처리 ((C/C++ preprocessor 를 말하는게 아니라 코드 생성기의 자동 생성, 리소스 묶기, 설정 파일과 코드의 결합 등등 컴파일 전에 처리해야할 일련의 작업)) , 컴파일, 링킹의 3단계로 이루어진다. (물론 이 뒤에 테스트, 코드 검사, 배치 등등이 있지만) 전처리는 원래 큰 시간이 걸리지 않는 경우가 대부분이거나, 자주하지 않아도 되는 경우가 많다(적어도 개발 주기 동안에는). 그리고 CPU를 많이쓰게되는 컴파일 작업의 경우에도 incredibuild나 distcc 같은 분산컴파일러들의 개발로 어느 정도 견딜만한 수준으로 내려갔다.
그렇지만 마지막 남은 링커의 문제 — 대규모 소프트웨어일수록 링커에서 걸리는 시간이 길어지고, 거의 직렬연산이라 최적화의 여지도 적다라는 것. Incremental linking같은 최적화 방법도 존재하지만, 얘도 가끔 문제를 일으키고, release code에서 쓰기엔 좀 불안하다는 거.
이런 문제에 대한 해결책으로 구글에서 OpenSource community에 이번에 제공한 것이 내부적으로 어느 정도 써봤다는 새 링커 gold다. 대형 C++ 프로젝트에서 5배 가까운 성능 향상을 보았다고하며, 자료 구조의 변경/병렬화로 성능 향상을 이뤘다고 한다.
C/C++ 프로그램을 “만들어내는데” 있어서 현재의 병목인 링킹문제가 좀 해결되서 좀더 빠른 빌드를 볼 수 있었으면 한다. 링킹 시간은 너무 길다 Orz.
ActionScript의 악몽
ActionScript 2.0에는 Array 타입 하나로 일반적인 vector와 map의 기능을 수행한다. 근데 이걸 associaive array로 사용하는 경우 아주아주 끔찍한 문제가 있다.
전체 배열에 들어있는 원소 수를 알 수 없다.
-_-
이런 문제로 Flex3/ActionScript 3.0에는 dictionary란 자료구조가 추가되긴 했지만, 이 말인즉슨. 2.0 이전에는 제대로 된 자료구조도 제공하지 않는 언어라는 것. 현대 언어에서라면 당연히 제공해야하는 두 가지 기본 자료구조 — vector, map — 이 엉성한 상태인 것. 덕분에 삽질 좀 했다. flash 덤벼 -_-
ps. Flex 를 쓰게되면 2.0대는 쳐다보지도 말자.
binutils 메일링 리스트도… 구독하냐 ㄷㄷ ;;
구독은 아니고 선거일 오후에 봤는데 출처를 모르겠음 -_-;;
binutil은 요즘 관심이(생길수) 없는 상태에요; Win32만 만지고있으니 ㅠㅠ
for (var i in arr) ++count;
[퍽]
병렬 링킹이라.. 상당히 맛있어 보이는군요[?]
회사에서 incredibuild 를 쓰고 있는데 링킹이 견딜 수 없이 오래 걸리더라구요 ㅜㅜ
dasony / 그렇게 하고 있음. 근데 그렇게 구해야하는거라 구현되었다고 하기가 참 -_-
비오 / …여기 생짜로 컴파일부터 하는 사람이 있다
저도 요즘 수업 듣는 게 있어서(디자인학부 전공 미디어프로그래밍)
쓰고 있는데 액션스크립트은 애니메이션 액션을 위한
간단한 스크립트 정도로만 생각하는 게 마음이 편하더군요.
많은 걸 바라면 안 됨 ㅜㅜ
Flex3는 좀 다르다는 얘기도 있던데(dasony도 그렇고 포럼 쪽 글들도 그렇고), ActionScript 2.0은 GG 다;