Wieviel Ghz sind ein Teraflop

Elvis

Commander
Mitglied seit
03.08.2003
Beiträge
182
Renomée
0
Standort
Planet Earth
hi

kürzlich hab ich irgentwo was von teraflops gelesen und möchte jetzt nur interessehalber mal wissen wieviel Gigaherz des sind

mfg elvis
 
Wenn ich richtig informiert bin, kannst du nicht sagen:

1Ghz=0,2 Teraflops
2Ghz=0,4 Teraflops
3Ghz=0,6 Teraflops
...

Eine genaue Definition findest du hier.

mfG

Parad0x
 
Die Frage is völlig falsch formuliert. Man kann den Wert Gigahertz nicht direkt auf die Floating Point Leistung eines Prozessors übertragen (Flop= Floatingpoint Operation).

Es kommt immer auf die Prozessorarchtitektur an wieviel Mega/Giga/Teraflops eine CPU leistet. Ein Athlon XP 2400+ mit 2Ghz schafft ca. 3 Gigaflops. Da kannst du dann ja selber ausrechnen mit wieviel Ghz diese CPU takten müsste um auf 1000 Gigaflops (1 Teraflop)zu kommen... ;)
 
... es ist sogar noch viel gemeiner denn du brauchst neben einer entsprechend schnellen CPU auch noch ein passendes Memory-Subsystem. Darum würde selbst ein "700 GHz Athlon XP" noch lange kein Tera-Flop leisten.
 
Für den eigentlichen Flop reicht der Cache, da braucht man keinen Speicher (Flop -> Floatpoint operation /s).

Aber bei solchen Fragen bin ich immer wieder versucht meinen X5 zu benchen und den Wert auf 1TFlop umzurechnen. Wer wettet, dass was über 20Ghz rauskommt? *buck*
 
sorry 4 spam aber ein teraflop kann eigentlich nur von intel sein oda *lol* !
mfg
 
@intel_hasser

> Für den eigentlichen Flop reicht der Cache, da braucht man keinen Speicher (Flop -> Floatpoint operation /s).

Welchen Sinn würde solch eine Angabe haben? Praktisch keinen!

Industrieüblich ist die Angabe von [M/T]FLOP Werten die mit Linpack gebencht wurden. Linpack arbeitet aber mit variablen Matrixgrößen und z.B. eine 1800x1800 Matrix passt nun mal nicht in den Cache heutiger Maschinen.
 
@Henry

Ok, schau dir mal den Sandra Bench an ;)

... wo selbst ein Duron 2.4ghz einen Barton 2.35ghz plattmacht *lol*
 
Original geschrieben von I²K
Wieviel PS braucht man für 100 km/h?


danke das du mir den Ausdruck dieser "wackeligen" Formulierung der Flops-messung von Elvis vorweg nimmst ;) :]
 
Klar ist, dass die TFlops von vielen Faktoren abhängen:
- Programmgröße (bei großen natürlich auch das Memeory Subsystem)
- Prozessorkern (Anzahl und Leitungsfähigkeit der FP Pipelines)
- Genauigkeit (32, 64, 80 Bit)(SSE, SSE2, x87)
- Compiler (Effizienz)
 
Original geschrieben von intel_hasser
@Henry

Ok, schau dir mal den Sandra Bench an ;)

... wo selbst ein Duron 2.4ghz einen Barton 2.35ghz plattmacht *lol*

Der Sandra cpu bench hat imo genau 0 Aussagekraft, wenns um die Leistungsfähigkeit einer Cpu geht. Wenn die Sandra Autoren es wollten, hätte auch eine via cpu die gleiche pro-hertz Leistung wie ein fx64.

Bei älteren Sandra Versionen hatte der pentium3 bei beiden cpu Tests die gleiche pro-hertz Leistung wie der Celeron auf p3 Basis. Ebenso war es beim P4/willi/nw und dem cleron mit p4 Kern. Ebenso beim Duron/Athlonxp.(Da kann ja irgendwo was nicht stimmen, oder lieg ich damit daneben?) Obs bei der neusten immer noch so ist, weiß ich nicht, aber ich werd mir den Müll nicht extra installieren um es herauszufinden.
 
Zuletzt bearbeitet:
Das ist schon richtig, aber der bench arbeitet 100%ig wie er soll.

