куска?
WASM (module (func $ga (result i32) i32.const 3) (func (export "xorByThree") (param $lhs i32) (result i32) local.get $lhs call $ga i32.xor)) vanila export const murych_xorCons = () => 3; export const murych_xorer = ( i ) => i ^ murych_xorCons(); код let iter = 10000001; let sumator = 1; while ( iter-- ) { //sumator += xorByThree( iter ); sumator += murych_xorer( iter ); }
Очеивдно что V8 правильно оптимизировал JS код и очень плохо код WASM модуля. Очевидно что код WASM модуля можно оптимизировать схожим образом. Только это не отменяет проблемы. Которая заключается в том, что в лучшем случае WASM не сделает мой код быстрее для числодробилки. Потому что быстрее банального xor вставленного инлоайном ничего быть не может.
Понятно. Т.е. тот чудовищный блок как я ипредпологал относиться к cross-boundry между js и wasm. Никто в принципе и не спорит, что это пока очень дорого. Что касается вызова `call $ga`. В AS он бы заинлайнился если бы вы скомпилировали с флагом -O3. И по факту было бы так: (func (export "xorByThree") (param $lhs i32) (result i32) local.get $lhs i32.const 3 i32.xor))
Это сворешенно неважно. Важно то, что сам по себе WASM в его текущем состоянии, не может дать НИЧЕГО для решение ЛЮБЫХ JS задач. За исключением удобного апи для написания кроскопиляторов из разных языков которые априори будут рабооать хзуже чем аналогичная нейтив реализация
> Это сворешенно неважно. Важно то, что сам по себе WASM в его текущем состоянии, не может дать НИЧЕГО для решение ЛЮБЫХ JS задач. Это не правда. Он прекрасно справляется с числодробильными задачами намного лучше js. По одной простой причине - LLVM и Binaryen могут позволить намного более дорогой анализ для оптимизаций чем v8 (у которого есть бюджет на инстанцирование)
Покажи мне пример любой числодробилки где это так. И я завтра тебе дам код лучше на ваниле
Обсуждают сегодня