PovRay3 - wie schnell sind andere Kisten ?
Kristian Köhntopp
h...@caty.ol.sub.de (Holger Lubitz) writes:
>Daher moechte ich alle PovRay-Fans bitten, doch mal auf ihrer Kiste eine
>Szene zu rendern und das Ergebnis unter Angabe des Prozessors zu posten.
>Als Testszene habe ich mir chess.pov ausgesucht, sie ist im povlinux.tgz
>mit dabei (unter povscn/level3/chess.pov). Ich habe die Szene mit dem
>offiziellen Linux-Binary von povray (Povray 3.00e.Linux.gcc) und Optionen
>wie folgt gerendert:
>povray +W640 +H480 +A0.3 +Q9 +L/usr/local/lib/povray3/include +Ichess.pov
>(der Vollstaendigkeit halber: povray ist ein Symlink auf x-povray)
Ich habe aehnliche Untersuchungen selber einmal gemacht, aber
mit einer anderen Szene. Ich habe die Antworten hier in der
Gruppe und meine Werte einmal in einer Tabelle zusammengefasst.
Dabei bedeuten:
Lubitz-Bench:
povray +W640 +H480 +A0.3 +Q9 +L/usr/local/lib/povray3/include +Ichess.pov
Koehntopp-Bench:
povray +W640 +H480 +Q9 +L$HOME/povray3/include +V +Ilaser.pov
Ich habe einmal angenommen, dass man Lubitze in Koehntopps
umrechnen kann und ich skaliere das mit 3.16 Koehntopps = 1
Lubitz (siehe die Messwerte fuer Sparc Ultra in der Tabelle
unten). Mit (*) markierte Werte sind aus dem jeweils anderen
Benchmark errechnet. Alle Angaben in den Spalten Lubitz und
Koehntopp in Sekunden, kleinere Werte sind besser.
In der Spalte "Rel. Performance" ist die relative
Geschwindigkeit der Kisten angegeben. Dabei ist ein PPro
200/256 mit 200 Einheiten zu Grunde gelegt worden, die Werte
sind also "Pentium Pro MHz", groessere Werte sind besser.
Beachte besonders die enttaeuschenden Werte der relativ alten
Alphas (die 3000er Serie wird von DEC seit geraumer Zeit nicht
mehr hergestellt und verkauft).
Alles in allem kann ein PPro200/256 mit aktuellen Workstations
gut mithalten, was die FP-Performance angeht. Beachte, dass
dieser Test ueber Integer-Performance fast nichts aussagt,
ueber I/O-Leistung oder Grafikperformance gar nichts.
Ich wuerde gerne noch ein paar Werte von aktuellen Alphas und
HP Workstations sehen und vielleicht setzen Stefan Stapelberg
oder Heiko Schlichting noch einmal eine SGI darauf an...
Kristian
Maschine Lubitz Koehntopp Rel.
Performance
==========================================================
DEC Alpha, OSF/1 3.2 717(*) 227 60
A3000/400, 175 MHz (Baujahr 1992/93)
DEC Alpha, OSF/1 3.2 559(*) 177 77
A3000/500, 225 MHz (Baujahr 1993/94)
Sparc 10/40, 726(*) 230 59
Solaris 2.5 (Baujahr 1994)
Sparc Ultra, 225 71 191
Solaris 2.5 (Baujahr 1996?)
486DX2/66/256 986(*) 312 44
NT3.51
AMD 586 150/? 718 227(*) 60
Linux
P90/256 549 174(*) 78
Linux
P100/0 615 195(*) 70
Linux
P120/256 449 142(*) 96
Linux
P133/256 381 120(*) 115
Linux
P133/512 372 118(*) 115
Linux
PPro200/256 214 68(*) 200
Linux
--
Kristian Koehntopp, Wassilystrasse 30, 24113 Kiel, +49 431 688897
">Streams, die immer nur das eine wollen, nicht aber gewritten werden...
Gib ihnen zwei Wochen lang morgens, mittags und abends je ein
ioctl, dann geht das weg." -- Florian Kirstein, Sven Tuerpe, de.talk.bizarre
Heiko Schlichting
kr...@schulung.netuse.de (Kristian =?ISO-8859-1?Q?K=F6hntopp?= ) writes:
>h...@caty.ol.sub.de (Holger Lubitz) writes:
>Ich habe aehnliche Untersuchungen selber einmal gemacht, aber
>mit einer anderen Szene. Ich habe die Antworten hier in der
>Gruppe und meine Werte einmal in einer Tabelle zusammengefasst.
>Dabei bedeuten:
>
>Lubitz-Bench:
> povray +W640 +H480 +A0.3 +Q9 +L/usr/local/lib/povray3/include +Ichess.pov
>
>Koehntopp-Bench:
> povray +W640 +H480 +Q9 +L$HOME/povray3/include +V +Ilaser.pov
>
>HP Workstations sehen und vielleicht setzen Stefan Stapelberg
>oder Heiko Schlichting noch einmal eine SGI darauf an...
Nichts leichter als das. Wenn ich das richtig sehe, ist die SGI schneller
als alle anderen Systeme in Deiner Liste. Bei den jeweils angegebenen
Parametern benoetigt der Rechner
48 Sekunden fuer laser.pov
und
2 Minuten 16 Sekunden fuer chess.pov.
System:
Silicon Graphics Indigo2
MIPS R10000 Prozessor
Betriebssystem IRIX 6.2
Zu bedenken ist dabei, dass ich povray nicht speziell fuer R10000 optimiert
habe, damit das Binary auch auf unseren R4400 Systemen im Cluster lauffaehig
ist. Mit entsprechenden Optionen waere also vermutlich noch etwas rauszuholen.
Heiko
harmsmci
> Ich habe povray jetzt noch einmal neu uebersetzt und dabei die Optimierungen
> fuer R10000 sowie aggressive Compiler-Optimierung eingeschaltet, in dem ich
> folgende Optionen gesetzt habe:
> -O3 -r10000 -mips4 -GCM:aggressive_speculation=ON -OPT:fast_exp=ON:fast_sqrt=ON
>
> Ausserdem habe ich mit -lfastm statt -lm gelinkt. Dadurch lassen sich
> die benoetigten Zeiten weiter verbessern - ohne nennenswerte Veraenderungen
Beim R8000 bringt der Optimierungsparameter
-OPT:roundoff=3:IEEE_arithmetic=3:fast_sqrt=ON
sehr gute Laufzeiten. (Quelle: Schulungunterlagen von SGI)
System: SGI PowerChallenge-XL mit 12 CPUs, 2Gb RAM
Werd mich hüten da zu raytracen, obwohl es verlockend ist!
Markus
Heiko Schlichting
Ich schrieb vor wenigen Tagen auf einen Artikel von Kristian Köhntopp::
>>Lubitz-Bench:
>> povray +W640 +H480 +A0.3 +Q9 +L/usr/local/lib/povray3/include +Ichess.pov
>>
>>Koehntopp-Bench:
>> povray +W640 +H480 +Q9 +L$HOME/povray3/include +V +Ilaser.pov
>
>in Deiner Liste. Bei den jeweils angegebenen Parametern benoetigt der
>Rechner
>
> 48 Sekunden fuer laser.pov
>und
> 2 Minuten 16 Sekunden fuer chess.pov.
>
>System:
> Silicon Graphics Indigo2
> MIPS R10000 Prozessor
> Betriebssystem IRIX 6.2
>
>Zu bedenken ist dabei, dass ich povray nicht speziell fuer R10000 optimiert
>habe, damit das Binary auch auf unseren R4400 Systemen im Cluster lauffaehig
>ist. Mit entsprechenden Optionen waere also vermutlich noch etwas rauszuholen.
Ich habe povray jetzt noch einmal neu uebersetzt und dabei die Optimierungen
fuer R10000 sowie aggressive Compiler-Optimierung eingeschaltet, in dem ich
folgende Optionen gesetzt habe:
-O3 -r10000 -mips4 -GCM:aggressive_speculation=ON -OPT:fast_exp=ON:fast_sqrt=ON
Ausserdem habe ich mit -lfastm statt -lm gelinkt. Dadurch lassen sich
die benoetigten Zeiten weiter verbessern - ohne nennenswerte Veraenderungen
des resultierenden Bildes:
39 Sekunden fuer laser.pov
und
1 Minute 50 Sekunden fuer chess.pov
System:
Silicon Graphics Indigo2
MIPS R10000 Prozessor, 200 MHz
Betriebssystem IRIX 6.2
Falls also nochmal eine neue Uebersicht erstellt wird, bitte die optimierten
Werte fuer den R10000 angeben. Von den bislang geposteten Werten ist die
SGI damit natuerlich immer noch der schnellste Rechner. Hat denn niemand
eine der neusten Alphas?
Heiko
Fritz Ganter
Heiko Schlichting (he...@chemie.fu-berlin.de) wrote:
: Ausserdem habe ich mit -lfastm statt -lm gelinkt. Dadurch lassen sich
: die benoetigten Zeiten weiter verbessern - ohne nennenswerte Veraenderungen
: des resultierenden Bildes:
: 39 Sekunden fuer laser.pov
: und
: 1 Minute 50 Sekunden fuer chess.pov
: System:
: Silicon Graphics Indigo2
: MIPS R10000 Prozessor, 200 MHz
: Betriebssystem IRIX 6.2
: Falls also nochmal eine neue Uebersicht erstellt wird, bitte die optimierten
: Werte fuer den R10000 angeben. Von den bislang geposteten Werten ist die
: SGI damit natuerlich immer noch der schnellste Rechner. Hat denn niemand
: eine der neusten Alphas?
Ich habe vielleicht kommende Woche eine 500MHz (i.W. fuenfhundermegahertz)
21164 Alpha zum Installieren. Wenn sichs zeitlich ausgeht, werde ich schnell
mal povray drauf installieren und laufen lassen.
--
Fritz "who dances with the Linux" Ganter. gan...@fvkma.tu-graz.ac.at
WWW: http://fvkma.tu-graz.ac.at/ganter gan...@quant-x.com
EDV-Consulting F.Ganter Grazerstr. 26a,A-8045 Graz Phone +43 664 1021621
Member of the Quant-X Group: Alpha based Systems running Linux
Florian Hars
Décade II, Primidi de Vendémiaire de l'Année 205 de la Révolution
he...@chemie.fu-berlin.de (Heiko Schlichting) writes:
>
> Falls also nochmal eine neue Uebersicht erstellt wird, bitte die optimierten
> Werte fuer den R10000 angeben. Von den bislang geposteten Werten ist die
> SGI damit natuerlich immer noch der schnellste Rechner. Hat denn niemand
> eine der neusten Alphas?
>
Also, der 386SL, den ich Donnerstag Abend auf chess.pov angesetzt habe, ist
schon bei 460818 Byte für chess.tga.
Tschüss, Florian.
--
``Im Usenet ist nämlich die Verwendung der ISO-Kürzel als Namen für
Länder-Hierarchien üblich. Die weltweite deutschsprachige Hierarchie
de.* zu nennen ist damit eine böse und arrogante Okkupierung des
Namensraums.'' - Hauke Möller in de.talk.bizarre
Florian Hars
Décade III, Duodi de Vendémiaire de l'Année 205 de la Révolution
ha...@math.uni-hamburg.de (Florian Hars) writes:
>
> Also, der 386SL, den ich Donnerstag Abend auf chess.pov angesetzt habe, ist
> schon bei 460818 Byte für chess.tga.
>
Er ist fertig!
Also: 386SL-20 mit Linux 1.2.13
Time For Parse: 0 hours 7 minutes 44.0 seconds (464 seconds)
Time For Trace: 399 hours 59 minutes 57.0 seconds (1439997 seconds)
Total Time: 400 hours 7 minutes 41.0 seconds (1440461 seconds)
Wie gut, dass ich zwischendurch im Urlaub war und das Teil nicht für
was anderes brauchte.
Mario Link
am 13.10.96 schrieb ha...@math.uni-hamburg.de:
> > Also, der 386SL, den ich Donnerstag Abend auf chess.pov
> > angesetzt habe, ist schon bei 460818 Byte für chess.tga.
> Er ist fertig!
> Also: 386SL-20 mit Linux 1.2.13
> Time For Parse: 0 hours 7 minutes 44.0 seconds (464 seconds)
> Time For Trace: 399 hours 59 minutes 57.0 seconds (1439997seconds)
> Total Time: 400 hours 7 minutes 41.0 seconds (1440461 seconds)
Herrlich :-)
Danke das Du uns auf dem "laufenden" gehalten hast.
--
ma...@homer.allcon.com
Flensburg, Germany Seltsam? Aber so steht es geschrieben.
Frank Pohl
smu...@stardust.bln.sub.org (Joerg Mertin) wrote:
>Alle Achtung... Ich waere beinahe gewillt dies auch auf meinem
>386DX33MHz + Co CPU auszuprobieren. Glaube aber nicht dass es da sooo
>lange dauert... Mal sehen. Wenn ich Platz habe dass zu installieren :)
>Waer doch was :)
DX waere ja dann mit FPU, und beim raytracen macht das schon mal die
eine oder andere Stunde aus.
Frank
Uwe Meier
In de.comp.os.linux.misc Frank Pohl <fp...@t-online.de> wrote:
: smu...@stardust.bln.sub.org (Joerg Mertin) wrote:
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
: eine oder andere Stunde aus.
Von FPU kann beim 386DX keine Rede sein. Das DX heißt nur, daß der
Prozessor 32 Bit Datenbus und Adreßbus hat, was ihn vom 386SX
unterscheidet (16 Bit externer Datenbus und 24 Bit Adreßbus). Die FPU
kam auf Wunsch als separater Chip hinzu (387DX oder 387SX).
mfg
Uwe
Karsten Trostmann
Frank Pohl <fp...@t-online.de> wrote:
: DX waere ja dann mit FPU, und beim raytracen macht das schon mal die
In der Tat. Ich habe seinerzeit meinen 386er mit einer FPU aufgeruestet.
Beschleunigte gerade den povray enorm.
Das Teil habe ich noch. Gegen Portokosten gebe ich den gern ab, also wer
ihn haben moechte -> Mail an mich. Ist ein 387/40, also fuer 40Mhz 80386
gedacht (gab es glaube ich nur von AMD)
MFG
Karsten
Florian Hars
Décade III, Sextidi de Vendémiaire de l'Année 205 de la Révolution
smu...@stardust.bln.sub.org (Joerg Mertin) writes:
> ha...@math.uni-hamburg.de (Florian Hars) writes:
> > Also: 386SL-20 mit Linux 1.2.13
> > Total Time: 400 hours 7 minutes 41.0 seconds (1440461 seconds)
>
> Alle Achtung... Ich waere beinahe gewillt dies auch auf meinem
> 386DX33MHz + Co CPU auszuprobieren. Glaube aber nicht dass es da sooo
> lange dauert... Mal sehen. Wenn ich Platz habe dass zu installieren :)
Mit Coprozessor ist das feige :-). Damit sollte es deutlich schneller
werden, da das ganze praktisch nur Fließkommarechnung ist.
Ulrich Schmitz
Hi,
> >Alle Achtung... Ich waere beinahe gewillt dies auch auf meinem
> >386DX33MHz + Co CPU auszuprobieren. Glaube aber nicht dass es da sooo
> >lange dauert... Mal sehen. Wenn ich Platz habe dass zu installieren :)
> >Waer doch was :)
>
> DX waere ja dann mit FPU, und beim raytracen macht das schon mal die
> eine oder andere Stunde aus.
Sorry, aber da hast Du wohl einen 386DX mit einem 486DX verwechselt.
Ein *386*DX hat definitiv *keinen* integrierten CoPro, den musste
man extra kaufen (vor 7 Jahren kostete der noch 1500,- DM ;-) heute
so um die 20,- DM)
cu
Ulrich
Anselm Lingnau
Im Artikel <5451k8$k...@methusalix.rz.tu-clausthal.de> schrieb
Uwe Meier <me...@iei.tu-clausthal.de>:
> Von FPU kann beim 386DX keine Rede sein. Das DX heißt nur, daß der
> Prozessor 32 Bit Datenbus und Adreßbus hat, was ihn vom 386SX
> unterscheidet (16 Bit externer Datenbus und 24 Bit Adreßbus).
Das ist wohl eine Verwechslung zwischen 386 und 486. Beim 486 ist in der
Tat die SX-Version die ohne Fliesskommateil und die DX-Version die mit
(sie haben beide einen externen 32-Bit-Bus).
Langj"ahrige Leser der c't werden sich daran erinnern, dass der als
`Zusatz' zu einem 486SX gemeinte `Fliesskommaprozessor' 487 in
Wirklichkeit ein 486DX mit einem etwas anderen Pinout war.
Anselm
--
Anselm Lingnau ......................... lin...@tm.informatik.uni-frankfurt.de
Now let me explain why this makes intuitive sense. --- Prof. Larry Wasserman
Joerg Mertin
In article <543eja$7...@kwcom.in-berlin.de>,
fp...@t-online.de (Frank Pohl) writes:
> smu...@stardust.bln.sub.org (Joerg Mertin) wrote:
>
>>Alle Achtung... Ich waere beinahe gewillt dies auch auf meinem
>>386DX33MHz + Co CPU auszuprobieren. Glaube aber nicht dass es da sooo
>>lange dauert... Mal sehen. Wenn ich Platz habe dass zu installieren :)
>>Waer doch was :)
>
> DX waere ja dann mit FPU, und beim raytracen macht das schon mal die
> eine oder andere Stunde aus.
Naja, in diesem Falle hab ich gesagt, _mit Co Cpu_ was mit FPU
gleichzusetzen ist. Nur zu deiner information, eine 386DX Cpu besitzt
keine FPU, sondern ist lediglich die nicht Kastrierte Version der
386er CPU, d.h. 32 Bit breiter Speicher Bus & CPU. Die SX CPU's waren
hatten effectiv nur einen 16 Bit Speicher bus, und mussten sie die 32
Bit adressen mit Tricks intern umrechnen.
cu
--
`*** Fatal Error: Found [MS-Windows] -> Repartitioning Disk for LiNUX...'
------------------------------------------------------------------------
| Joerg Mertin : smu...@linux.de (Home) |
| in Berlin Spandau at : jo...@pc50.zrz.tu-berlin.de |
| Stardust's LiNUX System : Data, Fax & Voice 49 30 3627345 |
| PGP 2.6.2i Key on Demand : ZyXEL Link |
------------------------------------------------------------------------
PGP Key fingerprint = C6 3F A3 12 D7 EE 60 27 88 A0 01 E6 0B 11 45 67
Joerg Mertin
In article <m2zq1lpo8w.fsf%fm5...@bielefeld.public.uni-hamburg.de>,
ha...@math.uni-hamburg.de (Florian Hars) writes:
> Décade III, Sextidi de Vendémiaire de l'Année 205 de la Révolution
>
> smu...@stardust.bln.sub.org (Joerg Mertin) writes:
> > ha...@math.uni-hamburg.de (Florian Hars) writes:
> > > Also: 386SL-20 mit Linux 1.2.13
> > > Total Time: 400 hours 7 minutes 41.0 seconds (1440461 seconds)
>
> >
> > 386DX33MHz + Co CPU auszuprobieren. Glaube aber nicht dass es da sooo
> > lange dauert... Mal sehen. Wenn ich Platz habe dass zu installieren :)
>
> werden, da das ganze praktisch nur Fließkommarechnung ist.
Gut gut... Nehme ich halb raus. Da muss ich aber den Kernel neu
kompilieren. mal sehen wann ich zeit dazu habe ;)
J Wunsch
smu...@stardust.bln.sub.org (Joerg Mertin) schrieb:
> ... Die [386] SX CPU's waren
> hatten effectiv nur einen 16 Bit Speicher bus, und mussten sie die 32
> Bit adressen mit Tricks intern umrechnen.
Was heißt ,,mit Tricks intern umrechnen''? Es war ein ganz normaler
Multiplexbus, bei dem High- und Low-Teil in zwei Phasen ausgegeben
wurden. Wie auch schon beim 8080 (8-Bit Bus und 16 bit breite
Adressen), 8088 (ebenso) oder 68000 (16-Bit Bus und 32 bit breite
Adressen). Als ,,Rechnen'' würde ich das nicht bezeichnen.
Übrigens hatte der i386sx nur 24 bit physische Adreßleitungen.
--
J"org Wunsch Unix support engineer
joerg_...@interface-business.de http://www.interface-business.de/~j
Helge Oldach
j...@ida.interface-business.de (J Wunsch) writes:
| smu...@stardust.bln.sub.org (Joerg Mertin) schrieb:
| > ... Die [386] SX CPU's waren
| > hatten effectiv nur einen 16 Bit Speicher bus, und mussten sie die 32
| > Bit adressen mit Tricks intern umrechnen.
| Was heißt ,,mit Tricks intern umrechnen''? Es war ein ganz normaler
| Multiplexbus, bei dem High- und Low-Teil in zwei Phasen ausgegeben
| wurden.
Na eben, Tricksen. So tun, als ob man breit wäre, aber in Wirklichkeit
nur halb so breit sein.
| Wie auch schon beim 8080 (8-Bit Bus und 16 bit breite Adressen), 8088
| (ebenso) oder 68000 (16-Bit Bus und 32 bit breite Adressen). Als
| ,,Rechnen'' würde ich das nicht bezeichnen.
Was ist Rechnen anderes als das geschickte Verschieben von Bits? Eben.
| Übrigens hatte der i386sx nur 24 bit physische Adreßleitungen.
Meiner *hat*.
Helge
--
3 RX+ 2a --[100 Ohm]----+ ---------- / ----------
4 TX+ 1a --[100 Ohm]--+ | | 87654321 | | 12345678 |
5 TX- 1b -------------+ | |__ __|/ |/_ /_|
6 RX- 2b ---------------+ |____| |/___|
Peter Wuddel
Am 18 Oct 1996 09:06:29 +0200 gab Anselm Lingnau seinen Senf ab:
: Im Artikel <5451k8$k...@methusalix.rz.tu-clausthal.de> schrieb
: Uwe Meier <me...@iei.tu-clausthal.de>:
:
: > Von FPU kann beim 386DX keine Rede sein. Das DX heißt nur, daß der
: > Prozessor 32 Bit Datenbus und Adreßbus hat, was ihn vom 386SX
: > unterscheidet (16 Bit externer Datenbus und 24 Bit Adreßbus).
:
: Das ist wohl eine Verwechslung zwischen 386 und 486. Beim 486 ist in der
: Tat die SX-Version die ohne Fliesskommateil und die DX-Version die mit
: (sie haben beide einen externen 32-Bit-Bus).
:
: Langj"ahrige Leser der c't werden sich daran erinnern, dass der als
: `Zusatz' zu einem 486SX gemeinte `Fliesskommaprozessor' 487 in
: Wirklichkeit ein 486DX mit einem etwas anderen Pinout war.
:
Das ist alles schoen und gut aber was hat ein 486SX damit zutun, das ein
386er kein CoPro hat ???
--
Tschuess Peter
--------------------------------------------------------------------------
Peter Wuddel jun. Fido : 2:2444/202...@fidonet.org
Hagen-Hohenlimburg / Germany email: pet...@mamut.ping.de
--------------------------------------------------------------------------