WebAssembly - native speed for the web

Discussion and feedback on Construct 2

Post » Thu Jul 07, 2016 7:02 pm

Let's keep this thread about webAssembly itself - the native export discussion is another topic that's been discussed elsewhere.

What is webAssembly?

An oversimplified explanation is it's a new technology for the web that loads faster and claims it'll run at native speed.

In addition, unlike other such attempts in the past, this one is being worked on by Apple, Google, Microsoft and Mozilla so everyone's actually going to support it.

Though there's still a lot of work to be done, it's not all that far away, either - experimental support is already beginning to appear in browsers.

Ashley has expressed interest in possibly rewriting the event system to use it if we want it.

@Ashley - I'm very happy to hear that you're open to the idea of rewriting at least parts of the engine in webAssembly - I had been considering making a thread to ask about it earlier until you mentioned it in your blog. I do a lot of intensive stuff with events, so if construct 3 has that it will make me very interested to upgrade.

I suspect the reason more people haven't expressed interest in it yet is because it's so new they don't know about it since the implementation hasn't even been completed yet.

I have a few questions about it, though:

- You said it brings improvements to memory management - does that mean we as users would get more control of loading and unloading things like textures from memory?
- When you talked about the possibility of rewriting the event system in it, how far would that extend? Would that cover behaviors as well? Would people be able to make third-party extensions using it as long as they had the tools?
- In particular I'm interested in collisions - I have a lot of scenarios where using collision cells is either difficult, unfeasible or complicates my code, so any speedup there would be helpful.
- Rendering - I acknowledge my ignorance on the subject, but since webGL is written in javascript, it seems plausible that it could help with the performance impact of the draw calls or other such elements of preparing the scene for rendering, even if it wouldn't speed up rendering itself?
- Physics - because webAssembly needs to be compiled to from another language like C similarly to asm.js, would it be a comparatively simple task to compile the physics for webAssembly to get the 20-30% speed boost (if, of course, it's really that much faster)?

Who else wants native speed events? :)
Moderator
B
95
S
34
G
33
Posts: 3,007
Reputation: 27,876

Post » Thu Jul 07, 2016 7:15 pm

A few other questions:
"- When you talked about the possibility of rewriting the event system in it, how far would that extend? Would that cover behaviors as well? Would people be able to make third-party extensions using it as long as they had the tools?"

Is it a separate exporter that requires rewriting plugs?

Would it require any third party wrappers?
What platforms would be available?
Image ImageImage
B
169
S
50
G
174
Posts: 8,331
Reputation: 110,806

Post » Thu Jul 07, 2016 7:45 pm

I think it would help illustrate the issue if people can have some examples of events that run slow with the current implementation. I've noticed at times where some things might be slow, like with many loops- is this the sort of thing that would be improved? What exactly about the event system is slow if it were compared to what webAssembly would do? Or is it just everything in general?
B
45
S
21
G
65
Posts: 1,118
Reputation: 38,227

Post » Thu Jul 07, 2016 9:19 pm

I think by "memory management" it means faster things than garbage collection can be used. Aka less small pauses.

Actually, it's very similar to asm.js and probably has similar performance characteristics. The main draw over asm.js is the code will be more compact in size, but I'd have to see an example to see by what margin.

If parts of the engine were re-written to use it I'd imagine it would mainly be the bottleneck areas. I doubt the interface used would change as that would break existing plugins. Also it's just a feature available to the browser so plugins/behaviors can even be made to use it now if the browser supports it. The same can be said for asm.js currently.
B
92
S
32
G
110
Posts: 5,295
Reputation: 71,501

Post » Fri Jul 08, 2016 10:37 am

Arima wrote: - You said it brings improvements to memory management - does that mean we as users would get more control of loading and unloading things like textures from memory?

Mainly I was comparing it to a major limitation of asm.js, where by default you get a fixed amount of memory, and that's it. This is a pretty major shortcoming for a game engine since nobody can easily tell how much memory they'll need in advance, or if it might still exceed that in rare cases. Also you can't just set it really high, because it always uses that much memory, even if it is only using less. I think you can enable memory growing in asm.js, but last I looked it had a bunch of caveats and reduced performance. AFAIK WebAssembly aims to solve this problem properly, where memory can automatically grow (and possibly shrink) to match the requirement and not impact performance.

Anything that can be done with textures can already be done with WebGL, it's not really related.



- When you talked about the possibility of rewriting the event system in it, how far would that extend? Would that cover behaviors as well? Would people be able to make third-party extensions using it as long as they had the tools?

I don't know really, this whole project is still just an idea. I would lean towards no, all plugins and behaviors would be written in normal JS, because it's so much easier (JS is easier than languages like C++ and the development process is far simpler without needing ahead-of-time compilation, especially if you get in to debugging). However there is still uncertainty about what the WebAssembly <-> JS transition performance overhead is, which could kill that. Individual plugins and behaviors could still use asm.js/WebAssembly if it benefits them, like Physics already does. Another open question about WebAssembly is if it can elegantly handle multiple WebAssembly programs in the same page.

- In particular I'm interested in collisions - I have a lot of scenarios where using collision cells is either difficult, unfeasible or complicates my code, so any speedup there would be helpful.

Collision cells are an automatic internal engine feature and it doesn't need you to do anything different, so what exactly is difficult/infeasible/complicated about that?

- Rendering - I acknowledge my ignorance on the subject, but since webGL is written in javascript, it seems plausible that it could help with the performance impact of the draw calls or other such elements of preparing the scene for rendering, even if it wouldn't speed up rendering itself?

