TE
科技回声
首页24小时热榜最新最佳问答展示工作
GitHubTwitter
首页

科技回声

基于 Next.js 构建的科技新闻平台,提供全球科技新闻和讨论内容。

GitHubTwitter

首页

首页最新最佳问答展示工作

资源链接

HackerNews API原版 HackerNewsNext.js

© 2025 科技回声. 版权所有。

Calls between JavaScript and WebAssembly are finally fast

907 点作者 lainon超过 6 年前

21 条评论

bluejekyll超过 6 年前
Very exciting! And really amazing work. It appears that WASM, at least in Firefox, is now going to be on par with JS in terms of performance when calling other JS facilities. Those comparison times are quite impressive.<p>I think the thing I found most exciting is at the end: “WebAssembly is getting more flexible types very soon. Experimental support for the current proposal is already landed in Firefox Nightly.” Implication being that WASM will have native access to the DOM.<p>I think at that point WASM could be used to fully work with the DOM with no negative costs, right?
评论 #18169021 未加载
评论 #18170523 未加载
markdog12超过 6 年前
Another interesting flag I found was javascript.options.wasm_cranelift, which enables a WASM code generator written in Rust: <a href="https:&#x2F;&#x2F;github.com&#x2F;CraneStation&#x2F;cranelift" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;CraneStation&#x2F;cranelift</a>
评论 #18174316 未加载
lemmyg超过 6 年前
Exposing Web APIs (e.g. DOM) to WASM and projecting them into native languages seems like it overlaps a lot with defining actual native API projections that would be shared between browser implementations.<p>It doesn&#x27;t read like this is an explicit goal of the project, but are we going to get this by accident? Being able to use the same X code (where X is your favourite statically-compilable language) to generate both a WASM version that runs on the web and a statically-compiled version that links to the Y browser source (where Y can be whichever browser works for you because they all support the same native API) would be awesome.
mmastrac超过 6 年前
Kudos to the author of this post - it takes a lot of skill to explain complex concepts like this, let alone in plain enough english that someone not skilled in the art could follow along.<p>WebAssembly is one of those technologies where we haven&#x27;t seen the true extent of its capabilities yet. This is an exciting time to be working in browsers.
评论 #18170008 未加载
评论 #18169174 未加载
评论 #18169272 未加载
评论 #18168878 未加载
评论 #18168943 未加载
steipete超过 6 年前
You can see the difference in the WebAssembly Benchmark: <a href="http:&#x2F;&#x2F;iswebassemblyfastyet.com" rel="nofollow">http:&#x2F;&#x2F;iswebassemblyfastyet.com</a>
评论 #18171152 未加载
评论 #18171609 未加载
评论 #18173430 未加载
评论 #18171544 未加载
Ooveex2C超过 6 年前
Do wasm -&gt; builtin calls, e.g. DOM methods still call the JS code if JS code has been monkey-patched?<p>E.g. if userscript replaces the built-in window.fetch() API to modify page behavior will wasm also be intercepted?
评论 #18169362 未加载
finchisko超过 6 年前
Lin is awesome, but reading this nice article I have one noob question.<p>&gt; We took the code that C++ was running — the entry stub — and made it directly callable from JIT code. When the engine goes from JavaScript to WebAssembly, the entry stub un-boxes the values and places them in the right place. With this, we got rid of the C++ trampolining.<p>So they replaced unboxing C++ trampoline with entry stub. But isn&#x27;t that stub technically written in C++ too?
评论 #18170906 未加载
评论 #18169903 未加载
jokoon超过 6 年前
Function calls from WASM to JS don&#x27;t seem to have improved so much.<p>I don&#x27;t know what I want more, DOM calls from WASM, or C++ modules. A web without javascript would be welcome.
评论 #18169011 未加载
评论 #18169364 未加载
评论 #18168830 未加载
评论 #18169538 未加载
benjaminjackman超过 6 年前
While searching for more information on a configuration value mentioned in the article (javascript.options.wasm_gc) I came across another article on the topic, which I also found interesting because it&#x27;s a bit more technical:<p><a href="https:&#x2F;&#x2F;blog.benj.me&#x2F;2018&#x2F;07&#x2F;04&#x2F;mozilla-2018-faster-calls-and-anyref&#x2F;" rel="nofollow">https:&#x2F;&#x2F;blog.benj.me&#x2F;2018&#x2F;07&#x2F;04&#x2F;mozilla-2018-faster-calls-an...</a>
writepub超过 6 年前
I hope the chrome team is looking at this too, with 65+% market share, it&#x27;ll be real impactful when chrome makes similar optimizations.
huang47超过 6 年前
Lin is amazing. I do enjoy reading her posts and learn a lot from them.
nikeee超过 6 年前
Did anyone re-implement the basic React API surface, using Wasm as a backend for the Virtual DOM? To me, it sounds like this would be an interesting project.
评论 #18172614 未加载
twoodfin超过 6 年前
I’m a little surprised that making cross-language inlining trivial wasn’t (apparently) a design goal of the original WASM spec.<p>(Maybe it’s functionally easy but getting the heuristics right is hard? Curious what the primary obstacles are for Mozilla or others.)
评论 #18171659 未加载
评论 #18174921 未加载
DonHopkins超过 6 年前
Firefox loads and runs Unity3D WebGL apps MUCH faster than Chrome.<p>The point of UnityJS is to tightly and efficiently integrate Unity3D and JavaScript, so it does a lot of JavaScript &lt;=&gt; C# calls, and I&#x27;m looking forward to it getting even faster!<p><a href="https:&#x2F;&#x2F;github.com&#x2F;SimHacker&#x2F;UnityJS" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;SimHacker&#x2F;UnityJS</a><p>You can pass delegates to C# functions that are directly callable into JavaScript using some magic PInvoke attributes and the Unity Runtime.dynCall function.<p>Declare a delegate that describes the signature of your C# function you want to call from JavaScript:<p><a href="https:&#x2F;&#x2F;github.com&#x2F;SimHacker&#x2F;UnityJS&#x2F;blob&#x2F;master&#x2F;UnityJS&#x2F;Assets&#x2F;Libraries&#x2F;UnityJS&#x2F;Scripts&#x2F;BridgeTransportWebGL.cs#L35" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;SimHacker&#x2F;UnityJS&#x2F;blob&#x2F;master&#x2F;UnityJS&#x2F;Ass...</a><p><pre><code> public delegate int AllocateTextureDelegate(int width, int height); </code></pre> Then declare a C# static method with the MonoPInvokeCallback attribute, to implement you C# function:<p><a href="https:&#x2F;&#x2F;github.com&#x2F;SimHacker&#x2F;UnityJS&#x2F;blob&#x2F;master&#x2F;UnityJS&#x2F;Assets&#x2F;Libraries&#x2F;UnityJS&#x2F;Scripts&#x2F;BridgeTransportWebGL.cs#L82" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;SimHacker&#x2F;UnityJS&#x2F;blob&#x2F;master&#x2F;UnityJS&#x2F;Ass...</a><p><pre><code> [MonoPInvokeCallback(typeof(AllocateTextureDelegate))] public static int AllocateTexture(int width, int height) { ... } </code></pre> Then pass those specially marked delegates to JavaScript and stash them in JS variables when you initialize (it doesn&#x27;t work unless you use the magic MonoPInvokeCallback attribute):<p><a href="https:&#x2F;&#x2F;github.com&#x2F;SimHacker&#x2F;UnityJS&#x2F;blob&#x2F;master&#x2F;UnityJS&#x2F;Assets&#x2F;Libraries&#x2F;UnityJS&#x2F;Scripts&#x2F;BridgeTransportWebGL.cs#L48" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;SimHacker&#x2F;UnityJS&#x2F;blob&#x2F;master&#x2F;UnityJS&#x2F;Ass...</a><p><pre><code> [DllImport(PLUGIN_DLL)] public static extern void _UnityJS_HandleAwake(AllocateTextureDelegate allocateTextureCallback, FreeTextureDelegate freeTextureCallback, LockTextureDelegate lockTextureCallback, UnlockTextureDelegate unlockTextureCallback); </code></pre> <a href="https:&#x2F;&#x2F;github.com&#x2F;SimHacker&#x2F;UnityJS&#x2F;blob&#x2F;master&#x2F;UnityJS&#x2F;Assets&#x2F;Libraries&#x2F;UnityJS&#x2F;Scripts&#x2F;BridgeTransportWebGL.cs#L175" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;SimHacker&#x2F;UnityJS&#x2F;blob&#x2F;master&#x2F;UnityJS&#x2F;Ass...</a><p><pre><code> public override void HandleAwake() { &#x2F;&#x2F;Debug.Log(&quot;BridgeTransportWebGL: HandleAwake: this: &quot; + this + &quot; bridge: &quot; + bridge); _UnityJS_HandleAwake( AllocateTexture, FreeTexture, LockTexture, UnlockTexture); } </code></pre> In the awake function on the JavaScript side of your Unity WebGL extension (a .jslib file), wrap the C# delegate in a JavaScript thunk that calls into it via Runtime.dynCall:<p><a href="https:&#x2F;&#x2F;github.com&#x2F;SimHacker&#x2F;UnityJS&#x2F;blob&#x2F;master&#x2F;UnityJS&#x2F;Assets&#x2F;Libraries&#x2F;UnityJS&#x2F;Plugins&#x2F;WebGL&#x2F;UnityJS.jslib#L11" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;SimHacker&#x2F;UnityJS&#x2F;blob&#x2F;master&#x2F;UnityJS&#x2F;Ass...</a><p><pre><code> &#x2F;&#x2F; Called by Unity when awakened. _UnityJS_HandleAwake: function _UnityJS_HandleAwake(allocateTextureCallback, freeTextureCallback, lockTextureCallback, unlockTextureCallback) { [...] function _UnityJS_AllocateTexture(width, height) { &#x2F;&#x2F;console.log(&quot;UnityJS.jslib: _UnityJS_AllocateTexture: width: &quot; + width + &quot; height: &quot; + height + &quot; allocateTextureCallback: &quot; + allocateTextureCallback); var result = Runtime.dynCall(&#x27;iii&#x27;, allocateTextureCallback, [width, height]); &#x2F;&#x2F;console.log(&quot;UnityJS.jslib: _UnityJS_AllocateTexture: result: &quot; + result); return result; }; window.bridge._UnityJS_AllocateTexture = _UnityJS_AllocateTexture; </code></pre> Then you can call the C# method from JavaScript:<p><a href="https:&#x2F;&#x2F;github.com&#x2F;SimHacker&#x2F;UnityJS&#x2F;blob&#x2F;f0a4e1fb07fd9e8aaba2849fefd1d2239c262a97&#x2F;UnityJS&#x2F;Assets&#x2F;StreamingAssets&#x2F;game.jss#L348" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;SimHacker&#x2F;UnityJS&#x2F;blob&#x2F;f0a4e1fb07fd9e8aab...</a><p><pre><code> params.cache.backgroundSharedTextureID = id = window.bridge._UnityJS_AllocateTexture(params.width, params.height); </code></pre> This is zillions of time faster and more flexible than using Unity&#x27;s terrible SendMessage technique to send messages from JS=&gt;C#, whose only parameter is a single string, and which inefficiently dispatches messages by looking up Unity objects by name, and is asynchronous and can&#x27;t return a result.<p>I use this technique to efficiently copy binary textures and arrays of numbers between JavaScript and C#. MUCH better than serializing it as JSON, or base 64 encoded PNG files in a data: url (yuck!).<p><a href="https:&#x2F;&#x2F;github.com&#x2F;SimHacker&#x2F;UnityJS&#x2F;blob&#x2F;674eda49be12a7081205b6af4bf3986cb76ac7d7&#x2F;UnityJS&#x2F;Assets&#x2F;StreamingAssets&#x2F;game.jss#L382" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;SimHacker&#x2F;UnityJS&#x2F;blob&#x2F;674eda49be12a70812...</a><p><pre><code> function DrawToCanvas(params, drawer, success, error) { [...] var id = params.pie.backgroundSharedTextureID; if (!id) { params.pie.backgroundSharedTextureID = id = window.bridge._UnityJS_AllocateTexture(params.width, params.height); &#x2F;&#x2F;console.log(&quot;game.js: DrawToCanvas: WebGL: AllocateTexture: width: &quot; + params.width + &quot; height: &quot; + params.height + &quot; id: &quot; + id); } var imageData = context.getImageData(0, 0, params.width, params.height); window.bridge._UnityJS_UpdateTexture(id, imageData); texture = { type: &#x27;sharedtexture&#x27;, id: id }; success(texture, params); canvasNode.parentNode.removeChild(canvasNode); </code></pre> This lets me draw 2D user interface stuff, pie charts, diagrams, data visualizations, etc, in JavaScript with canvas, d3, or whatever library I like, and then efficiently use those images in Unity3D as user interface overlays, 3D textures, etc. It works great, and it&#x27;s smooth and interactive, mixing up 2D canvas graphics with 3D Unity stuff!<p>Unity is sorely lacking a decent 2D drawing library like canvas, not to mention fancy stuff built on top of it like d3.<p>I&#x27;m currently working on the plumbing to send binary arrays of floats from JavaScript to Unity, so I can pass them right into shaders!<p>Here&#x27;s some discussion about the magic MonoPInvokeCallback attribute:<p><a href="https:&#x2F;&#x2F;forum.unity.com&#x2F;threads&#x2F;monopinvokecallback-in-unity.132510&#x2F;" rel="nofollow">https:&#x2F;&#x2F;forum.unity.com&#x2F;threads&#x2F;monopinvokecallback-in-unity...</a><p>And about Unity.dyncall and the WebGL runtime:<p><a href="https:&#x2F;&#x2F;forum.unity.com&#x2F;threads&#x2F;c-jslib-2-way-communication.323629&#x2F;" rel="nofollow">https:&#x2F;&#x2F;forum.unity.com&#x2F;threads&#x2F;c-jslib-2-way-communication....</a><p>and:<p><a href="https:&#x2F;&#x2F;forum.unity.com&#x2F;threads&#x2F;super-fast-javascript-interaction-on-webgl.382734&#x2F;" rel="nofollow">https:&#x2F;&#x2F;forum.unity.com&#x2F;threads&#x2F;super-fast-javascript-intera...</a>
NVRM超过 6 年前
« ... calls between JS and WebAssembly are faster than non-inlined JS to JS function calls. »<p>Good note taken.
skrowl超过 6 年前
Looking forward to testing this with Blazor. This was the biggest problem currently.
infogulch超过 6 年前
Editing note: the first sentence under &quot;Optimizing JavaScript » WebAssembly calls&quot; seems to be repeated twice with different phrasings.
freecodyx超过 6 年前
some people are just good with explaining stuff,
catchmeifyoucan超过 6 年前
This was explained really well! I feel more knowledgeable now.
merhard超过 6 年前
wasted opportunity to mention apple pie in the example function.
simplecomplex超过 6 年前
Fast? What makes webapps slow isn’t JavaScript, it’s downloading 2 fucking megs of total shit to show the user a bunch of text and form inputs.