Comments 56
О, привет Java.
Бинарный web! Бинарный web! Бинарный web!
Давно пора, честно говоря. Свечка на css, ага…
Давно пора, честно говоря. Свечка на css, ага…
чем оно будет отличатся от имеющихся технологий? (.net, JVM).
Или даже clang умеет генерить не привязанный к конкретной архитектуре код (флаг -emit-llvm ), который можно потом при линковке преобразовать в ассемблер целевой машины.
Или даже clang умеет генерить не привязанный к конкретной архитектуре код (флаг -emit-llvm ), который можно потом при линковке преобразовать в ассемблер целевой машины.
Отсутствием фатального недостатка.
как я понял, нода хочет заменить бинарники на wasm?
чем оно будет отличатся от имеющихся технологий? (.net, JVM).
Намного эффективнее(он более низкоуровневый), нет привязки к рантайму(гц, операции над объектами и прочее).
Или даже clang умеет генерить не привязанный к конкретной архитектуре код (флаг -emit-llvm )
llvm не совсем умеет отвязывать ir от архитектуры. База там действительно общая, но существует много всякой платформо-специфичной атрибутики. В целом ir почти во всём лучше wasm, но.
Основная фишка wasm — это именно изолированное(и эта изоляция намного ниже, нежели в ситуации с той же java) исполнение кода. Очевидно, что брать и генерировать asm — это не лучшая идея. Сам же llvm хоть и называется vm — vm не является.
Т.е. wasm — это такое безопасный ассемблер, который исполняется в вм. Он компилируемый, простой, крайне низкоуровневый, но он не позволяет читать/писать куда не надо. Это его основная задача и фундаментальное отличие от всего остального.
Поддерживаю! Еще одна абстрактная стек машина.
Правда WebAsm стек машина более низкого уровня чем CIL или JVM. Думаю она больше напоминает стек машину LLMV.
Возможно было бы проще использовать стек машину LLMV, но фатальный недостаток помешал.
Правда WebAsm стек машина более низкого уровня чем CIL или JVM. Думаю она больше напоминает стек машину LLMV.
Возможно было бы проще использовать стек машину LLMV, но фатальный недостаток помешал.
UFO just landed and posted this here
Иногда у меня есть ощущение, что технологии развиваются куда-то не туда. Мы сделали JS, чтобы запускать код в браузере, потом сделали WebAssembly, чтобы запускать его быстрее, а потом хотим сделать WebAssembly без веба, чтобы запускать код вне браузеров.
А потом мы захотим писать на чем-нибудь более удобном, чем C/C++/Rust/итп, например, хотим сборку мусора, и притащим GC поверх WASM, когда в .NET/JVM/итп он реализован нативно. Тут уже сделали Blazor — веб-фреймворк на C#, путем портирования Mono на WASM. Мы портировали виртуальную машину на виртуальную машину, чтобы ты мог запускать виртуальную машину, пока запускаешь виртуальную машину (с).
Намного эффективнее(он более низкоуровневый)
А потом мы захотим писать на чем-нибудь более удобном, чем C/C++/Rust/итп, например, хотим сборку мусора, и притащим GC поверх WASM, когда в .NET/JVM/итп он реализован нативно. Тут уже сделали Blazor — веб-фреймворк на C#, путем портирования Mono на WASM. Мы портировали виртуальную машину на виртуальную машину, чтобы ты мог запускать виртуальную машину, пока запускаешь виртуальную машину (с).
Предлагаю относиться к JS как к обкатке технологии "вседозволенности в песочнице". Все же прототипировать на скрипте всяко удобней.
UFO just landed and posted this here
Так точно! И для компиляции между стек машинами будем использовать LLVM стек машину. Потому что так проще писать компиляторы между всем этим зоопарком!
Запилите наконец везде LLVM стек машину и все ваши стек машины компилируйте в нее.
Запилите наконец везде LLVM стек машину и все ваши стек машины компилируйте в нее.
llvm не стек-машина. Про llvm я уже говорил — его ir сложен, не особо переносим и llvm не умеет в изоляцию, т.к. это не vm.
Для этого по идее нужно обеспечить строгую совместимость текущих версий байткода LLVM с будущими. И заодно разработать формальную спецификацию.
Всё-таки у проекта LLVM несколько иные приоритеты в плане развития, вроде оптимизации процесса компиляции в нативный код для аппаратной платформы, которые идут немного вразрез как с идеей заморозки спецификации, так и с концепцией «песочницы» (неопределённое поведение и пр.).
GC не нужен, если программируешь на Rust. Совсем. В прикладной разработке почти не заметно его отсутствие.
Мы сделали JS, чтобы запускать код в браузере
Хоть жс и хорош, но он был ошибкой. Причины тому просты — никто не думал, что это выльется в полноценные приложения на жс. Броузер стал некой новой ОС и такой высокоуровневый язык очень плох как базовый язык платформы.
потом сделали WebAssembly
Правильно. Это попытка исправить проблему.
чтобы запускать его быстрее
Быстрее — это просто следствие. Задача была «сделать максимально близкое к железу представление, которое может всё то — что может железо».
А потом мы захотим писать на чем-нибудь более удобном, чем C/C++/Rust/итп
А это неважно. Тут фишка в том, что вы на си можете написать питон, а на питоне си нет.
например, хотим сборку мусора
Мы просто берём и пишем любую сборку мусора.
и притащим GC поверх WASM
Нет. Ненужно ничего тащить. Вы, скорее всего, неправильно поняли. Когда говорят «тащить гц в васм» — это говорится именно про доступ из васма к js-объектам. Т.е. налаживания коммуникации между двумя отдельно запущенными в броузере vm. Некий такой ffi.
Но вам ничего не мешает собрать v8 под васм и запустить в броузере. Можете jvm собрать. Оно, конечно, так просто не соберётся т.к. использует очень много платформо-специфичных решений. И если их убрать/заменить на васм-специфичные, то никаких проблем не будет.
когда в .NET/JVM/итп он реализован нативно.
Нету там никакого нативно и в этом проблема. wasm — это именно llvm-ir, а не жава/дотнет-байткод. Об их фундаментальной разнице я говорил выше. Ни на каком жава/дотнет-байткоде вы jvm не напишите, а вот на ir/wasm вполне.
В этом фишка. Вы берёте базовый язык — это такой язык, который может «всё». А далее пишите что хотите, хоть jvm, хоть питон.
Тут уже сделали Blazor — веб-фреймворк на C#, путем портирования Mono на WASM.
Да, это так и работает. Так и задумывалось. Люди правильно сделали.
Мы портировали виртуальную машину на виртуальную машину, чтобы ты мог запускать виртуальную машину, пока запускаешь виртуальную машину (с).
Нет. Вы путаете слова и понятия. vm в разных контекста значит совершенно разное, ведь любая ОС — это по-сути vm.
Воспринимайте wasm как ОС + некую отдельную платформу(аппаратную). И уже далее на этой ПА платформе вы запускаете нативные программы. Такой нативной программой является mono. И люди её запустили. А ваш C#-код и его окружение — это уже ваши внутренние с .net/mono заморочки. wasm это не интересует, как и любую другую платформу(нативную или около того).
и притащим GC поверх WASM
Нет. Ненужно ничего тащить. Вы, скорее всего, неправильно поняли.
Я не имел в виду поддержку GC непосредственно в WASM, я имел в виду как раз
Мы просто берём и пишем любую сборку мусора.
когда в .NET/JVM/итп он реализован нативно.
Нету там никакого нативно и в этом проблема.
Очень даже есть. Например, .NET GC реализован как часть CoreCLR (если говорим о .NET Core), написан на C++, как большинство CoreCLR.
Воспринимайте wasm как ОС + некую отдельную платформу(аппаратную).
Это, конечно же, очень круто, но только эта платформа не аппаратная, абстрактная виртуальная машина. И инструкции WASM-не инструкции x86 или иной реальной аппаратной платформы, а инструкции абстрактной виртуальной машины (кстати, стековой). И есть WASM-runtime, который занимается исполнением всего этого дела. Поэтому как не крути, это медленнее.
И если C (C++/Rust/etc), компилированный в WASM и исполняемый WASM-рантаймом vs C#, компилированный в IL и исполняемый .NET-рантаймом я еще могу понять, потому что там нет всего того высокоуровневого оверхеда от .NET, то идею скомпилировать .NET (JVM/что угодно) под WASM — нет, потому что это будет медленнее, чем .NET (JVM), скомпилированные под конкретную физическую платформу. И идея подложить слой абстракции под абстракцию кажется мне весьма сомнительной.
В таком ключе я вижу целевое применение WASM исключительно в переносимом производительном коде, написанным на C/C++/Rust/etc. Что, имхо, довольно ограниченная ниша.
З.Ы. При условии, что я правильно все понимаю.
UFO just landed and posted this here
Я не имел в виду поддержку GC непосредственно в WASM, я имел в виду как раз
Правильно. Если вам нужен ГЦ в программе на С++ — вы пишите гц на С++. Это не вызывает никаких проблем и С++ ненужна нативная поддержка гц. Васм такой же С++.
Очень даже есть. Например, .NET GC реализован как часть CoreCLR (если говорим о .NET Core), написан на C++, как большинство CoreCLR.
Ну С++ — это внешний для .net мир. Я имел ввиду нативно в контексте .net. Ведь именно потому гц написан там на С++.
Именно поэтому .net и нужен С++ и нативнища, ведь байткод и vm там высокоуровневые. Wasm же — это совершенно другой случай.
Это, конечно же, очень круто, но только эта платформа не аппаратная, абстрактная виртуальная машина.
llvm-ir тоже абстрактная виртуальная машина. Ключевым тут является не название, а смысл. Какого уровня эта машина и насколько полно она может обобщать эту аппаратную платформу.
И есть WASM-runtime, который занимается исполнением всего этого дела. Поэтому как не крути, это медленнее.
WASM-runtime не занимается исполнением кода. Он компилируемый, как и ir. Да, этому коду(как и ir) требуется некий рантайм, но в чём проблема? Никто и не говорил, что это бесплатно.
К тому же, вы предлагали(насколько я понял) заменить это жава/дотнет байткодом, который ещё более медленный, на порядки более медленный. И для решения этой проблемы там есть специальный jit, который воспринимает этот байткод не как байткод, а как некий язык высокого уровня.
ir и, в меньшей степени, wasm — уже оптимизируются на уровне байткода и транслируются в бинарник почти 1в1.
И идея подложить слой абстракции под абстракцию кажется мне весьма сомнительной.
Вы воспринимаете jvm/.net по своему, но всё это лишь обычные программы на том же C (C++/Rust/etc).
И этот слой нужен для изоляции, ведь ОС так же вносит множество оверхеда, как и все аппаратные средства изоляции в железе(процессоре). На самом деле да, в какой-то мере wasm и броузер заново изобретают ОС и работают хуже. Взять ту же изоляцию памяти. Но броузер не может стать ОС потому что уже есть ОС, есть вендорлок и никто никуда не уйдёт и никого никуда не пустят.
К тому же изоляция уровня ОС достаточна слаба и броузер(либо какая-то другая песочница) всё равно нужен и это так же будет накладывать множество ограничений. В том числе и по производительности.
В таком ключе я вижу целевое применение WASM исключительно в переносимом производительном коде, написанным на C/C++/Rust/etc. Что, имхо, довольно ограниченная ниша.
jvm/.net — это такой же С++ код как и любой другой.
И в этом его смысл. Мы можем в броузере(в какой угодно другой песочнице) запустить любой C/C++/Rust/etc-софт, а это значит, что мы можем запустить и jvm и v8 и что угодно. Да, это будет медленнее, но.
Смысл в том, что это будет работать и работать хорошо. Причём максимально безопасно. Вы сможете загрузить любой нужный вам рантайм к пользователю в броузер и делать так что хотите. Какая вам разница с того, что нативная jvm будет работать быстрее? Считайте, что у пользователя просто процессор похуже.
Возможно, я что-то не понимаю. Как осуществляется исполнение WASM? llvm-ir — это внутреннее представление кода, которое может быть скомпилировано в машинный код для целевой платформы (либо JIT-исполняться). Как я понимаю, идея WASM, что он переносимый, т.е. пофиг, какая там у нас архитектура процессора и ОС. Поэтому, как я понимаю, wasm-бинарь содержит не конечный машинный код, а некое промежуточное представление, машинный код абстрактной машины. Который затем должен быть интерпретирован/JIT-компилирован/компилирован целиком перед запуском в реальный машинный код платформы, на которой он запускается, верно?
Вы сможете загрузить любой нужный вам рантайм к пользователю в броузер и делать так что хотите. Какая вам разница с того, что нативная jvm будет работать быстрее?
В статье речь идет о запуске WASM в том числе и вне браузера. В браузере я могу понять, хотят писать не только на JS. Но в чем смысл делать переносимой саму JVM, если и так есть имплементации JVM почти под что угодно, и наше jvm-приложение таким образом УЖЕ переносимо?
И есть WASM-runtime, который занимается исполнением всего этого дела. Поэтому как не крути, это медленнее.
WASM-runtime вполне может иметь JIT (как например cranelift или V8) или вообще можно транслировать wasm-байткод в llvm-IR и скомпилировать при помощи llvm.
Да, в теории это будет медленнее, тк до llvm дойдёт меньше полезной информации от основного компилятора, но судя по бенчмаркам - разница не такая уж и большая (1-2 процента).
+ спецификация WASM постоянно расширяется и туда добавляют, например, всякие векторные инструкции, чтобы можно было вызывать всякие AVX / SSE как будто ты в нативе
llvm-ir — это внутреннее представление кода, которое может быть скомпилировано в машинный код для целевой платформы (либо JIT-исполняться).
WASM — это тоже самое.
Как я понимаю, идея WASM, что он переносимый
Да, как и llvm-ir. Но переносимость это главное — главное изолированность.
Который затем должен быть интерпретирован/JIT-компилирован/компилирован целиком перед запуском в реальный машинный код платформы, на которой он запускается, верно?
Ну интерпретацией его никто заниматься не хочет. А так да — как ir.
В статье речь идет о запуске WASM в том числе и вне браузера.
Ну да, для целей похожих на броузер. Платформонезависимость + изолированность. Два кита.
если и так есть имплементации JVM почти под что угодно
Ну не под что угодно, а под конкретный набор платформ. Это просто бинарник, который не исполняется в изолированной среде. Ваша jvm может делать с системой что угодно.
А далее вам понадобится изоляция, а ещё и платформо-независимая. И вы сделаете очередную vm для нативного кода. Но тут всё сделано уже за вас.
и наше jvm-приложение таким образом УЖЕ переносимо?
Нет, вашего jvm-приложения на уровне платформы не существует — они никому не интересно. Это просто какая-то локальная логика jvm. Приложением является jvm и она не переносима.
К тому же, кейсы использования wasm«а выходят за „одно приложение“. Там обычно миллионы приложений. jvm/.net/js/python — тысячи их. Везде и всюду какие-то непонятные окружения, бинарники, платформа-специфичная структура.
WASM же един. Все программы имеют одинаковое окружение, а уже внутри этого окружения организуется необходимое вам окружение и там уже работает ваш конечный софт(если это какая-нибудь java).
Профит очевиден. Юзеру ненужно ставить себе тысячи рантайма тысяч языков. Вам ненужно собирать свой рантайм под тысячи платформ, чтобы таскать его с собою. Юзеру ненужно заботится о том, что ваша jvm может быть заражена и украсть его данные/сломать ему систему.
Он просто ставит заранее надёжный wasm-рантайм а далее его ничего не волнует. Что там у вас, как там у вас. Он просто использует что угодно, где угодно, безопасно.
Юзеру ненужно ставить себе тысячи рантайма тысяч языков.
Покажите альтернативу. Что есть остальные 14(или сколько их там) стандартов?
Он не конкурирующий, он обратно совместимый
wasm сейчас скорее выглядит как перспективное решение для всяких AWS Lambda и подобных.
1. Можно скомпилировать почти что угодно
2. Нет проблемы холодного старта, тк провайдер может заранее скомпилировать и закэшировать у себя
3. достаточно легко считать "газ", а соответственно более точно и предсказуемо выставлять счета (в отличие от CPU*hour)
запуск WebAssembly за пределами веба
А что, в пределах веба он уже играет какую-то ощутимую роль? А то я за последнее время лишь парочку статей на хабре по практическому применению WebAssembly видел. И все они в духе «Да, технология перспективная. И у нас действительно что-то получилось. Но у нее еще есть ряд немаловажных ограничений.»
Так что складывается впечатление, что все об этом уже долго говорят и единодушно признают, что за этим будущее, а оно все никак не наступает, и когда наступит — непонятно.
На хабре есть статьи, где wasm успешно крутится в продакшене. Важно лишь можно использовать в продакшене или нет
На мой взгляд, кроме принципиальной возможности использовать на проде, важно какое количество проблем он готов решить. Т.е., если он по своей идеологии и уровню развития окружения будет подходить лишь для 0,25 процентов проектов, то говорить о том, что эта технология действительно взлетела и хоть сколько-то реализовала свой потенциал, не приходится.
И судя из этой статьи и комментов к ней wasm сейчас имеет очень мало реально полезных применений и целый ряд ограничений, в частности, отсутствие стабильных компиляторов для многих популярных языков и невозможность обращаться к браузерному api напрямую, без использования js прослойки, ну, и общую некую сырость экосистемы в целом.
Поэтому и интересно, является ли wasm частью чьих-нибудь «будней веб-разработчика». Потому что, на мой субъективный взгляд, в широкой практике его не видно вообще.
И судя из этой статьи и комментов к ней wasm сейчас имеет очень мало реально полезных применений и целый ряд ограничений, в частности, отсутствие стабильных компиляторов для многих популярных языков и невозможность обращаться к браузерному api напрямую, без использования js прослойки, ну, и общую некую сырость экосистемы в целом.
Поэтому и интересно, является ли wasm частью чьих-нибудь «будней веб-разработчика». Потому что, на мой субъективный взгляд, в широкой практике его не видно вообще.
WebAssembly изначально решал одну конкретную проблему. WebAssembly это не швейцарский нож.
частности, отсутствие стабильных компиляторов для многих популярных языков
Это претензии к этим самым популярным языкам.
невозможность обращаться к браузерному api напрямую
Лично нам это никак не мешает.
WebAssembly это не швейцарский нож.
А тут я как-то не нашел слов, что wasm не предназначен для решения каких-то задач. Ну, и если wasm не подходит/предназначен для употребления в качестве универсального швейцарского ножа, то что тогда предназначено? JS что ли? :) Какие у него в принципе могут быть преимущества перед wasm, кроме проработанного окружения, конечно же.
А тут я как-то не нашел слов, что wasm не предназначен для решения каких-то задач.
Там же написано, для чего он предназначен:
WebAssembly (abbreviated Wasm) is a binary instruction format for a stack-based virtual machine. Wasm is designed as a portable target for compilation of high-level languages like C/C++/Rust, enabling deployment on the web for client and server applications.
Очевидно, что делать лендинги на C/C++/Rust это не про wasm.
Все равно не вижу ограничений.
Там сказано, что wasm нужен для компиляции высокоуровневых языков в бинарный формат и их использовании на клиенте и сервере. А использовать его вы, в принципе, можете, как захотите, хоть на лендинге. В конце концов уменьшение размера загружаемых ресурсов и увеличение скорости их выполнения не помешают нигде, вопрос лишь в цене.
Хотя я конечно больше говорил про SPA и какой-нибудь golang или ts в качестве языка разработки. И они, кстати, под формулировку «compilation
of high-level languages like...» тоже подходят, так что идеологии wasm, имхо, нисколько не противоречат.
Там сказано, что wasm нужен для компиляции высокоуровневых языков в бинарный формат и их использовании на клиенте и сервере. А использовать его вы, в принципе, можете, как захотите, хоть на лендинге. В конце концов уменьшение размера загружаемых ресурсов и увеличение скорости их выполнения не помешают нигде, вопрос лишь в цене.
Хотя я конечно больше говорил про SPA и какой-нибудь golang или ts в качестве языка разработки. И они, кстати, под формулировку «compilation
of high-level languages like...» тоже подходят, так что идеологии wasm, имхо, нисколько не противоречат.
уменьшение размера загружаемых ресурсов
Что с чем сравниваем?
увеличение скорости их выполнения не помешают нигде
Wasm не увеличивает скорость выполнения. Wasm призван сэкономить на парсинге большого asm.js файла, но нигде не утверждается, что он будет быстрее работать чем JS после JIT.
какой-нибудь golang или ts
Вы не поверите, но golang поддерживает компиляцию в wasm.
Ну, golang, вроде как, на уровне бета-версии сейчас wasm поддерживает. Только ко 2 версии релизную обещают. Да и SPA при условии накладных расходов общения wasm с DOM смысла на нем нет делать.
Скорость старта — тоже важная характеристика. Байт код все-таки, наверное, быстрее парсится да и пространства под оптимизации поболе имеет.
Скорость старта — тоже важная характеристика. Байт код все-таки, наверное, быстрее парсится да и пространства под оптимизации поболе имеет.
Что с чем сравниваем?
Исходный код и бинарное представление. Но дело даже не в этом — wasm генерирует компилятор со всеми вытекающими. Возможности компилятора по уменьшению кода куда выше, нежели у минификаторов. А такие вещи как google closure compiler не далеко ушли от минификатора. Для примера посмотрите на дарт и его компилятор в js.
Wasm не увеличивает скорость выполнения.
Это была одна из задач.
Wasm призван сэкономить на парсинге большого asm.js файла
wasm — это уже далеко не asm.js. К тому же asm.js не был изолирован от js и напрямую мог его вызывать, а значит ни о какой адекватной компиляции речь идти не могла.
что он будет быстрее работать чем JS после JIT.
Ну это же очевидные вещи. jit никак js помочь не может. Нужна оптимизация, т.е. выкидывание всего js из js. Кейсов где возможна подобная оптимизация очень мало. К тому же jit как компилятор очень слаб и рядовая логика обычно вообще никак не оптимизируется( она исполняется мало и слишком динамичная — т.е. оптимизатор будет оптимизировать код дольше, чем исполняется функция + это мало что даст, т.к. основная нагрузка там именно на js-рантайм).
За примерами тоже далеко ходить не нужно. Посмотрите на dart и на то как они решают проблемы производительности. Это не смотря на то, что dart куда более статический язык, нежели js.
Исходный код и бинарное представление.
Сравнивать нужно именно с конечным JS, например полученным asm.js после компиляции крупного C/C++/Rust проекта. Когда на выходе 50+ Mb файл, то задумываешься о том, что бы быстро его парсить. Естественно бинарный формат парсится быстрее.
Ну это же очевидные вещи. jit никак js помочь не может
Ой ли? Вы проводили тесты производительности js и wasm кода в разных браузерах, на разных архитектурах(arm/x86)?
например полученным asm.js
Причём тут полученный asm.js? Проблема asm.js не в том, что он текстовый, а в том, что это некий избыточный код для существующего js-кода. Текстовый wasm куда компактнее asm.js.
Ой ли?
Это очевидные вещи. Вам даже привели пример — dart, как пример сравнения jit/aot в js-подобном языке с vm подобной v8 от её же авторов. Сравнением же компилируемого(того же С++) и jit(особенно js) — завален весь интернет.
Вы проводили тесты производительности js и wasm кода в разных браузерах, на разных архитектурах(arm/x86)?
Начните с себя, я подожду ваших доказательств в пользу «не отличается». Это не более чем попытка тратить моё врем, хотя все вводные уже были даны и из них делается один простой вывод — js и какой-то слабый jit никогда не смогут конкурировать с полноценным компилятором и статическим языком.
подобной v8 от её же авторов
Представьте себе, не у всех v8.
Начните с себя
Мы начали и закончили. Летом будет 2 года, как используем в продакшене
js и какой-то слабый jit никогда не смогут
Только в браузер ничего другого не завезли. Wasm выполняется тем же движком, что и JS.
Что-то вы ушли с темы и опять проигнорировали почти все мои тезисы, тезисы неудобные.
Почти у всех, да и это говорит не в пользу js. Сделать хороший aot для wasm куда проще. Та же мозила его делает и он вполне на уровне. А вот js уже уступает v8.
На этом уже можно закончить. emscripten это тонны костылей и рантайма для эмуляции нативной среды в броузере. Их проблемы и производительность — имеют малое отношение к wasm.
К тому же, какое отношение ссылка имеет к теме? Там рассуждения про касты и emscripten. Покастуйте даблы в инты на js, а лучше в 64 битные инты. Или про js мы уже забыли?
Неверно. Никакого того же движка нет, да и вообще это полная глупость. Он внутри того же v8 находится не потому, что «другого нет» и не потому, что его собирает тот же jit — это обусловлено совершенно другим.
Первое — wasm должен иметь общую память с js. Второе — wasm должен исполняется в изолированной среде. Это среда уже создана для js — зачем её писать второй раз? Тоже самое касается и рантайма, который везде одинаковый и кодогенератора.
По-сути v8 стал таким себе llvm, т.е. он некий middle/back-end и для wasm и для js.
Представьте себе, не у всех v8.
Почти у всех, да и это говорит не в пользу js. Сделать хороший aot для wasm куда проще. Та же мозила его делает и он вполне на уровне. А вот js уже уступает v8.
Мы начали и закончили. Летом будет 2 года, как используем в продакшене
emscripten
На этом уже можно закончить. emscripten это тонны костылей и рантайма для эмуляции нативной среды в броузере. Их проблемы и производительность — имеют малое отношение к wasm.
К тому же, какое отношение ссылка имеет к теме? Там рассуждения про касты и emscripten. Покастуйте даблы в инты на js, а лучше в 64 битные инты. Или про js мы уже забыли?
Только в браузер ничего другого не завезли. Wasm выполняется тем же движком, что и JS.
Неверно. Никакого того же движка нет, да и вообще это полная глупость. Он внутри того же v8 находится не потому, что «другого нет» и не потому, что его собирает тот же jit — это обусловлено совершенно другим.
Первое — wasm должен иметь общую память с js. Второе — wasm должен исполняется в изолированной среде. Это среда уже создана для js — зачем её писать второй раз? Тоже самое касается и рантайма, который везде одинаковый и кодогенератора.
По-сути v8 стал таким себе llvm, т.е. он некий middle/back-end и для wasm и для js.
Почти у всех
На iOS нет никакого V8.
Их проблемы и производительность — имеют малое отношение к wasm.
Пока что, они генерят лучший код, чем llvm.
- JS в современном мире хорошо джитится. Иначе не было бы игр на Unity и Unreal с хорошим FPS.
- Нет никакого существенного оверхеда, при вызове js кода из wasm. При рендеринге каждого кадра вызывается десятки и сотни методов WebGL. Если был бы оверхед, то Doom 3 не давал бы в среднем 30 FPS.
Нелепые попытки игнорировать все тезисы и минусовать продолжаются.
И? Что из этого следует? Я где-то говорил, что он везде? Нет. Почему нету ответа на всё остальное?
Кто они и где пруфы?
Опять всякие глупости, никакой Unity и Unreal на js не написан. К тому же, я уже приводил реальные примеры, а не эту чушь. Точно так же я уже говорил, что никакой jit никому не интересен и вообще ничего не значит.
Вы пытаетесь кидать какие-то лозунги даже не понимая что они значат и в каком контексте они действительно работают. Дак вот — jit является чем-то быстрым именно в контексте сравнения с интерпретатором. Всё то, что вы пытаетесь мне ретранслировать — взято именно из этого контекста. Если же мы выходим за контексте сравнения с интерпретатором, то всё это перестаёт работать.
Надо пойти и изучить базовую матчасть перед тем как кидаться подобными окровениями.
Я не понимаю к чему пишутся эти рандомные фразы. Причём тут оверхед, какой ещё оверх? Это попытка сев в 10раз в лужу придумать новую тему? Ну дак и с ней возникла проблемы — оверхед там гигантский. Для этого достаточно зайти на девблог v8 и почитать.
Я кажется понял к чему эти относится эти глупые фразы. Это попытка ответить на мой тезис:
Это попытка поспорить? Она глупа и неудачна. Как минимум потому, что у js/asm.js(и любой нативщины) абсолютно разные форматы данных и call abi. Единственное, что там можно на халяву(условно) перекидывать между функциями — это value-типы, т.е. даблы. Именно поэтому это и есть единственный способ коммуникации, но даже он показывает плохую производительность.
Пруфы про «десятки и сотни». Конкретное кол-во в студию. К тому же, это просто крохи нелепые. Даже сисколы измеряются сотнями тысяч, не говоря уже о нативных вызовах. Да даже js-вызовов в рамках самого js.
К тому же, причём тут вообще webgl? Там используются внутренние/value-типы. webgl может быть специально оптимизирован. К тому же, вызовы js->натив куда менее сложные, нежели натив->js.
К тому же, ваши новые отсылки противоречат ваши предыдущим заявлениям. Автор порта:
Где же «разницы нет» и js-jit всё смог? Или опять всё забылось?
На iOS нет никакого V8.
И? Что из этого следует? Я где-то говорил, что он везде? Нет. Почему нету ответа на всё остальное?
Пока что, они генерят лучший код, чем llvm.
Кто они и где пруфы?
JS в современном мире хорошо джитится. Иначе не было бы игр на Unity и Unreal с хорошим FPS.
Опять всякие глупости, никакой Unity и Unreal на js не написан. К тому же, я уже приводил реальные примеры, а не эту чушь. Точно так же я уже говорил, что никакой jit никому не интересен и вообще ничего не значит.
Вы пытаетесь кидать какие-то лозунги даже не понимая что они значат и в каком контексте они действительно работают. Дак вот — jit является чем-то быстрым именно в контексте сравнения с интерпретатором. Всё то, что вы пытаетесь мне ретранслировать — взято именно из этого контекста. Если же мы выходим за контексте сравнения с интерпретатором, то всё это перестаёт работать.
Надо пойти и изучить базовую матчасть перед тем как кидаться подобными окровениями.
Нет никакого существенного оверхеда, при вызове js кода из wasm.
Я не понимаю к чему пишутся эти рандомные фразы. Причём тут оверхед, какой ещё оверх? Это попытка сев в 10раз в лужу придумать новую тему? Ну дак и с ней возникла проблемы — оверхед там гигантский. Для этого достаточно зайти на девблог v8 и почитать.
Я кажется понял к чему эти относится эти глупые фразы. Это попытка ответить на мой тезис:
К тому же asm.js не был изолирован от js и напрямую мог его вызывать, а значит ни о какой адекватной компиляции речь идти не могла.
Это попытка поспорить? Она глупа и неудачна. Как минимум потому, что у js/asm.js(и любой нативщины) абсолютно разные форматы данных и call abi. Единственное, что там можно на халяву(условно) перекидывать между функциями — это value-типы, т.е. даблы. Именно поэтому это и есть единственный способ коммуникации, но даже он показывает плохую производительность.
При рендеринге каждого кадра вызывается десятки и сотни методов WebGL. Если был бы оверхед, то Doom 3 не давал бы в среднем 30 FPS.
Пруфы про «десятки и сотни». Конкретное кол-во в студию. К тому же, это просто крохи нелепые. Даже сисколы измеряются сотнями тысяч, не говоря уже о нативных вызовах. Да даже js-вызовов в рамках самого js.
К тому же, причём тут вообще webgl? Там используются внутренние/value-типы. webgl может быть специально оптимизирован. К тому же, вызовы js->натив куда менее сложные, нежели натив->js.
К тому же, ваши новые отсылки противоречат ваши предыдущим заявлениям. Автор порта:
Put it in other words, while WebAssembly/C++ is 2x slower than Native/C++, it is nevertheless 3x faster than pure Javascript.
Где же «разницы нет» и js-jit всё смог? Или опять всё забылось?
Из всех комментариев здесь (в частности, ваших) я так и не понял, как именно работает WASM. Я погуглил (может быть, я не умею гуглить), и нашел о том, что такое WASM, насколько это круто, как компилировать то или это под WASM и запускать в браузере. Но я так и не нашел деталей имплементации, например, в движке Blink.
Вы говорите, что WASM быстрее, чем JS JIT. Как имплементирован WASM? Как этот абстрактный ассемблер исполняется? JIT-компиляция? Почему тогда это быстрее, чем JS JIT? AOT-компиляция, т.е. перед запуском? И насколько это долго?
(С тем, что особенности самого JS не способствуют скорости я не спорю).
Но я так и не нашел деталей имплементации, например, в движке Blink.
blink — это не про wasm. Про wasm — это v8. Можете сюда посмотреть: github.com/WAVM/WAVM
JIT-компиляция?
Можно и так.
Почему тогда это быстрее, чем JS JIT?
Потому что сам по себе jit ничего не значит и ничего не стоит. jit — это просто генератор машинного кода. Да, это много даёт в сравнении с интерпретатором(отсюда и мифы, что jit какой-то там быстрый и прочее). Но мы не сравнивает jit и интерпретатор.
Что такое js? Это динамический язык на 90% состоящий из внешнего(по отношению к js) рантайма. dom, регулярки, вся объектная модель, сами объекты(массивы, строки) — всё это реализовано С++ кодом в той же v8.
И в этом случае какая-то оптимизация не очень помогает. А что она вообще может сделать, если код на самом js исполняется 10-20% времени?
Поэтому оптимизировать js попросту бесполезно — это ничего не даст, но. Решение есть. Мы можем провести анализ кода и найти те места, где использование рантайма мы можем заменить на value-типы.
Допустим, у нас в коде очень часто используется какой-нибудь объект: {x: number, y: number}, мы можем понять, что в нём нету никаких прототипов, в него поля не записываются и читаются/пишется только в x/y.
Мы берём и заменяет js-объект на нативный объект( на что-то типа struct {double x; double y;}). И далее нам ненужно использовать сложный рантайм — мы его выкинули и заменили на структуру.
Но даже самый оптимизированный js-код никогда не будет работать как нативный. Причины тоже просты и понятны. Даже если мы видим, что ничего кроме x/y не используется — это не значит, что вскоре не придёт z. Поэтому js-jit постоянно должен вставлять в код всякие ловушки, которые будут ловить «не то пришло» и деоптимизировать код.
Из этого так же можно понять, что обычный код в js попросту почти никак не оптимизируется. Причины я описывал выше, где я говорил о дарте. dart это показательный пример того — насколько может jit и динамический язык.
Но васм это не-динамическое представление — ему ненужен никакой рантайм(почти). Его можно сразу брать и компилировать прямиком в оптимальный нативный код. В оптимальные нативные структуры данных.
К тому же нужно понимать, что wasm уже оптимизирован. А js это попросту исходник на динамическом языке.
AOT-компиляция, т.е. перед запуском? И насколько это долго?
Да. Это не очень долго и это можно кэшировать. jit для wasm достаточно прост + код уже оптимизировать + из кода уже выкинуто всё лишнее + там ненужны все эти сложности(я о них выше рассказывал), которые присущи jit для динамических языков.
По крайней мере для FF разрабатывается потоковый компилятор: компиляция производится параллельно, по мере загрузки wasm-кода. Причем компилируется это быстрее, чем загружаются данные по сети. Таким образом, после окончания загрузки программа уже готова к выполнению. После этого в фоне начинает работу оптимизирующий компилятор. Как только он закончит компиляцию, первая версия программы в памяти будет заменена на вторую, более производительную.
Вообще это прекрасное промежуточное представление для любых аддонов и расширений программ, а еще это же великолепное промежуточное представление для всяких хранимых процедур и, упаси боже, для блокчейн транзакций.
По сути дела осталось дождаться, когда больше языков будут уметь исполнятся в wasm. Причем если сложные языки с большой vm типа jvm или .net будут тут смотреться как слон на трехколесном велосипеде, то для скриптовых типа питона или lua это очень хорошая тема. Всегда же можно GC оставить на уровне подсчета ссылок и таким образом срезать 90 процентов веса рантайма.
Пока еще Python в WASM можно скомпилировать только вместе с его рантаймом. Увы и ах, Python слишком динамичен. Собственно, поэтому в данной нише у таких языков как Rust есть преимущество.
И для того, чтобы переносимо и безопасно запустить программу на Python, не заботясь о том, есть ли у пользователя Python, какой версии и с какими библиотеками, мы
- загрузим python-рантайм, скомпилированный под WASM
- загрузим все библиотеки (если у них есть нативная составляющая, например, numpy, она тоже должна быть под WASM)
- наконец, загрузим наше приложение.
Время старта кажется очень большим. А также потребление дискового пространства, если мы захотим все закэшировать. Бонус — мы избавились от dll-hell.
Данная концепция исходят из защиты на основе полномочий, как в системах CloudABI и Capsicum.
Ощущаю себя парнем, который случайно попал в новости и узнал своё смазанное лицо: WebAssembly/reference-sysroot #4.
CraneStation/wasmtime/docs/WASI-api.md (wasi.dev ссылается на него) выгляди так, будто они отрерайтили NuxiNL/cloudabi, но ничего плохого не вижу ибо это хорошая годная штука изначально.
Sign up to leave a comment.
Стандарт WASI: запуск WebAssembly за пределами веба