C++Talk.NET C++ language newsgroups   Archives   FAQ   Search   Memberlist   Usergroups   Register   Profile   Log in to check your private messages   Log in  Der alte Hochsprache vs. Assembler Streit Goto page 1, 2  Next          C++Talk.NET Forum Index -> C++ (German) View previous topic :: View next topic   Author Message Sascha T. Guest Posted: Wed Oct 06, 2004 8:02 am    Post subject: Der alte Hochsprache vs. Assembler Streit Hallo und herzliche Grüsse in dieses Forum, ich war einige (lange) Zeit weg vom "Coding-Fenster" und beginne gerade, mich wieder mit diesem Gebiet zu beschäftigen (-> bin also ein Re-Newbie). Konkret: Ich bin auf dem Stand von 1992, Motorola (Amiga). Ich freunde mich gerade mit C++ an, deshalb das Posting in dieses Forum. Damals war es üblich, geschwindigkeitskritische Routinen in Assembler zu coden und alles drumherum in C. (Footnote: geschwindigkeitskritisch: Häufige Zugriffe auf den Speicher, allgemeine mathematische Kalkulationen...) Mir wurde erzählt, dass die Compiler heutzutage (z.B. ICC, PGC) derart leistungsfähig wären, dass i.A. Assembler-Coding überflüssig wäre. 1.Frage: Ist das wahr? Ich kann nicht glauben, dass irgendein Compiler derart optimiert ist, dass er besser als ein Mensch entscheiden kann, welches die minimale Anzahl an und optimale Kombination aus Anweisungen ist, die ein Prozessor benötigt, um eine Aufgabe auszuführen. 2.Frage: Fortran: Wenn es denn nun darum geht, geschwindigkeitskritische Routinen zu implementieren und auf Assembler zu verzichten, würde es tatsächlich noch einen Vorteil bringen, diese in Fortran zu coden und mit C/C++-Objekten zu verlinken? Bin auf Euere Meinungen gespannt und auch für Links zu diesem Thema dankbar! Gruss Sascha ----------------------------- E=mc^2 -> I really *mean* it! ----------------------------- -- de.comp.lang.iso-c++ - Moderation: mailto:voyager+mod (AT) bud (DOT) prima.de FAQ: http://www.voyager.prima.de/cpp/ mailto:voyager+send-faq (AT) bud (DOT) prima.de Back to top Enrico Thierbach Guest Posted: Wed Oct 06, 2004 10:25 am    Post subject: Re: Der alte Hochsprache vs. Assembler Streit Quote: Mir wurde erzählt, dass die Compiler heutzutage (z.B. ICC, PGC) derart leistungsfähig wären, dass i.A. Assembler-Coding überflüssig wäre. 1.Frage: Ist das wahr? Ich kann nicht glauben, dass irgendein Compiler derart optimiert ist, dass er besser als ein Mensch entscheiden kann, welches die minimale Anzahl an und optimale Kombination aus Anweisungen ist, die ein Prozessor benötigt, um eine Aufgabe auszuführen. Nur ganz kurz (da IMHO off-topic): das Problem ist eher, daß die 92er Methode, Assembler zu coden, ja dann so ging, daß man anhand von Tabellen die Takte, die ein bestimmter Befehl gebraucht hat, addierte, um dann die resultierende Gesamtlaufzeit zu bestimmen. Das geht aber heute nicht mehr: Die Laufzeit eines Befehls hängt u.a. auch von der Reiehnfolge der Befehle ab (Branch-Prediction, Parallelism etc. pp.) Und die so entstehende Komplexität schafft der Compiler auf jeden Fall besser wie der Mensch. Alle Artikel, die ich in letzter Zeit darüber gelesen hatte, zogen das Fazit: Hand-Assembler macht nur noch Sinn, wenn man MMX/3D Now braucht. Bei allem anderen ist das Quatsch. /eno -- de.comp.lang.iso-c++ - Moderation: mailto:voyager+mod (AT) bud (DOT) prima.de FAQ: http://www.voyager.prima.de/cpp/ mailto:voyager+send-faq (AT) bud (DOT) prima.de Back to top Rolf Magnus Guest Posted: Wed Oct 06, 2004 10:34 am    Post subject: Re: Der alte Hochsprache vs. Assembler Streit Sascha T. wrote: Quote: Hallo und herzliche Grüsse in dieses Forum, ich war einige (lange) Zeit weg vom "Coding-Fenster" und beginne gerade, mich wieder mit diesem Gebiet zu beschäftigen (-> bin also ein Re-Newbie). Konkret: Ich bin auf dem Stand von 1992, Motorola (Amiga). Ich freunde mich gerade mit C++ an, deshalb das Posting in dieses Forum. Damals war es üblich, geschwindigkeitskritische Routinen in Assembler zu coden und alles drumherum in C. (Footnote: geschwindigkeitskritisch: Häufige Zugriffe auf den Speicher, allgemeine mathematische Kalkulationen...) Mir wurde erzählt, dass die Compiler heutzutage (z.B. ICC, PGC) derart leistungsfähig wären, dass i.A. Assembler-Coding überflüssig wäre. 1.Frage: Ist das wahr? Ich kann nicht glauben, dass irgendein Compiler derart optimiert ist, dass er besser als ein Mensch entscheiden kann, welches die minimale Anzahl an und optimale Kombination aus Anweisungen ist, die ein Prozessor benötigt, um eine Aufgabe auszuführen. Ich nehme mal an, daß es um Desktop-Computer (also PC, Mac oder was auch immer) geht. Es gibt auch heute noch handoptimierte Assembler-Routinen, aber sie sind sehr stark reduziert. Die Frage ist auch nicht so sehr, ob der Compiler wirklich jeden einzelnen unnötigen Taktzyklus einsparen kann, sondern ob es in Zeiten von Multicore-CPUs mit 3GHz und mehr überhaupt noch eine Rolle spielt. Bei 1Ghz durchläuft die CPU in einer Millisekunde eine Million Taktzyklen. Außerdem können oft die meisten Operationen in einem Taktzyklus ausgeführt werden. Assembler wird manchmal noch z.B. bei Software eingesetzt, die mit Video zu tun hat, wo man unter Zuhilfenahme von entsprechnden CPU-Erweiterungen Kopieren oder Skalieren optimiert. Aber auch das wird immer seltener gebraucht, da man im Allgemeinen auf vorhandene Bibliotheken zugreift, die die Assemblerei hinter einem Hochsprachen-Interface wegkapseln oder die gleich entsprechend spezialisierte Hardware verwenden. Selbst Betriebssystem-Kernels enthalten meistens fast keinen Assemblercode mehr. Quote: 2.Frage: Fortran: Wenn es denn nun darum geht, geschwindigkeitskritische Routinen zu implementieren und auf Assembler zu verzichten, würde es tatsächlich noch einen Vorteil bringen, diese in Fortran zu coden und mit C/C++-Objekten zu verlinken? Ich kenne Fortran nicht, aber in C und C++ kann man schon sehr flotten Code produzieren. -- de.comp.lang.iso-c++ - Moderation: mailto:voyager+mod (AT) bud (DOT) prima.de FAQ: http://www.voyager.prima.de/cpp/ mailto:voyager+send-faq (AT) bud (DOT) prima.de Back to top dietmar_kuehl@yahoo.com Guest Posted: Wed Oct 06, 2004 10:52 am    Post subject: Re: Der alte Hochsprache vs. Assembler Streit Sascha T. wrote: Quote: Mir wurde erzählt, dass die Compiler heutzutage (z.B. ICC, PGC) derart leistungsfähig wären, dass i.A. Assembler-Coding überflüssig wäre. 1.Frage: Ist das wahr? Abgesehen von ein paar wenigen und sehr einfachen Ausnahmen, wie etwa 'memcpy()' (einfach in dem Sinne, dass die Operation eigentlich nichts kompliziertes macht), kann ein Mensch de facto die diversen Pipelines und Caches eines RISC Prozessors nicht überblicken. Das Ziel ist, dass auf jeden Taktzyklus ein Befehl pro Pipeline fertig wird. Da die Befehle jedoch mehr als einen Taktzklus brauchen (typischerweise vier oder fünf), werden immer mehrere Befehle gleichzeitig in einer Pipeline bearbeitet und es gibt dazu ggf. auch noch mehr als eine Pipeline (zB. drei Integer Pipelines plus 2 Floating Point Pipelines; wobei für letztere etwas andere Regeln gelten). Um die Sache etwas interessanter zu machen, gibt es ggf. Abhaengigkeiten, ab wann Ergebnisse von vorherigen Befehlen verwendet werden koennen, und bei bedingten Spruengen muessen ggf. die Befehle in der Pipeline abgebrochen werden, was Branch-Prediction sehr wichtig macht (wobei die teilweise sogar automatisch vom Prozessor gemacht wird...). Wenn man dann noch die unterschiedlichen Zugriffszeiten auf die unterschiedlichen Arten von Speicher (neben Hauptspeicher und Registern oft zwei Level von Caches) berücksichtigt, ahnt man dass das Problem etwas unuebersichtlich wird... Es gibt sicher ein paar Gründe, warum man gelegentlich ein paar Assembler-Befehler verwendet, aber die sind selten Performance. Der Hauptgrund für Assembler-Befehler ist, dass einige Operationen nicht direkt von Hochsprachen aus zugreifbar sind, etwa die Befehle für Multi-Threading wie "check and set". Allerdings sind solche Sachen normalerweise schon in irgendwelchen Bibliotheken zugreifbar. Quote: Ich kann nicht glauben, dass irgendein Compiler derart optimiert ist, dass er besser als ein Mensch entscheiden kann, welches die minimale Anzahl an und optimale Kombination aus Anweisungen ist, die ein Prozessor benötigt, um eine Aufgabe auszuführen. Mit beliebig viel Zeit kann man vielleicht etwas besseres hinbekommen, aber das lohnt sich nicht. Ausserdem war der m68k extrem einfach zu programmieren und es gab wenig zu beachten: Befehle wurden einfach sequentiell abgearbeitet und Caches waren weitgehend irrelevant, weil der Hauptspeicher ausreichend schnell zugegriffen werden konnte. Quote: 2.Frage: Fortran: Wenn es denn nun darum geht, geschwindigkeitskritische Routinen zu implementieren und auf Assembler zu verzichten, würde es tatsächlich noch einen Vorteil bringen, diese in Fortran zu coden und mit C/C++-Objekten zu verlinken? Möglicherweise. In Fortran werden oft Parallelisierungsmöglichkeiten besser ausgenutzt und es gibt bestimmte Aliasing-Probleme nicht. Wenn man allerdings keinen Rechner hat, der Vektoroperationen direkt unterstützt, dann relativiert sich das weitgehend, sofern man nicht allzu naiv programmiert (etwa für Vektor- und Matrizenoperationen wird man Expression-Templates a la Blitz++ verwenden, um temporaere Objekte zu verwenden). Persoenlich programmiere ich normalerweise erstmal eine funktionsfaehige Loesung. Wenn sich diese als zu langsame erweist, verbessere ich sie, wobei ich direkt gucke, wo die Performance-Probleme sind: normalerweise sind die Problem nicht dort, wo man sie vermutet. -- <mailto:dietmar_kuehl (AT) yahoo (DOT) com> <http://www.dietmar-kuehl.de/> <http://www.contendix.com> - Software Development & Consulting -- de.comp.lang.iso-c++ - Moderation: mailto:voyager+mod (AT) bud (DOT) prima.de FAQ: http://www.voyager.prima.de/cpp/ mailto:voyager+send-faq (AT) bud (DOT) prima.de Back to top Hendrik Belitz Guest Posted: Wed Oct 06, 2004 11:07 am    Post subject: Re: Der alte Hochsprache vs. Assembler Streit Sascha T. wrote: Quote: Mir wurde erzählt, dass die Compiler heutzutage (z.B. ICC, PGC) derart leistungsfähig wären, dass i.A. Assembler-Coding überflüssig wäre. 1.Frage: Ist das wahr? Ich kann nicht glauben, dass irgendein Compiler derart optimiert ist, dass er besser als ein Mensch entscheiden kann, welches die minimale Anzahl an und optimale Kombination aus Anweisungen ist, die ein Prozessor benötigt, um eine Aufgabe auszuführen. In 99 von 100 Fällen ist das wahr. Denn vieles, was Assembler-Programmierer von Hand optimieren, bringt auf den heutigen Prozessorarchitekturen nicht mehr viel. In den meisten Fällen produzieren sie sogar langsameren Code (bedenke, daß Assembleranweisungen heutzutage eben nicht mehr vollständig seriell, sondern über geschickte Pipelining-Architekturen abgearbeitet werden. Analog zu Murphy: Wer von Hand optimiert, übersieht dabei mindestens einen Fallstrick.). Bei einigen Compilern kann man evtl. noch etwas reißen, wenn man in den Bereich der erweiterten instruction sets eindringt, also SSE, MMX, 3DNow usw. Aber auch hier sind die compilerbedingten Optimierungen stark im Kommen. Zudem stößt man bei solchen Erweiterungen sehr schnell an die Grenzen der Portabilität. Quote: 2.Frage: Fortran: Wenn es denn nun darum geht, geschwindigkeitskritische Routinen zu implementieren und auf Assembler zu verzichten, würde es tatsächlich noch einen Vorteil bringen, diese in Fortran zu coden und mit C/C++-Objekten zu verlinken? AFAIK ist effizient programmiertes C++ genauso schnell, wenn nicht sogar schneller als Fortran77 oder Fortran90 (Dazu gibt es ein paar sehr schöne Artikel von einem Menschen namens Todd Verdhuizen. Einfach mal googlen). Zudem bezieht sich die Geschwindigkeit bei Fortran nahezu ausschließlich auf die dort sehr effizienten Datenstrukturen für die lineare Algebra, die teilweise parallel abgearbeitet werden (wenn ich mich recht entsinne). Außerhalb des mathematischen Anwendungsfeldes war Fortran nie schneller als C. -- To get my real email adress, remove the two onkas -- Hendrik Belitz - Abort, Retry, Fthagn? - -- de.comp.lang.iso-c++ - Moderation: mailto:voyager+mod (AT) bud (DOT) prima.de FAQ: http://www.voyager.prima.de/cpp/ mailto:voyager+send-faq (AT) bud (DOT) prima.de Back to top Peter Jutzies Guest Posted: Wed Oct 06, 2004 11:46 am    Post subject: Re: Der alte Hochsprache vs. Assembler Streit Sascha T. wrote: Quote: "Coding-Fenster" (Amiga) Das klingt so, als ob Du irgendwelche Demos schreiben willst. Schau nach in welcher Sprache deine Grafikbibliotheken unter deinem Betriebsystem am besten unterstuezt werden, und nimm die. Die Grafikkartenhersteller haben nicht alle ihre Funktionen dokumentiert. Du wirst nicht versuchen wollen an diesen Biliotheken vorbei zu programmieren. Das war schon zu Zeiten des Amigas aeusserst unschoen, da inkompatibel. Heutzutage ist das soagr ein richtiger Nachteil fuer dich. Bei den kurzen Produktzyklen gibt es schon wieder neue SuperDuperFeatures, bevor Du auch nur annaehernd heraus gefunden hast, wie alten funktionieren. Solltest Du aber dein Wissen dann in OpenSource-Treiber fuer Grafikkarten investieren, wird Dir Ruhm und Ehre gewiss sein ;-) Tsch"u"s Peter -- de.comp.lang.iso-c++ - Moderation: mailto:voyager+mod (AT) bud (DOT) prima.de FAQ: http://www.voyager.prima.de/cpp/ mailto:voyager+send-faq (AT) bud (DOT) prima.de Back to top Andreas Huennebeck Guest Posted: Wed Oct 06, 2004 1:37 pm    Post subject: Re: Der alte Hochsprache vs. Assembler Streit Sascha T. wrote: Quote: ich war einige (lange) Zeit weg vom "Coding-Fenster" und beginne gerade, mich wieder mit diesem Gebiet zu beschäftigen (-> bin also ein Re-Newbie). Konkret: Ich bin auf dem Stand von 1992, Motorola (Amiga). Ich freunde mich gerade mit C++ an, deshalb das Posting in dieses Forum. Damals war es üblich, geschwindigkeitskritische Routinen in Assembler zu coden und alles drumherum in C. (Footnote: geschwindigkeitskritisch: Häufige Zugriffe auf den Speicher, allgemeine mathematische Kalkulationen...) Mir wurde erzählt, dass die Compiler heutzutage (z.B. ICC, PGC) derart leistungsfähig wären, dass i.A. Assembler-Coding überflüssig wäre. 1.Frage: Ist das wahr? Ja. Ich habe einen Kurs in C-Programmierung fuer DSPs besucht, da haben wir einen typischen Algorithmus programmiert. Die optimierte C-Version war genauso schnell wie die beste Assembler- Variante, wobei letztere extrem kompliziert war, da die Pipeline und die beiden Register und ALU-Sets immer gefuellt sein mussten. Soweit ich mich noch erinnere, war die Daten etwa so: Aufgabe: Loop ueber 40 Operationen Add und Multiply von 16 Bit Int. 1. C-Variante ohne Optimierung: > 1000 Takte 2. C-Variante mit Optimierung: 38 Takte (!) 3. einfache Assembler-Variante: > 200 Takte 4. beste Assembler-Variante: 38 Takte Quote: Ich kann nicht glauben, dass irgendein Compiler derart optimiert ist, dass er besser als ein Mensch entscheiden kann, welches die minimale Anzahl an und optimale Kombination aus Anweisungen ist, die ein Prozessor benötigt, um eine Aufgabe auszuführen. Kann er, da er mehr Ueberblick hat ueber die aktuelle Belegung der Register und Pipeline, als Du Dir merken kannst und willst. Quote: 2.Frage: Fortran: Wenn es denn nun darum geht, geschwindigkeitskritische Routinen zu implementieren und auf Assembler zu verzichten, würde es tatsächlich noch einen Vorteil bringen, diese in Fortran zu coden und mit C/C++-Objekten zu verlinken? Nein. Fortran hinzuzulinken ist dann sinnvoll, wenn man den Fortran-Code nicht in C++ umschreiben moechte oder kann. Es gibt ja noch genug Mathebibliotheken in Fortran. Tschau Andreas -- Andreas Hünnebeck | email: [email]ah (AT) despammed (DOT) com[/email] ----- privat ---- | www : http://www.huennebeck-online.de Fax/Anrufbeantworter: 0721/151-284301 GPG-Key: http://www.huennebeck-online.de/public_keys/andreas.asc -- de.comp.lang.iso-c++ - Moderation: mailto:voyager+mod (AT) bud (DOT) prima.de FAQ: http://www.voyager.prima.de/cpp/ mailto:voyager+send-faq (AT) bud (DOT) prima.de Back to top Lutz Jacob Guest Posted: Wed Oct 06, 2004 6:43 pm    Post subject: Re: Der alte Hochsprache vs. Assembler Streit Am Wed, 06 Oct 2004 10:02:50 +0200 schrieb Sascha T.: Quote: Damals war es üblich, geschwindigkeitskritische Routinen in Assembler zu coden und alles drumherum in C. (Footnote: geschwindigkeitskritisch: Häufige Zugriffe auf den Speicher, allgemeine mathematische Kalkulationen...) Ich schließe mich dem an, was die anderen geschrieben haben. Ergänzen möchte ich noch, dass die wesentliche Optimierungsmöglichkeit, die nur Dir aber nicht dem Compiler offen steht, die Wahl der geeigneten Datenstrukturen und Algorithmen ist. In meiner bisherigen Programmiererfahrung war es bei Laufzeitproblemen immer wieder so, dass aufwendige Optimierung am Code Vorteile im Prozentbereich brachten, während durch Optmierung auf höherem Level oft Größenordnungen zu holen waren. Hier hilft einem auch C++ im Vergleich zu C ganz massiv, durch die in der STL verfügbaren und sehr unkompliziert nutzbaren Container und Algorithmen. Wenn man wirklich mal Performance-Probleme hat, ist es außerdem wichtig, zu messen, wo die Zeit wirklich verloren geht. Ansonsten sucht man oft an einer völlig falschen Stelle. Das Erlebnis mit handoptimiertem Assemblercode, der am Ende langsamer als die C++-Variante war, hatte ich übrigens auch schon. ciao Lutz -- de.comp.lang.iso-c++ - Moderation: mailto:voyager+mod (AT) bud (DOT) prima.de FAQ: http://www.voyager.prima.de/cpp/ mailto:voyager+send-faq (AT) bud (DOT) prima.de Back to top Markus Breuer Guest Posted: Wed Oct 06, 2004 8:38 pm    Post subject: Re: Der alte Hochsprache vs. Assembler Streit Sascha T. wrote: Quote: Damals war es üblich, geschwindigkeitskritische Routinen in Assembler zu coden und alles drumherum in C. (Footnote: geschwindigkeitskritisch: Häufige Zugriffe auf den Speicher, allgemeine mathematische Kalkulationen...) Mir wurde erzählt, dass die Compiler heutzutage (z.B. ICC, PGC) derart leistungsfähig wären, dass i.A. Assembler-Coding überflüssig wäre. 1.Frage: Ist das wahr? Kurz: ja Quote: Ich kann nicht glauben, dass irgendein Compiler derart optimiert ist, dass er besser als ein Mensch entscheiden kann, welches die minimale Anzahl an und optimale Kombination aus Anweisungen ist, die ein Prozessor benötigt, um eine Aufgabe auszuführen. Die heutigen Compiler setzten Code-Optimierer ein, an die du als Mensch kaum heranreichen kannst. Gibt es tatsächlich eine kritische Stelle im Code, so lässt man vom Compiler Assember erzeugen und bearbeitet ihn manuell nach. Wenn du Assembler programmierst, hast du folgende Nachteile: - dein Code ist nicht portabel, du schreibst ihn für eine bestimmte CPU. Allein bei Intel unterscheidet man 8086/80286/386/486 und Pentium - Der Quelltest eines Assemberprogrammes ist wesentlich umfangreicher, als der eines C/C++ Programms. Dem entsprechend ist die Gefahr von Fehlern größer, der Code ist weniger übersichtlich, Dritte benötigen lange Einarbeitungszeiten - Die Hardware wird von Generation zu Generation Leistungsfähiger. Schon vor Jahren hat man erkannt, dass wartbarer Code wichtiger ist, als assembler-optimierter Code. Glaubst du nicht? Bestes Beispiel sind relationale Datenbanken (Oracle,MySql,Postgres,SQL Server,...) => relationale Datenbanken waren aufgrund ihrer Mengen-Relation stets langsamer als etwa hierarchische DBs. Heute ist dieser Nachteil zu vernachlässigen, man will sie gut Administrieren und verwalten können. - In den Hoch-zeiten der Assembler wurden Programme exklusiv für die CPU geschrieben, in heutigen Zeiten hat man stets ein Betriebsystem, das zählt sogar schon für viele Embedded Systeme. Quote: 2.Frage: Fortran: Wenn es denn nun darum geht, geschwindigkeitskritische Routinen zu implementieren und auf Assembler zu verzichten, würde es tatsächlich noch einen Vorteil bringen, diese in Fortran zu coden und mit C/C++-Objekten zu verlinken? Jetzt machst du aber Sprünge: Assember nach Fortran. Wenn du C/C++ beherrscht, dann bewegst du dich sehr dicht am Optimum. Auf eine andere Hochsprache würde ich nur zurückgreifen, wenn ich mit weniger Aufwand mehr Leistung erhalte. Seit Jahren entwickle ich Software im Server-Bereich, kümmere mich als weniger um grafische Frontends als um max. Leistung beim Datendurchsatz, und habe hier noch nie die Notwendigkeit gesehen, verschiedene Sprachen zu mischen. Compiler der nächsten Generation sind gar in der Lage, dein Programm so zu zerlegen, dass es parallelisiert von der CPU ausgeführt werden kann. Die heutigen CPUs implementieren Featuren wie branch-prediction, also können die Wahrscheinlichkeit von Sprungoperationen im vorraus berechnen oder gar beide zweige Vorverarbeiten. Vergiss Assember und eigne dir eine Hochsprache an. Für einen Einsteiger ist Assember ungeeignet, lerne C/C++, Pascal, Java, Fortran oder Smalltalk (es gibt unzählige weitere Sprachen). Gruß Markus -- de.comp.lang.iso-c++ - Moderation: mailto:voyager+mod (AT) bud (DOT) prima.de FAQ: http://www.voyager.prima.de/cpp/ mailto:voyager+send-faq (AT) bud (DOT) prima.de Back to top Sascha T. Guest Posted: Thu Oct 07, 2004 7:07 am    Post subject: Re: Der alte Hochsprache vs. Assembler Streit Hi! Vielen Dank für die vielen, sehr nützlichen Antworten. Mir ist jetzt vieles klarer, vor allem, dass man heute die Geschwindigkeit von Programmen nicht mehr in Taktzyklen messen kann. Daran hatte ich nicht gedacht. Einige von euch haben gefragt, *wofür* ich optimieren möchte. Nun, es geht um "molecular dynamics" (MD) (-> googlen). Ganz kurz: Es geht darum, die Bewegung von Molekülen in Abhängigkeit von der Zeit zu simulieren (Numerische Lösung der Newton'sche Bewegungsintegrale für c.a. 60000 Atome * 3 Raumrichtungen * 107 Zeitschritte). Der Bottleneck ist also eindeutig das Lösen der Gleichungen. Wir haben berechnet, dass wir auf einem IBM SP4 mit 8 p655+ Prozessoren (je 1.5GhZ) die Berechnungen c.a. 1 Monat laufen lassen müssen -nur, um den Umfang zum verdeutlichen. Meine Frage zielte nun auf folgendes ab: * Einige bei uns schwören auf Fortran-Code. Viele MD-Programme sind tatsächlich in Fortran geschrieben, doch sind es bei weitem nicht die schnellsten. * Das schnellste, uns bekannte Programm heisst NAMD ( http://www.ks.uiuc.edu/Research/namd/ ), ist open-source und zu meiner einstigen Verwunderung (jetzt, nach eueren Erläuterungen nicht mehr) in reinem C++ geschrieben. * Schliesslich fragte ich mich, warum diese Codes nie in Assembler geschrieben waren, nun, jetzt bin ich ja schlauer. Nur um Missverständnissen vorzubeugen: Ich beabsichtige NICHT, selber solche Programme zu schreiben. Das können andere viel besser als ich. Ich habe mich nur gewundert, warum das schnellste Programm ausgerechnet in C++ geschrieben ist, wo ich doch immer dachte, dass Assembler für solche Zwecke ideal wäre und Fortran für mich in dem Ruf stand, schnellere Codes zu erzeugen. Nun, da habe ich mich wohl geirrt. Danke nochmal für euere Antworten, Gruss Sascha T -- de.comp.lang.iso-c++ - Moderation: mailto:voyager+mod (AT) bud (DOT) prima.de FAQ: http://www.voyager.prima.de/cpp/ mailto:voyager+send-faq (AT) bud (DOT) prima.de Back to top Heinz Saathoff Guest Posted: Thu Oct 07, 2004 7:33 am    Post subject: Re: Der alte Hochsprache vs. Assembler Streit Markus Breuer schrieb... Quote: Ich kann nicht glauben, dass irgendein Compiler derart optimiert ist, dass er besser als ein Mensch entscheiden kann, welches die minimale Anzahl an und optimale Kombination aus Anweisungen ist, die ein Prozessor benötigt, um eine Aufgabe auszuführen. Die heutigen Compiler setzten Code-Optimierer ein, an die du als Mensch kaum heranreichen kannst. Gibt es tatsächlich eine kritische Stelle im Code, so lässt man vom Compiler Assember erzeugen und bearbeitet ihn manuell nach. Kann man so nicht verallgemeinern, da es vom Compilerhersteller abhängig ist. Ich arbeite hier u.A. mit dem Keil C-Compiler für den C166. Der erzeugte Code ist bei weitem nicht so optimal, wie er sein könnte. Man sieht ihm förmlich an, daß er nach einfachen formalen kriterien erzeugt wird. Da werden Register umkopiert und dann damit gerechnet, obwohl es auch auf den originalregistern getan hätte. Da werden Ausdrücke mehrfach ausgewertet, obwohl daß Ergebnis als 'Abfall' des vorherigen Ausdruckes verfügbar ist (z.B. bei Division und anschließendem Modulo). Im Zweifelsfall schaut man sich halt den generierten Code an (sofern man ihn lesen kann), um die Qualität zu prüfen. BTW, einige RISC-Maschinen möchte ich nicht unbedingt per Assembler programmieren, weil sie häufig Fallstricke integriert haben, die ein Compiler besser behandeln kann. - Heinz -- de.comp.lang.iso-c++ - Moderation: mailto:voyager+mod (AT) bud (DOT) prima.de FAQ: http://www.voyager.prima.de/cpp/ mailto:voyager+send-faq (AT) bud (DOT) prima.de Back to top Peter Jutzies Guest Posted: Thu Oct 07, 2004 9:26 am    Post subject: Re: Der alte Hochsprache vs. Assembler Streit Sascha T. wrote: Quote: Wir haben berechnet, dass wir auf einem IBM SP4 mit 8 p655+ Prozessoren (je 1.5GhZ) die Berechnungen c.a. 1 Monat laufen lassen müssen -nur, um den Umfang zum verdeutlichen. Da hast Du schon den naechsten Grund. Je nachdem wie sich euer Problem verteilt berechnen laesst (Der Kommunikationsaufwand zwischen den einzelnen Knoten duerfte hier entscheidend sein), koennte man das Programm in C++ relativ einfach auf eure Desktoprechner portieren und so das Ergebnis schon viel frueher erhalten. SETI@home, ClimatePrediction und wie sie nicht alle heissen, arbeiten auf diese Weise. Tsch"u"s Peter -- de.comp.lang.iso-c++ - Moderation: mailto:voyager+mod (AT) bud (DOT) prima.de FAQ: http://www.voyager.prima.de/cpp/ mailto:voyager+send-faq (AT) bud (DOT) prima.de Back to top Martin Kaminski Guest Posted: Thu Oct 07, 2004 9:43 am    Post subject: Re: Der alte Hochsprache vs. Assembler Streit Hallo Sascha, Hallo NG, bin zwar spät dran, will aber auch noch meinen Senf dazugeben. "Sascha T." schrieb: Quote: Mir wurde erzählt, dass die Compiler heutzutage (z.B. ICC, PGC) derart leistungsfähig wären, dass i.A. Assembler-Coding überflüssig wäre. 1.Frage: Ist das wahr? Die Frage ist falsch gestellt. Ich habe mal in einem Projekt zeitkritische Basisroutinen einer Wavelet-Dekompression in MMX-Code nach Parallelisierungsregeln handcodiert. Selbstredent ist so eine Lösung immer schneller. Wenn es um kostenintensive numerische Aufgaben geht, führt an einer Handcodierung nichts vorbei, da Compiler immer Redundanz erzeugen müssen (schon alleine durch Stackframes usw.). Aber eine Vorliebe für Handcodierung kann ich nicht entwickeln. Sehe ich mir 2 Wochen später das Programm an, weiss ich schon nicht mehr auf Anhieb, was ich mir dabei gedacht habe, dass Umstellen der Operationen nach Parallelisierungsregeln macht so ein Programm extrem unleserlich und beinahe unwartbar durch andere Personen. Spezielle Optimierungen, wie sie von Fortran-Compilers bei bestimmten Problemen gemacht werden, erschlagen halt auch nicht alle Optimierungs- probleme. Vollmundige Ankündigungen der Hersteller von "Wunder-Compilern" sind meistens weit hinter meinen Erwartungen weit zurückgeblieben. Vielleicht passt aber genau dieser Compiler gerade für dein spezielles Problem. Ich möchte heute auf den Evolutionsschritt, den z.B. C++ gebracht hat, vor allem bei großen Projekten, nicht mehr verzichten. Dabei sollten die verwendeten Algorithmen 'von Hand' (Kopf) optimiert und nicht darauf vertraut werden, dass es der Compiler schon richten wird. Die Ergebnisse einer solchen Einstellung sieht man in der heutigen schnelllebigen Softwarewelt nur allzu drastisch. In der Hoffnung, dass unsere Köpfe in der Zukunft noch gebraucht werden Martin -- de.comp.lang.iso-c++ - Moderation: mailto:voyager+mod (AT) bud (DOT) prima.de FAQ: http://www.voyager.prima.de/cpp/ mailto:voyager+send-faq (AT) bud (DOT) prima.de Back to top Sascha T. Guest Posted: Thu Oct 07, 2004 12:17 pm    Post subject: Re: Der alte Hochsprache vs. Assembler Streit Am Thu, 07 Oct 2004 12:53:25 +0200 schrieb Mark Henning: Quote: ... - bei molecular dynamics kann es halt nur sein, dass die Kommunikation da das Nadelöhr ist. Hat mir damals einige Wochen Rechenzeit gespart. Stimmt tatsächlich! Der IBM-PC SP4, auf dem ich hauptsächlich rechne, bietet 8 Prozessoren pro Node. Eine Skalierung der CPU-Time gegen Anzahl der Prozessoren hat gezeigt, dass alles, was über einen Node hinausgeht, mit der von uns genutzten Software (NAMD) keinen Geschwindigkeitsvorteil bringt. Ferner rechne ich noch auf zwei weiterne Clustern, die je 2 Prozessoren pro Node anbieten, wahlweise Ethernet oder Myrinet. Der Cluster mit dem aktuelleren Myrinet zeigt noch akzeptable Geschwindigkeitsvorteile bei bis zu 14 Prozessoren, danach ist aber Sense. Quote: Das größte Problem war im Übrigen nicht der Algorithmus an sich, sondern die Software so zu schreiben, dass der Gesamtkomplex einzelne Rechnerabstürze, irrtümliches Abschalten von Rechnern, DAU-Aktionen u.s.w. schadlos übersteht, ohne die Rechnung zu vermurksen. *gg* Stimmt! Jedoch schreibe ich meine Trajektorien in 24h-Häppchen heraus und starte täglich einen rsync, sodass der Schaden doch relativ minimal bleibt. Gruss ST -- ----------------------------- E=mc^2 -> I really *mean* it! ----------------------------- -- de.comp.lang.iso-c++ - Moderation: mailto:voyager+mod (AT) bud (DOT) prima.de FAQ: http://www.voyager.prima.de/cpp/ mailto:voyager+send-faq (AT) bud (DOT) prima.de Back to top Sascha T. Guest Posted: Thu Oct 07, 2004 12:22 pm    Post subject: Re: Der alte Hochsprache vs. Assembler Streit Am Thu, 07 Oct 2004 11:26:06 +0200 schrieb Peter Jutzies: Quote: Da hast Du schon den naechsten Grund. Je nachdem wie sich euer Problem verteilt berechnen laesst (Der Kommunikationsaufwand zwischen den einzelnen Knoten duerfte hier entscheidend sein), koennte man das Programm in C++ relativ einfach auf eure Desktoprechner portieren und so das Ergebnis schon viel frueher erhalten. Hmmm? Du meinst eine Single-Prozessor Rechung läuft schneller als eine Multiprozessor Rechung? Hab das Programm auch hier auf meinen AMD Athlon XP (2.0GHz) compiled, und ich kann nicht behaupten, dass ich schneller an das Ergebniss komme. Um genau zu sein, braucht mein AMD 8x länger, um den selben Algorithmus mit den selben Variablen auszuführen, wie der Power-PC mit 8 Prozessoren. Aber die Portierbarkeit ist natürlich sensationell, das stimmt! Wenn ich da an so manche Fortran-Codes denke... Gruss ST ----------------------------- E=mc^2 -> I really *mean* it! ----------------------------- ! Anmerkung des Moderators: ! Bitte in Replies wieder mehr Bezug zu C++ - oder ein follow-up in eine ! passendere Gruppe. -- de.comp.lang.iso-c++ - Moderation: mailto:voyager+mod (AT) bud (DOT) prima.de FAQ: http://www.voyager.prima.de/cpp/ mailto:voyager+send-faq (AT) bud (DOT) prima.de Back to top Display posts from previous: All Posts1 Day7 Days2 Weeks1 Month3 Months6 Months1 Year Oldest FirstNewest First         C++Talk.NET Forum Index -> C++ (German) All times are GMT Goto page 1, 2  Next Page 1 of 2   Jump to: Select a forum C/C++----------------C LanguageC Language (Moderated)C++ Language (Moderated)C++ language (comp.lang.c++)C++ language, library and standards Non-English C/C++ Newsgroups----------------C++ (German)C++ (French)  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 Powered by phpBB © 2001, 2006 phpBB Group SEO toolkit © 2004-2006 webmedic.