Comments 25
да и вообще к собственному коду программа доступа тут не имеет.
Т.е. написать на WASM JIT для высокоуровневого языка с генерацией самого WASM (чтобы потом движок доJITил до нативного кода) нельзя?
Искаропки нет, но ничего не мешает хостовому окружению прокинуть внутрь функции для этого. Вроде как я даже встречал прецеденты, но с ходу не вспомню где.
В теории ничто не мешает вам использовать PGO, на практике пока вроде этим никто не занимался
А оно тут каким боком? Я имел в виду, скажем, написанную на WASM реализацию питона, генерирующую из питоновых функций код на самом WASM (который потом движок WASM'а превратит в нативный).
PGO - это по сути то что делает JIT, когда оптимизирует горячие вызовы. В контексте браузера это обычно определение коротких простых типов для аргументов. Условно было (a,b) => a+b
, где a
и b
это JsObject
, а после того как функцию прогрели, появляется одельная аналогичная функция, но с типами float или int.
Питон не занимался компилированием примерно никогда. Уже есть несколько имплементаций питона в браузере, включая порт самого известного СPython и для запуска питоновских скриптов нужны только эти самые скрипты и немного шаманства, чтобы импорты завелись. Можно поинтересоваться есть ли у Mojo (это такой копилируемый питон) таргет в wasm и порт компилятора, но скорее всего нет.
Но вот ситуации, чтобы кому-то понадобилось взять WASM порт и в нём запустить JIT, который бы в итоге также испускал другой wasm код я пока не встречал ибо сфера применения звучит крайне специфичной и проще сделать это на обычном хосте при помощи обычного нативного кода. Хотя компиляторы и портируют в wasm, но точно не в предложенном вами формате.
Да есть примеры, вот парень делает JIT поддержку чтобы JS движок скомпилированный в Wasm генерил Wasm код и потом его же линковал в исходный модуль: https://www.youtube.com/watch?v=8GPOy7x-iKw&ab_channel=WASMI%2FO
+/+
Голые руки - это ничего, это наше всё, главное чтобы ровные были. :)
По WASM - тема с начала и до конца выглядит стрёмно.
1. Как "выросла" исторический обзор: (кратко: всех предшественников - предследовали неудачи: NaCl, PNaCl, asm.js - сдохли)
https://habr.com/ru/articles/475778/
2. Сам WASM: не Lisp и не ASM - что-то "посередине".
Спецификация - "WASM inspired": не BNF и не математика, а где-то "между".
https://webassembly.github.io/spec/core/_download/WebAssembly.pdf
3. Поискал VM-ки. Особо они не светятся, Гугл выдал эту:
https://github.com/WAVM/WAVM
Её "жизненный цикл" у меня прошёл по этому сценарию: Качнул-открыл-закрыл-удалил.
Ещё одна: WebAssembly Micro Runtime. По коду лучше, но когда размер исходников папки core занимает 6 мб, то какое же это Micro?!
https://github.com/bytecodealliance/wasm-micro-runtime
4. Цели WASM так же туманны. Главный вопрос: "зачем?" (ответа для себя не нашёл).
Так же всегда смущали заклинания разработчиков о "безопасности" достигаемой запрещением операторов вроде goto на уровне грамматики интерпртируемого либо компилируемого языка. Ребята, это что, серьёзно?! :))))
Прогноз (ИМХО): будет жить в состоянии толи жив толи мёртв - где-то "между".
Поискал VM-ки. Особо они не светятся
wasmtime вроде более-менее живой. Вот тут ребята пощупали wamr, результат так себе (последний пункт на слайде 20 повеселил).
Когда можно попробовать Wasm:
Когда вам нужно получить порцию одобрения от использования модной технологии. У вас команда мечтателей и хочется атмосферу стартапа. При этом вы допускаете, что финансирование в любой момент могут свернуть, и тогда придётся искать новую работу.
:) Там и по второму слайду видно, что ребята - весёлые. :)
Из рантаймов:
wasmer - наиболее живой и продвинутый из standalone рантаймов. В будущих статьях с его помощью будем делать CLI программы на WASM.
wasmtime - вроде живой, но я его особо не пробовал.
В V8 на котором основаны хром и нода есть встроенный WASM рантайм и он наиболее передовой по фичам. Собственно он и использовался в этой статье.
У огнелиса тоже есть своя реализация.
В общем имплементаций хватает
asm.js
этот жив и используется только в качестве полифила. У emscripten это всё ещё вполне живой таргет.
Цели WASM так же туманны.
Если кратко - люди хотели иметь что-то типа флеша, только без установки чего-либо кроме собственно браузера. Берём canvas, берём wasm и вот тебе готовая производительная и безопасная альтернатива. Из плюсов - она открытая и имеет собственную спеку. Кейсов для чего нужна изоляция даже в браузере вполне немало.
но когда размер исходников папки core занимает 6 мб, то какое же это Micro?!
А вы что всю репу сразу деплоите? Оный рантайм на IoT может деплоиться, куда уже сильнее micro?
Если кратко - люди хотели иметь что-то типа флеша, только без установки чего-либо кроме собственно браузера.
А может оставим браузер браузером: простой штукой для просмотра текста? А то в нем уже скрестили не только ежа и колючую проволоку, но и весь зоопарк, который смогли найти, и процесс продолжается. :)
Но уж если сильно ассемблера хочется... Из их тумана я не понял, что мешало им в браузер LLVM IR затащить? (работы на неделю двум программистам)
Вариант с LLVM IR тоже рассматривался. Но там было сложно песочницу реализовать без сильной потери производительности. К тому же IR не такой уж и переносимый за пределами хелоувордов на самом деле. Модуль собранный в WASM должен запускаться всегда и везде где есть рантайм, втч на архитектурах CPU которых еще даже не существует в природе.
простой штукой для просмотра текста?
А заодно выгоним всех этих неайтишных юзеров, которые ломают семантичный веб своими хотелками и хотят игры играть не отходя от кассы, смотреть видео, слушать музыку, тыкать в прочие кнопки со свистоперделками и эмоджи.
Из их тумана я не понял, что мешало им в браузер LLVM IR затащить? (работы на неделю двум программистам)
Ларчик открывался просто - когда Google взялся за браузер они для скорости навернули в него собственный JIT с собственным IR, который впоследствии адаптировала уже и Mozilla с Apple и в довольно быстро все сошлись во мнении, что неплохо было бы иметь некоторый стандарт и дать API напрямую в браузер, чтобы ты мог сразу подключить оптимизированный модуль и не ждать, пока у тебя JIT прогреется.
У LLVM IR очень много всякого платформоспецифичного (например общение с очень длинными регистрами на эльбрусах) и не слишком поддерживаемого непосредственно в браузере - адресация например там была исключительно 32 битная, целых чисел тоже больше 32 бит не было, ну и вагон ещё всяких похожих приколов. Так ли хочется разрабам думать за какие-нибудь phi-ноды в браузере? В итоге пришлось бы взять LLVM IR, выкинуть из него процентов 80 и сделать из него какой-нибудь LLVM IR nano, включавший бы сабсет исходного и добавлявший приколы, связанные с браузерами. В итоге получился бы тот же wasm только llvm ir. Зачем делать сложно, когда можно не делать. Тем более, что референсная имплементация уже в браузере и работает. Отдельный момент касается стандартизации того IR в виде спеки ISO, чего LLVM наверняка не очень хочет, предпочитая оставить простор для манёвра - им хватает головняка на уровне стандартов языков.
Отдельный вопрос, как потом это разрабам кормить, чтобы те использовали именно LLVM IR, а не IR от C#/Java/Haskell/Lua?
А может оставим браузер браузером: простой штукой для просмотра текста? А то в нем уже скрестили не только ежа и колючую проволоку, но и весь зоопарк, который смогли найти, и процесс продолжается. :)
Нет больше таких браузеров, у них нет целей, нет задач и нет юзеров, кроме полутора гиков. Эти браузеры остались там, в эпохе IE, и умерли со смертью WEB1.0. Теперь браузер - это не просто загрузить по get html и отрендерить его, это полноценная, мощная, кроссплатформенная VM, которая, в добавок ко всему, еще и безопасная (относительно). Раньше мы могли смотреть только html, а сейчас в браузере работает figma, google sheet, office и еще куча всего. И для рядового пользователя это приемлимо - не надо ничего качать, все выполняется в песочнице, и я, честно, моментами прямо радуюсь. Раньше чтобы конвертировать файлы, например, надо было станцевать с бубном, скачать сомнительную тулзу, прочитать на что ругается антивирус, пойти изучать, нормально ли это, потом чистить комп от троянов, а теперь все онлайн и на клиенте выполняется.
Чтобы сконвертировать файл - достаточно ffmpeg и ImageMagick. И то, и другое опенсорсное, под любую систему и никаких троянов.
Хахаха. Я, разраб и человек, тыкающий линукс последние 15 лет, и то каждый раз ключи что к тому, что к тому гуглю. Идите, расскажите юзерам, как им использовать эти "опенсорсные и под любую систему" поделия.
Не вижу проблемы, юзера тоже умеют гуглить. А сейчас им еще и ChatGPT подскажет. Вообще, идея того, что все должно делаться одной кнопкой "Сделать з@ебись" глубоко ущербна. Любой инструмент требует освоения.
Вот, собственно, корень проблемы того, что юзеры массово идут в облачные сервисы корпораций и платят подписку за адоб и так далее: апологеты опенсорса не считают нужным делать юзеру хоть сколько-нибудь удобно и не видят ничего странного в том, чтобы предлагать обычным юзерам на полном серьезе пользоваться ffmpeg и ImageMagick.
Удивительно, почему же такой классный опенсорс, который "под любую систему и никаких троянов" обычным пользователям не нужен даже даром.
Чтобы сконвертировать файл - достаточно ffmpeg и ImageMagick
Вы не чувствуете себя узкоумозрительным обделённым человеком? Файлы бывают разные, например, сконвертируйте fbx в gltf при помощи приложенных вами библиотек. Это во первых. А во вторых - людям нужно просто в пару кликов получить результат, не тратя время на инструкцию как установить какой-то очередной опенсорс.
Благодарю за полезный материал!
Хотелось бы узнать, существуют ли какие-либо плагины или расширения, которые могут помочь с подсветкой синтаксиса, линтеры, дебаггеры и другие инструменты для работы с низкоуровневым wasm.
wabt - основной инструмент при работе с WASM. Также wasm-tools и некоторые утилиты из комплекта binaryen. Из плагинов ничего более продвинутого чем подсветка синтаксиса и автодополнение имен операций я не встречал. VSCode базово поддерживает искаропки, для остальных редакторов плагины гуглятся.
WebAssembly голыми руками