Design: JS -> WASM 컴파일러가 있습니까?

브라우저에는 wasm과 함께 기본 JavaScript VM이 계속 있습니다. 전체 javascript vm도 포함해야 하므로 JS를 wasm으로 컴파일할 이유가 없습니다. 결과 코드는 기본적으로 제공되는 JS VM보다 거대하고 느립니다.

wasm에 대한 스크립팅 언어가 구현될 수 있도록 wasm 코드에서 GC에 대한 액세스를 추가하는 것과 같은 작업을 추가하기 위한 작업 포스트 MVP가 있습니다.

JS → wasm은 wasm이 GC를 지원하고 JIT 컴파일도 지원해야 실제로 의미가 있습니다. 이것은 기본적으로 wasm에서 JS 엔진을 구현하는 것과 같습니다! 나는 최근에 이것을 @BrendanEich 는 나를

분명히 말해서, wasm의 목표는 JavaScript를 _교체_하는 것이 아니라 보완하는 것입니다. 따라서 JS → wasm을 지원하는 것이 현재 목표는 아니지만 구현하려는 기능이 이를 가능하게 할 것입니다. 그러나 개발자의 관점에서 그것이 그렇게 유용할지 확신할 수 없습니다. 크기를 줄일 수는 있지만 그게 전부입니다. 브라우저의 관점에서 보면 순수한 보안 관점에서 wasm에 JS 엔진을 구현하는 것이 흥미로울 수 있습니다.

@jfbastien 2초

그러나 당신의 대답이 더 좋습니다. 나는 wasm의 GC와 JIT에 대해 기대하고 있습니다. 나는 내 자신의 언어를 만들고 웹에서 실행하는 것을 좋아합니다.

asm.js 또는 TypeScript/ES7과 같은 변형을 지원하는 것은 어떻습니까? 이것들
Javascript의 특징은 어느 정도의 유형 보장을 약속합니다.

JIT에 대한 필요성은 덜하지만 GC는 여전히 많이 필요하다고 생각합니다.
이러한 언어에 필요합니다. {typed flavor JS} -> WASM 만들기
이것이 더 이상 가능합니까?

여: http://bguiz.com

2015년 6월 24일 09:44에 Tim Caswell [email protected] 은 다음과 같이 썼습니다.

@jfbastien https://github.com/jfbastien 2초 차로 저를 이겼습니다 :P

—
이 이메일에 직접 답장하거나 GitHub에서 확인하세요.
https://github.com/WebAssembly/design/issues/219#issuecomment -114675456.

예, asm.js -> wasm 번역기가 최우선 순위이며 Luke는 이미
좋은 출발점으로 작용할 수 있는 압축기에서 작업하십시오.

2015년 6월 24일 수요일 오전 1시 59분, Brendan Graetz [email protected]
썼다:

asm.js 또는 TypeScript/ES7과 같은 변형을 지원하는 것은 어떻습니까? 이것들
Javascript의 특징은 어느 정도의 유형 보장을 약속합니다.

JIT에 대한 필요성은 덜하지만 GC는 여전히 많이 필요하다고 생각합니다.
이러한 언어에 필요합니다. {typed flavor JS} -> WASM 만들기
이것이 더 이상 가능합니까?

여: http://bguiz.com

2015년 6월 24일 09:44에 Tim Caswell [email protected] 은 다음과 같이 썼습니다.

@jfbastien https://github.com/jfbastien 2초 차로 저를 이겼습니다 :P

—
이 이메일에 직접 답장하거나 GitHub에서 확인하세요.
< https://github.com/WebAssembly/design/issues/219#issuecomment -114675456
.

—
이 이메일에 직접 답장하거나 GitHub에서 확인하세요.
https://github.com/WebAssembly/design/issues/219#issuecomment -114677789.

우리는 TypeScript 팀과 이 가능성에 대해 이야기했으며 그들은 관심을 보였습니다. 그러나 현재 JS에 유형이 지정된 개체를 추가하는 데 진전이 있는 것 같습니다.

@bguiz : JS 엔진은 wasm 엔진이며 진화하는 JS 표준 언어를 계속 지원할 것입니다. 걱정하지 마세요. 다른 사람들이 언급했듯이 OTOH는 wasm이 GC, JIT 지원 및 기타 동적 언어 기능을 발전시켜 JS의 일급 대상이 되기까지 시간이 필요합니다. 이러한 것들이 진화하더라도 JS/wasm 엔진이 다운로드한 JS-in-wasm VM을 위해 JS 구문과 내장 기능을 버릴지 의심스럽습니다. 우리는 보게 될 것이다!

/이다

asm.js-to-WebAssembly 변환기도 Emscripten 에 추가

일반 JS의 경우 다른 사람들이 위의 질문에 답변했다고 생각합니다.

JS의 요점은 dhteumeuleu 또는 codepen.io/ge1doot와 같이 코딩하기 쉽고 놀라운 일을 할 수 있지만 소스를 볼 수 있고 해킹하기 쉽습니다.

"wasm"은 google, apple co.에서 더 많은 게임 및 기타 앱을 판매하는 유일한 방법입니다. 유일한 "진화"는 빅 브라더 서버에서 직접 "설치 없음"으로 더 잘 제어할 수 있다는 것입니다... 나는 그들이 아직 서로를 먹는 것을 두려워하지 않는다는 것에 놀랐습니다...

코드 분석 또는 코드 주석을 사용하여 ECMAScript를 WebAssembly로 컴파일하는 것이 가능합니다. 이것은 WebAssembly 팀의 우선 순위처럼 들리지 않지만 독립적인 노력을 위한 훌륭한 아이디어처럼 들립니다.

나는 관련이 있을 수 있는 장난감 프로그래밍 언어로 실험을 시작했습니다: https://github.com/evanw/thinscript. TypeScript 스타일 구문을 사용하고 WebAssembly로 컴파일합니다. 흥미로운 사례 연구일 수 있기 때문에 언급해야 한다고 생각했습니다. 또한 WebAssembly가 생성하기가 얼마나 쉬운지 즐겁게 놀랐습니다. 모두들 잘했어!

나는 일반적으로 wasm 위에 매우 얇은 래퍼를 사용하는 것에 대해 사람들에게 경고합니다. 한 예로, 씬스크립트 코드를 살펴보니 while 문이 loop { if (!condition) break; } 낮아져 여러 wasm 엔진에서 if (condition) loop { ...; br_if condition } 보다 덜 효율적임을 알 수 있습니다.

나에게 wasm을 재가열된 JS 이상으로 만드는 것은 다른 철학의 가능성입니다. wasm은 컴파일러 대상이기 때문에 컴파일러는 코드를 클라이언트에 제공하기 전에 최적화를 수행할 수 있으므로 클라이언트 측 VM을 더 간단하게 유지하고 더 빠르게. 그러나 was 주위의 얇은 래퍼가 대중화되면 수행되지 않은 최적화를 수행하기 위해 클라이언트 측 구현이 결국 더 커지고 복잡해져야 할 위험이 있습니다.

그래, 난 동의. WebAssembly에서 내가 가장 좋아하는 것 중 하나는 단순성입니다. 언어가 더 완성되면 컴파일러 최적화를 추가하고 벤치마크를 수행할 계획입니다. 예를 들어 인라인이 더 큰 승리 중 하나가 될 것으로 예상하며 WebAssembly가 나를 위해 그렇게 할 것이라고 기대하지 않습니다. 또한 기계어 코드 대상으로 실험할 계획이며 두 대상 모두에 대해 동일한 최적화를 사용할 것입니다.

아주 멋진 소리! 나는 그것이 어디로 이어지는지 관심을 가질 것입니다.

저는 JS->WASM이 클라이언트보다 서버에 더 매력적이라고 ​​상상하고 있습니다. 내가 염두에 두고 있는 아키텍처에 대한 매우 높은 수준의 개요로서...

JavaScript -> WebAssembly -> Tracing Interpreter -> LLVM IR -> Machine Code

이 개념에서 가비지 수집을 위해 WASM에서

약간의 생각, 이것이 거짓이라면 자유롭게 삭제하십시오!

크로스 환경 호환성은 JS 생태계에서 심각한 문제입니다. Babel은 좀 더 채택된 버전의 ES로 변환하여 이 문제를 해결하려고 하며 우리 모두는 그것이 꽤 성공적이라고 말할 수 있을 것 같습니다.

그래도 여기에는 여전히 문제가 있습니다. 예를 들어 호환성을 위해 ES 2016 코드를 ES5로 변환하고 코드가 ES 2016을 (부분적으로 또는 완전히) 지원하는 환경에서 실행되는 경우 해당 환경에서 ES 2016을 지원하는 이점을 놓치게 됩니다. .

모든 사람이 자신의 코드를 ES5로 변환하는 경우 우선 환경에서 ES 2016을 지원하면 어떤 이점이 있습니까?

"babel-preset-env"라는 새 프로젝트는 버전별로 환경을 대상으로 지정하여 이 문제를 해결하려고 합니다. 그 이면의 아이디어는 (1) 브라우저의 특정 버전 또는 "최신 X 버전"을 대상으로 하도록 요청하고, (2) 기능의 가장 낮은 공통 분모를 결정하고, (3) 필요한 변환만 활성화한다는 것입니다. 이것은 도움이 되지만 슬프게도 문제를 해결할 수 없습니다.

