Design: WebAssembly.Instance가 이미 컴파일된 모듈을 다시 컴파일할 수 있습니까?

WebAssembly.Instance 가 때때로 재컴파일을 일으키는 것이 좋을 것입니다. 이렇게 하면 변경 불가능한 전역 변수가 생성된 코드에서 일정하게 접힐 수 있습니다. 예를 들어 Emscripten은 정적 데이터에 대한 모든 포인터를 오프셋하여 재배치 가능한 코드를 생성합니다. 오프셋은 모듈이 인스턴스화될 때 변경할 수 없는 전역 변수로 전달됩니다. WebAssembly.Instance 를 다시 컴파일할 수 있으면 생성된 코드를 특수화할 수 있습니다.

사양은 "컴파일"이 무엇인지 정의하지 않으며
구현 방식이 크게 다를 수 있으므로 그렇게 하는 것이 좋습니다.
(통역사 포함). 따라서 이에 대해 어떠한 규범적 발언도 할 수 없습니다.
어느 쪽이든. 우리가 할 수 있는 최선은
WebAssembly.Instance 은(는) "빠른" 것으로 예상됩니다.

2016년 10월 27일 03:24, Michael Bebenita [email protected]
썼다:

WebAssembly.Instance가 때때로 재컴파일을 일으키는 것이 좋을 것입니다.
이 방법으로 불변 전역 변수는 생성된 파일에서 일정하게 접힐 수 있습니다.
암호. 예를 들어 Emscripten은 모든 항목을 오프셋하여 재배치 가능한 코드를 생성합니다.
정적 데이터에 대한 포인터. 오프셋은 변경할 수 없는 전역 var로 전달됩니다.
모듈이 인스턴스화될 때. WebAssembly.Instance를 다시 컴파일할 수 있는 경우
생성된 코드를 전문화할 수 있습니다.

—
이 스레드에 가입했기 때문에 이 메시지를 받고 있습니다.
이 이메일에 직접 답장하고 GitHub에서 확인
https://github.com/WebAssembly/design/issues/838#issuecomment -256522163,
또는 스레드 음소거
https://github.com/notifications/unsubscribe-auth/AEDOO9sJPgujK3k0f6P7laYV_zaJxES5ks5q3_1LgaJpZM4Kh1gM
.

기껏해야 비규범적인 메모가 될 것이라는 데 동의했습니다.

SM에서는 현재 재컴파일하지 않도록 인스턴스화하여 개발자를 위한 예측 가능한 컴파일 비용 모델이 있도록 하려고 합니다(특히 개발자가 WebAssembly.compile 및 IDB를 사용하여 컴파일 히트를 제어할 수 있도록). . 동기 Instance 생성자 내에서 인스턴스화 시간 재컴파일은 확실히 해당 비용 모델을 깨고 주요 버벅거림으로 이어질 수 있습니다.

그러나 별도의 컴파일은 생성된 코드를 주변 매개변수로 전문화하기 위해 수행할 수 있는 다양한 최적화와 근본적으로 상충된다는 점을 인정합니다. 컴파일과 인스턴스화를 하나의 비동기 작업으로 통합하는 것은 의미가 있으며 과거에 고려했던 것입니다. 물론 단점은 이것이 명시적 캐싱을 억제한다는 것입니다( Module ). 따라서 개발자는 불쾌한 절충안을 만들어야 합니다. 일부 옵션:

• impl은 현재 FF에 있는 asm.js와 마찬가지로 암시적 콘텐츠 주소 지정 캐싱(키에 주변 매개변수를 포함할 수 있음)을 수행할 수 있습니다. 이것은 일종의 고통이며 암시적 캐시의 모든 예측 가능성/경험적 문제가 있습니다.
• 우리는 새로운 방법 (예를 들어, 새로운 만들 수 WebAssembly.Cache 당신이 바이트 코드와 인스턴스 매개 변수를 전달 API를하고 다시 얻을 Promise<Instance> .

후자는 저를 흥미롭게 하고 IDB를 사용하는 것보다 훨씬 더 나은 개발자 경험을 제공할 수 있으며 캐싱을 더욱 최적화할 수 있는 기회를 제공할 수도 있지만(캐시는 목적에 맞게 특화되어 있기 때문에) 확실히 큰 기능이며 시간이 좀 걸리고 싶습니다. 고려하다.

@rossberg-chromium 내 목적을 잘못 설명한 것 같습니다. 사양이 말하는 내용에 대해 논쟁하고 싶지 않습니다. API 아래에 숨어 있는 개발자들에게 심각한 놀라움으로 보이는 것을 지적하려고 합니다. 개발자는 .compile 의 결과가 다시 컴파일되는 것을 기대하지 않습니다. 그것은 나에게 디자인 결함처럼 보인다.

@lukewagner 는 암시적 또는 명시적 캐싱을 사용하더라도 동일한 문제가 있을 수 있습니다. 동일한 주소 공간/원점에서 얼마나 많은 WebAssembly.Memory 를 만들 수 있는지는 브라우저 제한 사항입니다. 나는 당신이 제안하는 것을 좋아하지만 문제와 직교한다고 생각합니다. 당신이 제안한 것을 내가 잘못 이해했다면 알려주십시오.

아마도 .compile 및 Module 에 Memory 가 주어질 수 있고 Instance 에는 다른 컴파일/인스턴스화에 전달할 수 있는 .memory 속성이 있습니다. ?

재컴파일 가능성을 없애려는 것이 아니라 첫 번째 컴파일 시간(또는 캐시 검색 시간)에 완벽한 정보 wrt Memory 가 있는 일반적인 관용적 API 사용을 원한다고 생각합니다. 필요한 경우 컴파일에서 경계 검사를 내보내는지 여부를 확인합니다.

@jfbastien 특정 인스턴스화 매개변수(그래서 Memory )가 제공된 암시적/명시적 캐싱을 사용하면 재컴파일이 어떻게 필요한지 알 수 없습니다.

@jfbastien 특정 인스턴스화 매개변수(그래서 Memory )가 제공된 암시적/명시적 캐싱을 사용하면 재컴파일이 어떻게 필요한지 알 수 없습니다.

다음이 있을 수 있습니다.

1. 많은 Memory 만듭니다.
2. Memory 가 너무 많기 때문에 명시적(느린) 경계 검사를 사용하여 코드를 컴파일합니다.
3. 해당 코드를 캐시합니다.
4. 페이지를 나가십시오.
5. 페이지를 다시 로드하십시오.
6. 빠른 버전을 가져오는 Memory 하나만 할당하십시오.
7. 캐시에서 가져옵니다.
8. 느린 코드 수신 Instance .

이 시점에서 재컴파일이 _필요하지 않다는 데 동의하지만 필요하지 않을 때 느린 경계 검사를 수행하는 것은 어리석은 일입니다.

내가 말했듯이: 나는 당신이 제안한 이 Cache API가 마음에 든다. 나는 그것이 WebAssembly를 더 유용하게 만든다고 생각하지만, 나는 여전히 문제가 있다고 생각한다. 😢

인스턴스화 매개변수와 바이트코드를 허용하는 향상된 캐시에 대한 제 요점입니다. 캐시된 항목이 인스턴스화 매개변수와 일치하지 않는 경우 캐시를 다시 컴파일할 수 있습니다. 따라서 단계는 다음과 같습니다.

1. 많은 Memory
2. 캐시에서 Instance 요청, 그 중 하나를 (느린) Memory
3. 느린 코드는 컴파일되고 캐시되어 Instance 로 반환됩니다.
4. 페이지를 떠나다
5. 페이지를 다시 로드
6. 하나만 할당 Memory
7. 캐시에서 Instance 요청, 빠른 Memory
8. 빠른 코드는 컴파일되고 캐시되어 Instance 로 반환됩니다.

8단계 이후에는 모든 향후 페이지 로드가 빠르거나 느린 코드로 캐시됩니다.

@lukewagner 우선, WebAssembly가 결정적 성능을 제공한다는 명시된 목표에 반하는 완화 방안을 제안하고 있습니다. 느린 것과 빠른 것의 차이는 약 20%로 마지막으로 인용되었으므로, 결정론적 성능을 목표로 하는 사양이 API 특성 때문에 바닥에 떨어뜨리면 정말 악취가 날 것입니다. 나는 프로파일-재컴파일-캐시 최적화의 필요성을 없애기 위해 사양이 이미 다른 곳에서 많은 문제를 일으키고 있기 때문에 콘텐츠 주소 지정 캐시가 있는 브라우저가 올바른 솔루션이라고 생각하지 않습니다. 예를 들어, 우리는 코드가 캐시되지 않더라도 앱이 합리적인 동작을 할 수 있도록 정확하게 컴파일을 약속합니다. 이것이 지정되는 방식으로 인해 우리 모두가 캐시 또는 기타 완화를 구현해야 하는 경우 사람들에게 합리적으로 이식 가능한 비용 모델을 제공하려는 목표에 실패할 것입니다.

나에게 문제는 바로 이것입니다. 경쟁적인 이유로 우리 모두가 효과적으로 수행해야 하는 최적화 중 하나(4GB 가상 메모리 경계 확인, 나는 4GB 해킹이라고 칭함)는 현재 사양에서 희생 없이는 수행할 수 없습니다. 다음 중 하나:

• wasm 메모리에 대해 항상 4GB의 가상 메모리를 할당하면 문제를 해결할 수 있습니다. 이렇게 하면 사람들이 작은 모듈에 WebAssembly를 사용하는 것을 권장하지 않습니다. 왜냐하면 이러한 많은 항목을 할당하면 가상 메모리 할당 제한, 가상 메모리 조각화 또는 기타 문제에 부딪히게 되기 때문입니다. 또한 많은 할당을 허용하면 ASLR과 같은 보안 완화의 효율성이 떨어질까 두렵습니다. 기존 API는 할당한 메모리를 커밋하고 실제 메모리가 허용하는 것보다 훨씬 더 많이 할당하기 전에 OOM 또는 충돌하므로 이러한 위험을 공유하지 않습니다.
• 인스턴스화 중에 불일치를 발견할 때 재컴파일을 허용하면 문제를 해결할 수 있습니다(컴파일된 코드는 4GB 해킹을 원하지만 메모리에는 가상 메모리 할당이 없습니다). 인스턴스화로 인해 메모리가 4GB 영역으로 이동한 경우에도 문제를 해결할 수 있지만 이전 요점을 참조하세요. 따라서 아마도 이런 일이 발생할 때마다 이를 발견한 브라우저의 P1 버그가 될 것입니다.

이것은 사양이 공급업체가 wasm 메모리가 할당될 때마다 4GB 예약을 허용하거나 이를 감지하기 위해 캐시/지연 컴파일/프로파일 최적화를 갖도록 수렴하도록 권장한다는 것을 의미한다고 생각합니다.

마지막으로, 나는 이것을 비규범적으로 만드는 것에 대한 요점을 이해하지 못합니다. 이것은 규범적일 수 있습니다. 왜냐하면 우리는 API가 브라우저에 어떤 종류의 메모리가 있는지 알지 못한 채 무언가를 컴파일해야 할 가능성을 배제할 수 있기 때문입니다. 나는 이것을 하는 많은 방법이 있다고 상상한다. 예를 들어 인스턴스화는 약속을 반환할 수 있고 별도의 컴파일 단계를 제거할 수 있습니다. 이것은 인스턴스화가 시간이 걸릴 수 있는 단계라는 것을 분명히 하고 클라이언트에게 이것이 컴파일을 수행하는 단계임을 강력하게 암시합니다. 이러한 API에서 컴파일러는 컴파일 대상 메모리에 4GB 해킹이 있는지 여부를 항상 알고 있습니다.

우리가 이것을 이제서야 알아차린다는 것이 슬프지만, 여러분이 이것이 더 큰 문제라고 생각하지 않는다는 것에 놀랐습니다. 내가 간과하고 있는 캐싱 이외의 완화 방법이 있습니까?

동기 부여 시나리오에서 @jfbastien 은 모듈이 빠른 메모리를 선호하도록 작성되었다고 지적했습니다. 나는 당신이 주로 특정 모듈이 원할 때 빠른 메모리 최적화를 활성화하는 것을 쫓고 있다고 가정하고 모듈이 원하지 않을 때 그것을 하지 않아도 괜찮을 것입니다. , 우선 순위를 구분하려고 애쓰는 것뿐입니다).

