P5.js: Performance boosts w/ WASM ?

[a-y-u-s-h]

Nature of issue?

• [ ] Found a bug
• [ ] Existing feature enhancement
• [x] New feature request

Most appropriate sub-area of p5.js?

• [ ] Color
• [ ] Core
• [ ] Data
• [ ] Events
• [ ] Image
• [ ] IO
• [ ] Math
• [ ] Typography
• [ ] Utilities
• [ ] WebGL
• [x] Other (specify if possible)

New feature details:

I'm not sure if what I'm saying is possible at all. I've seen some Web Assembly implementations of canvas sketches like this one. And they have really impressive performance (near native C++ equivalent) on the web!

And this talk by Lin Clark at JSConf 17 convinced me that it's very much possible to boost performance of existing canvas or webgl libraries while keeping the interface/api same for users. Won't it be really good to introduce some wasm implementations of existing functions in p5? Web assembly modules are faster to load as well.

I also want to begin contributing to p5 and participate for GSoC 18 if possible. So any link which demonstrates how to start contributing here would be really helpful! Thanks in advance!

[Spongman]

yes indeed! Web Assembly is certainly very interested stuff. I don't think there's any reason you couldn't replace the render.js portion of that example with a version that uses p5.js to handle the management of the webgl shader. i think a good first step might be porting that sample to p5 and finding out what needs to be fixed, and that might point to places where functionality can be added to p5 to make using it with WASM simpler.

you may want to start with PR #2349, as that already fixes some stuff wrt. using custom shaders.

[a-y-u-s-h]

Thanks! :)

[stalgiag]

Great advice @Spongman! I just also want to point out that figuring out ways that WASM can help performance on p5 is an interesting project and definitely something to consider with a more long term endeavor such as Google Summer of Code but that said, it might be a good idea to start with smaller changes and fixes to become accustomed to contributing to the library. I would start by reading the development wiki. After doing that, it might be a good idea to take on an issue that is labeled good first issue. Tackling smaller problems like this is a good way to get accustomed to the library and get a feel for how contribution works.

[trosel]

Would it make sense to rewrite processing heavy portions in web assembly?

For example, if you have one portion of your p5js app written in web assembly, would it be quick enough to call that one function many many times, passing inputs and outputs to and from it?

The entire thing would almost have to be a wasm app for true efficiency, right?

Update: Here's an example of sharing a buffer between Rust (wasm) and Javascript https://www.hellorust.com/demos/canvas/index.html

[JithinKS97]

This seems to be really exciting...I've been thinking about contributing to p5.js since very [email protected] you started the work?

[a-y-u-s-h]

@WildYorkies that's interesting. Even though I know and like Rust and C++, if I were to experiment with this idea : I would pick Typescript. There may be some micro trade-offs in performance, but a pro of using typescript is that a lot of enthusiastic contributors won't have to learn entirely new syntax just to get access to web assembly. Later if someone finds out that there's something that needs us to squeeze out every last bit of performance : one can always use toolchains for C++ and Rust and use modules generated by them.

There are tools such as AssemblyScript which have been under heavy development for quite some time to provide us JS like comfort and C like performance on the web. Check out these cool demos written in TS and converted to WASM using AssemblyScript: Conway's Game of Life, Mandelbrot Set, N-body System. These make me happy.

@JithinKS97 No, I haven't. Life took a different path some time after I posted this issue.Though there may be somebody else who may already have started. Frequent contributers may have an idea.

[trosel]

@a-y-u-s-h I bet that 96% of p5.js users are not familiar with server-side javascript. Today they are happily including the p5 script and simply rendering their html in the browser.

Introducing Typescript requires explaining a whoooole lot about the current javascript ecosystem. I really don't like the cargo cult that web programming requires today :/

[a-y-u-s-h]

@WildYorkies Not sure about that but I believe Typescript would make it easier for people to participate than Rust would because it's very close to home for JS developers. It's close to Java as well with some new concepts, so there's that.

It's not like we really _require_ the cargo system : we can write code in proper C, C++ or Go as well - they'll all produce essentially the same wasm module - I think typescript too. C++ has this emscripten toolchain and people have tried and internet-ified their OpenFrameworks projects too. Besides those TS to WASM demos perform decent in my opinion. But again, technology stack will depend on the developer who'll be making this a reality. I'm in middle of a full time internship so it's going to take me some time to experiment with this.

[lmccart]

I'm going to close this because there hasn't been much energy around it in a while and it seems a departure from our current direction.