Programm fuer Intel Core Duo optimieren

B

booth

Aktives Mitglied
Thread Starter
Dabei seit
14.02.2003
Beiträge
250
Reaktionspunkte
2
Hallo,

ich moechte ein Programm (C++) moeglichst effektiv uebersetzen. Ich benutze zum compilieren (g++) zwar die -arch i386 Option (richtig? oder lieber -march i686), das Programm ist aber einen Faktor 5 langsamer als ein identisches, dass in Fortran geschrieben ist.
Fragt jetzt bitten nicht, warum ich dann nicht das Fortranprogramm benutze ;)

Die Prozessorauslastung scheint bei beiden Prozessen gleich zu sein.
Das Programm ist reine Numerik.

MfG
 
Bei Apple habe ich nicht gesucht, weil das eher alles ObjectiveC und Cocoa etc. lastig ist.

Die -O3-Option scheint keinen Vorteil zu bringen.

Vielleicht ist C einfach nicht geeignet, was schade ist, weil ich Fortran naemlich gar nicht schreiben kann...
 
Klingt schon komisch. Ist das Fortran-Programm vielleicht mit dem Intel Fortran Compiler übersetzt worden?
Ansonsten ist das Programm vielleicht doch nicht ganz identisch. Wenn du willst kann ja hier jemand mal drüber gucken.

Auf jeden Fall ist C von der Geschwindigkeit her sicher für Numerik geeignet.
 
wie gross sind denn die beiden dateien, die unter c++ und fortran erzeugt wurden? würde mich nicht wundern, wenn das c++-compilat um einiges grösser ist als das übersetzte fortran-programm.

gruss
hajo
 
Also:

in2itiv: XCode kann zwar C++ compilieren, dass kann ich ja aber auch von hand auf der console. Ich glaube beide benutzen g++. Ich kann mal probieren, was passiert, wenn ich XCode benutze um das zu kompilieren. Allerdings war mir XCode dafuer bisher immer zu aufwendig (Projekte erzeugen etc.)

nschum: Ich habe g95 fuer das Fortranprogramm benutzt und keine Optionen angegeben. Es waere natuerlich prima, wenn sich das jemand ansehen koennte, aber alles pasten ist vielleicht etwas viel. Im Prinzip ist es nur ein Runge-Kutta 4. Ordnung.

com_hajo: Ist genau umgekehrt: C++-Programm ist 27k gross, Fortranprogramm 680k.

Vielen Dank fuer eure Muehe.
 
Schicks mir ruhig mal gezippt an n_schumacher bei web.de.
Ich hab zwar noch keinen Intel Mac hier, aber ich gucks mir gerne mal an.
 
Es gibt auch den icc, den Intel C-Compiler. Der kostet Geld, kann nur C und C++ (keine Objective-C), ist aber einiges besser als der g++

Alex
 
hm... wenn ich so auf die dateigrößen schaue: kann es sein, dass der c++ compiler viele sprünge im code erzeugt und deswegen die ausführungsgeschwindigkeit so gering is?

versuch mal heufig verwendete methoden als inline zu deklarieren. dann kopiert der compiler den code direkt an die stelle an der er gebraucht wird und macht nicht nur einen verweis mit einem sprungbefehl.

bei heufihg verwendeten methoden kann das zwar das binary ganz schön aufblähen, aber die ausführungsgeschwindigkeit sollte auch steigen.
 
nine_inch_nail schrieb:
hm... wenn ich so auf die dateigrößen schaue: kann es sein, dass der c++ compiler viele sprünge im code erzeugt und deswegen die ausführungsgeschwindigkeit so gering is?

Ich glaube eher, dass g95 statisch gelinkt hat und gcc nicht. Zumindest kann ich mir bei Runge-Kutta nicht so viel Code vorstellen.

Da fällt mir ein ... von welchen Zeiten reden wir hier eigentlich? Wenn's um Millisekunden geht, kommt das sicher durch das dynamische Linken.
 
Core Duo ausreizen....

Hi,

um die Multi-kern-Prozessoren wirklich ausreizen zu können, müssen die Programme in parallele Threads aufgeteilt werden, die dann auf alle möglichen Kerne verteilt werden können.

Für C/C++ gibts dort Unterstützung durch OpenMP (war vor nicht allzu langer Zeit in der c't ne Artikelserie). Der GNU compiler hat ab Version 4.1 OpenMP-Support 'build-in'.

Der bei MacOX Tiger mitgelieferte Compiler ist Vers. 4.0. Es existiert jedoch ein Projekt auf source-forge, welches ein um OpenMP Unterstützung angereicherte GNU compiler collection für OS X Tiger anbietet: [SIZE=-1]http://hpc.sourceforge.net.

Btw: ausser für C/C++ kann OpenMP auch unter Fortran verwendet werden....


[/SIZE]
 
Sorry, dass ich erst jetzt wieder schreibe, ich habe keine Benachrichtigung von MacUser bekommen, dass hier was passiert ist.

Bzgl. der Dauer: Ein Schleifendurchlauf dauert ca 1 min. bei Fortran und knapp ueber 5 min. bei C++

Ich habe leider keine Ahnung, was in inline ist, darum werde ich mich aber mal bemuehen.

Parallele Threads stelle ich mir schwer vor, weil es zur Zeit nur einen Schleifendurchlauf gibt und der laeuft einfach von oben nach unten durch (mit ein paar Unterschleifen), aber das sinnvoll auf zwei Prozessoren aufzuteilen stelle ich mir schwer vor, weil die einzelnen Schleifenergebnisse voneinander abhaengen.

MfG
 
Multithreading hin oder, in dem C++ Programm muss etwas grundlegend faul sein, wenn es so viel langsamer ist.

inline bringt vermutlich auch nur wenige Prozent, zumal sich gcc bei -O3 ohnehin selbstständig dafür entscheidet.
 
Jo, exakt. Inline vor die Funktionen schreiben hat fast nichts gebracht, nur dass ich die Version, die ich Dir geschickt habe nicht benutzen kann; keine Ahnung warum.
Ich habe noch eine Version, die keine Bibliothek benutzt sondern alle Funktionen in einer Datei hat. Diese Version laeuft ca. 1 Minute schneller.
 
booth schrieb:
die ich Dir geschickt habe

Gut, dass du mir das sagst. Ich hab sie nämlich noch nicht bekommen. Offenbar war mein Mailserver verkonfiguriert. :rolleyes:
Jetzt läuft's wieder. Ich hoffe dein Mailserver versucht es später noch einmal.
 
Hallo,

genau dasselbe Thema hatte mich auch schon mal beschäftigt, als ich C-Code nach Fortran portiert habe, als ich zu Studienzwecken eine DFT programmiert habe.

Jedenfalls kann man Compiler noch tunen, was die Leistungsfähigkeit der Programme hinterher betrifft. Tolle Seite dazu: http://hpc.sourceforge.net/

Was mich interessieren würde:

Runge-Kutta 4. Ordnung und dann 1 - 5 Minuten Laufzeit? Wie viele Zeitschritte rechnest du?
Ich hab das auch neulich in einem Fortran-Programm umgesetzt um ein System von abhängigen Differentialgleichungen (Lorenz-Attraktor) numerisch zu lösen, hab dabei für 100000 Integrationsschritte eine halbe Minute ohne zusätzliche Optionen beim Kompilieren gebraucht.

Schönen Abend noch!
 
Zurück
Oben Unten