우리는 여전히 주요 공급업체가 작동하지 않고 Microsoft가 수년 동안 Internet Explorer에서 일으킨 동일한 문제를 일으킬 위험이 있습니다. 전체 생태계는 구현 대상과 구현 시기를 결정하는 몇몇 공급업체의 손에 달려 있습니다. 이것은 자유롭지도 개방적이지도 않습니다.

유일한 솔루션은 성능이 뛰어나고 JS 엔진보다 훨씬 적은 유지 관리(원하는 것은 없음)가 필요한 JavaScript용 새로운 컴파일 대상입니다. 환경(브라우저, Node.js 등)이 이러한 대상을 지원하기 시작하면 새로운 ES 기능을 구현하는 것은 엔진 공급업체가 아니라 컴파일러의 책임이 되어야 합니다.

JS -> WASM은 고객 서버에 Electron 앱을 사내 설치하는 경우 코드 난독화로 지적 재산을 보호하는 데 흥미로울 것입니다. 믿기 ​​어렵지만 사실입니다. 독일에는 인터넷 연결이 거의 또는 전혀 되지 않는 소규모 기관이 많이 있어 사내 설치가 필요하지만 전체 코드를 일반 텍스트로 제공하는 것은 소프트웨어 회사에 끔찍할 수 있습니다.

@Simran-B Wasm은 친숙한 텍스트 형식을 지원하는 디자인 원칙을 가지고 있습니다. 특히 빠른 분석을 위한 구조화된 제어 흐름 설계가 있으며 스택 순서로 사용되는 일회용 정의에 최적화되어 있으므로 가독성 있는 표현식에 최적화되어 있습니다. 따라서 '코드 난독화' 대상이 아니지만 개발자는 이 위에 자체 '코드 난독화'를 내보낼 수 있지만 인코딩 효율성 감소 및 성능 저하 측면에서 비용이 예상된다는 점을 이해해야 합니다.

안녕하세요, 방금 WebAssembly를 발견했지만 JS -> wasm 컴파일러에 대해 생각하면서 Angular2의 Ahead-of-Time 컴파일과 같은 것을 상상했습니다. 가능한 적이 있습니까? 그만한 가치가 있습니까?

편집하다
또한 브라우저가 wasm을 지원하는 플래그를 클라이언트에 보낼 수 있는 가능성이 있다고 생각합니다. 그러면 자바스크립트 파일 대신 미리 컴파일된 앱을 제공할 수 있습니까?

리차드

@Richard87 웹어셈블리 는 자체적으로 특수화된 인코딩 및 호출 규칙을 사용하는 플랫폼 독립적인 명령어 세트로 생각할 수 있습니다. 웹 어셈블리의 세계에서 작업하기 위해 매우 쉽게 변환할 수 있는 자바스크립트의 하위 집합을 설명할 수 없다는 말은 없지만 이를 적용하는 것은 아마도 어려울 것입니다. 기능 세트와 구현 표면적은 자바스크립트에서 영원히 증가하고 있으며, 특히 현재 웹어셈블리에 가비지 수집이 없다는 점을 감안할 때 해당 하위 집합에서 작동하도록 기존 라이브러리와 프레임워크를 적용하는 것은 어려울 수 있으며 기본적으로 기존 자바스크립트의 이점을 잃게 됩니다. 암호.

웹 어셈블리에 가비지 수집 프리미티브를 추가하면 큰 가상 머신을 작성하지 않고 트랜스파일할 수 있는 자바스크립트의 하위 집합이 확장되지만 내 생각에는 여전히 더 적합한 언어를 사용하면 자바스크립트의 오버헤드가 약간만 줄어들기 때문에 웹 애플리케이션(네트워크!)의 중요한 오버헤드가 확대되고 처음부터 자바스크립트를 사용하여 얻고자 하는 이점은 여전히 ​​도달할 수 없습니다. "자바스크립트"와 유사한 것을 사용한다고 말하는 것 외에도(이것은 실제로 Unity가 UnityScript와 함께 있는 유사한 보트입니다. 단, 다른 변덕 외에 일반적으로 하위 시스템 및 호출 규칙과 더 잘 통합되도록 조정했다는 점을 제외하면).

브라우저와 Webgl을 보고 있는 우리 중 일부는 게임을 더 빠르게 하는 것이 매우 중요하다고 생각합니다. 나는 webgl에서 상업적 품질의 게임을 가져오려고 하지만 현재 기술은 프레임이 건너뛰는 쓰레기를 너무 많이 생성합니다.
JS 게임 엔진을 사용한 브라우저 게임은 거의 실패했고 Unity가 이륙했습니다. 내 생각에 C++ => Wasm은 코드를 WASM으로 크로스 컴파일할 수 있는 프레임워크 제작자와 같은 이러한 큰 Unity에게 과도한 이점입니다.
그러나 Three JS 또는 Babylon을 사용하여 손으로 JS를 작성하는 사람들은 어떻습니까? JS/Asm.js => Wasm 도구 체인이 없다는 것은 Js의 대규모 애플리케이션이 죽고 사람들이 Wasm을 생성하기 위해 C++ 및 코드 생성 백엔드를 사용한다는 것을 의미합니다. 더 구체적으로 게임 등에서.
JS => JS 개발자에게 불공평한 Wasm 백엔드가 없습니다. 또한 EMCC는 실행 시 큰 힙을 할당하고 이로 인해 속도가 분명하지만 좋은 js 코드를 작성하는 Js 개발자는 이러한 코드 작성의 복잡성으로 인해 여전히 많은 성능을 달성하지 못했습니다. 대부분의 것을 재사용할 수 있는 메커니즘과 gc를 더 일찍 또는 마음대로 호출할 수 있는 기능이 있어야 합니다. GC가 실행될 때 프레임 건너뛰기는 Webgl이 프레임을 건너뛰게 하는 큰 문제이며 해결해야 합니다. 코드 생성기보다 JS 코드를 더 잘 조정할 수 있는 메커니즘이 있어야 합니다. 손으로 작성한 Assembly와 마찬가지로 여전히 훨씬 작고 고도로 정렬된 코드를 생성합니다. 그것은 웹 어셈블리에서 가능해야합니다.

@metacritical C++는 많은 사람들이 프로세스에 많은 작업을 투입하기 때문에 WASM으로 컴파일할 수 있습니다. JavaScript에서도 같은 일이 일어날 수 있지만 내가 아는 한 현재 아무도 이것을 시도하지 않습니다. 그렇게 할 이유는 거의 없습니다. 성능은 변경되지 않습니다.

엔진의 문제는 가비지 수집입니다. 선형 메모리와 WASM 코드를 사용하는 가비지 수집 알고리즘을 구축하면 이 문제가 해결되지 않습니다. 결국 프로그램을 중지하여 어떤 개체가 아직 살아 있는지 확인하고 그렇지 않은 개체는 삭제해야 합니다. 해결책은 GC가 실행될 필요가 없도록 가비지 개체를 생성하지 않는 것입니다. 이를 달성하기 위해 WASM이 필요하지 않으며 엔진을 재작업해야 합니다.

배열을 재사용하고 쓰레기를 적게 만드는 매우 깨끗한 Javascript는 작성하기가 매우 어렵습니다. 또한 Plain Js는 WASM으로 컴파일할 수 없다고 생각합니다. Asm.js 또는 Typescript는 각각 유형 주석 또는 유형의 가용성으로 인해 WASM으로 컴파일하기가 더 쉬울 것입니다.

@metacritical 어렵지만 불가능하지는 않습니다. C++ 엔진에서도 대부분의 코드는 객체 수명 관리에 관한 것입니다. 틀에 얽매이지 않지만 JavaScript에서 동일한 작업을 수행할 수 없는 이유는 없습니다.

일반 JS는 WASM으로 컴파일할 수 _있지만 컴파일러는 가비지 수집, 반사, 속성 등과 같은 JavaScript의 상위 수준 기능을 활성화하기 위해 많은 도우미 코드를 추가해야 합니다. 기본적으로 브라우저에 내장된 JS 엔진으로 무료로 얻을 수 있는 모든 것. TypeScript는 별로 도움이 되지 않습니다.

그에 비해 ASM.JS는 WASM으로 쉽게 변환할 수 있습니다. ASM.JS에서 허용하는 JS 기능의 엄격한 하위 집합도 WASM에서 100% 적용됩니다. ASM.JS로 작성된 많은 양의 코드가 있다면 이것은 가치 있는 노력이 될 것이지만 내가 아는 한 모든 주요 ASM.JS 파일은 이미 WASM을 직접 대상으로 할 수 있는 C++ 소스 코드에서 생성됩니다.

그에 비해 ASM.JS는 WASM으로 쉽게 변환할 수 있습니다.

맞습니다. 실제로 오늘날 우리가 C++를 wasm으로 컴파일하는 주요 방법은 먼저 asm.js로 컴파일한 다음 Binaryen의 asm2wasm을 사용하여 것 입니다.

@kripken asm.js 사양을 보면 손으로 쓴 asm.js를 작성하는 것이 쉬워 보입니다. 이는 js 프로그래머에게 모든 것이 손실되지 않는다는 것을 의미합니다. 우리는 여전히 위의 방법을 사용하여 WASM 바이너리를 얻을 수 있습니다.

JS의 진화, 즉 엄격하게 입력된 언어가 JS -> WASM의 좋은 후보가 될 수 있지 않을까요?
TC39에 typed object에 대한 제안이 있다고 생각합니다. 더 많은 다른 기능이 이를 가능하게 할 수 있습니다.