그렇다면 캐싱 또는 비동기 인스턴스화에 대한 이러한 대안은 다음과 같을 것입니다.

1. 모듈 작성자는 최소/최대 메모리로 4GB가 필요합니다.
2. 빠른 메모리만 허용하는 인스턴스를 생성하는 컴파일(적어도 비동기, 동기화도 가능)의 변형입니다.

"4GB 해킹" 문제와 이를 사용하는 메모리와 이를 예상하는 코드 간의 불일치에 대해 내부적으로 두 가지 버전의 코드를 내보내는 컴파일이 의미가 있습니까? (분명히 이것은 더 많은 메모리를 사용하게 되어 슬프지만 컴파일 시간이 훨씬 더 나빠지지 않기를 바랍니다. 작성자가 두 가지를 동시에 생성할 수 있을까요?)

@mtrofin 사용 하지 않으

On 2.: 여전히 개발자에게 큰 도움이 되지 않습니다. 해당 변형을 사용하고 실패하면 어떻게 됩니까?

@kripken 이중 컴파일은 좋은 생각이 아니라고 생각합니다.

@kripken 나는 이것이 우리가 이 문제에 대한 다른 해결책 없이 할 수 있는 일이라고 생각합니다.

캐주얼 브라우징의 경우 WebAssembly가 훌륭하기를 바랍니다. 멋진 일에 대해 이야기하고 URL을 보내면 클릭하고 몇 분 동안 즐겁게 지냅니다. 그것이 웹을 멋지게 만드는 것입니다. 그러나 이는 많은 컴파일이 캐시되지 않은 코드로 이루어지므로 컴파일 시간이 사용자의 배터리 수명에 큰 역할을 한다는 것을 의미합니다. 그래서, 더블 컴파일은 저를 슬프게 합니다.

@mtrofin

모듈 작성자는 최소/최대 메모리로 4GB가 필요합니다.

많은 장치에 4GB의 물리적 메모리가 없기 때문에 실제로는 실용적이지 않습니다. 또한 사양하기가 어렵습니다.

빠른 메모리만 허용하는 인스턴스를 생성하는 컴파일(적어도 비동기, 동기화도 가능)의 변형입니다.

나는 우리가 이중 컴파일을 원하지 않는다고 생각합니다.

@pizlonator 지금까지 다른 모드의 코드 생성이 필요한 디자인은 고려하지 않았습니다. 우리는 항상 64비트에 4GB 영역을 할당했고 Linux, OSX 및 Windows에서 수천 개의 메모리에 대해 성공하는 것을 관찰했습니다. 많은 소규모 라이브러리 사용 사례를 지원하기에 충분할 것으로 예상되는 사용 가능한 주소 공간의 사소한 전체 고갈을 방지하기 위해 보수적인 상한선이 있습니다. 따라서 여기서 해결하려는 새로운 제약 조건은 iOS에 4GB 할당 수를 줄일 수 있는 가상 주소 공간 제한이 있다는 것입니다.

따라서 한 가지 관찰은 4GB 해킹이 허용하는 경계 확인 제거의 많은 부분을 wasm 메모리 끝에 작은 보호 영역을 가짐으로써 피할 수 있다는 것입니다. 우리의 초기 실험은 기본 분석(루프와 관련이 없으며 동일한 기본 포인터가 있는 로드/저장에 대한 검사 제거)이 이미 경계 검사의 대략 절반을 제거할 수 있음을 보여줍니다. 그리고 아마도 이것은 더 나아질 수 있습니다. 따라서 4GB 해킹은 더 겸손하고 덜 필요한 속도 향상이 될 것입니다.

내가 이전에 가지고 있던 또 다른 아이디어는 경계 검사(가드 페이지 기반 제거 사용)를 사용하여 코드를 비관적으로 컴파일한 다음 고속 모드 메모리로 인스턴스화할 때 제거하는 것입니다. 결합하면 오버헤드는 이상적인 고속 모드 코드에 비해 상당히 작을 수 있습니다.

@lukewagner

지금까지 우리는 다른 모드의 코드 생성이 필요한 디자인을 고려하지 않았습니다. 우리는 항상 64비트에 4GB 영역을 할당했고 Linux, OSX 및 Windows에서 수천 개의 메모리에 대해 성공하는 것을 관찰했습니다. 많은 소규모 라이브러리 사용 사례를 지원하기에 충분할 것으로 예상되는 사용 가능한 주소 공간의 사소한 전체 고갈을 방지하기 위해 보수적인 총 수를 가지고 있습니다. 따라서 여기서 해결하려는 새로운 제약 조건은 iOS에 4GB 할당 수를 줄일 수 있는 가상 주소 공간 제한이 있다는 것입니다.

이것은 iOS 관련 문제가 아닙니다. 문제는 이러한 할당을 많이 허용하면 각 할당이 ASLR의 효율성을 감소시키기 때문에 보안 위험이 있다는 것입니다. 따라서 VM에는 할당하는 4GB 공간 수에 대해 매우 낮은 제한을 설정하는 옵션이 있어야 하지만 이는 대체 경로가 너무 비싸지 않아야 함을 의미합니다(즉, 다시 컴파일할 필요가 없어야 함).

할당할 4GB 메모리 수에 제한이 있습니까? 이 한계에 도달하면 무엇을 합니까? 완전히 포기하거나 인스턴스화할 때 다시 컴파일합니까?

따라서 한 가지 관찰은 4GB 해킹이 허용하는 경계 확인 제거의 많은 부분을 wasm 메모리 끝에 작은 보호 영역을 가짐으로써 피할 수 있다는 것입니다. 우리의 초기 실험은 기본 분석(루프와 관련이 없으며 동일한 기본 포인터가 있는 로드/저장에 대한 검사 제거)이 이미 경계 검사의 대략 절반을 제거할 수 있음을 보여줍니다. 그리고 아마도 이것은 더 나아질 수 있습니다. 따라서 4GB 해킹은 더 겸손하고 덜 필요한 속도 향상이 될 것입니다.

분석을 통해 더 많은 검사를 제거할 수 있다는 점에는 동의하지만 최고의 성능을 원한다면 4GB 해킹을 선택하는 것이 좋습니다. 모두가 최고 성능을 원하고 보안 문제, 리소스 문제, 예기치 않은 재컴파일도 일으키지 않고 최고 성능을 얻을 수 있도록 하면 좋을 것 같아요.

내가 이전에 가지고 있던 또 다른 아이디어는 경계 검사(가드 페이지 기반 제거 사용)를 사용하여 코드를 비관적으로 컴파일한 다음 고속 모드 메모리로 인스턴스화할 때 제거하는 것입니다. 결합하면 오버헤드는 이상적인 고속 모드 코드에 비해 상당히 작을 수 있습니다.

경계 검사가 있는 코드는 메모리 크기에 대한 레지스터를 고정하고 메모리 기반에 대한 레지스터를 고정하는 것이 가장 좋습니다.

4GB 해킹을 사용하는 코드는 메모리 기반 레지스터만 고정하면 됩니다.

따라서 이것은 훌륭한 솔루션이 아닙니다.

사양과 구현을 랭글링해야 하는 번거로움 외에 컴파일과 인스턴스화를 약속된 하나의 작업으로 결합하는 것의 단점은 무엇입니까?

문제는 이러한 할당을 많이 허용하는 경우 각각의 이러한 할당 때문에 보안 위험이 발생한다는 것입니다.
할당은 ASLR의 효율성을 감소시킵니다.

저는 ASLR에 대한 전문가는 아니지만 iiuc, 비록 우리가 보수적인 경계를 가지고 있지 않더라도(즉, 커널이 해당 수에 도달하여 mmap 실패할 때까지 계속 할당하도록 허용한 경우) address-ranges max), 전체 47비트 주소 지정 가능 공간의 작은 부분만 사용되므로 코드 배치는 이 47비트 공간에서 계속 매우 무작위적입니다. IIUC, ASLR 코드 배치도 완전히 무작위가 아닙니다. 무엇이 있을지 예측하기 어렵게 만들기에 충분합니다.

할당할 4GB 메모리 수에 제한이 있습니까? 너 뭐하니
이 한계에 도달했을 때 - 완전히 포기할 것인가, 아니면 인스턴스화할 때 재컴파일할 것인가?

글쎄요, asm.js 시절부터 1000개밖에 안 됐거든요. 그러면 메모리 할당이 그냥 던집니다. 아마도 우리는 이것을 부딪쳐야 할 것입니다. 그러나 동일한 프로세스를 공유하는 많은 슈퍼 모듈화 앱(각각 많은 개별 wasm 모듈 포함)이 있더라도 너무 많은 것이 필요할 것이라고 상상할 수 없습니다. Memory 는 앱이 자연스럽게 수천 개를 만들고 싶어하지 않는다는 점에서 기존의 ArrayBuffer 와 다르다고 생각합니다.

사양과 구현을 랭글링해야 하는 번거로움 외에 단점은 무엇입니까?
컴파일과 인스턴스화를 하나의 약속된 작업으로 결합하는 것?

위에서 언급했듯이 Promise<Instance> eval(bytecode, importObj) API를 추가하는 것은 괜찮지만 이제 개발자는 일부 플랫폼에서 성능 향상과 컴파일된 코드를 캐시할 수 있는 것 사이에서 선택해야 하기 때문에 어려운 위치에 놓입니다. 모든 플랫폼. 캐싱과 통합되는 솔루션이 필요한 것 같으며 위에서 명시적인 Cache API로 브레인스토밍을 했습니다.

새로운 아이디어: new Instance 의 비동기 버전을 추가하고 WebAssembly.instantiate 와 같이 WebAssembly.compile 와 같이 모든 사람이 비동기 버전을 사용해야 한다고 하면 어떻게 될까요? 이것은 패치를 사용하는 경우 인스턴스화에 몇 ms가 걸릴 수 있기 때문에 _어쨌든_ 고려했던 것입니다. 그런 다음 사양에서 엔진이 compile 또는 instantiate 에서 값비싼 작업을 수행할 수 있다고 말합니다(엔진이 지연 유효성 검사/컴파일을 수행하는 경우 둘 다!).

