c
а сколько времени занимает джиттинг васма перед стартом?
Size: a a a
2020 October 15
M
а сколько времени занимает джиттинг васма перед стартом?
Все зависит от того кслючем baseline или нет. Ну и от размера самого модуля. А вообще джита в привычном понимании нету. Лучше это называть компияцией во время истанцирования.
c
ну я так понимаю глубоких оптимизаций там не будет под текущий проц
M
ну я так понимаю глубоких оптимизаций там не будет под текущий проц
почему это?
c
ну кажется это довольно сложная и долгая процедура
c
ллвм же очень долго все потрошит
c
а инструкций в васме совсем уж мало относительно x86
M
ну кажется это довольно сложная и долгая процедура
Это сложная и долгая процедура для LLVM. Для предварительно оптимизированного wasm модуля это относительно просто. Тем не менее даже у wasmtime есть как минимум два IR (точнее LIR) представления, свой набор peephole правил и оптимизации для CFG (каскрутка циклов, loop rotation, loop peeling и т д), Ну иницкоуновневые вещи как оптимизация аллокации регистров, оптимизации для планировщика, селектора и т д
c
Это сложная и долгая процедура для LLVM. Для предварительно оптимизированного wasm модуля это относительно просто. Тем не менее даже у wasmtime есть как минимум два IR (точнее LIR) представления, свой набор peephole правил и оптимизации для CFG (каскрутка циклов, loop rotation, loop peeling и т д), Ну иницкоуновневые вещи как оптимизация аллокации регистров, оптимизации для планировщика, селектора и т д
ну те еще нужно понимать какой код умеют оптимизировать движки васма, чтобы подавать к ним полупереваренный код
M
ну те еще нужно понимать какой код умеют оптимизировать движки васма, чтобы подавать к ним полупереваренный код
Ну конечно у них есть там неоптимальные штуки (в основном я находил отутвующие правила для 64-битных операций), но это все временно. В идеале в светлом будующем wasmtime не должен сильно уступать будет LLVM, но компилировать при этом во много много раз быстрее. Но пока там разница примерно 1.5-3 раза унего с LLVM
c
Ну конечно у них есть там неоптимальные штуки (в основном я находил отутвующие правила для 64-битных операций), но это все временно. В идеале в светлом будующем wasmtime не должен сильно уступать будет LLVM, но компилировать при этом во много много раз быстрее. Но пока там разница примерно 1.5-3 раза унего с LLVM
а не будет такого в будущем что для каждого движка(хром, сафари, васмтайм) нужно будет выкатывать свою версию кода для максимальной скорости?
M
а не будет такого в будущем что для каждого движка(хром, сафари, васмтайм) нужно будет выкатывать свою версию кода для максимальной скорости?
Это вряд ли. Сейчас возможно и есть небольшая разница между FF и Chrome к примеру, но в дальнейшем этой разницы не должно быть. Кроме того, тот же LLVM не даст тебе сгенерировать какой то другой wasm код специфичный для некоего браузера. В этом нет смысла и это противоречит самой идеи и философии WerbAssembly (пункт про портативность)
c
ну и слава богу
c
а то для джса сейчас нужно прям понимать особенности оптимизаций каждого движка, иначе никак
К
@maxgraey а вы мантису и экспоненту в AS умеете считать у флоатов в виде m*10^n, а не m*2^n ?
Как
Как
toExponential в JSК
просто мне интересно, а можно 1 форму перевести в другую не высчитывая мантису, мне ток экспонента нужна по сути
M
@maxgraey а вы мантису и экспоненту в AS умеете считать у флоатов в виде m*10^n, а не m*2^n ?
Как
Как
toExponential в JSНе очень понимаю о чем ты. Есть про decimals (10-чная база), то это всегда soft-реализация и через сторонние библиотеки в любом языке.
toExponential(), это не decimal. Это просто конвертация (вывод) строки в scientific формате (всегда с экспонентой), только и всегоM
В AS пока не реализовано
M
только toString()
2020 October 16