Geschwindigkeit Assembler und C++

[LL0rd]

Hallo,

als ich vor ca. 8 Jahren mit Asm angefangen habe, war Asm wirklich die schnellste Sprache in der Ausführung. Auch die erstellten Dateien waren nur ein paar bytes groß, eben alles optimiert.

Heute ist man da etwas anderer Meinung, viele sagen, dass manche C/C++ Compiler den Code so dermaßen optimieren können, dass er schneller läuft, als wenn er tatsächlich in Asm geschrieben wurde. Habt ihr da irgendwelche Erfahrungen zu?

 

[deepthroat]

Hi.

Ein optimierender (C/C++) Compiler wird auf den allgemeinen Fall hin optimieren, kann aber meistens mit bestimmten Einstellungen noch etwas anders konfiguriert werden. Allerdings gibt es natürlich ausgefeilte Optimierungstechniken die im Compiler angewendet werden können.

Der Assembler hat doch mit der Ausführungsgeschwindigkeit des Programmes letztendlich gar nichts zu tun. Es kommt auf das Wissen und Können desjenigen an, der das Programm geschrieben hat.

Wenn jemand extrem gute Kenntnisse über den zu verwendenden Prozessor hat, und verschiedene Optimierungsstrategien für den Prozessor anwenden kann, dann kann er es sicherlich schaffen, ein Programm zu erstellen welches schneller ist als ein Compiler-optimiertes Programm.

Aber kein Mensch der noch ganz bei Trost ist schreibt heute ein komplettes (grafisches) Programm in Assembler.

Das würde ohnehin viel zu lange dauern, von der Wartbarkeit ganz zu schweigen.

Falls das Programm noch optimiert werden muss, sollte man erstmal die "Hotspots" finden und dort ggf. Assembler einsetzen. Allerdings ist Assembler extrem un-portabel, so das das Problem auftaucht für verschiedene Architekturen oder CPU-Typen (i586, i686, usw) spezielle Befehle zu verwenden.

Letztendlich hat die Laufzeit-Effizienz meist nichts mit der verwendeten Sprache, sondern mit den verwendeten Algorithmen bzw. Datenstrukturen zu tun.

Gruß

 

[LL0rd]

Hi,

vielen Dank für deine Antwort. Ich hatte auch nicht vor, die ganze Anwendung in Assembler zu programmieren. Die Sache ist die, ich habe ein Programm in C# entwickelt, das "rumrechnet". Der Server dahinter ist ein 4x DualCore Xeon (also 8 Cores) und 32GB Ram.

Das Problem ist, dass die Geschwindigkeit der Berechnung noch nicht ausreichend ist, sie muss um einen Faktor 20-40 steigen. (statt 2-4 sek soll das Programm nur noch 200-100ms rechnen). Meine Vermutung ist momentan, dass die Berechnung so langsam läuft, weil C# bzw. das .Net Framework alles nicht direkt ausführen und zunächst einmal jitten müssen. Deshalb hoffe ich mir damit einige Zeit an den Übergängen von einem Algorithmus zum anderen einzusparen.

 

[Wolfsbein]

Ein Faktor 20-40 holst du nicht so einfach raus. Da musst du schon am Code was drehen. Also schauen warum er so langsam ist. Eventuell falscher Kontrollfluss, usw.

 

[takidoso]

Hi,

vielen Dank für deine Antwort. Ich hatte auch nicht vor, die ganze Anwendung in Assembler zu programmieren. Die Sache ist die, ich habe ein Programm in C# entwickelt, das "rumrechnet". Der Server dahinter ist ein 4x DualCore Xeon (also 8 Cores) und 32GB Ram.

Das Problem ist, dass die Geschwindigkeit der Berechnung noch nicht ausreichend ist, sie muss um einen Faktor 20-40 steigen. (statt 2-4 sek soll das Programm nur noch 200-100ms rechnen). Meine Vermutung ist momentan, dass die Berechnung so langsam läuft, weil C# bzw. das .Net Framework alles nicht direkt ausführen und zunächst einmal jitten müssen. Deshalb hoffe ich mir damit einige Zeit an den Übergängen von einem Algorithmus zum anderen einzusparen.

Also wenn ich Dich jetzt richtig verstanden habe, läuft Dein Programm auf einen Server mit mehreren Processoren. Soweit ich weiß hilft das so erstmal nicht Das programm schneller auführen zu lassen, selbst wenn Du (mal gesponnen) 100 Prozessoren auf Deinem REchner hast. Du musst, falls Du Deine Brechnungen auf besagten Mehrprozessorigen Rechner aufürhen und die Last auf dieProzessoren verteilen willst, vermutlich Deine Berechnungen so Bauen dass Teile davon parallel abgearbeitet werden können. Aber das ist jetzt nur ne Frage ob Dein Problem überhaupt derart algorythmisch aufgeteilt werden kann.

Ansonsten kommt es schwer auf die Berechnungen an ob es sich lohnt diese in z.B. Assembler (oder in diesem Fall würde ich eher C mit nativecompilierung und nicht managed Code empfehlen) zu schreiben.

 

[LL0rd]

Ich muss vorab zugeben, dass ich bisher noch nicht all zu viel Erfahrungen mit der Ansteuerung mehrerer CPUs habe. Aber wir haben den Algorithmus so aufteilen können, dass sich Teilstücke ergeben haben, die durchaus parallel und unabhängig voneinander ausgeführt werden können. In dem .Net Programm erfolgt das derzeit, in dem ein ThreadPool gestartet wird und dann in 64 Threads Rumgerechnet wird. Dabei wird es dem Prozess-Scheduler überlassen, welcher Thread wann läuft.

Und ich bin der Meinung, dass dies genau der Flaschenhals sein kann. Deshalb würde ich eigentlich sehr gerne jede CPU einzeln ansprechen können.

Die Berechnungen sind fast alle geometrischer Natur. Auf den ersten Blick lässt sich das alles ohne größere Probleme in Asm realisieren. Aber in C bzw. C++ würde man es dann doch schneller hinbekommen. Vor allem weiß ich nicht, wie gut man die Multi CPU Geschichte in Asm hinbekommt. Aber die Programmierer der PS3 haben eigentlich auch mit dem gleichen Problem zutun.

 

[Grimreaper]

Warum 64 Threads bei 8 Cores? Wenn die Arbeit sicht recht gut durch 8 Teilen laesst, dann wuerde ich auch nur 8 Threads verwenden. Spart dir das Erstellen und synchronisieren von 56 Threads...

 

[LL0rd]

64 Threads ist das Limit des .Net Threadpools. Ich habe bereits probiert die Anwendung mit 8 Threads laufen zu lassen. Aber es hat nicht wirklich performant funktioniert. Es haben zwar alle CPUs genutzt, aber nur zu ca. 30%.

 

[kle-ben]

Wenn die Threads die CPU nicht stark auslasten, sie aber stark rechenintensiv sind,
dann würde ich sagen sind sie nicht gut snychronisiert. Lange Wartezeiten auf shared Memmory.Oder ein großer Teil der Threads ist nciht CPU lastig. Greifen sie denn auf häufig auf andere Geräte zu ?

Ich bin kein .Net Experte, ehrlich gesagt hab ich keine Ahung von .NET aber ich habe gerade das http://www.yoda.arachsys.com/csharp/threads/ gefunden. Der Threadpool ist wohl eher besser für kurzablaufende Threads. Keine Ahnung ob das in deinem Fall einen EInfluss auf dein Programm hat aber vieleicht hilfts.

Benny