Design: 데이터 JS/WASM 컨텍스트를 전달하는 가장 효과적인 방법

JavaScript와 WebAssembly 간에 데이터를 복사할지 아니면 WebAssembly가 데이터를 소유하도록 할지 결정해야 합니다.

데이터를 복사하려면 for 루프를 직접 작성하는 대신 TypedArray.prototype.set() 을 사용할 수 있습니다.

let instance = ...;
let myJSArray = new Float32Array(...);
let length = myJSArray.length;
let myWasmArrayPtr = instance.exports.allocateF32Array(length);
let myWasmArray = new Float32Array(instance.exports.memory.buffer, myWasmArrayPtr, length);

// Copy data in to be used by WebAssembly.
myWasmArray.set(myJSArray);

// Process the data in the array.
instance.exports.processF32Array(myWasmArrayPtr, length);

// Copy data out to JavaScript.
myJSArray.set(myWasmArray);

WebAssembly가 데이터를 소유하는 경우 WebAssembly.Memory 버퍼에 대한 보기를 만들고 이를 JavaScript 함수에도 전달할 수 있습니다.

let instance = ...;
let length = ...;
let myArrayPtr = instance.exports.allocateF32Array(length);
let myArray = new Float32Array(instance.exports.memory.buffer, myArrayPtr, length);

// Use myArray as a normal Float32Array in JavaScript, fill in data, etc.
...

// Process the data in the array.
instance.exports.processF32Array(myArrayPtr, length);

// No need to copy data back to JavaScript, just use myArray directly.

또한 embind 와 같은 도구를 사용하여 이를 좀 더 쉽게 사용할 수 있습니다.

와, @binji님 감사합니다. 멋지네요. 제가 찾던 바로 그 제품입니다. 또한 시간을 내어 예제 코드를 작성해 주셔서 감사합니다. 이것도 매우 도움이 됩니다. 오늘 저녁에 시도하고 Loader impl에 대한 몇 가지 개선 사항을 요청합니다. https://github.com/AssemblyScript/assemblyscript에서 WASM과 인터페이스하는 데 사용 중입니다.

이와 관련하여 webassembly.org에서 문서를 확장할 수 있는 옵션이 있습니까?

예를 들면 다음과 같습니다.

https://webassembly.org/docs/web/

가능하다면 기꺼이 그렇게 하겠다.

여기에서 설명하는 것도 좋은 생각이라고 생각합니다.

https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/WebAssembly/Memory

@binji 주제가 아닌 경우 프로젝트에 대해 아직 알지 못한다면 https://github.com/torch2424/wasmBoy를 좋아할 것입니다. 그리고 이 프로젝트는 for 루프를 사용하여 ROM 메모리를 설정하기 때문에 제안한 솔루션의 이점을 얻을 수도 있습니다.

이와 관련하여 webassembly.org에서 문서를 확장할 수 있는 옵션이 있습니까?

이 변경 사항과 함께 webassembly.org를 업데이트해야 한다는 데 동의했습니다. 디자인 리포지토리에 있는 문서는 여전히 있지만 사양 리포지토리는 훨씬 최신이고 정확합니다.

더 많은 웹 개발자가 webassembly.org보다 해당 사이트를 사용할 것이라는 점을 고려하면 MDN에 몇 가지 예제를 추가하는 것이 더 쉽고 더 나을 것입니다.

주제에서 벗어나 아직 프로젝트에 대해 알지 못한다면 https://github.com/torch2424/wasmBoy를 좋아할 수 있습니다.

예, @torch2424를 압니다. :-) 저만의 wasm 기반 게임보이 에뮬레이터도 있습니다: https://github.com/binji/binjgb

더 많은 웹 개발자가 webassembly.org보다 해당 사이트를 사용할 것이라는 점을 고려하면 MDN에 몇 가지 예제를 추가하는 것이 더 쉽고 더 나을 것입니다.

