Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Mozilla's JM crosses Apple's Nitro threshold

arewefastyet.com

Post reply on HN
Print view View original

11–20 of 37 posts

Re: Mozilla's JM crosses Apple's Nitro threshold

#11

Post by natmaster »

buster wrote: post #10
natmaster wrote: post #9

Earlier quoted context omitted.

And yet that's what people seem to like using it for. I still don't see why machine translated scheme is a good benchmark for fine tuning code. Javascript is a fine language to work in - especially if you are wanting to use it for things other than a browser (then you must really like it!).

I haven't seen the code but based on the description it's a benchmark that was originally in scheme and ported to javascript.. sounds fine to me. And "kernel simulation benchmark" may have a usecase too, just because you can't think of it, doesn't mean it isn't there ;) I can think of tests for scheduling, threading, asynchronous code, I/O when i think of "kernel simulation". Again, people like to use V8benchmarks, w…

"...Florian Loitsch's Scheme2Js compiler"

No, Florian Loitsch isn't a human translator for hire - he wrote a compiler.

Re: Mozilla's JM crosses Apple's Nitro threshold

#12

Post by buster »

natmaster wrote: post #11
buster wrote: post #10

Earlier quoted context omitted.

I haven't seen the code but based on the description it's a benchmark that was originally in scheme and ported to javascript.. sounds fine to me. And "kernel simulation benchmark" may have a usecase too, just because you can't think of it, doesn't mean it isn't there ;) I can think of tests for scheduling, threading, asynchronous code, I/O when i think of "kernel simulation". Again, people like to use V8benchmarks, w…

"...Florian Loitsch's Scheme2Js compiler" No, Florian Loitsch isn't a human translator for hire - he wrote a compiler.

Yes, but the benchmark is not "how fast does V8 translate scheme to JS", it's "how fast does V8 run benchmarks in javascript that where translated from scheme some time ago". Atleast that's how i understand it.

Re: Mozilla's JM crosses Apple's Nitro threshold

#14

Post by _delirium »

buster wrote: post #12
natmaster wrote: post #11

Earlier quoted context omitted.

"...Florian Loitsch's Scheme2Js compiler" No, Florian Loitsch isn't a human translator for hire - he wrote a compiler.

Yes, but the benchmark is not "how fast does V8 translate scheme to JS", it's "how fast does V8 run benchmarks in javascript that where translated from scheme some time ago". Atleast that's how i understand it.

That's true, but machine-generated code can be pretty nutty, depending on what exactly the Scheme2JS compiler does. It's legitimate JS code, but it might not be representative of what JS-written-in-JS looks like.

Re: Mozilla's JM crosses Apple's Nitro threshold

#15

Post by buster »

_delirium wrote: post #14
buster wrote: post #12

Earlier quoted context omitted.

Yes, but the benchmark is not "how fast does V8 translate scheme to JS", it's "how fast does V8 run benchmarks in javascript that where translated from scheme some time ago". Atleast that's how i understand it.

That's true, but machine-generated code can be pretty nutty, depending on what exactly the Scheme2JS compiler does. It's legitimate JS code, but it might not be representative of what JS-written-in-JS looks like.

True, but i see that this is a valid testcase. For example GWT generates JS out of Java, so it might be useful to also benchmark machinegenerated JS.

Re: Mozilla's JM crosses Apple's Nitro threshold

#16

Post by pornel »

thristian wrote: post #6
samps wrote: post #3

One possible takeaway from these graphs is the urgent need for better JavaScript benchmarks. Both SunSpider and the V8 benchmarks are sets of microbenchmarks and the difference between them is enormous: JM+TM is significantly faster than plain JM on V8 but is a little slower on SunSpider. The fact that the conclusions can vary so greatly among these two (both deeply flawed) benchmark suites suggests that the true "re…

About a month ago, Mozilla released their' "Kraken" benchmark suite, designed to better reflect what actual web-apps actually do: http://blog.mozilla.com/rob-sayre/2010/09/14/release-the-kraken/ It's not listed on arewefastyet.com, but apparently Firefox 4 handily beats Chrome and IE9: http://weblogs.mozillazine.org/asa/archives/2010/09/javascript_performan.html