FLOP ist eine Angabe für die reine Rechenleistung einer CPU - andere Faktoren (wie etwa Speicheranbindung) spielen dabei keine Rolle (oder sollte keine Rolle spielen).
Wenn irgend ein Bench einer CPU 4GFLOP beschert, und die CPU schafft unter den günstigsten Bedingungen 5GFLOP/s ist das Ergebnis des Benchs eben falsch - die CPU schafft mehr.

Klar, das der bench net aussagekräftig ist. Aber so ist das nunmal mit Benchmarks. Es gibt extrem reale benches (zb. Photoshop), es gibt abstrakte benches (zb. 3D Murks) und es gibt die Benches die nur auf einen einzelnen ganz bestimmten Teilbereich eingehen (FLOPs, Dry/Whetstones, Dreiecksdurchsatz der Graka, Texeldurchsatz der Graka, Speicherbandbreite etc...).

Von der letzten Kategorie gibt es wohl so viele weil sich das am einfachsten benchen lässt. Und weil man am wenigsten falsch machen kann - nimm bei den anderen Benches eine ungünstige Verteilung der Anforderung und du bist sofort der Buhmann, weil vielleicht der P4 schneller läuft als der Athlon (oder umgekehrt, was aber seltener vorkommt).
Und da gibts gleich das nächste Problem - auf den P4 zu optimieren geht einfach, da ist sehr oft ziemlich viel Potenzial (der P4 mags gern vorverdaut ;)), dagegen nimmt der Athlon was kommt (ist also weniger Optimierungspotential).
Also wird man einen benchmark, wenn man diesen optimiert (was man ja in der Regel schon tut) wohl eher richtung P4 optimieren -> Buhmann, auch wenns vielleicht garnet so gemacht wurde.


Und dann steht natürlich bei den etwas angewandteren Benches wieder der Sinn im Vordergrund - was bring mir Quake3 mit 600fps? Die Anforderungen die Quake bei derart abnormen FPS Zahlen stellt entsprechen schon lange nicht mehr dem was gebraucht wird. Und so kommt es bei Quake auch jetzt noch zb. auf reinen Dreiecksdurchsatz an, anstatt auf zb. verbesserte Shader.

Alte Leistungsmerkmale werden unwichtig und neue Features sind auf einmal Hauptleistungsmerkmal - so zersägt meine Matrox Millenium2 auch jetzt noch in Standart-2D jede aktuelle Graka. Alte Spiele die auf dieses Merkmal angewiesen sind freuen sich, Quake3 wäre das zb. völlig egal.




Und desswegen gibt es mehr extrem-abstrakte Benches, wie eben FLOP/s einer ist.
Der Vorteil davon ist auch, dass man weis was man erreichen kann.
Wenn du eine wissenschaftliche Simulation laufen lassen willst wirst du nicht erst das Programm für 2 verschiedene Plattformen bis zum bitteren Ende optimieren um dann zu sehen, dass die eine Architektur schneller ist.
Wenn der Algorithmus eben 80% FPU und 20% Speicherbandbreite braucht (mal grob gesagt, die genauen Zeiten variieren ja von Sys zu Sys) wird man die CPU mit der besseren Rechenleistung -> höheren FLOP-Zahl nehmen.

Korrigiere mich, wenn ich da falsch liege ;)
 
Original geschrieben von intel_hasser
Das ist schon richtig, aber der bench arbeitet 100%ig wie er soll.

FLOP ist eine Angabe für die reine Rechenleistung einer CPU - andere Faktoren (wie etwa Speicheranbindung) spielen dabei keine Rolle (oder sollte keine Rolle spielen).
Wenn irgend ein Bench einer CPU 4GFLOP beschert, und die CPU schafft unter den günstigsten Bedingungen 5GFLOP/s ist das Ergebnis des Benchs eben falsch - die CPU schafft mehr.

Klar, das der bench net aussagekräftig ist. Aber so ist das nunmal mit Benchmarks. Es gibt extrem reale benches (zb. Photoshop), es gibt abstrakte benches (zb. 3D Murks) und es gibt die Benches die nur auf einen einzelnen ganz bestimmten Teilbereich eingehen (FLOPs, Dry/Whetstones, Dreiecksdurchsatz der Graka, Texeldurchsatz der Graka, Speicherbandbreite etc...).