compile d Module 가 IDB에 저장되어 있을 때 무엇을 해야 하는지에 대한 질문은 여전히 ​​남지만, 여러 codegen 모드가 _어쨌든_ 있을 때 이는 어려운 질문일 뿐입니다. 한 가지 아이디어는 IDB에 저장되거나 IDB에서 검색된 Module 가 IDB 항목에 대한 핸들을 잡고 이 항목에 새 컴파일된 코드를 추가한다는 것입니다. 그런 식으로 IDB 항목은 모듈의 하나 이상의 컴파일된 버전을 느리게 축적하고 인스턴스화 중에 필요한 것을 제공할 수 있습니다.

IDB 부분은 약간 더 많은 작업이 필요하지만 성능 면에서 이상에 가깝습니다. 어떻게 생각하십니까?

async instantiate 추가하는 것이 합리적이라고 생각하지만 compile Memory 매개변수도 추가합니다. instantiate 다른 메모리를 전달하면 다시 컴파일할 수 있습니다. 그렇지 않으면 컴파일할 때 이미 메모리를 "바인딩"한 것입니다.

나는 아직 완전한 형태의 의견을 가질 만큼 캐싱에 대해 생각하지 않았습니다.

@lukewagner

나는 ASLR에 대한 전문가는 아니지만 iiuc, 비록 우리가 보수적인 경계를 갖고 있지 않더라도(즉, 커널이 최대 주소 범위 수에 도달했기 때문에 mmap이 실패할 때까지 계속 할당하도록 허용한 경우) , 전체 47비트 주소 지정 가능 공간의 작은 부분만 사용되므로 코드 배치는 이 47비트 공간에서 계속해서 매우 무작위적입니다. IIUC, ASLR 코드 배치도 완전히 무작위가 아닙니다. 무엇이 있을지 예측하기 어렵게 만들기에 충분합니다.

ASLR은 코드와 데이터 모두에 영향을 미칩니다. 요점은 공격자가 데이터 구조에 대한 포인터를 추적하지 않고 데이터 구조에 침입하는 데 더 많은 비용이 들게 하는 것입니다. 공격자가 메모리를 고갈시킬 수 있다면 확실히 더 많은 영향력을 행사할 수 있습니다.

글쎄요, asm.js 시절부터 1000개밖에 안 됐거든요. 그러면 메모리 할당이 그냥 던집니다. 아마도 우리는 이것을 부딪쳐야 할 것입니다. 그러나 동일한 프로세스를 공유하는 많은 슈퍼 모듈화 앱(각각 많은 개별 wasm 모듈 포함)이 있더라도 너무 많은 것이 필요할 것이라고 상상할 수 없습니다. 메모리는 앱이 자연스럽게 수천 개의 생성을 원하지 않는다는 점에서 기존의 일반 ArrayBuffer와 다릅니다.

1000은 합리적인 한계처럼 보입니다. 보안 담당자에게 물어보겠습니다.

위에서 언급했듯이 Promise를 추가하면eval(bytecode, importObj) API는 괜찮지만 이제 개발자는 일부 플랫폼에서 성능 향상과 모든 플랫폼에서 컴파일된 코드를 캐시할 수 있는 것 중 하나를 선택해야 하기 때문에 개발자를 어려운 위치에 둡니다. 캐싱과 통합되는 솔루션이 필요한 것 같으며 위에서 명시적 Cache API를 사용하여 브레인스토밍했습니다.

오른쪽. 그러한 API가 작동하도록 만들 수 있는 몇 가지 방법을 볼 수 있습니다. 싸구려지만 실용적인 API는 eval을 오버로드하는 것입니다.

1. instancePromise = 평가(바이트 코드, importObj)
2. instancePromise = 평가(모듈, importObj)

Instance에는 getter가 있습니다.

모듈 = instance.module

여기서 모듈은 구조를 복제할 수 있습니다.

이것에 대해서 어떻게 생각하니?

새로운 아이디어: WebAssembly.instantiate와 같이 새 인스턴스의 비동기 버전을 추가하고 WebAssembly.compile과 마찬가지로 모든 사람이 비동기 버전을 사용해야 한다고 가정하면 어떻게 될까요? 이것은 패치를 사용하는 경우 인스턴스화에 몇 ms가 걸릴 수 있기 때문에 어쨌든 고려한 것입니다. 그런 다음 사양에서 엔진이 컴파일 또는 인스턴스화에서 비용이 많이 드는 작업을 수행할 수 있다고 말합니다(엔진이 지연 유효성 검사/컴파일을 수행하는 경우 둘 다!).

컴파일된 모듈이 IDB에 저장될 때 무엇을 해야 하는지에 대한 질문은 여전히 ​​남아 있지만 어쨌든 여러 codegen 모드가 있는 경우 어려운 질문일 뿐입니다. 한 가지 아이디어는 IDB에 저장되거나 IDB에서 검색된 모듈이 IDB 항목에 대한 핸들을 잡고 이 항목에 새 컴파일된 코드를 추가한다는 것입니다. 그런 식으로 IDB 항목은 모듈의 하나 이상의 컴파일된 버전을 느리게 축적하고 인스턴스화 중에 필요한 것을 제공할 수 있습니다.

IDB 부분은 약간 더 많은 작업이 필요하지만 성능 면에서 이상에 가깝습니다. 어떻게 생각하십니까?

흥미롭다. 위의 내 아이디어와 관련하여 :

장점: 당신은 지금 우리가 말하는 것과 개념적으로 유사한 이해하기 쉬운 추상화입니다.
단점: 당신의 것은 사용자가 하는 일과 내 제안이 허용하는 만큼 엔진이 하는 일 사이에 많은 시너지 효과를 가져오지 않습니다.

귀하의 제안이 사용자에게 저만큼 많은 제어 권한을 부여하지 않는 세 가지 영역이 있습니다.

1. 비용이 많이 드는 작업은 두 곳 중 한 곳에서 발생할 수 있으므로 사용자는 둘 중 하나가 비용이 많이 드는 계획을 세워야 합니다. 웹 콘텐츠 중 하나가 비싸면 제대로 작동하지 않는 웹 콘텐츠를 갖게 될 것입니다. 내 제안에는 비용이 많이 드는 일이 발생하여 구현 간의 균일성이 향상되는 한 곳이 있습니다.
2. 모든 버전의 컴파일된 코드가 캐시되도록 명확하게 보장된 경로는 없습니다. 반면에 API를 통해 모듈을 스레딩하는 것은 사용자가 캐시를 관리할 수 있도록 하면서 VM이 매번 더 많은 항목으로 모듈을 구축할 수 있음을 의미합니다. 따라서 처음으로 4GB를 수행하면 이것이 캐시되지만 두 번째로 4GB를 수행하지 못하면 잠재적으로 둘 다 캐시할 수 있습니다(사용자가 모든 컴파일 후에 instance.module을 캐시하는 경우).
3. 브라우저의 비정상적인 코너 케이스 또는 기타 문제로 인해 구성표에서 이중 컴파일이 발생할 수 있습니다. 컴파일 단계에서 한 가지를 컴파일하지만 인스턴스화 단계에서 다른 것이 필요하다는 것을 깨닫기 때문입니다. 내 버전에는 이중 컴파일이 필요하지 않습니다.

그래서 저는 제 것이 더 좋습니다. 그렇긴 하지만, 당신의 제안은 진보적이라고 생각하기 때문에 확실히 나에게 좋게 들립니다.

이 문제는 조각화로 인해
메모리(4GB + 최대 지원 오프셋 또는 8GB)가 실패합니다. 만약
아마도 1% 미만일 것입니다. 그러면 완전히 비합리적이지 않을 수도 있습니다.
OOM 상황입니다.

사용자가 웹을 탐색하고 많은 것을 사용하는 시나리오에서
작은 WASM 모듈이 연속적으로 빠르게 연결되며 아마도 모두 라이브 상태가 아닐 것입니다.
한 번. 이 경우 예약된 4GB 청크의 작은 캐시가
문제.

또 다른 가능한 전략은 다음을 사용하여 한 버전의 코드를 생성하는 것입니다.
경계를 확인하고 빠른 메모리를 사용할 수 있는 경우 경계를 덮어씁니다.
nops로 확인합니다. 추악하지만, 그것은 지옥보다 훨씬 빠릅니다.
다시 컴파일하고 두 컴파일보다 적은 공간을 차지합니다.

2016년 10월 27일 목요일 오후 9:03, pizlonator [email protected]
썼다:

@mtrofin https://github.com/mtrofin

모듈 작성자는 최소/최대 메모리로 4GB가 필요합니다.

많은 장치에 4GB의 물리적 메모리가 없기 때문에 실제로는 실용적이지 않습니다.
메모리. 또한 사양하기가 어렵습니다.

다음을 생성하는 컴파일의 변형(적어도 비동기, 동기화도 가능)
빠른 메모리만 허용하는 인스턴스.

나는 우리가 이중 컴파일을 원하지 않는다고 생각합니다.

—
이 스레드에 가입했기 때문에 이 메시지를 받고 있습니다.
이 이메일에 직접 답장하고 GitHub에서 확인
https://github.com/WebAssembly/design/issues/838#issuecomment -256738329,
또는 스레드 음소거
https://github.com/notifications/unsubscribe-auth/ALnq1F6CYUaq0unla0H6RYivUC8jfxIAks5q4PWIgaJpZM4Kh1gM
.

ASLR 뿐만 아니라 pagetable/allocator/etc 오염이기도 합니다. 우리 모두는 보안 담당자 _뿐만 아니라_ 커널/시스템 담당자와 이야기해야 합니다. 또는 각 엔진이 "빠른" Memory 에 부과하는 제한에 대해 개발자에게 미리 알리고 API에서 이를 관용적으로 만들어서 잘못 사용하기 어렵게 만들 수 있습니다.

nop 또는 이중 컴파일과 같이 사용할 수 있는 모든 목발이 있지만 왜 목발이 있습니까?

@jfbastien PROT_NONE 메모리 비용이 페이지 테이블 항목이라고 생각하지 않습니다. 페이지 테이블이 느리게 채워지는 매핑을 보유하는 별도의 데이터 구조가 있다고 생각합니다.

@pizlonator 저는 그 아이디어가 마음에 Module 무시할 수 있다면 더 간결하고 가르치기 쉽습니다. 이것은 또한 가장 좋은 API를 비동기 API로 만들어 동기화 API 사용을 방해하는 @s3ththompson 의 우려를 해결할 수 있습니다.

그러나 WebAssembly.compile 및 Module 생성자를 제거해서는 안 된다고 생각합니다. "코드 서버"(IDB + postMessage 를 통해 원본 간 코드 캐싱 제공)가 있는 시나리오를 상상하고 있습니다. new Module 통해)을 원하는 동일한 모서리 경우에 대해 new Instance 를 유지해야 합니다.

따라서 이에 동의하면 언급한 두 개의 WebAssembly.eval 오버로드에 대한 순전히 추가 제안으로 요약됩니다. 예?

하나 팅겨, 비록 : 내가 생각하는 우리는이 안되는 module 게터이는 필요하기 때문에 Instance 의 수명 주변에 일부 내부 데이터를 유지하기 위해 (즉, 바이트 코드.) Instance ; 지금 Module 는 일반적으로 인스턴스화 직후에 GC될 수 있습니다. 이것은 데이터 속성(사용자가 제거할 수 있지만 잊어버릴 수 있음) 또는 {instance, module} 쌍을 반환하는 eval 의 세 번째 버전을 제안합니다.