알겠습니다. 오늘 밤 업데이트를 게시하겠습니다. 공개되는지 알아보겠습니다.

예, @torch2424를 압니다. :-) 저만의 wasm 기반 게임보이 에뮬레이터도 있습니다: https://github.com/binji/binjgb

하하, 멋지다! 데프하겠습니다. 시도해 보세요 :) 에뮬레이터는 Zelda - Link's Awakening에서 칼을 얻을 때 충돌하지 않습니다. (해변에서) ;))

나는 wasmBoy에서도 충돌을 고칠 시간을 찾기를 바랍니다. :)

이봐! wasmboy를 찾았습니다! 😄 네, @binji 의 에뮬레이터가 확실히 더 정확

피드백을 기반으로 몇 가지 버그를 열었습니다.
https://github.com/torch2424/wasmBoy/issues/141 - 메모리 전달
https://github.com/torch2424/wasmBoy/issues/142 - Zelda Crash(스크린샷과 함께 작동합니다)

어쨌든, 대화/문제를 탈선시키고 싶지 않다면 내가 연 문제로 넘어갈 것입니다. 하지만 피드백 주셔서 감사합니다! 😄

WebAssembly가 데이터를 소유하는 경우 WebAssembly.Memory 버퍼에 대한 보기를 만들고 이를 JavaScript 함수에도 전달할 수 있습니다.

한 가지 중요한 주의 사항: WebAssembly 인스턴스가 메모리를 늘리면 메모리 버퍼에 대한 보기가 무효화됩니다. WebAssembly 인스턴스에 대한 추가 호출 이후에 지속되는 뷰에 대한 참조를 저장하지 마십시오.

@binji 이것을 사용할 때 AssemblyScript 측에 무엇을 넣는지 알려

let myWasmArrayPtr = instance.exports.allocateF32Array(length);

나는 다음과 같이 쓰고 작동하지만 여전히 올바른 방법인지 알고 싶습니다.

export function allocateF32Array(length: usize): usize {
    return memory.allocate(length * sizeof<f32>());
}

memory.free() 로 해제하려면 다른 AS 함수를 작성해야 하고 배열을 JS 측에 전송한 후 호출해야 합니까?

@fmkang @binji가 설명한 내용은 JS 측에서 설명한 것입니다(틀린 경우 수정해 주세요).

Typed Arrays를 사용하면 Wasm Array Buffer와 함께 set() 을 사용하여 JS 측에서 WASM 메모리에 효율적으로 쓸 수 있습니다.

