Comments 11
Только как-то очень хаотично написан раздел про llvm. Что получилось собрать, а что нет? В графики попала wasm версия полученная через asm.js, а упрощённый тест был просто для проверки, что 64 бита возможны? Тогда можно ожидать, что когда всё заработает wasm версия будет в несколько раз быстрее?
NaCl запрещён по умолчанию для веб-приложений, просить его включить в настройках некомильфо, т.е. сделать этого, можно сказать, что и нельзя.
Вот почему у PNaCl так плохо с инцииализацией при 100-килобайтном .pexe, мне непонятно, время jit-а должно быть несколько мс. Так что тоже не всё гладко… У wasm уже сейчас время старта стабильно, это хорошо.
Вы про нотацию use asm и процедуру валидации-компиляции-выполнения asm.js js subset, или про fastcomp, форк llvm, который используется в emscripten? Поддержку asm.js скорее всего уберут, когда все браузеры поддержат wasm. Может быть, какой-то переходный период будет, когда asm.js будет компилироваться браузером в wasm, но вообще его нет смысла тащить дальше, когда есть бинарный формат. C → wasm работает плоховато, потому что поддержкой компиляторов пока что ещё не очень и занимаются по-хорошему. Я думаю, приведут в порядок тоже. Компиляторов скорее всего вообще много будет, Microsoft наверное тоже что-то сделает.
Поддержку asm.js скорее всего уберут, когда все браузеры поддержат wasm.
А какой смысл убирать то, что уже добавлено. В ФФ — это отдельная прекомпиляция, а в других браузерах это ведь выполняется силами штатного компилятора, как это вообще можно убрать?
asm.js будет компилироваться браузером в wasm
А сейчас разве не так происходит? То есть не учитывая поддержку 64-разрядных целых разве wasm не просто бинарное представление asm?
но вообще его нет смысла тащить дальше, когда есть бинарный формат
Ну как сказать нет смысла — сейчас можно быстренько в asm критичные вещи завернуть и даже ничего не компилировать или на продакшн компилировать asmjs -> wasm. А если его уберут — прийдется на С писать и обязательно компилировать даже в стадии разработки.
В идеале было бы хорошо, чтоб asm развивался как один из языков которые компилируются в wasm. Опять же поддержка int64 в js совсем не помешает, эмуляция на int32 и правда медленная.
C → wasm работает плоховато, потому что поддержкой компиляторов пока что ещё не очень и занимаются
Ну не только по этому, рукописный код всегда аккуратнее сгенерированного, потому в случае asmjs -> wasm мы получим именно то, что написали, а вот c -> wasm иногда генерирует кучу ненужного мусора, нужно за этим следить. Но да, компиляторы и правда становятся лучше.
В целом asmjs сейчас очень помогает исправлять косяки в реализации браузерных API к примеру DataView и помогает писать критичные участки кода без предварительной компиляции. Очень хотелось бы, чтоб его развитие продолжилось и нововведения vm для wasm были портированы в asmjs и js.
Всмысле, что убрать могут анализ типов в коде, аннотации, специальную поддержку asm.js браузером… — потому что их достатчно сложно держать в актуальном состоянии. Тот же Firefox периодически отламвывает валидацию. Или просто перестанут развивать, оставив что работает. А может быть и нет, посмотрим, но пока я где-то читал, что его не планируют развивать, asm.js это переходный этап.
64-битная арифметика в браузере и WebAssembly