App installieren
How to install the app on iOS
Follow along with the video below to see how to install our site as a web app on your home screen.
Anmerkung: This feature may not be available in some browsers.
Du verwendest einen veralteten Browser. Es ist möglich, dass diese oder andere Websites nicht korrekt angezeigt werden.
Du solltest ein Upgrade durchführen oder ein alternativer Browser verwenden.
Du solltest ein Upgrade durchführen oder ein alternativer Browser verwenden.
Wieviel Ghz sind ein Teraflop
- Ersteller Elvis
- Erstellt am
Elvis
Commander
hi
kürzlich hab ich irgentwo was von teraflops gelesen und möchte jetzt nur interessehalber mal wissen wieviel Gigaherz des sind
mfg elvis
kürzlich hab ich irgentwo was von teraflops gelesen und möchte jetzt nur interessehalber mal wissen wieviel Gigaherz des sind
mfg elvis
Parad0x
Vice Admiral Special
TheVenom
Grand Admiral Special
- Mitglied seit
- 11.11.2001
- Beiträge
- 2.080
- Renomée
- 2
- Mein Laptop
- Acer Aspire2023 WLMi
- Prozessor
- Phenom II X6 1055T
- Mainboard
- ASRock 870 Extreme3
- Kühlung
- EKL Alpenföhn Nordwand Rev. B
- Speicher
- 2x 2048 MB G.Skill DDR3LV 1600Mhz
- Grafikprozessor
- MSI Radeon HD 5770 Hawk
- Display
- Samsung Syncmaster 226BW
- HDD
- OCZ Vertex 2 60GB, WD 640 GB
- Optisches Laufwerk
- Samsung SH-B083L Blu-ray
- Gehäuse
- Xigmatek Midgard
- Netzteil
- Enermax Modu87+
- Betriebssystem
- Windows 7 SP1 x64
- Webbrowser
- Firefox 8
- Verschiedenes
- Synology Diskstation DS211+
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 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...
HenryWince
Vice Admiral Special
... 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?
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?
ElVerplano
Grand Admiral Special
- Mitglied seit
- 22.10.2002
- Beiträge
- 4.686
- Renomée
- 0
sorry 4 spam aber ein teraflop kann eigentlich nur von intel sein oda !
mfg
mfg
HenryWince
Vice Admiral Special
@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.
> 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.
I²K
Grand Admiral Special
Wieviel PS braucht man für 100 km/h?
p4z1f1st
Grand Admiral Special
- Mitglied seit
- 28.04.2003
- Beiträge
- 9.722
- Renomée
- 81
- Prozessor
- AMD FX-6300
- Mainboard
- Gigabyte GA-970A-UD3
- Kühlung
- HEATKILLER® CPU Rev3.0 LC + HEATKILLER® GPU-X² 69x0 LT
- Speicher
- 2x 4096 MB G.Skill RipJawsX DDR3-1600 CL7
- Grafikprozessor
- AMD Radeon RX 480 8GB
- Display
- Dell U2312HM
- HDD
- Crucial m4 SSD 256GB
- Optisches Laufwerk
- Sony Optiarc AD-7260S
- Soundkarte
- Creative Labs SB Audigy 2 ZS
- Gehäuse
- Chieftec Scorpio TA-10B-D (BxHxT: 205x660x470mm)
- Netzteil
- Seasonic X-Series X-660
- Betriebssystem
- Microsoft Windows 10 Professional 64bit
- Webbrowser
- Mozilla Firefox
- Verschiedenes
- Watercool HTF2 Dual + 2x Papst 4412 F/2GL
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
mtb][sledgehammer
Grand Admiral Special
- Mitglied seit
- 11.11.2001
- Beiträge
- 4.375
- Renomée
- 30
- Mein Laptop
- HP Compaq nx6125
- Prozessor
- Athlon XP 2500+
- Mainboard
- Asrock K7S8XE
- Kühlung
- AC / selfmade Wakü
- Speicher
- 1 GB PC3200 Team Memory
- Grafikprozessor
- ATI Radeon 9500
- Display
- 20,1'' Samsung SyncMaster 205BW 1680x1050
- HDD
- Samsung SV0802N
- Optisches Laufwerk
- Toshiba DVD-ROM SD-M1612
- Soundkarte
- Creative SB Live! Player 1024
- Gehäuse
- Chenbro Net Server Tower
- Netzteil
- Coba 400 Watt (silent)
- Betriebssystem
- Windows XP, Ubuntu Linux
- Webbrowser
- Mozilla Firefox
- Verschiedenes
- knc TV Station , Terratec Cinergy 1200 DVB-C
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)
- 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)
knallebumm
Vice Admiral Special
- Mitglied seit
- 20.02.2002
- Beiträge
- 728
- Renomée
- 3
- Prozessor
- Q9450
- Mainboard
- Asus P5Q-E
- Kühlung
- Xigmatex S1283
- Speicher
- 2*2gb + 2*1gb DDR2 800
- Grafikprozessor
- HIS R9 270
- Display
- Dell UltraSharp U2414H
- SSD
- Samsung 250gb
- HDD
- Samsung F1 1TB
- Soundkarte
- Onboard
- Gehäuse
- Antec nine-hundred
- Netzteil
- Seasonic S12II 380w
- Betriebssystem
- Win 7 Pro
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
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
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
knallebumm
Vice Admiral Special
- Mitglied seit
- 20.02.2002
- Beiträge
- 728
- Renomée
- 3
- Prozessor
- Q9450
- Mainboard
- Asus P5Q-E
- Kühlung
- Xigmatex S1283
- Speicher
- 2*2gb + 2*1gb DDR2 800
- Grafikprozessor
- HIS R9 270
- Display
- Dell UltraSharp U2414H
- SSD
- Samsung 250gb
- HDD
- Samsung F1 1TB
- Soundkarte
- Onboard
- Gehäuse
- Antec nine-hundred
- Netzteil
- Seasonic S12II 380w
- Betriebssystem
- Win 7 Pro
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.
HenryWince
Vice Admiral Special
@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 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 ;-]
> 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 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).
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).
larsbo
Grand Admiral Special
- Mitglied seit
- 20.06.2003
- Beiträge
- 5.864
- Renomée
- 62
- Prozessor
- Ryzen 5 3400G
- Mainboard
- Gigabyte B450I Aorus pro Wifi
- Kühlung
- Noctua NH-L9a
- Speicher
- 32 GB, 2x ADATA 16GB single rank PC4-3200 1,2V (Samsung 16Gbit 2666-Chips)
- Grafikprozessor
- APU
- SSD
- Samsung 970Pro 1TB NVMe PCIe3
- Optisches Laufwerk
- Pioneer BD-RE slim-line
- Soundkarte
- on-board
- Gehäuse
- SilverStone ML08-H
- Netzteil
- Corsair SF450 (80PlusGold)
- Betriebssystem
- Win10pro 64
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
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:
HenryWince
Vice Admiral Special
@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?
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.
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.
HenryWince
Vice Admiral Special
@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 )
> 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
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
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 (!!!)
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.
HenryWince
Vice Admiral Special
> 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!
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 - , 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.
Die Daten bei dem Codefetzen den ich hab sind ca. 500 Byte... kein malloc, kein nix.
HenryWince
Vice Admiral Special
@Intelhasser
> Hab gestern noch gemerkt, dass es garnet der Linpack war
Naja die Routinen dürften trozdem in den Cache passen. BTW. Die Urversion des Linpack Benchmarks arbeitete mit 100*100 Matrizen, nur das war 1970.
> kein malloc, kein nix.
Das Orginal ist Fortran => siehe http://www.netlib.org/benchmark/hpl/, http://www.netlib.org/linpack/ und http://www.netlib.org/blas/
P.S. Aber es gibt auch eine C Version
> Hab gestern noch gemerkt, dass es garnet der Linpack war
Naja die Routinen dürften trozdem in den Cache passen. BTW. Die Urversion des Linpack Benchmarks arbeitete mit 100*100 Matrizen, nur das war 1970.
> kein malloc, kein nix.
Das Orginal ist Fortran => siehe http://www.netlib.org/benchmark/hpl/, http://www.netlib.org/linpack/ und http://www.netlib.org/blas/
P.S. Aber es gibt auch eine C Version
Zuletzt bearbeitet:
Ähnliche Themen
- Antworten
- 4
- Aufrufe
- 2K
- Antworten
- 8
- Aufrufe
- 2K