일반적인 모놀리식 앱의 권장 사례로 비동기 1단계 API를 사용하는 것이 권장 패턴으로 의미가 있습니다.

new Module + new Instance가 다루는 모든 동기화(인라인 컴파일) 사례가 모두 유용 하다는
또한 동기화 인스턴스화 기능이 있는 백그라운드 컴파일(비동기) 서버도 유용해 보입니다.

제안된 두 가지 평가 변형을 추가하는 것이 이를 소개하는 좋은 방법인 것 같습니다.

그러나 나는 그 이름이 마음에 들지 않습니다. 왜냐하면 그것은 (보안) 사람들의 마음과 js eval(한 면에서는 비슷하지만 범위 캡처 측면에서는 그렇지 않음)과 융합될 것이기 때문입니다.
WebAssembly.instantiate는 어떻습니까?

하, 좋은 지적입니다. eval에는 약간의 담당자가 있습니다. +1 ~ WebAssembly.instantiate .

비동기 인스턴스화를 사용할 때 개발자에 대한 지침은 무엇입니까?

@mtrofin 특정 용도와 독립적으로 Module 컴파일해야 하는 특별한 코드 공유/로딩 체계가 없는 한 기본적으로 WebAssembly.instantiate 를 사용합니다.

@lukewagner 합리적인 것 같습니다.

하, 좋은 지적입니다. eval에는 약간의 담당자가 있습니다. WebAssembly.instantiate에 +1.

동의.

따라서 이에 동의하면 언급한 두 개의 WebAssembly.eval 오버로드에 대한 순전히 부가적인 제안으로 요약됩니다. 예?

그게 무슨 소리야.

모듈 getter가 없어야 한다고 생각합니다. 이렇게 하려면 Instance가 Instance의 수명 동안 일부 내부 데이터(즉, 바이트코드)를 유지해야 하기 때문입니다. 바로 지금 모듈은 일반적으로 인스턴스화 직후에 GC될 수 있습니다. 이것은 데이터 속성(사용자가 제거할 수 있지만 잊어버릴 수 있음) 또는 {instance, module} 쌍을 반환하는 세 번째 버전의 eval을 제안합니다.

확실히 데이터 속성이 더 나은 것처럼 느껴집니다. 또는 WebAssembly.instantiate가 항상 인스턴스, 모듈 쌍을 반환하도록 합니다.

이것이 맞습니까? fastmemory 모듈 변형을 얻기 위해 WebAssembly.instantiate 한다고 가정하십시오. 이제 모듈을 가져와 구조 복제합니다. 이제 이 모듈은 fastmemory를 지원하는 Memory -es로 인스턴스화해야 합니다.

@pizlonator 예, 여러 가지 방법으로 자전거를 탈 수 있습니다. 나는 실수로 사용하지 않은 Module 동반하는 사람들이 줄어들기 때문에 쌍을 반환하는 것이 더 낫다고 생각합니다.

@mtrofin 재 컴파일은 instantiate 호출에서 Module 를 뽑고 새 가져오기로 instantiate 를 뽑을 때 여전히 필요할 수 있습니다. 이 API 추가의 요점은 일반적인 경우가 아니며 근본적으로 필요할 때만 발생한다는 것입니다(즉, 두 종류의 메모리에 액세스하는 1개의 모듈이 있는 경우).

이 스레드가 길어지고 수렴되는 것처럼 보이지만 100% 확신하려면 다른 사용자가 작성할 것으로 예상되는 코드를 작성해야 합니다.

1. 단일 모듈의 비동기 인스턴스화.
2. 다른 모듈과 메모리를 공유하는 모듈의 비동기 인스턴스화.
3. 단일 모듈의 동기식 인스턴스화(동기식 다중 모듈이 유용하지 않다고 생각합니까?).
4. 이 모든 것에 대한 캐싱(메모리를 사용하여 캐시에 저장하고 검색 및 인스턴스화).
5. 단일 .wasm 모듈의 업데이트 및 다른 모듈의 캐시된 로드.

다른 건 없나요? @lukewagner 가 내가 완전히 이해하지 못하는 수입품에 대한 아이디어를 가지고 있는 것

즉, 이 모듈의 후속 사용은 비동기식으로 인스턴스화해야 하며, 그렇지 않으면 놀랍게도 긴 동기식 인스턴스화로 UI 스레드를 차단할 위험이 있습니다.

@jfbastien 저는 개발자가 작성하기를 기대하는 각 스니펫, 특정 경로로 이동하도록 동기를 부여하는 요소, 개발자가 결정을 내리기 위해 사용할 수 있어야 하는 정보를 이해하고 싶습니다.

@mtrofin 맞습니다. Module m 주어지면 비동기식인 WebAssembly.instantiate(m) 를 호출할 것입니다. new Instance(m) _할 수 있고 비용이 많이 들 수 있지만 new Module(m) 와 다르지 않습니다.

@jfbastien "비동기 인스턴스화"라고 말할 때 "비동기 컴파일 및 인스턴스화"를 의미한다고 가정하면 다음은 짧은 버전입니다.

1. WebAssembly.instantiate(bytecode, imports)
2. WebAssembly.instantiate(bytecode, imports) , 여기서 imports 는 공유 메모리를 포함합니다.
3. new Instance(new Module(bytecode), imports)
4. 모든 경우에 당신이 얻을 수 Module 당신에게 다음, put 있다는에서 IDBObjectStore . 나중에 get a Module m 다시 WebAssembly.instantiate(m, imports) 전화를 겁니다.
5. 당신에게 : 아무것도 정말 여기에 특별한 WebAssembly.instantiate 바이트 코드에서 하나 개의 모듈 및 instantiate 로부터 나머지 Module IDB에서 가져온들.

동기화 컴파일을 사용할 수 있다고 생각되면 동기화 인스턴스화를 사용하고 비동기 컴파일을 사용해야 한다고 생각되면 비동기 인스턴스화를 사용하는 것이 좋습니까?

그 외에도 개발자가 더 복잡한 시스템, 즉 우리가 계획 중인 최적화를 가능하게 하는 더 많은 선택에 직면하게 될까봐 걱정됩니다. 그리고 개발자가 절충점을 만드는 데 사용할 수 있는 올바른 정보가 있는지 확신할 수 없습니다. 개발자의 관점에서 생각해보면 그들이 신경쓰고 편안하게 표현할 수 있는 작은 걱정거리가 있습니까? 우리는 개발자가 "정확한 실패 지점을 희생하여 최적화"하는 것에 대해 이야기했습니다(이것은 경계 확인을 다시 끌어올리는 것이었습니다). 대안이 "최적화" 플래그가 될까요?

@mtrofin 개발자가 작성하거나 툴체인에서 생성한 WebAssembly.instantiate 입니다. 특별한 "나는 wasm에서 JIT를 작성 중입니다"에 대해서만 동기화 API를 사용하고 일부 코드 공유 시스템을 작성하는 경우 WebAssembly.compile 대해서만 동기화 API를 사용하므로 "시작하기" 튜토리얼이 WebAssembly.instantiate 독점적으로 다룰 것이라고 생각합니다

@lukewagner 위의 #3 new Module()에 가져오기를 추가했습니다. WebAssembly.compile에 추가하는 것은 좋은 생각이며 가능성을 완성한다고 생각합니다.
그렇게하면 컴파일 타임에 메모리에 대해 힌트를 얻을 수 있습니다.
나중에 다른 가져오기로, 특히 동기적으로 다시 인스턴스화하면 딸꾹질이 발생할 수 있습니다.

변경 사항 요약 (내가 명확하기 때문에) :

• WebAssembly.instantiate(bytes, imports) 추가는 {instance:, module:}의 약속을 반환합니다.
• WebAssembly.instantiate(module, imports) 추가는 {instance:, module:}의 약속을 반환합니다.
• 새 Module(bytes , imports )로 변경하면 모듈이 반환됩니다.
• WebAssembly.compile(bytes , imports ) 변경은 인스턴스의 약속을 반환합니다.

컴파일에서 가져오기가 인스턴스화되면 인스턴스화 속도가 빨라질 것이라는 예상을 어딘가에 명시하십시오.

어떻게 생각하십니까?

이런, 가져오기를 Instance 인수로 넣으려고 했습니다. Module 또는 compile 필요하다고 확신하지 못합니다. [편집: 가지고 있다면 instantiate 전화를 걸기 때문입니다.]

즉, 종단 간 비동기의 경우 4GB 해킹 메모리에 바인딩되지만 JITed 필터 커널 또는 백그라운드 컴파일 항목에 대해서는 바인딩되지 않는다는 것을 알 수 있습니다. 떨어져 인스턴스)?

컴파일 및 인스턴스화의 비동기 쌍에 대한 지침에 초점을 맞추는 데 +1 - 메시지를 단순하게 만들고 개발자로부터 결정 문제의 복잡성을 숨깁니다.

네, 저는 우리 모두가 사람들에게 다음을 지적한다는 데 동의한다고 생각합니다.
처음으로:
WebAssembly.instantiate(bytes, imports) -> {module, instance}의 약속(indexeddb에 대한 캐시 모듈)
두번째:
WebAssembly.instantiate(module, imports) -> {module, instance}의 약속

그것이 주요 패턴이라는 것에 대한 이의가 있습니까?

컴파일/새 모듈에 대한 가져오기에 대해 고민하고 있습니다. 유용한 힌트가 될 것 같습니다.
그러나 나는 그것을 가능성으로 언급하고 Post-MVP에 해당 arg(선택 사항일 수 있음)를 추가하는 것을 연기할 수 있습니다.

생각?

@mtrofin (기술적으로는 instantiate 입니다.)

@lukewagner ( @mtrofin이 의미했던 것 같아요)

@lukewagner , @flagxor OK, 하지만 우리는 비동기 컴파일 API를 유지하고 있습니다. 맞죠?

이 시나리오는 어떻습니까? 수많은 플러그인이 포함된 PhotoShop과 같은 응용 프로그램을 얻을 수 있습니다. 각 플러그인은 wasm 모듈입니다. 메인 앱을 시작하고 fastmemory를 트리거하는 마법의 메모리 크기를 할당합니다(이 시나리오에서는 앱 하나, 메모리 부족).

여러 플러그인을 병렬로 컴파일하고 일부 작업자를 실행하여 이를 수행하려고 합니다. 당신은 당신이 사용할 실제 메모리를 그 컴파일을 전달할 수 없습니다(맞습니까?). 따라서 기본값에 따라 플러그인에 대한 느린 메모리 컴파일이 발생하고 플러그인이 앱에 연결될 때 fastmemory에 대한 비용이 많이 드는 비동기 재컴파일이 뒤따릅니다.

이 시나리오를 구입하면 일부 메모리 설명자(실제 지원 메모리 없이 명확하게)를 컴파일 API에 전달하는 데 가치가 있을 수 있다고 생각합니다.

예, Memory 를 컴파일에 전달할 수 있어야 합니다(심지어 권장됨).

@mtrofin 맞습니다. 고급 용도의 경우 compile 입니다. 플러그인 예제는 Memory 가 있지만 _컴파일_ 하고 _그리고_ 하지만 인스턴스화(아직)는 원하지 않는 유효한 경우라고 생각합니다.