@aruns07 사람들이 사용하도록 허용하는 JavaScript 기능이

@Kardax @aruns07 사람들은 Dynamic Language의 편리함을 좋아합니다. 항상은 아니지만 가끔 강력한 유형이 필요합니다.

jfbastien이 2015년 6월 24일에 댓글을 남겼습니다.
JS → wasm은 wasm이 GC를 지원하고 JIT 컴파일도 지원해야 실제로 의미가 있습니다. 이것은 기본적으로 wasm에서 JS 엔진을 구현하는 것과 같습니다!

다음 링크에 따르면:
https://lists.w3.org/Archives/Public/public-webassembly/2017Feb/0002.html
WebAssembly 합의 및 브라우저 미리보기 종료

첫 회신 후 2년이 지난 지금 WebAssembly는 오늘날 주요 웹 브라우저에서 지원됩니다.
따라서 wasm에서 JS 엔진을 구현하는 것과 동일하지 않습니다.
js -> wasm의 장점은 GC 지원뿐만 아니라 더 작은 코드 크기와 더 빠른 실행, 특히 일반적으로 응용 프로그램 로드 시간이 5를 초과하는 10MB 정도의 JS 파일을 생성하는 Ionic2와 같은 하이브리드 응용 프로그램 개발 분야에서 그렇습니다. 초(JS의 각 2MB 구문 분석 = 1초)

@jfbastien JS -> wasm transpiler에 대한 업데이트된 답변을 게시해 주세요.

석사 논문의 일부로 JavaScript의 하위 집합에서 WebAssembly로 Transpiler를 작성하려고 합니다. 처음에는 TypeScript로 제한되지만 Flow와 같은 다른 유형의 변형도 향후 지원될 수 있습니다.

그러나 목표는 전체 JavaScript 언어를 구현하는 것이 아닙니다. 이 경우 JIT 구현이 오늘날 직면하고 있는 것과 동일한 문제에 직면하게 되므로 속도 향상을 기대할 수 없습니다. ). SoundScript에서 정의한 것과 같은 하위 집합이 될 것입니다.

내 목표는 개발자가 익숙한 개발 환경을 벗어나거나 다른 프로그래밍 언어를 사용할 필요 없이 애플리케이션의 특정 부분을 WebAssembly로 컴파일할 수 있도록 하는 것입니다. 따라서 기존 JavaScript 응용 프로그램을 허용하는 범용 변환기가 아니라 응용 프로그램의 중요한 부분의 성능을 가속화하기 위한 것입니다.

그러한 접근 방식의 장단점을 볼 때 내 연구 결과가 어떻게 될지 매우 궁금합니다. 의견이 있으면 알려주십시오.

@Mohsen7s 내 대답은 여전히 ​​정확합니다. WebAssembly의 MVP 버전은 빠른 JavaScript 가상 머신을 구현할 수 있게 해주는 GC 및 JIT 기능을 지원하지 않습니다. 인터프리터는 완전히 가능하며 영리한 트릭을 사용하면 꽤 좋을 수 있지만 기본 구현만큼은 아닙니다.

이것은 "최소 실행 가능한 제품" 접근 방식에 내재되어 있습니다. 먼저 일부 사용 사례에 적합한 제품을 출시한 다음 다른 사용 사례에 맞는 기능을 추가합니다. MVP 및 누락된 "미래 기능"에 대한 유사한 토론에 대해서는 다음 스레드를 참조하십시오. https://github.com/WebAssembly/design/issues/992#issuecomment -281735235

현재 구현할 수 있는 것과 불가능한 것에 대한 기술적인 논의는 제쳐두고, JS -> WASM이 철학적으로나 마케팅 관점에서 1순위 목표가 아니라는 사실에 놀랐습니다. 이 경우까지 개발자 바이인. 모든 시장에서 일할 수 있는 JS 기술을 가진 모든 프론트/백 엔드/풀 스택 개발자가 대신 훨씬 더 작은 산업 하위 집합에서 사용되는 C++를 배우는 데 시간을 보내고 싶다면 이미 했을 것입니다. 그래서 - 나도 알아, 나는 하나로 말한다. 나는 이 전체 토론이 일종의 반향실이며 컴파일러의 부족을 옹호하는 사람들이 그들의 시간을 그들이 정말로 원하는 것이 무엇인지 묻는 사람들과 이야기하는 데 시간을 더 투자하는 것이 더 낫다고 생각하지 않을 수 없습니다.

@BossLevel

현재 구현할 수 있는 것과 불가능한 것에 대한 기술적인 논의는 제쳐두고, JS -> WASM이 철학적으로나 마케팅 관점에서 1순위 목표가 아니라는 사실에 놀랐습니다. 이 경우까지 개발자 바이인. 모든 시장에서 일할 수 있는 JS 기술을 가진 모든 프론트/백 엔드/풀 스택 개발자가 대신 훨씬 더 작은 산업 하위 집합에서 사용되는 C++를 배우는 데 시간을 보내고 싶다면 이미 했을 것입니다. 그래서 - 나도 알아, 나는 하나로 말한다.

브라우저는 이미 JavaScript를 효율적으로 실행할 수 있습니다. 브라우저는 의도한 사용 사례 를 효율적으로 실행할 수 없습니다. 게다가 WebAssembly에는 웹이 아닌 열망이 있습니다.

이 토론과 https://github.com/WebAssembly/design/issues/992#issuecomment -281735235는 다양한 사람들이 가진 다양한 목표를 보여줍니다. 아무도 틀리지 않아! MVP는 단순히 누가 먼저 서비스를 받는지 우선순위를 정하면 됩니다.

나는 이 전체 토론이 일종의 반향실이며 컴파일러의 부족을 옹호하는 사람들이 그들의 시간을 그들이 정말로 원하는 것이 무엇인지 묻는 사람들과 이야기하는 데 시간을 더 투자하는 것이 더 낫다고 생각하지 않을 수 없습니다.

그것이 W3C 커뮤니티 그룹을 구성하는 핵심이었습니다. 많은 관심 있는 개발자들로부터 들은 대로 성공했다고 생각합니다. 일부는 MVP에 관심이 없지만 향후 기능 에는 관심이

@jfbastien

브라우저는 이미 JavaScript를 효율적으로 실행할 수 있습니다.

하, 나는 2008년부터 평균적인 휴대전화에서 괜찮은 FPS로 실행할 수 있는 대규모 멀티플레이어 HTML5 게임을 작성하려고 노력했지만 여전히 거기에 있지 않습니다! 그리고 청구서를 지불하기 위해 계약할 때 매우 좋은 보상을 받는다는 점을 감안할 때 진행 상황이 부족한 것은 코드 품질 때문이 아니라고 확신합니다.

그것이 W3C 커뮤니티 그룹을 구성하는 요점이었습니다.

다시 하-커뮤니티 그룹에 가입한 실제 개발자가 몇 명입니까? 그렇게 하는 개발자는 일반적으로 예를 알고 있지만 실제 개발자의 고통을 덜 느끼는 전도사 등입니다.

그리고 죄송합니다. 이 페이지/관련된/W3C에서 누구를 폄하하고 싶지 않습니다. 말씀하신대로 이것은 토론이고 최전선에서 본 저의 입장입니다.

뼈를 걱정하는 개처럼 돌아와서 죄송하지만 멀리있는 동안 내 요점을 설명하는 더 나은 방법을 생각했습니다. 다음 뉴스레터/커뮤니티 이벤트 또는 피드백을 얻을 수 있는 수단이 무엇이든 웹 개발자(고객)에게 이 질문을 하십시오.

브라우저 기반 성능을 한 단계 끌어올리려면 다른 언어를 배워야 합니다. 이게 받아들여질까요?

그것은 기본적으로 이 페이지의 일부가 이미 (내 생각에는 해롭게) 답변한 질문이기 때문입니다.

그리고 마지막으로 (약속합니다 ;-) ) @jfbastien , 다음과 같은 경우:

게다가 WebAssembly에는 웹이 아닌 열망이 있습니다.

이름이 "WebAssembly"인 이유는 무엇입니까?

@BossLevel 나는 당신이 어디에서 왔는지 알 것 같습니다. 나는 복음화를 하는 사람들을 대변할 수는 없지만 WebAssembly에 관심이 있는 전통적인 "네이티브" 개발자들과 여러 전도자들이 접촉해 왔다는 것을 이해합니다. 귀하의 관점에서 볼 때 명확하지 않을 수 있지만 최소한 "진지한" 개발자의 표시로 Unity의 관심을 지적할 수 있습니다. 이 사람들은 또한 자신의 이름으로 github에 게시하지만 소속이 항상 명확한 것은 아닙니다. 제가 그들을 대변할 자리는 아닙니다.

하, 나는 2008년부터 평균적인 휴대전화에서 괜찮은 FPS로 실행할 수 있는 대규모 멀티플레이어 HTML5 게임을 작성하려고 노력했지만 여전히 거기에 있지 않습니다! 그리고 청구서를 지불하기 위해 계약할 때 매우 좋은 보상을 받는다는 점을 감안할 때 진행 상황이 부족한 것은 코드 품질 때문이 아니라고 확신합니다.

