일반 JavaScript를 asm.js로 변환 할 수 있습니까? 아니면 정적으로 유형이 지정된 저수준 언어의 속도를 높이기위한 것입니까?

일반 JavaScript를 asm.js로 변환 할 수 있습니까? 아니면 정적으로 유형이 지정된 저수준 언어의 속도를 높이기위한 것입니까?

---

asm.js로 테스트하고 개발하는 방법에 대한 질문 을 읽었습니다. , 허용되는 답변은 http://kripken.github.com/mloc_emscripten_talk/#/ 링크를 제공합니다 .

슬라이드 쇼의 결론은 " 정적으로 형식화 된 언어, 특히 C / C ++는 JavaScript로 효과적으로 컴파일 될 수 있습니다." 따라서 컴파일 된 C / C ++의 속도가 네이티브 코드보다 2 배 더 느리거나 더 나을 것으로 기대할 수 있습니다. , 올해 말 ".

그러나 일반 JavaScript 자체와 같이 비 정적으로 형식화 된 언어는 어떻습니까? asm.js로 컴파일 할 수 있습니까?

---

JavaScript 자체를 asm.js로 컴파일 할 수 있습니까?

그 동적 특성 때문에 실제로는 아닙니다. C 또는 네이티브 코드 로 컴파일 할 때와 동일한 문제입니다. 실제로 이러한 비 정적 측면을 처리하려면 VM과 함께 VM을 제공해야합니다. 최소한 다음과 같은 VM이 가능합니다.

js.js 는 JavaScript의 JavaScript 인터프리터입니다. 처음부터 인터프리터를 생성하는 대신 SpiderMonkey 는 LLVM 으로 컴파일 된 다음 emscripten 이 출력을 JavaScript로 변환합니다.

그러나 asmjs 코드가 일반 JS보다 빠르게 실행되면 JS를 asmjs로 컴파일하는 것이 합리적입니다.

아니요. asm.js 는 바이트 코드로 쉽게 변환 할 수있는 매우 제한된 JS 하위 집합입니다. 그러나이 이점을 얻으려면 먼저 JS의 모든 고급 기능을 해당 하위 집합으로 분해해야합니다. 매우 복잡한 작업입니다. 그러나 JavaScript 엔진은 이러한 모든 고급 기능을 직접 바이트 코드 로 변환하도록 설계 및 최적화되었습니다. 그렇다면 asm.js와 같은 중간 단계에 신경 쓰는 이유는 무엇입니까? Js.js는 "네이티브"JS보다 약 200 배 느리다고 주장합니다.

일반적으로 비 정적 유형 언어는 어떻습니까?

슬라이드 쇼는 … C / C ++ 만? 앞으로. 구체적으로 특별히:

동적 언어

전체 C / C ++ 런타임을 컴파일하고 원래 언어를 적절한 의미 체계로 해석 할 수 있지만 이것은 경량이 아닙니다.

이러한 언어에서 JavaScript 로의 소스-소스 컴파일러는 의미 적 차이 (예 : 숫자 유형)를 무시합니다.

실제로 이러한 언어는 효율성을 위해 특수 VM에 의존합니다.

이들을위한 소스-소스 컴파일러는 해당 VM에서 수행 된 최적화에 실패합니다.

---

일반적인 질문에 대한 응답으로 "가능합니까?" 그렇다면 대답은 JavaScript와 asm.js 하위 집합 모두 Turing이 완료되어 번역이 존재한다는 것입니다.

이를 수행하고 성능상의 이점을 기대해야하는지 여부는 다른 질문입니다. 짧은 대답은 "아니오,해서는 안됩니다."입니다. 나는 이것을 압축 파일을 압축하는 것과 비슷합니다. 예, 압축 알고리즘을 실행할 수 있지만 일반적으로 결과 파일이 더 작을 것으로 예상해서는 안됩니다.

짧은 대답 : 동적 형식 언어의 성능 비용은 코드의 의미에서 비롯됩니다. 동일한 의미를 가진 정적으로 유형이 지정된 프로그램은 동일한 비용을 부담합니다.

이를 이해하려면 asm.js가 성능상의 이점을 제공하는 이유 를 이해하는 것이 중요 합니다. 또는보다 일반적으로 정적 유형 언어가 동적 유형 언어보다 더 나은 성능을 발휘하는 이유. 짧은 대답은 "런타임 유형 검사에 시간이 걸립니다"이며 더 긴 대답에는 정적으로 유형이 지정된 코드를 최적화 할 수있는 개선 된 가능성이 포함됩니다. 예를 들면 :

function a(x) { return x + 1; }
function b(x) { return x - 1; }
function c(x, y) { return a(x) + b(y); }

x와 y둘 다 정수로 알려진 경우 c몇 가지 기계어 코드 명령으로 기능 을 최적화 할 수 있습니다 . 정수 나 문자열이 될 수 있다면 최적화 문제는 훨씬 더 어려워집니다. 나는 이것을 어떤 경우에는 문자열 추가로 취급하고 다른 경우에는 추가로 처리해야합니다. 특히에서 발생하는 덧셈 연산에 대해 네 가지 가능한 해석이 있습니다 c. 추가, 문자열 추가 또는 두 가지 다른 변형의 문자열 및 추가 강제 변환이 될 수 있습니다. 가능한 유형을 더 추가하면 가능한 순열 수가 증가합니다. 동적 유형 언어의 최악의 경우에는 각각 k 개를 가질 수있는 n 개 용어를 포함하는 표현식에 대해 k ^ n 개의 가능한 해석이 있습니다.유형. 정적으로 유형이 지정된 언어에서 k = 1이므로 주어진 표현식에 대해 항상 1 개의 해석이 있습니다. 이 때문에 최적화 프로그램은 동적으로 입력 된 코드보다 정적으로 입력 된 코드를 최적화하는 데 근본적으로 더 효율적입니다. 최적화 기회를 검색 할 때 고려해야 할 순열이 적습니다.

