Gflop/s bei modernen haushaltsüblichen Prozessoren.

Kaufempfehlungen, Hardwaretips, Softwareprobleme, Overclocking, Technikfragen ohne Bezug zu DC.
Nachricht
Autor
Benutzeravatar
exec
Projekt-Fetischist
Projekt-Fetischist
Beiträge: 604
Registriert: 28.04.2002 10:55
Wohnort: München

Gflop/s bei modernen haushaltsüblichen Prozessoren.

#1 Ungelesener Beitrag von exec » 07.05.2003 12:20

Hallo Leute,
ich habe gestern vergeblich versucht die Anzahl der Fließkommaoperationen je Sekunde von meinem AMD XP 2400+ herauszufinden.

Angestoßen durch die 6,1 Gflop/s, welche meine PS2 schafft, möchte ich nun wissen, wieviel meine AMD-CPU schafft, kann mir einer helfen?
Bild
Aktive Projekte: Seventeen or Bust
Einstige Projekte: TSC, DF, D2OL, Seti@Home, MD@Home

Benutzeravatar
oobdoo
Rechenkraft.net-Sponsor
Rechenkraft.net-Sponsor
Beiträge: 201
Registriert: 02.01.2003 01:19
Wohnort: Bremen
Kontaktdaten:

Re: Gflop/s bei modernen haushaltsüblichen Prozessoren.

#2 Ungelesener Beitrag von oobdoo » 07.05.2003 14:18

exec hat geschrieben:Hallo Leute,
ich habe gestern vergeblich versucht die Anzahl der Fließkommaoperationen je Sekunde von meinem AMD XP 2400+ herauszufinden.

Angestoßen durch die 6,1 Gflop/s, welche meine PS2 schafft, möchte ich nun wissen, wieviel meine AMD-CPU schafft, kann mir einer helfen?
Mal so auf die schnelle...

http://www.spec.org/osg/cpu2000/results/

Bis dann

Andreas
Homepage: http://www.oobdoo.de
Projekte: Prime95, Zetagrid
SpeedMax: Zetagrid 750/~19.17 - 2000/~46,63
Speed: Prime95 2000/~0,175

Benutzeravatar
exec
Projekt-Fetischist
Projekt-Fetischist
Beiträge: 604
Registriert: 28.04.2002 10:55
Wohnort: München

#3 Ungelesener Beitrag von exec » 07.05.2003 17:07

Danke für den Link, trotztdem kann ich der Webseite keine Angaben bzgl. der Gflop/s entnehmen.
Bild
Aktive Projekte: Seventeen or Bust
Einstige Projekte: TSC, DF, D2OL, Seti@Home, MD@Home

Benutzeravatar
oobdoo
Rechenkraft.net-Sponsor
Rechenkraft.net-Sponsor
Beiträge: 201
Registriert: 02.01.2003 01:19
Wohnort: Bremen
Kontaktdaten:

#4 Ungelesener Beitrag von oobdoo » 07.05.2003 17:39

exec hat geschrieben:Danke für den Link, trotztdem kann ich der Webseite keine Angaben bzgl. der Gflop/s entnehmen.
Da steht doch SPECfp2000. SPEC ist der Test, fp steht für FloatingPoint und die Zahl für das Jahr der Testerstellung.

Der Test
http://www.spec.org/osg/cpu2000/results/cfp2000.html

Asus A7M266-D Motherboard, AMD Athlon (TM) MP 2400+
http://www.spec.org/osg/cpu2000/results ... 01835.html

Epox 8KHA+ Motherboard, AMD Athlon (TM) XP 2400+
http://www.spec.org/osg/cpu2000/results ... 01549.html

Bin mir ziemlich sicher, das es genau das ist was Du suchst. Kann mich aber auch irren, schließlich hatte ich heute Frühschicht und da bin ich nur ein halber Mensch. :lol:

Bis dann

Andreas
Homepage: http://www.oobdoo.de
Projekte: Prime95, Zetagrid
SpeedMax: Zetagrid 750/~19.17 - 2000/~46,63
Speed: Prime95 2000/~0,175

Benutzeravatar
Wurmi
Rechenkraft.net-Sponsor
Rechenkraft.net-Sponsor
Beiträge: 314
Registriert: 09.07.2002 22:44
Wohnort: Stuttgart