빠른 JavaScript 작성이 쉽다는 의미는 아닙니다. 내가 말하고 싶은 것은: WebAssembly는 JavaScript 최적화를 더 쉽게 만들지 않는다는 것입니다. 오히려 브라우저가 안정적인 성능을 생성하는 데 더 적합한 형식을 사용할 수 있습니다. 또한 TC39는 JavaScript를 컴파일 대상으로 하는 것이 아니라 JavaScript 자체를 개선하는 데 집중할 수 있습니다.

다시 하-커뮤니티 그룹에 가입한 실제 개발자가 몇 명입니까? 그렇게 하는 개발자는 일반적으로 예를 알고 있지만 실제 개발자의 고통을 덜 느끼는 전도사 등입니다.

그리고 죄송합니다. 이 페이지/관련된/W3C에서 누구를 폄하하고 싶지 않습니다. 말씀하신대로 이것은 토론이고 최전선에서 본 저의 입장입니다.

당신의 관점은 참으로 타당하며, 당신의 입장에서 내가 믿기 힘든 말을 하고 있는 것이 분명하다고 생각합니다. 우리는 이것을 더 잘 전달해야 합니다(아니면 제가 틀렸을 수도 있습니다 :wink:).

브라우저 기반 성능을 한 단계 끌어올리려면 다른 언어를 배워야 합니다. 이게 받아들여질까요?

그것은 기본적으로 이 페이지의 일부가 이미 (내 생각에는 해롭게) 답변한 질문이기 때문입니다.

나는 당신의 우려를 이해하지만 그것이 사실로 밝혀지는 것이 아니길 바랍니다. 다시 말하지만, 내가 틀릴 수 있습니다. 내가 보기에 WebAssembly는 과거에 웹에 대한 나쁜 경험이 있거나 무서운 이야기를 들은 개발자인 새로운 개발자를 이 플랫폼에 데려옵니다. 결과적으로 "전통적인" 코드(일부에서는 "레거시"라고 함)를 사용하려는 JavaScript 개발자가 해당 코드를 사용하는 데 도움이 됩니다. 우리는 WebAssembly를 JavaScript에서 쉽게 사용할 수 있기를 바랍니다. 이를 달성하려면 npm 를 사용하는 것처럼 쉬워야 합니다(항상 쉽지는 않습니다!).

나는 우리가 Twitter, Hacker News, Reddit 및 다양한 컨퍼런스에서 본 피드백 때문에 이것이 밝혀질 것이라고 어느 정도 확신합니다. 다시 말하지만 내가 틀렸을 수도 있고 에코 챔버를 듣고 있습니다. 최소한 C++와 JavaScript 배경을 가진 사람들과 회의에서 매우 유망한 토론을 했습니다.

동시에 TC39는 진정으로 JavaScript를 개선하기 위해 노력하고 있습니다. 최근 몇 년 동안 특히 ES6에서 그랬다고 생각합니다.

하지만 요점은 남아 있습니다. 개발자는 JavaScript 뿐만 아니라 C++ 또는 Rust와 같은 "WebAssembly 친화적인" 언어에 정통하기를 원할 것입니다. 어떤 방향으로 일이 진행될지 모르겠습니다.

이름이 "WebAssembly"인 이유는 무엇입니까?

하아! 멋진 질문입니다. "WebAssembly: 웹 도 어셈블리도 아닙니다"라는 제목의 강연이 있습니다. 이름에 대해 어떻게 느끼는지 표현할 수 있도록 공개적으로 알려야 합니다.

그래서 나는 당신이 그것에 매달리도록 할 것입니다.

나는 여기에서 두 가지 욕망을 읽고 있습니다.

1. 빠른 로드 시간을 위한 표준 JavaScript의 이진 표현입니다.
2. 기본적으로 컴파일된 C++와 표준 JavaScript 사이의 성능 격차를 해소하기 위한 것입니다.

항목 2는 많은 회사에서 지속적인 연구와 대규모 투자의 대상입니다. 지난 15년 동안 JavaScript 엔진의 성능 측정을 보면 역시 작동하고 있습니다. 격차가 점점 줄어들고 있습니다.

항목 1은 내가 아는 한 아무도 작업하고 있지 않습니다. 그것은 엄청나게 복잡하고 JavaScript가 빠른 속도로 계속 발전함에 따라 점점 더 어려워지고 있습니다. WebAssembly는 매우 엄격하고 상대적으로 복잡하지 않으며 개발하는 데 몇 년이 걸렸습니다.

@jfbastien -

따라서 특별한 순서 없이 몇 가지 예시 사항이 있습니다.

1) 이 전체 토론과 나아가야 할 방향에 대한 내 견해에 대한 좋은 예는 NodeJS에 있습니다. JS API/C++ 백엔드에 대한 프론트엔드입니다. 한편으로는 속도, 다른 한편으로는 속도.
2) 2008년에 개인 오디세이를 시작했을 때 Node를 고수했습니다. ;-) 저는 원래 백엔드를 위해 PHP와 Java를 모두 살펴보았습니다. 그리고 판매 ;-) !) 그러나 나는 단지 하나의 언어를 배우고 그 언어를 잘 배우고 싶다는 단순한 이유 때문에 그것들을 빨리 할인했습니다! 내가 아는 개인적인 이야기지만, 내가 이런 느낌을 받는 유일한 개발자인지 의심스럽습니다. 특히 언어를 배우는 동안 회사에서 한푼도 받지 않고 스스로를 위해 일하는 개발자입니다.
3) 다음 요점을 제시하기 전에 의도적으로 숫자를 검색하지 않았지만(실제로 내가 할 수 있을지 확신할 수 없음) ASM의 비중이 낮았다는 점에 기꺼이 내기할 것입니다. 초기 데모를 보고 매우 흥분했다는 것을 알고 있지만 컴파일러가 없다는 것을 알게 되자 즉시 그것을 무시했습니다. 온라인에서 사용할 수 있는 방대한 API, 라이브러리, 리소스, 자습서, 프레임워크 등을 제공하는 지구상에서 가장 큰 개발자 커뮤니티(JS)의 일부인 웹 개발자에게 그런 것에서 한 발짝 물러나도록 요청하는 것은 너무 많은 것을 요구하는 것입니다. 잠재적으로 첫 번째 단계(즉, 컴파일러)가 귀하의 명백한 트릭을 놓치게 할 수 있는 수단을 제공하지 않음으로써. 나는 GLSL(Shading langage) 개발이 ASM보다 더 많은 성장을 보였다고 내기까지 했습니다. 이제 a) Pixi.js 및 Three.js와 같은 우수한 프레임워크에 직접 작성하고 b) 함께 사용할 수 있습니다. ShaderToy 와 같은 사이트에서 직접
4) 게임 산업/게임 전반. 저는 경험을 통해 다음과 같이 말할 수 있습니다.) 저는 지난 9년 동안 (아직 출시되지 않은) 게임을 작성해 왔습니다. b) TIGA (영국 게임 개발자를 위한 무역 협회) 이사회에서 2년 동안 일했습니다. 저를 믿으세요. 웹으로 마이그레이션하기를 원하는 게임 개발자의 수는 한 손으로 셀 수 있을 것입니다. 게임 개발자는 이미 자신이 좋아하는 업계에 있고 그럼에도 불구하고 오랜 시간 동안 급여를 받거나 일하고 있으므로 이러한 WA의 대상이 되어서는 안 됩니다. 예, 고용주는 항상 게임을 이식할 수 있는 새로운 매체를 찾고 있습니다. 하지만 모바일을 제외하고 스스로를 놀리지 말자(여기서 네이티브 코드는 슬프게도 WASM에서 수정하기를 원하는 경우). 웹은 여전히 ​​매우 중요합니다. 성능 및 수익 창출 측면에서 PC/콘솔과의 관계가 좋지 않습니다.
5) 반대로 침실 코더/인디 씬은 몇 년 전처럼 절정은 아니지만 여가 시간에 웹 게임을 만들고 싶어하는 웹 개발자가 엄청나게 많습니다. 정치적으로 노골적으로 방향을 틀고 싶지 않고 Unity 사람들을 노크하지도 않지만(여러 사람과 거래를 했으며 훌륭한 제품임), 개인적으로 당신이 이익을 돌봐야 한다고 생각합니다. 하나의 큰 사람이 아니라 여러 명의 작은 사람 중 하나입니다(철학적 및 상업적 의미가 모두 있음).

@jfbastien 의 강연을 많이 기대

@RyanLamansky - 당신이 합리적인 구별을 한다고 생각합니다. 다음과 관련하여:

항목 1은 내가 아는 한 아무도 작업하고 있지 않습니다. 그것은 엄청나게 복잡하고 JavaScript가 빠른 속도로 계속 발전함에 따라 점점 더 어려워지고 있습니다.

지극히 개인적인 차원에서 2008년부터 하루에 8시간씩 JS를 작성해 온 사람으로서 JS의 발전이 잠시 멈추고 다른 모든 사람들이 따라잡을 수 있기를 바랍니다! 나는 항상 가장 낮은 공통 분모에 대한 개발 원칙에 따라 작업했습니다. 즉, 100% 지원이 없으면 발생하지 않습니다(IE6/7/8/9는 제쳐두고 ;-). 그래서 우리는 데스크탑과 모바일에서 ES5에 대한 100% 브라우저 지원도 얻지 못했을 때 유행하는 ES6 패턴과 가정된 사용 사례에 초점을 맞추는 어리석은 입장에 있습니다. 이 언어는 시장 점유율에서 알 수 있듯이 분명히 있는 그대로 작동합니다(허용됨이 인정되었음에도 불구하고). 따라서 개발자 커뮤니티로서 앞으로 몇 년 동안 우리가 가진 것으로 효율적이고 최적의 코드를 작성하는 법을 배우는 것은 어떻습니까? 아직 새로운 힙스터 코드로 바퀴를 재발명(죄송합니다 ;-) )?