여기서 요점은 동적으로 입력 된 코드에서 정적으로 입력 된 코드로 변환 할 때 (JavaScript에서 asm.js로 이동할 때처럼) 원래 코드의 의미를 고려해야한다는 것입니다. 유형 검사가 여전히 발생하고 (지금은 정적으로 유형이 지정된 코드로 철자가 지정됨) 이러한 모든 순열이 컴파일러를 방해하기 위해 여전히 존재 함을 의미합니다.

---

개념을 명확하게하는 asm.js 에 대한 몇 가지 사실 :

1. 예 , 손으로 asm.js 방언을 작성할 수 있습니다 .

   당신의 예제를보고 한 경우 asm.js , 그들은 아주 멀리있는 별에서 사용자 친화적 . 분명히 Javascript는이 코드를 만드는 데 사용되는 프런트 엔드 언어가 아닙니다.

2. 바닐라 자바 ​​스크립트를 asm.js 방언으로 번역하는 것은 불가능 합니다.

   생각해보십시오. 이미 표준 자바 스크립트를 완전히 정적으로 번역 할 수 있다면 asm.js 가 필요한 이유는 무엇입니까? asm.js 의 유일한 존재는 Javascript JIT 사람들이 개발자의 노력없이 Javascript가 더 빨라질 것이라는 약속을 포기 했음을 의미합니다.

   여기에는 몇 가지 이유가 있지만 JIT가 정적 컴파일러만큼 좋은 동적 언어를 이해하는 것은 정말 어려울 것이라고 가정 해 보겠습니다 . 그리고 아마도 개발자가 JIT를 완전히 이해해야 할 것입니다.

결국 작업에 적합한 도구를 사용하는 것으로 귀결됩니다. 정적이고 성능이 뛰어난 코드를 원한다면 C / C ++ (/ Java )를 사용하십시오. 동적 언어를 원한다면 Javascript , Python , ...

---

asm.js는 쉽게 최적화 할 수있는 자바 스크립트의 작은 부분 집합이 필요하여 만들어졌습니다. javascript를 javascript / asm.js로 변환하는 방법이 있다면 asm.js는 더 이상 필요하지 않습니다.이 방법은 js 인터프리터에 직접 삽입 할 수 있습니다.

---

이론적으로 asm.js에있는 언어의 제한된 하위 집합으로 표현할 수있는 경우 모든 JavaScript 작업을 asm.js로 변환 / 컴파일 / 트랜스 파일 할 수 있습니다. 그러나 실제로는 현재 일반 JavaScript를 asm.js로 변환 할 수있는 도구가 없습니다 (2017 년 6 월).

어느 쪽이든 정적 타이핑 을 사용 하는 언어 를 asm.js 로 변환하는 것이 더 합리적입니다 . 왜냐하면 정적 타이핑은 asm.js의 요구 사항이고 asm으로 컴파일하기 매우 어렵게 만드는 일반 JavaScript의 기능 중 하나가 없기 때문입니다. .js.

2013 년 asm.js가 뜨거웠을 때 JavaScript와 유사한 정적으로 형식화 된 언어 를 컴파일 하려는 시도가 있었지만 언어와 컴파일러는 모두 포기 된 것 같습니다.

현재 2017 년에는 JavaScipt 하위 집합 TypeScript 및 Flow 가 asm.js 로의 변환에 적합한 후보가 될 수 있지만 두 언어 모두의 핵심 개발 팀은 이러한 변환에 관심이 있습니다. LLJS 에는 asm.js로 컴파일 할 수있는 포크가 있었지만 그 프로젝트는 거의 죽었습니다. ThinScript 는 훨씬 더 최근의 시도이며 TypeScript를 기반으로하지만 활성화되지 않은 것 같습니다.

So, the best and easiest way to produce asm.js code is still to write your code in C/C++ and convert / compile / transpile it. However, it remains to be seen whether we'll even want to do this in the forseeable future. Web Assembly may soon replace asm.js altogether and there's already popping up TypeScript-like languages like TurboScript and AssemblyScript that convert to Web Assembly. In fact, TurboScript was originally based on ThinScript and used to compile to asm.js, but they appear to have abandoned this feature.

---

check this http://badassjs.com/post/43420901994/asm-js-a-low-level-highly-optimizable-subset-of

basically you need check that your code would be asm.js compatible (no coercion or type casting, you need to manage the memory, etc). The idea behind this is write your code in javascript, detect the bottle neck and do the changes in your code for use asm.js and aot compilation instead jit and dynamic compilation...is a bit PITA but you can still use javascript or other languages like c++ or better..in a near future, lljs.....

---

It may be possible to convert regular JavaScript into ams.js by first compiling it into C or C++, and then compiling the generated code into asm.js using Emscripten. I'm not sure if this would be practical, but it's an interesting concept nonetheless.

More recently, I found another tool called NectarJS that compiles JavaScript into WebAssembly and ASM.js.

참고URL : https://stackoverflow.com/questions/15626611/can-regular-javascript-be-converted-to-asm-js-or-is-it-only-to-speed-up-statica