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

科技回声

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

GitHubTwitter

首页

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

资源链接

HackerNews API原版 HackerNewsNext.js

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

How Node.js applications will benefit from replacing V8 in JXcore

29 点作者 obastemur大约 11 年前

8 条评论

tantalor大约 11 年前
Nothing to see here. Author uses Octane benchmark where bigger is better, so v8 ~26 beats the &quot;experimental engine&quot;.<p><i>Q: What do the scores mean?</i><p><i>A: In a nutshell: bigger is better. Octane measures the time a test takes to complete and then assigns a score that is inversely proportional to the run time (historically, Firefox 2 produced a score of 100 on an old benchmark rig the V8 team used).</i><p><a href="https://developers.google.com/octane/faq" rel="nofollow">https:&#x2F;&#x2F;developers.google.com&#x2F;octane&#x2F;faq</a>
评论 #7694997 未加载
评论 #7695106 未加载
egeozcan大约 11 年前
They should clearly state that this is a private fork (as in, not open source).
评论 #7694666 未加载
cibyr大约 11 年前
I thought bigger means faster for Octane scores. Isn&#x27;t this showing that their engine has about 75% of the performance of V8?
评论 #7694766 未加载
AshleysBrain大约 11 年前
How exactly does JXCore manage to beat years worth of optimisation engineering by Google? I&#x27;m skeptical, especially since I can imagine an engineering tradeoff between performance and stability. Maybe V8 is slower because they fixed crash bugs caused by overoptimistic code generation. What assurances does anyone have that their slower but working V8 code won&#x27;t be fast and broken in a new engine?
评论 #7694789 未加载
评论 #7694829 未加载
bbllee大约 11 年前
Seems double-silly. First there&#x27;s the whole &quot;smaller is better... I mean, whoops!&quot;-ness of the blogpost. Second is the general choice of benchmark: JXcore is supposed to be a multithreaded JS engine, so it seems like you&#x27;d want to benchmark its multithreaded performance against V8&#x27;s single thread perf. on some workload that can take advantage of multiple threads.
Excavator大约 11 年前
Source code protection? I guess this is some form of security by obscurity when distributing to clients? If it&#x27;s for in-house code, why would you limit it to the set of data covered by this framework rather than proper encryption for your whole project?
chilledheart大约 11 年前
Maybe JXcore will come with a new LLVM Javascript Frontend?<p>Looking forward to it.<p><a href="http://jxcore.com/jxcore-llvm-javascript-frontend-b/" rel="nofollow">http:&#x2F;&#x2F;jxcore.com&#x2F;jxcore-llvm-javascript-frontend-b&#x2F;</a>
alexchamberlain大约 11 年前
What are you doing computing heavy stuff in JS for?
评论 #7694907 未加载
评论 #7694837 未加载