Von der letzten Kategorie gibt es wohl so viele weil sich das am einfachsten benchen lässt. Und weil man am wenigsten falsch machen kann - nimm bei den anderen Benches eine ungünstige Verteilung der Anforderung und du bist sofort der Buhmann, weil vielleicht der P4 schneller läuft als der Athlon (oder umgekehrt, was aber seltener vorkommt).
Und da gibts gleich das nächste Problem - auf den P4 zu optimieren geht einfach, da ist sehr oft ziemlich viel Potenzial (der P4 mags gern vorverdaut ;)), dagegen nimmt der Athlon was kommt (ist also weniger Optimierungspotential).
Also wird man einen benchmark, wenn man diesen optimiert (was man ja in der Regel schon tut) wohl eher richtung P4 optimieren -> Buhmann, auch wenns vielleicht garnet so gemacht wurde.


Und dann steht natürlich bei den etwas angewandteren Benches wieder der Sinn im Vordergrund - was bring mir Quake3 mit 600fps? Die Anforderungen die Quake bei derart abnormen FPS Zahlen stellt entsprechen schon lange nicht mehr dem was gebraucht wird. Und so kommt es bei Quake auch jetzt noch zb. auf reinen Dreiecksdurchsatz an, anstatt auf zb. verbesserte Shader.

Alte Leistungsmerkmale werden unwichtig und neue Features sind auf einmal Hauptleistungsmerkmal - so zersägt meine Matrox Millenium2 auch jetzt noch in Standart-2D jede aktuelle Graka. Alte Spiele die auf dieses Merkmal angewiesen sind freuen sich, Quake3 wäre das zb. völlig egal.




Und desswegen gibt es mehr extrem-abstrakte Benches, wie eben FLOP/s einer ist.
Der Vorteil davon ist auch, dass man weis was man erreichen kann.
Wenn du eine wissenschaftliche Simulation laufen lassen willst wirst du nicht erst das Programm für 2 verschiedene Plattformen bis zum bitteren Ende optimieren um dann zu sehen, dass die eine Architektur schneller ist.
Wenn der Algorithmus eben 80% FPU und 20% Speicherbandbreite braucht (mal grob gesagt, die genauen Zeiten variieren ja von Sys zu Sys) wird man die CPU mit der besseren Rechenleistung -> höheren FLOP-Zahl nehmen.

Korrigiere mich, wenn ich da falsch liege ;)

Harhar, Ich wäre gerne in der Lage Dich zu korrigieren, wenn Du falsch liegen würdest.
 
@intel_hasser

> FLOP ist eine Angabe für die reine Rechenleistung einer CPU

Ich kenn das etwas anders: FLOPs ist eine Kenngröße der Rechenleistung, aber mit allem was dazugehört -- eben die Durchschnittliche Anzahl der Flieskommaoperationen die eine CPU in einer Sekunde erledigen kann. D.h. incl. Instruction Overhead und dem Memoryzugriff und Compilerabhängigkeiten.

Wenn du auf das theorethische Maximum der CPU raus willst sagt das doch überhaupt nichts aus.

Bei optimalem Code käme ein P IV auf 3 * Taktfrequenz FLOPs (Zwei Operationen/Cycle in den SSE2 Einheiten und eine/Cycle in der FPU). D.h. Ein 3.2 GHz P IV käme auf 9.6 GFLOPS. So nun zeig mir mal eine reale Anwednug die auch nur Entfernt an diesen Wert ran kommt.

> - andere Faktoren (wie etwa Speicheranbindung) spielen dabei keine Rolle (oder sollte keine Rolle spielen).

Für was sollte das gut sein? Leute, die sich für Systeme im TFLOP Bereich interessieren benötigen aussagekräftige Zahlen und keine theoretischen Phantasiewerte. Da in den Bereichen die numerischen Probleme einen entsprechenden Datenumfang haben kann man z.B. das Speicherinterface nicht vernachlässigen. Man trägt dem Rechnung indem die Kenngrösse FLOP eben bei einer bekannten und möglichst äquivaltenten Problemgröße(n) mit einem Benchmark (Linpack) ermittelt wird.

> Wenn du eine wissenschaftliche Simulation laufen lassen willst wirst du nicht erst das Programm für 2 verschiedene Plattformen bis zum bitteren Ende optimieren um dann zu sehen, dass die eine Architektur schneller ist.

Eben darum braucht man FLOP Angaben die auch tatsächlich ERREICHBAR sind.

> Wenn der Algorithmus eben 80% FPU und 20% Speicherbandbreite braucht

Wie willst du diese Anteile so einfach ermitteln?

>(mal grob gesagt, die genauen Zeiten variieren ja von Sys zu Sys)

Ja, denn dahinter steht u.A. die Architektur und die Taktfrequenz. Mehr noch je nach Architektur gibt es auch noch andere Abhängigkeiten!

