Size: a a a

WebAssembly — русскоговорящее сообщество

2021 October 08

К

Константин in WebAssembly — русскоговорящее сообщество
берём d8, кормим демку, форсим турбофан - смотрим и байткод и ассемблерные инструкции которые он навыплевывал
источник

DM

Demi Murych in WebAssembly — русскоговорящее сообщество
d8, node, даже google chrome все они да, позволят осуществить ваш сценарий. Но есть одно НО.

К сожалению таким образом далеко не всегда можно составить правильное понимание того как это будет in wild. По причине того, что для ситуаций, которые человеку кажутся идентичными, для машины таковыми не являются, у машины может быть несколько совершенно разных паттернов оптимизации.

Самый простой пример этому алгоритм принятия решений о  инлайне кода вызываемой функции или алгоритм принятия решения о оптимизации функции в котором целый ряд оптимизаций зависит от размера функции. Не от кода, не от логики ее работы, а от ее размера. Где при оценке раземра, внезапно, могут принимать участие и комментарии в коде.

Потому безусловно, самым верным источником информации будет трейс выданный самим v8, но этот трейс нужно уметь читать( не только ориентироваться в архитектуре того процессора для которого сгенерирован трейс, но и понимать ту пачку статистических данных которые его сопровождают/описывают принятое решение) и быть в курсе хотя бы  базы  того, что у программистов V8 сейчас в тренде.
источник

К

Константин in WebAssembly — русскоговорящее сообщество
Тогда вообще пофигу, потому что ты не компилятор и не сможешь учесть всех вариантов.
Детерминизма невозможно достичь = пофиг как писать и чего ждать в каждом из кейсов использования.
Ну если только не профилировать с трейсом каждый раз скриптик после изменения количества и очередности операций.
источник

К

Константин in WebAssembly — русскоговорящее сообщество
Все же надо смотреть самый максимально производительный вариант и интерпретацию на игнишене
источник

PM

Pavel Mellonges® in WebAssembly — русскоговорящее сообщество
А есть ли под Webassembly самый предпочтительный язык? Какой самый популярный?
источник

AC

Alexander Chichigin in WebAssembly — русскоговорящее сообщество
AssemblyScript!!! 😃
источник

PM

Pavel Mellonges® in WebAssembly — русскоговорящее сообщество
Не думаю)
источник

AC

Alexander Chichigin in WebAssembly — русскоговорящее сообщество
На самом деле Rust, конечно. 😊
источник

AC

Alexander Chichigin in WebAssembly — русскоговорящее сообщество
Как "самый предпочтительный" — вполне.
источник

PM

Pavel Mellonges® in WebAssembly — русскоговорящее сообщество
Там просто на go и c# ещё поддерживает
источник

AC

Alexander Chichigin in WebAssembly — русскоговорящее сообщество
Эти сильно со скрипом. Лучше уж Rust взять.
источник

К

Константин in WebAssembly — русскоговорящее сообщество
c# вообще выкинуть, GO еще выкинуть, но поближе =)
источник

D

Danya in WebAssembly — русскоговорящее сообщество
С++!
источник

でゲソ in WebAssembly — русскоговорящее сообщество
то бишь превращение карирования в функцию от n параметров
источник

M

MaxGraey in WebAssembly — русскоговорящее сообщество
Не только коррирование любые замыкания где свободные переменные можно передать через расширение сигнатуры замыкания. Просто тот пример более наглядный
источник

でゲソ in WebAssembly — русскоговорящее сообщество
а то бишь можно считать, что плюсовые лямбды с их захватом контекста типа
[a] (auto b) {return a + b} тоже могут быть подвержены такой штуке?
источник

でゲソ in WebAssembly — русскоговорящее сообщество
пока модули нормально не взлетят я б за него не голосовал
источник

M

MaxGraey in WebAssembly — русскоговорящее сообщество
Да, такие кейсы довольно легко оптимизируются в LLVM
https://godbolt.org/z/h713eWfa3
источник

D

Danya in WebAssembly — русскоговорящее сообщество
Имхо модули не самая проблемная часть там
Лучше бы сумтипы в язык втащили и рефлексию
источник

D

Danya in WebAssembly — русскоговорящее сообщество
Но это уже оффтоп
источник