| View previous topic :: View next topic |
| Author |
Message |
mv
Watchman
Joined: 20 Apr 2005
Posts: 6780
|
 Posted: Fri May 11, 2007 7:56 am Post subject: |
 |
|
| UTgamer wrote: | | "-ffast-math", ja der Hinweis auf wissenschaftliche Verarbeitungsprogramme ist mir bekannt, ich nutze sie nicht. |
Mir würde es auch genügen, wenn eine für mich wichtige Video-/Soundaufnahme kaputtkodiert würde. Klar, wenn man den Rechner nur zum Abspielen oder Zocken benutzt, ist es egal - da würde ja selbst ein (seltener) Absturz nicht wirklich Probleme bereiten. Ob dann allerdings der geringfügige Geschwindigkeitsvorteil ins Gewicht fällt?
| Quote: | | Da ich aber auch auf meinem alten 32 bit-Rechner (siehe Signatur) schon seit 2004 dieses Flag nutze und über die Jahre kaum Probleme hatte, werde ich auf 64 Bit noch viel weniger Probleme haben und habe sie auch nicht. |
Das dürfte wohl nichts mit 32/64 Bit zu tun haben. Oder hat float/double auf 64Bit eine andere Länge?
| Quote: | | -m64, der Start von z.B. OpenOffice hat sich beschleunigt, sogar PHP |
Möglicherweise, weil es nach der Rekompilation an einer günstigeren Stelle der Platte liegt o.ä. - mit -m64 hat das jedenfalls nichts zu tun, weil das eben nichts am erzeugten Code ändert. |
|
| Back to top |
|
 |