Beispiel P IV: Eine Gleitpunkt Addition hat in der FPU eine Latenz von 5 Cycles, ein Multiplikation von 7 Cycles. D.h. ein "normales" Programm, dass zwei Zahlen Addiert und die Ergebnisse dann Multipliziert (=3 Floating Point Operationen) benötigt dafür 13 Cycles.

1: Issue FADD R0, R1 (1)
2: Issue FADD R2, R3 (2)
3: Issue FMUL R0, R2 (3)
4:
5: (1) Completes
6: (2) Completes
7: [Mul Stage 1]
8: [Mul Stage 2]
9: [Mul Stage 3]
10: [Mul Stage 4]
11: [Mul Stage 5]
12: [Mul Stage 6]
13: (3) Completes: Final Result

... Wie du siehst erreicht dieses Programmstück nur einen Bruchteil der theoretischen FLOP Leistung (Gerade mal 1/13). BTW. Die zwei FADDs durch SSE2 zu ersetzen bringt auch nix weil dort die FADD Latenz 6 Cycle ist und man zudem das Ergebnis umschaufeln müste (bzw. eine FMUL Latenz von 8 Cyclen hätte).

> wird man die CPU mit der besseren Rechenleistung -> höheren FLOP-Zahl nehmen.

Das wird man fast immer [so die FLOPs auch korekt ermittelt wurden ;-]
 
Dein kleines Beispiel liefert nicht 1/13 der max. Leistung, sondern 3/13 - die Addition ist auch eine Fließkommaoperation ;)

Wenn du nun zb. sowas hier machst

E=C+5
A=C+3
F=E*3
B=D+5
A=A*B

Teil1:
A=C+3
B=D+5
A=A*B

Teil2:
E=C+5
F=E*3

Wird dir die Superskalare Architektur helfend unter die Arme greifen und den Code parallel ausführen, dann braucht zwar der eine Teil trotzdem X Takte, aber der andere Teil wird eben praktisch parallel ausgeführt, wodurch beide Operationen zusammen nicht so lange brauchen wie beide Operationen einzeln hintereinander.

HT ist auch nicht viel anders als die Superskalare Architektur (die mit dem 5x86 bei x86 ein geführt wurde), hier sorgt man mit 2 parallelen Threads nur dafür, dass die Daten nicht so oft voneinander abhängen (ein paralleler Thread will vielleicht nur Integer-Operationen, die dann völlig unabhängig von den FPU Operationen ausgeführt werden können).


Du kannst die Leistung einer CPU ebensowenig mit einem kleinen Codefetzen testen, wie mit der reinen Rechenleistung der FPU.
Da spielen Faktoren wie Pipelining, die Superskalare Architektur und eben HT zu stark mit ein. Und bei dem kleinen Codefetzen lässt du genau das außer Acht. Während die FPU multipliziert könnte ein anderer Codefetzen Addieren (dazu brauchts nichtmal HT) und umgekehrt. Und genau das kann in dem kleinen Beispiel eben nicht passieren, da du keinen anderen Code (der aber sicherlich parallel ausgeführt werden würde, dank Superskalarer A.) betrachtest.




Ein Taschenrechner ist übrigens auch ein schönes Beispiel. Der schafft auch einige FLOPs. Der schafft sogar garnet mal so wenige FLOPs.
Aber wenn du mich als Benutzer mit einbeziehst kommt das nicht über 1 FLOP/s, und für den Linepack Bench bräuchte ich auch etwas länger.

Die CPU im Taschenrechner schafft aber einige FLOP/s (sowas lässt sich zwar verdammt schwer schätzen, aber die kleinen Schulrechner dürften so ca. 50FLOP/s packen - wenn 63! etwas länger dauert wird sicherlich einfach draufmultipliziert und da brauchen die meißten so ca. 1.5sek).
 
Also, Ihr streitet ein wenig um des Kaisers Bart hier. ;)

Beides ist natürlich richtig. Das Eine sind die theoretisch aufgrund der Prozessor-Architektur maximal möglichen Fießkommaoperationen pro Sekunde (eben Flops), das andere real erreichbare Flops. Flops sind natürlich beides!

Allerdings muss man sagen, dass die Top500 der Supercomputer nach den realen Flops mittels Linpack ermittelt werden. Wieviel der EarthSimulator in Japan theoretisch an Flops leisten könnte, wenn er nicht auch mal auf den Speicher warten müsste, interessiert dabei nicht.

Gruß
larsbo
 
Zuletzt bearbeitet:
@larsbro

Full Ack!