Yes, it could speed up draw calls, but I don't think it's worth it - usually draw calls are not a bottleneck, in cases they are there are still ways we can optimise it in normal JS, and draw calls are issued by plugins which are typically written in normal JS.

- Physics - because webAssembly needs to be compiled to from another language like C similarly to asm.js, would it be a comparatively simple task to compile the physics for webAssembly to get the 20-30% speed boost (if, of course, it's really that much faster)?

Right now nothing involving asm.js/WebAssembly seems straightforward, because they are not really mature technologies yet so it's easy to run in to roadblocks. So probably not. But I doubt there would be a huge improvement anyway, asm.js is pretty good as it is.


In short, this is still just an idea, there are a lot of details and uncertainties to be figured out, particularly around third-party plugins.
Scirra Founder
B
398
S
236
G
88
Posts: 24,441
Reputation: 194,671

Post » Sat Jul 09, 2016 1:46 am

newt wrote:Is it a separate exporter that requires rewriting plugs?

Would it require any third party wrappers?
What platforms would be available?


As I understand it, it's an addition to the web spec so exporting wouldn't change. If I recall correctly, I think it is backwards compatible even with browsers that don't support it yet by using javascript instead.


Prominent wrote:What exactly about the event system is slow if it were compared to what webAssembly would do? Or is it just everything in general?


I think most things written in it would just be faster, as it's inherently faster than javascript.


R0J0hound wrote:Actually, it's very similar to asm.js and probably has similar performance characteristics. The main draw over asm.js is the code will be more compact in size, but I'd have to see an example to see by what margin.


That's a bit frustrating and feels somewhat misleading of them to call it native performance if that's true, but regardless getting the event system up to asm.js levels of speed would still be fantastic, even if it's not truly native speed.


Ashley wrote:Mainly I was comparing it to a major limitation of asm.js, where by default you get a fixed amount of memory, and that's it.


Wow, that's... a bit odd. Glad to hear webAssembly fixes that.

Collision cells are an automatic internal engine feature and it doesn't need you to do anything different, so what exactly is difficult/infeasible/complicated about that?


I thought they required collision checks to happen before any instance filtering occurred in the event sheet? Most of the times I need to check collisions it's after filtering has occurred. Doing it the other way around is basically backwards from my entire code tree because I keep needing to check collisions in different ways and different times due to the complex behaviors I'm trying to make. I do my best to limit the number of checks via the filtering, but when doing enough loops or such, it always helps to have more speed that can free up the cpu for tasks elsewhere.

Also, after seeing your tweet about a quarter million sprites at 30 fps on a GTX 1070, any concerns I had about draw calls have been alleviated. XD

Still, even if it is just the event system, I could definitely make use of it.
Moderator
B
95
S
34
G
33
Posts: 3,007
Reputation: 27,876

Post » Sat Jul 09, 2016 3:39 pm

Arima wrote:I thought they required collision checks to happen before any instance filtering occurred in the event sheet? Most of the times I need to check collisions it's after filtering has occurred.

Oh right, yes, that was a limitation. But then in theory your filtering has already reduced the list of candidates that need to be tested for collisions. Or are you picking large numbers of instances first? That could effectively disable the optimisation, but if it's really bad it should be possible to rearrange events to do the collision-cell enabled check first.
Scirra Founder
B
398
S
236
G
88
Posts: 24,441
Reputation: 194,671

Post » Sat Jul 09, 2016 5:59 pm

That's a bit frustrating and feels somewhat misleading of them to call it native performance if that's true, but regardless getting the event system up to asm.js levels of speed would still be fantastic, even if it's not truly native speed.

Not really, like asm.js it's setup in a way that can be more directly translated to machine language by the javascript engine. So that's where the native performance statement comes from. Who knows, it may allow for more efficient machine language to be generated. But I don't imagine significant speed improvements in most cases, because generating machine code is nothing new for a javascript engine.
B
92
S
32
G
110
Posts: 5,295
Reputation: 71,501

Post » Sun Jul 10, 2016 6:54 am

Ashley wrote:Oh right, yes, that was a limitation. But then in theory your filtering has already reduced the list of candidates that need to be tested for collisions. Or are you picking large numbers of instances first? That could effectively disable the optimisation, but if it's really bad it should be possible to rearrange events to do the collision-cell enabled check first.


Possible, yes, but it can be messy and runs backwards to all the other logic as I mentioned before. The point really is just that any cpu cycles that can be saved frees them up for other use elsewhere, and if it wouldn't be that much work - and I acknowledge that I have no idea of how much work it would actually be - why not?

R0J0hound wrote:Not really, like asm.js it's setup in a way that can be more directly translated to machine language by the javascript engine. So that's where the native performance statement comes from. Who knows, it may allow for more efficient machine language to be generated. But I don't imagine significant speed improvements in most cases, because generating machine code is nothing new for a javascript engine.


I guess we'll just have to wait to find out. :)
Moderator
B
95
S
34
G
33
Posts: 3,007
Reputation: 27,876

Post » Tue Jul 12, 2016 10:18 am

I'm glad to see this technology develop and even better if C3 will support it at some point. We'll see how it turns out. How long can we expect to wait for this technology to mature? 2-3 years?
B
135
S
33
G
17
Posts: 1,557
Reputation: 20,717

Next

Return to Construct 2 General

Who is online

Users browsing this forum: No registered users and 10 guests