chromium / octane

The JavaScript Benchmark Suite for the modern web
https://developers.google.com/octane/
BSD 3-Clause "New" or "Revised" License
183 stars 73 forks source link

Version of GameBoy Online used for GB-EMU is out of date #6

Closed GoogleCodeExporter closed 9 years ago

GoogleCodeExporter commented 9 years ago
I noticed a bunch of core code in the latest github version is different than 
what is used in Octane trunk. Specifically things like the APU core (A more 
efficient version has landed since your copy of it) and XAudioJS library are 
out of date.

Some unrelated nitpicks about GB-EMU:
I'm also surprised that the Octane modification to make sure no audio is 
generated was done within the audio library, rather than by changing the value 
stored at index 0 of the settings array to false. The GBC core will still 
emulate the APU, but simply not use the audio lib, which is already "dummy 
emulated" by Octane's modifications anyhow. I'm also surprised Octane is 
passing a full dummy canvas object in rather than having the emulator output to 
a fully hidden canvas. Lastly, I noticed that the bench is said to require 
typed arrays, while the official copy of GameBoy-Online explicitly does not 
require typed array support. The code was designed around legacy arrays with 
typed arrays as a "bonus," which means things like 8-bit math are bitwise AND 
guarded manually in the code (Which actually is faster than requiring the typed 
arrays to implicitly perform the overflow wrap, as some browser engines slow 
down a lot on performing the implied overflows).

Original issue reported on code.google.com by grantgal...@gmail.com on 31 Aug 2012 at 7:55

GoogleCodeExporter commented 9 years ago
We also seem to have extraneous "use strict"; lines in the bench as well.

If someone is having a hard time spotting the audio disable/enable setting, 
it's at 
http://code.google.com/p/octane-benchmark/source/browse/trunk/gbemu.js#10689

Original comment by grantgal...@gmail.com on 31 Aug 2012 at 7:59

GoogleCodeExporter commented 9 years ago

Original comment by octane.t...@gmail.com on 11 Sep 2012 at 2:58

GoogleCodeExporter commented 9 years ago
> I noticed a bunch of core code in the latest github version is different than 
what is used in Octane trunk.
> Specifically things like the APU core (A more efficient version has landed 
since your copy of it) and XAudioJS
> library are out of date.

We need to stick to the version picked when Octane was made, if we update it, 
we would change the score. We might think to update it in the future with a 
newer version of Octane, but only if there are advantages from a benchmarking 
point of view

> I'm also surprised that the Octane modification to make sure no audio is 
generated was done within the
> audio library, rather than by changing the value stored at index 0 of the 
settings array to false.
We wanted to make sure that the Resampler.interpolate gets called at least 
once, also having audio library makes it easier to add other games.

> I'm also surprised Octane is passing a full dummy canvas object in rather 
than having the emulator output 
> to a fully hidden canvas.
We already implemented dummy canvas for other benchmarks and it was easier to 
reuse it.

> Lastly, I noticed that the bench is said to require typed arrays, while the 
official copy of GameBoy-Online
> explicitly does not require typed array support. 
Our interpretation of the code was that if TypedArrays are present, they will 
be used and there will be a fallback to normal types if not available. This is 
not wished at the moment, since we need to know the same code is executed the 
whole time, i.e. a test should not have two versions.

But we are reviewing this last point, perhaps we could mark what tests used 
typed arrays and what not and allow all tests to fallback when desired.

Original comment by octane.t...@gmail.com on 12 Sep 2012 at 1:52

GoogleCodeExporter commented 9 years ago
I'm worried though that using the audio lib in an unrealistic manner (running 
once versus many times over the course of even seconds) might affect the goal 
of measuring realistic performance. The emulator was designed for performance 
over hours, with no respect to startup time. It was designed for run-time 
performance, not compile-time performance.

Original comment by grantgal...@gmail.com on 21 Sep 2012 at 2:53