DEV Community: Gonzalo Ruiz de Villa

Sesgo en Machine Learning: no se trata sólo de los datos

Gonzalo Ruiz de Villa — Sun, 28 Feb 2021 19:56:33 +0000

Hoy en día resulta evidente el gran beneficio que la inteligencia artificial y, en particular, Machine Learning ofrece a la sociedad. Se trata de algo que no para de crecer en temas tan dispares como análisis facial, vehículos autónomos, interpretación de pruebas médicas, optimización de procesos, controles de calidad o determinar cómo se pliegan las proteínas.

Sin embargo, uno de lo principales problemas en los sistemas de aprendizaje automático es que los modelos estén sesgados. El sesgo puede tener unas consecuencias bastante negativas en función del contexto, como por ejemplo, cuando el algoritmo aplica criterios racistas o misóginos en sus predicciones. Hay ya demasiados ejemplos de estos problemas y por ello es muy importante entender cómo se producen estos sesgos y cómo combatirlos.

Hay una creencia generalizada de que el sesgo algorítmico es un problema exclusivo de los datos. Si los datos usados para entrenar tienen sesgo, el sesgo será aprendido por el modelo y, por lo tanto, eliminando o corrigiendo el sesgo presente en los datos tendrá como consecuencia la corrección del sesgo del modelo. Esto es verdad pero no es toda la verdad. Puede haber otras causas que acentúen este problema.
Veamos algunos ejemplos de cómo otras cosas pueden incrementar el sesgo dado un mismo conjunto de datos.

Poda y cuantificación de redes neuronales (pruning and quantification)

La poda y la cuantificación de redes neuronales son recursos cada vez más populares por las limitaciones de los entornos de ejecución en términos de latencia, memoria y energía.

Las técnicas de cuantificación consiguen una compresión muy significativa mientras el impacto en las métricas de desempeño mas populares suele ser insignificante. La cuantificación es una técnica de aproximación de una red neuronal que utiliza números de punto flotante mediante otra red neuronal que usa números de menor precisión. Esto reduce drásticamente tanto el requisito de memoria como el coste computacional del uso de redes neuronales. Sin embargo, si bien es cierto que la precisión general no se vea afectada, esta apreciación oculta un error desproporcionadamente alto en pequeños subconjuntos de datos. En esta publicación, titulada “Characterising Bias in Compressed Models”, Sara Hooker de Google Brain y otros exploran este tema y proponen técnicas para detectar este potencial problema. A este subconjunto de datos lo llaman Ejemplares Identificados por Compresión (CIE del inglés Compression Identified Exemplars) y establecen que para estos subconjuntos, la compresión amplifica enormemente el sesgo algorítmico existente.

Fuente: https://arxiv.org/pdf/2010.03058.pdf

De forma parecida, la poda de redes neuronales reducen el tamaño de la red sin apenas impacto en las métricas de la red neuronal, pero también pueden incrementar de forma desproporcionada el error en pequeños subconjuntos de datos infra-representados, en este caso llamados PIE (Pruning Identified Exemplars). En “What Do Compressed Deep Neural Networks Forget?” se muestra cómo se produce una sobre indexación en los PIE y proponen una metodología para detectar los ejemplos atípicos para tomar medidas adecuadas.

Fuente: https://arxiv.org/pdf/1911.05248.pdf

Los ejemplos difíciles se aprenden más tarde

En este artículo, "Estimating Example Difficulty Using Variance of Gradients", Chirag Agarwal, Sara Hooker definen una puntuación escalar como proxy para medir cómo de complicado es para una red neuronal aprender un ejemplo concreto. Usando esta puntuación que llaman Variance of Gradients (VOG) pueden ordenar los datos de entrenamiento según su dificultad para ser aprendidos.

Fuente: https://arxiv.org/pdf/2008.11600.pdf

En redes con exceso de parámetros se ha visto que se puede llegar a cero errores mediante la memorización de ejemplos. Esta memorización se produce más tarde durante el entrenamiento y las técnicas propuestas en el artículo ayuda a discriminar que elementos del dataset son especialmente difíciles y deben, por tanto, ser memorizados. La memorización de datos puede presentar riesgos de privacidad cuando los datos tienen información sensible. Es interesante destacar que medidas como VOG permiten detectar datos atípicos o out-of-distribution (OOD).

Modelos que garantizan la privacidad diferencial tienen un efecto dispar en la precisión del modelo

La privacidad diferencial (Differential privacy o DP) en machine learning es un mecanismo de entrenamiento que minimiza las fugas de datos sensibles presentes en los datos de entrenamiento. Sin embargo, el coste de la privacidad diferencial es una reducción en la precisión del modelo que no afecta por igual a todos los ejemplos. La precisión sobre los que pertenecen a clases o grupos infrarrepresentados tiene una caída mucho mayor.

En “Differential Privacy Has Disparate Impact on Model Accuracy” demuestran como, por ejemplo, la clasificación de género tiene una precisión muy inferior en caras negras que en caras blancas y que en un modelo DP el gap de precisión es mucho mayor que en el modelo no-DP. Es decir, si el modelo original no es justo, esta característica se acentúa en el modelo con privacidad diferencial.

Fuente: https://arxiv.org/pdf/1905.12101.pdf

Conclusión

En los ejemplos anteriores se observa que combatir el sesgo en los modelos no es algo que se resuelva exclusivamente a nivel de datos (es importante notar que estos ejemplos distan mucho de ser exhaustivos). Al aplicar distintas técnicas populares sobre los modelos, se puede acentuar inadvertidamente el sesgo de los modelos. Entender, primero, y medir, después, este efecto negativo son los pasos necesarios para poder tomar las acciones adecuadas de corrección o compensación.