@pizlonator Btw, "프로세스당 1000개 이상의 4GB 맵이 있는 경우 던지기" 해킹이 ASLR/보안 문제를 해결하기에 충분하다고 가정하고 이전에 묻고 싶었습니다. 가상 주소 할당량 제한? 없었다면 고급 사용자를 위한 성능 고려 사항도 아니었다면 확실히 좋았을 것입니다. (물론 instantiate API는 우리가 언급한 다른 이유로 추가하는 데 유용해 보입니다.)

또한 2의 거듭제곱에 스필 영역을 더한 메모리 크기의 이점을 얻을 수 있는 응용 프로그램이 있습니다. 여기서 응용 프로그램은 이미 포인터를 마스크하여 태깅을 제거하므로 경계 검사를 피하기 위해 상위 비트를 마스킹할 수 있습니다. 이러한 응용 프로그램은 마스킹에 사용되는 전역 상수를 수정하거나 wasm으로 압축을 푸는 동안 적절한 상수를 베이킹하여 컴파일 전에 받을 수 있는 메모리 할당 크기에 대해 추론해야 합니다.

또한 일부 런타임에서 활용하기를 원하는 0에서 버퍼 최적화가 있으며 프로세스당 하나의 버퍼만 있을 것입니다.

또한 애플리케이션을 컴파일하기 전에 필요한 메모리와 사용 가능한 메모리에 대해 추론할 수 있다면 플랫폼을 보다 사용자 친화적으로 만들 수 있습니다. 예를 들어, 브라우저나 앱이 사용자에게 애플리케이션을 실행하거나 성능 저하 없이 실행하려면 일부 탭을 닫아야 함을 알릴 수 있습니다.

웹 브라우저는 사용자를 위한 옵션인 전용 앱 모드를 원할 수 있습니다. 이 모드에서는 제한된 장치에서 실행되고 하나의 응용 프로그램을 제대로 실행하기 위해 얻을 수 있는 모든 메모리와 성능이 필요할 수 있습니다. 이를 위해서는 요구 사항에 대해 조기에 추론할 수 있어야 합니다.

메모리는 컴파일 전에 할당할 필요가 없으며 합리적으로 예약해야 합니다. 제한된 장치에서 컴파일만으로도 많은 메모리를 사용할 수 있으므로 큰 VM 할당도 쇼 스토퍼가 될 수 있습니다.

이것은 새로운 문제가 아니며 수년 동안 논의되어 왔습니다. 메모리 자원 관리가 필요하며 코드 생성과 함께 조정되어야 합니다.

@lukewagner 내 생각에 그렇게 생각합니다. 왜냐하면 우리가 1000개의 모듈로 제한한다면 허용 오차가 충분히 크지 않을까 걱정할 것이기 때문입니다.

• 이 한도를 낮추기 위해 필요한 공격이 부상하는 것에 대해 걱정할 것입니다.
• 사용 가능한 가상 주소 공간의 양을 줄이는 스택의 다른 곳에서 최적화에 대해 걱정할 것입니다. 그러면 천장이 충분히 낮은지 여부를 재평가해야 합니다.
• 나는 의도적으로 1000개의 모듈을 만드는 프로그래밍 스타일을 방지하는 것에 대해 걱정할 것입니다. 예를 들어, 대부분의 JavaScriptCore 프레임워크 클라이언트가 VM을 만들고 약간의 작업을 수행한 다음 이를 제거한다는 것을 알고 있습니다. WebAssembly가 JSC가 Objective-C에서 가져온 것과 같은 방식으로 JS에서 사용되는 경우 64비트 시스템에서 작동하도록 하려면 GC가 1000개의 메모리를 할당하는 경우(각각이 작더라도) 알아야 합니다. 1000개의 메모리에 도달할 수 없다는 이유로 다음 할당이 성공해야 하는 경우의 GC입니다. 이미 10개의 4GB 핵 메모리가 라이브 상태인 후 비 4GB 핵 메모리를 할당하는 기능은 GC가 휴리스틱을 크게 변경할 필요가 없다는 것을 의미합니다. instanceiate->run->die 루프에서 1001번째 모듈을 할당할 때 GC를 수행할 필요가 없습니다. 이것은 작은 메모리를 사용하는 패턴에 이점이 될 것입니다. 1MB 미만이면 1000개를 갖는 것이 합리적입니다. 나는 사람들이 64KB에서 유용한 일을 하는 것을 상상할 수 있습니다.
• 나는 이것이 다른 JavaScript 컨텍스트에 덜 유용하지 않을까 걱정할 것입니다. JSC C API 및 Objective-C API 클라이언트가 JS 코드에서 WebAssembly API에 액세스할 수 있도록 문을 열어두고 싶습니다. 이러한 클라이언트는 우리가 할당하는 4GB 메모리 수에 대한 작은 제한을 선호할 것입니다. 그러한 컨텍스트에서 해당 할당량을 구성할 수 있도록 하는 것도 좋습니다.

개선된 API를 통해 메모리 수에 인위적인 상한선이 필요하거나 재컴파일해야 하는 필요 또는 기타 바람직하지 않은 일을 제거할 수 있다는 점이 마음에 듭니다. 나는 허용 오차가 매우 크지 않는 한 인공 천장을 좋아하지 않으며 여기에서는 그렇지 않다고 생각합니다.

@pizlonator 충분히 공정하고 더 깨끗하고 간단한 API이므로 추가하는 것이 좋다고 생각합니다.

귀하가 언급한 항목에 대해 관심이 없는 이유는 다음과 같습니다(현재).

• 한도를 높여야 할 수도 있습니다. 그건 쉽습니다.
• 합당한 제한이 무엇이든 간에 총 64비트 주소 공간의 작은 부분만 사용되므로 공격 벡터가 무엇인지 알지 못합니다. 결정된 콘텐츠는 자체적으로 OOM할 수 있는 여러 가지 방법이 있습니다.
• 우리는 예약 크기에 상응하는 GC 휴리스틱을 범하고 Memory s를 휘젓는 것은 더 공격적인 GC로 이어집니다. 더 많은 GC는 좋지 않지만 이것이 일반적인 패턴인지 확신할 수 없습니다.

그러나 우리가 미래에 무엇을 보게 될지 누가 알 수 있습니까? 따라서 지금 내장된 유연성을 갖는 것이 유용하다고 생각합니다.

js API(특히 아키텍처/플랫폼별 세부사항)에서 너무 많은 구현 세부사항을 표면화하려고 하는 것은 나쁜 생각이라고 생각합니다. 빠른 메모리에 대한 자체 내부 제한을 구현하는 것으로 충분해야 한다고 생각합니다.

비동기 인스턴스화 기능을 사용하는 것이 합리적으로 보이지만 컴파일러 힌트를 제공하는 데 사용하려면 다른 것을 사용해야 한다고 생각합니다. 예를 들어, 싱글톤 최적화, 많은 인스턴스 최적화, 로드 시간 최적화, 예측 가능한 성능 최적화 등을 요청하는 플래그 섹션을 갖도록 모듈을 확장할 수 있습니다. 물론 (있는 경우) 엔진이 하는 일은 전적으로 구현에 따라 다릅니다. 그러나 개발자에게 방향을 돌릴 수 있는 손잡이를 제공하고 경쟁은 브라우저 공급업체를 정직하게 유지합니다.

2016년 10월 28일 금요일 오전 2시 15분, JF Bastien [email protected]
썼다:

예, 메모리를
편집.

나는 그것이 오히려 반대에 찬성하여 낙담해야한다고 생각합니다
메모리 가져오기/내보내기. 결국 모듈을 가져오지 않으면
메모리를 내보내거나 컴파일할 때 메모리를 예약할 수 있습니다. 우리 알아
일부는 복잡한 모듈을 효율적으로 처리할 수 있기를 원합니다.
애플리케이션은 하고 싶어하지만 모놀리식 WASM 앱은
우리가 예상하는 것보다 더 일반적입니다. 내가 여기 소수일 수도 있지만
동적 바인딩이 적은 모듈을 더 적게 보고 싶습니다.

—

당신이 댓글을 달았기 때문에 이것을 받는 것입니다.
이 이메일에 직접 답장하고 GitHub에서 확인
https://github.com/WebAssembly/design/issues/838#issuecomment -256805006,
또는 스레드 음소거
https://github.com/notifications/unsubscribe-auth/ALnq1KXrUWaegRZwEhznmT1YcyI33IN9ks5q4T6TgaJpZM4Kh1gM
.

전적으로 동의합니다. 모놀리식 앱이 최소한 mvp 이후 몇 년 동안은 주요 사용 사례가 될 것이라고 생각합니다. 수만 개의 모듈이 로드되었을 때 무슨 일이 일어날지 걱정하는 것은 아직 존재하지 않는 wasm 생태계에 대해 많은 것을 가정하는 것입니다.

그렇다면 이 문제를 해결하기 위해 해야 할 일은 무엇입니까? 한 가지는 내가 할 수 있는 http://webassembly.org/getting-started/js-api 를 업데이트하는 것입니다. 또 다른 것은 binaryen이 기본적으로 이것을 방출하는 것입니다(좋은 @kripken?). @titzer Canary는 WebAssembly.instantiate 구현합니까?

다른 건 없나요?

@lukewagner : 당신이 무엇을 묻고 있는지 확실하지 않습니다. 이 문제에 대한 논의는 매우 깁니다. 여기에 제안된 새로운 약속 기반 API 중 하나를 사용하는 데 사용하는 현재 동기화 WebAssembly.Instance API에서 바이너리를 변경하시겠습니까? 그것이 필요합니까? 우리는 이전 방식을 제거하고 있습니까?

@kripken 맞습니다. WebAssembly.instantiate 사용으로 전환합니다. 우리는 이전 방법을 제거하지 않지만 새 방법이 더 효율적이며 기본적으로 사용됩니다.

HTML을 생성할 때 promise 기반 API를 사용할 수 있지만 많은 사용자가 JS를 생성하고 자동으로 비동기 단계를 추가하는 것은 쉽지 않습니다. 우리는 사람들을 위해 이것을 문서화할 수 있습니다. 하지만 모든 브라우저에 이 기능이 탑재된 후에만 이 모든 작업을 수행해야 한다고 생각합니다.

@kripken 내가 이해했는지 잘 모르겠습니다. 현재 접근 방식은 비동기 API를 전혀 사용하지 않는 것입니까?

예 . 비동기 항목을 추가하려면 이 문제 를 참조하세요.

@kripken 노드에는 작동하는 약속이 있을 것입니다. 셸에도 약속 대기열을 명시적으로 비우는 방법이 있습니다(따라서 모든 해결을 동기적으로 실행). SM에서는 drainJobQueue() 이고 V8에서는 %RunMicroTasks() 라고 들었습니다. 단순히 test WebAssembly.instantiate 기능을 제공하고 기본적으로 존재할 때 사용할 수 있는 것 같습니다.

물론, 하지만 먼저 Promise 지원은 최신 node.js에 있을 수 있지만 일반적으로 사용되는 버전에는 없습니다(예: Linux 배포판의 기본 버전). 두 번째로 더 큰 문제는 HTML을 내보낼 때 페이지가 로드되는 방식을 제어할 수 있다는 것입니다(emcc가 사용자를 위해 로드 코드를 내보냄). 반면 JS를 내보낼 때는 JS가 선형으로 실행되는 것으로 가정하고 사용자는 예를 들어 해당 JS 바로 뒤에 다른 스크립트 태그가 있을 수 있습니다. 이 경우 사용자는 자신의 로딩 코드를 작성합니다.