아마 코트를 받을 때가 된 것 같아요 ;-)

@RyanLamansky 저는 WebAssembly가 번들 빌드 프로세스의 새로운 대상이 될 것이며 갑자기 모든 것이 더 빨라질 것이라는 인상을 받았습니다. 분명히 그렇지 않습니다. WebAssembly는 매우 구체적인 대상 사용 사례를 가지고 있으며 비즈니스 로직으로 가득 찬 대규모 JS 코드 기반을 가진 일반적인 웹 개발자에게 제공할 것이 많지 않을 것입니다.

그러나 언급했듯이 보다 일반적인 비즈니스 지향 웹 응용 프로그램의 경우 JS 기반 개발 수명 주기에는 몇 가지 간격이 있습니다.
1) 큰 JS 번들은 상당한 파싱 오버헤드를 가지며 일반적으로 난독화를 제공하지 않습니다.
2) 표준 JS 코드에는 JIT/네이티브 코드 최적화에 필요한 유형 주석(및 기타 힌트)이 없습니다.

이것은 가능한 솔루션이 개발자에게 보다 결정적이고 투명한 최적화 경로를 제공하는 적절하게 유형이 지정되고 주석이 달린 JS 버전과 해당 언어 버전의 사전 구문 분석된 바이너리 버전임을 제안합니다.

의견과 문서에 따르면 WASM은 JS 외에 실행되고 동일한 JS 엔진을 사용하는 브라우저(최적화)입니다. https://developer.mozilla.org/en-US/docs/WebAssembly

나는 이 질문을 정말로 이해하지 못한다.

어리석은 질문을 하고 어리석은 말을 해서 죄송합니다. 질문과 Webassembly 팀의 의견은 Webassembly is FASTER than Javascript? I do not see performance comparison for WebAssembly Code and similar Javascript Code? 주관적인 생각만 본다는 것을 의미합니까? 누군가 이것을 설명할 수 있습니까? Webasemly가 Javascript보다 빠르다면 왜 변환기를 제공하지 않습니까? Javascript가 가능하지 않다면 왜 ES7/TS 코드가 안될까요? 왜 이것에 대해 그렇게 많은 비밀이 있습니까?

@ganeshkbhat WASM의 초기 릴리스는 JavaScript의 매우 엄격한 하위 집합인 asm.js의 압축 바이너리 인코딩에 불과합니다. asm.js에서 에뮬레이트해야 하므로 64비트 정수를 사용하지 않는 한 asm.js보다 빠르게 실행되지 않습니다.

WASM에 기능(가비지 수집, DOM 통합, 스레드)이 JavaScript에 더 가까워지도록 하는 기능을 추가하려는 제안이 있지만 전체 JavaScript 기능 세트를 추가할 계획은 없습니다. 따라서 JS->WASM 변환기는 절대 존재하지 않을 것입니다. 대신 WASM의 한계 내에서 작동하도록 설계된 새로운 애플리케이션과 라이브러리가 만들어질 것입니다. 오늘날 언어 제한이 WASM 및 asm.js와 잘 맞는 C 및 C++입니다.

비밀도 마법도 없습니다. Wasm은 하드웨어에 훨씬 더 가까운 훨씬 간단한 언어이기 때문에 "JavaScript보다 빠릅니다". JavaScript는 실행 중에 많은 비용이 드는 작업을 수행해야 하는 복잡한 언어입니다. 직접 대신 Wasm을 통해 네이티브 코드로 컴파일하면 마술처럼 빨라지지 않습니다.

@ganeshkbhat 현재 asm.js/webassembly 내부에 개체를 할당할 수 없습니다. asm.js 및 webassembly에서 모든 JavaScript 작업은 하나의 큰 typedarray를 사용하여 값을 저장하고 로드합니다. JavaScript 개체(예: var obj = {a: 1, b: 'test'} ) 및 배열(예: var a = []; )은 아직 개체 지원이 없기 때문에 웹 어셈블리 내에서 생성할 수 없습니다. 이것은 가능한 한 빨리 모든 주요 브라우저에서 웹 어셈블리 지원을 받기 위해 만들어진 Minimal Viable Product의 디자인 결정입니다.

향후 버전에서는 웹 어셈블리에 대한 GC 지원 이 계획되어 있습니다. 우리( LeaningTech.com 개발자)는 더 큰 JavaScript 하위 집합 을 변환할 수 있어야 하지만 현재 사용 가능한 모든 기능 을

확신하는. 여기에서 JS에 대한 더 나은 지원을 기대하십시오. 확실히 지원할 수 있다고 생각합니다. 트랜스파일러를 작성하는 것은 언어를 지원하는 유형에 필요할 수 있습니다.

웹 어셈블리에 대해 읽은 내용에서 주로 웹 브라우저를 대상으로 하고 있으며 해당 영역에서는 js -> 웹 어셈블리 컴파일러를 사용하는 것이 그다지 매력적으로 들리지 않습니다. 그러나 브라우저가 아닌 환경에서 웹 어셈블리를 실행하는 것을 상상할 수 있습니다. 이것은 nodejs에서도 실행할 수 있는 것처럼 완전히 사실이 아니지만 vertx와 같은 nodejs 환경의 진정한 잠재력을 봅니다. 웹 어셈블리로 컴파일할 수 있는 모든 언어로 작성된 모듈을 실행할 수 있는 다중 언어. 나는 이런 일을 하는 것이 매우 어려울 것이라고 상상할 수 있습니다. 구현하려면 GC와 같은 많은 기능이 필요하고 심지어 어떤 종류의 VM도 필요하지만 불가능한 것은 없습니다. 많은 사람들이 asm.js에 대해서도 회의적이었다는 것을 기억하고 오늘 그것을 살펴보십시오.

js -> 웹 어셈블리를 컴파일하는 것에 대해 (나처럼) 흥분되는 모든 사람들에게 미래에 프로젝트 ts2c 변환기 를 사용하여 js -> c -> 웹 어셈블리 를 통해 간접적이고 매우 울퉁불퉁한 방법이 있을 수 있습니다.

@mauron85 비 브라우저 및 비 자바스크립트 런타임 환경은 확실히 디자인의 고려 사항입니다. 오늘날에는 JS API만 존재한다는 것입니다.

제 경우에는 .NET JIT 시스템을 실험해 보았고 시간 외에는 실질적인 장벽이 없다고 생각합니다. 또한 WASM을 선호하는 플랫폼에 통합하려는 다른 사람들도 있을 것이라고 확신합니다. 나는 몇 년 후에 WebAssembly를 위한 고품질 비 자바스크립트 런타임이 있을 것이라고 확신합니다. 유일한 미해결 문제는 WebAssembly 팀에서 공식적으로 승인할 정도입니다.

IMO JavaScript -> WebAssembly 컴파일 기능의 한 가지 이점은 Javascript 라이브러리 및 도구의 개발자/유지 관리자가 API를 두 가지 형식으로 릴리스할 수 있다는 것입니다.

1. 사용자가 브라우저 및 노드에 사용할 수 있는 JS(현재 그대로)
2. WASM은 더 효율적일 수 있는 컴파일된 라이브러리입니다.

그리고 이것은 JS 라이브러리에서 WASM의 성능 이점을 활용하려는 경우 기존 JS 코드를 C/C++로 다시 작성할 필요가 없습니다.
따라서 라이브러리 개발자는 여전히 Javascript로 개발 및 유지 관리할 수 있으며 JS 및 WASM 모두에서 두 개의 서로 다른 대상에 대해 두 개의 출력을 생성할 수 있습니다.

그리고 컴파일된 WASM 버전 라이브러리를 사용하는 것이 사용자에게 확실히 더 효율적일 것입니다. 사용자는 라이브러리에서 노출된 API를 사용하기만 하면 되며 WASM으로 작성되었는지 여부를 분명히 신경 쓰지 않을 것입니다. 그러나 성능은 확실히 향상될 것입니다.

더 효율적일 수 있는 컴파일된 라이브러리로서의 WASM

왜요? 왜 자바스크립트 덩어리가 웹 어셈블리를 트랜스파일했을까요(최악의 시나리오는 해당 바이너리의 자바스크립트 엔진에 대한 런타임의 대부분을 포함하고, 최상의 시나리오는 미래의 빌트인 wasm GC 위에 구축된 레이어를 포함하여 어쨌든 자체 오버헤드가 발생함) ) 자바 스크립트를 실행하는 전용 jit에 던져진 자바 스크립트보다 빠르게 실행?

좋아요, 오버헤드가 더 많으면 속도가 더 느려질 것이라는 말씀이신가요?

제가 잘 이해하지 못한 부분이 있을 수 있습니다. C/C++/Rust -> WebAssembly 컴파일된 항목이 어떻게 정말 효율적이고 미래에 오버헤드를 야기할 JS -> WASM 지원이 있더라도? JS는 동적 언어이고 C, C++ 및 Rust는 그렇지 않기 때문입니까? 아니면 JS가 본질적으로 완전히 컴파일된 언어가 아니라 이러한 다른 언어들이 있기 때문입니까?

