I'm going to attach a patch I wrote that fixes CPU and L2 Cache detection on alpha. CPU/cache detection is messed up on alpha because the format of /proc/cpuinfo is different for alpha. More details here: http://www.gentoo.org/proj/en/base/alpha/doc/alpha-porting-guide.xml#doc_chap7 I'll send a copy upstream, but I'm not sure if or when there will be another release. The last release was 12/30/04. output without the patch: ///////////////////////////////////////////////// CPU : L2 Cache : ///////////////////////////////////////////////// output from 2 systems using the patch: ///////////////////////////////////////////////// CPU : Dual Tsunami EV68AL 833MHz L2 Cache : 4096 KB ///////////////////////////////////////////////// ///////////////////////////////////////////////// CPU : Miata EV56 433MHz L2 Cache : 96 KB ///////////////////////////////////////////////// While you're at it, 'dodoc' reports that RESULT does not exist, but there is a file in the package called RESULTS. It looks like a typo, just add an S to RESULT in the dodoc line of the ebuild.
Created attachment 89356 [details, diff] nbench-byte-2.2.2-alpha.patch
Comment on attachment 89356 [details, diff] nbench-byte-2.2.2-alpha.patch patch is ugly, rewrite it better :p also, this isnt broken on just alpha, but many other systems ... see the cpuinfo patch we apply to coreutils for the values on most all arches
Created attachment 96077 [details, diff] nbench-2.2.2-cpuinfo.patch (In reply to comment #2) > (From update of attachment 89356 [details, diff] [edit]) > patch is ugly, rewrite it better :p > > also, this isnt broken on just alpha, but many other systems ... see the > cpuinfo patch we apply to coreutils for the values on most all arches Since reading /proc/cpuinfo is broken in a lot of programs for a lot of architectures, I wrote a library called libproccpuinfo which can read cpuinfo files from 19 architectures. Its in the portage tree as dev-libs/libproccpuinfo. Attached is a patch for nbench-2.2.2 which makes use of the library.
Please check if 2.2.3 fixes the issue.
No. The differences between 2.2.2 and 2.2.3 only consist of --- nbench-byte-2.2.2/sysinfo.sh 2004-12-29 21:58:29.000000000 -0500 +++ nbench-byte-2.2.3/sysinfo.sh 2008-05-12 16:35:23.000000000 -0400 @@ -18,7 +18,8 @@ compiler=`echo $* | sed -e 's/-static//g' -e 's/-Bstatic//g'` if $TEST `basename $1` = "gcc" && ($compiler -v) >/dev/null 2>&1 ; then - gccversion=`$compiler -v 2>&1 | sed -e "/version/!d"` +# Cygwin writes more than one line with "version" in it + gccversion=`$compiler -v 2>&1 | sed -e "/version/!d" | tail -n 1` else gccversion="$1" fi nbench not reading /proc/cpuinfo is a minor problem in comparison to the rotting hulk that is its code. Since nbench has to stay compatible with previous versions which means supporting DOS and other nastiness, so I decided to fork it and create cleanbench. I've spent some time majorly cleaning, reformatting, and all around making it decent code. Things like using libproccpuinfo, stripping huge amounts of entirely unused code, stripping DOS, Mac OS Classic, and Windows 3.1 support, fixing countless warnings, and splitting the 4445 line nbench1.c file into individual files for each benchmark. Check the code, you'd be amazed. The benchmark results are exactly the same. No tests have been altered other than to clean code and remove cruft. For comparison, sloccount reports nbench-2.2.3 ansic: 5217 (98.94%) sh: 56 (1.06%) cleanbench-1.0 ansic: 3084 (98.28%) sh: 54 (1.72%) The sizes of binaries compiled with gcc-4.2.4 and CFLAGS="-O3 -march-k8 -msse3" are nbench-2.2.3 - 64K cleanbench-1.0 - 46K ebuild attached. Please add to portage and mark bug as closed.
Created attachment 175140 [details] cleanbench-1.0 ebuild
Created attachment 175141 [details] cleanbench-1.0 sources
Since nothing is happening here anymore, I'll mark this closed/wontfix.
