AF
wasm это же не только про браузеры но и про все где есть js?
Wasm вообще никак с js не связан. Wasm - это просто бинарный формат.
Size: a a a
2020 October 15
AF
кстати, очень рекомендую ознакомиться с FAQ (ссылка в описании группы)
NK
я прочел его 2 раза, но все прямо не упомнить зато нашел линку на assembyScript которую пропустил
AR
предсказуемой скорости выполнения нет из за типизации и того что на разогрев функции нужно 11088 проходов и ее можно деоптимизировать если засунуть после что то что не было ожидаемо? Можно не отвечать на мои вопросы прямо простой линки всегда достаточно))
В основном, сборка мусора и несколько стадий jit'а. Всё это может запуститься в случайный момент и даже совершенно непредсказуемо повлиять на последующую производительность
NK
то что есть в faq или вы думаете что есть можно так помечать кстати с пересылкой что бы меньше было напряжения
AR
Тут кстати вопрос чем wasmtime с jit'ом принципиально лучше js в плане предсказуемости скорости выполнения
NK
Ну его даже в IoT засунули. Но это скорее исключение. А вообще JS не стоит засовывать в рантаймы где нужна:
a) предсказуемая скорость выполнения
б) строгий детерминизм
в) многопоточность
г) малое потребление памяти
д) безопасность
a) предсказуемая скорость выполнения
б) строгий детерминизм
в) многопоточность
г) малое потребление памяти
д) безопасность
а в assemblyscript это все есть или не совсем?
M
Тут кстати вопрос чем wasmtime с jit'ом принципиально лучше js в плане предсказуемости скорости выполнения
Много чем. Во первых там совершенно разные типы jit компиляторов. В wasmtime да и во всех остальных движках для wasm нету деоптимизаций, т е производительность не может деградировать в произвольный момент, кроме в wasm есть информация о типах, которая позволяет оптимизировать лучше и быстрее.
M
а в assemblyscript это все есть или не совсем?
assemblyscript таргетиться в wasm, стало быть обладает такими же преимкществами)
AR
Много чем. Во первых там совершенно разные типы jit компиляторов. В wasmtime да и во всех остальных движках для wasm нету деоптимизаций, т е производительность не может деградировать в произвольный момент, кроме в wasm есть информация о типах, которая позволяет оптимизировать лучше и быстрее.
Я скорее про то, что wasmtime тоже надо греть иначе производительность скакнет в произвольный момент (но, да, только в одну сторону). И что этот скачок может сопровождаться фризами (хотя смотря где там jit происходит)
Но если дальше лезть в кроличью нору, то окажется, что вообще любой код греть надо, даже нативный
Но если дальше лезть в кроличью нору, то окажется, что вообще любой код греть надо, даже нативный
M
Я скорее про то, что wasmtime тоже надо греть иначе производительность скакнет в произвольный момент (но, да, только в одну сторону). И что этот скачок может сопровождаться фризами (хотя смотря где там jit происходит)
Но если дальше лезть в кроличью нору, то окажется, что вообще любой код греть надо, даже нативный
Но если дальше лезть в кроличью нору, то окажется, что вообще любой код греть надо, даже нативный
Не нужно ничего греть, это не JVM=) Можно просто отключить baseline компилятор (lightbeam) в wasmtime и все. Будет несколько раз больше инстанцироваться но зато сразу получишь оптимальную производительность
M
JIT в wasm это не JIT в JVM или V8. Можно вообще без jit-а обойтись. Lucet так и делает например.
M
JIT в wasmtime нужен лишь для того что бы сгенерировать наимболее оптимальный машинный код релевантный платформе на которой она запускается. То есть это такой себе -march=native только компиляция происходит один раз во время запуска а не предварительно. Вот и все. Поэтому это и JIT.
AR
Ну тогда это не jit, а aot скорее.
Так я могу
Так я могу
gcc && ./a.out jit'ом назватьM
Просто многие когда слышат слово JIT скразу думают, хм, но ведь AOT быстрее. И думают неверно! В данном случае JIT намного лучше AOT. Но конечно это зависит сильно он компилятора
M
Ну тогда это не jit, а aot скорее.
Так я могу
Так я могу
gcc && ./a.out jit'ом назватьСкажем так, это отложенный AOT
AR
Ну тогда всё сходится. Я думал там именно jit, который во время выполнения
M
Ну тогда всё сходится. Я думал там именно jit, который во время выполнения
В том то и дело что нет. Там компилируется весь модуль один раз во время запуска и все, Никогда больше не перекомпилируется.
M
В отличии от JVM или JS где обычно JIT включается только выборочно для горячихз участков и происходят еще guard вставки (ловушки) для деоптимизации и провала в интерпретацию и т д. В общем в wasm jit всего этого нету и не нужно
M
Кстати хороший вопрос для FAQ