UTgamer
Veteran
Joined: 10 Aug 2003
Posts: 1326
Location: Troisdorf (Köln) Deutschland
|
| Posted: Sat May 12, 2007 11:29 am Post subject: |
|
|
| mv wrote: | | UTgamer wrote: | | "-ffast-math", ja der Hinweis auf wissenschaftliche Verarbeitungsprogramme ist mir bekannt, ich nutze sie nicht. |
Mir würde es auch genügen, wenn eine für mich wichtige Video-/Soundaufnahme kaputtkodiert würde. Klar, wenn man den Rechner nur zum Abspielen oder Zocken benutzt, ist es egal - da würde ja selbst ein (seltener) Absturz nicht wirklich Probleme bereiten. Ob dann allerdings der geringfügige Geschwindigkeitsvorteil ins Gewicht fällt? |
Ich habe mir die Tage mehrere Landkarten (Maßstab 1:20000) erstellt, von der Größe 7000*7000 Pixel und arbeite darin ohne irgendwelche Probleme, flink im Scrollen und alles, 2-3 Grafikfenster + Browser auf und zwischen denen wird munter umkopiert. Der /tmp-Ordner liegt in einer 256 MB großen Ramdisk, nicht ein Absturz, nicht einmal eine der riesigen Grafiken beschädigt, live beim copy&paste wird von 24-Bit-Grafiken auf 8-Bit Grafiken herunter gerechnet zwischen den Grafiktools. Browser ist 24 Bit, Irfanview im wine laufend ist 24 bittig für die Schneidarbeiten, xv für screenshoots ist 24 bittig, und für meine Zwischenablagen für fertig geschnittene Teile dient kolourpaint vom KDE im 8-Bitmodus.
Gepackt im PNG-Format auf der Platte sind sie allein rund 8,8 MB groß. Das einzige wo ein Fenster mal für rund 5 Sek. blockiert ist wenn ich abspeichere.
Ich habe sie mal gerade aus interresse extra im BMP-Format abgespeichert, das dauerte dafür dann auch nur 1 Sekunde über wine ausm IrfanView, also ungepackt (BMP) ist eine 35 MB groß!
Probleme beim konvertieren von 35MB großen Daten in verschiedene Formate (BMP/GIF/PNG/JPG) 
Keine Ahnung was ihr habt, ich finde keine Probleme mit "-ffast-math" oder den anderen Flags.
Wie sagt man in Mel Brooks - Spaceballs so schön: "Colonel - Wahnsinnige Geschwindigkeit" 
-----------------
PS - Offtopic:
Das einzige was mir im Linus noch fehlen würde wäre das alte "Deluxe Paint" vom Amiga, ein Tool für alles. Ich würde ja nur das benutzen wenn der scheiß UAE-Emulator unter Linux nicht so beschießen zu konfigurieren und zum Laufen zu bewegen wäre. Unter Windows funktioniert die ein oder andere WinUAE-Version wenigstens sauber.
Kommt mir nicht mit Gimp, a) muß ich dafür Gnome installieren (niemals) und b) habe ich mir das unter Debian mal angesehen, keine richtige deutsche Menüführung und überhaupt überall kann man dran drehen aber wofür die ganzen Sachen sind - ka, einfach mal mehrere Layer einrichten und transparent durchscheinen lassen um sie schön gegeneinander zu verschieben wie das in Deluxe Paint geht, habe ich nicht gefunden, ebenso habe ich die progamminternen Clipboards (schiebe Clipboard 3 auf Layer 4, dann mixe Layer 1 + 4 miteinander damit ich die richtige Position finden kann, dann schalte Layer 2 gegen Layer 4, wobei ich die beiden Grafiken dann merge) nicht gefunden. Hallo Markt&Technik legt das Amiga-Deluxe-Paint wieder neu auf für Linux. Animierte Grafiken (IFF-Format) konnte man damit auch bereits in den 80ern herstellen (Grafikstandart unter Amiga). Wo stelle ich hier unter X und wie kompliziert animierte Desktophintergründe oder Dateimanager-Hintergründe her? Ging alles mit Deluxe-Paint Linux hat noch einen langen Weg auf dem Desktop vor sich um selbst Desktoptechniken der 80er Jahre irgendwan mal zu erreichen. Windows ist wirklich keine Alternative für Amigaanhänger, hat ja noch nichtmal eine einzige RAM-Disk  Mit Linux-DBUS kommt so ganz ganz langsam mal eine Alternative für das alte Arex, einer DCOP/DBUS Programmiersprache, abgewandelt und kompatibel zum IBM-REX.
Ich bin einfach besseres gewohnt oder auch verwöhnt und muß zusehen wie ich mit den beschränkten Mitteln hier zurecht komme.
Langsame Amigas gab es nie, ich hätte gerne den gleichen Komfort, und "-ffast-math", tmpfs und viel RAM kommen solangsam auf die 28 MHz Geschwindigkeit die ich auf meinem Motorolla 68030er mit 4 MB RAM und einer Bootgeschwindigkeit von 7 Sekunden nach Powerbuttondrücken bis zum annimierten Desktop hatte. Heute habe ich die 258 fache CPU-Geschwindigkeit, 40 fache RAM-Größe und 37 fache Busgeschwindigkeit, und das System ist immer noch lahmer als früher. (Heul) Die Sprach-Ein/Ausgabe zum Programme starten vermisse ich ebenfalls. Früher einfach ein Alias auf eine Ramdisk gelegt in dem die meist benötigten CLI-Befehle gelegen hatten und das war Geschwindigkeit pur. Heute weiß man ja während eines Arbeitstages ja noch nichtmal wie oft irgend eine der Bins aus /usr/bin wie oft den Tag über gestartet wurden, und alle in eine RAM-Disk legen, geht auch nicht, zur Zeit habe ich in /usr/bin 320 MB drinn, zudem sind die meistbenutzten sowieso nur Scripte die auf irgendwelche Libs verweisen. Also das war früher auch besser gelöst. Die Anwendungsprogramme hatten nichts im Commando-Ordner zu suchen, die packte man als Verknüpfung in die Desktopleiste oder als Icon. Wieviele bins im /usr/bin Verzeichnis habe ich eigentlich noch nie seit Installation gestartet? Hab leider die atime abgeschaltet sonst würde ich direkt mal nachschauen. Weil geil währe ein Initscript welches eine RAM-Disk erstellt und die meist benötigten Befehle darein schiebt (wie ich damals Standart eingerichtet hatte), dann ein Script welches alle anderen nur als Symlink mit dareinlegt. Beim dem Projekt wäre ich sofort mit dabei.
_________________
AMD Phenom II x4 >> CFLAGS="-march=amdfam10 -O2 -mmmx -msse3 -mfpmath=sse,387 -pipe -ffast-math" is stable and here in use.
Did Intel produce at any time bugfree HW?
http://www.urbanmyth.org/microcode/
http://www.heise.de/newsticker/meldung/91748 |
|
| Back to top |
|
|
mv
Watchman
Joined: 20 Apr 2005
Posts: 6780
|
| Posted: Sun May 13, 2007 8:35 am Post subject: |
|
|
| UTgamer wrote: | | Keine Ahnung was ihr habt, ich finde keine Probleme mit "-ffast-math" oder den anderen Flags. |
Bei den beschriebenen Aktionen dürfte -ffast-math weitestgehend keinen Einfluss haben; der entscheidende Faktor bei der Geschwindigkeit dürfte wohl eher der Festplatten-IO bzw. -Caching sein. Höchstens bei Konvertierung von/zu jpg könnte etwas Fließkommaarithmetik in Benutzung sein. Von daher ist es auch nicht überraschend, dass dabei mit -ffast-math keine Probleme auftreten.
| Quote: | | Kommt mir nicht mit Gimp, a) muß ich dafür Gnome installieren (niemals) und b) habe ich mir das unter Debian mal angesehen |
a) ist sicherlich falsch. Ich habe Gimp installiert, aber kein Gnome und auch keine Gnome-Libraries.
b) Jedes mächtige Graphikprogramm ist einarbeitungsbedürftig. Es ist natürlich verständlich, dass Du nicht ein neues lernen willst, wenn Du bereits in eines eingearbeitet bist.
| Quote: | | Windows ist wirklich keine Alternative für Amigaanhänger, hat ja noch nichtmal eine einzige RAM-Disk |
Was ist tmpfs Deiner Meinung nach?
| Quote: | | Die Sprach-Ein/Ausgabe zum Programme starten vermisse ich ebenfalls. |
Ich würde erwarten, dass Du in app-accessibility etwas dafür findest (sphinx?)
| Quote: | | Weil geil währe ein Initscript welches eine RAM-Disk erstellt und die meist benötigten Befehle darein schiebt |
Ziemlich blödsinnig wäre das, weil der Fesplatten-Cache des Betriebssystems das Ram viel efffizienter nutzt (indem eben automatisch die selten benutzten Sachen herausfliegen und für das häufig benutzte Platz machen) - sowas gab es unter dem Amiga natürlich nicht, deswegen musste man sich mit Ramdisk behelfen. Wenn es Dir nur um das schnelle Starten beim ersten Aufruf geht (und Du dafür beim Booten länger warten willst) kannst Du ja ein Script schreiben, das die betreffenden Programme lädt (und ggf. unmittelbar darauf wieder killt). Was vielleicht sinnvoll wäre, wäre eine Möglichkeit, gezielter auf die Cache-Strategie Einfluß zu nehmen (etwa indem man bestimmte Teile angeben kann, die bevorzugt im Cache gehalten werden sollen; sinnvoll wäre es, wenn man das dann über Neubooten hinweg speichern können) - dazu solltest Du Dich allerdings an die Filesystem-Maintainer wenden. |
|
| Back to top |
|
|
UTgamer
Veteran
Joined: 10 Aug 2003
Posts: 1326
Location: Troisdorf (Köln) Deutschland
|
| Posted: Sun May 13, 2007 11:50 am Post subject: |
|
|
| mv wrote: | | UTgamer wrote: | | Keine Ahnung was ihr habt, ich finde keine Probleme mit "-ffast-math" oder den anderen Flags. |
Bei den beschriebenen Aktionen dürfte -ffast-math weitestgehend keinen Einfluss haben; der entscheidende Faktor bei der Geschwindigkeit dürfte wohl eher der Festplatten-IO bzw. -Caching sein. Höchstens bei Konvertierung von/zu jpg könnte etwas Fließkommaarithmetik in Benutzung sein. Von daher ist es auch nicht überraschend, dass dabei mit -ffast-math keine Probleme auftreten. |
Jetzt bin ich aber überrascht, Photobearbeitung in JPG steht gerade nicht auf meiner todo-Liste, ich werde meine Ohren mal offenhalten, weil meine Frau auf dem anderen Rechner ebenfall mit "-ffast-math" dieser Tage einige Photos bearbeiten will, ich werde sie mal fragen ob sie auf dem Athlon XP irgend etwas negatives bei der Photobearbeitung auszusetzen hat.
(Seltsam, als ich noch Assembler auf dem Amiga programmierte habe ich jeden Co-Prozezzor mit eingebunden gehabt den es gab, um jedwede Geschwindigkeit auszureizen, die FPU hatte einen nicht unbeachtlichen Anteil daran, ich schrieb CPU-Instructions zur Anweisung die gefüllten FPU-Register Päckchenweise nummeriert auf vordefinierte Arrays zu schieben, die FPU-Datenpäckchen in Registergröße im Array vorzuhalten war eine sehr schnelle Methode sie von CPU und Grafikchips direkt wieder in die Register schieben zu können zur Weiterverarbeitung. Es war etwas kniffelig, aber brachte die schnellsten Programme hervor. Ich habe das Programmieren wegen der Little-/Big-Endian Umstellung vor Jahren aufgegeben.)
Zudem gerade bei JPGs wie du auch erwähntest fällt es doch mal nicht auf, ob ein einzelnes Pixel statt dem Helligkeitswert 255*255*255 durch einen Rundungsfehler mal 255*254*255 zu erhalten. Ich dachte aber mit der mittlerweile gegen früher viel höheren Nachkommastelle würde es für alle Grafikdaten einfach unnötig werden noch Integer als (Bild-/Audio-)Daten zu verwenden. Bei jedem CD-Brennvorgang mit höherer Geschwindigkeit werden zwar die Daten nach dem Brennen meist mit dem Original verglichen, aber auf jedem anderem lesendem Laufwerk ist die Fehlerrate und damit Korrektur durch Spur- , Staub, Kratzer, Fett und Herstellungsfehlern die Fehlerwarscheinlichkeit höher als bei einem FPU-Rundungsfehler.
https://forums.gentoo.org/viewtopic-p-4054106.html#4054106
PS - Offtopic:
| mv wrote: | | Quote: | | Kommt mir nicht mit Gimp, a) muß ich dafür Gnome installieren (niemals) und b) habe ich mir das unter Debian mal angesehen |
a) ist sicherlich falsch. Ich habe Gimp installiert, aber kein Gnome und auch keine Gnome-Libraries.
b) Jedes mächtige Graphikprogramm ist einarbeitungsbedürftig. Es ist natürlich verständlich, dass Du nicht ein neues lernen willst, wenn Du bereits in eines eingearbeitet bist. |
Ich habe einen WOW-Effekt, vor längerer Zeit wollte das Ebuild noch Gnometeile mitinstallieren. Schön das du mich darauf aufmerksam gemacht hast das dies nicht mehr der Fall ist, kann ich ja jetzt nochmal schauen ob es meine Wünsche erfüllen kann (die Entwicklung steht ja nicht).
| mv wrote: | | Quote: | | Windows ist wirklich keine Alternative für Amigaanhänger, hat ja noch nichtmal eine einzige RAM-Disk |
Was ist tmpfs Deiner Meinung nach? |
Aneinander vorbei geredet, ich meinte MS-Windows, das hat nämlich 0 (außer dem internen Cache). Hier auf meinem Linux nutze ich mehrere tmpfs (RAM-Disks), selbst für den Browsercache von 128 MB.
| mv wrote: | | Quote: | | Die Sprach-Ein/Ausgabe zum Programme starten vermisse ich ebenfalls. |
Ich würde erwarten, dass Du in app-accessibility etwas dafür findest (sphinx?) |
Werde ich mir mal ansehen, ich hatte noch nicht für alles Zeit.
(Sprachsynthese zum Vorlesen von Texten war bereits ins System integriert, mußte man nur Entsprechungen für Deutsch selbst definieren wie er z.B. ein ö aussgeben soll). Eingabe ja ging auch nur über Zusatztools, meist war bei 40-80 Worten Schluß. Stand jetzt bei mir mal hinten an, vermisse ich aber so langsam. Kommt auch bald drann, jetzt wo das System meinen Vorstellungen langsam entspricht (lange Jahre Arbeit war das).
| mv wrote: | | Quote: | | Weil geil währe ein Initscript welches eine RAM-Disk erstellt und die meist benötigten Befehle darein schiebt |
Ziemlich blödsinnig wäre das, weil der Fesplatten-Cache des Betriebssystems das Ram viel efffizienter nutzt (indem eben automatisch die selten benutzten Sachen herausfliegen und für das häufig benutzte Platz machen) - sowas gab es unter dem Amiga natürlich nicht, deswegen musste man sich mit Ramdisk behelfen. Wenn es Dir nur um das schnelle Starten beim ersten Aufruf geht (und Du dafür beim Booten länger warten willst) kannst Du ja ein Script schreiben, das die betreffenden Programme lädt (und ggf. unmittelbar darauf wieder killt). Was vielleicht sinnvoll wäre, wäre eine Möglichkeit, gezielter auf die Cache-Strategie Einfluß zu nehmen (etwa indem man bestimmte Teile angeben kann, die bevorzugt im Cache gehalten werden sollen; sinnvoll wäre es, wenn man das dann über Neubooten hinweg speichern können) - dazu solltest Du Dich allerdings an die Filesystem-Maintainer wenden. |
Ja demnächst werde ich meine Augen für alles aus diesem Thema "Cache-Strategie Einfluß" offen halten.
Das über einen Reboot festgehalten werden wäre echt nützlich (damals gab es dafür die resetfeste RAM-Disk, ok aber das war eine MMU-HW-Sache, und ermöglichte einen Reboot nach dem Resetknopf drücken innerhalb von 2 Sekunden).
So jetzt muß ich aber mal los, Heute ist Muttertag 
_________________
AMD Phenom II x4 >> CFLAGS="-march=amdfam10 -O2 -mmmx -msse3 -mfpmath=sse,387 -pipe -ffast-math" is stable and here in use.
Did Intel produce at any time bugfree HW?
http://www.urbanmyth.org/microcode/
http://www.heise.de/newsticker/meldung/91748 |
|
| Back to top |
|
|
mv
Watchman
Joined: 20 Apr 2005
Posts: 6780
|
| Posted: Sun May 13, 2007 1:11 pm Post subject: |
|
|
| UTgamer wrote: | | Zudem gerade bei JPGs wie du auch erwähntest fällt es doch mal nicht auf, ob ein einzelnes Pixel statt dem Helligkeitswert 255*255*255 durch einen Rundungsfehler mal 255*254*255 zu erhalten. |
Ich vermute nicht, dass -fast-math Einfluss auf die Rundungsfehler hat. Es geht dabei eher um so Fragen wie, ob z.B. im Falle eines NaN-Zwischenergebnisses (not-a-number, etwa bei Division durch 0, die leicht bei Division durch Differenzen auftreten kann) auch als Endergebnis NaN herauskommt, oder ob der Compilercode das NaN-Flag aus Geschwindigkeitsgründen ignoriert, und man dafür ein "zufälliges" Ergebnis erhält. Ob und ggf. wie sehr sich das auswirkt, hängt natürlich stark von der Anwendung ab, und inwieweit sich deren Implementierung auf das (eigentlich dokumentierte) Verhalten verlässt.
| Quote: | | Sprachsynthese zum Vorlesen von Texten war bereits ins System integriert |
Kannst Du haben: app-accessibility/speechd
Es gibt aber auch noch app-accessibility/festival und sicher noch weitere.
| Quote: | | damals gab es dafür die resetfeste RAM-Disk |
Das will man gar nicht mehr brauchen müssen, denn ein Reset ist ja inzwischen höchstens notwendig, wenn irgendeine Hardware oder Kernel/Treiber massive Bugs hat (oder bei einer Kernel-Neukompilation).
| Quote: | | habe ich jeden Co-Prozezzor mit eingebunden gehabt den es gab, um jedwede Geschwindigkeit auszureizen |
Zwar habe ich mich mit modernen Prozessoren nicht viel beschäftigt, aber so etwas bringt dort vermutlich nicht viel: Die parallelisieren soweit wie möglich ohnehin schon selbständig - es ist da eher wichtig, dass man den Code so schreibt, dass sie die parallel berechneten Ergebnisse auch nutzen können und nicht ganze Queues wegschmeißen müssen (Stichwort: branch-prediction). Wenn man sich dann noch "händisch" (sprich: unter Zuhilfenahme von Code) mit dem Co-Prozessor synchronisieren müsste, hätte man jedweden Vorteil verspielt. |
|
| Back to top |
|
|
UTgamer
Veteran
Joined: 10 Aug 2003
Posts: 1326
Location: Troisdorf (Köln) Deutschland
|
| Posted: Sun May 13, 2007 9:20 pm Post subject: |
|
|
| mv wrote: | | UTgamer wrote: | | Zudem gerade bei JPGs wie du auch erwähntest fällt es doch mal nicht auf, ob ein einzelnes Pixel statt dem Helligkeitswert 255*255*255 durch einen Rundungsfehler mal 255*254*255 zu erhalten. |
Ich vermute nicht, dass -fast-math Einfluss auf die Rundungsfehler hat. Es geht dabei eher um so Fragen wie, ob z.B. im Falle eines NaN-Zwischenergebnisses (not-a-number, etwa bei Division durch 0, die leicht bei Division durch Differenzen auftreten kann) auch als Endergebnis NaN herauskommt, oder ob der Compilercode das NaN-Flag aus Geschwindigkeitsgründen ignoriert, und man dafür ein "zufälliges" Ergebnis erhält. Ob und ggf. wie sehr sich das auswirkt, hängt natürlich stark von der Anwendung ab, und inwieweit sich deren Implementierung auf das (eigentlich dokumentierte) Verhalten verlässt. |
Das war das Stichwort NaN-Flag (not-a-number) (damals auf den kleineren 16(32) Bitrechnern auch noch Rundungsfehler).
Ich übersehe immer aus eigener ASM-Erfahrung das C und Nachfollger ja Hochsprachen sind.
Klar jetzt fällt es mir wieder wie Schuppen von den Augen, die Compilerprogrammierer von fast jeder Hochsprache haben dieses Problem. Unter Assembler und einigen negativen Erfahrungen am Anfang kriegte man das recht schnell in den Griff, und wenn es perse nicht hinhauen wollte hat man eben doch wieder auf Integer umgestellt, je nach Programmzweck. (So ungefähr hatte ich das Problem angegangen.) Man definierte den Inhalt von Arrays als int oder float und mußte um Vermischungen vorzubeugen z.B. die Register am besten fest reservieren, reg 15-31 z.B. für float, so konnte man z.B. dem NaN-Problem einfach entgehen, weil Vermischungen ausgeschlossen waren am Ende für den Assembler nicht vergessen Stack und Register wieder als float/raw und nicht int zu markieren. Und die RAW-Daten konnten direkt als Datenstream der Grafikausgabe übergeben werden.
(Sind schon ein paar Jahre her, das ich das das letze mal gemacht hatte).
Früher hatte "C" den Manko das man ja die Register nicht fest reservieren konnte (von bis) wie in Assembler, daß das Heute intern immer noch ein Problem ist hätte ich jetzt so nicht erwartet und einfach vergessen. Zudem spielt Multi-tasking/-threading auch noch mit zur erschwerenden Problematik.
Ich sehe es ja ein, Hochsprachenkompiler haben ihre Probleme damit.
Am Beispiel Xara Xtreme: | Quote: | | Xara Xtreme bietet eine hohe Verarbeitungsgeschwindigkeit, die durch die Programmierung in Assembler in Xara Xtremes Renderer erreicht wird. Laut Angaben des Herstellers gilt Xara Xtreme derzeit als das mit Abstand schnellste Illustrationsprogramm auf dem Markt |
sieht man immer wieder was alles in ASM machbar ist. Der SVG Grafikstandard demnächst in KDE 4, sollte am besten auch in float über ASM programmiert werden, dann ist a) die CPU frei für andere Dinge und b) Float ist wesentlich schneller abgearbeitet.. *g*
Eines fällt mir aber noch dazu ein, warum merke ich eigentl. das wenn die gesammte Software auf dem Rechner so mit meinen jetzt gesetzen Flags kompiliert wurde das sie flotter läuft, als wenn ich sie unter Standart -O2 kompiliere?
| mv wrote: | | Zwar habe ich mich mit modernen Prozessoren nicht viel beschäftigt, aber so etwas bringt dort vermutlich nicht viel: Die parallelisieren soweit wie möglich ohnehin schon selbständig - es ist da eher wichtig, dass man den Code so schreibt, dass sie die parallel berechneten Ergebnisse auch nutzen können und nicht ganze Queues wegschmeißen müssen (Stichwort: branch-prediction). Wenn man sich dann noch "händisch" (sprich: unter Zuhilfenahme von Code) mit dem Co-Prozessor synchronisieren müsste, hätte man jedweden Vorteil verspielt. |
Die FPU-Geschwindigkeit eines Athlon ist zumindest enorm, sie soll rund dopplt so schnell sein wie auf Intelsystemen.
branch-prediction - damit habe ich leider keine Erfahrung.
Es mag Geschwindigkeitsvorteile bringen, aber belastet doch sicher den Energieverbrauch einer CPU (Stichwort: Ruhestrom). Ob das der richtige Weg ist wage ich einfach mal ohne höheres Wissen zu bezweifeln. Irgendo las ich diesen Monat das die IT-Systeme in D schon 2% der CO2 Emissionen ausmachen. Nun bei branch-prediction kann ich mich als Ruhestromkiller auch täuschen.
Es bringt zumindest etwas Leistungsvorteil. Zudem ist branch-prediction für die Co-Prozessoren auch garnicht nötig, ich bin froh wenn diese Einheiten überhaupt etwas zu tun haben, meist unter Integer schlummern sie ja doch nur rum außer bei z.B. großartigen 3D-Spielen (sse/mmx/i368). Ich finde sogar die Renderausgabe der Mozilla-Browser (Gecko) solle es am besten auch nutzen (scrollen, Seitenaufbau (Tabellen/CSS), etc). Dann kann die CPU im Hintergrund z.B. noch schneller emergen weil sie dann zu 99% frei wäre. *g*
_________________
AMD Phenom II x4 >> CFLAGS="-march=amdfam10 -O2 -mmmx -msse3 -mfpmath=sse,387 -pipe -ffast-math" is stable and here in use.
Did Intel produce at any time bugfree HW?
http://www.urbanmyth.org/microcode/
http://www.heise.de/newsticker/meldung/91748 |
|
| Back to top |
|
|
obrut<-
Apprentice
Joined: 01 Apr 2005
Posts: 183
Location: near hamburg, germany
|
| Posted: Sun May 13, 2007 10:29 pm Post subject: |
|
|
branch prediction macht einen erheblichen anteil der performance heutiger cpus aus, da die pipelines länger sind als früher und daher ein abwarten des ergebnisses einer operation um den nächsten befehl ausführen zu können einfach zu lange dauert.
selbst wenn die fpus stärker genutzt würden, so wäre "die cpu" trotzdem nicht frei. fpu und alu teilen sich dieselben befehlsdecoder, von denen es üblicherweise nur 3 oder 4 gibt. wenn jetzt die 3 decoder eines athlon dessen fpus befeuern, von denen es immerhin 3 gibt (je einmal fmul, fadd und fmisc), dann laufen die alus leer, da sie keinen nachschub bekommen. der k10 wird wie auch die aktuellen cpus von intel 4 decoder bekommen um die verschiedenen funktionseinheiten besser auslasten zu können. |
|
| Back to top |
|
|
UTgamer
Veteran
Joined: 10 Aug 2003
Posts: 1326
Location: Troisdorf (Köln) Deutschland
|
| Posted: Mon May 14, 2007 11:19 am Post subject: |
|
|
| obrut<- wrote: | branch prediction macht einen erheblichen anteil der performance heutiger cpus aus, da die pipelines länger sind als früher und daher ein abwarten des ergebnisses einer operation um den nächsten befehl ausführen zu können einfach zu lange dauert.
selbst wenn die fpus stärker genutzt würden, so wäre "die cpu" trotzdem nicht frei. fpu und alu teilen sich dieselben befehlsdecoder, von denen es üblicherweise nur 3 oder 4 gibt. wenn jetzt die 3 decoder eines athlon dessen fpus befeuern, von denen es immerhin 3 gibt (je einmal fmul, fadd und fmisc), dann laufen die alus leer, da sie keinen nachschub bekommen. der k10 wird wie auch die aktuellen cpus von intel 4 decoder bekommen um die verschiedenen funktionseinheiten besser auslasten zu können. |
Zu branch prediction, thx hat mir weiter geholfen, und nicht schlecht ins Detail gegangen.
Aber deine Werte scheinen doch etwas älter zu sein.
Ich habe hier mal ein paar Textpassagen (mit Quellenangaben) herausgesucht was wirklich in einem modernen Pentium 7+ oder Athlon (XP, 64 oder 64 x2) abgeht; bei der Benutzung von nicht Integer also 3D Now, MMX, SSE, SSE2.
###################################
#### http://www.cpushack.net/CPU/cpu3.html ####
The P7 extended the pipeline even further to over 20 stages (or 30 during cache misses), stressing clock speed over execution speed (for marketing reasons) - this led to some questionable design decisions. The three decoders are replaced by single decoder and a trace cache - similar in concept to the decoded instruction cache of the AT&T Hobbit, but 80x86 instructions often decode into multiple micro-ops, so mapping the micro-ops to memory is more complex, and instructions are loaded ahead of time using branch prediction. This speeds execution within the cache, but the single decoder limits the external instruction stream to one at a time. Long micro-op sequences are stored in microcode ROM and fed to the dispatch unit without being stored in the cache.
There are seven execution units, one FPU/MMX/SSE, one FP register load/store unit, two add/subtract integer units, one logic (shift and rotate) unit, one load and one store unit. The add/subtract units run at double the clock rate, basically as a two stage pipe, allowing two results within a single clock cycle, meaning up to nine micro-ops could be dispatched each cycle to the seven units, but in practice the trace cache is limited to three per cycle. A slower logic unit replaces two faster address units in the P6, slowing most code. Since the stack-oriented FPU registers are difficult to use for superscalar or out-of-order execution, Intel added floating-point SSE instructions (called SSE2), so that floating point operations can use the flat SSE registers which will make future designs easier, and the old FPU design becomes less important.
...
...
...
When moving from the 80286 to the 80386 (IA-32), Intel took the opportunity to fix some of the least liked features remaining in the previous design. Moving to x86-64, AMD decided to further modernize the design, adding a cleaner 64-bit mode (selected by Code Segment Descriptor (CSD) register bits).
It's based on sixteen 64-bit integer and sixteen 128-bit vector/floating point (XMM) registers (the lower eight registers of each map to the original x86 integer and SSE/SSE2 registers) and the 8087 FPU/MMX registers, with a 64-bit program counter. In 64-bit mode, integer registers are uniform and can be 8-, 16-, 32-, or 64-bit. Address spece is changed from mainly segmented to a flat space (keeping data segment registers in 32- or 16-bit sub-modes) with PC relative addressing, although code segments (within the address space) are still used to define the modes for each segment. Older 8086 modes are supported in a separate "legacy" mode. These changes give compilers a larger, more regular register set to use making optimizations easier.
Rumours persisted that Intel was developing a CPU codenamed "Yamhill", originally based on original 64-bit P7 plans dusted off, but then switching to the x86-64 architecture and instruction set (apparently under pressure from Microsoft to avoid creating yet another instruction set to support - ironically making Intel a follower of AMD, after driving 80x86 development from the beginning). Originally it was an unofficial project, then official when performance of the first Itanium disappointed, and K8 popularity exceeded expectations. It was finally released as an "enhanced" Pentium 4 Xeon (March 2004), despite being a new design. The 64-bit capability is designed as a 32-bit add-on (like old bit-slice processors) and is disabled in lower end versions, (much like the low-cost 80486SX FPU was disabled). When enabled, the extended 32 bit pipeline operates 1/2 clock cycle later than the main pipeline.
It has the same registers, addressing modes and extensions as the AMD K8, but is otherwise similar to the 64-bit P7, with the same pipeline, including double-clocked add/subtract units, though fixing the bottlenecks and using larger caches, buffers, etc. In addition, there are separate SSE2 functional units, rather than using the older FPU units for SSE operations as the P7 did.
###################################
Optimizing Performance on Modern HPC Systems: Learning From Simple Kernel Benchmarks
http://www10.informatik.uni-erlangen.de/~jan/download/rgw05.ps
(Den HTML-Link kann das Forum irgendwie nicht, muß das PS-Dokument dafür herhalten)
---------
3.2 Handcoded optimizations
While the achievable sustained memory performance of former x86 cpu generations
was far below peak, latest generation CPUs as the AMD Athlon 64 and Intel Pentium
4 Prescott can nearly reach their theoretical peak memory bandwidth. However,
this can only be done using the SSE/SSE2 instruction set extensions and special
optimizations that have not found their way into standard compilers yet. We have
explored the potential of these new instructions with handcoded assembly language
versions of the vector triad.
SSE/SSE2
SSE and SSE2, available on Intel Pentium 4 as well as AMD Athlon64 and Opteron
processors, not only provide a completely new set of SIMD registers that has sig-
nificant advantages over the traditional FPU register stack, but also add special
instructions for explicit memory subsystem control:
Nontemporal stores can bypass the cache hierarchy by using the write-combine
buffers (WCBs) which are available on all modern CPUs. This not only enables
more efficient burst operations on main memory, but also avoids cache pollu-
tion by data which is exclusively stored, i. e. for which temporal locality is not
applicable.
Prefetch instructions, being hints to the cache controller, are provided in order
to give programmers more control over when and which cachelines are brought
into the cache. While the built-in hardware prefetch logic does a reasonable job
identifying access patterns, it has some significant limitations [7] that might be
circumvented by manual prefetch.
Explicit cache line flush instructions also allow explicit control over cache use,
making cache based optimizations more effective. These special instructions were
not used in the benchmarks described below.
...
In order to get an impression of cache behavior we ran plain FPU and SSE2 versions
of the vector triad (Fig. 3). An important general observation on all Pentium 4
revisions is that cache bandwidth scales with the register width used in load/store
instructions, i. e. the CPU reaches its full potential only when using the 16-byte
SSE registers. On the other hand, the AMD Athlon 64 bandwidth almost stays the
same when going from FPU to SSE2. Moreover, this CPU shows a mediocre L2
bandwidth when compared to the Pentium 4. The AMD design clearly does not
favor vector streaming applications as much as the Pentium 4 which is trimmed
to SIMD performance. As a side note, the cache bandwidths on a Pentium 4 are
asymmetric, meaning that read bandwidth is much higher than write bandwidth,
the latter being 4 bytes/cycle on all cache levels. The Athlon64 does not show this
asymmetry at all.
One must still keep in mind that the Pentium 4 CPUs derive much of their
superior cache performance from a very high clock rate. Memory bandwidth, on the
other hand, depends on completely different factors like the number of outstanding
memory references or the effectivity of hardware prefetch.
###################################
####### CodingForSpeedInDelphi.doc ##########
http://dennishomepage.gugs-cats.dk/CodingForSpeedInDelphi.doc
Aus einem Delphi Speedoptimisation Manual:
14. Memory Copy
1. Integer
2. Floating Point
Copying floating point data can basically be done in two ways. Either by using CPU registers as temporary storage or by using the FPU stack. Using SSE on P3 or SSE/SSE2 on P4 can also do it.
As an example this chapter uses functions for copying complex numbers in rectangular format. Just think about the records used in a general way. Any record with floating point numbers would suffice. The basic function looks like this
###################################
Naja, die Funktion -fast-math scheint außer den möglichen Risiken eines NaN (und evtl. wissenschaftl. Rundungsfehlern) bei Compiler-/Programmierfehlern wohl doch sehr viele Vorteile zu haben.
Mich kriegt man auf Desktoprechnern, ja sogar einfachen Web- oder Storage-Servern nicht davon überzeugt das die RAW-Datentechnik für diese von Nachteil ist.
Auf Hochverfügbarkeitsmachinen Wissenschaft/Forschung/Finanzzentren (Cluster, etc.) und in Datenzentren ist es natürlich unmöglich sich auf solche Risiken einzulassen.
Nebenbei bemerkt für reines Numbercrunching.
Ich fand eine Unmenge an Diskussionen über Floatoptimizations für die Projecte unter Boinc, wie z.B. die Suche nach außerirdischem - Seti. Dort wurde von vielen gesagt das die Berechnungen unter SSE2 rund 7 mal schneller vonstatten gehen als auf dem Standart Boinc in Integer. Unter SSE3 wurden Wertsteigerungen gegenüber SSE2 vom nochmal 0,5-1 fachen angegeben, also rund 7,5 - 8 mal schneller.
---
Ich kann mir auch nicht vorstellen das eine Co-Unit mit ihrer ALU-Ausnutzung die ganze Main-Unit ausbremsen soll, die müssen doch eigene ALUs besitzen um das verarbeiten zu können und auf einem DualCore erst überhaupt nicht. Berechne ich die 128 Bit Float-Werte auch auf den 64 Bit Int-ALUs des Main-Core und wie soll ich damit z.B. beim NumberCrunching die 7-8 fache Geschwindigkeit erreichen? Zudem kann es auch garnicht übereinstimmen, da ich mehrmals gelesen hatte das die SSE-Einheit einem RISK-Prozessorsatz ähnelt. | obrut<- wrote: | | Selbst wenn die fpus stärker genutzt würden, so wäre "die cpu" trotzdem nicht frei. fpu und alu teilen sich dieselben befehlsdecoder, von denen es üblicherweise nur 3 oder 4 gibt. wenn jetzt die 3 decoder eines athlon dessen fpus befeuern, von denen es immerhin 3 gibt (je einmal fmul, fadd und fmisc), dann laufen die alus leer, da sie keinen nachschub bekommen. der k10 wird wie auch die aktuellen cpus von intel 4 decoder bekommen um die verschiedenen funktionseinheiten besser auslasten zu können. |
^ Diese Aussage paßt zum ersten Auszug oben für Intel-FPU instructions, jedoch nur mehr bedingt für SSE, wobei AMD diese Einheiten ja wieder besser geregelt hat. Letztendlich hat Intel ja seinen Murks zu Gunsten der AMD-Architektur auf drängen Microsofts aufgegeben, also wer sich einen älteren Pentium 4 gekauft hat ist selbst schuld, er hat sich vorher nicht richtig informiert, und hat hier eben eine Geschwindigkeitsbremse bei der Main-Unit (ist aber im Gesammten gesehen immer noch performanter als ganz ohne float). | Quote: | | It's based on sixteen 64-bit integer and sixteen 128-bit vector/floating point (XMM) registers |
| Quote: | | Copying floating point data can basically be done in two ways. Either by using CPU registers as temporary storage or by using the FPU stack. Using SSE on P3 or SSE/SSE2 on P4 can also do it. |
Treffe ich zudem hierbei den Nagel auf den Kopf wenn ich vom Compilerflag -m64 rede, das Optimierung dann einfacher von statten geht?
"Older 8086 modes are supported in a separate "legacy" mode. These changes give compilers a larger, more regular register set to use making optimizations easier."
Kleine Notiz am Rande für nicht Techniker: | Quote: | Arithmetic Logic Unit
Die ALU ist der eigentliche Rechner. In ihr werden alle arithmetische und logische
Funktionen und Berechnungen ausgeführt. Zur ALU gehören auch der Akku(Speicher) und die Flags(Ereignisspeicher).
Eine Maschinensprache hat folgende Befehlsarten:
Arithmetische Befehle(Grundrechenarten)
Logische Befehle(logische Grundverknüpfungen)
Registrieranweisungen
Sprungbefehle
Unterprogrammbehandlung
-----------------------------------------------
Der Burst-Modus der auch von der SSE(2) Einheit aber nicht von der FPU i387 unterstützt wird:
In diesem Modus kann ein zusammenhängender Speicherblock übertragen werden. Ab einer
Startadresse kann ein beliebig großer Speicherblock, ohne weitere Adressierung, übertragen
werden.
Ein Latenz-Timer sorgt dafür, dass ein langer Burst unterbrochen werden kann, wenn eine
andere Komponente den PCI-Bus benötigt. |
Kleiner Aufruf an alle Programmierer, bitte nutz zur Multimediaprogrammierung Bild,Audio,Video mehr die 128 Bit- und Burstvorteile der SSE Technologie, für ältere CPUs und AMD einzeln auch gerne MMX und 3D Now. Den diese Befehlssätze sind extra für Multimedia entwickelt worden. 
_________________
AMD Phenom II x4 >> CFLAGS="-march=amdfam10 -O2 -mmmx -msse3 -mfpmath=sse,387 -pipe -ffast-math" is stable and here in use.
Did Intel produce at any time bugfree HW?
http://www.urbanmyth.org/microcode/
http://www.heise.de/newsticker/meldung/91748 |
|
| Back to top |
|
|
UTgamer
Veteran
Joined: 10 Aug 2003
Posts: 1326
Location: Troisdorf (Köln) Deutschland
|
| Posted: Tue May 22, 2007 3:54 pm Post subject: |
|
|
 Damit der Thread nicht einschläft fiel mir gerade ein das wir eine kleine Benchmarksammlung zu unserer Diskussion einfügen könnten.