Mir gehts nur daraum Aufzuzeigen, das ebem eine theorethische FLOPs niemanden was nützen. Die gebencheten (=real erreichbare FLOPs) hingegen schon, aber da spielt das Memoryinterface, die CPU Architektur, Datenabhängigkeiten, Compilergüte usw. eine grosse Rolle.

@Intelhasser

> Dein kleines Beispiel liefert nicht 1/13 der max. Leistung, sondern 3/13 - die Addition ist auch eine Fließkommaoperation

Nope, ich hatte schon richtig Gerechnet, denn wenn du pro Cycle 3 FP Operationen schedulen kannst (2xSSE2 FP, 1xFPU) kommst du im best case bei 13 Cycles auf 3*13 Operationen. D.h. im betrachten Fall sind die realen FLOPs nur 1/13 der theorethisch erreichbaren :-)

> Wenn du nun zb. sowas hier machst [snnip]

Sowas nennt man instruction reordering. Das hat erst mal nichts mit Superscalar zu tun. Genau das ist ein Trick um die reale Rechenleistung eher in Richtung Peakperformacne zu bekommen.

> Wird dir die Superskalare Architektur helfend unter die Arme greifen und den Code parallel ausführen, dann braucht zwar der eine Teil trotzdem X Takte, aber der andere Teil wird eben praktisch parallel ausgeführt, wodurch beide Operationen zusammen nicht so lange brauchen wie beide Operationen einzeln hintereinander.

Jup, das ist in meinem Beispiel ja berücksichtigt, sonnst gäbe es das Ergebnis erst nach 17 Cycles.


> HT ist auch nicht viel anders als die Superskalare Architektur (die mit dem 5x86 bei x86 ein geführt wurde), hier sorgt man mit 2 parallelen Threads nur dafür, dass die Daten nicht so oft voneinander abhängen (ein paralleler Thread will vielleicht nur Integer-Operationen, die dann völlig unabhängig von den FPU Operationen ausgeführt werden können).

Superscalare Architektur heist erst mal nur das der entsprechende [Uni]Prozessor mehr als eine Instruction pro Cycle ausführen kann. Wie das passiert ist eine technische Frage.

Hyperthreading hat primär die Absicht möglichst alle Ausführungseinheiten in jedem Takt zu nutzen -- wieviele Instructions dafür "in flight" sind ist davon unabhängig.

> Du kannst die Leistung einer CPU ebensowenig mit einem kleinen Codefetzen testen, wie mit der reinen Rechenleistung der FPU. Da spielen Faktoren wie Pipelining, die Superskalare Architektur und eben HT zu stark mit ein. Und bei dem kleinen Codefetzen lässt du genau das außer Acht. Während die FPU multipliziert könnte ein anderer Codefetzen Addieren (dazu brauchts nichtmal HT) und umgekehrt. Und genau das kann in dem kleinen Beispiel eben nicht passieren, da du keinen anderen Code (der aber sicherlich parallel ausgeführt werden würde, dank Superskalarer A.) betrachtest.

Genau da sagst du nichts anderes als, dass die peak FLOP Leistung einer CPU nicht Vergleichbar ist ohne genaue Hintergründe zu kennen. D.h. die Zahl selber besizt in dem Fall keine Aussagekraft -- warum willst du diese dann als Leistungsindikator angeben?
 
Ich hab doch selber gesagt, dass dieser Wert für den Endanwender keinen Sinn macht?!?

Oder schreibst du dir als Endanwender mathematische Simulationen und optimierst die auf die schnellere Architektur? Wohl eher nicht ;)

Genauso blöd wäre es einen Itanium für Datenbanksysteme zu nehmen. Das sieht man an der Interger Leistung, die relativ bescheiden ist. Die FPU spielt bei Datenbanken weniger/überhauptnet die Rolle, und das ist des Itaniums Stärke.


Mit den Techniken meine ich im genauen das hier: Superskalare Architektur, HT und Out of Order Execution, die die Wirkung der Superskalaren Architektur nochmal deutlich verbessert, da auch Abhängigkeiten umgangen werden können.

In der C't war mal wieder ein schöner Wert - der P4 arbeitet nicht nur 3 Instruktionen parallel ab, bzw. vertauscht deren Reihenfolge, sondern der nimmt sich gleich mehr als 100 (!) vor. Und dein Beispiel hat wohl keine 100 x86 Instruktionen, daraus ergeben sich natürlich extrem viel mehr Möglichkeiten nicht belastete Einheiten doch auszulasten.
100 Anweisungen - in der Zeit ist man mathematisch schon einige Probleme weiter im Code. Und irgendwo hat man immer andere Anweisungen, die auch andere Bereiche belasten. Sei es das inkrementieren eines Counters.



