Wow, nice! Much more in-line with what I was expecting. And a Pandaboard with hardfp should get in the same ballpark as that, right? Suddenly the power question is in much sharper relief.
ARM Cortex-A9 PandaBoard ES Benchmarks
Collapse
X
-
Originally posted by ssvb View PostBTW, here are my benchmark results from gentoo (hardfp) running on origenboard (dual-core ARM Cortex-A9 @1.2GHz): http://openbenchmarking.org/result/1...AR-1112277AR91
Comment
-
-
Originally posted by Wyatt View PostWow, nice! Much more in-line with what I was expecting. And a Pandaboard with hardfp should get in the same ballpark as that, right? Suddenly the power question is in much sharper relief.
Originally posted by curaga View PostHow much is from hardfp and how much from a tweaked arm core (exynos)?
I recall samsung's pr saying the exynos outruns omap4.
Originally posted by ldesnogu View PostThanks for doing that! These results make me think the Pandaboard was misconfigured.
Also a major problem for ARM when running tests like this is the missing sane support for runtime cpu features detection (-march=native and -mtune=native options support in gcc, reliable neon detection and use in all the neon optimized libraries). ARM Ltd. has been aware of the problem for years, but did nothing to address it
Comment
-
-
As for the benchmarks, "compress-7zip" test compiles the code with -O optimization, which is equivalent to -O1:
Code:$ cat install.log mkdir -p bin make -C CPP/7zip/Bundles/Alone all make[1]: Entering directory `/mnt/mmcblk0p2/.phoronix-test-suite/installed-tests/pts/compress-7zip-1.6.0/p7zip_9.20.1/CPP/7zip/Bundles/Alone' g++ -O -pipe -s -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -DNDEBUG -D_REENTRANT -DENV_UNIX -D_7ZIP_LARGE_PAGES -DBREAK_HANDLER -DUNICODE -D_UNICODE -c -I. -I../../../myWindows -I../../../ -I../../../include_windows ../../../myWindows/myGetTickCount.cpp g++ -O -pipe -s -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -DNDEBUG -D_REENTRANT -DENV_UNIX -D_7ZIP_LARGE_PAGES -DBREAK_HANDLER -DUNICODE -D_UNICODE -c -I. -I../../../myWindows -I../../../ -I../../../include_windows ../../../myWindows/wine_date_and_time.cpp ...
The build system for libvpx clearly does not use NEON, which explains poor results for "VP8 libvpx Encoding" test:
Code:# cat install.log Configuring selected codecs enabling vp8_encoder enabling vp8_decoder Configuring for target 'generic-gnu' enabling generic Creating makefiles for generic-gnu libs Creating makefiles for generic-gnu examples Creating makefiles for generic-gnu docs [DEP] vpx_config.c.d [DEP] vp8/decoder/reconintra_mt.c.d [DEP] vp8/decoder/idct_blk.c.d [DEP] vp8/decoder/threading.c.d [DEP] vp8/decoder/onyxd_if.c.d ...
Some other tests may show suboptimal results too, but I haven't looked there yet.
Comment
-
-
Originally posted by ssvb View PostBTW, here are my benchmark results from gentoo (hardfp) running on origenboard (dual-core ARM Cortex-A9 @1.2GHz): http://openbenchmarking.org/result/1...AR-1112277AR91
Comment
-
-
Enabled the use of NEON in VP8 LIBVPX ENCODING test by hacking libvpx build scripts:
Code:$ ./configure --target=armv7-linux-gcc Configuring selected codecs enabling vp8_encoder enabling vp8_decoder Configuring for target 'armv7-linux-gcc' enabling armv7 enabling armv6 enabling armv5te enabling fast_unaligned Creating makefiles for armv7-linux-gcc libs Creating makefiles for armv7-linux-gcc examples Creating makefiles for armv7-linux-gcc docs
Comment
-
-
Originally posted by ssvb View PostAs for the benchmarks, "compress-7zip" test compiles the code with -O optimization, which is equivalent to -O1
Code:$ cat install.sh #!/bin/sh tar -zxvf smallpt-1.tar.gz g++ -fopenmp smallpt.cpp -o smallpt-renderer echo $? > ~/install-exit-status echo "#!/bin/sh ./smallpt-renderer 100 > \$LOG_FILE 2>&1 echo \$? > ~/test-exit-status" > smallpt chmod +x smallpt
Comment
-
Comment