Search Unity

It looks like Chrome 51 will have WebAssembly support...

Discussion in 'Web' started by Arowx, Apr 27, 2016.

  1. Arowx

    Arowx

    Joined:
    Nov 12, 2009
    Posts:
    8,194
  2. AFrisby

    AFrisby

    Joined:
    Apr 14, 2010
    Posts:
    223
    Excellent to hear it's coming so quickly.

    I haven't seen much from Unity in terms of schedule of it (so no answers there), but they did just recently release a version of Angry Bots ( https://webassembly.github.io/demo/ ) using WebAssembly, so there must be a experimental version of the editor floating around somewhere.
     
  3. jonas-echterhoff

    jonas-echterhoff

    Unity Technologies

    Joined:
    Aug 18, 2005
    Posts:
    1,666
    Chrome 51 has a development version of WebAssembly behind a flag. However, that is very different from saying "Chrome 51 will have WebAssembly support" - it will take longer for the feature to be mature enough, and in a final specification for it to be enabled by default without a flag.

    But still, this is good news. Firefox has it in nightly builds as well.
     
  4. Arowx

    Arowx

    Joined:
    Nov 12, 2009
    Posts:
    8,194
    Any stats on performance between asm and WebAssembly?

    In theory they should be about the same, although the download speed and parsing time should be faster for WebAssembly, right?
     
  5. jonas-echterhoff

    jonas-echterhoff

    Unity Technologies

    Joined:
    Aug 18, 2005
    Posts:
    1,666
    No stats yet.

    But that theory only holds up for browsers which already had an AOT compilation path for asm.js code (Firefox, Edge), where this will indeed "just" change the distribution format. For Chrome, I expect to see a decent boost in runtime performance, as WebAssembly will run on a new AOT engine, as opposed to a JavaScript JIT.
     
  6. Arowx

    Arowx

    Joined:
    Nov 12, 2009
    Posts:
    8,194
    Are the Multi-Threading, SIMD and Modular/DLL elements of WebAsm still a long way off, or are they progressing well?
     
  7. jonas-echterhoff

    jonas-echterhoff

    Unity Technologies

    Joined:
    Aug 18, 2005
    Posts:
    1,666
    Multi-Threading (SharedArrayBuffers) and SIMD.js are under development simultaneous to WebAssembly, and will ship independently of - but also, unfortunately - initially exclusive to WebAssembly. So, in their initial implementations, these features will only be available from JavaScript, and they will come to WebAssembly later, meaning that there will be a window in time where it is possible to user either SIMD & SharedArrayBuffers or WASM, but not both. Hopefully, this window in time will not be too long. For various technical reasons we are choosing to adapt WASM first, and then the other features, once they are supported in WASM.

    I'm not sure if the initial WASM spec will support dynamic linking (DLLs), but we have no immediate need for that in Unity either.
     
  8. supron

    supron

    Joined:
    Aug 24, 2013
    Posts:
    67
    Correct me if I'm wrong, but looking at the newest Emscripten incoming builds, it looks like you have to only add some compilation params to support multi-threading on low cpp level. It shouldn't break anything in theory. So is there any chance that you will update Emscripten engine to the newest version anytime soon, so we can test some MT stuff by ourselves on nightly firefox? I'm not talking about any changes in Unity or il2cpp, just an Emscripten update. I'm already using a lot of cpp code to extend browsers utility. Considering that game coding is rather long process it could be very beneficial to test some incoming features even if we cant really release it.
     
  9. jonas-echterhoff

    jonas-echterhoff

    Unity Technologies

    Joined:
    Aug 18, 2005
    Posts:
    1,666
    It is not that simple. Yes, emscripten has an option to support Shared Array Buffers to enable multithreading in JavaScript. We have been experimenting with it, and have been able to test builds using it internally (see here for some results: http://blogs.unity3d.com/2015/12/15/updated-webgl-benchmark-results/).

    However, "just turning this on" probably won't help anyone today. Some issues:

    -When we turn this on, we also need to enable threading in our code base, which will make it fail when no threading is available in the browser. So we'd need two builds of Unity WebGL, or one which can dynamically work with or without threading. We kind of have the latter working, but then, on the JavaScript level, we need to patch out all the Shared Array Buffer code at load time, which is not trivial, and increases startup times.

    -Shared Array Buffers won't initially be supported in WebAssembly, so we cannot have both.

    -In it's current implementations, Shared Array Buffers require a separate copy of the code in memory for each thread, which increases memory usage (which is already a problem). So we'd rather want to wait until the functionality becomes available in WebAssembly, where this likely won't be a problem

    -Shared Array Buffers currently allow no way to either pause threads, or to inspect a thread's stack, which is required for managed Garbage Collection. Without this (or some other GC solution), it will not be possible to run user C# code in threads.
     
    tonialatalo likes this.
  10. Genom

    Genom

    Joined:
    Dec 2, 2014
    Posts:
    86
    Hi Jonas, now that .net 4.6 has is available (in the beta, of course, and not yet completely compatible with Webgl, I know) I think me and many more we are wondering when System.Threading will be available for WebGL, I guess by using Shared Array Buffers below.

    Do you have any news about this topic? I cannot wait to have the whole .net 4.6 (more or less..) for WebGL in my hands : )
     
  11. Marco-Trivellato

    Marco-Trivellato

    Unity Technologies

    Joined:
    Jul 9, 2013
    Posts:
    1,654
    The current plan is to add threads support as soon as SAB is available in WebAssembly. However, first we are going to look at enabling internal threads, then expose them to the user (via System.Threading) at a later stage.
     
  12. Genom

    Genom

    Joined:
    Dec 2, 2014
    Posts:
    86
    Great!

    about WebAssembly, are you yet waiting until the browsers have it available by default or is any other thing in the middle?

    Wihout any pressure and in a wide frame, is there any ETA for Webassembly in first place, and for SBA in WebAssembly in a second one? It would be good to know (month, a year, 2 years..) for long term strategic decisions for us developers. Anyway, thanks for your answers and hard work : )
     
    Last edited: Feb 7, 2017
  13. Marco-Trivellato

    Marco-Trivellato

    Unity Technologies

    Joined:
    Jul 9, 2013
    Posts:
    1,654
    You can try WebAssembly today in Unity 5.6 Beta, enable it in PlayerSettings=>PublishingSettings and in the browser via flags:
    • Firefox Nightly: about:config => javascript.options.wasm
    • Chrome Canary: chrome://flags => #enable-webassembly
    Though, consider that wasm support is an experimental feature in 5.6 and that in the current Beta there are a couple of bugs that we are still resolving.

    5.6 is the next release so you won't have to wait too long for that (fingers crossed). For SAB is a bit premature but certainly C# Threads will not be available anytime soon. We will try to keep you posted in the coming months.
     
  14. Genom

    Genom

    Joined:
    Dec 2, 2014
    Posts:
    86
    Thank you Marco, according with WebAssebly Roadmap they'll probably have the final release for summer (just guessing comparing their previous times). Instead, about SBA I was not able to find anything, when or how they want to add it.

    cheers!
     
  15. nsmith1024

    nsmith1024

    Joined:
    Mar 18, 2014
    Posts:
    870
    Is there anyway to have two builds on a website (regular javascript WebGL, and WebAssembly), and somehow depending on the browser capability, load the correct one?
     
  16. kognito1

    kognito1

    Joined:
    Apr 7, 2015
    Posts:
    331
    I believe webassembly can be decoded to asm.js/javascript with javascript (much like Unity will do gzip decompression in javascript if you haven't set up your server correctly). You shouldn't need two versions.
     
    xAvatarchikx likes this.
  17. Marco-Trivellato

    Marco-Trivellato

    Unity Technologies

    Joined:
    Jul 9, 2013
    Posts:
    1,654
    When Wasm support is enabled, Unity will generate both asm.js and wasm code (as separate files). The user will download and run wasm code if supported, otherwise asm.js
     
  18. Marco-Trivellato

    Marco-Trivellato

    Unity Technologies

    Joined:
    Jul 9, 2013
    Posts:
    1,654
    WebAssembly support is in 5.6 beta 11. Feedback is welcome! Please create new forum post threads for specific issues (and/or submit bug reports).
     
    Claytonious and AFrisby like this.
  19. kognito1

    kognito1

    Joined:
    Apr 7, 2015
    Posts:
    331
    I did a very quick test (I want to stress the quick part!) and the results were:

    Chrome (version 58) uses about 150-200mb more memory with webassembly enabled
    Firefox (version 52) uses about 100mb-150mb less memory with webassembly enabled

    Just a couple other random notes:
    -Even though chrome uses more memory, "fps-wise" webassembly does seem quicker
    -Caching (from the Asset Store Package) + WebAssembly = crazy fast load times! :)
    -Stripping physics works!

    Unity 5.6 looking to be a game changer for webgl! :)
     
    Claytonious likes this.
  20. Claytonious

    Claytonious

    Joined:
    Feb 16, 2009
    Posts:
    904
    @kognito1 - what "caching (from the Asset Store Package)" are you referring to?
     
  21. kognito1

    kognito1

    Joined:
    Apr 7, 2015
    Posts:
    331
    Asset bundle caching: https://www.assetstore.unity3d.com/en/#!/content/71538. The superior way (atm at least) for caching asset bundles on WebGL.

    And as a general update to this thread: chrome now uses less memory (and in general behaves like firefox) for web assembly. I can't recall the split for edge and safari (enabled through experimental options), but I don't recall (major?) regressions compared to the javascript (asm.js) version.
     
  22. Claytonious

    Claytonious

    Joined:
    Feb 16, 2009
    Posts:
    904
    Chrome WebAssembly compile time still seems to be more than 3x slower than Firefox, though, as of 60.0.3112.113 on a Mac. We have a large game that starts up in only ~7 seconds on Firefox - more than 25 on Chrome, and almost all of that difference appears to be WebAssembly compilation.
     
  23. Marco-Trivellato

    Marco-Trivellato

    Unity Technologies

    Joined:
    Jul 9, 2013
    Posts:
    1,654
    Could you please measure load times with Chrome 63 (Canary build) and Firefox Nightly 55? I would expect a smaller gap between Chrome and Firefox.
     
  24. Claytonious

    Claytonious

    Joined:
    Feb 16, 2009
    Posts:
    904
    Sure, just tried it and it's not much different. Chrome Canary 63 is *slightly* better but nowhere close to as fast as Firefox. This is all localhost, and Firefox still gets to our first scene in 6 to 7 seconds, whereas Canary still takes between 20 and 22 seconds.
     
  25. Claytonious

    Claytonious

    Joined:
    Feb 16, 2009
    Posts:
    904
    This was from 5.6.2p4, BTW. Would it be worthwhile for me benchmark again with a build from 2017.2 beta?