돌아가기 삭제 이동 파일 올리기

asm.js _{(편집) (2)}

(편집 필터 규칙)

== 상세 ==
앞서 설명했듯 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 서브셋 문법으로 이뤄진 부분을 브라우저의 컴파일러에서 해당 부분을 저레벨로 처리할 수 있도록 컴파일해서 처리함으로서 자바스크립트가 가지는 스크립트 언어로서의 한계를 넘어서 시스템에 저레벨로 접근할 수 있도록 해주는데 주요한 목적이 있다.

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 등의 기능에 의해 수동으로 관리되기 때문이다. 이러한 특성 때문에 자바스크립트 엔진에서 처리해야할 타입 분류나 메모리 관리영역의 부하도 덜어주기 때문에 특히나 부하가 심하게 걸리는 산술연산에서 큰 효과를 얻을 수 있게 된다. 이러한 특성은 부하가 심하게 걸릴 수 밖에 없는 게임 엔진 등의 원활한 이식으로 이미 증명되고 있다.

비로그인 상태입니다. 편집한 내용을 저장하면 지금 접속한 IP가 기록됩니다.

편집을 전송하면 당신은 이 문서의 기여자로서 본인이 작성한 내용이 CC BY 4.0에 따라 배포되고, 기여한 문서의 하이퍼링크나 URL로 저작자 표시가 충분하다는 것에 동의하는 것입니다.