The tests are: astar, beat-detection, dft, fft, oscillator, gaussian-blur, darkroom, desaturate, parse-financial, stringify-tinderbox, crypto-aes, crypto-ccm, crypto-pbkdf2, crypto-sha256-iterative.

One big thing that's missing here is DOM interaction, which is a real bottleneck for current web apps (and handling 'foreign' API well is JS engine's job too).

Re: Mozilla's JM crosses Apple's Nitro threshold

#17

Post by riffraff »

natmaster wrote: post #4
samps wrote: post #3

One possible takeaway from these graphs is the urgent need for better JavaScript benchmarks. Both SunSpider and the V8 benchmarks are sets of microbenchmarks and the difference between them is enormous: JM+TM is significantly faster than plain JM on V8 but is a little slower on SunSpider. The fact that the conclusions can vary so greatly among these two (both deeply flawed) benchmark suites suggests that the true "re…

Here's an alternative: http://krakenbenchmark.mozilla.com/kraken-1.0/driver.html I have to agree, that things like machine translated scheme and OS scheduling are not representative of real world applications. (Part of the V8 suite: http://v8.googlecode.com/svn/data/benchmarks/v6/run.html - specifically Richards, and EarleyBoyer)

the richards benchmark is not only a simulation of OS scheduling though, it's a classic benchmark of method dispatch performance (at least from what I recall, which is why everybody is using it via a Smalltalk inheritance and not reimplementing the bcpl code)

Re: Mozilla's JM crosses Apple's Nitro threshold

#18

Post by mgedmin »

nathanhammond wrote: post #5

This appears to be what got them there: http://andreasgal.wordpress.com/2010/10/13/compartments/ Also worth noting, there is no longer a gigantic "NO" down at the bottom of the page. :)

I miss that "NO".

I expected to see "YES!", or maybe "MAYBE" in its place, but there's nothing there.

Re: Mozilla's JM crosses Apple's Nitro threshold

#19

Post by amix »

I have heard from the V8 developers that Mozilla do some optimizations just to score better on benchmarks - i.e. they score really good on things that are specifically benchmarked. I have not verified their claim, but generally for me as an user Chrome and Safari feel a lot faster than Firefox.

Re: Mozilla's JM crosses Apple's Nitro threshold

#20

Post by _urga »

A good browser benchmark would also measure:

1. Browser boot time.

2. Browser shutdown time (on clicking Close).

3. Tab boot time.

4. Tab shutdown time.

5. LocalStorage boot time (on first call to LocalStorage API, some browsers load LocalStorage into memory at this point, blocking the UI).

6. IO performance of LocalStorage, WebSQLDatabase, IndexedDB for massive get/set operations (bandwidth) and many get/set operations (latency).

7. ApplicationCache update time (and update time after an interrupted update cycle).

8. Smoothness of moving a DOM element across the screen by adjusting absolute position (some browsers are choppy with this).

9. Javascript parse time.

10. Minimum setTimeout frequency (is it 1ms or 5ms?).

11. Hash change event propagation time.

12. Stack size limit.

13. Speed of Array.shift on massive arrays.

14. Vertical height of browser chrome at top of the window in pixels (less is better).

15. Vertical height of browser chrome at bottom of the window in pixels (less is better).

16. Number of colors used in browser chrome, including favicons in location and bookmark bars etc. (less is better).

17. Fullscreen support and switch to fullscreen time.

18. Developer Console boot and shutdown time.

19. Number of words, tabs, nested interfaces used across all Preferences pages (less is better).

20. Number of user actions (clicks, keypresses, mouse movement distances) required to clear LocalStorage, History, WebSQLDatabase, IndexedDB, Cache, ApplicationCache (less is better).

21. Default storage limits for LocalStorage etc. (higher is better).

22. Data-URI size limits (higher is better).

Post reply on HN