Компиляция Assemblyscript в Wasm, производительность
Я видел, что уже есть компилятор для компиляции TypeScript в WebAssembly (Wasm), Ссылка здесь.
Я также слышал из множества источников, что компиляция JS в Wasm неосуществима из-за динамической природы и динамических типов JavaScript.
Однако TypeScript предлагает типизированные переменные, которых нет в JavaScript. А в будущем Wasm сможет даже взаимодействовать с DOM / взаимодействовать с другим веб-API.
Вопрос:
Будет ли написание приложений на TypeScript и его компиляция в Wasm давать какие-либо преимущества в производительности по сравнению с написанием веб-приложения на JavaScript?
![Безумие обратных вызовов в javascript [JS]](https://i.imgur.com/WsjO6zJb.png)
Ответы 3
Если вы можете скомпилировать определенную функциональность Javascript до Wasm, вероятно будет работать быстрее. JavaScript работает очень быстро по сравнению с другими динамическими языками, поскольку (большинство) браузеров компилируют его до байт-кода низкого уровня, который очень быстро интерпретируется (или даже выполняется изначально). Wasm спроектирован так, чтобы быть очень близким к байт-коду, поэтому в лучшем случае JS и «подмножество JS с типами, скомпилированными в Wasm» работают с одинаковой скоростью (если оба компилятора хорошо справляются со своей задачей). Но:
1) Исходный код JS, вероятно, больше, чем код Wasm, поэтому его загрузка с сервера занимает больше времени (время запуска)
2) JavaScript должен быть оптимизирован для такой быстрой работы, и, поскольку он не знает типов / времени жизни переменных и свойств, требуется некоторое время, пока движок не найдет лучший способ его скомпилировать, этот процесс оптимизации требует времени. (время разогрева).
Тем не менее, вы не можете просто превратить большую часть JavaScript или TypeScript в Wasm (вот почему AssemblyScript является подмножеством TS) по разным причинам:
1) eval, with или просто for(const el of [1, "seven", null]) убивают производительность в JS, но их невозможно скомпилировать в Wasm (потому что они убивают производительность).
2) В JavaScript есть сборка мусора.
Не уверен, откуда вы взяли, что Wasm разработан так, чтобы быть близким к байтовому коду JS. Это неверно на нескольких уровнях. Во-первых, Wasm спроектирован так, чтобы быть близким к машинному коду оборудования и не иметь никакого отношения к JS. Вот почему это быстро. Во-вторых, движки JavaScript также не запускают оптимизированный JS как байтовый код, а компилируют его в собственный код.
@andreas medium.com/dailyjs/understanding-v8s-bytecode-317d46c94775, насколько я понимаю, v8 компилирует только горячие функции в собственный код. Поэтому термин «компиляция» здесь немного ошибочен, поэтому он смешан с термином «интерпретируемый», чтобы отличить его от реального скомпилированного кода. Что касается части Wasm, я полагаю, вы правы и изменили "этот байт-код" на "байт-код".
Конечно, но V8 не использовал байтовый код до прошлого года, его введение в качестве первого уровня - недавнее изменение. Этот байт-код предназначен исключительно для JS и не имеет ничего общего с Wasm. Кроме того, он намного медленнее, поэтому не используется для быстрого выполнения.
@andreas да, но моя точка зрения все еще остается в силе. Если вы пишете код более высокого уровня, неважно, будет ли он скомпилирован в Wasm раньше или будет скомпилирован интерпретатором JS, вы получите почти тот же байт-код, поэтому он будет работать одинаково быстро.
Я не уверен, что ты имеешь в виду. Wasm не компилируется до байтового кода, поэтому код, скомпилированный с помощью Wasm, не может «закончиться байтовым кодом». Оба пути могут закончиться собственным кодом, но даже это будет выглядеть очень по-разному между ними.
@andreas, но можно сказать, что Wasm и JS, выполняющие разумные задачи, могут работать с одинаковой скоростью, верно?
Ну да, но это гипотетическое утверждение, верное для любых двух языков. На практике это маловероятно для нетривиального кода JS и Wasm.
Реальный ответ: нет. Есть несколько распространенных заблуждений по поводу TypeScript. Во-первых, он менее динамичен, чем JavaScript. Это неправда, на самом деле он настолько же динамичен, как JS, потому что он охватывает всю семантику JavaScript (включая все безумные угловые случаи), а его система типов слишком слабая и ненадежная, чтобы гарантировать, что обычный автономный компилятор может использовать для статической оптимизации. В лучшем случае типы могут использоваться как подсказки, которые динамическая виртуальная машина может сначала попытаться оптимизировать, зная, что они могут оказаться неверными.
(Кроме того, я не знаю компилятора TypeScript-to-Wasm. Вы, вероятно, думаете об AssemblyScript, но, хотя он повторно использует синтаксис TypeScript, его семантика сильно отличается.)
Итак, этот компилятор github.com/AssemblyScript/assemblyscript не компилирует TS в WASM? А скрипт сборки для WASM?
Вы указали AssemblyScript в своем вопросе. Сценарий сборки - это чрезвычайно строгий набор машинописных текстов. Не путайте это с самим машинописным текстом. Большая разница в том, что Typescript включает в себя все динамические атрибуты, которые мы все знаем и любим (ненавидим) в Javascript. AssemblyScript, с другой стороны, этого не делает.
Примеры пары больших различий: в AssemblyScript у вас не может быть закрытий. У вас также не может быть типов объединения.
Отсутствие закрытий или дискриминируемых союзов - временное ограничение. Есть PR для реализации закрытия например: github.com/AssemblyScript/assemblyscript/pull/1240
Я думаю, вам следует заменить TypeScript на AssemblyScript, чтобы избежать путаницы.