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

科技回声

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

GitHubTwitter

首页

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

资源链接

HackerNews API原版 HackerNewsNext.js

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

The Emterpreter: Run asm.js code before it can be parsed

181 点作者 Rauchg超过 10 年前

12 条评论

Kronopath超过 10 年前
I actually really like the sound of this, not because of the stated benefits (though those are nice), but because it sounds like this would actually create a really good upgrade path to implementing a <i>proper bytecode</i> into browsers.<p>I mean, with asm.js and the copious amounts of compile-to-Javascript languages available these days, Javascript is already becoming a de facto bytecode for the web. But it&#x27;s always been a weird and uncomfortable hack done for the sake of backwards compatibility: a higher-level language hijacked to work as a compile target, simply because it&#x27;s the only thing supported by browsers.<p>If projects like this Emterpreter catch on, though, it allows for a smooth path to proper bytecode: for backwards compatibility, you have the Emterpreter read and execute the bytecode, but in other, more modern browsers you have the browser execute the bytecode directly. I think this would be an overall better approach than what we have now.
评论 #9096910 未加载
评论 #9097536 未加载
评论 #9096585 未加载
评论 #9096621 未加载
flohofwoe超过 10 年前
I think this is the first emscripten feature which I don&#x27;t &quot;get&quot;, e.g. not fully understanding the motivation behind it :) Firefox AOT compile time is great, and nothing at all compared to the time it takes to download the code. The real art lies in getting the actual emscripten compiled executable small, not because of emscripten, but because of C++&#x27;s tendency to bloat the executable size if one isn&#x27;t really careful. Also, clang and emscripten&#x27;s code generation passes have very aggressive dead code elimination, but there can be wrong decisions on the game engine architecture-level which can cause the inclusion of code that might never be called. A native executable that&#x27;s several dozen MByte&#x27;s big is a bad thing on any platform, it just doesn&#x27;t appear as such a problem if it is a part of a 50 GByte game download. To come to and end, I think an emscripten client of up to 5 MByte (gzipped) doesn&#x27;t really require a fix like emterpreter for its startup time(?), and it&#x27;s perfectly possible to fit a full 3D game client into such a size with a little care about size optimization.<p>[edit: fixed a formulation which sounded like code bloat can be blamed on emscripten instead of user-code]
评论 #9096904 未加载
评论 #9096738 未加载
评论 #9096866 未加载
AshleysBrain超过 10 年前
This is very cool, and great to read more interesting research from Mozilla. However in this article I notice something curious: normal asm.js kicks off and shortly after reaches top speed by around 700ms. emterpreter gets going by 200ms, but takes another 1200ms to reach top speed by 1400ms. Why is it not another 700ms? Isn&#x27;t it just doing the same work as asm.js but in the background while running with emterpreter?<p>Non-blacklisted emterpreter looks slow enough (5fps ish on that graph?) to simply not be useful for some use cases, like a game engine - it&#x27;s not going to be remotely playable like that. Therefore emterpret =&gt; asm.js actually significantly increases the startup time. Playable by 1400ms is worse than playable by 700ms. But I guess this is all preliminary and improvable though!
评论 #9097077 未加载
jerf超过 10 年前
As I sometimes see wmf say, &quot;as predicted by prophecy:&quot; <a href="https://news.ycombinator.com/item?id=6923758" rel="nofollow">https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=6923758</a>
评论 #9096748 未加载
mmastrac超过 10 年前
Hot damn, that&#x27;s exciting. I prefer the asm.js approach over PNaCl because it lets browsers gradually move over to the standard rather than forcing a flag day. This solves the big issue, namely parsing that big, hot mess of raw JS.<p>I hope we&#x27;ll eventually see a proper bytecode spec with bidirectional assembly&#x2F;disassembly w.r.t. JS (ie: more a transformation than an assembly spec) evolve from this effort, but it&#x27;s obviously something that needs to happen <i>after</i> asm.js has had its time to bake.<p>This, of course, assumes that browsers don&#x27;t get AOT&#x2F;background compilation to the point where it&#x27;s no longer necessary to consider a bytecode spec.
im3w1l超过 10 年前
After we have evicted Java from our browsers and turned Javascript into the new Java, what have we gained?
评论 #9096669 未加载
kelvin0超过 10 年前
Yeah, maybe if we could compile to some byte code and simply download a VM to compile once and run everywhere ... hmmm where have I seen this before?
al2o3cr超过 10 年前
&quot;Oh wow, wouldn&#x27;t it be great if browsers had a bytecode interpreter in them?&quot;<p>Two words: &quot;Java applets&quot;.
GeorgeHahn超过 10 年前
Is it straightforward to reference a separate compiled library from an Emscripten binary?<p>Seems that caching commonly shared dependencies could be a good way to cut down on size and parse&#x2F;compile time.
leeoniya超过 10 年前
a bit OT, but one thing i always wondered is, can&#x27;t we extract inferred type information from the JIT after running plain JS code through 1M cycles and then compile that to an asm.js variant?
评论 #9096787 未加载
rafaelferreira超过 10 年前
Quite similar to tiered compilation on the JVM
AndrewDucker超过 10 年前
So, how long until someone gets the JVM or CLR running inside the browser using asm.js - and then reopens the world of running Java&#x2F;C# in the browser. Only this time without plugins.
评论 #9097576 未加载