Fuentes

Characterising Bias in Compressed Models [https://arxiv.org/abs/2010.03058] Sara Hooker, Nyalleng Moorosi, Gregory Clark, Samy Bengio, Emily Denton
What Do Compressed Deep Neural Networks Forget? [https://arxiv.org/abs/1911.05248] Sara Hooker, Aaron Courville, Gregory Clark, Yann Dauphin, Andrea Frome
Estimating Example Difficulty Using Variance of Gradients [https://arxiv.org/abs/2008.11600] Chirag Agarwal, Sara Hooker
Characterizing Structural Regularities of Labeled Data in Overparameterized Models [https://arxiv.org/abs/2002.03206] Ziheng Jiang, Chiyuan Zhang, Kunal Talwar, Michael C. Mozer
Differentially Private Fair Learning [http://proceedings.mlr.press/v97/jagielski19a/jagielski19a.pdf] Matthew Jagielski, Michael Kearns, Jieming Mao. Alina Oprea, Aaron Roth, Saeed Sharifi-Malvajerdi, Jonathan Ullman
Differential Privacy Has Disparate Impact on Model Accuracy [https://arxiv.org/abs/1905.12101] Eugene Bagdasaryan, Vitaly Shmatikov
Does Learning Require Memorization? A Short Tale about a Long Tail [https://arxiv.org/abs/1906.05271] Vitaly Feldman

Magic refactoring with Unison: much more than a new programming language

Gonzalo Ruiz de Villa — Wed, 18 Dec 2019 16:35:10 +0000

I recognise it, I am obsessed with refactoring. When I program, I keep changing the names of the variables, methods or classes again and again. Or, for example, there are no functions to which the arguments do not change without stopping, until finally I am slightly satisfied. I always have the feeling that something more can and should be done.

That is why I was surprised by the refactoring capacity of this new programming language called Unison. As I said, I rename things obsessively, but this has a cost. For example, when renaming a function, you have to modify all references, or, what is the same, you have to modify all the files where there are functions or methods that invoke the renamed function. Let’s say that in the project there are a thousand files with calls to that function: this implies that after the renamed, in the code commit, of the 1001 files it will contain, only one will have a relevant change, while the changes in the rest of the files only generate noise. But… could it be otherwise?

And, of course, the answer is yes (otherwise this article would not make sense, right? 🤷🏼‍♀️).

In Unison, to change the name of a function, we use the move command:

 .> move.term base.List.foldl base.List.foldLeft

If we now review the implementation of a function that uses the old foldl, now renamed as foldLeft, we see that Unison’s magic has already done its work:

.> view base.List.reversebase.List.reverse : [a] -> [a] 
base.List.reverse as = 
  use base.List +: 
  base.List.foldLeft (acc a -> a +: acc) [] as

When you rename a function with Unison, all references are instantly corrected. But in order to do so, what Unison is not going to do is to mutate texts on your behalf, updating thousands of files, generating a gigantic diff and breaking the libraries of users who expect the function to continue using the old name. What a madness, right?

Unison is a typed language largely influenced by Haskell, Erlang and a research language called Frank. There is a very simple and basic idea on which Unison relies: to identify definitions not by name but by content. That is, if we define a factorial function as the product of the natural numbers between 1 and a given number n, it will not matter if the name that we give the function is “factorial”, “lairotcaf” or something else. Similarly, it is completely unimportant if the parameter is called “n”, “z” or any other name: the function does not change in its essence.

What Unison does is the following: first, Unison calculates the hash of the implementation. Second, instead of storing text files, what you save in the code base is the abstract syntax tree (AST) of the function, where references to other functions are made using the corresponding hashes. In this way, a management of the base code is achieved that allows, among other things, the following:

not having to recompile anything
trivial renaming
cache test results
eliminate dependency conflicts
persistent typing and simple storage

The Unison base code manager is the piece that makes all these things possible by storing the AST and becoming the only source of truth and not relying on textual representations found in text files. The base code manager has some very interesting properties:

append-only: definitions are never modified or deleted, only new ones are added.
as a result of the above, it can be versioned and synchronised with Git or similar tools without generating conflicts.
as it can only be added, many types of information can be cached without worrying about the expiration of the cache.
the names are stored separately from the definitions, so renaming is very fast and 100% accurate. In addition, aliases can be added easily.

I believe this comment by the creators of the language is very clarifying:

// Detect dark theme var iframe = document.getElementById('tweet-1123289581959434241-58'); if (document.body.className.includes('dark-theme')) { iframe.src = "https://platform.twitter.com/embed/Tweet.html?id=1123289581959434241&theme=dark" }

Unison provides some files, the scratch files, where you can explore the codebase definitions and make and test the changes before saving them in the codebase manager.

Another of the motivations behind Unison’s design that I have found especially interesting is to be able to accurately describe programs that can be deployed on their own and to describe distributed elastic systems.

For example, look at the following merge sort implementation:

dsort: (a -> a -> Boolean) -> [a] -> {Remote} [a]
dsort lte as =
  if size as < 2 then as
  else case halve as of (left, right) ->
    resL = at spawn ‘(dsort lte left)
    resR = at spawn ‘(dsort lte right)
    merge lte (force resL) (force resR)

It seems a typical implementation of in memory sort, where the list is divided into halves that are ordered and then the results are mixed. The particular thing about this implementation is that recursive calls are being made in parallel in two different newly provisioned computing resources.

This is part of the magic that Unison promises: distributed programs without configurations, without JSONs, without network connection management, etc. Just add annotations to the code where you want concurrent or distributed executions and then Unison will do its magic.

Conclusion

Unison is a very interesting bet that is testing new concepts. I don’t know if it will have much of a future or not, but what it, undoubtedly, is already doing is helping to rethink how we approach certain aspects of software development with programming languages. It is not only a new syntax, but rather a more ambitious effort.

References

The Unison Language https://www.unisonweb.org/
“Unison: a new distributed programming language” by Paul Chiusano https://www.youtube.com/watch?v=gCWtkvDQ2ZI
Lambda World 2018 — Introduction to the Unison programming language — Rúnar Bjarnason https://www.youtube.com/watch?v=rp_Eild1aq8

Refactorización mágica con Unison: algo más que un nuevo lenguaje de programación

Gonzalo Ruiz de Villa — Mon, 25 Nov 2019 11:05:20 +0000

Lo reconozco, soy un obseso de la refactorización. Cuando programo, no dejo de cambiar los nombre de las variables, los métodos o las clases. O, por ejemplo, no hay funciones a las que no les cambie los argumentos sin parar, hasta que por fin me quede ligeramente satisfecho. Siempre me quedo con la sensación de que se puede hacer algo más.

Por eso, me sorprendió la capacidad de refactorización que tiene de este nuevo lenguaje de programación llamado Unison. Como he dicho, renombro las cosas obsesivamente, pero esto tiene un coste. Por ejemplo, al renombrar una función, hay que modificar todas las referencias, o lo que es lo mismo, hay tocar todos los ficheros donde haya funciones o métodos que invoquen la función renombrada. Pongamos que en el proyecto hay mil ficheros con llamadas a dicha función: esto implica que tras el renombrado, en el commit, de los 1001 ficheros que contiene, solo uno tiene un cambio relevante, mientras que los cambios en el resto de ficheros solo generan ruido. Pero, ¿podría acaso ser de otra forma?

Y, evidentemente, la respuesta es si (si no este artículo no tendría sentido, ¿no? 🤷🏼‍♀️).

En Unison, para cambiar el nombre de una función, usamos el comando move:

.> move.term base.List.foldl base.List.foldLeft

Si ahora revisamos la implementación de una función que use la antigua foldl, ahora foldLeft, vemos que la magia ya ha hecho su efecto:

.> view base.List.reverse
base.List.reverse : [a] -> [a] 
base.List.reverse as = 
  use base.List +: 
  base.List.foldLeft (acc a -> a +: acc) [] as

Al renombrar una función con Unison, instantáneamente todas las referencias quedan corregidas. Pero para hacerlo, lo que no va a hacer Unison es mutar textos en tu nombre, actualizando miles de ficheros, generando un diff gigantesco y rompiendo las librerías de usuarios que esperan que la función siga usando el nombre antiguo. Menuda locura ¿no?

Unison es un lenguaje tipado muy influenciado por Haskell, Erlang y un lenguaje de investigación llamado Frank. Hay una idea de fondo muy sencilla sobre la que se apoya Unison: identificar las definiciones no por su nombre sino por su contenido. Es decir, si definimos una función factorial como el producto de los números naturales entre 1 y un número dado n, no importará si el nombre con el que definimos la función es “factorial”, “lairotcaf” o cualquier otra cosa. De igual manera, no tiene ninguna importancia que el parámetro se llame “n”, “z” o cualquier otro nombre: la función no cambia en su esencia.

Lo que hace Unison es lo siguiente: primero, Unison calcula el hash de la implementación. Segundo, en lugar de almacenar ficheros de texto, lo que guardar es el abstract syntax tree de la función, donde las referencias a otras funciones se realiza mediante los correspondientes hashes. De esta forma, se consigue una gestión del código base que permite entre otras cosas:

no tener que recompilar nada
renombrar de forma trivial
cachear los resultados de los tests
eliminar los conflictos de dependencias
almacenamiento persistente tipado y sencillo

El gestor de código base de Unison es la pieza que posibilita todas estas cosas al almacenar el AST y convertirse en la única fuente de la verdad y no representaciones textuales en ficheros de texto. El gestor de código base tiene unas propiedades muy interesantes:

append-only: nunca se modifican o borran las definiciones, solo se añaden nuevas.
como resultado de lo anterior, se puede versionar y sincronizar con Git o herramientas similares sin generar conflictos. como solo se puede añadir, se pueden cachear muchos tipos de información sin preocuparse por la caducidad de la cache.
los nombres se almacenan separados de las definiciones, por lo que renombrar es rapidísimo y preciso al 100%. Además, se pueden agregar alias fácilmente.

Unison proporciona unos ficheros, los scrach files, donde puedes explorar las definiciones del codebase y realizar y probar los cambios antes de guardarlos en el codebase manager.

Otra de las motivaciones detrás de Unison que he encontrado muy interesante es la de poder describir de forma precisa programas que se puedan desplegar por sí mismos y describir sistemas elásticos distribuidos. Por ejemplo, observa la siguiente implementación de merge sort:

dsort: (a -> a -> Boolean) -> [a] -> {Remote} [a]
dsort lte as =
  if size as < 2 then as
  else case halve as of (left, right) ->
    resL = at spawn '(dsort lte left)
    resR = at spawn '(dsort lte left)
    merge lte (force resL) (force resR)

Parece una implementación típica en memoria, donde se divide la lista en mitades que se ordenan y entonces se mezclan los resultados. Lo particular es que las llamadas recursivas se están haciendo en paralelo en dos nuevos y recién aprovisionados recursos computacionales.

Esta es parte de la magia que promete Unison, programas distribuidos sin configuraciones, sin JSONs, sin gestión de conexiones de red, etc. Solo código anotando donde quieres ejecución concurrente o distribuida y Unison hace su magia.

Conclusión

Unison es una apuesta muy interesante que prueba conceptos nuevos. No se si tendrá mucho futuro o no, pero lo que que sin duda ya está haciendo es ayudar a replantear como enfocamos ciertos aspectos del desarrollo de software con los lenguajes de programación. No se trata de una sintaxis nueva, sino de ejercicio bastante más ambicioso.

Referencias

The Unison Language https://www.unisonweb.org/
“Unison: a new distributed programming language” by Paul Chiusano https://www.youtube.com/watch?v=gCWtkvDQ2ZI
Lambda World 2018 — Introduction to the Unison programming language — Rúnar Bjarnason https://www.youtube.com/watch?v=rp_Eild1aq8

AssemblyScript: making WebAssembly more accessible to JavaScript programmers

Gonzalo Ruiz de Villa — Fri, 20 Sep 2019 09:17:37 +0000

tl;dr This is an introduction to AssemblyScript: I explain what WebAssembly is, why AssemblyScript maybe an interesting alternative to build WebAssembly for JavaScript developers and, finally, in order to compare JavaScript to AssemblyScript, I comment a small image manipulation project I’ve developed for this purpose.

WebAssembly is one of the biggest revolutions coming to the web, although it is neither Web nor Assembly. WebAssembly, also known as Wasm, is a fast, efficient, safe and low-level bytecode for the Web.

This means that, on one hand, it isn’t an assembly language but bytecode instead. Although both of them are similar in the sense that they are not high-level languages, they are easily understandable, which is something that does not happen with machine code. Thus, they can be classified into an intermediate language category between high-level languages and machine code. The main difference between assembly language and bytecode is that, the first one is created for CPUs while the second is created for virtual machines. That is, one is targeting hardware whereas the other is targeting software.

There is indeed a bytecode textual version, which is named WebAssembly Text Format (or just Wat!).

Additionally, although it’s usually said that Wasm is for the Web, the truth is that it’s not just for the web, because it can be also used for desktop applications, serverless or, even, Crypto and Smart Contracts.

Efficient

WebAssembly was designed to have a binary file format that is easy to download and to compile to machine code. It also allows the code to be compiled at the same time that it is being downloaded. This feature is called Streaming Compilation.

Using a Wasm module from JavaScript is as simple as it follows:

async function run() {
  const {instance} = await WebAssembly.instantiateStreaming(
    fetch("./add.wasm"),
    env: { abort: () => console.log("Abort!") }
  );
  const r = instance.exports.add(1, 2);
  console.log(r);
}
run();

The following way to load a Wasm module suggested by Das Surma will allow you to use Streaming Compilation robustly. It will work even if the Content-Type is not correctly set to application/wasm (Firefox will normally fail, for instance), or even, if you are using Safari (which does not support instantiateStreaming yet).

async function maybeInstantiateStreaming(path, ...opts) {
  // Start the download asap.
  const f = fetch(path);
  try {
    // This will throw either if `instantiateStreaming` is
    // undefined or the `Content-Type` header is wrong.
    return WebAssembly.instantiateStreaming(
      f,
      ...opts
    );
  } catch(_e) {
    // If it fails for any reason, fall back to downloading
    // the entire module as an ArrayBuffer.
    return WebAssembly.instantiate(
      await f.then(f => f.arrayBuffer()),
      ...opts
     );
  }
}

There has been a lot of work on the Web in order to provide a safe environment that protects us from malicious intentions, and Wasm was designed with the same principles. For instance, as JavaScript does too, Wasm is executed in sandboxed environments that keeps it isolated from production environment. As a consequence, for example, it is necessary to use Web File API to access the file system, which is exactly how it needs to be done with JavaScript.

Bytecode

What were the main goals for Wasm design? To be codified in a binary code (very efficient, from the size and loading time point of view), to be executed at native speeds and, also, to take advantage of the common hardware capabilities available in different platforms.

In order to achieve these goals, the authors of Wasm had to build something new (using asm.js as the starting point) instead of using LLVM, Java or .Net bytecode. There fore, they developed a new binary instruction designed to be a portable target for compilation of high level languages like C, C++ or Rust.

“Wat” should I do if I want to program WebAssembly?

One can never know too much, so if you want to learn Wat, go ahead! Nevertheless, if you like JavaScript, look at the following example and correct me if I’m wrong when I say that you would like an alternative to Wat:

(;
  Filename: add.wat
  This is a block comment.
;)
(module
  (func $add (param $p1 i32) (param $p2 i32) (result i32)
    local.get $p1 ;; Push parameter $p1 onto the stack
    local.get $p2 ;; Push parameter $p2 onto the stack
    i32.add ;; Pop two values off the stack and push their sum
    ;; The top of the stack is the return value
  )
  (export "add" (func $add))
)

AssemblyScript

AssemblyScript compiles a strict subset of TypeScript (a typed superset of JavaScript) to WebAssembly. That means that we can take advantage of the JavaScript knowledge to develop Wasm.

In order to illustrate how similar JavaScript and AssemblyScript are, I’ve prepared this small project where I manipulate a picture with code in vanilla JavaScript and in AssemblyScript compiled to Wasm. You can find it here: [https://github.com/gonzaloruizdevilla/image-manipulation-assemblyscript]

In the project, you will see a picture that it’s loaded inside an html canvas and several buttons that will apply different filters to the pictures when clicked. These buttons will execute the filter either with JavaScript or with the Wasm module generated with AssemblyScript.

Applying the different filters we obtain images like these:

In order to use the project, just clone it from Github, and then install AssemblyScript dependency and compile index.ts AssemblyScript file with the following instructions:

npm install
npm run asbuild

It´s interesting to note that, when a Wasm function is called from JavaScript code, the arguments of the call must be of the following types:

i32: 32-bit integer
i64: 64-bit integer
f32: 32-bit float
f64: 64-bit float

Obviously, that means that we can’t pass the image as an argument of the call. In order to be able to use a picture’s information from Wasm, first, it should be stored in a shared area of the memory that it will be created using the WebAssembly.Memory class. This shared memory object is used as an argument of the Wasm instantiating function as you can see in the following code:

//A memory created by JavaScript or in WebAssembly code will be accessible and mutable from both JavaScript and WebAssembly.

const memory = new WebAssembly.Memory({ initial:initial * 2 });

//Instantiating Wasm module

const importObject = { env: { memory, abort: () => console.log("Abort!") }};
const {instance} = await WebAssembly.instantiateStreaming(
    fetch("./build/untouched.wasm"),
    importObject
);

//Creating a typed array reference to write into the memory buffer
const mem = new Uint8Array(memory.buffer);

Before calling a Wasm filter, the picture data in the canvas is retrieved and copied into the shared memory. After that, the Wasm filter is called, then the result is read and stored in imageData. Finally, we send imageData to canvas context, redrawing the images.

JavaScript version

//retrieve image pixels (4 bytes per pixel: RBGA)
const data = imageData.data;
//copy to bytes to shared memory
mem.set(data);

//invoque 'fn'  Wasm filter. We need to inform of the image byte size
const byteSize = data.length;
instance.exports[fn](byteSize, ...args);

//copy the response from the shared memory into the canvas imageData
data.set(mem.slice(byteSize, 2*byteSize))
//update canvas
ctx.putImageData(imageData, 0, 0);

There are four different filter functions implemented in both JavaScript and AssemblyScript: invert, grayscale, sepia and convolve (this one is used to apply the blur, edge detection and emboss filters). As you can see below, they are very similar:

function invert(data) {
    for (var i = 0; i < data.length; i += 4) {
        data[i]     = 255 - data[i];     
        data[i + 1] = 255 - data[i + 1]; 
        data[i + 2] = 255 - data[i + 2]; 
    }
};

function grayscale(data){
    for (var i = 0; i < data.length; i += 4) {
        const avg = 0.3  * data[i] + 0.59 * data[i + 1] + 0.11 * data[i + 2];
        data[i]     = avg;  
        data[i + 1] = avg; 
        data[i + 2] = avg; 
    }
}

function sepia(data){
    for (var i = 0; i < data.length; i += 4) {
        const avg = 0.3  * data[i] + 0.59 * data[i + 1] + 0.11 * data[i + 2];
        data[i]     = avg + 100;  
        data[i + 1] = avg + 50; 
        data[i + 2] = avg; 
    }
}

function addConvolveValue(pos, i, data, length){
    return pos >= 0 && pos < length ? data[pos] : data[i];
}

function convolve(data, w, offset, v00, v01, v02, v10, v11, v12, v20, v21, v22){
    console.log( w, offset, v00, v01, v02, v10, v11, v12, v20, v21, v22)
    const divisor = (v00 + v01 + v02 + v10 + v11 + v12 + v20 + v21 + v22) || 1;
    const length = data.length;
    let res = 0;
    let newData = new Uint8Array(length)
    for(let i = 0; i < length; i++){
        if ((i + 1) % 4 === 0) {
            newData[i] = data[i];
            continue;
        }
        let res = v00 * addConvolveValue(i - w * 4 - 4, i, data, length) +
                    v01 * addConvolveValue(i - w * 4, i, data, length) +
                    v02 * addConvolveValue(i - w * 4 + 4, i, data, length) +
                    v10 * addConvolveValue(i - 4, i, data, length) +
                    v11 * data[i] +
                    v12 * addConvolveValue(i + 4, i, data, length) +
                    v20 * addConvolveValue(i + w * 4 - 4, i, data, length) +
                    v21 * addConvolveValue(i + w * 4 , i, data, length) +
                    v22 * addConvolveValue(i + w * 4 + 4, i, data, length);
        res /= divisor;
        res += offset;
        newData[i] = res;
    }
    data.set(newData)
}

AssemblyScript version

/// <reference path="../node_modules/assemblyscript/dist/assemblyscript.d.ts" />

export function invert(byteSize: i32): i32 {
  for (var i = 0; i < byteSize; i += 4) {
    let pos = i + byteSize; 
    store<u8>(pos, 255 - load<u8>(i));
    store<u8>(pos + 1, 255 - load<u8>(i + 1));
    store<u8>(pos + 2, 255 - load<u8>(i + 2));
    store<u8>(pos + 3, 255);
  }
  return 0;
}


export function grayscale(byteSize: i32): i32 {
  for (var i = 0; i < byteSize; i += 4) {
    let pos = i+byteSize;
    const avg = u8(0.3  *  load<u8>(i) + 0.59 * load<u8>(i + 1) + 0.11 * load<u8>(i + 2));
    store<u8>(pos, avg);
    store<u8>(pos + 1, avg);
    store<u8>(pos + 2, avg);
    store<u8>(pos + 3, 255);
  }
  return 0;
}

export function sepia(byteSize: i32): i32 {
  for (var i = 0; i < byteSize; i += 4) {
    let pos = i+byteSize;
    const avg = 0.3  *  load<u8>(i) + 0.59 * load<u8>(i + 1) + 0.11 * load<u8>(i + 2);
    store<u8>(pos, u8(min(avg + 100, 255)));
    store<u8>(pos + 1, u8(min(avg + 50, 255)));
    store<u8>(pos + 2, u8(avg));
    store<u8>(pos + 3, 255);
  }
  return 0;
}

@inline
function addConvolveValue(pos:i32, oldValue:u8, length:i32): i32 {
  return pos >= 0 && pos < length ? load<u8>(pos) : oldValue;
}

export function convolve(byteSize:i32, w:i32, offset:i32, v00:i32, v01:i32, v02:i32, v10:i32, v11:i32, v12:i32, v20:i32, v21:i32, v22:i32): i32 {
  let divisor = (v00 + v01 + v02 + v10 + v11 + v12 + v20 + v21 + v22) || 0;
  if (divisor === 0) {
    divisor = 1;
  }
  for(let i = 0; i < byteSize; i++){
      if ((i + 1) % 4 === 0) {
        store<u8>(i+byteSize, load<u8>(i));

      } else {
        let oldValue = load<u8>(i);
        let prev = i - w * 4;
        let next = i + w * 4;
        let res = v00 * addConvolveValue(prev - 4, oldValue, byteSize)  +
                  v01 * addConvolveValue(prev, oldValue, byteSize)      +
                  v02 * addConvolveValue(prev + 4, oldValue, byteSize)  +
                  v10 * addConvolveValue(i - 4, oldValue, byteSize)     +
                  v11 * oldValue +
                  v12 * addConvolveValue(i + 4, oldValue, byteSize)     +
                  v20 * addConvolveValue(next - 4, oldValue, byteSize)  +
                  v21 * addConvolveValue(next , oldValue, byteSize)     +
                  v22 * addConvolveValue(next + 4, oldValue, byteSize);
        res /= divisor;
        res += offset;
        store<u8>(i+byteSize, u8(res));
      }
  }
  return 0;
}

As you can see, the AssemblyScript code is extremely similar, but with types and working at a lower level, and this is what allows developers to leverage all the Wasm potential. So, now, it’s your turn to start playing with AssemblyScript and grow your confidence on Wasm technology, which is meant to become more and more important in web development in the coming years!

Introducción a AssemblyScript: cómo hacer WebAssembly más fácil para programadores de JavaScript

Gonzalo Ruiz de Villa — Sat, 07 Sep 2019 18:07:10 +0000

tl;dr Introducción a AssemblyScript: explico qué es WebAssembly, por qué AssemblyScript es una alternativa de construcción de WebAssebly interesante para programadores de JavaScript y comento un sencillo proyecto de manipulación de imágenes que permite comparar las implementaciones de JavaScript y AssemblyScript.

WebAssembly es una de las grandes revoluciones que llegan a la web, aunque no es Web ni es Assembly. WebAssembly, también conocido como Wasm, es un bytecode eficiente, seguro y de bajo nivel para la Web.

Es decir, por un lado no es un lenguaje ensamblador sino bytecode. Aunque ambos son similares en el sentido de que aunque no son lenguajes de alto nivel, se pueden entender razonablemente, cosa que no pasa con el código máquina. Esto los coloca en una categoría de lenguajes intermedios entre los lenguajes de alto nivel y el código máquina. La principal diferencia entre el lenguaje ensamblador y el bytecode es que el primero se crea para las CPUs y el segundo para máquinas virtuales, es decir, uno para hardware y otro para software.

Por cierto, existe una versión textual del bytecode llamada WebAssembly Text Format o Wat para abreviar.

Y además, aunque se dice que es para la Web, no es sólo para la Web ya que se puede usar para aplicaciones de escritorio, serverless o, incluso, para Crypto y Smart contracts.

Efficiente

WebAssembly fue diseñado para tener un formato de fichero binario muy compacto, rápido de descargar y de compilar a código máquina. Tanto es así que, además, permite incluso compilar el código a la vez que se está descargando. Esta característica se llama Streaming Compilation.

Usar un módulo de Wasm desde JavaScript es tan sencillo como:

async function run() {
  const {instance} = await WebAssembly.instantiateStreaming(
    fetch("./add.wasm"),
    env: { abort: () => console.log("Abort!") }
  );
  const r = instance.exports.add(1, 2);
  console.log(r);
}
run();

La siguiente forma de cargar módulos Wasm propuesta por Das Surma https://dassur.ma/things/raw-wasm/ te permitirá usar de forma robusta el Streaming Compilation. Funcionando aunque el Content-Type no esté correctamente establecido a application/wasm (que hace que falle en Firefox, por ejemplo) o si usas Safari (que todavía no soporta instantiateStreaming)

async function maybeInstantiateStreaming(path, ...opts) {
  // Start the download asap.
  const f = fetch(path);
  try {
    // This will throw either if `instantiateStreaming` is
    // undefined or the `Content-Type` header is wrong.
    return WebAssembly.instantiateStreaming(
      f,
      ...opts
    );
  } catch(_e) {
    // If it fails for any reason, fall back to downloading
    // the entire module as an ArrayBuffer.
    return WebAssembly.instantiate(
      await f.then(f => f.arrayBuffer()),
      ...opts
     );
  }
}

Seguro

Se ha trabajado mucho en la Web para proporcionar un entorno seguro que nos proteja de intenciones maliciosas, y Wasm continúa en la misma línea. Por ejemplo, al igual que JavaScript se ejecuta en un entorno Sandbox que lo aísla del entorno de producción. Como consecuencia de esto, para acceder al file system se tiene usar la Web File Api al igual que se haría en JavaScript.

Bytecode

Los principales objetivos en el diseño de Wasm fueron que pudiera ser codificado en un formato binario muy eficiente desde el punto de vista del tamaño y del tiempo de carga a la par que pudiese ejecutarse a velocidades nativas y pudiese, además, aprovecharse de las capacidades de hardware comunes de un amplio espectro de plataformas.

Estos objetivos fueron los que obligaron a construir algo nuevo (usando asm.js como punto de partida) en lugar de usar LLVM, el bytecode de Java o .Net. De esta manera, se diseñó un nuevo formato de instrucciones binario que es un objetivo de compilación para lenguajes de alto nivel como C, C++ o Rust.

`Wat` should I do if I want to program WebAssembly?

El saber no ocupa lugar, así que si te apetece aprender Wat ¡adelante!, aunque inspeccionando el siguiente código, probablemente si dominas JavaScript te gustaría alguna alternativa más sencilla:

(;
  Filename: add.wat
  This is a block comment.
;)
(module
  (func $add (param $p1 i32) (param $p2 i32) (result i32)
    local.get $p1 ;; Push parameter $p1 onto the stack
    local.get $p2 ;; Push parameter $p2 onto the stack
    i32.add ;; Pop two values off the stack and push their sum
    ;; The top of the stack is the return value
  )
  (export "add" (func $add))
)

Si lo tuyo es JavaScript, entonces C, C++, Rust y lenguajes similares probablemente tampoco te resultarán atractivas, aunque probablemente será cuestión de tiempo que esa situación cambie. Afortunadamente, mientras tanto, existe una alternativa que sí te encajará: AssemblyScript

AssemblyScript

AssemblyScript (AS) es un subconjunto de TypeScript que es a su vez JavaScript con tipos. Este subconjunto de TypeScript se puede compilar a Wasm fácilmente, con lo que podemos aprovechar los conocimientos de JavaScript para desarrollar Wasm.

Para ilustrar cuánto se parecen JavaScript y TypeScript, he preparado este pequeño proyecto en el que manipulo una imagen tanto con JavaScript como con TypeScript. Puedes encontrarlo aquí: https://github.com/gonzaloruizdevilla/image-manipulation-assemblyscript

En el proyecto se muestra una imagen que se carga dentro de un canvas y varios botones que aplicarán distintos filtros a la imagen. Los botones ejecutarán el filtro con JavaScript o con Wasm generado con AssemblyScript:

Aplicando los filtros obtendremos imágenes como estas:

Para usar el proyecto, tras clonarlo de Github, puedes instalar la dependencia de AssemblyScript y compilar el fichero de AssemblyScript index.ts con las siguientes instrucciones:

npm install
npm run asbuild

Es interesante hacer notar que cuando se invocan funciones de Wasm desde JavaScript, los argumentos de la llamada solo pueden ser de los siguientes tipos:

i32: 32-bit integer
i64: 64-bit integer
f32: 32-bit float
f64: 64-bit float

Evidentemente, no podemos pasar la imagen a través de un argumento de la llamada a Wasm. Por lo tanto, para poder enviar la información de la imagen a Wasm, primero hay que dejarla en una zona compartida de memoria entre el contexto de JavaScript y Wasm que se crea instanciando la clase WebAssembly.Memory. Después dicha instancia se usa al instanciar el módulo Wasm, como puedes ver a continuación:

//A memory created by JavaScript or in WebAssembly code will be accessible and mutable from both JavaScript and WebAssembly.

const memory = new WebAssembly.Memory({ initial:initial * 2 });

//Instantiating Wasm module

const importObject = { env: { memory, abort: () => console.log("Abort!") }};
const {instance} = await WebAssembly.instantiateStreaming(
    fetch("./build/untouched.wasm"),
    importObject
);

//Creating a typed array reference to write into the memory buffer
const mem = new Uint8Array(memory.buffer);

Antes de invocar a Wasm, copiamos los datos de la imagen del canvas en la memoria compartida. Después invocamos al filtro de Wasm, leemos la respuesta y la guardamos en imageData y, por último, enviamos imageData al contexto del canvas para que la imagen se pinte de nuevo.

//retrieve image pixels (4 bytes per pixel: RBGA)
const data = imageData.data;
//copy to bytes to shared memory
mem.set(data);

//invoque 'fn'  Wasm filter. We need to inform of the image byte size
const byteSize = data.length;
instance.exports[fn](byteSize, ...args);

//copy the response from the shared memory into the canvas imageData
data.set(mem.slice(byteSize, 2*byteSize))
//update canvas
ctx.putImageData(imageData, 0, 0);

En el proyecto , hay cuatro funciones de manipulación tanto en JavaScript como en AssemblyScript: invert, grayscale, sepia y convolve (esta última para aplicar los filtros de blur, edge detection y emboss). Como podemos ver son muy similares:

function invert(data) {
    for (var i = 0; i < data.length; i += 4) {
        data[i]     = 255 - data[i];     
        data[i + 1] = 255 - data[i + 1]; 
        data[i + 2] = 255 - data[i + 2]; 
    }
};

function grayscale(data){
    for (var i = 0; i < data.length; i += 4) {
        const avg = 0.3  * data[i] + 0.59 * data[i + 1] + 0.11 * data[i + 2];
        data[i]     = avg;  
        data[i + 1] = avg; 
        data[i + 2] = avg; 
    }
}

function sepia(data){
    for (var i = 0; i < data.length; i += 4) {
        const avg = 0.3  * data[i] + 0.59 * data[i + 1] + 0.11 * data[i + 2];
        data[i]     = avg + 100;  
        data[i + 1] = avg + 50; 
        data[i + 2] = avg; 
    }
}

function addConvolveValue(pos, i, data, length){
    return pos >= 0 && pos < length ? data[pos] : data[i];
}

function convolve(data, w, offset, v00, v01, v02, v10, v11, v12, v20, v21, v22){
    console.log( w, offset, v00, v01, v02, v10, v11, v12, v20, v21, v22)
    const divisor = (v00 + v01 + v02 + v10 + v11 + v12 + v20 + v21 + v22) || 1;
    const length = data.length;
    let res = 0;
    let newData = new Uint8Array(length)
    for(let i = 0; i < length; i++){
        if ((i + 1) % 4 === 0) {
            newData[i] = data[i];
            continue;
        }
        let res = v00 * addConvolveValue(i - w * 4 - 4, i, data, length) +
                    v01 * addConvolveValue(i - w * 4, i, data, length) +
                    v02 * addConvolveValue(i - w * 4 + 4, i, data, length) +
                    v10 * addConvolveValue(i - 4, i, data, length) +
                    v11 * data[i] +
                    v12 * addConvolveValue(i + 4, i, data, length) +
                    v20 * addConvolveValue(i + w * 4 - 4, i, data, length) +
                    v21 * addConvolveValue(i + w * 4 , i, data, length) +
                    v22 * addConvolveValue(i + w * 4 + 4, i, data, length);
        res /= divisor;
        res += offset;
        newData[i] = res;
    }
    data.set(newData)
}

Y ahora la versión de AssemblyScript:

/// <reference path="../node_modules/assemblyscript/dist/assemblyscript.d.ts" />

export function invert(byteSize: i32): i32 {
  for (var i = 0; i < byteSize; i += 4) {
    let pos = i + byteSize; 
    store<u8>(pos, 255 - load<u8>(i));
    store<u8>(pos + 1, 255 - load<u8>(i + 1));
    store<u8>(pos + 2, 255 - load<u8>(i + 2));
    store<u8>(pos + 3, 255);
  }
  return 0;
}


export function grayscale(byteSize: i32): i32 {
  for (var i = 0; i < byteSize; i += 4) {
    let pos = i+byteSize;
    const avg = u8(0.3  *  load<u8>(i) + 0.59 * load<u8>(i + 1) + 0.11 * load<u8>(i + 2));
    store<u8>(pos, avg);
    store<u8>(pos + 1, avg);
    store<u8>(pos + 2, avg);
    store<u8>(pos + 3, 255);
  }
  return 0;
}

export function sepia(byteSize: i32): i32 {
  for (var i = 0; i < byteSize; i += 4) {
    let pos = i+byteSize;
    const avg = 0.3  *  load<u8>(i) + 0.59 * load<u8>(i + 1) + 0.11 * load<u8>(i + 2);
    store<u8>(pos, u8(min(avg + 100, 255)));
    store<u8>(pos + 1, u8(min(avg + 50, 255)));
    store<u8>(pos + 2, u8(avg));
    store<u8>(pos + 3, 255);
  }
  return 0;
}

@inline
function addConvolveValue(pos:i32, oldValue:u8, length:i32): i32 {
  return pos >= 0 && pos < length ? load<u8>(pos) : oldValue;
}

export function convolve(byteSize:i32, w:i32, offset:i32, v00:i32, v01:i32, v02:i32, v10:i32, v11:i32, v12:i32, v20:i32, v21:i32, v22:i32): i32 {
  let divisor = (v00 + v01 + v02 + v10 + v11 + v12 + v20 + v21 + v22) || 0;
  if (divisor === 0) {
    divisor = 1;
  }
  for(let i = 0; i < byteSize; i++){
      if ((i + 1) % 4 === 0) {
        store<u8>(i+byteSize, load<u8>(i));

      } else {
        let oldValue = load<u8>(i);
        let prev = i - w * 4;
        let next = i + w * 4;
        let res = v00 * addConvolveValue(prev - 4, oldValue, byteSize)  +
                  v01 * addConvolveValue(prev, oldValue, byteSize)      +
                  v02 * addConvolveValue(prev + 4, oldValue, byteSize)  +
                  v10 * addConvolveValue(i - 4, oldValue, byteSize)     +
                  v11 * oldValue +
                  v12 * addConvolveValue(i + 4, oldValue, byteSize)     +
                  v20 * addConvolveValue(next - 4, oldValue, byteSize)  +
                  v21 * addConvolveValue(next , oldValue, byteSize)     +
                  v22 * addConvolveValue(next + 4, oldValue, byteSize);
        res /= divisor;
        res += offset;
        store<u8>(i+byteSize, u8(res));
      }
  }
  return 0;
}

Como podéis ver, el código es extremadamente parecido, pero con tipos y trabajando a un nivel un poco más bajo, que es lo que nos permite usar todo el potencial de Wasm. Así que, ¡ahora solo toca animarse, empezar a jugar con AssemblyScript y coger confianza en la tecnología Wasm, que va a ser una parte cada vez más importante de la web en los próximos años.