#5 Ungelesener Beitrag von Wurmi » 07.05.2003 23:31

Man kann auch (wie bei der PS/2) "Pseudo-Flops" angeben: Die Verktoreinheiten der aktuellen x86 Prozessoren bringen 2 64-Bit Flops / 2 Takte bzw. 4 32-Bit Flops / 2 Takte. (Angaben ohne Garantie :angel2:). Ich bin mir nicht sicher, ob SSE2 auch MULAlDD hat, dann könnte man kühn von 8 Flops / 2 Takten fabulieren. Bei den 2,0 echen GHz des XP2400+ wären das also 8GFlops. Heißes Eisen :lol:.

Grüßle, Wurmi :Fade-color.
Recently, I tweaked the universe to appear even weirder. Now, e^(i*pi) equals -1. Ain't that cool?

Benutzeravatar
exec
Projekt-Fetischist
Projekt-Fetischist
Beiträge: 604
Registriert: 28.04.2002 10:55
Wohnort: München

#6 Ungelesener Beitrag von exec » 08.05.2003 06:37

Also ich habe Angaben von einer amerikanischen Seite, dass der AMD XP 1800+ in etwa 1867 Gflop/s.

Nun weiße ich nicht ob ich das mit 8 Gflop/s glauben soll.
Tja AMD hat auch keine Angaben auf seiner Webseite.
Bild
Aktive Projekte: Seventeen or Bust
Einstige Projekte: TSC, DF, D2OL, Seti@Home, MD@Home

Benutzeravatar
Wurmi
Rechenkraft.net-Sponsor
Rechenkraft.net-Sponsor
Beiträge: 314
Registriert: 09.07.2002 22:44
Wohnort: Stuttgart

#7 Ungelesener Beitrag von Wurmi » 08.05.2003 21:28

exec hat geschrieben:... AMD XP 1800+ in etwa 1867 Gflop/s.
Ich nehme an, da stand 1.867 GFlops, wobei hier der Punkt dem deutschen Komma entspricht. Zum Vergleich: für die o.g. 1,8 TFlops waren seinerzeit 9000 PentiumPro200 nötig.

Grüßle, Wurmi :Fade-color.
Recently, I tweaked the universe to appear even weirder. Now, e^(i*pi) equals -1. Ain't that cool?

Benutzeravatar
exec
Projekt-Fetischist
Projekt-Fetischist
Beiträge: 604
Registriert: 28.04.2002 10:55
Wohnort: München

#8 Ungelesener Beitrag von exec » 09.05.2003 12:17

Trotztdem bin ich verwirrt, von welchen Aspekten hängt der FPU-Wert ab?
Bild
Aktive Projekte: Seventeen or Bust
Einstige Projekte: TSC, DF, D2OL, Seti@Home, MD@Home

Benutzeravatar
Wurmi
Rechenkraft.net-Sponsor
Rechenkraft.net-Sponsor
Beiträge: 314
Registriert: 09.07.2002 22:44
Wohnort: Stuttgart

#9 Ungelesener Beitrag von Wurmi » 13.05.2003 23:42

exec hat geschrieben:Trotztdem bin ich verwirrt, von welchen Aspekten hängt der FPU-Wert ab?
Nun, dann will ich mal mein gesammeltes Halbwissen zum Besten geben. Hoffentlich wird es nicht zu peinlich :oops:. Das Spannende steht sowieso erst am Ende ;).

1. Urschleim 8). Die allermeisten Prozessoren arbeiten Befehle (also z.B. "addiere x und y") getakted ab. Wieviele dieser immer gleichlangen Takte je Sekunde durchgeführt werden, gibt die Taktfrequenz an (z.B. 2 Milliarden / Sekunde = 2 GHz). In 1. Näherung liegt die Anzahl der Operationen in der gleichen Größenordung wie die Taktfrequenz.

2. Verfeinerung. Eine CPU hat mehrere Ausführungseinheiten (z.B. welche für den Speicherzugriff, für Sprünge, zum Rechnen mit Integern, die FPU usw.), manche Arten sogar mehrfach (z.B. 2 FPUs). Je nachdem, welche Befehle gerade anstehen, kann der Prozessor die so verteilen, daß mehrere Befehle gleichzeitig abgearbeitet werden können. Wenn alles gut läuft, kommt man damit im Schnitt auf 2 Befehle je Takt bei typischen Programmen.