Aber im Endeffekt stimme ich larsbo auch zu. Unterscheiden wir einfach in die theoretischen Flops (bzw. Peak Leistung) und die praktischen Flops ;)
Letztere sind allgemeiner gültig, erstere für wissenschaftliche Simulationen wichtiger.
 
@Intel_Hasser

> Ich hab doch selber gesagt, dass dieser Wert für den Endanwender keinen Sinn macht?!?

Für wen macht die Angabe überhaupt Sinn?

> Oder schreibst du dir als Endanwender mathematische Simulationen und optimierst die auf die schnellere Architektur? Wohl eher nicht

Leute die TFLOPs benötigen wählen die optimale Architektur für ihr Problem -- Und ja die schreiben dann auch ihre eigenen Anwendungen dafür!

> Genauso blöd wäre es einen Itanium für Datenbanksysteme zu nehmen. Das sieht man an der Interger Leistung, die relativ bescheiden ist. Die FPU spielt bei Datenbanken weniger/überhauptnet die Rolle, und das ist des Itaniums Stärke.

*LOL* Der ist gut. Ein Grossteil der Itanium Systeme wird genau für das verwendet ;-)

Kuck mal bei:
http://www.oracle.com/corporate/press/index.html?1524171.html oder
http://www.unisys.com/products/es7000__servers/news_a_events/all__news/10218348.htm

> In der C't war mal wieder ein schöner Wert - der P4 arbeitet nicht nur 3 Instruktionen parallel ab, bzw. vertauscht deren Reihenfolge, sondern der nimmt sich gleich mehr als 100 (!) vor. Und dein Beispiel hat wohl keine 100 x86 Instruktionen, daraus ergeben sich natürlich extrem viel mehr Möglichkeiten nicht belastete Einheiten doch auszulasten.

Die Anzahl der In Flight Instructions ist zwar wirklich gross, aber trozdem ist die Auslastung der Einheiten bei weitem nicht 100% -- sonst würde HT ja gar keinen Sinn machen. Egal. Für einen guten Überblick kann ich http://arstechnica.com/cpu/01q2/p4andg4e/p4andg4e-1.html nur empfehlen.

> Aber im Endeffekt stimme ich larsbo auch zu. Unterscheiden wir einfach in die theoretischen Flops (bzw. Peak Leistung) und die praktischen Flops

OK :-))
 
ok :)


Der Opteron ist für Datenbanksysteme übrigens besser geeignet, aber ich beziehe mich jetzt auf die CPU selbst - bei Servern stehen ja noch andere Dinge im Hintergrund, die man mit einem benchmark leider net erfassen kann :P
 
zufälligerweise schlage ich mich gerade u.a. mit dem LinPack rum.


Fazit: Der Alg dazu passt in den L1 Cache meines 386ers (!!!)
Das ist reine Fließkommaleistung, und rein garnix anderes. Für den offiziellen LinPack wert wird sogar der Verlust einiger Schleifen herausgerechnet, damit man möglichst nur die Fließkommaleistung hat.
 
> Fazit: Der Alg dazu passt in den L1 Cache meines 386ers (!!!)

Und was ist mit den Daten? Bei den heute relevanten Problemgrößen passen die Daten nicht mehr in den Cache (z.B. eine 1000x1000 Matrix mit double float macht alleine 8'000'000 Byte)!

BTW. Linpack ist sogar ziemlich Memoryschonend da du nur etwa einen Memoryzugriff pro pro 2 FLOPS benötigt und man viele durch geschickte Optimierungen davon in den Cache bekommt.

Versuch doch mal sowas zu machen:

a_i = b_i + s*c_i

a_i, b_i, c_i sind Vektoren der Länge i, wobei i >> Cachesize
s ist ein Skalar

Das ist eine ganz einfache Vektor-Operation die 2*i FP Operationen benötigt.
Schau nun mal wie viele T/M/G FLOPS deine CPU macht!
 
Hab gestern noch gemerkt, dass es garnet der Linpack war - *noahnung*, die Seite wo ich das runtergeladen habe meinte es wäre die auf Linux portierte Version des Linpack.

Die Daten bei dem Codefetzen den ich hab sind ca. 500 Byte... kein malloc, kein nix.
 
Zuletzt bearbeitet:
Zurück
Oben Unten