============================================================
Test A
Also ich habe da diesen Benchmark http://www.cs.virginia.edu/stream/ ausfindig gemacht und ohne an irgendwelchen Parametern zu schrauben diese Werte erhalten:
| Code: |
Function Rate (MB/s) Avg time Min time Max time
Copy: 1447.4347 0.0222 0.0221 0.0225
Scale: 1458.1276 0.0220 0.0219 0.0221
Add: 1619.4354 0.0299 0.0296 0.0305
Triad: 1617.6918 0.0299 0.0297 0.0301
-------------------------------------------------------------
Solution Validates
------------------------------------------------------------- |
Die Kompilierung ist auf einfachster Stufe, herunterladen von:
http://www.cs.virginia.edu/stream/FTP/Code/stream.c
und
http://www.cs.virginia.edu/stream/FTP/Code/mysecond.c
, dann einfach mit gcc -O stream.c -o stream kompilieren, das dauert keine Sekunde
Bitte nicht optimieren auf irgendwas, es wäre schön wenn wir gleiche Ergebnisse bekämen, ich habe auch nicht auf den DualCore eingestellt.
============================================================
Test B
Jetzt habe ich hier den 2. Benchmark: http://r-goetz.de/RGBench/
Die Seite hat auch sehr viele aktuelle Vergleichswerte.
Den habe ich folgendermaßen mit meinen Standart USE-Flags eingestellt (wie nach Anleitung):
CC= gcc -march=athlon64 -O2 -msse3 -mfpmath=sse,387 -pipe -ffast-math -m64
Das Kompilieren hat rund 3 Sekunden gedauert
Dies sind meine Werte unter X: | Code: |
Task : estim.| absoulte | relative | Speed |
: memory| speed | speed | relative |
: usage | absoulte | relative | to PM7500 |
-------------------+-----------+----------+-----------|
MC - 250 : 0.5 | 14.09 | 100.00 | 2988.10 |
MC - 500 : 2.0 | 13.34 | 94.66 | 4362.91 |
MC - 1000 : 8.0 | 11.28 | 80.01 | 3894.43 |
MD - 500 : 0.5 | 216.09 | 100.00 | 3709.60 |
MD - 1000 : 2.0 | 207.52 | 96.03 | 4347.55 |
MD - 2000 : 8.0 | 209.75 | 97.07 | 4432.79 |
MCI- 12500 : 0.5 | 3029.85 | 100.00 | 4580.12 |
MCI- 60000 : 2.0 | 1669.69 | 55.11 | 2782.81 |
MCI-200000 : 8.0 | 1491.20 | 49.22 | 2788.54 |
-------------------+-----------+----------+-----------|
Averages:
by task by size speed loss
with mem size
MD : 4163.31 0.5MB : 3759.27 0.00
MC : 3748.48 2.0MB : 3831.09 -18.07
MCI : 3383.82 8.0MB : 3705.25 -24.57
single Core Throughput
float Average : 3955.90 3955.90
integer Average : 3383.82 3383.82
total Average : 3727.07 3727.07 |
Dies sind meine Werte auf der Konsole: | Code: |
Task : estim.| absoulte | relative | Speed |
: memory| speed | speed | relative |
: usage | absoulte | relative | to PM7500 |
-------------------+-----------+----------+-----------|
MC - 250 : 0.5 | 14.22 | 100.00 | 3015.01 |
MC - 500 : 2.0 | 13.44 | 94.50 | 4394.83 |
MC - 1000 : 8.0 | 11.39 | 80.10 | 3933.87 |
MD - 500 : 0.5 | 217.74 | 100.00 | 3737.87 |
MD - 1000 : 2.0 | 209.18 | 96.07 | 4382.22 |
MD - 2000 : 8.0 | 211.04 | 96.92 | 4459.97 |
MCI- 12500 : 0.5 | 2923.62 | 100.00 | 4419.54 |
MCI- 60000 : 2.0 | 1662.46 | 56.86 | 2770.76 |
MCI-200000 : 8.0 | 1408.73 | 48.18 | 2634.32 |
-------------------+-----------+----------+-----------|
Averages:
by task by size speed loss
with mem size
MD : 4193.35 0.5MB : 3724.14 0.00
MC : 3781.23 2.0MB : 3849.27 -17.52
MCI : 3274.87 8.0MB : 3676.05 -24.93
single Core Throughput
float Average : 3987.29 3987.29
integer Average : 3274.87 3274.87
total Average : 3702.33 3702.33 |
Meine Werte sind teils um einiges langsamer als die Werte auf seiner Webseite. Naja wenn einige kaum Dienste am laufen haben.
============================================================
Laßt mal bitte eure Werte vergleichen.
Für die Diskussion interresieren mich ja ganz besonders die fast-math Werte. Bei ähnlichen Proßessorgeschwindigkeiten (meine 3,8 GHz Athlon64).
Jetzt bitte nicht jeder wenn bereits mit ähnlichen HW-/Softwareprofilen gepostet wurde.
_________________
AMD Phenom II x4 >> CFLAGS="-march=amdfam10 -O2 -mmmx -msse3 -mfpmath=sse,387 -pipe -ffast-math" is stable and here in use.
Did Intel produce at any time bugfree HW?
http://www.urbanmyth.org/microcode/
http://www.heise.de/newsticker/meldung/91748 |
|
| Back to top |
|
|
firefly
Watchman
Joined: 31 Oct 2002
Posts: 5329
|
| Posted: Tue May 22, 2007 5:57 pm Post subject: |
|
|
Da die x86 Architektur auf der "von neumann maschine" beruht, ist die CPU komplett "blockiert", wenn eine der subeinheiten der CPU Daten liest oder schreibt (von Register zu Register, Register zu RAM oder RAM zu Register). Denn die "von neumann maschine" ist eine ein-bus architektur, sprich ein Datenbus, ein Addressbus und ein Steuerbus.
Es kann gut sein das in modernen CPUs intern mehrere Datenbusse gibt aber spätestens wenn es nach ausen geht existiert nur ein Daten-, Address und ein Steuerbus.
Druch pipelining kann man etwas performance heraushohlen da dann subeinheiten eventuell über einen eigenen bus daten austauschen können. Aber je länger die pipeline wird desto geringer wird der performance schub ausfallen,bei höhren Tagtraten, da die CPU "länger" auf das ergebniss warten muss.
Soweit ich weis, ist Intel dadurch mal ganz schön auf die Schnauze gefallen. Denn Intel hat bis vor kurzen den weg verfolgt, eine höhere Performance durch reine Taktraten Steigerung zu erreichen. Da die pipeline in Intel Cpus schon zum teil "extrem" lang war, wurden die CPUs, meines wissen nach, sehr instabil bei Taktraten über 3 Ghz.
_________________
Ein Ring, sie zu knechten, sie alle zu finden,
Ins Dunkel zu treiben und ewig zu binden
Im Lande Mordor, wo die Schatten drohn. |
|
| Back to top |
|
|
firefly
Watchman
Joined: 31 Oct 2002
Posts: 5329
|
| Posted: Tue May 22, 2007 5:59 pm Post subject: |
|
|
| UTgamer wrote: |
Für die Diskussion interresieren mich ja ganz besonders die fast-math Werte. Bei ähnlichen Proßessorgeschwindigkeiten (meine 3,8 GHz Athlon64). |
ähm du hast kein 3.8Ghz Athlon 64. Die 3800+ angabe spiegelt nicht den realtakt wieder. Der Athlon64 3800+ ist hat einen realtakt von 2.4 GHz
_________________
Ein Ring, sie zu knechten, sie alle zu finden,
Ins Dunkel zu treiben und ewig zu binden
Im Lande Mordor, wo die Schatten drohn. |
|
| Back to top |
|
|
UTgamer
Veteran
Joined: 10 Aug 2003
Posts: 1326
Location: Troisdorf (Köln) Deutschland
|
| Posted: Tue May 22, 2007 9:43 pm Post subject: |
|
|
| firefly wrote: | Da die x86 Architektur auf der "von neumann maschine" beruht, ist die CPU komplett "blockiert", wenn eine der subeinheiten der CPU Daten liest oder schreibt (von Register zu Register, Register zu RAM oder RAM zu Register). Denn die "von neumann maschine" ist eine ein-bus architektur, sprich ein Datenbus, ein Addressbus und ein Steuerbus.
Es kann gut sein das in modernen CPUs intern mehrere Datenbusse gibt aber spätestens wenn es nach ausen geht existiert nur ein Daten-, Address und ein Steuerbus. |
Ja stimmt für den "alten" Intel Weg, aber AMD hat mit dieser Bremse gebrochen, und nun läuft auch die AMD64 Optimierung auf den Intel 64ern.
| firefly wrote: | Druch pipelining kann man etwas performance heraushohlen da dann subeinheiten eventuell über einen eigenen bus daten austauschen können. Aber je länger die pipeline wird desto geringer wird der performance schub ausfallen,bei höhren Tagtraten, da die CPU "länger" auf das ergebniss warten muss.
Soweit ich weis, ist Intel dadurch mal ganz schön auf die Schnauze gefallen. Denn Intel hat bis vor kurzen den weg verfolgt, eine höhere Performance durch reine Taktraten Steigerung zu erreichen. Da die pipeline in Intel Cpus schon zum teil "extrem" lang war, wurden die CPUs, meines wissen nach, sehr instabil bei Taktraten über 3 Ghz. |
Das Bündeln von CPU und MMU soll heissen, das sogar neuerdings die IOMMU/Northbridge
zusammen auf dem einen CPU-Chip gebündelt werden, wegen der Pipelineschwäche des alten Intel Architekturerbes. Und wieder mal ist AMD vorraus.
Die IOMMU-Einheit in Athlons ist auch nicht neu, die gab es bereits seit 2002 in einem anderen Athlon Modell: | Quote: | | Alle Hammer haben einen integrierten Memory-Controller, der beim Opteron als Zweikanal-DDR-Interface mit einer theoretischen Bandbreite von 8,4 GByte/s mit PC2100- und 10,8 GByte/s mit PC2700-Modulen ausgelegt ist. |
Sie wird jetzt nur verbessert.
| firefly wrote: | | UTgamer wrote: |
Für die Diskussion interresieren mich ja ganz besonders die fast-math Werte. Bei ähnlichen Proßessorgeschwindigkeiten (meine 3,8 GHz Athlon64). |
ähm du hast kein 3.8Ghz Athlon 64. Die 3800+ angabe spiegelt nicht den realtakt wieder. Der Athlon64 3800+ ist hat einen realtakt von 2.4 GHz |
Ja weiss ich, es fehlte das + Zeichen dabei. Genau dies ist es ja warum seit dem Aufkommen der Athlons Intel mit ihrer "Von Neumann Architektur" nicht mehr die Innovationsliste von den Beiden anführt.
Ich denke da AMD mit IBM zusammen in der Prozessorentwicklung tätig ist, hat AMD das Wissen um die Änderungen von IBM erhalten. Das die Coprozessoren auf den Athlons nicht mehr die CPU blockieren hatte IBM bereits in seiner 68000 Reihe, wie auch damals Motorola (Amiga/Apple/Atari).
Das habe ich woanders bereits häufiger gelesen, das IBM Know-How hinzusteuert, die IO-MMU Geschichte die in der nächsten Generation kommt hatte bereits auch mein 68030 Amiga vor 16 Jahren.
Es ist heute auf allen Athlons und auf den von Intel eingekauften "Core 2 Duos" einfach nicht mehr der Fall das eine SSE(x) oder MMX Einheit die CPU blockiert. Bis zur Intel Pentium D Reihe stimmt deine Aussage noch mit der "Von Neumann Architektur".
AMD/IBM mischen gerade Intel auf. *g*
Ich als alter 68000er Fan, war schon immer gegen Intel eingestellt, damals prangte noch auf meinem Amiga-Desktop ein riesiges Intel Outside Logo; Intel ist heute noch nicht so weit wie Motorolla/IBM es vor 20 Jahren waren. Mit Taktraten kann Intel allerdings am besten von allen umgehen, das Geld für die kleinere Dye-Technik haben sie ja.
Dieser Artikel verdeutlicht auch nochmal die Struckturänderung die AMD 1999 in seinen Athlon hat einfließen lassen: http://www.heise.de/ct/99/16/088/
| Quote: | | Athlon ist mit einem neuen Prozessor-Bus ausgestattet, dessen Protokoll AMD von dem Hersteller eines der schnellsten Mikroprozessoren überhaupt, Digital, übernommen hat. Den Versuch eines eigenständigen Prozessorbusses hat seinerzeit mal die Prozessorschmiede NexGen unternommen - der Versuch scheiterte kläglich: NexGen wurde schließlich von AMD aufgekauft und ihr Design floss in den K6 ein, den AMD wieder in kompatibles Sockel-7-Format presste. |
| Quote: | Wie unsere Benchmarkergebnisse belegen, schlägt er den Pentium III bei gleichem Takt in nahezu allen Belangen. Zum Teil, etwa im Gleitkomma-Bereich, düpiert er den Herausgeforderten geradezu. Ja, es gibt sogar einen Benchmark bei SPECfp95 (fpppp), wo Athlon sensationell um den Faktor drei schneller ist. Als i-Tüpfelchen kommt dabei noch hinzu, dass die Benchmarks mit den Intel- C++- und Fortran-Compilern übersetzt wurden, die wohl kaum im Ruf stehen, speziell für Athlon zu optimieren.
Benchmarks wie SPECfp95 oder die BAPCo-Suite mied AMD früher wie der Teufel das Weihwasser - nun sind sie auf einmal AMDs Lieblinge - und ganz zufällig mag Intel auf einmal die BAPCo-Suite gar nicht mehr. Und auch typische Benchmarks aus Intels Drei-Welten-Theorie (Integer, MMX, FPU) wie der hauseigene Media Bench stehen nun in einem gänzlich anderen Lichte da. Wissenschaftler, die sich die SPECfp95-Ergebnisse anschauen, müssen einfach in Scharen zum Athlon überlaufen, was dessen Ruf sicherlich gut tut. |
Das macht der Athlon eben bereits seit 8 Jahren. Schöne Integergrüße an die Intelfraktion.
Jeder der ein Athlondesign ohne "-ffast-math" nutzt verschenkt sehr viel Leistung. Sollte eine einzelne schlecht programmierte Anwendung mal Probleme haben, kann genau für diese das "-ffast-math" ja abgeschaltet werden. Solch eine Anwendung ist z.B. sys-devel/gdb, eine weitere ist mir zur Zeit nicht bekannt.
_________________
AMD Phenom II x4 >> CFLAGS="-march=amdfam10 -O2 -mmmx -msse3 -mfpmath=sse,387 -pipe -ffast-math" is stable and here in use.
Did Intel produce at any time bugfree HW?
http://www.urbanmyth.org/microcode/
http://www.heise.de/newsticker/meldung/91748 |
|
| Back to top |
|
|
mv
Watchman
Joined: 20 Apr 2005
Posts: 6780
|
| Posted: Wed May 23, 2007 8:29 am Post subject: |
|
|
| UTgamer wrote: | | Jeder der ein Athlondesign ohne "-ffast-math" nutzt verschenkt sehr viel Leistung. |
Wie kommst Du denn auf diese Aussage? -ffast-math hat nichts mit Athlon vs. Intel zu tun. Schau Dir doch nochmal in der manpage an, welche Schalter -ffast-math genau umlegt, und was das bewirkt: Es geht jeweils nur um die Frage, ob ein paar zusätzliche Code-Befehle für Exceptions u.ä. eingebaut werden, falls sich Programme auf die dokumentierte Behandlung dafür verlassen. |
|
| Back to top |
|
|
UTgamer
Veteran
Joined: 10 Aug 2003
Posts: 1326
Location: Troisdorf (Köln) Deutschland
|
| Posted: Wed May 23, 2007 10:52 am Post subject: |
|
|
| mv wrote: | | UTgamer wrote: | | Jeder der ein Athlondesign ohne "-ffast-math" nutzt verschenkt sehr viel Leistung. |
Wie kommst Du denn auf diese Aussage? -ffast-math hat nichts mit Athlon vs. Intel zu tun. Schau Dir doch nochmal in der manpage an, welche Schalter -ffast-math genau umlegt, und was das bewirkt: Es geht jeweils nur um die Frage, ob ein paar zusätzliche Code-Befehle für Exceptions u.ä. eingebaut werden, falls sich Programme auf die dokumentierte Behandlung dafür verlassen. |
Diese Diskussion pro/kontra fast-math führte 2001 bereits dewar (von http://www.adacore.com/home/company/) mit Linus Torvalds.
Das Englisch ist nicht ganz einfach: http://gcc.gnu.org/ml/gcc/2001-07/msg02151.html
Dort ging es auch um noch von Hand aufgebesserte Assembleroptimierung um den Punkt den Obrut ansprach zu verhindern. | obrut<- wrote: | | ... selbst wenn die fpus stärker genutzt würden, so wäre "die cpu" trotzdem nicht frei. fpu und alu teilen sich dieselben befehlsdecoder, von denen es üblicherweise nur 3 oder 4 gibt. wenn jetzt die 3 decoder eines athlon dessen fpus befeuern, von denen es immerhin 3 gibt (je einmal fmul, fadd und fmisc), dann laufen die alus leer, da sie keinen nachschub bekommen. der k10 wird wie auch die aktuellen cpus von intel 4 decoder bekommen um die verschiedenen funktionseinheiten besser auslasten zu können. |
Wieder bezog sich dies einzig um die "Von Neuman Architektur" von Intel. Als Beispiel nannte Torvalds Quake3 mit seiner Handoptimierung bei Laufzeiten. Da der Athlon jedoch einen eigenständigen CPU-Buss besitzt hätte sich ID-Software an Q3 jede Menge Arbeit sparen können. Aber Q3 ist ja leider noch älter, und war auch das schnellste Spiel was ich damals kannte.
Nun ein kleines Zitat einer deutschen Seite (2005), http://www.heise.de/newsticker/meldung/print/58863 | Quote: | | Die 64-Bit-Welle hat auch vor der GCC nicht Halt gemacht: Ein Reihe mathematischer Funktionen wie asin, acos oder log10 sind nun als Intrinsics für die AMD64-Befehlssatzerweiterung verfügbar, sofern man seinen Code mit dem GCC-Schalter -ffast-math übersetzt. Vergleichbares gibt es auch für die Itanium-Plattform (IA-64), wo Gleitkomma- und Ganzzahl-Divisionen sowie Quadratwurzelberechnungen nun inline stattfinden. |
Anmerkend weiß ja jeder das Intel-Itanium eine Totgeburt war.
Die Beschreibung im man zu -ffast-math ist sehr eingeschrängt. Ich zitiere einmal die Funktionen die der GCC für -ffast-math nur für "inline x87" bereithält direkt von http://gcc.gnu.org/, und worauf man verzichten muß ohne.
Also nach http://gcc.gnu.org/gcc-4.0/changes.html | Quote: | New Targets and Target Specific Improvements
...
IA-32/x86-64 (AMD64)
* The acos, asin, drem, exp10, exp2, expm1, fmod, ilogb, log10, log1p, log2, logb and tan mathematical builtins (and their float and long double variants) are now implemented as inline x87 intrinsics when using -ffast-math.
* The ceil, floor, nearbyint, rint and trunc mathematical builtins (and their float and long double variants) are now implemented as inline x87 intrinsics when using -ffast-math.
* The x87's fsincos instruction is now used automatically with -ffast-math when calculating both the sin and cos of the same argument.
* Instruction selection for multiplication and division by constants has been improved. |
Der man Eintrag nochmal aktuell für 4.1.2 aus dieser Doku http://gcc.gnu.org/onlinedocs/gcc-4.1.2/gcc/Floating-point-implementation.html#Floating-point-implementation
| Quote: | # Whether and how floating expressions are contracted when not disallowed by the FP_CONTRACT pragma (C99 6.5).
Expressions are currently only contracted if -funsafe-math-optimizations or -ffast-math are used. This is subject to change. |
Zu SSE- oder MMX-Befehlen habe ich jetzt erstmal auf die Schnelle leider nichts gefunden.
Weitere Markierungen in dem Text sagen auch das einige Optimierungen nicht in GCC selbst sondern in der C Biblithek hinterlegt sind. (Das geht mir aber zu tief in C, komme nur aus der ASM-Ecke.)
Also warum sollten "inline x87", SSE(x) und MMX bei mathematischen und Multimediaoperationen nicht das System beschleunigen? Das die CPU blockiert wird (Register-/Stackcharing) von den floats findet nur auf Intel und nicht AMD Prozessoren statt.
Ich mische ja auch noch die Register mit -sse,387 
| Quote: | -sse,387
Attempt to utilize both instruction sets at once. This effectively double the amount of available registers and on chips with separate execution units for 387 and SSE the execution resources too. Use this option with care, as it is still experimental, because the GCC register allocator does not model separate functional units well resulting in instable performance. |
Aber instabil wie erwähnt ist hier überhaupt nichts, scheint wohl wieder mal nur für Intels zu gelten. *g*
Hier noch ein Artikel von Intel selbst http://www.intel.com/cd/ids/developer/asmo-na/eng/dc/itanium/275924.htm?page=3 | Quote: |
The current version of the GNU Compiler Collection (GCC) by the Free Software Foundation is a minor release of 4.0. In moving to GCC 4.0, the GCC team adopted a new optimization framework called Tree-SSA7. This has enabled them to perform more optimizations, and improve the performance of existing optimizations.
Fluent, working with Intel, tested the quality of the code produced by GCC and the Intel compiler by benchmarking their solver on a 3.4 GHz Intel Xeon dual-processor system with 16 GB of memory. They tested a serial version of FLUENT, using only one processor. This prevented interconnect and communication library performance from affecting the results.
Three binaries were produced: one with GCC 4.08, one with GCC 4.0 with fast math enabled, and one with the Intel compiler and Math Library. The "-ffast-math" switch for GCC uses more efficient floating point routines than the standard math library (libm). These routines disable error-checking and sacrifice accuracy in certain cases, but this may be justified by the usually substantial performance improvement. |
Selbst Intel gibt zu das die Performance gesteigert wird.
_________________
AMD Phenom II x4 >> CFLAGS="-march=amdfam10 -O2 -mmmx -msse3 -mfpmath=sse,387 -pipe -ffast-math" is stable and here in use.
Did Intel produce at any time bugfree HW?
http://www.urbanmyth.org/microcode/
http://www.heise.de/newsticker/meldung/91748 |
|
| Back to top |
|
|
mv
Watchman
Joined: 20 Apr 2005
Posts: 6780
|
| Posted: Wed May 23, 2007 11:37 am Post subject: |
|
|
| UTgamer wrote: | | Quote: | * The acos, asin, drem, exp10, exp2, expm1, fmod, ilogb, log10, log1p, log2, logb and tan mathematical builtins (and their float and long double variants) are now implemented as inline x87 intrinsics when using -ffast-math.
* The ceil, floor, nearbyint, rint and trunc mathematical builtins (and their float and long double variants) are now implemented as inline x87 intrinsics when using -ffast-math.
* The x87's fsincos instruction is now used automatically with -ffast-math when calculating both the sin and cos of the same argument.
* Instruction selection for multiplication and division by constants has been improved. |
|
Ich bin baff: Das scheint in der Tat zu stimmen und auch noch für 4.1.2 gültig zu sein. Es ist mir vollkommen schleierhaft, wieso dies nicht automatisch sondern nur bei Benutzung von -fast-math geschieht. Die man-/infopage gibt offensichtlich Falschinformationen, denn mit der dortigen Beschreibung, dass -fast-math nur ein paar andere Flags setzt (die offensichtlich nichts damit zu tun haben) hat das überhaupt nichts zu tun. |
|
| Back to top |
|
|
UTgamer
Veteran
Joined: 10 Aug 2003
Posts: 1326
Location: Troisdorf (Köln) Deutschland
|
| Posted: Wed May 23, 2007 12:13 pm Post subject: |
|
|
Ich bin froh das du das meist brach liegende Potenzial erkannt hast.
Es gibt noch eine Erweiterung die bereits längst in AMD64 eingeflossen ist.
Eine ältere Diskussion darüber ist hier zu finden http://gcc.gnu.org/ml/gcc/2005-08/msg00270.html
Wobei die dort erwähnte crtfastmath.c kein i386 Code ist sondern z.B. von IA64.
Früher gab man z.B. :
"CFLAGS="-march=athlon64 -O2 -pipe -frename-registers -fweb -ffast-math -mfpmath=sse -ftracer -funroll-loops -fstack-protector "
als seine CFlags an.
Aber das ist überhohlt:
-mfpmath=sse is the default choice for the x86-64 compiler.
SSE bietet noch weit mehr Funktionen und Geschwindigkeit als float.
_________________
AMD Phenom II x4 >> CFLAGS="-march=amdfam10 -O2 -mmmx -msse3 -mfpmath=sse,387 -pipe -ffast-math" is stable and here in use.
Did Intel produce at any time bugfree HW?
http://www.urbanmyth.org/microcode/
http://www.heise.de/newsticker/meldung/91748 |
|
| Back to top |
|
|
schachti
Advocate
Joined: 28 Jul 2003
Posts: 3765
Location: Gifhorn, Germany
|
| Posted: Wed May 23, 2007 12:24 pm Post subject: |
|
|
Du hast mich ja fast ueberzeugt, auf meinem (32-bittigen) Athlon64 X2 System mal -ffast-math auszuprobieren...
_________________
Never argue with an idiot. He brings you down to his level, then beats you with experience.
How-To: Daten verschlüsselt auf DVD speichern. |
|
| Back to top |
|
|
UTgamer
Veteran
Joined: 10 Aug 2003
Posts: 1326
Location: Troisdorf (Köln) Deutschland
|
| Posted: Wed May 23, 2007 1:27 pm Post subject: |
|
|
@ schachti, keine Sorge das System bleibt weiterhin genauso stabil wie vorher.
Du merkst die Beschleunigung am allermeisten beim GQview, weitere Anwendungen bei denen man richtig was spürt hatte ich im Verlauf auch genannt.
Ich bin mir nicht ganz sicher ob es mit diesen Compilerflags zusammenhängt aber das Abspeichern auf Festplatte unter reiserfs 3.6 geht auch flotter, bei ext3 habe ich jedoch nichts gemerkt, daher habe ich vor rund 2 Monaten von Mischfilesystemen auf den gleichen Platten (Debian Kernel 2.6.18.x/Gentoo) alles auf reiserfs umgestellt, und nicht einmal einen Fehler in den 1,5 Jahren auf dem 64er bekommen, kann aber auch eine Inlinekernelverbesserung sein. Oder die CPU hat doch soviel mehr Freiraum bekommen das die Flags sich auswirken. Ich habe ja das gesammte System damit erstellt icl. aller Treiber, eine Optimierung mehr oder weniger kann sich schon merkbar auswirken.
_________________
AMD Phenom II x4 >> CFLAGS="-march=amdfam10 -O2 -mmmx -msse3 -mfpmath=sse,387 -pipe -ffast-math" is stable and here in use.
Did Intel produce at any time bugfree HW?
http://www.urbanmyth.org/microcode/
http://www.heise.de/newsticker/meldung/91748 |
|
| Back to top |
|
|
Keruskerfuerst
Advocate
Joined: 01 Feb 2006
Posts: 2289
Location: near Augsburg, Germany
|
| Posted: Mon Jun 18, 2007 7:05 am Post subject: |
|
|
| erhöht die Leistungsfähigkeit des System auch. |
|
| Back to top |
|
|
Storm.Xapek.de
Tux's lil' helper
Joined: 09 Feb 2006
Posts: 97
|
| Posted: Mon Jun 18, 2007 2:25 pm Post subject: |
|
|
| Keruskerfuerst wrote: | | erhöht die Leistungsfähigkeit des System auch. |
??
Warum sollte das die "Leistungsfähigkeit des Systems" erhöhen?
Klas boost ist ne feine Sache wenn mans plattformunabhängig will,
aber was hat boost mit Leistungsfähigkeit zu tun? |
|
| Back to top |
|
|
|
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
|
Deutsches Forum (German)