JS에서 WASM으로의 컴파일이 지속적인 성능을 향상시킬 가능성은 거의 없다고 생각합니다. 그러나 여전히 유용한 이진 인코딩으로 인해 코드 크기와 구문 분석 시간이 향상될 수 있습니다.

나는 우리가 JS에 대한 바이너리 인코딩을 정의할 수 있다고 생각하고 지금은 선형 메모리 등을 무시할 수 있습니다. 이것은 간단하고 폴리필 가능합니다.

@kabirbaidhya 현재 JS -> WASM의 주요 문제는 스택을 분석하여 활성 상태인 개체를 확인할 방법이 없기 때문에 내부에 효율적인 가비지 수집기를 구축할 수 없다는 것입니다. 즉, 선형 메모리(힙)에 모든 개체 참조의 복사본을 배치하고 동기화 상태를 유지해야 하므로 성능이 심각하게 저하됩니다. 또한 공유 메모리 멀티 스레딩이 부족하여 백그라운드 가비지 수집이 불가능합니다. WASM의 향후 버전은 호스트 브라우저의 가비지 수집 엔진을 활용하여 이 문제를 해결할 수 있습니다.

JS -> WASM의 또 다른 주요 장벽은 거의 모든 객체가 완전히 동적이라는 사실입니다. WASM은 본질적으로 모든 것이 순전히 정적일 것으로 예상하므로 표준 JS 성능에 접근하려면 복잡한 매핑 레이어, 에뮬레이션 및 동적 코드 생성이 필요합니다. 다행히 TypeScript가 이를 도와주므로 TypeScript의 엄격한 하위 집합이 어느 정도 WASM을 대상으로 할 수 있습니다. 나는 이것을 구축하려는 사람이 적어도 한 명 있다는 것을 알고 있습니다.

C/C++는 WASM의 제한 사항이 C/C++가 대상으로 하도록 설계된 기본 하드웨어 제한 사항과 밀접하게 정렬되어 있기 때문에 WASM의 첫 번째 릴리스와 잘 작동합니다.

FWIW에는 V8이 JavaScript 산술을 처리하는 방법에 대한 훌륭한 슬라이드가 있습니다. https://docs.google.com/presentation/d/1wZVIqJMODGFYggueQySdiA3tUYuHNMcyp_PndgXsO1Y/edit

tl;dr 이것은 실제가 보이는 것보다 훨씬 더 어렵고 실제로는 그다지 의미가 없는 _하나의_ 예일 뿐입니다. 기본 VM이 진정한 기본이고 리소스와 API는 결코 하지 않을 것이며 (아마도) 가장 중요한 것은 수년간의 반복입니다.

그렇다고 ThinScript , TurboScript 등과 같이 JS/TypeScript 의 _subset_ 가 성공적으로 증식할 수 없다는 것은 아닙니다. 언뜻 보기에는 JS 프로그래머에게 매우 친숙해 보일 것입니다.

나는 여전히 이것이 좋은 질문이라고 생각하고 계속 질문합니다. 우리 모두가 WebAssembly의 사용 사례와 미래뿐만 아니라 비목표를 이해하는 것이 중요합니다.

2017년 4월 6일 00시 36분에 Ryan Lamansky [email protected] 은 다음과 같이 썼습니다.

JS -> WASM의 또 다른 주요 장벽은 거의 모든 객체가
완전히 동적입니다. WASM은 본질적으로 모든 것을 순수하게 기대합니다.
정적이고 복잡한 매핑 레이어, 에뮬레이션 및 동적 코드 생성
표준 JS 성능에 접근하려면 필요합니다. 다행스럽게도,
TypeScript가 이를 도와주므로 TypeScript의 엄격한 하위 집합은 다음을 수행할 수 있습니다.
어느 정도 WASM을 대상으로 합니다. 적어도 한 사람이 노력하고 있다는 것을 알고 있습니다.
이것을 구축하십시오.

불행히도 TypeScript가 이와 관련하여 도움이 되는지 의심스럽습니다. 포괄하다
JS 레거시, 그 유형 시스템은 너무 깊고 근본적으로 불건전하여
흥미로운 "엄격한" 하위 집합이 없습니다. 예를 들어, 그러한 하위 집합은
TS의 하위 유형 개념을 제외해야 합니다.
그 영역에서는 별로 쓸모가 없습니다.

SafeTypeScript와 같은 훌륭한 연구 논문이 있지만
더 제한적일 뿐 아니라 상당한 양의
비용이 많이 드는 추가 런타임 부기 및 확인,
토론(그리고 사실상 JS/TS와 다른 언어임).

어쩌면 나는 뭔가를 얻지 못하고 있지만 WebAssembly의 아이디어 중 하나는 js의 구문 분석 시간을 피하기 위해 AST를 직접 로드하는 것입니다. 맞습니까?

따라서 js를 이 ast 형식으로 컴파일하고 브라우저에 전달하는 도구가 있다면 구문 분석 시간을 피하는 것이 좋지 않을까요?

@agnivade , 완전히 다른 훨씬 더 낮은 수준의 언어를 위한 AST입니다.

JS를 오프라인으로 Wasm으로 컴파일하려는 경우 예, 클라이언트 측에서 구문 분석할 필요가 없습니다(디코딩만 하면 됨). 동시에 JS는 너무 복잡하기 때문에 코드 크기가 5배 이상으로 급격히 증가하며, 이는 훨씬 더 높은 비용입니다. (그리고 그것은 메가바이트의 코드에 불과한 Wasm에 JS VM 런타임 시스템의 전체 구현을 포함해야 할 수도 있다는 점을 고려하지도 않습니다.)

게다가, 소스를 나타내지 않고서는 JS를 거의 빠른 속도로 얻는 데 중요한 대부분의 동적 최적화를 구현할 수 없습니다. 이러한 최적화는 원본 소스 코드를 다시 컴파일하고 프로파일링 정보를 기반으로 전문화하는 데 의존합니다. 이미 컴파일된 Wasm AST는 이를 가능하게 하지 않으며, 원래 소스 프로그램의 AST가 필요합니다.

@rossberg-chromium - 감사합니다. 그것은 많은 것을 해결합니다! 하지만 한 가지 의문점은 -

그리고 그것은 당신이 아마도 메가바이트의 코드인 Wasm에 JS VM 런타임 시스템의 전체 구현을 포함해야 할 필요가 있다는 것을 고려하지도 않습니다.

VM 런타임 시스템이 필요한 이유는 무엇입니까? 브라우저 자체가 VM 런타임이 아닙니까? 브라우저에서 쉽게 실행할 수 있도록 코드를 AST 형식으로 지정하고 싶습니다. 언어 자체가 복잡하고 동적 최적화를 구현할 수 없기 때문에 순 크기가 증가한다는 것을 알았습니다. 하지만 브라우저가 있는데 VM 런타임 자체를 번들로 묶어야 하는 이유는 무엇입니까?

@agnivade , 동적 최적화 없이 JavaScript는 느릴 것이고, 제 말은

"런타임"이란 DOM과 같은 브라우저 항목을 의미하는 것이 아니라 가비지 수집기, 객체 표현, 기본 라이브러리 및 기본 라이브러리와 같은 베어 JS 언어 지원을 의미합니다. 이는 JavaScript에 대해 상당히 거대합니다. Wasm 내부에서 모든 것을 다시 구현해야 합니다.

물론 DOM에 대한 인터페이스 레이어도 필요합니다.

좋아, 이제 좀 더 이해가 잘 된 것 같아. 나는 생각했다

가비지 수집기, 개체 표현, 기본 라이브러리 및 기본 라이브러리 등

브라우저 자체에서 사용할 수 있습니다. 그리고 브라우저가 AST를 로드하고 일반적인 작업을 수행하도록 할 수 있습니다. 하지만 이제는 모든 것이 WASM 자체 내부에 패키징되어야 한다는 것을 깨달았습니다.

보편적인 스크립팅 언어 바이트코드는 흥미로울 것입니다! 동적으로 유형이 지정되고 가비지 수집된 언어로 작성된 프로그램을 효율적으로 전송하고 실행하도록 설계된 컴파일 대상으로, 인기 있는 언어(자바스크립트, 루비, 파이썬, 루아)의 모든 기이한 경우가 (일부 경우) 특수 opcode 및 구조 등으로 다루어집니다.

@distransient , 모든 스크립팅 언어의 조합적 광기를 원하십니까? 저는 인류가 2050년까지 이를 효율적으로 지정하고 구현하기 위해 엔지니어링 리소스를 수집하는 것이 가능할 것이라고 낙관합니다. :)

LLVM을 사용하여 TypeScript를 WebAssembly로 컴파일하는 데 관심이 있는 사람. 이 도달 프로젝트를 확인하십시오. https://github.com/MichaReiser/speedy.js
이 토론은 끝나지 않을 것 같습니다 ...

@rossberg-chromium 나는 그것이 "재미있다"고 말했지만 쉽지도 예쁘지도 않았습니다 😉

보편적인 스크립팅 언어 바이트코드는 흥미로울 것입니다...

WASM은 Python과 같은 것을 지원하도록 점진적으로 발전하고 있지만 동시에 반대편에서 문제에 접근한다면 WASM이 제공할 수 있는 것보다 훨씬 빨리 웹용 스크립팅 언어 개발에 대한 최고 수준의 지원을 받을 수 있습니다.

