Skip to content
This repository has been archived by the owner on Dec 29, 2022. It is now read-only.

Octane fails on big endian systems #19

Open
GoogleCodeExporter opened this issue Apr 11, 2015 · 1 comment
Open

Octane fails on big endian systems #19

GoogleCodeExporter opened this issue Apr 11, 2015 · 1 comment

Comments

@GoogleCodeExporter
Copy link

What steps will reproduce the problem?
1. Obtain V8 port to PowerPC https://github.com/andrewlow/v8ppc
2. Compile V8 on PowerPC running big endian
3. Run octane benchmark using V8 on a big endian system

What is the expected output? What do you see instead?

Ideally we'd like the Octane benchmark to apply to all systems capable of 
running JS. Unfortunately with TypedArrays it is possible to create endian 
specific code in JS, this often breaks when switching endian.

What version of the product are you using? On what operating system?

Latest version of octane: 
svn checkout http://octane-benchmark.googlecode.com/svn/trunk/ 
octane-benchmark-read-only

PowerPC in big endian mode / Linux (RHEL).

Please provide any additional information below.

There are only a couple of tests that fail:
mandreel
zlib

The mandreel tests bail with: "Mandreel: Alert called with argument: Check sum 
mismatch: expected ???, actual 6152943" - this is because of the use of typed 
arrays for heap emulation AND the assumption that you can mix and match 32bit 
accesses and 8bit accesses (classic endian breaking code).

The mandreel code is difficult to propose a patch as it's been run through a 
C++ -> JS tool. The correct 'fix' may be to have the tool deal with big endian 
systems. It may be possible to tweak the mixed 8/16 bit accesses with some 
offset adjustments via a manual patch.

The zlib test is more descriptive with it's failure:
"Assertion failed: Typed arrays 2 must be run on a little-endian system:
Error
    at Error (<anonymous>)
    at F (eval at InitializeZlibBenchmark (zlib-data.js:65:37), <anonymous>:1:3255)
    at z (eval at InitializeZlibBenchmark (zlib-data.js:65:37), <anonymous>:1:3312)
    at eval (eval at InitializeZlibBenchmark (zlib-data.js:65:37), <anonymous>:1:6179)
    at eval (native)
    at InitializeZlibBenchmark (zlib-data.js:65:37)
    at Benchmark.runZlib [as run] (zlib.js:37:5)
    at Measure (base.js:307:17)
    at BenchmarkSuite.RunSingleBenchmark (base.js:325:5)
    at RunNextBenchmark (base.js:369:20)
zlib: Assertion: Assertion failed: Typed arrays 2 must be run on a 
little-endian system"

The zlib problem may be easier to address as it's clear the code is checking 
for it. I've not looked into it yet.

Ultimately it would be good to have Octane work across all JS capable platforms 
(both endians) as I believe it to be a good choice for benchmarking JS (and 
specifically V8) performance.

A policy statement from the team maintaining Octane on the support of big 
endian (or not) would also be welcomed.

Original issue reported on code.google.com by [email protected] on 22 May 2014 at 2:05

@GoogleCodeExporter
Copy link
Author

"Octane's goal is to be a proxy for the JavaScript application that you'll 
encounter when running browser games..."

PPC, while a minor player in the browser world, is still a viable environment 
that one may find a JavaScript application. In order to meet the goals of 
Octane the test should be able to execute in any spec compliant ECMA 
environment.

Original comment by [email protected] on 31 Oct 2014 at 12:51

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests

1 participant