이 두 가지의 결과로 앞서 언급한 것처럼 HTML을 내보낼 때 Promise API를 사용할 수 있지만(그러면 분명히 셸에 있지 않고 로드를 제어할 수 있음) JS를 내보낼 때는 사용할 수 없습니다. 그곳에서 우리는 그것을 문서화할 수 있을 뿐입니다.

Node에 WebAssembly를 지원하지만 Promise는 지원하지 않는 버전이 있습니까? 노드 사람들은 이러한 버전에 관심이 있습니까?

나는 직선 JS를 이해하지 못한다. 항상 Promise를 반환하면 Just Work(코드 사용자는 Promise를 사용해야 함)가 되지 않습니까?

첫 번째 질문에 대한 답은 모르지만 polyfill을 사용하면 약속이 없는 노드 버전에서 wasm을 실행할 수 있습니다. 노드가 잠시 동안 setTimeout 버전을 가지고 있기 때문에 약속을 폴리필하는 것이 가능할 수도 있지만, 그것도 확실하지 않습니다.

직선 문제 정보: emcc는 런타임을 설정하고 컴파일된 코드에 연결하는 JS를 방출합니다. 스크립트 태그의 일부 JS는 컴파일된 코드를 호출할 수 있습니다(예: ccall 사용). 즉, emcc의 JS 출력은 약속이 아니므로 "약속 반환"이 무엇을 의미하는지 잘 모르겠습니다. 누가 반환하고 누가 받을까요? 그러나 어떤 경우든 앞서 언급했듯이 권장되는 경로는 emcc가 HTML을 내보내는 것입니다. 이 경우 비동기 로딩 코드를 생성할 수 있습니다. 일부 사용자는 로드를 보다 직접적으로 제어하는 ​​것을 선호합니다. 더 나은 경우 비동기 wasm을 사용하도록 권장해야 합니다.

WebAssembly가 있지만 Promise가 없는 IMO Node는 우리가 걱정해야 하는 설계 제약 조건이 아닙니다. WebAssembly에 대한 폴리필은 그런 맥락에서 꽤 어리석은 일입니다.

오늘 코드가 무엇을 하는지 설명하고 있습니다. 나는 그것을 완전히 이해하지 못하지만 백업하고 싶습니다. 웹 페이지의 코드가 Promise API를 사용하기를 원합니다. Emscripten은 이러한 코드의 제작자입니다. 약속을 사용하는 코드를 내보내는 것을 차단하는 것이 무엇인지 이해하지 못합니다. "오늘은 그렇지 않기 때문에 의미 있는 작업이지만 우리가 해보도록 하겠습니다"라고 말해도 괜찮습니다. 그러나 우리 토론에서 그것이 당신이 말하는 것인지 확실하지 않습니다.

캐싱을 위해 비동기 API를 사용하는 것에 대해서만 지적한 문제 입니까? 그것이 시작이라고 생각하지만 내가 도달하고 싶은 최종 상태는 첫 번째 로드에서도 비동기 API가 사용되는 곳입니다.

노드에서 폴리필이 어리석은 이유는 무엇입니까? 다른 경우보다 적더라도 그 맥락에서 여전히 유용해 보입니다. :)

다시: Emscripten 은 HTML을 내보낼 때 promise API

그것이 당신의 우려 사항을 해결합니까?

내가 말하고자 하는 것은 Emscripten이 JS(덜 권장되는 경로)를 방출할 때 해당 출력에 대한 보장이 내부적으로 비동기 마술을 수행하는 코드와 일치하지 않는다는 것입니다. 우리는 원하지 않는 사람들의 코드를 깨뜨릴 것입니다. 내가 말했듯이 누군가는 준비가 되었다고 가정하는 JS 직후에 동기적으로 실행되는 JS를 작성할 수 있습니다. 따라서 이 경우에는 약속을 사용할 수 없습니다. 이것을 상상해보십시오.

````

````

doSomething Module.my_func 이 존재하려면 output.js 방금 약속을 반환했다면 아직 존재하지 않는 것입니다. 따라서 이것은 획기적인 변경이 될 것입니다.

그게 지금 말이 됩니까?

노드에서 폴리필이 어리석은 이유는 무엇입니까? 다른 경우보다 적더라도 그 맥락에서 여전히 유용해 보입니다. :)

wasm에 대한 폴리필은 어리석은 일이 아닙니다. wasm이 없고 폴리필하고 약속은 없지만 폴리필하지 않는 노드 설치에 케이터링을 제공하는 것은 어리석은 일입니다. 반말입니다. 그들은 엉덩이의 나머지 절반을 가져와야합니다 😁

다시: Emscripten은 HTML을 내보낼 때 promise API를 사용합니다. 그리고 그것이 권장되는 경로입니다. 따라서 귀하의 질문에 대한 대답은 "예"입니다. 의미 있는 작업은 아닙니다. 캐싱에 중점을 둔 해당 문제에 스케치되어 있지만 (이전) 오프라인 토론에서 메모를 추가했습니다. 그렇게 하는 동안 우리가 할 수 있고 사소한 것이기 때문에 거기에서 다른 비동기 최적화도 많이 수행해야 합니다.

그것이 당신의 우려 사항을 해결합니까?

그래 괜찮네! 대부분의 웹 페이지가 promise API를 사용하는 한 저는 만족합니다.

[한조각]

그게 지금 말이 됩니까?

예. 설명해주셔서 감사합니다.

내 관점에서 볼 때 Emscripten은 더 이상 JS를 내보내는 사업이 아닙니다! 귀하의 예는 Ye Olden Codes에 적합하지만 새로운 것은 약속 IMO를 가정해야 합니다.

Btw, instantiate 를 사용하도록 webassembly.org/demo를 전환하는 것을 보았고 현재 동기 new Instance 가 동기 결과를 원하는 컨텍스트에서 발생하는 것은 약간 까다롭습니다. 따라서 기본적으로 instantiate 를 방출하도록 Binaryen이 업데이트되면 AngryBots 데모를 처음부터 다시 빌드하는 것이 좋습니다.

예, 하지만 처음부터 다시 빌드하는 것만으로는 충분하지 않을 수 있습니다. Unity는 자체 로딩 및 HTML 코드를 사용한다고 생각합니다. 따라서 앞서 언급한 대로 이 문제를 문서화하고 전달하여 필요한 작업을 수행할 수 있도록 해야 합니다(또는 emcc에서 html을 내보내도록 할 수 있지만 이것이 가능한지 모르겠습니다).

예, 하지만 처음부터 다시 빌드하는 것만으로는 충분하지 않을 수 있습니다. Unity는 자체 로딩 및 HTML 코드를 사용한다고 생각합니다. 따라서 앞서 언급한 대로 이 문제를 문서화하고 전달하여 필요한 작업을 수행할 수 있도록 해야 합니다(또는 emcc에서 html을 내보내도록 할 수 있지만 이것이 가능한지 모르겠습니다).

WebAssembly.instantiate API를 사용 하지 않을 때의 잠재적인 단점을 감안할 때 사용을 고려하도록 요청하는 것이 좋습니다.

이러한 단점이 문서화되어 있습니까? 메인 wasm 웹사이트나 emscripten wasm 위키 페이지 에서 이에 대한 명확한 지침이

나는이 긴 문제를 직접 훑어 보았고 아직 단점이 명확하지 않으므로 그것도 읽고 싶습니다. :)

