Se ha producido la segunda versión importante del proyecto Wasmer, que desarrolla un runtime para ejecutar módulos WebAssembly, el cual se puede utilizar para la creación de aplicaciones universales que pueden funcionar en diferentes sistemas operativos, así como para la ejecución aislada de código no confiable. El código del proyecto está escrito en Rust y se distribuye bajo licencia MIT.
La portabilidad se garantiza mediante la compilación del código de la aplicación en un código intermedio de bajo nivel WebAssembly, que puede ejecutarse en cualquier sistema operativo o integrarse en programas escritos en otros lenguajes de programación. Los programas actúan como contenedores ligeros en los que se ejecuta código WebAssembly. Estos contenedores no están ligados al sistema operativo y pueden incluir código originalmente escrito en cualquier lenguaje de programación. Se puede utilizar el conjunto de herramientas Emscripten para compilar a WebAssembly. Para la traducción de WebAssembly a código máquina de la plataforma actual, se admite la conexión de diferentes backends de compilación (Singlepass, Cranelift, LLVM) y motores (utilizando JIT o generando código máquina).
El control de acceso y la interacción con el sistema se llevan a cabo mediante la API WASI (Interfaz de Sistema WebAssembly), que proporciona interfaces programáticas para trabajar con archivos, sockets y otras funciones proporcionadas por el sistema operativo. Las aplicaciones están aisladas del sistema principal en un entorno sandbox y tienen acceso únicamente a las funcionalidades declaradas (el mecanismo de seguridad basado en el control de capacidades establece que para cada uno de los recursos (archivos, directorios, sockets, llamadas al sistema, etc.) la aplicación debe tener los permisos correspondientes).
Para ejecutar un contenedor WebAssembly, solo es necesario instalar en el sistema el runtime Wasmer, que se proporciona sin dependencias externas ("curl https://get.wasmer.io -sSfL | sh"), y ejecutar el archivo necesario ("wasmer test.wasm"). Los programas se distribuyen en forma de módulos WebAssembly comunes, cuyo manejo se puede realizar mediante el gestor de paquetes WAPM. Wasmer también está disponible en forma de biblioteca, que se puede usar para integrar código WebAssembly en programas en lenguajes como Rust, C/C++, C#, D, Python, JavaScript, Go, PHP, Ruby, Elixir y Java.
La plataforma permite lograr un rendimiento de ejecución de aplicaciones cercano al de las compilaciones nativas. Con el Native Object Engine para el módulo WebAssembly, se puede generar código máquina ("wasmer compile —native" para generar archivos objeto .so, .dylib y .dll precompilados), cuyo lanzamiento requiere un runtime mínimo, pero mantiene todas las capacidades de aislamiento sandbox. Es posible suministrar programas precompilados con Wasmer incorporado. Se ofrecen API de Rust y Wasm-C-API para crear extensiones y complementos.
El cambio significativo en el número de versión de Wasmer está relacionado con la introducción de cambios incompatibles en la API interna, los cuales, según los desarrolladores, no afectarán a más del 99% de los usuarios de la plataforma. También se señala un cambio en el formato de los módulos Wasm serializados (los módulos serializados en Wasmer 1.0 no podrán ser utilizados en Wasmer 2.0). Otros cambios:
- Soporte para instrucciones SIMD (Single Instruction, Multiple Data), que permiten paralelizar operaciones sobre datos. Áreas donde la aplicación de SIMD puede mejorar notablemente el rendimiento incluyen el aprendizaje automático, la codificación y decodificación de video, el procesamiento de imágenes, la simulación de procesos físicos y la manipulación gráfica.
- Soporte para tipos de referencia, que permiten a los módulos Wasm acceder a información en otros módulos o en el entorno base.
- Se ha realizado una optimización significativa del rendimiento. La velocidad del runtime de LLVM con números de punto flotante se ha incrementado en aproximadamente un 50%. Se ha acelerado notablemente la invocación de funciones al reducir las situaciones que requieren acceder al núcleo. La productividad del generador de código Cranelift ha aumentado en un 40%. Se ha reducido el tiempo de deserialización de datos.
- Para reflejar mejor la esencia, se han cambiado los nombres de los motores: JIT → Universal, Native → Dylib (Biblioteca Dinámica), Object File → StaticLib (Biblioteca Estática).
Fuente: opennet.ru
