asm.js

asm.js는 어셈블리(assembly) + 자바스크립트(javascript)로 만들어진 합성 명칭으로, 모질라가 주축이되어 개발하고 있는 특정 목적용 자바스크립트 서브셋이다. 이름그대로 저레벨 연산을 위해서 특화된 자바스크립트라는 뜻. 일반적으로 asm.js에서 정의된 서브셋과 실행을 위한 컴파일러를 포함한 브라우저의 환경 전체를 지칭하는 형태로 사용되고 있다.

기본적으로 저레벨의 계산을 고성능으로 처리하기 위해서 만들어졌으며, 독자적인 코드작성보다 C나 Cpp등의 언어에서 작성된 코드를 asm.js 서브셋을 사용한 자바스크립트로 변환해 저레벨 연산을 처리할 수 있게 해준다.

웹브라우저상에서 더 빠른 프로그램을 돌리기 위한 목적을 가지기는 하지만, 방법면에서 ‘자바스크립트를 빠르게 처리하는’ 것과는 다른 형태의 접근이다. 즉 구조적으로 한계가 있는 자바스크립트에 ‘복잡한 연산을 저레벨로 빠르게 연산한다’라는데 목적가진 서브셋을 통해 저레벨에 접근할 수 있는 통로를 만든 것이다. 즉 자바스크립트 자체가 빨라지는 것이 아니라 저레벨의 고성능 처리가 필요한 프로그램을 자바스크립트로 전달하는데 필요한 기능이다. 이러한 형태의 처리를 위해 구글에서 만들고 있는 크롬용 바이너리 실행기인 구글 네이티브 클라이언트와 플랫폼 독립구조인 구글 PNaCl과 목적면에서는 닮아있으나 구현방향이 크게 다른 프로젝트라고 할 수 있다.

여러번의 비공식 버전에서의 지원을 거쳐 파이어폭스 브라우저 버전 22를 시작으로 공식 지원이 시작되었으며, 크롬 브라우저에서는 버전28부터 지원을 시작했다.(당연한 이야기지만 같은 블링크 엔진을 쓰는 오페라 브라우저도 지원 중)

대표적으로 언리얼 엔진과 유니티 엔진이 asm.js 프로젝트로 포팅되어 지원하고 있다. 그외에도 QT등의 프레임웍도 이식되면서 앞으로의 전망이 꽤 밝다고 할 수 있다.

아직까지 모든 스펙이 정해진 상태는 아니며 계속 수정이 이뤄지는 초안(Draft) 상태로 진행중이다.

앞서 설명했듯 asm.js 자체는 자바스크립트 언어의 서브셋을 가리키는 것으로, asm.js 서브셋 문법으로 이뤄진 부분을 브라우저의 컴파일러에서 해당 부분을 저레벨로 처리할 수 있도록 컴파일해서 처리함으로서 자바스크립트가 가지는 스크립트 언어로서의 한계를 넘어서 시스템에 저레벨로 접근할 수 있도록 해주는데 주요한 목적이 있다.

asm.js 자체는 새로운 자바스크립트 엔진도 아니고 독자적 VM환경도 아니다. 이 점은 매우 중요한데, 일반적으로 사용되는 표준 웹브라우저에서 모두 실행시킬 수 있는 범용성을 가지고 있기 때문이다. 때문에 경쟁상대로 종종 언급되는 구글 PNaCl과는 일단 적용 플랫폼 범주부터 다르다. 파이어폭스 브라우저의 경우에는 asm.js를 빠르게 처리하기 위해 ‘오딘몽키(OdinMonkey)‘라는 자바스크립트 엔진에 부속된 최적화 모듈을 가지고 있으나 이것은 어디까지나 최적화를 위한 모듈일 뿐이라 이것을 거치지 않아도 실행에는 아무 지장이 없다.

asm.js 코드 자체는 사람이 알아볼 수 있는 형태이지만, 해당 코드를 직접 작성하기보다는 C나 Cpp를 비롯한 여타 언어로 만들어진 네이티브 언어용 코드를 asm.js코드로 변환시키는 것을 주요 목적으로 개발되고 있다. 굳이 바이트코드 등의 중간언어가 아닌 자바스크립트로 변환시키는 것은 사람들이 읽을 수 있는 코드로 제공되는 것이 웹 플랫폼의 주요한 메리트이기 때문이다.

네이티브 프로그램 작성에 많이 사용되는 C나 Cpp를 자바스크립트로 변환시켜주는 Emscripten이나 Mandreel 등의 프로젝트가 중간에서 번역가 역할을 하고 있다. 엠스크립튼은 LLVM의 자바스크립트 백엔드인데, 잠시 LLVM 구조를 살펴보자면, LLVM은 프론트엔드 단에서 C나 Cpp, 오브젝티브C 등의 소스코드를 컴파일해 중간언어인 LLVM IR로 변환을 한다. 이를 다시 타겟 플랫폼에 맞춰 백엔드 단에서 링킹과정을 거쳐 바이너리가 생성되게 되는데, 이 백엔드 단에서 자바스크립트로 변환을 해주는 것이 Emscripten이다.

