Linearer Modus

thosch97 · 14.04.2011 14:40

Hier hats der FF4 einwandfrei angezeigt.
@oreissig: Ich würd statt einem [code] eher [tt] nehmen, vermeidet dann halt unnötige Kästen drumherum

**Xaar** · 14.04.2011 15:00

Ja wann denn? VOR oder NACHDEM Oreissig das umgeändert hat? Jetzt zeigts mir auch alles richtig an.

thosch97 · 14.04.2011 15:10

Vorher wars schon richtig

**oreissig** · 14.04.2011 15:16

Dann ist 1. Dein firefox 4 anders als meiner, ich bin ja auch damit unterwegs und 2. Ist deiner dann fehlerhaft, denn das zu tiefe verschachtelungen ausgelassen werden ist afaik ein feature gegen endloszitierungen

Wegen tt vs code: tt ist nach wie vor normaler text, der kürzt leerzeichen weg und zerstört damit das tabellenlayout der nbench-ausgabe. Bei Pi hätt mans machen können, ja, aber nu binsch zu faul zu editieren

28.04.2011 10:49

Auf meiner Blade 1500 mit 1,05GHz UltrasparcIIIi unter Solaris 10.

18.48 sec. (real time)

Neu, jetzt auch mit Java!

51.24 sec. (real time)

**oreissig** · 26.05.2011 21:57

so, meine kleine Microchannel-RS/6000 7011-250:

Code:

BYTEmark* Native Mode Benchmark ver. 2 (10/95)

Index-split by Andrew D. Balsa (11/97)

Linux/Unix* port by Uwe F. Mayer (12/96,11/97)

TEST                : Iterations/sec.  : Old Index   : New Index

                    :                  : Pentium 90* : AMD K6/233*

--------------------:------------------:-------------:------------

NUMERIC SORT        :          29.142  :       0.75  :       0.25

STRING SORT         :          2.0638  :       0.92  :       0.14

BITFIELD            :      6.4662e+06  :       1.11  :       0.23

FP EMULATION        :          4.6065  :       2.21  :       0.51

FOURIER             :          617.05  :       0.70  :       0.39

ASSIGNMENT          :         0.33956  :       1.29  :       0.34

IDEA                :          68.027  :       1.04  :       0.31

HUFFMAN             :          54.152  :       1.50  :       0.48

NEURAL NET          :         0.70796  :       1.14  :       0.48

LU DECOMPOSITION    :           19.92  :       1.03  :       0.75

==========================ORIGINAL BYTEMARK RESULTS==========================

INTEGER INDEX       : 1.192

FLOATING-POINT INDEX: 0.937

Baseline (MSDOS*)   : Pentium* 90, 256 KB L2-cache, Watcom* compiler 10.0

==============================LINUX DATA BELOW===============================

CPU                 : 80MHz PowerPC 601

L2 Cache            : ???

OS                  : AIX 5.1

C compiler          : C for AIX Compiler, Version 5

libc                :

MEMORY INDEX        : 0.223

INTEGER INDEX       : 0.369

FLOATING-POINT INDEX: 0.520

Baseline (LINUX)    : AMD K6/233*, 512 KB L2-cache, gcc 2.7.2.3, libc-5.4.38

* Trademarks are property of their respective holder.

**oreissig** · 07.07.2011 23:51

SGI POWER Indigo²

32bit (n32):

Code:

$ ./nbench BYTEmark* Native Mode Benchmark ver. 2 (10/95) Index-split by Andrew D. Balsa (11/97) Linux/Unix* port by Uwe F. Mayer (12/96,11/97) TEST : Iterations/sec. : Old Index : New Index : : Pentium 90* : AMD K6/233* --------------------:------------------:-------------:------------ NUMERIC SORT : 41.67 : 1.07 : 0.35 STRING SORT : 5.9997 : 2.68 : 0.41 BITFIELD : 2.1607e+07 : 3.71 : 0.77 FP EMULATION : 10.723 : 5.15 : 1.19 FOURIER : 990.64 : 1.13 : 0.63 ASSIGNMENT : 0.91409 : 3.48 : 0.90 IDEA : 155.28 : 2.37 : 0.71 HUFFMAN : 74.712 : 2.07 : 0.66 NEURAL NET : 2.3819 : 3.83 : 1.61 LU DECOMPOSITION : 84.007 : 4.35 : 3.14 ==========================ORIGINAL BYTEMARK RESULTS========================== INTEGER INDEX : 2.660 FLOATING-POINT INDEX: 2.658 Baseline (MSDOS*) : Pentium* 90, 256 KB L2-cache, Watcom* compiler 10.0 ==============================LINUX DATA BELOW=============================== CPU : MIPS R8000 75MHz L2 Cache : 2MB OS : IRIX64 6.2 C compiler : MIPSpro 7.3 (n32) libc : MEMORY INDEX : 0.662 INTEGER INDEX : 0.665 FLOATING-POINT INDEX: 1.474 Baseline (LINUX) : AMD K6/233*, 512 KB L2-cache, gcc 2.7.2.3, libc-5.4.38 * Trademarks are property of their respective holder.

