XCode Codewarrior C++ Super Langsam

[BigSebek]

Hallo an alle,
ich habe ein Problem. Ich habe ein Programm in c++ geschrieben. Erst habe ich das mit XCode geschrieben. Das programm war super träge. Dann habe ich den gleichen code mit codewarrior kompiliert und es lief viel schneller. ich habe das ganze auf eine emac 1.25 kompiliert. Jetzt wollte ich das auf einem dual_core 2.3 teste wie schnell es läuft. ich dachte das würde rasendschnell laufen ab denkste. Woran kann es liegen. Muss ich das auf dem dual_core kompilieren damit er den prozessor richtig ansteuert?

ich habe halt ein programm geschrieben dass zwei schleife durchläuft. Irgendwie läuft das programm nicht schneller auf dem G5 Dual_core. Das ding lief sogar langsamer als auf einem pc intel p4 2.53. ich dachte das würde auf dem g5 viel schneller sein. anscheinend sind mac für solche berechnung nicht gut.

sehe ich das was falsch. kann mir jemand helfen?

 

[below]

Ja, CodeWarrior macht besseren Code, das ist immer noch so ...

Aber von DualCore hast Du nur etwas, wenn das OS Dein Programm auch auf die verschiedenen CPUs verteilen kann. Wenn das einfache Schleifen sind, dann geht das nicht:

"On multiprocessor systems, each processor can execute the code for a different thread. This parallel execution can lead to tremendous performance gains for your program and for the system as a whole."

Du solltest die Logik Deines Programms in POSIX Threads (man pthread) aufteilen. Erst dann kannst Du von den Multi-CPUs profitieren.

Gruss

Alex

 

[oneOeight]

CW hat default mässig optimierung im deployment target...
bei XCode musst du erstmal die ganzen settings für gcc machen, das fängt mit dem
-ftree-vectorize -fast -faltivec usw an....

 

[BigSebek]

Hi, danke für die hilfe.

Also kann ich mir das sparen mit dem dual_core. so gut kann ich keine programme schreiben dass ich mehrere prozessoren ausnutze. das finde ich echt schade. codewarrior gibt aber die entwicklung für MacIntel auf. Deshalb sagt man doch ich solle auf xcode umsteigen. ja toll. wo bekomme ich denn die anleitung was ich dort alle einstellen muss.

ich verstehe nur nicht wieso, meine schleifen auf einem inel 2.5ghz ca. 1 stunden brauchen. auf meinem emac 1.25 ghz drei stunden. jedoch auf einem dual-core 2.3 fast 2 stunden. das ist doch eine verbesserung. ist intel in dieser hinsicht besser. vieleicht auch unter anderem der wechsel bei apple. ich habe immer gedacht ppc wären solche hardcore-maschinen.

 

[pdr2002]

ich verstehe nur nicht wieso, meine schleifen auf einem inel 2.5ghz ca. 1 stunden brauchen. auf meinem emac 1.25 ghz drei stunden. jedoch auf einem dual-core 2.3 fast 2 stunden. das ist doch eine verbesserung. ist intel in dieser hinsicht besser. vieleicht auch unter anderem der wechsel bei apple. ich habe immer gedacht ppc wären solche hardcore-maschinen.

Um das beurteilen zu können, müßte man einmal den Quellcode sehen. Zum anderen würe ich Dir einmal diese Bücher hier empfehlen. Dann sehen wir weiter.

 

[below]

Vor allem leifert Apple aber auch ein super Tool, "Shark", mit dem man sehr genaue Analysen machen kann.

Gruss

Alex

 

[Generalsekretär]

ich verstehe nur nicht wieso, meine schleifen auf einem inel 2.5ghz ca. 1 stunden brauchen. auf meinem emac 1.25 ghz drei stunden. jedoch auf einem dual-core 2.3 fast 2 stunden. das ist doch eine verbesserung. ist intel in dieser hinsicht besser. vieleicht auch unter anderem der wechsel bei apple. ich habe immer gedacht ppc wären solche hardcore-maschinen.

Dabei spielen natürlich auch Dinge rein wie der auf dem Intel verwendete Compiler. Aber ganz allgemein:
Willkommen in der Wirklichkeit.
Apple hat die letzten 5-6 Jahre permanent getönt, wie schnell doch die eigenen Rechner seien auch ohne MHz. Nur leider war das zum Teil einfach Marketing-Bullshit.

Der Fairness halber möchte ich bemerken, daß ein G5 mit dem richtigen OS und Compiler sejr schnell sein kann.
Ich habe Vergleichstests im Inet gesehen (u.A. anadtech), bei denen auf x86 wie G5 Linux mit einer vergleichbaren Version des GCC lief. Darauf wurden eigene Benchprogramme übersetzt und dann getestet.
Tendenz: der G5 ist schnell, aber nicht wirklich fundamental schneller als ein P4, gegen einen Athlon64 zieht er meist den Kürzeren.

 

[below]

Es soll ja Leute geben, die schon jetzt OS X auf anderen Prozessoren ausprobieren können. Aber die dürfen nicht darüber reden ...

Aber auf jedem "gängigen" Betriebssystem muss jedes Programm für Multi-Prozessor Betrieb angepasst werden. Das OS kann einfach sehr schlecht raten, was man an Deinem Code parallelisieren kann.

Gruss

Alex

 

[kiu]

@one0eight
zitat: "CW hat default mässig optimierung im deployment target...
bei XCode musst du erstmal die ganzen settings für gcc machen, das fängt mit dem
-ftree-vectorize -fast -faltivec usw an...."

heisst das ich kann mit der richtigen einstellung des gcc die performance des cw-compilers erreichen und die programme laufen dann vergleichsweise, wie die die vom cw compiliert wurden ??

gruss kiu

 

[Unixx]

Für den cc von sun gab und gibt es eine Befehl, der den code automatisch parallelisieren kann. Das funktioniert mit den ultrasparc cpus auch ganz.

 

[-Nuke-]

Das hatten wir doch mal in einem anderen Thread, oder war das woanders?

Weil soweit ich weiß optimiert der CW-Compiler von Haus aus schon die Schleifen, etc. Das macht GCC erst mit Optionen, ich glaube -floop-optimize, oder so etwas.

 

[Generalsekretär]

Jaja, die Schleifenbehandlung...
Habe das mal unter OSX getestet mit dem beliebten '-funroll-loops'. Mit dem (IIRC) nbench konnte man da auch ein paar Prozent mehr Leistung rauskitzeln (mit dem GCC 3.3 von OSX 10.3)