2a. Spezialfall. Für bestimmte Aufgaben müssen die immer gleichen, einfachen Operationen auf viiiieeele Daten angewendet werden (Bildverarbeitung hat z.B. viele Pixel durchzukauen). Dazu packt man dann eben viele (4, 8 oder 16) einfache Rechenwerke auf den Chip und steuert diese alle gleichzeitig mit einem einzigen Befehl an. Diese Technik verbirgt sich hinter MMX, SSE, SSE2, AltiVec, 3Dnow! etc. Man erreicht damit dann 4, 8 oder 16 Operationen pro Takt extra. Theoretisch :roll:!

2b. Spitzfindigkeiten. Einige Rechenwerke können einen Taktschritt noch weiter unterteilen und so 2 Operationen pro Takt durchführen. Das spart im wesentlichen Platz und ändert wenig an den folgenden Beschränkungen.

3. Beschränkungen. Die Parallelisierung kann leider nicht beliebig weit getrieben werden, d.h. es ist schwer, überhaupt die erwähnten 2 Operationen je Takt als Durchschnitt über längere Zeit zu erreichen. Die vier Hauptgründe:

* Der Speicherdurchsatz ist so gering, daß nur alle paar Takte mal eine neue Zahl in der CPU ankommt. Z.B. 2xPC3200 genügen nur für 800 Mio Floatingpointwerte je Sekunde - also nur eine Zahl alle 3 bis 4 Takte. In der Zwischenzeit muß man mit dem auskommen, was im Cache bereits vorhanden ist.

* Die Auswirkungen der Speicherlatenz sind meist viel gravierender: Der Zugriff auf eine zufällige Speicherposition (alles, was nicht im Cache ist) dauert einige hundert Takte (660 beim PIV-3.06). Selbst wenn das nur in 1% der Fall wäre (typisch sind eher 5%), dauert jeder Speicherzugriff allein hierdurch 6 Takte länger als ohnehin schon. Um die 2 Operationen pro Takt halten zu können, muß man also in dieser Zeit 12 andere Befehle haben, die man ausführen kann.

* Abhängigkeiten im Code: Programme enthalten Abfragen ("Ende erreicht?"), deren Ergebniss bestimmt, wie weiter gemacht wird, sowie Abhängigkeiten in den Daten (z.B. bei a/(b+c) ). In der Folge muß man also warten, bis das jeweilige Ergebnis vorliegt, bevor man die nächsten Befehle abarbeiten kann. Durch einen Trick ("Spekulative Ausführung") kann man das zwar entschärfen: führe einfach beide Alternativen aus und verwerfe die, die sich als falsch herausstellt. Aber so arbeiten immer mehr Einheiten für die Tonne, so daß die effektiv ausgeführten Operationen / Takt kaum noch ansteigen.

* Programmcode braucht auch Speicher. Versucht man, viele Befehle gleichzeitig auszuführen, muß man einen entsprechenen Speicherdurchsatz haben. Probleme siehe oben. Das ist unter anderem das große Problem der Intel Itanium-Reihe: durch die verschwenderische Codierung der Befehle und viele erfolglose Ausführungsversuche sinkt die durchschnittliche Abarbeitungsgeschwindigkeit bis auf 0,2 Befehle / Takt.

4. Sonderfall: Vektorrechner. Oft zeichnen sich technische Problemstellungen durch gute Vorhersagbarkeit des Programmflusses aus (z.B. Invertierung einer 1000x1000 Matrix), weil immer gleiche Operationen auf einem großen Datenstrom ausgeführt werden. Ein Vektorrechner hat eine spezielle Architektur, die es erlaubt, mit einem Befehl hunderte Zahlen am Stück "durchzuschleusen". Gepaart mit einer extremem RAM Bandbreite werden so viele der o.g. Probleme umgangen. Allerdings sind solche Rechner für andere Problemstellungen nur schwer zu gebrauchen. Mit SSE(2) etc. bieten moderne Prozessoren in viel kleinerem Maßstab ähnliche Techniken.