여기서 알아둬야 할 점은 asm.js 프로젝트는 독자적으로 발생했다기 보다는 엠스크립튼이나 맨드릴 같은 프로그램이 만들어내는 결과물을 더 효율적으로 빠르게 처리하기 위한 방법론으로 등장한 것이다. 엠스크립튼이나 맨드릴 등의 프로그램은 asm.js가 나오기 전에도 존재했으며, 초기에는 독자적인 자바스크립트를 생성했다. 즉 백엔드인 엠스크립튼에서 코드를 자바스크립트로 변환하는 것 자체는 asm.js자체와는 상관이 없다는 이야기다. 엠스크립튼이나 맨드릴과 같은 프로젝트를 통해 나온 결과물 자바스크립트 파일을 처리하는데 공통적으로 사용되는 요소들을 걸러내고, 추려내 특화함으로서 산술연산 등의 부하가 많이 걸리는 연산을 asm.js 서브셋 코드로 변환함으로서 각종 사전처리 등의 부가적 접근을 통해 성능적 개선을 추구하고 있는 것이다.

그러한 태생적 특성 때문에 asm.js는 기본적으로 수식처리 등 산술처리 기능에 특화되어있으며, 자바스크립트 엔진에서 asm.js를 위한 독자적 가속 기능을 지원하지 않아도 실행 자체에는 문제가 없다.

Emscripten 등을 거쳐서 생성된 자바스크립트 코드는 사용자가 실행할 때 웹브라우저의 자바스크립트 엔진에서 해석에 들어가게 되는데, 최근 자바스크립트 엔진의 특성에 따라 JIT 컴파일방식으로 컴파일이 이뤄지는데, 이 과정에서 ‘use asm’으로 명시된 항목의 경우 asm.js에서 처리해야할 코드로 분류되어 사전처리(Ahead Of Time, AOT)방식을 사용해 컴파일을 하며(즉 인터프리터 방식이 아닌, 실행되기 전에 컴파일된다), 그 과정에서 추상 구문 트리(AST)에서 타입을 확인해 asm.js가 처리할 코드가 맞는지 걸러내고, 링킹 과정에서 다시한번 체크를 해서 자신이 실행할 내용을 엄격하게 추려낸다.

asm.js에서 사용하는 코드는 저레벨 처리를 위한 목적을 가지기 때문에 엄격한(strict) 유효성 검사를 거치게 되어있다. 그렇다고 유효성 검사를 통과하지 못한 코드가 에러를 뱉고 죽어버리는 것은 아니고, 단지 저레벨로 컴파일되지 않고 통상의 자바스크립트 인터프리터를 통해 실행되므로 코드 자체에 문제가 없다면 실행 자체에는 문제가 생기지는 않는다.(단지 속도 차이가 있을 뿐)

여기서 사전처리(AOT) 컴파일을 통해 실행되는 코드는 가비지 컬렉터가 불필요해진다. 해당 코드가 사용하는 메모리는 컴파일 단계에서 규정된 타입이며, malloc과 free 등의 기능에 의해 수동으로 관리되기 때문이다. 이러한 특성 때문에 자바스크립트 엔진에서 처리해야할 타입 분류나 메모리 관리영역의 부하도 덜어주기 때문에 특히나 부하가 심하게 걸리는 산술연산에서 큰 효과를 얻을 수 있게 된다. 이러한 특성은 부하가 심하게 걸릴 수 밖에 없는 게임 엔진 등의 원활한 이식으로 이미 증명되고 있다.

위에서 입이 닳도록 설명했지만 다시 설명하자면, 아래 어플리케이션들은 ‘asm.js’를 쓰는 어플이 아니라 엠스크립튼 같은 프로그램으로 자바스크립트로 포팅을 한 버전이라고 보는게 맞다. 그 결과물이 asm.js를 쓰도록 포팅되고 있는 것. 때문에 검색하려면 ‘emscripten’ 등과 함께 검색하는 편이 검색 결과가 잘 나온다.

참고로 게임 엔진이나 QT의 경우는 실행에 꽤 부하가 걸리는 편이므로 탭 여러개 열고 작업하던 내용이 있다면 창 열어서 실행시켜보기 전에 저장을 해두도록 하자. 자칫 하다가는 브라우저가 뻗어서 자료를 전부 날리는 경우가 생길 수도 있다.

Qt : KDE나 QTOPIA 등에 사용되는 프레임웍. KATE 등의 QT기반 어플리케이션이 이미 포팅되어 데모를 선보이고 있다.