64bit:

Code:

$ ./nbench BYTEmark* Native Mode Benchmark ver. 2 (10/95) Index-split by Andrew D. Balsa (11/97) Linux/Unix* port by Uwe F. Mayer (12/96,11/97) TEST : Iterations/sec. : Old Index : New Index : : Pentium 90* : AMD K6/233* --------------------:------------------:-------------:------------ NUMERIC SORT : 38.219 : 0.98 : 0.32 STRING SORT : 6.4353 : 2.88 : 0.45 BITFIELD : 2.1633e+07 : 3.71 : 0.78 FP EMULATION : 10.462 : 5.02 : 1.16 FOURIER : 994.19 : 1.13 : 0.64 ASSIGNMENT : 0.36684 : 1.40 : 0.36 IDEA : 155.58 : 2.38 : 0.71 HUFFMAN : 76.395 : 2.12 : 0.68 NEURAL NET : 2.3762 : 3.82 : 1.61 LU DECOMPOSITION : 84.926 : 4.40 : 3.18 ==========================ORIGINAL BYTEMARK RESULTS========================== INTEGER INDEX : 2.327 FLOATING-POINT INDEX: 2.668 Baseline (MSDOS*) : Pentium* 90, 256 KB L2-cache, Watcom* compiler 10.0 ==============================LINUX DATA BELOW=============================== CPU : MIPS R8000 75MHz L2 Cache : 2MB OS : IRIX64 6.2 C compiler : MIPSpro 7.3 (64) libc : MEMORY INDEX : 0.500 INTEGER INDEX : 0.650 FLOATING-POINT INDEX: 1.480 Baseline (LINUX) : AMD K6/233*, 512 KB L2-cache, gcc 2.7.2.3, libc-5.4.38 * Trademarks are property of their respective holder.

EDIT: hier mal die Ergebnisse gegen den 200MHz R4400 1MB in meiner IP22 Indigo² (von dem aktuellen 250er 2mb hab ich noch keine benchmarkergebnisse mit MIPSpro)

Code:

CPU                 : MIPS R4400 200MHz

L2 Cache            : 1MB

OS                  : IRIX 6.5.22

C compiler          : MIPSpro 7.4.4m (n32)

libc                : 

MEMORY INDEX        : 0.816

INTEGER INDEX       : 0.650

FLOATING-POINT INDEX: 1.307

weiß nicht genau, warum die Kiste nen merklich höheren Memory index hat (ältere architektur, weniger cache, und 32bit wars ja in beiden fällen. vll liegts am etwas neueren compiler. benchmark mit gleichem setup werd ich mal noch machen), aber der integer index ist in etwa gleich zum 75MHz R8k und in FP schlägt der R8k den sehr viel schnelleren R4400 sogar

alles in allem ziemlich beachtliche Leistung für 75MHz

08.07.2011 08:51

Jo, der R8k hat eine deutlich höhere Floatingpoint Leistung als der R4k4, welcher bei Integer dann wegen dem Takt besser ist. Ein R8k mit mehr Takt wäre geil.

**oreissig** · 08.07.2011 09:27

mrshadowtux schrieb: Ein R8k mit mehr Takt wäre geil.

nennt sich R10k

ich mach ja bei meinen benchmarks immer noch als kleines fazit (MEM+INT+FP)/Takt*, und die Top 3 dort sind:

39,73 MIPS R12000 2MB (300MHz) in der Octane
38,02 MIPS R10000 1MB (250MHz) in der Octane
37,35 MIPS R8000 2MB (75MHz) in der Indigo²

danach ist erstmal bisschen abstand und dann kommen HP PA-8800 32MB (33,86), DEC Alpha 21264A 4MB (32,37) und gleichauf IBM POWER3-II 8MB (32,37)

zum Vergleich: mein alter Banias Pentium-M im Compaq N620c kam auf 16,45 und mein Merom Core2Duo im Thinkpad T61 kommt auf 12,02. allerdings sind die auch mit gcc gebenchmarkt, der insbesondere im FP-bereich mal überhaupt nich an herstellereigene Compiler rankommt.

EDIT: * damits hübscher aussieht hab ich den wert noch *1000 genommen, sonst wären das alles nachkommawerte

05.09.2011 16:12

pi_css5

Wir erinnern uns: Sun Ultra 2 (UltrasparcII mit 300MHz) unter Debian GNU/Linux mit Standard CFLAGS 65,16 Sekunden.

Heute mal mit

Zitat:CFLAGS = -O4 -mcpu=ultrasparc -pipe -fomit-frame-pointer -ffast-math -finline-functions -fweb -frename-registers -mapp-regs

Das verkürzt den Durchlauf auf 50,96 Sekunden!

Wer glaubt das war alles, der täuscht sich.
Mit

Zitat:CFLAGS = -O4 -mcpu=ultrasparc -pipe -fomit-frame-pointer -ffast-math -finline-functions -fweb -frename-registers -mapp-regs -mvis -Wa,-Av8plusa

sind es 49,28 Sekunden!