5. FPU. Im Grundsatz gilt: FPUs müssen so rechnen, wie wir es in der Schule beim schriftlichen Rechnen gelernt haben. Damit das in erträglicher Zeit passiert, sind einige Funktionen "hart verdrahtet" und können parallel verwendet werden. Solche elementaren Funktionen werden durch 2 Kennzahlen beschrieben:

* Latenz: wie lange dauert es, bis das Ergebnis vorliegt? Diese Zahl ist wichtig, wenn man das Ergebnis für die Weiterverarbeitung braucht.
* Durchsatz: nach wievielen Takten können neue Operanden angenommen werden. Bei guten Architekturen ist Durchsatz < Latenz, manchmal sogar nur 1 Takt. Dann rauschen die Zahlen wie bei einem Wasserfall durch das Rechenwerk. Dieser Wert limitiert das Maximum an FLOPs, die die jeweilige Einheit leisten kann.

Besonders heikel ist die Division. Hier kann die Latenz schon mal 70 Takte betragen, da nach jedem Bit entschieden werden muß, wie man weitermacht. Nur sehr clevere Architekturen schaffen hier bessere Werte bzw. einen guten Durchsatz (der FDIV-Bug des Pentiums lag genau in einer dieser Optimierungen). Darum vermeided man Divisionen und setzt eher auf Näherungsverfahren und Multiplikationen.

Letztere werden vom Herstück einer FPU, dem / den FMAC(s), realisiert. Diese Schaltungen berechnen a*b+c mit einer gegebenen Anzahl von Bits (z.B. 16 oder 32). Längere Zahlen lassen sich durch Kaskadierung der FMACs verarbeiten, was die Latenz entsprechend erhöht. Ziel ist, FMACs mit einer Latenz von 5 Takten oder weniger und einem Durchsatz von 1 Operation / Takt zu bauen. Da jedoch viele Gatter zu durchlaufen sind, können große (64 Bit) FMACs die Taktfrequenz beschränken (Schaltzeiten reichen sonst nicht). Es kann also Sinn machen, 4 kleine FMACs einzubauen (doppelte Latenz) und im Gegenzug 70% mehr Takt zu ermöglichen.

6. Zusammenfassung. Eine hohe theoretische Rechenleistung ist einfach zu erhalten, indem man möglichst "breite" Vektoreinheiten einbaut (MMX aufwärts). Das Problem liegt in der Bereitstellung der Daten (Speicherbandbreite) und der Steuerung des Ablaufes (ebenfalls Code, der abgearbeitet werden muß) sowie inherenten Beschränkungen (wenn eine Berechnungsreihenfolge eingehalten werden muß). Schafft man GFLOPs = GHz, ist das schon ein sehr guter Wert.

Mein längstes Posting bisher!

Grüßle, Wurmi :Fade-color.
Recently, I tweaked the universe to appear even weirder. Now, e^(i*pi) equals -1. Ain't that cool?

Benutzeravatar
Michael H.W. Weber
Vereinsvorstand
Vereinsvorstand
Beiträge: 20282
Registriert: 07.01.2002 01:00
Wohnort: Marpurk
Kontaktdaten:

#10 Ungelesener Beitrag von Michael H.W. Weber » 14.05.2003 11:17

Jetzt bin ich erleuchtet! :D

Michael.
Fördern, kooperieren und konstruieren statt fordern, konkurrieren und konsumieren.

http://signature.statseb.fr I: Kaputte Seite A
http://signature.statseb.fr II: Kaputte Seite B

Bild Bild Bild

Benutzeravatar
exec
Projekt-Fetischist
Projekt-Fetischist
Beiträge: 604
Registriert: 28.04.2002 10:55
Wohnort: München

#11 Ungelesener Beitrag von exec » 14.05.2003 12:35

Danke für die Umfassende Beschreibung
Bild
Aktive Projekte: Seventeen or Bust
Einstige Projekte: TSC, DF, D2OL, Seti@Home, MD@Home

masel

#12 Ungelesener Beitrag von masel » 15.05.2003 09:17

gutes halbwissen ;-)

wer noch mehr wissen will kann sich mal folgendes durchlesen.

Antworten

Zurück zu „Hardware, Software, Technik, Betriebssysteme“