JavaScript 엔진이 JavaScript AST를 실행할 수 있는 능력을 노출하는 것은 비교적 간단해야 하며 승인된 AST는 표준화될 수 있습니다(비표준 중간 형식으로 내부적으로 즉시 변환되더라도).

AST 형식(예 estree )과 직렬화 형식(예: JSON)을 결합하여 새 확장자를 가진 새 파일 형식을 만들 수 있습니다. 브라우저가 스크립트 태그 등의 형식을 지원하는 경우 TypeScript 및 CoffeeScript와 같은 언어는 트리를 구문 분석하기 위해 컴파일하고 브라우저는 거기에서 가져옵니다. 트랜스파일된 언어는 코드 생성을 수행할 필요가 없으며 어휘 정보가 실제 소스를 기반으로 하기 때문에 소스 맵도 더 이상 필요하지 않습니다.

기본 지원이 설정되면 기본적으로 새로운 노드 유형을 추가하여 중간에서 WASM을 충족하도록 표준을 점진적으로 발전시킬 수 있습니다. 명시적인 add 및 concat 노드 또는 DEC64와 같은 새 데이터 유형 추가와 같이 시작할 수 있는 간단한 것들이 있습니다.

WASM이 스크립팅 언어를 지원하도록 구축됨에 따라 GC와 같은 것을 추가함으로써 AST 실행이 하향 이동하여 다른 고급 언어의 기능을 포함하도록 JavaScript 의미론을 확장하므로 광범위한 스크립팅 언어 세트가 일종의 추상 JavaScript로 컴파일될 수 있습니다.

2017년 5월 25일 02:57에 Carl Smith [email protected] 은 다음과 같이 썼습니다.
>

해결해야 할 몇 가지 문제가 있지만,
JavaScript 엔진이 내부 지원을 노출하는 데 비교적 간단합니다.
JavaScript AST를 실행하기 위해 허용되는 AST는 다음과 같아야 합니다.
표준화(AST가 즉시 비표준으로 전환되더라도
내부적으로 중간 형식).

당신이 생각하는 것보다 훨씬 더 광범위한 "상대적으로 단순한" 정의에 대해서만
염두에두고... ;)

WASM에 비해 간단합니다.

@bguiz 예:

• JS는 아키텍처가 다르기 때문에 기본적으로 ASM으로 변환할 수 없습니다.
• CPU 지면 수준에서 리소스에 액세스할 수 없기 때문에 ASM에서 DOM을 조작할 수 없습니다.

Google V8 엔진은 실행하기 전에 전체 런타임 작업을 컴파일하여 JavaScript를 기본 기계어로 직접 컴파일합니다.

따라서 클라이언트 측에서 대체 WASM 파이프라인을 갖는 것은 완전히 불필요합니다.

다른 한편으로 WASM은 Mandelbrot 데모와 함께 제공되었으며 처음에는 Unity "Tanks" 데모를 제공했지만 ASM->CPU(SSE 배정밀도 포함)를 사용하여 픽셀을 그리는 것이 더 빠를 수 있을지 의심스럽습니다. WebGL->GPU보다 이 커뮤니티에서 말하는 것처럼 GPU가 범위에 포함되지 않기 때문입니다. 그래서 무엇?

@ivanherczeg 와우! 이 커뮤니티에서 GPU가 사양에 없다고 말하는 곳은 어디입니까?

@SephReed

우리는 이미 arm과 x86 사이의 자전거 보관소 차이로 인해 긴장이 있습니다. 다른 하드웨어 대상 세트를 추가하면 더 많은 긴장이 발생할 것이라고 생각합니다. 모든 대상에서 균일한 의미를 얻기 위해 에뮬레이션 비용으로 인해 더 많은 작업이 느려지거나 모든 사람이 빠르게 실행할 수 있도록 더 많은 작업에 정의되지 않은 동작이 있어야 합니다. 현재(또는 앞으로도) GPU를 고려하는 것은 수익성이 없다고 생각합니다.

-필

https://github.com/WebAssembly/design/issues/273#issuecomment -123094583

C# 런타임은 wasm으로 이식되었으며 JS를 완전히 대체하는 완전한 기능의 프로토타입이었습니다. 따라서 이는 미래에 런타임이 브라우저에서 JS를 대체하고 Java, C# 또는 C++로 클라이언트 측 웹 앱을 작성하고 "코드는 네이티브에 가깝게 실행될 것입니다" , "컴파일된 코드는 VM보다 빠릅니다" 라는 명령문과 함께 등장할 것으로 예상할 수 있음을 의미합니다. 또는 JavaScript의 도움 없이는 무엇이든 가능합니다.

제가 말하고자 하는 바를 이 영상 을 봐주세요.

WebASM은 JS가 완전히 인수되지 않도록 보완하기 위해 도입되었으며 First 클래스 언어를 대체합니다.

가까운 장래에 기본적으로 컴파일된 서버에서 웹 페이지가 제공될 것으로 기대할 수 있습니다.

https://github.com/ballercat/walt

@Steakey 아주 좋아요 :) 연극을 해야겠어요 - 강조해주셔서 감사합니다 :)

NectarJS를 사용하여 JS를 WebAssembly로 컴파일할 수 있습니다. 데모: http://nectar-lang.com/ 드롭다운 WebAssembly에서 선택

흥미롭게도 NectarJS 데모는 emscripten을 사용하며 asm.js 출력에서 ​​볼 수 있습니다. JS를 C 또는 LLVM IR과 같은 것으로 정적으로 컴파일한 다음 emscripten을 통해 실행하는 것으로 보입니다.

wasm 출력도 emscripten을 사용하지만(바이너리 검사에서 볼 수 있음) 최신 VM에서 실행되지 않는 0xd wasm 바이너리를 방출하므로 이전 버전을 사용하는 것 같습니다. 또한 JS가 아닌 wasm을 보내므로 어쨌든 실행할 수 없습니다. 어쨌든 asm.js와 동일한 작업을 수행할 가능성이 매우 높습니다. wasm 출력 플래그를 켜고 emscripten을 실행하기만 하면 됩니다.

데모는 입력에 300바이트 제한이 있으므로 분석이 얼마나 강력한지 느끼기 위해 실제 프로그램을 제공하기가 어렵습니다. 이것이 이와 같은 정적 접근 방식의 실제 질문입니다. 일반적으로 이 주제에 대한 학술 연구는 회의론을 제시합니다.

Windows용으로 컴파일된 데모가 나에게 충돌합니다 🤕

@kripken 회의론에 동의합니다. 임의의 JS를 WebAssembly로 합리적으로 변환할 수 없다고 생각합니다. 이를 달성한다고 주장하는 모든 도구는 JS 언어의 다루기 쉬운 하위 집합에서 작동하거나 실행 성능을 포기할 수 있습니다.

JS는 매우 역동적인 언어입니다. 예측할 수 없는 런타임 작업은 코드의 의미 체계를 전 세계적으로 크게 변경할 수 있습니다. 이것은 Ahead-Of-Time(또는 오프라인) 컴파일러가 더 나쁜 경우만 가정하고 가능한 모든 경우를 처리할 수 있는 매우 비효율적인 일반 코드를 생성할 수 있음을 의미합니다. 예를 들어 다음 JS 코드를 사용합니다.

var a = {prop1: 1};
func(a);

(pseudo-wasm에서) 이것으로 변환될 수 있습니다

i32.const 42
call $CreateJSValFromStrTable ;; Returns prop1
i32.const 1
call $CreateJSValFromInt
call $CreateJSObj1 ;; Consume a JS string and a JS value to make an object
call $_func

이제 이것은 우리가 합리적으로 "컴파일"이라고 생각할 수 있는 것과는 거리가 멀고 인터프리터를 펼치는 것과 더 유사합니다. 물론 Wasm으로 컴파일된 JS 인터프리터를 실행하는 것도 가능하지만 성능상 승리하지는 못할 것입니다.

V8 및 Spidermonkey와 같은 JS 엔진은 Just-In-Time으로 컴파일하여 JS 코드를 빠르게 실행할 수 있습니다. JIT 컴파일을 수행함으로써 그들은 주어진 JS 조각에 대해 실제로 의도된 의미가 무엇인지 관찰하고 해당 특정 경우에 대한 빠른 코드를 생성할 수 있으며, 물론 현재 가정을 무효화할 수 있는 환경의 변경을 감지하는 데 주의를 기울일 수 있습니다.

동의. 그러나 JavaScript 하위 집합을 사용하는 것은 마음에 들지 않습니다. 또는 아마도 역동성을 줄이고 보다 효율적인 코드를 생성할 수 있도록 하는 유형이 지정된 변형일 수 있습니다.

"강한 모드"전면 BTW에 대한 소식이 있습니까?

@Simran-B, 여기에 요약된 이유 때문에 우리는 오랫동안 강력한 모드를 포기

같은 이유로 JavaScript나 TypeScript의 "정적으로 컴파일 가능한" 방언을 디자인한다는 아이디어에 대한 희망도 별로 없습니다. 기존 코드를 실행할 수 없는 다른 언어일 것이기 때문에 별 의미가 없습니다.

@Simran-B : "하지만 JavaScript 하위 집합을 사용하는 것은 마음에 들지 않습니다. 아니면 유형이 지정된 변형일 수도 있습니다."

