Comments 30
Не каждая стеково-регистровая машина становится ФОРТом. Для этого нужна, как минимум, встроенная возможность определять новые произвольные слова. Для чего нужна уже абстракция более высокого уровня, чем простая трансляция ограниченного набора инструкций байткода. Разновидность обычного ассемблера, скорее.
А ассемблером их язык можно назвать, поскольку имеем тот же принцип — мнемоники для машинных кодов. Другое дело, что вводились коды не поцифрово, а нажатием кнопок с мнемониками — но в памяять при этом вносился и появлялся на экране шестнадцатеричный машкод команд и операндов (получался такой аппаратный транслятор), и его можно было «дизассемблировать». Ну и еще сам алфавит мнемоник не существовал в машинном представлении.
Так же хотелось бы увидеть доказательство того как разные JVM исполняют один и тот же код по разному. Естественно, что речь не идёт про функции устройств, которые не входят в стандарт Java. Если Вы будете использовать в WA функции доступные только браузеру, то никакое WASI не спасёт вас от различающегося поведения кода. Не сможет консолька рисовать canvas, а браузер не сможет получить доступ к raw-сокетам.
Не вводите людей в заблуждение,
WASM это обычная виртуальная машина со стеклом и памятью, она не быстрее и не медленнее остальных (Jvm, net)
Безопасность там не лучше других, эта виртуальная машина не может определять чистая функция или нет, в спецификации этого может и не быть, а то что модули зачастую предоставляют чистые функции - это точнее не заслуга wasm, а разработчика модуля
Плюс ещё скажите лучше про ограничение в 4гб оперативны, и ещё не ясно как в ней решен вопрос синхронизации поток (cpu)
Хотяв целом я рад ее появлению, но далеко не все языки включили поддержку
Ну и про jvm - тоже заблуждение, jvm вполе из коробки безопасна и ограничить доступ к ОС делается на раз
и не медленнее остальныхВесьма спорное утверждение. Ценой внешней похожести на настоящий ассемблер стало затирание информации о типах. И если JVM откомпилировав метод может быть уверена, что при вызове метода, this != null && VALID_PTR(this) && VALID_PTR(this+sizeof(myclass)) и можно не проверять данные в процессе выполнения. То в случае же WASM всё это проверять необходимо. У всё тоже самое для каждого указателя, независимо от того, как долго функция будет с ним работать. Для аппаратного ускорения таких проверок, нужно писать полноценную виртуальную машину работающую в ядре ОС. А браузерописатели к этому совсем не готовы.
Браузерописатели ко всему готовы, на V8 гугл изначально нанял чуваков с 20-30 лет опыта написания интерпретаторов и виртуальных машин. Многие разработчики JVM были сханчены.
И если JVM откомпилировав метод может быть уверена, что при вызове метода, this != null && VALID_PTR(this) && VALID_PTR(this+sizeof(myclass)) и можно не проверять данные в процессе выполнения. То в случае же WASM всё это проверять необходимо
А что мешает эти проверки провести на этапе компиляции в WASM?
Я не понял ваш ответ. Допустим, у меня есть программа на Rust, и компилятор мне проверил, что нигде нет null. Я эту программу компилирую в WASM. Зачем мне там теперь нужны динамические проверки?
Зачем ему вообще что-то проверять, если вся программа работает в своей собственной линейной памяти и за ее пределы выйти не может?
Насколько я знаю, под каждый wasm-модуль выделяется 16 Гб виртуальной памяти, 8 Гб до начала памяти модуля, и 8 Гб на саму память (guard pages). Поэтому максимальный адрес, который может быть использован в WASM 32, не выходит за данный диапазон (он рассчитывается как 0xffffffff + 0xffffffff = 0x1fffffffe), и проверка условия не требуется.
Безопасность там не лучше других, эта виртуальная машина не может определять чистая функция или нет
Чтобы написать грязную ф-ю надо из нее вызвать уже существующую грязную функцию, т.е. нужны грязные примитивы, на уровне языка или его стандартной библиотеки.
Речь не о том, что виртуальная машина определит, чистая функция или нет.
Речь о том, что wasm для внешнего мира может быть только чистой функцией и ограниченным списком внешних api
Если все api будут безопасными - разработчик может написать только чистые функции либо чистые функции, которые вызывают безопасное api.
Но согласен, в чем отличие от остальных VM, которые тоже нормально контролируют свою память и свое внешнее api - непонятно
Этот ваш WA это очередная тупиковая ветвь развития (по производительности быстрее java и собратьев не будет ни конда). WA нужен только что бы фортрановские коды не переписывать на javascript ибо не каждый осилит (очень дорого), а полезного много.
Что код был быстрым приходится учитывать особенности железа (особенности векторизации, кэши, количество каналов памяти, длину конвейера спекулятивного исполнения и топологию процессоров). Как это всё учитывается в WA?
Более того почти всегда используются уже готовые высоко оптимизированные библиотеки для типовых вычислений которые постановляют производители железа (intel, nvidia, amd ...) и самому не заморачиваться, а тут ничего нет только выход в javascript (который это может скормить часть вычислений в ускоритель через webgl и т.о. не факт)
И еще это минимализм может привести к тому что, когда вы компануя разные модули можете заметить десяток разных вариантов реализации одного и того же функционала, у каждого модуля но по разному. Например у каждого модуля будет своя особенная библиотека для работы с векторами и матрицами. В результате чего размер итогового файла будет расти как на дрожжах.
Никогда общее решение не будет быстрее специализированного решения, особенно сейчас когда уже производительность на ядро уперлось в потолок и мы видим увеличение длинны векторных инструкций появления специализированных вычислителей под разные особенности вычислительных конвейеров
Вы не хотите покритиковать всю архитектуру x86? Это не повод от нее отказываться.
Лучше васм чем его отсутствие.
Этот ваш WA это очередная тупиковая ветвь развития (по производительности быстрее java и собратьев не будет ни конда).
эволюционная ветвь, уже 5 лет и пока все мысли о развитии. Не похоже на тупик в ближайшей перспективе.
Поживем увидим конечно, но на данный момент как и говорится нам остается только ждать чуда описанного в посте, т.к пока что он остается "ЯП низкого уровня" но не менее полезным чем его конкуренты, он переносимый как на Web Так и на такие языки как C++, C#. Да и лет не особо много прошло с момента его появления и утверждать что скоро он станет повсеместно используемым это как тыкать пальцем в небо.
Большинство из нас слышали мантру «Напиши раз, развертывай везде», которую популяризовали сторонники байткода Java, но Wasm не является просто разновидностью JVM или .NET CLR.
Во-первых, байткод Java по факту не портативен, и разные JVM могут выполнять его совершенно по-своему, исключая возможность переноса. Фреймворк .NET тоже заявляет о портативности, хотя и JVM, и .NET CLR, на мой взгляд, слишком перегружены инструкциями, чтобы уверенно обеспечивать такую возможность. При этом многие из их инструкций буквально нарушают необходимые для портативности условия. К примеру, и JVM, и .NET предоставляют доступ к операционной системе, что уже создает проблемы с переносом, а также вносит риски для безопасности, о чем я расскажу ниже.
Про то, что «JVM могут выполнять по разному» — это ложь, до тех пор, пока автор не предоставит доказательств обратного. Я по памяти могу вспомнить только пример, где Оракловская JVM корректно работает с виндоусовским керберосом, а опенсорсная — нет, но сомневаюсь что такое будет проблемой для большинства пользователей.
Вообще, смешно — убили java applet'ы в браузере, вырезали JVM-ку, «потому что ненадёжно!», что бы в итоге к тому же самому и вернуться. Ах, да! Сейчас она не перегружена инструкциями и не даёт доступ к системе. Потом, внезапно, окажется что существующих команд недостаточно, начнут добавлять, выкатят масштабное дополнение для более прямого доступа к системным ресурсам, а в итоге, внезапно, окажется, что у нас очередной комбайн, изучать который молодые программисты не захотят и от которого надо будет избавляться. Задолбало…
WebAssembly был содан для того что бы покончить с монополией богомерзкого JavaScript в баузерах. И дать возможность писать высоко оптимизированный код на нормальных языках програмирования.
WebAssembly – это ни web, ни assemblyНо, Wasm это же такой ассемблер. Т.е. WebAssembly это ни web, ни assembly, ни Wasm. Хотя конечно Wasm уже умер и можно переиспользовать имя, но создается ощущение
При изучении WebAssembly (кратко именуемого Wasm)…
Что это за зверь — WebAssembly?