@kripken 현재 코드의 문제는 내보내기가 동기적으로 필요함과 동시에 binaryen/emscripten이 필요한 가져오기( instantiate 에 대한 인수로 필요)만 제공한다는 것입니다. 가져오기를 "앞서" 사용할 수 있는 경우 비동기 XHR의 꼬리 부분에 WebAssembly.instantiate 를 부착하는 것은 매우 간단합니다(현재 데모에서 async compile 수행한 것처럼 본 바에 따르면 현재 AngryBots wasm 빌드는 차선책이며 어쨌든 새로워져야 합니다.

오, 나는 wasm XHR이 시작되기도 전에 수입품을 사용할 수 있게 하는 것이 여기서 핵심이라는 것을 이해하지 못했습니다. 그러면 훨씬 더 까다롭습니다. 그래서 내가 전에 말한 대부분은 틀렸다.

가져오기를 하려면 모든 JS 글루를 다운로드, 구문 분석 및 실행해야 합니다. wasm XHR이 시작되기 전에 이 모든 작업을 수행하면 지금과는 매우 다른 로딩 방식과 트레이드오프가 됩니다. 특히, 중소 규모 프로젝트의 경우 속도 향상이 아닐 수도 있습니다. 아직 측정하지 않았다면 측정해야 할 것 같습니다.

이것은 Unity가 할 수 있는 간단한 일이 아닙니다. 컴파일된 코드가 준비되기 전에 JS 글루가 실행될 수 있도록 emcc가 내보내는 코드를 크게 변경해야 합니다.

아마도 우리는 방출된 JS의 새 모델, 가져오기를 위한 하나의 JS 파일, 나머지를 위한 하나의 JS 파일을 고려하고 싶습니까? 그리고 그것은 옵트인(opt-in)이 될 것이고, 그래서 우리는 아무도 방해하지 않을 것입니다. 어쨌든 많은 고려 사항이 있으며 측정 없이는 무엇이 최적인지 추측하기 어렵습니다.

@kripken XHR 이전이 아니라 완료된 후, 그리고 내보내기 개체에 동기식 액세스를 원하는 스크립트 실행을 시작하기 얼마 전에. 인스턴스화가 해결될 때 호출되는 일부 콜백에 내보내기 사용 코드를 넣는 것처럼 간단할 수 있습니다.

흠, 죄송합니다(특히 비동기가 가져오기를 가져오는 것과 상호 작용하는 이유를 이해하지 못합니다. 가져오기가 동기적으로 작동하지 않는 이점이 있을까요?). 그러나 위에서 언급한 문제는 XHR이 완료된 후에도 여전히 관련이 있는 것 같습니다. 즉, 이제 가져오기를 생성하고 내보내기도 수신하는 단일 스크립트가 있습니다. 이를 나누면 절충점이 생길 수 있습니다. 시간이 있을 때 측정하면 됩니다.

콜백에 내보내기 사용 코드를 넣는 것과 관련하여 슬프게도 앞에서 언급한 이유로만 작동하지는 않지만 새로운 컴파일 모드를 추가하는 측정의 일부로 조사할 수 있습니다.

instantiate 의 서명은 WebAssembly.instantiate(bytes, importObj) 이므로 비동기 컴파일+인스턴스화를 시작하려면 importObj 를 전달해야 합니다.

오프라인에서 @lukewagner 는 여기서 주요 문제가 모듈을 컴파일하는 동안 메모리가 있다는 점에 깊은 인상을 받았습니다. 전반적으로 이 새로운 API를 실제로 사용하는 것이 얼마나 쉬운지와 관련된 세 가지 문제가 있는 것 같습니다.

1. 컴파일할 때 메모리를 제공합니다.
2. 컴파일할 때 모든 가져오기를 제공합니다(이전 항목의 상위 집합).
3. 이 모든 작업을 비동기식으로 수행합니다.

현재 툴체인이 작동하는 방식을 고려할 때 위에서 설명한 것처럼 2 + 3을 수행하는 것은 기존 사용자를 손상시키기 때문에 어렵습니다. 우리는 할 수 있지만 기본적으로 켜기를 원하지 않을 수도 있습니다. 적어도 처음에는 그렇지 않습니다. 커뮤니티 구성원과 상의해야 합니다. 그리고 실제로 잘 하려면 - 새로운 오버헤드가 없습니다 - 시간과 작업이 필요합니다(빠르게 하면 수입 또는 수출에 간접 계층을 추가하여 수행).

그러나 일부 다른 옵션은 사용하기가 매우 쉽습니다.

• 1 + 3에는 instantiate(bytes, Memory) -> Promise 와 같은 새 API가 필요합니다. 이것이 사용하기 쉬운 이유는 메모리가 어쨌든 일찍 생성될 수 있기 때문입니다(거의 다른 가져오기는 JS 함수이며 초기에는 가질 수 없음).
• 2 자체로, 3 없이, 즉 new Instance(bytes, imports) . 즉, 바이너리 데이터 + 가져오기에 대한 동기 컴파일입니다. 이것이 사용하기 쉬운 이유는 현재 코드가 instance = new WebAssembly.Instance(new WebAssembly.Module(getBinary()), imports) 하므로 이를 1개의 API 호출로 접을 것입니다.

나는 마지막 옵션이 의미가 있다고 생각합니다. 기본적으로 새 API의 동기화 버전을 추가하여 기존 동기식 컴파일 옵션과 더 대칭적으로 만드는 것을 의미합니다. 그리고 컴파일 타임에 메모리를 아는 새로운 최적화를 비동기 컴파일에 묶을 이유가 보이지 않습니까? (비동기는 훌륭하지만 별도의 문제입니까?)

컴파일하기 전에 가져오기를 할당 해야 한다는 제약을 깨기 위해 가져오기(메모리)를 설명하는 메타 개체를 제안합니다. 그러면 instantiate 메소드는 제공된 메모리가 예상한 것과 일치하지 않고 재컴파일이 지연되지 않는 경우 오류를 던질 수 있습니다.

또한 메모리 제약이 있는 장치에 선형 메모리를 할당하기 전에 컴파일할 수 있고 선형 주소 공간에서 0에 할당된 메모리에 대해 컴파일을 최적화할 수 있고 보호 영역이 있는 메모리에 대해 최적화할 수 있는 것도 매우 유용합니다. 2의 거듭제곱에 유출 영역을 더한 고정된 최대 크기로 메모리를 최적화합니다. 이 메타 객체는 또한 협상된 메모리 특성에 최적화된 코드를 방출하기 위해 wasm 사용자 디코더/재작성기에 의해 사용될 수 있습니다.

이것은 몇 년 전 이 프로젝트가 시작될 무렵에 필요에 따라 제안된 것입니다!

@kripken 동기화 API가 기술적으로 필요하다고 생각하지만 확실히 권장하지 않는 경로여야 합니다.

동기 컴파일/인스턴스화를 명시적으로 금지해야 하는 이유(또는 과거에 주장한 것처럼 허용하지 않는 경우도 있음)에 대한 더 나은 예를 제공하려는 의도였습니다. 바라건대 이것은 토론을 위한 추가 자료를 제공합니다.

잠시 축소하고 사용자 경험에 대해 이야기해 보겠습니다.

다음은 AngryBots 데모를 비동기식으로(asm.js를 통해) 로드하는

동기 컴파일은 끔찍한 사용자 경험을 제공하고 진행률 표시줄이나 응용 프로그램 로딩에 대한 기타 시각적 표시를 깨뜨립니다.

노력이 무엇이든 상관없이 Emscripten, Unity 및 기타 도구가 기본적으로 WebAssembly를 로드하는 비동기식으로 내보내도록 함께 협력해야 한다고 생각합니다. cc @jechter @juj 뿐만 아니라 개발자가 동기 로딩 코드를 작성하는 함정에 빠지는 것을 엄청나게 어렵게 만들어야 한다고 생각합니다.

WebAssembly.compile & WebAssembly.instantiate 을 명시적으로 권장하고 new WebAssembly.Module & new WebAssembly.Instance 권장하지 않습니다.

WebAssembly의 경우 오른쪽에 있는 진행률 표시줄이 얼마나 나쁜지 좀 더 자세히 살펴보겠습니다.

다음은 DevTools 성능 패널로 캡처한 추적입니다.

MacBook Air에서 진행률 표시줄을 표시하는 데 30초가 걸립니다.

시간이 걸리는 이유는 무엇입니까? 메인 스레드가 완전히 잠겨 있을 때 wasm 모듈이 다운로드된 후 ~20초로 확대해 보겠습니다.

컴파일에는 ~20초가 걸리고 인스턴스화에는 ~2초가 걸립니다.

이 경우 Unity 로더는 지원되는 경우 이미 비동기 WebAssembly.compile 호출하고 있으므로 20년대는 V8이 여전히 내부에서 동기 컴파일을 수행하기 때문입니다. cc @titzer @flagxor 이것은 V8이 정말로 수정해야 할 부분입니다.

2초 인스턴스화 버벅거림은 동기 new WebAssembly.Instance 호출하는 Unity 로더 코드로 인한 것입니다. 이것이 Unity 코드와 Emscripten에서 모두 수정해야 하는 부분입니다.

이것은 개발자가 발에 총을 쏘거나 하지 않는 _단순히_ 위험이 아니라는 점도 언급할 가치가 있다고 생각합니다. 평균적인 웹 페이지에는 수십 개의 타사 스크립트가 포함되어 있습니다. 이러한 스크립트는 모두 최상위 문서 버벅거림 WebAssembly를 포함할 가능성이 있습니다.

(추적을 더 자세히 살펴보고 싶다면 https://chromedevtools.github.io/timeline-viewer/?loadTimelineFromURL=https://www.dropbox.com/s/에서 전체 타임라인을 볼 수 있습니다. noqjwql0pq6c1wy/wasm?dl=0)

async가 훌륭하다는 데 100% 동의합니다. 하지만 모듈을 컴파일하면서 동시에 메모리를 얻는 최적화와 직교합니다. 그리고 우리는 async + that 최적화를 쉽게 얻을 수 없다는 것 - 우리는 그 콤보를 얻을 수 있지만 약간의 오버 헤드를 희생하거나 새로운 플래그를 도입하고 기본값으로 단계적으로 적용하는 방법을 찾으면 시간이 걸립니다. .

따라서 메모리/컴파일 최적화가 기본적으로 켜져 있고 최대 효율성을 원한다면 이를 비동기식으로 묶는 것도 문제입니다. 그러나 긴급하지 않거나 기본적으로 켜져 있지 않아도 괜찮거나 새로운 오버헤드가 있어도 문제가 되지 않습니다.

개발자가 wasm을 선택하기 때문에 새로운 기본값으로 최상위 구조를 약간 변경할 기회를 잡는 것이 합리적이라고 생각합니다(필요한 경우 이전 동작을 선택하는 방법 포함). 동기화를 사용하는 사람들

@kripken 저 , @lukewagner 및 @s3ththompson 이 가진 결론과 다른 결론에 도달했다고 생각합니다. 왜냐하면 가장 중요한 부분은 기존 개발자에게 asm.js에서 원활한 전환을 제공하는 것이기 때문입니다.

이 올바른지?

나는 이것이 타당한 우려라는 데 동의합니다. WebAssembly를 사용한 IMO가 asm.js보다 더 많은 개발자를 불러들였기 때문에 더 낮은 무게를 둡니다. 얼리 어답터를 태우는 것을 피하고 싶지만 IIUC 기존 개발자는 매우 유연 하고 비동기 컴파일을

그들이 비동기 컴파일을 원하고 이를 얻기 위해 일부를 리팩토링할 의향이 있다고 가정하면 남은 것은 컴파일 시 메모리를 갖는 것뿐입니다. 이것이 이 API가 제공하는 것입니다. 함정을 피하기 때문에 매우 바람직합니다.

이전에 이를 지원하기 위해 Emscripten 측에 관련된 작업의 양에 대해 우려를 표명했습니다. 아직도 이것이 문제라고 생각하십니까?

FWIW, Unity 5.6은 WebAssembly.instantiate를 사용합니다.

조나스

2016년 12월 28일 오후 11시 42분에 Seth Thompson [email protected]이 다음과 같이 썼습니다.

동기 컴파일/인스턴스화를 명시적으로 금지해야 하는 이유(또는 과거에 주장한 것처럼 허용하지 않는 경우도 있음)에 대한 더 나은 예를 제공하려는 의도였습니다. 바라건대 이것은 토론을 위한 추가 자료를 제공합니다.

잠시 축소하고 사용자 경험에 대해 이야기해 보겠습니다.

다음은 비동기 호출(asm.js를 통해), 왼쪽 및 동기 호출(현재 WebAssembly 구현)을 사용하여 AngryBots 데모를 로드하는 것(오른쪽)을 비교한 것입니다.

동기 컴파일은 끔찍한 사용자 경험을 제공하고 진행률 표시줄이나 응용 프로그램 로딩에 대한 기타 시각적 표시를 깨뜨립니다.

노력이 무엇이든 상관없이 Emscripten, Unity 및 기타 도구가 기본적으로 WebAssembly를 로드하는 비동기식으로 내보내도록 함께 협력해야 한다고 생각합니다. cc @jechter @juj 뿐만 아니라 개발자가 동기 로딩 코드를 작성하는 함정에 빠지는 것을 엄청나게 어렵게 만들어야 한다고 생각합니다.

WebAssembly.compile & WebAssembly.instantiate를 명시적으로 권장하고 새로운 WebAssembly.Module 및 새로운 WebAssembly.Instance를 권장하지 않아야 합니다.

WebAssembly의 경우 오른쪽에 있는 진행률 표시줄이 얼마나 나쁜지 좀 더 자세히 살펴보겠습니다.

다음은 DevTools 성능 패널로 캡처한 추적입니다.

MacBook Air에서 진행률 표시줄을 표시하는 데 30초가 걸립니다.

시간이 걸리는 이유는 무엇입니까? 메인 스레드가 완전히 잠겨 있을 때 wasm 모듈이 다운로드된 후 ~20초로 확대해 보겠습니다.

컴파일에는 ~20초가 걸리고 인스턴스화에는 ~2초가 걸립니다.

이 경우 Unity 로더는 지원되는 경우 이미 비동기식 WebAssembly.compile을 호출하고 있으므로 20대는 V8이 여전히 내부에서 동기식 컴파일을 수행하기 때문입니다. cc @titzer @flagxor 이것은 V8이 정말로 수정해야 할 부분입니다.

2초 인스턴스화 버벅거림은 동기식 새 WebAssembly.Instance를 호출하는 Unity 로더 코드로 인해 발생합니다. 이것이 Unity 코드와 Emscripten에서 모두 수정해야 하는 부분입니다.

이것은 개발자가 발에 총을 쏘거나 말거나하는 위험이 아니라는 점도 언급할 가치가 있다고 생각합니다. 평균적인 웹 페이지에는 수십 개의 타사 스크립트가 포함되어 있습니다. 이러한 스크립트는 모두 최상위 문서 버벅거림 WebAssembly를 포함할 가능성이 있습니다.

(추적을 더 자세히 살펴보고 싶다면 https://chromedevtools.github.io/timeline-viewer/?loadTimelineFromURL=https://www.dropbox.com/s/에서 전체 타임라인을 볼 수 있습니다. noqjwql0pq6c1wy/wasm?dl=0)

—
당신이 언급되었기 때문에 이것을 받는 것입니다.
이 이메일에 직접 답장하거나 GitHub에서 보거나 스레드를 음소거하세요.

@jfbastien "결론"이 무엇을 의미하는지 이해하지 못할 수도 있습니다. 나는 주로 여기에 옵션을 제시하고 있습니다. 나 자신도 결론이 없다.

지금 바로 컴파일 시 메모리 옵션을 원하는 경우 현재 동기화 컴파일을 간단하게 수정하여 최대한 빨리 사용할 수 있는 몇 가지 옵션을 제안했습니다.

또는 지금 비동기 방식으로 해당 옵션을 선택하려는 경우 최대한 빨리 사용할 수 있는 옵션("1 + 3", 즉 컴파일 타임에 모든 가져오기를 수신하지 않고 메모리만 수신)을 제안했습니다.

또는 현재 API("1 + 3"이 아님)를 사용하여 해당 opt의 비동기 버전에 집중하고 싶다면 그것도 얻을 수 있습니다. 중요한 변경 사항이기 때문에 약간의 신중한 계획이 필요할 것입니다. 기존 사용자를 중단하기로 결정하는 것은 여기에서 우리가 선택할 수 있는 옵션이 아니라고 생각하므로 커뮤니티와 상의해야 합니다. 우려 사항이 거의 없고 그냥 할 수 있습니다. 이 경우 얼마나 많은 노력이 얼마나 많은 오버헤드를 허용할 의향이 있는지에 따라 달라집니다. 오버헤드를 전혀 수용할 수 없다면 많은 노력이 필요할 수 있습니다. 또는 내 개인적인 직감인 우려가 있을 수 있습니다. 모든 주요 변경 사항은 점진적으로 수행되어야 합니다. 이 경우 시간이 더 오래 걸리므로 새로운 옵션으로 시작하여 결국 기본값으로 설정할 계획입니다.

다시 말하지만, 나에게서 결론이 나지 않습니다. 위의 모든 것은 옵션입니다. 그것은 정말로 당신이 더 신경 쓰는 것에 달려 있습니다: Memory-at-Compile-time, async, 또는 둘 다; 그리고 새로운 오버헤드를 허용하는 것과 허용하지 않는 것의 문제; 긴급히 원하는지 아니면 기다릴 수 있는지 등. 사람들이 결정하는 방식에 상관없이 위의 사항에 대해 emscripten 측에서 기꺼이 도와드리겠습니다.

또는 현재 API("1 + 3"이 아님)를 사용하여 해당 opt의 비동기 버전에 집중하고 싶다면 그것도 얻을 수 있습니다. 중요한 변경 사항이기 때문에 약간의 신중한 계획이 필요할 것입니다. 기존 사용자를 중단하기로 결정하는 것은 여기에서 우리가 선택할 수 있는 옵션이 아니라고 생각하므로 커뮤니티와 상의해야 합니다. 우려 사항이 거의 없고 그냥 할 수 있습니다. 이 경우 얼마나 많은 노력이 얼마나 많은 오버헤드를 허용할 의향이 있는지에 따라 달라집니다. 오버헤드를 전혀 수용할 수 없다면 많은 노력이 필요할 수 있습니다. 또는 내 개인적인 직감인 우려가 있을 수 있습니다. 모든 주요 변경 사항은 점진적으로 수행되어야 합니다. 이 경우 시간이 더 오래 걸리므로 새로운 옵션으로 시작하여 결국 기본값으로 설정할 계획입니다.

확실히 이해하려면:

1. 간접비는 무엇입니까?
   
   
   
   • 이러한 오버헤드는 비동기 + 컴파일 시 메모리에 내재되어 있습니까? 아니면 나중에 수정할 수 있는 구현 제약 조건입니까? IMO가 A+M 고유의 것이라면 최대한 빨리 API를 수정해야 합니다.
   
   
   • IIUC 오버 헤드는 수입 또는 수출에 대한 일시적인 것이며 A + M에 고유하지 않습니다. 맞습니까? 좀 더 자세히 설명해 주시겠습니까?
   
   
2. 어떤 사용자가 중단에 대해 이야기하고 있습니까? 동일한 코드가 wasm도 대상으로 하기를 원하는 asm.js 사용자?

다시 말해서 무한한 시간이 있고 "레거시"가 없는 경우 WebAssembly의 이상적인 최종 상태는 무엇입니까? 나는 우리가 이상적인 최종 상태를 위해 설계했다고 생각하고 당신은 그 과정에서 장애물을 지적하고 있지만 여전히 그것이 사실인지 확신할 수 없습니다. 그렇다면 WebAssembly에 전환을 용이하게 하기 위해 임시방편이 필요한지 또는 Emscripten 사용자의 하위 집합(및 어떤 사용자)에게 일시적인 부담이 허용되는지 파악하기에 충분한 정보가 있는지 확신할 수 없습니다.

일부 옵션의 오버헤드에 대해: 위에서 설명한 것처럼 까다로운 점은 현재 가져오기를 보내고 내보내기를 동기적으로 수신해야 하며 JS가 준비될 때까지 JS 가져오기가 없다는 것입니다. !). 이 문제를 해결하는 한 가지 방법은 가져오기 또는 내보내기에 간접 계층을 추가하는 것입니다. 예를 들어, 아주 초기에(JS 이전의 HTML에서) 실제 가져오기 대신 썽크를 제공할 수 있으므로 동기적으로 제공하는 것처럼 보입니다(그러나 JS가 있기 전에도 생성하기 쉬운 썽크일 뿐입니다). . 그런 다음 나중에 JS가 있으면 올바른 위치를 가리키도록 썽크를 업데이트할 수 있습니다. 이렇게 하면 다른 JS 호출의 오버헤드와 각 가져오기 호출에 대한 JS 개체 조회가 추가됩니다. 또한 코드 크기 및 시작 시 약간의 오버헤드가 발생합니다.

사용자 깨기: 우리는 기존 emscripten 사용자가 플래그 를 원합니다 . 많은 사용자와 파트너가 이에 대해 만족하고 있습니다. 이를 통해 asm.js와 wasm을 비교할 수 있으며 새로운 이식 노력 없이도 wasm의 이점을 얻을 수 있습니다. 또한 was로 이식하는 동안 시작 코드를 비동기화해야 하는 경우 문제가 발생하면 wasm을 불필요하게 비난할 수 있는 위험을 피할 수 있습니다.

JS가 준비될 때까지 JS 가져오기가 없습니다(하지만 메모리는 있습니다!)

이는 부수적인 것으로 보이며 API로 영원히 제 시간에 구워야 하는 것은 아닙니다. 게다가 @s3ththompson이 설명한 이유 때문에 컴파일 시 메모리 문제를 무시하더라도 합니다 . 그래서 저는 @jfbastien 에 이상적인 최종 상태 API가 있으며 여기서 타협해서는

사용자 중단 정보: "onload" 이벤트/약속과 같은 간단한 마이그레이션 경로를 제공하는 경우 사용자가 마이그레이션하기가 간편해야 하며 당근이 모든 주요 성능이 승리합니다. 정확한 asm.js 소스 backcompat이 기본 구성에 대한 어려운 요구 사항이라는 증거가 없다고 생각합니다. 우리는 정반대의 예가 많이 있습니다. 사용자는 최적의 성능을 달성하기 위해 무엇이든 기꺼이 하려고 합니다. 왜냐하면 그것이 물론 요점이기 때문입니다.

@lukewagner와 오프라인으로 대화하면서 가장 좋은 방법은 emscripten의 기본 권장 설정에서 wasm에 대한 인스턴스화를 활성화하는 것부터 시작하는 것입니다. 이는 위에서 설명한 대로 내보내기에서) 간접 계층을 추가하여 시작하는 것입니다. 대부분의 사용 사례에서 무시할 수 있는 오버헤드가 있을 것입니다. 그래서 이것은 우리 모두가 여기서 원하는 이점을 얻습니다.

결국 우리는 그 작은 오버헤드를 없앨 수 있지만 분명히 좋은/올바른 방법이 없기 때문에 더 많은 계획과 메일링 리스트 토론 등이 필요한 주요 변경 사항이 될 것임을 깨달았습니다. 하지만 간접 계층의 오버헤드가 매우 낮다고 생각하기 때문에 이 부분은 시급하지 않습니다.

@kripken 대단해! 다양한 인스턴스 / JS / 가져오기 / 내보내기 / 메모리 / 테이블을 보여주는 다이어그램이 있으면 도움이 될 것입니다. 이 토론을 다른 곳으로 옮기시겠습니까(Emscripten / binaryen repo)? 나는 C++ 코드가 무엇으로 구성되어야 한다고 생각하는지에 대한 정신적 그림을 가지고 있지만, 지금쯤 당신이 같은 그림을 가지고 있지 않다는 것은 꽤 분명합니다! 당신은 그곳에서 더 많은 경험을 하고 있기 때문에 나는 그곳에서 배우고 내가 할 수 있는 한 도움을 드리고 싶습니다.

@jfbastien : 물론입니다. 나는 당신이 다이어그램에서 무엇을 찾고 있는지 아직 명확하지 않지만 예, 아마도 다른 곳이 더 나을 것입니다. emscripten에서 이를 구현하기 위해 이전에 언급한 문제가 있습니다. https://github.com/kripken/emscripten/issues/4711 , 원하는 것을 다루지 않는 경우 다른 문제도 자유롭게 여십시오.

IIUC Emscripten은 이제 기본적으로 이것을 사용합니다. 폐쇄.

@s3ththompson comment 에 대한 후속 조치를 위해서는 동기 컴파일 및 인스턴스화가 유용합니다. 특히, 최근에 Node.js( v7.7.2 )에서 WebAssembly 모듈을 동기적으로 로드하고 컴파일하려는 상황에 부딪쳤습니다. 약속을 반환하는 API만 사용할 수 있는 경우 동기 내보내기를 제공할 수 없습니다.

비동기, 동기화 또는 두 API를 모두 제공할지 여부를 결정할 때 브라우저 컨텍스트가 사람들이 WebAssembly를 사용하려는 유일한 환경이 아니라는 점을 기억하십시오. 저를 포함하여 많은 사람들이 JVM과 유사한 Node.js 런타임과 결합된 효율적인 컴파일 대상으로서 WebAssembly의 잠재력에 관심이 있습니다. 비동기 가져오기/내보내기 가 Node.js에

@kgryte 내 의견은 주로 브라우저에 실행 컨텍스트로 관련되어 있음을 분명히 했어야 했습니다. 동기 API를 여전히 노출하는 API 표면에 도달했습니다. 브라우저는 동기 API에 전달된 모듈에 크기 제한을 부과할 수 있지만(예: Chrome은 이미 수행) 해당 제한은 임베더에서 구성할 수 있으며 Node.js에 적용할 필요가 없습니다.

@s3ththompson 설명 감사합니다.