[AssemblyScript] gl-matrix port to WebAssembly

[StEvUgnIn]

Hi everyone,
I am working since yesterday on the port of gl-matrix to WebAssembly.

Define objectives are:

• compatibility with TypeScript preserved (using std/assemblyscript/portable definitions)
• minimal changes from the original code
• encapsulation and compatibility with projects using the JavaScript implementation

I will publish as soon as I have a solid draft to present :) But the code of gl-matrix is concise, not too shaby for JavaScript code, easily portable to TS/AS environments.

[StEvUgnIn]

Don't hesitate to share your feedback on my ongoing work here

[stefnotch]

Out of curiosity, how will garbage collection be handled?

[StEvUgnIn]

Garbage collection makes more sense in bigger projects. Memory is handled manually on Webassembly by the programmer. You have a ton of projects porting C/C++, JavaScript, Rust to Webassembly.

Webassembly is designed to work alongside JavaScript. That means that the binary needs glue code to be able to run in an application (client or server).

After research, the AssemblyScript team is bringing some experimental support for GC. Here is a link https://www.assemblyscript.org/runtime.html

[trusktr]

AssemblyScript has automatic GC currently.

• if an AssemblyScript Wasm module is no longer referenced by JS, the it is collected (this is regular stuff, not assemblyscript-specific).
• If an AssemblyScript Wasm module is still held by JS, then every time JS invokes the module, AssemblyScript does it's own GC (custom implementation, not the upcoming Wasm GC) on each call. The developer, by default, does not need to worry about it.

[StEvUgnIn]

Thanks for your explanation @trusktr 🙂

[StEvUgnIn]

https://travis-ci.org/github/toji/gl-matrix/builds/764734352 😎

[StEvUgnIn]

@stefnotch @trusktr @pyrotechnick @alexmax
#421 (review)

[psnet]

I tested on another project same idea for calculations on WASM and due to the bridge JS - WASM where non-scalar values are copied between memory of JS and WASM so it is actually slower than done in pure JS.

So this entire idea is not efficient

[PaperPrototype]

C# is inherently inefficient, same with JS, and same with Python, but developers like it, so now Python runs in GPUs and C# powers a lot of web backends (and games)... and even runs in the browser (https://codetoy.io/3f6632eb-b79c-4c44-aa93-8ea44dd1ffdb, takes a very long time to load) so... GIMME GL MATRIX IN AssemblyScript cus I WANT IT

[stefnotch]

@PaperPrototype The AssemblyScript version of gl-matrix wouldn't really offer any advantages, I believe. As in, calling it from another language like JavaScript incurs enough overhead to make it useless.

So my genuine recommendations are

• Write the code in simple enough JavaScript and stay on the happy path of JavaScript engines. Then you get decent performance with small bundle sizes.
• Or choose a language that actually has a good WebAssembly compilation story. Like Rust or C. Those are systems programming languages which do not have a runtime nor a garbage collector. Which saves a lot of space when compiling to WASM.

(P.S. Feel free to dm me on Discord stefnotch if you have any questions or would find some expertise helpful. I'm happy to answer anything.)

[psnet]

@PaperPrototype

C# is inherently inefficient, same with JS, and same with Python

C# is bit faster than JS, JS far away faster than python, python is slowest from all modern languages. Dont do comparison of them directly.

C# even runs in the browser (https://codetoy.io/3f6632eb-b79c-4c44-aa93-8ea44dd1ffdb, takes a very long time to load)

Simple raycasting technique (a like Doom games series) takes too long to load? Don't you find a problem with this statement?

so... GIMME GL MATRIX IN AssemblyScript cus I WANT IT

Do it yourself, compare results carefully, measure timing of data transfer JS - WASM - JS, investigate how it will perform if entire codebase will be mostly on JS vs on WASM, will be there advantages of using WASM?

I tested all this cases and can say IPC is very heavy, if mostly entire codebase is on JS and rare calls JS - WASM - JS are inefficient.

[PaperPrototype]

Well that certainly sparked a conversation! :P

Do it yourself, compare results carefully, measure timing of data transfer JS - WASM - JS, investigate how it will perform if entire codebase will be mostly on JS vs on WASM, will be there advantages of using WASM?

@psnet I'm considering porting it to AssemblyScript (non-portable) and try using it in my Codetoy projects (though that'll probably have to wait until codetoy get's multi-file support). Also I'm not as interested in the performance as much as just the fact it I want to write AssemblyScript.

The AssemblyScript version of gl-matrix wouldn't really offer any advantages, I believe. As in, calling it from another language like JavaScript incurs enough overhead to make it useless.

@stefnotch I was thinking mostly doing everything in the AssemblyScript side by providing WebGL bindings directly to AssemblyScript, though there would probably be a tradeoff since it is still WASM -> JS for WebGL so not sure how the API would look (or perform). Also disclaimer I've never used WebGL before so this is just my own ideas, I'll have to sit down and learn WebGL before I make any actually useful insights.

[stefnotch]

@PaperPrototype There is an AssemblyScript port over here that you can build on. There's also an older C port for WASM usage.

If you don't have any prior WebGL (or WebGPU) experience, then my recommendation is to first start with the tried an tested Typescript/Javascript path. And only then play with the bindings part. The tutorial series https://webglfundamentals.org/ , https://webgl2fundamentals.org/ , https://webgpufundamentals.org/ is an excellent learning resource.

The WASM <-> JS overhead for just the WebGL API should be pretty minimal. It's a somewhat small number of calls per frame. It should be dwarfed by everything else that the application does.