[c++] Windows vs. Linux Performanz

DataNaut

Cadet 2nd Year
Registriert
Nov. 2005
Beiträge
31
Verehrtes Fachpublikum,
ich habe eine C++ - Klasse, die unter Linux 3-4 mal schneller läuft, als unter Windows. Innerhalb dieser Klasse wird nur gerechnet, es gibt keine Netzwerk oder Datei Zugriffe.
Ich muss gestehen, dass ich keine Ahnung habe, wo ich anfangen soll zu Suchen. Außer natürlich hier im Forum zu Posten. Hat jemand Erfahrungen oder Ideen?
Gruß vom
DataNaut
 
leider ist meine glaskugel defekt...
poste doch bitte mal den inhalt der klasse. die performance-unterschiede können vielfältige gründe habe, daher ist es müßig darüber zu spekulieren.

EDIT nachtrag: schreib bitte auch gleich dazu, welche compiler die genommen hast und welche flags du gesetzt hattest.
 
ich hab vergessen zu erwähnen, dass weder bei Linux noch bei Windows irgendwelche Compiler Optimierungsflags gesetzt sind.
 
Lässt du die Klasse unter Windows in einer IDE laufen? Wenn ja, dann führ das Programm mal ohne IDE aus.
 
@Simpson474 du meinst mit laufendem debugger? das hätte doch mal was. ;-)
 
ghorst schrieb:
leider ist meine glaskugel defekt...
poste doch bitte mal den inhalt der klasse. die performance-unterschiede können vielfältige gründe habe, daher ist es müßig darüber zu spekulieren..

Wenn ich den Inhalt dieser Klasse hier posten würde, dann würde ich unter Garantie meinen Job verlieren.

EDIT nachtrag: schreib bitte auch gleich dazu, welche compiler die genommen hast und welche flags du gesetzt hattest
die Compiler werden noch erfragt
 
dann bau es doch so um, das man nicht mehr erkennen kann, wo es hingehört...
nur ohne code kann dir hier mit sicherheit keiner weiterhelfen, wenn du nicht den von Simpson474 beschrieben fehler gemacht hast...
 
Performancemessungen machen ausschließlich im Release-Mode Sinn.

Von Debug-Microsoftgebauten-Executables darfst du eh keine Auslieferung an Kunden machen. Ist in den Deployment-Hinweisen ausdrücklich nicht gestattet.

Der MS-Compiler baut im Debug-Modes wesentlich mehr Prüfungen drin als der GCC beispielsweise, deshalb erscheinen die Executables erstmal schleichend lahm. Damit lassen sich allerdings viele Fehler finden und das ist m.E. sehr sinnvoll. Für einen Performance-Vergleich kann man ein Debug-Executable aber niemals heranziehen.

Der Debugger sollte btw. fast garkeinen Unterschied machen. Wenn Unterschiede da sind -> Profiler anwerfen. gprof unter Linux (mit gcc mit -pg bauen), unter Windows gibt's zumindest in den größeren Versionen vom VS auch einen eingebauten Profiler. Freie sind mir gerade nicht bekannt, was nicht heißen muss, dass es keine gibt.

Noch so zur Info: Ein Projekt bei uns mit ca. 4600 Dateien ist unter Windows etwas (nicht sehr viel) performanter als unter Linux. (VS2005 vs. GCC 4). Im Releasemodus versteht sich, Debug ist absolut nicht vergleichbar. Nennenswerte Unterschiede konnte ich noch nicht feststellen. Zumal wenn es nur reine Rechnerei ist.
 
Zuletzt bearbeitet:
Vielen Dank erstmal für die rege Beteiligung.
Die Vergleiche sind im Release gemacht worden.
Die Klasse so umzubauen oder Abzuspecken, dass man sie hier zeigen kann, ist leider unmöglich.
Beruhigend ist, das 7H3 N4C3R in seinem Projekt keinen nennenswerten Unterschied festgestellt hat.
 
Oh, dann war ich etwas verwirrt :) Ich hatte es jetzt so verstanden, dass es Debug war. In diesem Falle musst du Release mit Debuginformationen bauen und jeweils einen Profiler draufwerfen. Anders wirst du hier nicht weiterkommen.

Man kann natürlich 3 Tage auf den Code schauen und überlegen und eventuell die Stelle raten. Zuverlässig in einer konstant abschätzbaren Zeit kommst du aber nur mit Profiler weiter.


Potenzielle Ideen wären Speicherallokierung (wobei Faktor 3-4 sehr krass wäre), vielleicht aber auch schon z.B. die Default-Optimierungsflags. Unter Windows z.B. ohne SSE, unter Linux mit; Angabe des Prozessortyps zum besseren Caching etc. Unbedingt auch mal die Aktivierung von intrinsic functions auf beiden Plattformen checken. Inlining sollte im Releasefall aktiv sein, trotzdem mal prüfen. Wenn das ganze gleitkommalastig ist, auch auf die diversen Flags checken (IEEE754 strict mode vs. relaxed, und das alles).

Ist die Hardwareplattform auf Windows und Linux dieselbe? Evtl. hilft die auch ein Cache-Profile weiter. Wenn's unter Windows Cache-Misses hagelt, wäre das ein guter Kandidat.


Btw, noch eine Idee. Führ das Programm mal unter Linux mit time aus und schau mal wieviel Zeit es im User- und im System-Mode verbringt. Hängt natürlich von der Gesamtlaufzeit ab, deshalb ist es schwer zu sagen wieviel Zeit im Systemmode sein "darf". Aber bei einem Verhältnis von weniger als 1000/1 (ganz grob geraten) ist es ziemlich wahrscheinlich, dass es an Systemaufrufen liegt. Poste doch mal sonst das Ergebnis bei Unsicherheit.


Und nochwas :) Lässt sich der umgebende Code soweit reduzieren, dass das Testobjekt möglichst nur noch aus der betreffenden Klasse besteht? (falls das möglich ist und du das eh nicht schon getan hast) Das vereinfacht das Finden des Problems enorm.
Ohne Profiler könnte man sonst auch hier sukzessive Code ausbauen und im Trial und Error Verfahren sich immer weiter annähern. Sofern der Code das wieder zulässt natürlich.

Und noch ein Nachtrag *g* Die Eingangsparameter des Algorithmus überprüfen. Manchmal liegt garnicht dort der Hund begraben wo du ihn vermutest, sondern dass der Algorithmus durch Rahmenbedingungen mit anderen Daten gefüttert wird. Versuch mal sicherzustellen, dass das auf beiden Plattformen gleich ist.

Noch eine Idee. Die letzte für heute :D Ist der Code komplett neu? Oder ist dir das jetzt erst aufgefallen? Sonst erstmal Vorgängerversionen auschecken und prüfen oder das Problem dort auch so auftritt. Falls nicht - annähern und die Versionsunterschiede untersuchen.
Btw, wildes Raten und Ändern was Schuld sein könnte, ist i.A. Zeitverschwendung.


Wenn das alles nichts hilft, versuch ein minimalistisches Beispiel zu konstruieren, was das Problem zuverlässig reproduziert. Das war jetzt ein ganzer Haufen Zeug. *g* Sag mal Bescheid, welche Erfolge du verbuchen konntest. :)
 
Zuletzt bearbeitet:
Zurück
Oben