Comments 35
мда, а бенчмарки есть, где меряют производительность php via WASM и чистый php 8.2 ?
PS: https://github.com/WordPress/sqlite-database-integration для тех, кто увидел wordpress и решил попробовать странного
Спасибо за вопрос. Вот тут есть хороший бенч. Можно сравнить, например, время обхода Merkle-дерева. Еще можно посмотреть академическое исследование Understanding the Performance of WebAssembly Applications и вот это:
The raw execution of an algorithm in WASM is almost always faster than in JavaScript. However, the cost of writing data into the WASM module’s memory can be so high that it removes the benefit of using WASM in the first place.
а почему только WASM?
тогда уж надо просто дать возможность запуска любого системного бинарника как контейнера (а wasm будет одним из вариантов).
брюки превращаются... превращаются брюки... в элегантный apache версии 1!
Проблема в изоляции - те бинарники могут знать о файловой системе, то чего им знать особо и не надо и сисколить то, чего сисколить по хорошему не положено. UML может спасать в некоторых случаях. но если это не Linux, а какая-нибудь *BSD или Windows, где искать тот юзермод? Вот тут и приходит wasm и WASI - настроил вирутальную файлуху, указал доступы к реальной файлухе и сисколам - вот тебе и изоляция.
Это почти как джава - write once, run everywhere.
Звучит интересно, но есть вопрос с отладкой, как отлаживать такие приложения, возможно ли это стандартными методами языка?
К сожалению нет. В отладкой постепенно улучщается но пока все сыро.
По идеи каких-то серьёзных проблем с отладкой WASM приложений быть не должно - это же виртуальная машина - тут всё дело просто в разработке инструмента. Но, вот, считается же что отладка нативных приложений для Linux или мобильных платформ, до сих пор сильно проигрывает отладке под Windows.
WASM сейчас очень сильно завязывается на среду выполнения (в первую очередь - это браузеры) - и отладку должны в первую очередь обеспечивать именно они.
Первым должна тут подтянуться Mozila - ибо WebAsasembly это изначально их проект.
Во вторую очередь - Google - расширенные средства отладки веб разработки у них в приоритете
Затем, вероятно подтянется Microsoft - ну те любят переизобретать велосипед в рамках своей экосистемы.
А вот Apple может ещё долго тормозить (не любят они сторонние приблуды в рамках своей экосистемы).
А вот с не браузерными средами исполнения всё будет куда печальнее!
Можно абстрагировать wasm часть и сделать нативный таргет для отладки. Напрямую wasm бинари пока разве, что в браузере отлаживать, если вы конечно понимаете ассемблерные языки.
Замена Docker для server-side и всего-всего ...
Круто! И как запустить в Wasm "контейнере" Spring, Kafka и Oracle?
Сначала были Lisp, Forth и другие интерпретируемые ЯП, позволяющие писать крос-платформенный код - оставим из покое (тогда это было не так актуально).
Потом пришёл Java, за ним Python, JavaScipt, C#... позволяющие создавать кроссплатформенный код в рамках своей виртуальной управляемой среды выполнения (но ещё до конца не изолированной).
Затем пришёл LLVM - задавший новый стандарт кроссплатформенности - уже без виртуальной среды (не смотря на Virtual Machine в названии)! Но впихнуть его в браузер не удалость.
И вот (после отдельной тупиковой но важной вехой в лице Asm.js) этот LLVM в итоге переродился в WebAssembly, который становится очередным стандартом кроссплатформенности, на этот раз оттолкнувшись именно от браузеров (хотя тяжеловесное проксирование вызовов с JavaScript до сих пор имеется - что сильно снижает производительность этих вызовов, да и работа с DOM идёт через JS), но технология, решила-таки, окончательно вытеснить LLVM из кроссплатформенных разработок без виртуальной среды (всё-таки создав её для изоляции).
Основная беда LLVM была видимо в том, что это регистровая виртуальная машина, и были сложности со встраиванием её в именно в браузеры (зато она хорошо компилировалась в машинный код, который почти всегда регистровый на этапе исполнения; ну и над изолированностью тогда не подумали). Да и инструкции не оптимизировали для работы в браузере. Вот автор и переделал её в WASM - где уже стековая машина (заодно это дало возможность компилировать в WASM и исходные коды с ЯП, предназначенные для стековых машин - как Java, C# и изначально интерпретируемые - их на стекловавшую машину переводить проще, как проще было перевести ЯП, изначально созданные для регистровых процессоров, тоже не стековое исполнение).
Так что, у WebAsembly есть много шансов занять своё место и в серверном кода - тут пока ещё тоже востребована кроссплатформенность.
Я правильно понял, что компиляцию WASM кода под конкретную платформу (бакэнд-компиляция а-ля LLVM) уже тоже завезли? А что там с JIT компиляцией - та же техника как у JavaScript?
Если не ошибаюсь, в большинстве случаев код в WASM как раз через LLVM и компилируется. Как и LLVM умеет компилировать WASM-файлы в нативные бинарники. Некоторые интерпретаторы WASM тоже через LLVM работают вроде.
Так что, у WebAsembly есть много шансов занять своё место и в серверном кода - тут пока ещё тоже востребована кроссплатформенность.
С одной стороны согласен, шансы есть. А с другой - очень сильно сомневаюсь, что получится. Просто потому, что WASM имеет очень мощную песочницу (которая и идет главной фишкой WASM) и весь софт надо серьезно адаптировать под WASM.
Из LLVM в WASM делают компиляцию. Но это только для тех ЯП, что умеют компилироваться в LLVM - и, скорее всего, это переходное решение (чтобы не переделывать фронт-компилятор). Например C# не умеет в LLVM - но умеет в WASM.
и весь софт надо серьезно адаптировать под WASM.
Да - тут проблем много, как и много софта у которого не так много взаимодействия за пределы песочницы. Но в итоге - скорее новый софт будут разрабатывать уже с оглядкой на WASM - для перехода на эту стадию уйдёт лет 10
Когда я щупал C#/Java в WASM - там все было очень сыро, на уровне очень ранней беты. Скорее просто демонстрация возможности.
На сколько понимаю, основной затык в GC - свой сборщик и рантайм тащить не хотят, а хотят на уровне WASM согласовать сборку мусора.
Но в итоге - скорее новый софт будут разрабатывать уже с оглядкой на WASM - для перехода на эту стадию уйдёт лет 10
WASM когда появился? В 2015? А с 2017 пошла интеграция в браузеры?
Технология уже достаточно взрослая. И за ближайшие 10 лет не думаю, что-то в WASM принципиально изменится. Да, досогласуются расширения, улучшится поддержка в браузере и расширится экосистема в целом...
Но WASM сейчас - технология крайне нишевая.
Фронт-разработчикам он особо не нужен, им хватает JS/TS. А бекендерам нет особо дел до браузера. Тем более, что для запуска WASM все равно нужна серьезная обвязка из JS.
Можно сказать, что своей полноценной ниши WASM пока не нашел. И не думаю, что в ближайшие лет 10 это значительно изменится.
На сколько понимаю, основной затык в GC
Всё верно - все ждут появления сборщика в WebAssembly 2.0
А пока на костылях тянут свой
Технология уже достаточно взрослая. И за ближайшие 10 лет не думаю, что-то в WASM
Ну взрослой технология обычно становится после 3-тьей версии, а пока только ожидается 2.0
Да и срок, реально не большой - из беты они вышли всего пару лет назад!
Пока WASM очень нишевой продукт (хотя бы потому что у него много детских недостатков, да хоть сильное снижение производительности при JS вызовах в т.ч. к DOM).
Но сейчас WASM интересен тем, что позволяют относительно легко портировать готовые приложения под браузер (особенно если они написаны под Native; с виртуальными машинами всё пока сложнее), и это можно делать, условно не прибегая к помощи профессиональных веб-разработчиков.
Так же можно вести разработку новых приложений с прицелом не на веб-клиент, но с оглядкой на него - параллельно создавая и WEB-клиент (или разрабатывать сразу подо всё).
В будущем WASM скорее будет интересен для разработки нового софта, на традиционных ЯП, без углубления в WEB разработку. Но даже сейчас - есть такие платформы как UNO Platform (и готовят аналогично в Avalonia), где можно вести и WEB разработку полностью на C# - что новым разработчикам может быть интереснее, чем изучение мира JS.
Но пока, для проф JS-фронтэндщиков WASM не интересен из-за падения производительности при JS вызовах - а там полно библиотек на JS. Вот обрастёт WASM своими библиотеками (и уменьшит задержки в JS вызовах) вот тогда и во фронтэде может быть интересным - учитывая что в WASM уже и TypeScript и Kotlin умеют компилироваться. Тогда можно будет вообще собирать ПО написанное на разных ЯП.
Ну а для развития темы кроссплатформенности можно прикручивать WASM и на серверной стороне. Но тут скорее как внутренний движок скрипто-исполнителя (как это п прикручено к Docker) - единую системы внутреннего исполнения алгоритмов. Хотя, на C# вот уже есть .NET Scripting и это уже не так актуально. Но для JVM пока ещё актуально! Ну это если серверную часть не стали пилить на Node.js (вместе с JS на клиенте) - там есть eval.
Сравнивать docker и WASM крайне некорректно. Они решают разные задачи и решают их по разному. Единственное что у них общее - возможность что-то запустить.
Docker дает возможность системный софт обернуть в образ, что дает повторяемость окружения и изоляцию.
WASM - виртуальная машина со своей системой команд (своим низкоуровневым языком). Да, за счет виртальности дает хорошую изоляцию от хоста (особенно если эту изоляцию подчеркивать). Но если бы не продвижение WASM как возможности запуска ресурсоемких вычислений в браузере - WASM был бы практически никому не интересен.
Зачем docker лезет в WASM - понятно. WASM - перспективная технология с неустоявшейся экосистемой. И популярный инструмент, который будет запускать WASM, может стать инструментом работы с WASM "по умолчанию", что в свою очередь может принести очень много денег.
Но называть WASM заменой docker - это очень и очень некорректно.
Но называть WASM заменой docker - это очень и очень некорректно.
Разве так называют?
Посыл был такой, что будет WASM представлен раньше (в виде WASI) - то Docker (по крайней мере в нынешнем виде) вряд ли появился бы (появилось бы нечто другое)
Ну вообще достаточно странный посыл. Потому что это технологии для решения совершенно разных задач. Docker позволяет запаковывать в контейнеры, изолировать и деплоить одинаковым образом имеющийся зоопарк софта без оглядки на то, как на одной машине могут сосуществовать разные версии php и питона например. А WASM - это фактически переизобретение джавы и сам по себе он проблему деплоя уже имеющегося зоопарка софта со своими либами и версиями никак не решает. Разве что пересобирать весь софт под WASM...
Docker использовали для изолированного выполнения кроссплатформенного кода на серверной стороне. Теперь для этого есть WASM. Ранее альтернативой были только .NET, JVM, Node.js - но все они видимо чем-то не подходили - видимо отсутствием изолированности. А WASM это решает - и можно писать код на широком спектре ЯП
Docker никогда не использовали для выполнения кроссплатформенного кода, платформа контейнера обязана совпадать с платформой хоста.
Вы не можете ни запустить amd64 контейнер на arm, ни запустить windows контейнер под linux.
Не совсем так - linux контейнеры работают на всех платформах (пускай местами и через виртуалку).
Также как и контейнеры amd64 запускается и на MacBook M1 и старше (не знаю, правда, как дела на других arm-платформах).
Но докер тут ни при чём, это фичи платформы.
Это фича Docker Desktop - а он всегда на возможности платформы так или иначе полагается.
Если не ошибаюсь, практически любой ARM может тот же x86 на QEMU запустить.
И на тех же же arm-маках Docker Desktop через QEMU и работает, на сколько мне известно. Считать ли QEMU фичей платформы - вопрос отдельный )
Нет, в случае винды это точно фича винды, называется WSL2. Docker Desktop просто удачно её использует для запуска linux контейнеров.
Причём он даже не делает попыток как-то различать контейнеры, просто запускает dockerd из-под wsl2 и передаёт все контейнеры нему. Ах да, и прозрачно использовать windows-контейнеры и linux-контейнеры совместно невозможно, пользователю надо явно переключать контексты. Совсем не то поведение, которое ожидается от слов "изолированного выполнения кроссплатформенного кода".
Да, но докер - это не среда для написания кода. А среда для интеграции уже имеющегося софта. Например, у вас есть какой-то проприетарный бинарник, который требует либы определенных версий, и докер позволяет его упаковать в контейнер, а дальше деплоить на разные серверы, не заботясь о совместимости либ и изоляции. Как эту же задачу решить средствами WASM? Исходников нет.
Так что WASM - это просто еще один рантайм, под который надо компилировать исходники, да, обладающий гибкими настройками изоляции, поддерживающий множество языков программирования и т.п. Но проблему интеграции софта он вообще никак не решает.
Так что мне например непонятна фраза, что если бы был уже WASM, то и докер создавать не нужно было...
Я с таким посылом и не согласен. Они решают разные задачи и по разному - их области применения пересекаются в очень узком спектре, чтобы WASM оказал серьезное влияние на docker.
Даже в этой статье для запуска PHP в WASM наложили патчи на интерпретатор PHP и в WASM добавили расширение для обхода песочницы. И даже с развитием WASM эти моменты не уйдут - просто потому что изоляция в WASM идет как главная фишка. И без адаптации софта под эту изоляцию никуда не деться.
А фишка docker - как раз в запуске стандартных linux-приложений.
Странное сравнение. Это скорее похоже на Application Server из мира Java, чем на Docker.
WebAssembly привносит истинную портируемость. Исполняемый файл достаточно собрать один раз, после чего его можно будет запускать везде.
А питоновские либы, которым нужны свои бинарники, например?
Видно, что образы Wasm-контейнеров намного меньше обычных. Даже
alpine-версия контейнераphpбольше, чем Wasm.
Каким образом это достигается? Ведь php даже внутри Wasm всё равно требуются все зависимости и окружение для работы платформы, которая интерпретирует php-код? Или каким-то образом оно научилось всё окружение тоже комплизировать и запихивать внутрь Wasm-виртуалки?
Вопрос даже не столь по php, сколь по обвязкам, зависимостям и окружениям любых других ЯП и их рантаймов.
Это кстати важный момент и отличный вопрос.
Подожду тут ответа.
Предположу, что часть окружения находится непосредственно в реализации WASI, а оставшаяся часть недоступна.
Ну там, к примеру, функция system в таком порезанном окружении просто упадёт с ошибкой.
WasmEdge позволяет создать AOT-оптимизированный (ahead-of-time) исполняемый файл, который нативно работает на текущей машине и может интерпретироваться на других.
И в чем прикол? Опять возвращаемся к тому, что надо компилировать под каждую платформу?
Уже сейчас можно rust компилировать с musl и контейнер собирать из scratch, в итоге получается очень маленький контейнер. Выходит, что wasm уже имеет не так много плюсов.
WebAssembly: Docker без контейнеров