Wasm/AS 내부에서 Wasm 메모리에 쓰기, 여전히 표준 for 루프 접근 방식을 사용하고 있습니다(예: https://github.com/torch2424/wasmBoy/blob/master/core/memory/dma.ts#L29).

하지만 @MaxGraey 또는 @dcodeIO 가 AS 또는 Wasm 랜드 내부에서 가장 효율적으로 이 작업을 수행하는 방법에 도움이 될 수 있습니까? 😄 비록 이것을 AS repo로 옮기는 것이 더 나을 수도 있지만

@fmkang 당신은 단순히

export function allocateF32Array(length: i32): Float32Array {
  return new Float32Array(length);
}

AS 측과

let myArray = module.getArray(Float32Array, module.allocateF32Array(length));

JS 측 에서 loader 를 사용

@torch2424 예, @binji 의 코드는 JS 쪽에 있지만 let myWasmArrayPtr = instance.exports.allocateF32Array(length) 는 Wasm 모듈에서 allocateF32Array 라는 함수를 호출하고 있습니다(AssembleScript로 컴파일되었을 가능성이 높음). 이 기능은 그의 스니펫이나 AS 내장 기능의 일부에 언급되어 있지 않으므로 직접 구현해야 한다고 생각합니다. 대응하는 Wasm 배열을 가리키는 이 포인터를 얻는 방법을 묻고 있습니다.

@dcodeIO 감사합니다. 이것은 전달 배열을 단순화하는 것 같습니다. 여기에 새로운 의견을 게시하기 전에 신중하게 실험해 보겠습니다. 그러나 내 기능을 귀하의 기능으로 교체한 후 로드될 때 내 모듈이 충돌합니다. 콘솔은 말한다

astest.html:1 Uncaught (in promise) TypeError: WebAssembly Instantiation: Import #0 module="env" error: module is not an object or function

내 AS 코드의 아무 곳에나 let a = new Float32Array(10); 와 같은 것을 쓰면 충돌이 발생합니다.

@dcodeIO ( let c: f64[] = [a[0] + b[0], a[1] + b[1]]; 와 같은 리터럴 대신) 표현식을 사용하여 배열을 초기화하거나 배열의 요소에 값을 할당하려고 할 때(예: let a: f64[] = [0, 0, 0]; a[0] = 1; 또는 let array = new Array<i32>(); array.push(1); ) Wasm 모듈이 충돌합니다

처음에는 memory 를 env 넣지 않았기 때문에 다음과 같이 작성했습니다.

var importObject = {
    env: { memory: new WebAssembly.Memory({initial:10}) },
    imports: { imported_func: arg => console.log(arg) }
};
WebAssembly.instantiate(wasmBinary, importObject).then(...);

그러나 문제는 여전히 존재했습니다. 그러다가 abort 가 없기 때문이라는 것을 알게 되었습니다. 우리는 다음과 같이 썼습니다.

env: {
    abort(msg, file, line, column) {
        console.error("abort called at main.ts:" + line + ":" + column);
    }
}

또는 단순히 env: { abort: function(){} } 하면 문제가 해결됩니다. 그러나 오류 메시지가 없으며 코드 실행이 실제로 "중단"되지 않았습니다. 우리는 여전히 이 문제의 실제 원인을 모릅니다.

우리는 WebAssembly를 처음 접합니다. 나는 단지 업데이트를 제공하기 위해이 게시물을 작성합니다. 답장을 할 필요는 없습니다.

@fmkang 모듈을 인스턴스화하기 위해 AssemblyScript 로더 를 사용하지 않는 것 같습니다. 이 모든 것을 직접 구현할 수 있지만 로더는 이미 중단 기능과 같은 모듈 내보내기에 대한 기본 기능을 추가합니다. AssemblyScript에 대해 더 궁금한 사항이 있는 경우 문제 추적기 에 문의해 주시면 기꺼이 도와드리겠습니다. :)

그래서 이 기술을 사용해 보았습니다.

let myArrayPtr = instance.exports.allocateF32Array(length);
let myArray = new Float32Array(instance.exports.memory.buffer, myArrayPtr, length);

// Use myArray as a normal Float32Array in JavaScript, fill in data, etc.
...

// Process the data in the array.
instance.exports.processF32Array(myArrayPtr, length);

그러나 내 processF32Array 함수 결과는 RuntimeError: memory access out of bounds 입니다. 나는 로더, FWIW를 사용하지 않습니다. 나는 또한 시도했다 :

let myArray = module.getArray(Float32Array, module.allocateF32Array(length));

그러나 내 모듈에는 "getArray"가 없으며 어떻게 가져와야 하는지 잘 모르겠습니다.

WebAssembly로/에서 배열을 복사하는 방법을 찾고 있었는데 이 스레드를 발견했습니다. 다른 사람의 경우 AssemblyScript 및 @torch2424 의 라이브러리 as-bind 를 사용하여 배열을 복사할 수 있었습니다.

내 간단한 테스트는 다음과 같습니다.

어셈블리스크립트

export function sum(arr: Float64Array): f64 {
  let sum: f64 = 0;
  for(let i = 0; i < arr.length; i++) {
    sum += arr[i];
  }
  return sum;
}

자바스크립트(노드)

const { AsBind } = require("as-bind");
const fs = require("fs");
const wasm = fs.readFileSync(__dirname + "/build/optimized.wasm");

