Достъпен е Wasmer 2.0, инструментариум за създаване на приложения на база WebAssembly

Състоя се вторият значителен ъпдейт на проекта Wasmer, който разработва runtime за изпълнение на WebAssembly модули. Тази технология може да се използва за създаване на универсални приложения, способни да работят на различни операционни системи, както и за изолирано изпълнение на ненадежден код. Кодът на проекта е написан на Rust и се разпространява под MIT лиценз.

Преносимостта се осигурява чрез компилирането на приложния код в ниско ниво WebAssembly междинен код, който може да се изпълнява на всяка ОС или да се вгражда в програми на други програмни езици. Програмите са леки контейнери, в които се изпълнява WebAssembly псевдокод. Тези контейнери не са привързани към операционната система и могат да включват код, написан на всякакъв програмния език. За компилиране в WebAssembly може да се използва инструментариумът Emscripten. За транслация на WebAssembly в машинен код на текущата платформа е предвидена възможност за свързване на различни компилаторни бекенди (Singlepass, Cranelift, LLVM) и движещи механизми (използване на JIT или генериране на машинен код).

Управлението на достъпа и взаимодействието със системата се осигурява чрез API WASI (WebAssembly System Interface), който предоставя програмни интерфейси за работа с файлове, сокети и други функции, предоставяни от операционната система. Приложенията са изолирани от основната система в sandbox среда и имат достъп само до обявената функционалност (механизъм за сигурност, основан на управление на правата — за действия с всеки от ресурсите (файлове, директории, сокети, системни повиквания и др.) приложението трябва да получи съответните правомощия).

За стартиране на WebAssembly контейнера е достатъчно да се инсталира в системата runtime Wasmer, който се предоставя без външни зависимости („curl https://get.wasmer.io -sSfL | sh“), и да се стартира необходимия файл („wasmer test.wasm“). Програмите се разпространяват под формата на обикновени WebAssembly модули, за управлението на които може да се използва пакетен мениджър WAPM. Wasmer също така е наличен под формата на библиотека, която може да се използва за вграждане на WebAssembly код в програми на езици Rust, C/C++, C#, D, Python, JavaScript, Go, PHP, Ruby, Elixir и Java.

Платформата позволява постигане на производителност на изпълнението на приложения, близка до производителността на местни компилации. Чрез Native Object Engine за WebAssembly модула може да се генерира машинен код („wasmer compile —native“ за генериране на предварително компилирани обектни файлове .so, .dylib и .dll), за стартирането на който е нужен минимален runtime, но се запазват всички възможности на sandbox-изолацията. Възможно е доставянето на предварително компилирани програми с вграден Wasmer. За създаване на надстройки и добавки се предлагат Rust API и Wasm-C-API.

Значителната промяна на версията на Wasmer е свързана с въвеждането на несъвместими промени в вътрешния API, които, според уверенията на разработчиците, няма да се отразят на 99% от потребителите на платформата. Също така, от несъвместимите промени се отбелязва промяната в формата на сериализирани модули Wasm (модули, сериализирани в Wasmer 1.0, няма да могат да се използват в Wasmer 2.0). Други изменения:

• Поддръжка на SIMD инструкции (Single Instruction, Multiple Data), които позволяват паралелизация на операциите с данни. Областите, в които използването на SIMD може да увеличи значително производителността, включват машинно обучение, кодиране и декодиране на видео, обработка на изображения, симулация на физични процеси и манипулации с графика.
• Поддръжка на референтни типове, позволяващи на Wasm модулите да получават информация от други модули или основната среда.
• Извършена е значителна оптимизация на производителността. Скоростта на работа на LLVM runtime с числа с плаваща запетая е увеличена с около 50%. Възможностите за извикване на функции са значително ускорени благодарение на намаляването на случаите, изискващи достъп до ядрото. Производителността на Cranelift кодогенератора е увеличена с 40%. Намалено е времето за десериализация на данни.
• Променени са имената на двигателите за по-точно отражение на същността: JIT → Universal, Native → Dylib (Динамична библиотека), Object File → StaticLib (Статична библиотека).

Източник: opennet.ru