WebAssembly로 컴파일되는 TypeScript의 엄격한 하위 집합인 AssemblyScript와 같은 매우 흥미로운 작업이 있습니다. https://github.com/AssemblyScript/assemblyscript

@rossberg : "또한 JavaScript 또는 TypeScript의 "정적으로 컴파일 가능한" 방언을 디자인한다는 아이디어에 대한 희망이 많지 않습니다. 기존 코드를 실행할 수 없는 다른 언어가 될 것이므로 별 의미가 없습니다."

AssemblyScript와 같은 기능의 큰 잠재력은 기존 코드를 실행하는 것이 아니라(일반적으로 실현 가능하지 않을 것이라는 점에 동의합니다.) 친숙하고 친숙한 언어를 사용하는 것은 큰 문제입니다.

현재 TypeScript 개발자이고 WebAssembly를 작성하려면 C++ 또는 Rust를 사용해야 합니다. 둘 다 좋은 언어이지만 단점도 있습니다. 그런 배경을 가진 사람에게는 AssemblyScript와 같은 것이 생산성을 높이는 가장 빠른 경로일 수 있습니다.

AssemblyScript가 JavaScript와 Assembly 모두로 컴파일할 수 있다면 매우 이상적일 것입니다. 이러한 업데이트를 기대합니다.

또한 미래에는 누군가 먼저 하지 않는 한 파일을 살펴보고 필요한 질문을 하고 변환을 수행하는 TypeScript -> Assembly Script 변환기를 작성하려고 할 것입니다. 잘 되기를 바랍니다!

@SephReed 예, 모든 WebAssembly 코드에서 작동해야 하는 WebAssembly -> asm.js 컴파일러 가 있기 때문에 JavaScript로 컴파일할 수 있습니다.

"WebAssembly를 폴리필할 수 있습니까?" 도 참조하십시오.

대신 "AssemblyScript가 관용적 JavaScript 코드로 컴파일할 수 있습니까?"를 의미했다면 WebAssembly/asm.js가 관용적 JavaScript 코드보다 훨씬 빠를 때 왜 그렇게 하고 싶습니까?

TypeScript 컴파일러를 통해 AssemblyScript 코드를 실행할 수 있어야 한다고 생각합니다. 그러나 특정 사항을 염두에 두어야 합니다.

AssemblyScript 설명서의 이 섹션 도 참조하십시오.

여러분, JavaScript와 유사한 WebAssembly 언어인 WALT 를 고려하십시오.

UPD. 네크로포스팅해서 죄송합니다

많은 사람들이 이 "JS -> WASM" 컴파일러를 좋은 생각이라고 생각합니다.

다음과 같이 유용하지 않은 사람들을 위해:

그러나 개발자의 관점에서 그것이 그렇게 유용할지 확신할 수 없습니다. 크기를 줄일 수는 있지만 그게 전부입니다. 브라우저의 관점에서 보면 순수한 보안 관점에서 wasm에 JS 엔진을 구현하는 것이 흥미로울 수 있습니다.

여기 왜 중요한지, 왜 유용한지에 대한 구체적인 예가 있습니다. "크기 축소는 가능하지만 그게 전부입니다". WebAssembly와 함께 제공되는 기능 중 하나는 다음과 같습니다.

<=XXX « 샌디박스 환경 » XXX=>

WebAssembly는 단순히 성능에 관한 것이 아닙니다. 당신은 Figma 팀에서 플러그인에 대한 좋은 기사를 볼 수 있습니다.

플러그인 시스템을 만드는 것은 상당히 어렵습니다. 사용자 지정 코드를 실행하려면 몇 가지 좋은 방법이 필요합니다. 별도의 환경, 안전한 환경이 필요합니다.

WebAssembly는 다음을 제공합니다. 일부 전역 변수와 같이 엉망이 없는 순수한 환경입니다. AssemblyScript를 사용하면 어떤 면에서는 편리합니다. 기본 앱의 환경과 거의 동일한 TypeScript 환경을 갖게 되므로 매우 좋습니다.

그러나 여기에 "거의 동일"이라는 문제가 있습니다.

안전한 환경 내에서 NPM의 JS 패키지를 사용할 수 있습니까?

아니요.

이 WALT 프로젝트는 일종의 AssemblyScript 대안입니다. 간신히 JS와 비슷합니다. js 형식입니다. TS에 가깝습니다. 그것으로 기존 js 라이브러리를 컴파일/트랜스파일할 수 없습니다.

안전한 환경 내에서 NPM의 TS 패키지를 사용할 수 있습니까?

아니요.

AssemblyScript도 TS와 유사한 언어입니다. 유형으로 완전히 덮여 있는 경우 TS로 작성된 것을 컴파일할 수 있습니다. 예외 없음. any 가 없습니다. 그러나 종종 사람들은 구성이 충분히 엄격하지 않거나 몇 가지 @ts-ignore 가 있거나 더 자주 - js로 패키지를 작성하고 .d.ts 파일에 별도의 유형을 제공합니다 - 이 모든 경우에 이러한 패키지를 WASM으로 컴파일할 수 없습니다.

@JerryGreen은 좋은 점을 지적하지만 성능 측면에서 실제로 몇 바이트를 절약하는 것 외에 상당한 성능 이점이 없다는 것은 큰 오해라고 생각합니다. 벤치마크를 포함한 사람들은 런타임 성능에 너무 집착합니다. 3D 게임이 얼마나 빨리 실행되는지 확인하시겠습니까?

그러나 실제 기회는 사실상 모든 웹사이트에 혜택을 주는 시작 실적 에 있습니다. WebAssembly가 런타임 이점보다 훨씬 더 빠른 시작 시간(바이트당)에 대해 이야기하는 사람은 거의 없습니다. 이것이 JavaScript와 같은 텍스트 콘텐츠의 gzip이 PLT에 거의 실제 영향을 미치지 않는 이유입니다. 중요한 것은 컴파일된 코드 의 크기입니다.

아이러니하게도 업계는 PLT(페이지 로드 시간) 및 다양한 시각적 완성 마커에 집착하지만 WebAssembly와 이러한 벡터 간의 상관 관계를 아는 사람이 아무도 없습니까? JavaScript는 대부분의 웹사이트에서 이러한 중요한 이벤트가 발생하기 전에 30% 이상의 시간을 소비합니다. 실제로 페이지 크기와 대역폭은 자바스크립트 시작 시간과 대기 시간과 같은 선형 성능 요인에 비해

즉, JS -> WebAssembly의 실현 가능성이 명확하지 않습니다.

@JerryGreen Figma 의 접근 방식은 매우 구체적인 경우이며 대부분의 프로젝트에서 iframe 또는 영역이 타사 자바 스크립트 격리에 충분하다고 생각합니다. 격리가 더 제어되어야 하고 성능, 크기 및 로드 시간이 그다지 중요하지 않은 특수한 경우에는 항상 QuickJS 또는 JavaScriptCore 를 WebAssembly로 컴파일할 수 있습니다.

또한 웹 작업자를 사용하고 신뢰할 수 없는 코드가 액세스할 수 없도록 하려는 API를 삭제하는 신뢰할 수 없는 코드보다 먼저 코드를 실행할 수 있습니다. 이 경우 @JerryGreen은 WASM이 필요하지 않습니다!

실제에서 세 개의 js에서 프레임 속도가 떨어집니다. wasm이 도움이 될 수 있을지 모르겠지만 적어도 표면적으로는 그렇게 보입니다.

전체 javascript vm도 포함해야 하므로 JS를 wasm으로 컴파일할 이유가 없습니다. 결과 코드는 기본적으로 제공되는 JS VM보다 거대하고 느립니다.

Profile-Guided Optimization을 통해 JS VM이 수행하는 모든 단일화 등을 수행할 수 없었습니까? 우리는 JS VM이 런타임에 하는 것과 거의 같은 일을 할 것입니다.

PGO 빌드는 두 단계로 구성됩니다. 첫 번째 단계는 계측된 바이너리를 빌드하는 것이고, 두 번째 단계는 계측된 바이너리를 실행하여 수집한 프로필 정보를 사용하여 최적화된 바이너리를 다시 빌드하는 것입니다.

첫 번째 실행은 모든 유형 정보(어떤 유형의 인수로 함수가 호출되는지 등)를 제공한 다음 함수가 호출되는 모든 변형으로 최적화된 바이너리를 빌드합니다(+ 프로파일링되지 않은 코드에 대한 동적 인수가 있는 일반 버전). . 전체 JS VM이 필요하지 않습니다.

PGO는 귀하의 프로그램에 대한 훌륭한 테스트 범위를 요구했습니다. 항상 가능한 것은 아닙니다. 그러나 v8에서 실행하는 동안 일부 유형 정보를 추적할 수 있습니다. 이 문서를 참조하십시오. https://docs.google.com/document/d/1JY7pUCAk8gegyi6UkIdln6j_AeJqQucZg92advaMJY4/edit#heading =h.xgjl2srtytjt

우리는 TypeScript 팀과 이 가능성에 대해 이야기했으며 그들은 관심을 보였습니다. 그러나 현재 JS에 유형이 지정된 개체를 추가하는 데 진전이 있는 것 같습니다.

유형이 필요하지 않습니다.

QuickJS를 실제로 WASM으로 컴파일할 수 있습니까?

예, Figma는 예를 들어 플러그인 시스템에 QuickJS를 사용합니다.

그리고 http://numcalc.com/ 에서도 사용됩니다.