const asyncTask = async () => {
  const asb = await AsBind.instantiate(wasm);

  // Make a large array
  console.time('Making array');
  let arr = new Float64Array(1e8).fill(1);
  console.timeEnd('Making array');

  // Find the sum using reduce
  console.time('Reduce');
  let sum1 = arr.reduce((acc, val) => acc + val, 0);
  console.timeEnd('Reduce');

  // Find the sum with for loops
  console.time('JS For');
  let sum2 = 0;
  for(let i = 0; i < arr.length; i++) sum2 += arr[i];
  console.timeEnd('JS For');

  // Find the sum with WebAssembly
  console.time('Wasm For');
  let sum3 = asb.exports.sum(arr);
  console.timeEnd('Wasm For');

  console.log(sum1, sum2, sum3);
};

asyncTask();

내 컴퓨터에서 다음과 같은 결과를 얻었습니다.

Making array: 789.086ms
Reduce: 2452.922ms
JS For: 184.818ms
Wasm For: 2008.482ms
100000000 100000000 100000000

이 방법을 사용하여 배열을 WebAssembly로 복사할 때 상당한 오버헤드가 있는 것처럼 보이지만 합계보다 더 비싼 작업에 대해 절충이 가치가 있다고 상상할 수 있습니다.

편집하다:

배열 복사본의 실행 시간을 분리하기 위해 AssemblyScript에서 합계를 제거했습니다.

export function sum(arr: Float64Array): f64 {
  let sum: f64 = 0;
  return sum;
}

그리고 벤치마크를 다시 실행했습니다.

Wasm 합계 없음

Making array: 599.826ms
Reduce: 2810.395ms
JS For: 188.623ms
Wasm For: 762.481ms
100000000 100000000 0

따라서 데이터 복사 자체가 1억 f64 s 이상을 복사하는 데 762.481ms가 걸린 것 같습니다.

@pwstegman 무작위 입력 데이터를 사용하고 js 엔진이 루프를 최적화하는 것을 방지하는 또 다른 벤치마크를 만들었습니다. https://webassembly.studio/?f=5ux4ymi345e

Chrome 및 FF의 경우 결과가 다릅니다.

Chrome 81.0.4044.129

js sum: 129.968017578125ms
sum result = 49996811.62100115

js reduce: 1436.532958984375ms
js reduce result = 49996811.62100115

wasm sum: 153.000244140625ms
wasm sum result = 49996811.62100115

wasm reduce: 125.009033203125ms
wasm reduce result = 49996811.62100115

wasm empty: 0.002685546875ms

안녕하세요.
저는 기본적으로 WASM에 대한 친숙함과 관련하여 신생아이며 여기와 #1162에 있는 사람들과 같은 문제를 우연히 발견했습니다. (이것이 더 최근 활동을 가지고 있기 때문에 나는 여기에 #1162 대를 묻는다.)
간단한 연구 후 나는 그것을 알아 내려고 시도하면서 데모 를 만들었고 데이터 복사를 피하기 위해 유형이 지정된 배열로 WASM 메모리에 뷰를 노출하는 방법으로 끝났습니다. 여기 JS 관점에서 요점이 있습니다. :

// need to know the size in advance, that's OK since the impl makes some init 
const fft = new Module.KissFftReal(/*size=*/N);depending on the size anyway

// get view into WASM memory as Float64Array (of size=N in this case)
const input = fft.getInputTimeDataBuffer();

// fill 'input' buffer

// perform transformation, view into WASM memory is returned here (of size=(N + 2) in this case, +2 for Nyquist bin)
const output = fft.transform();

// use transformation result returned in 'output' buffer

이것이 갈 길인가? 더 나은 솔루션이 있습니까? 이 주제에 대한 모든 의견/새로 고침을 주시면 감사하겠습니다.

추신 비록 추악하지만 그것은 실제로 나를 위해 환상적으로 작동합니다 (내가 그것을 이해하고 감사할 수 있는 한)