Y
HN Search
Hacker News Search
new
|
comments
|
top
|
jobs
kannanvijayan
searching PlanetScale…
1.
▲
2.
▲
3.
▲
4.
▲
5.
▲
6.
▲
32 ms
·
271.
▲
by
kannanvijayan
13y ago
Author here. The "regular JS scores" do REALLY well on several benchmarks (faster than native, even), for one primary reason: the transcendental math cache (which every JS engine uses). This is a very specific optimization that e
272.
▲
by
kannanvijayan
13y ago
The 5-10x difference mentioned is the difference in raw hardware speed between mobile CPUs and desktop CPUs, not a reference to JS speed vs native speed. JS speed as compared to native depends heavily on the nature of the code being execute
273.
▲
by
kannanvijayan
13y ago
That's not the point I was addressing. It's obviously true that mobile is slower than desktop by a factor of 5-10x. However, the author uses Sunspider as a metric to claim that "JS engines haven't really gotten all tha
274.
▲
by
kannanvijayan
13y ago
Disclaimer: I'm a JS JIT developer. The use of Sunspider performance to talk about JS application performance is unfortunate, and undermines a significant part of the argument made in the article. Sunspider is a great benchmark to use
275.
▲
by
kannanvijayan
14y ago
The Baseline JIT will have more of an impact on common web code than highly optimized JITs like Ion. Most web code executes for a few iterations, and runs for short periods of time. Baseline takes over from the interpreter far sooner than
276.
▲
by
kannanvijayan
14y ago
I'm not sure which builds you compared. Firefox 22 is currently in Aurora phase, and Firefox 21 is Beta. It does seem like there's been a regression in the aggregate scores. Thanks for bringing it up, though, that should be looked into.
277.
▲
by
kannanvijayan
14y ago
If a page goes into the back/forward cache, then its js code generally gets kept around. But we don't persistently store jitcode for a page, and I don't know of any JS engine that does.
278.
▲
by
kannanvijayan
14y ago
There will be separate jitcode generated for each page. It's hard to share this kind of code because during generation we often bake-in immediate pointers to various things (like global objects, etc.) into the generated jitcode. The jitcod
279.
▲
JavaScript JITs: The Ins and Outs of Invalidation
(blog.mozilla.org)
3 points
by
kannanvijayan
14y ago
|
0 comments