In questa guida, rivolta agli sviluppatori web che vogliono usufruire di WebAssembly, imparerai a utilizzare Wasm per esternalizzare le attività che richiedono un uso intensivo della CPU con l'aiuto di un esempio in esecuzione. La guida copre tutto, dalle best practice per il caricamento dei moduli Wasm all'ottimizzazione della loro compilazione e istanziazione. Inoltre, discute lo spostamento delle attività che richiedono un'intensa utilizzo della CPU nei web worker e analizza le decisioni di implementazione che dovrai prendere, ad esempio quando creare il web worker e se mantenerlo attivo in modo permanente o avviarlo quando necessario. La guida sviluppa in modo iterativo l'approccio e introduce un modello di rendimento alla volta, fino a suggerire la soluzione migliore al problema.
Ipotesi
Supponiamo che tu abbia un'attività molto incentrata sulla CPU che vuoi esternalizzare a WebAssembly (Wasm) per le sue prestazioni quasi native. L'attività che richiede un'elevata intensità di CPU
utilizzata come esempio in questa guida calcola il fattore di un numero. Il
fatoriale è il prodotto di un numero intero e di tutti i numeri interi al di sotto. Ad esempio, il fattoriale di 4 (scritto come 4!
) è uguale a 24
(ovvero 4 * 3 * 2 * 1
). I numeri diventano grandi rapidamente. Ad esempio, 16!
è
2,004,189,184
. Un esempio più realistico di un'attività che richiede un'elevata potenza di calcolo della CPU potrebbe essere la scansione di un codice a barre o il tracciamento di un'immagine raster.
Un'implementazione iterativa (anziché ricorsiva) di una funzione factorial()
è mostrata nel seguente esempio di codice scritto in C++.
#include <stdint.h>
extern "C" {
// Calculates the factorial of a non-negative integer n.
uint64_t factorial(unsigned int n) {
uint64_t result = 1;
for (unsigned int i = 2; i <= n; ++i) {
result *= i;
}
return result;
}
}
Per il resto dell'articolo, ipotizza che esista un modulo Wasm basato sulla compilazione di questa funzione factorial()
con Emscripten in un file denominato factorial.wasm
utilizzando tutte le best practice di ottimizzazione del codice.
Per un ripasso su come eseguire questa operazione, consulta
Chiamata di funzioni C compilate da JavaScript utilizzando ccall/cwrap.
Per compilare factorial.wasm
come
Wasm autonomo è stato utilizzato il seguente comando.
emcc -O3 factorial.cpp -o factorial.wasm -s WASM_BIGINT -s EXPORTED_FUNCTIONS='["_factorial"]' --no-entry
In HTML, è presente un form
con un input
accoppiato a un output
e un pulsante di invio
button
. A questi elementi viene fatto riferimento da JavaScript in base ai loro nomi.
<form>
<label>The factorial of <input type="text" value="12" /></label> is
<output>479001600</output>.
<button type="submit">Calculate</button>
</form>
const input = document.querySelector('input');
const output = document.querySelector('output');
const button = document.querySelector('button');
Caricamento, compilazione e istanziazione del modulo
Prima di poter utilizzare un modulo Wasm, devi caricarlo. Sul web, questo avviene tramite l'API fetch()
. Poiché sai che la tua app web dipende dal modulo Wasm per l'attività che richiede un'elevata intensità di risorse della CPU, devi precaricare il file Wasm il prima possibile. Puoi farlo con un
recupero abilitato CORS
nella sezione <head>
della tua app.
<link rel="preload" as="fetch" href="factorial.wasm" crossorigin />
In realtà, l'API fetch()
è asincrona e devi await
il risultato.
fetch('factorial.wasm');
Successivamente, compila e crea un'istanza del modulo Wasm. Esistono funzioni con nomi allettanti chiamate
WebAssembly.compile()
(oltre a
WebAssembly.compileStreaming()
)
e
WebAssembly.instantiate()
per queste attività, ma il metodo
WebAssembly.instantiateStreaming()
compila e esegue l'istanza di un modulo Wasm direttamente da un'origine di base in streaming come fetch()
, senza bisogno di await
. Si tratta del modo più efficiente
e ottimizzato per caricare il codice Wasm. Supponendo che il modulo Wasm esegua l'esportazione di una funzione factorial()
, puoi utilizzarla immediatamente.
const importObject = {};
const resultObject = await WebAssembly.instantiateStreaming(
fetch('factorial.wasm'),
importObject,
);
const factorial = resultObject.instance.exports.factorial;
button.addEventListener('click', (e) => {
e.preventDefault();
output.textContent = factorial(parseInt(input.value, 10));
});
Spostare l'attività in un Web Worker
Se lo esegui nel thread principale, con attività che richiedono un'elevata intensità di risorse della CPU, rischi di bloccare l'intera app. Una pratica comune è spostare queste attività in un Web Worker.
Ristrutturazione del thread principale
Per spostare l'attività ad alta intensità di CPU in un web worker, il primo passaggio consiste nel ristrutturare
l'applicazione. Ora il thread principale crea un Worker
e, a parte questo, si occupa solo di inviare l'input al web worker, quindi di ricevere l'output e di visualizzarlo.
/* Main thread. */
let worker = null;
// When the button is clicked, submit the input value
// to the Web Worker.
button.addEventListener('click', (e) => {
e.preventDefault();
// Create the Web Worker lazily on-demand.
if (!worker) {
worker = new Worker('worker.js');
// Listen for incoming messages and display the result.
worker.addEventListener('message', (e) => {
output.textContent = e.result;
});
}
worker.postMessage({ integer: parseInt(input.value, 10) });
});
Cattivo: l'attività viene eseguita in Web Worker, ma il codice è instabile
Il Web Worker esegue l'inizializzazione del modulo Wasm e, al ricevimento di un messaggio,
esegue l'attività ad alta intensità di CPU e restituisce il risultato al thread principale.
Il problema di questo approccio è che l'inizializzazione di un modulo Wasm con
WebAssembly.instantiateStreaming()
è un'operazione asincrona. Ciò significa
che il codice è instabile. Nel peggiore dei casi, il thread principale invia i dati quando il worker web non è ancora pronto e il worker web non riceve mai il messaggio.
/* Worker thread. */
// Instantiate the Wasm module.
// 🚫 This code is racy! If a message comes in while
// the promise is still being awaited, it's lost.
const importObject = {};
const resultObject = await WebAssembly.instantiateStreaming(
fetch('factorial.wasm'),
importObject,
);
const factorial = resultObject.instance.exports.factorial;
// Listen for incoming messages, run the task,
// and post the result.
self.addEventListener('message', (e) => {
const { integer } = e.data;
self.postMessage({ result: factorial(integer) });
});
Migliore: l'attività viene eseguita in Web Worker, ma con caricamento e compilazione potenzialmente ridondanti
Una soluzione alternativa al problema dell'inizializzazione asincrona del modulo Wasm è spostare il caricamento, la compilazione e l'inizializzazione del modulo Wasm nell'ascoltatore di eventi, ma ciò significa che questo lavoro deve essere eseguito su ogni messaggio ricevuto. Con la memorizzazione nella cache HTTP e la cache HTTP in grado di memorizzare nella cache il bytecode Wasm compilato, questa non è la peggiore delle soluzioni, ma esiste un modo migliore.
Se sposti il codice asincrono all'inizio del web worker e non aspetti che la promessa venga soddisfatta, ma la memorizzi in una variabile, il programma passa immediatamente alla parte del codice relativa all'ascoltatore di eventi e nessun messaggio del thread principale andrà perso. All'interno dell'ascoltatore di eventi, la promessa può essere attesa.
/* Worker thread. */
const importObject = {};
// Instantiate the Wasm module.
// 🚫 If the `Worker` is spun up frequently, the loading
// compiling, and instantiating work will happen every time.
const wasmPromise = WebAssembly.instantiateStreaming(
fetch('factorial.wasm'),
importObject,
);
// Listen for incoming messages
self.addEventListener('message', async (e) => {
const { integer } = e.data;
const resultObject = await wasmPromise;
const factorial = resultObject.instance.exports.factorial;
const result = factorial(integer);
self.postMessage({ result });
});
Buono: l'attività viene eseguita in Web Worker e viene caricata e compilata una sola volta
Il risultato del metodo statico
WebAssembly.compileStreaming()
è una promessa che risolve in un
WebAssembly.Module
.
Una caratteristica interessante di questo oggetto è che può essere trasferito utilizzando
postMessage()
.
Ciò significa che il modulo Wasm può essere caricato e compilato una sola volta nel thread principale (o anche in un altro web worker dedicato esclusivamente al caricamento e alla compilazione) e poi trasferito al web worker responsabile dell'attività che richiede un'elevata intensità di risorse della CPU. Il seguente codice mostra questo flusso.
/* Main thread. */
const modulePromise = WebAssembly.compileStreaming(fetch('factorial.wasm'));
let worker = null;
// When the button is clicked, submit the input value
// and the Wasm module to the Web Worker.
button.addEventListener('click', async (e) => {
e.preventDefault();
// Create the Web Worker lazily on-demand.
if (!worker) {
worker = new Worker('worker.js');
// Listen for incoming messages and display the result.
worker.addEventListener('message', (e) => {
output.textContent = e.result;
});
}
worker.postMessage({
integer: parseInt(input.value, 10),
module: await modulePromise,
});
});
Sul lato del web worker, non resta che estrarre l'oggetto WebAssembly.Module
e crearne un'istanza. Poiché il messaggio con WebAssembly.Module
non viene eseguito in streaming, il codice nel web worker ora utilizza WebAssembly.instantiate()
anziché la variante instantiateStreaming()
precedente. Il modulo sottoposto a istanza viene memorizzato nella cache in una variabile, pertanto l'operazione di istanza deve essere eseguita solo una volta all'avvio del web worker.
/* Worker thread. */
let instance = null;
// Listen for incoming messages
self.addEventListener('message', async (e) => {
// Extract the `WebAssembly.Module` from the message.
const { integer, module } = e.data;
const importObject = {};
// Instantiate the Wasm module that came via `postMessage()`.
instance = instance || (await WebAssembly.instantiate(module, importObject));
const factorial = instance.exports.factorial;
const result = factorial(integer);
self.postMessage({ result });
});
Perfetto: l'attività viene eseguita in un worker web in linea e viene caricata e compilata una sola volta
Anche con la memorizzazione nella cache HTTP, ottenere il codice del web worker (idealmente) memorizzato nella cache e potenzialmente accedere alla rete è costoso. Un trucco comune per migliorare le prestazioni è inserire il web worker in linea e caricarlo come URL blob:
. Ciò richiede comunque che il
modulo Wasm compilato venga passato al web worker per l'instanziazione, poiché i
contesti del web worker e del thread principale sono diversi, anche se
si basano sullo stesso file sorgente JavaScript.
/* Main thread. */
const modulePromise = WebAssembly.compileStreaming(fetch('factorial.wasm'));
let worker = null;
const blobURL = URL.createObjectURL(
new Blob(
[
`
let instance = null;
self.addEventListener('message', async (e) => {
// Extract the \`WebAssembly.Module\` from the message.
const {integer, module} = e.data;
const importObject = {};
// Instantiate the Wasm module that came via \`postMessage()\`.
instance = instance || await WebAssembly.instantiate(module, importObject);
const factorial = instance.exports.factorial;
const result = factorial(integer);
self.postMessage({result});
});
`,
],
{ type: 'text/javascript' },
),
);
button.addEventListener('click', async (e) => {
e.preventDefault();
// Create the Web Worker lazily on-demand.
if (!worker) {
worker = new Worker(blobURL);
// Listen for incoming messages and display the result.
worker.addEventListener('message', (e) => {
output.textContent = e.result;
});
}
worker.postMessage({
integer: parseInt(input.value, 10),
module: await modulePromise,
});
});
Creazione di worker web lazy o eager
Finora, tutti gli esempi di codice hanno avviato il web worker in modo lazy on demand, ovvero quando è stato premuto il pulsante. A seconda dell'applicazione, può essere opportuno creare il web worker in modo più attivo, ad esempio quando l'app è inattiva o anche nell'ambito della procedura di bootstrap dell'app. Pertanto, sposta il codice di creazione del worker web al di fuori dell'event listener del pulsante.
const worker = new Worker(blobURL);
// Listen for incoming messages and display the result.
worker.addEventListener('message', (e) => {
output.textContent = e.result;
});
Mantenere o meno il web worker
Una domanda che potresti porti è se mantenere il web worker permanentemente o ricrearlo ogni volta che ne hai bisogno. Entrambi gli approcci sono possibili e presentano vantaggi e svantaggi. Ad esempio, mantenere un worker web in modo permanente potrebbe aumentare l'impronta di memoria dell'app e complicare il trattamento delle attività concorrenti, poiché in qualche modo devi mappare i risultati provenienti dal worker web alle richieste. D'altra parte, il codice di bootstrap del tuo Web Worker potrebbe essere piuttosto complesso, quindi potrebbe esserci un overhead elevato se ne crei uno nuovo ogni volta. Fortunatamente, questo è un aspetto che puoi misurare con l'API User Timing.
Finora gli esempi di codice hanno mantenuto un Web Worker permanente. Il seguente codice di esempio crea un nuovo Web Worker ad hoc ogni volta che è necessario. Tieni presente che devi monitorare la terminazione del worker web. Lo snippet di codice salta la gestione degli errori, ma se si verifica un problema, assicurati di terminare in tutti i casi, indipendentemente dall'esito.
/* Main thread. */
let worker = null;
const modulePromise = WebAssembly.compileStreaming(fetch('factorial.wasm'));
const blobURL = URL.createObjectURL(
new Blob(
[
`
// Caching the instance means you can switch between
// throw-away and permanent Web Worker freely.
let instance = null;
self.addEventListener('message', async (e) => {
// Extract the \`WebAssembly.Module\` from the message.
const {integer, module} = e.data;
const importObject = {};
// Instantiate the Wasm module that came via \`postMessage()\`.
instance = instance || await WebAssembly.instantiate(module, importObject);
const factorial = instance.exports.factorial;
const result = factorial(integer);
self.postMessage({result});
});
`,
],
{ type: 'text/javascript' },
),
);
button.addEventListener('click', async (e) => {
e.preventDefault();
// Terminate a potentially running Web Worker.
if (worker) {
worker.terminate();
}
// Create the Web Worker lazily on-demand.
worker = new Worker(blobURL);
worker.addEventListener('message', (e) => {
worker.terminate();
worker = null;
output.textContent = e.data.result;
});
worker.postMessage({
integer: parseInt(input.value, 10),
module: await modulePromise,
});
});
Demo
Puoi provare due demo. Uno con un
Web Worker ad hoc
(codice sorgente)
e uno con un
Web Worker permanente
(codice sorgente).
Se apri DevTools di Chrome e controlli la console, puoi vedere i log dell'API UserTiming che misurano il tempo che intercorre tra il clic sul pulsante e il risultato visualizzato sullo schermo. La scheda Rete mostra le richieste URLblob:
. In questo esempio, la differenza di tempo tra le campagne ad hoc e quelle permanenti è di circa tre volte. In pratica, per l'occhio umano, in questo caso entrambe sono indistinguibili. I risultati per la tua app reale molto probabilmente varieranno.
Conclusioni
Questo post ha esplorato alcuni pattern di prestazioni per la gestione di Wasm.
- Come regola generale, preferisci i metodi di streaming (
WebAssembly.compileStreaming()
eWebAssembly.instantiateStreaming()
) rispetto alle relative controparti non in streaming (WebAssembly.compile()
eWebAssembly.instantiate()
). - Se possibile, esternalizza le attività che richiedono un elevato rendimento in un web worker e esegui il caricamento e la compilazione di Wasm solo una volta al di fuori del web worker. In questo modo, il worker web deve solo istanziare il modulo Wasm che riceve dal thread principale in cui sono stati eseguiti il caricamento e la compilazione con
WebAssembly.instantiate()
, il che significa che l'istanza può essere memorizzata nella cache se mantieni il worker web in modo permanente. - Valuta attentamente se ha senso mantenere un Web Worker permanente o creare Web Worker ad hoc ogni volta che sono necessari. Inoltre, pensa al momento migliore per creare il web worker. Gli aspetti da prendere in considerazione sono il consumo di memoria, la durata dell'instanziazione del worker web, ma anche la complessità di dover gestire eventuali richieste concorrenti.
Se prendi in considerazione questi pattern, sei sulla strada giusta per ottenere un rendimento ottimale di Wasm.
Ringraziamenti
Questa guida è stata esaminata da Andreas Haas, Jakob Kummerow, Deepti Gandluri, Alon Zakai, Francis McCabe, François Beaufort e Rachel Andrew.