Comments (16)
Consider AssemblyScript as a target. It is TypeScript compiled to WebAssembly https://www.assemblyscript.org/
from scratch-vm.
Another possible thing to consiter is c, c++, or rust because they are popular with webassembly and receive the most attention when it comes to develoupment, leading to webassembly enhancement and better documention.
from scratch-vm.
In the context of this project we would have to generate WASM bytecode dynamically at runtime. Adding a dependency on rustc at runtime is not viable for us
from scratch-vm.
That might take a long time to calculate especally for large projects that turbowarp is so famous for.
from scratch-vm.
I had a great idea
from scratch-vm.
What if you prepared pre-compiled webassembly functions for each block?
from scratch-vm.
And then simply embeded using webassembly API
from scratch-vm.
Compiling to WASM is entirely theoretical at this point and it's not clear whether it would actually be any faster because WASM <-> JavaScript interop is not free, and WebAssembly is not a magic cure to all performance issues. Browser's really don't want websites to syncronously compile WASM, which is a real problem for an app like TurboWarp that dynamically generates code at runtime and has to execute it immediately or else projects misbehave.
The JavaScript that TurboWarp generates is still significantly slower than the same code written by a human. We have a ways to go before WASM will be necessary to go faster.
from scratch-vm.
That is what hand-optimization is for according to the article you linked. Satifying the user takes hours and hours of hard, tough work. Because users don't know that in real life coding is a lot harder than snapping together blocks.
from scratch-vm.
The most easy solution is creating turbowarp's own Bytecode, and then running it inside a VM/Engine implemented in WebAssembly (C/C++)
it will be faster than compiling webassembly modules dinamically or converting to JS
Also execution should be faster than the current "compiled" JS code
For those who don't know, WebAssembly modules are not interpreted, they are compiled AOT to machine code before execution.
So a TurboWarp VM/Engine should be a pratical ideia
I am currently working on a prototype...
from scratch-vm.
A bytecode interpreter in WASM will not necessarily be faster than letting the browser's JavaScript JIT figure out how to optimize our scripts
from scratch-vm.
Because javascript runtimes arent really standard and their behaviour change depending on the runtimr and the execution context.
There is so much entropy
JS is a dynamic and object oriented language. in a custom bytecode we can have guarantees that we cannot have in JS code.
WASM is very efficient, near native and sandboxed.
As a personal opinion, i think the actual Scratch->JS compiler is still very inefficient
from scratch-vm.
Everything you said is correct but it doesn't prove that a bytecode interpreter in WASM will outperform our JavaScript as interpreting bytecode has a very non-insignificant performance overhead.
I am curious how well it performs. Do let me know when you having a working prototype to benchmark.
from scratch-vm.
A bytecode interpreter in WASM will not necessarily be faster than letting the browser's JavaScript JIT figure out how to optimize our scripts
It will be faster if well designed
Compiling WASM modules at runtime is not pratical because of the specifications of the binary format. The encoding of WASM modules are heavy and inneficient for code generation.
The only alternative is creating your own VM inside WASM
from scratch-vm.
Everything you said is correct but it doesn't prove that a bytecode interpreter in WASM will outperform our JavaScript as interpreting bytecode has a very non-insignificant performance overhead.
I am curious how well it performs. Do let me know when you having a working prototype to benchmark.
Sure!
from scratch-vm.
Any updates on this?
from scratch-vm.
Related Issues (20)
- about util.ioQuery HOT 3
- pen optimisation HOT 3
- Upload To Scratch HOT 4
- Weird Blocks HOT 3
- Custom Reporters - I dunno if this is my fault, but this makes no sense HOT 3
- Broadcasts get compiled dynamically HOT 8
- Suggestion: Compile broadcasts once per project start HOT 4
- Bug: `util.thread.peekStack()` is not working properly when there are nested reporters
- Compiler's waitPromise soft-lock if promise handlers executed immediately HOT 2
- New Argument: Block HOT 4
- vm crash HOT 2
- Global blockUtility HOT 4
- Native sb3fix integration
- Custom reporters can hang browser in certain situations. HOT 2
- Compiler Support HOT 3
- Request: Allow unlimited cloud variables on unpackaged projects. HOT 4
- Glide-to blocks don't pause when a project is paused
- Optimize namesOfCostumesAndSounds
- Procedure variant by argument types
- Optimize getSpriteTargetByName HOT 2
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from scratch-vm.