[C++] Windows 3x sneller dan Linux?

[DieterVDW]

Hallo,

Ik worstel momenteel met een bijzonder vreemd probleem.
Ik heb een CPU-intensief programma geschreven. Als ik dit compileer onder Windows, dan is de uitvoeringstijd van dit programma +- 9s voor een gegeven inputbestand.
Als ik exact dezelfde code compileer onder linux, dan is de uitvoeringstijd daar 27s (uiteraard met dezelfde input). En nochtans is de Linux machine een stuk krachtiger dan de Windows machine...

Ik heb al geprobeerd om talrijke optimalisatie flags te gebruiken met de gcc compiler op linux, maar ik krijg de uitvoeringstijd onmogelijk onder de 26s . Dit verschil is toch wel bijzonder groot! Hoe valt dit te verklaren en hoe kan ik dit oplossen?

Ik heb trouwens iemand gevonden met exact hetzelfde probleem, maar geen oplossing:
http://gcc.gnu.org/ml/gcc-help/2005-04/msg00204.html
Ik heb deze persoon in ieder geval gemaild.

De exacte specs van de machines en compilers:
- Windows:
Windows XP Pro
Intel Pentium D 2.8Ghz
2 Gig RAM
Visual Studio 2005 (v8.0)

- Linux
Debian 4.0
AMD Athlon 64 3200+
512Mb RAM
GCC 4.1.2

Ik heb al de volgende gcc flags geprobeerd:
-O3 -fomit-frame-pointer -ffast-math -sse2 -march=athlon64 -mmmx -mfpmath=sse,387 -funroll-loops
Geen enkele flag produceert echter een merkbare verbetering.

De applicatie linkt enkel met de standaard c/c++ libraries en gebruikt geen exotische calls of zoiets.
(Standaard number crunching).

Gezien de machinespecs is de voor de hand liggende conclusie dat de Linux machine over te weinig geheugen beschikt. De applicatie heeft echter een bijzonder lage memory footprint (16Mb max, en zoveel geheugen is vrij op de linux machine).

Ik sta voor een raadsel.
Ik hoop dat iemand mij kan helpen.
Alvast bedankt in ieder geval!

[leuk_he]

In de link die jij post komt het antwoord voorbij:

Then run your program, after that make "gprof your_program" look where your
code took a lot of time to execute (it might not be compiler problem).

meten is weten. (en anders log je wat?)

[Gerco]

Een Intel Pentium D en een Athlon 64 zijn hele andere CPUs en het kan zijn dat je programma niet bepaald lekker loopt op een Athlon64. Je zou kunnen proberen om eens een Linux LiveCD in die Pentium D te schuiven en te kijken hoe je programma in Linux presteert op die Pentium D.

Daarnaast heeft een Pentium D twee cores en een Athlon 64 niet, dat kan natuurlijk ook nog wel het 1 en ander schelen (of is het eigenlijk een X2?).

[Niemand_Anders]

Een groot verschil tussen de machines is wel het geheugen 2048 vs 512 mb. Kun je het geheugen in de windows machine terug brengen naar 512mb? Dan is de vergelijking tussen de twee machines wat eerlijker..

[Koppensneller]

Niemand_Anders schreef op donderdag 15 november 2007 @ 11:34:
Een groot verschil tussen de machines is wel het geheugen 2048 vs 512 mb. Kun je het geheugen in de windows machine terug brengen naar 512mb? Dan is de vergelijking tussen de twee machines wat eerlijker..

Dat zou gezien de kleine memory footprint van zijn applicatie helemaal niets mogen uitmaken.

[Cloud]

Gerco schreef op donderdag 15 november 2007 @ 11:24:
Een Intel Pentium D en een Athlon 64 zijn hele andere CPUs en het kan zijn dat je programma niet bepaald lekker loopt op een Athlon64.

Dat zou kunnen, als hij van allerlei exotisch goed gebruik maakt. Maar zelf geeft hij aan van niet. Het is gewoon standaard "number crunching" zoals hij het noemt. Als bij zo'n triviale zaak al zo'n enorm verschil op zou treden tussen verschillende processoren, hoor je dit bij veel meer applicaties te merken lijkt me. Dus het verschil in architectuur, nee ik denk niet dat het daaraan ligt.

edit:
Met de rest ben ik het wel eens trouwens, gebruik een LiveCD en test het op de Windows bak

[ Voor 7% gewijzigd door Cloud op 15-11-2007 11:41 ]

[Saeverix]

Het makkelijkste is gewoon zoals Gerco al zei: Linux LiveCD downloaden en in de Pentium D machine stoppen. Dan het zelfde opnieuw compileren... Dan pas kun je een perfecte vergelijking tussen Windows en Linux uitvoeren.

Het enige wat dan namelijk nog verschilt is dan het OS. En dat is wat hierbij de bedoeling is...

[!GN!T!ON]

DieterVDW schreef op donderdag 15 november 2007 @ 10:59:
En nochtans is de Linux machine een stuk krachtiger dan de Windows machine...

als ik zo naar die specs kijk dan is die windows bak veeel krachtiger

[voodooless]

Laat ik nu precies het omgekeerde gezien hebben deze week.

Stukje code deed er met de microsoft compiler 5 minuten over, en met gcc 4.3 ongeveer 20 seconden over.. You tell mee.. Gcc 3.x deed er trouwens ook erg lang over (zo'n 4 minuten).

Wat ik je in ieder geval zou aanraden is om je app even met mingw te compileren (neem dan wel gcc >= 4.x) onder Windows. Dan kun je gewoon op een machine testen en kunnen een direct vergelijk maken.

KoppenSneller schreef op donderdag 15 november 2007 @ 11:36:
Dat zou gezien de kleine memory footprint van zijn applicatie helemaal niets mogen uitmaken.

Dat een programma klein is wil nog niet zeggen dat het weinig memory gebruikt natuurlijk

[Koppensneller]

voodooless schreef op donderdag 15 november 2007 @ 11:42:
[...]


Dat een programma klein is wil nog niet zeggen dat het weinig memory gebruikt natuurlijk

Gezien de machinespecs is de voor de hand liggende conclusie dat de Linux machine over te weinig geheugen beschikt. De applicatie heeft echter een bijzonder lage memory footprint (16Mb max, en zoveel geheugen is vrij op de linux machine).

[Jaap-Jan]

voodooless schreef op donderdag 15 november 2007 @ 11:42:
Laat ik nu precies het omgekeerde gezien hebben deze week.

Stukje code deed er met de microsoft compiler 5 minuten over, en met gcc 4.3 ongeveer 20 seconden over.. You tell mee.. Gcc 3.x deed er trouwens ook erg lang over (zo'n 4 minuten).

Wat ik je in ieder geval zou aanraden is om je app even met mingw te compileren (neem dan wel gcc >= 4.x) onder Windows. Dan kun je gewoon op een machine testen en kunnen een direct vergelijk maken.

Hij heeft het over de uitvoeringstijd van het programma, niet over de compiletijd.

Dat een programma klein is wil nog niet zeggen dat het weinig memory gebruikt natuurlijk

Hij zegt in de openingspost dat het programma niet meer dan 16MB geheugen gebruikt en dat de Linux bak dat geheugen ook vrij heeft.

[Gerco]

wolkje schreef op donderdag 15 november 2007 @ 11:38:
Dat zou kunnen, als hij van allerlei exotisch goed gebruik maakt. Maar zelf geeft hij aan van niet. Het is gewoon standaard "number crunching" zoals hij het noemt.

Als de Athlon in floating point (bijvoorbeeld) een klein beetje langzamer is dan de Pentium D, maar zijn hele programma draait op floating point gereken (standaard number crunching dus), dan kan het een behoorlijk verschil opleveren natuurlijk.

[voodooless]

Jaap-Jan schreef op donderdag 15 november 2007 @ 11:47:
Hij heeft het over de uitvoeringstijd van het programma, niet over de compiletijd.

Ik ook

Over bovenstaande: Dat zou nooit een dergelijk groot verschil verklaren. Onze numbercrunsher draait op een Athlon sneller dan op een pentium4, en doet eigenlijk alleen maar pow en sqrt.

Let er ook op welke van de math functies je gebruikt. Ik heb al gezien dat bijvoorbeeld powl (long double), veel sneller is dan powf of pow, ook al zou je dat niet direct verwachten.

[ Voor 47% gewijzigd door voodooless op 15-11-2007 12:04 ]

[DieterVDW]

Gerco schreef op donderdag 15 november 2007 @ 11:24:
Daarnaast heeft een Pentium D twee cores en een Athlon 64 niet, dat kan natuurlijk ook nog wel het 1 en ander schelen (of is het eigenlijk een X2?).

Het programma is single-threaded, dus dat zou geen issue mogen zijn.

Voor zover ik weet gebruikt de applicatie trouwens geen floating point logica.
Het geïmplementeerde algoritme is speciaal ontwikkeld om dmv integer operaties te kunnen uitgevoerd worden.

Net even getest in cygwin met gcc-3.4.4 en het resultaat is idd ook niet al te best: 22s .
Blijkbaar is het probleem dus compiler gebonden...
Ik zal even gcc-4 installeren en daarmee nog eens proberen, maar ik veronderstel dus dat de microsoft compiler gcc gewoon van de aardbol blaast ...
Zijn er goeie alternatieve c++ compilers voor linux?

Edit: blijkbaar is gcc-3.4.4 de meest recent beschikbare gcc versie voor cygwin?
Ik bekijk mingw eens ...

[ Voor 52% gewijzigd door DieterVDW op 15-11-2007 12:37 ]

[.oisyn]

Een belangrijk verschil kan de implementatie van de standaard functies zijn. En zelfs dingen als de conversie van float naar int kunnen een dure functie aanroepen ipv gewoon een fsti instructie te genereren.

.edit: oh ik lees net dat er dus geen floats worden gebruikt. Wat voor operaties gebruik je dan wel? Een mul of div op een int64 is ook niet altijd wat het lijkt, tenzij je echt voor 64 bits aan het compilen bent.

[ Voor 34% gewijzigd door .oisyn op 15-11-2007 12:41 ]

[voodooless]

DieterVDW schreef op donderdag 15 november 2007 @ 12:28:
Edit: blijkbaar is gcc-3.4.4 de meest recent beschikbare gcc versie voor cygwin?
Ik bekijk mingw eens ...

http://www.thisiscool.com/gcc_mingw.htm

Gebruik efffe -mtune=native -march=native, dan zit je wat dat betreft altijd goed op je lokale machine.

Volgende stap is natuurlijk om te kijken naar de assembler code om te zien waar de verschillen precies liggen.

[Verwijderd]

DieterVDW schreef op donderdag 15 november 2007 @ 12:28:
[...]
Zijn er goeie alternatieve c++ compilers voor linux?

Van GCC is bekend dat deze niet bepaald de snelste code produceerd. Een alternatief is de Intel compiler, waarvan bekend is dat deze een erg goede optimizer heeft (met name voor Intel processoren).

[user109731]

Heb je een bepaalde voorbeeld functie (die je hier kunt posten) waarbij het probleem zich voordoet? Als ik jou was zou ik (zoals al gezegd) eerst eens profilen om te zien waar de meeste tijd in zit, en daarna een eenvoudige testcase schrijven. Dan is je probleem veel concreter en kun je zoeken naar een workaround ofzo.. Zo blijft het giswerk.

Ik ben ook wel benieuwd of gcc 4.3 nog verbetering geeft...

[SKiLLa]

Verwijderd schreef op donderdag 15 november 2007 @ 12:47:
[...]


Van GCC is bekend dat deze niet bepaald de snelste code produceerd. Een alternatief is de Intel compiler, waarvan bekend is dat deze een erg goede optimizer heeft (met name voor Intel processoren).

Die Intel compilers zijn inderdaad erg rap, maar ook erg prijzig

[DieterVDW]

De doelmachine is wel de Athlon. Ik zou het daarop een beetje performant moeten krijgen.

[Verwijderd]

mijn antwoord: profilen

eerst uitzoeken welke functie dat verschil maakt en daar de oplossing bijzoeken. menig IDE heeft wel een mooie interface om dat uit te zoeken. voor windows bevat bijvoorbeeld Dev-C++ een profiler die precies aangeeft hoevaak een functie is aangeroepen hoeveel tijd er aan besteed is. letop: een profile-build is groter en kan meer problemen in de onderlinge verschillen blootleggen, zeker in zulke kleine programma's maar ik weet natuurlijk niet precies hoe tight je loop is. mischien kun ons vertellen over precies wat je aan het numbercrunching bent als je geen source-code wilt posten dan hebben we tenminste een idee van de berekeningen die je aan het doen bent.

ook zeg je dat je compiled voor de athlon maar in gcc is dat volgensmij K7 en de Athlon64 is K8. check dus ff dat je geen K7 code zit te maken alhoewel dat niet zo'n verschil zou mogen zijn. ook zeg je niet of je Debian AMD64 draait. 64bit moet natuurlijk wat meer data verslepen omdat je integer's 2x zo groot zijn en ik weet van mezelf dat het met linux maar al te verleidelijk is om die AMD64 iso te pakken.

*edit:
nog een ideetje wat mij net te binnen schiet: probeer de Windows binary eens met Wine te draaien.

[ Voor 4% gewijzigd door Verwijderd op 16-11-2007 09:24 ]

[voodooless]

Verwijderd schreef op vrijdag 16 november 2007 @ 09:18:64bit moet natuurlijk wat meer data verslepen omdat je integer's 2x zo groot zijn en ik weet van mezelf dat het met linux maar al te verleidelijk is om die AMD64 iso te pakken.

Aan de andere kant heb je meer registers ter beschikking wat dus ook een voordeel kan zijn.

[Verwijderd]

voodooless schreef op vrijdag 16 november 2007 @ 09:24:
[...]


Aan de andere kant heb je meer registers ter beschikking wat dus ook een voordeel kan zijn.

klopt en in de meeste programma's is dit een voordeel. maar een 64bit binary die dus met 64bit integers werkt in een zeer compact programma kan dit verschil plots zichtbaar worden. en in Linux heb je soms niet eens door dat je 64bit draait en bakt gcc dus ook keurig een 64bit binary. subtiel verschil dat wel.

[voodooless]

Indien 64 bit debian dus even met -m32 compileren en nog eens testen

[Verwijderd]

ik heb trouwens eens even die post uit de mailinglist van de topic-start doorgelezen en in de followups bleek werd een profile ge-post waarin goed duidelijk werd dat erg veel tijd in de log1() functie ging zitten die waarschijnlijk weer IEEE754 functie's aanroepte. IEE754 is volgensmij de floating-point standaard en daar werd dus goed duidelijk dat het verschil zat in de implementatie of on-optimalizatie van de floating-point functies. zie deze post: http://gcc.gnu.org/ml/gcc-help/2005-04/msg00219.html

[.oisyn]

De TS had al gezegd dat er geen floating point math gebruikt werd.

[Verwijderd]

maar hij kan zonder het te beseffen toch floating-point math gebruiken. een functie kan intern best een kostbare floatingpoint berekening doen zonder het te beseffen. maar zonder profiling zul je dat natuurlijk nooit weten of je moet de assembly zelf gaan doorspitten.

[DieterVDW]

De code bevat enorm veel integer operaties en conditionele sprongen.
Ik vermoed dat de VS compiler gewoon een véél betere branch prediction heeft of zo ... ?

Ik zie niks bijzonder aan het profilen, maar misschien moet ik dit eens vergelijken met een profile run van de VS binary. Coming up ...

[Soultaker]

Het verschil kan 'm mijn idee in een stuk of vier dingen zitten:
• Pentium D versus AMD Athlon64;
• Windows kernel functies versus Linux kernel functies (waarschijnlijk gerelateerd aan I/O);
• MSVC library versus Linux libc;
• Microsoft C/C++ compiler versus GCC.
Het lijkt me handig om een aantal van deze dingen uit te sluiten/uit te zoeken, anders blijft het speculeren. Ik denk dat je conclusie dat de persoon op de mailinglist precies hetzelfde probleem heeft sowieso voorbarig is.

[DieterVDW]

Wel, als ik de code compileer op de windows machine met gcc, krijg ik ook een uitvoeringstijd van +- 25s . Ik verdenk dus heel hard de compiler...

[Verwijderd]

DieterVDW schreef op zaterdag 17 november 2007 @ 15:29:
De code bevat enorm veel integer operaties en conditionele sprongen.
Ik vermoed dat de VS compiler gewoon een véél betere branch prediction heeft of zo ... ?

Branch prediction zit niet in de compiler maar in de processor. En ja, er zitten verschillen in de branch predictors tussen processoren, en ook de kosten van een misprediction verschillen.

Op dit moment ben je aan het gokken omdat je twee totaal verschillende systemen, met twee totaal verschillen compilers (en compiler instellingen), met twee totaal verschillende runtime libraries aan het vergelijken ben. Dat zijn teveel variabelen om te kunnen vaststellen waar het verschil nu precies in zit. De suggestie om een LiveCD te gebruiken om in ieder geval één factor uitsluiten is een goed begin.

[Soultaker]

Verwijderd schreef op zaterdag 17 november 2007 @ 16:25:
Branch prediction zit niet in de compiler maar in de processor. En ja, er zitten verschillen in de branch predictors tussen processoren, en ook de kosten van een misprediction verschillen.

De compiler heeft behoorlijk grote invloed op de mate waarin branch prediction effectief is. Dat gebeurt zeker wanneer je optimaliseert voor een specifieke processor (bijvoorbeeld Intel's compiler heeft nogal wat opties om code te tunen, eventueel met behulp van profile informatie).

DieterVDW schreef op zaterdag 17 november 2007 @ 16:12:
Wel, als ik de code compileer op de windows machine met gcc, krijg ik ook een uitvoeringstijd van +- 25s . Ik verdenk dus heel hard de compiler...

Link je nu nog wel tegen dezelfde C library (msvcrt.lib)? En welke versie van GCC is dit?

[Verwijderd]

DieterVDW schreef op zaterdag 17 november 2007 @ 16:12:
Wel, als ik de code compileer op de windows machine met gcc, krijg ik ook een uitvoeringstijd van +- 25s . Ik verdenk dus heel hard de compiler...

En hoe is de uitvoeringstijd met MS VS? Dat GCC niet de snelste code genereert is algemeen bekend, maar een verschil van meer dan een tiental procenten is wel erg veel.

Soms kan het in kleine dingen zitten. Zo heeft een collega van mij eens geprobeerd om een een stuk code te optimaliseren door een aantal float operaties te vervangen door integer operaties. Het resultaat was dat de "geoptimaliseerde" code meer dan 10x langzamer was dan de oorspronkelijke code omdat in een kritische loop een float naar integer conversie was toegevoegd. En als de compiler er niet van uit kan gaan dat de rounding mode van de FPU goed staat is dat een bijzonder dure operatie.

Ook compiler opties kunnen soms verrassende effecten opleveren, bijv. het inschakelen van de ANSI-C compatibiliteit mode op de MS VS compiler schakelt impliciet ook de "improve float consistency" optie in. Deze laatste optie kan floating point intensieve code factoren langzamer maken, omdat met deze optie tussenresultaten niet in de registers gehouden worden maar telkens naar het geheugen geschreven worden om afronding naar 32- of 64-bit te forceren.

Nu betreft het in dit geval kennelijk integer code, maar ook daar hebben compiler opties invloed op. Vaak is het in dit soort gevallen interessant om naar de assembler output te kijken.

Van de week had ik overigens een discussie met een collega die opmerkte dat shared libraries bij Linux position independent zijn, dit in tegenstelling tot Windows waarbij het OS DLL's 'patched' als deze niet op hun preferred load address geladen kunnen worden. Jumps in position independent code zijn trager en (volgens die collega) wordt daarvoor ook beslag gelegd op een register (waar je er bij x86 instructieset sowieso al een structureel tekort aan registers hebt). Ik heb zelf nog niet de behoefte gehad om de assembly output van GCC op Linux te controleren, maar zijn verhaal klonk plausibel. Mogelijk dat GCC voor alle targets position independent code genereert.

[Soultaker]

Volgens mij zijn op een IA-32 architectuur libraries standaard ook niet position-independent (en worden dus gefixt bij het laden als het gewenste adres niet vrij is). Op AMD64 is dat anders, en sommige packages compileren expliciet wél position-independent code (geen idee waarom precies).

[DieterVDW]

Zodra ik maandag terug bij mijn PC ben stop ik er eens Knoppix in en compileer ik de boel met gcc-4 op mijn Pentium D machine. Ik hou jullie op de hoogte.

Ter informatie: het gaat hier over zeer complexe code van +-20000 lijnen code ...
Om de assembly output daarvan te beginnen analyseren ...

Maar zoals gezegd, ik ga eens een vergelijking maken tussen de profiling op linux en windows, misschien dat daarin duidelijk wordt dat een bepaalde subroutine veel meer tijd inneemt onder linux dan onder windows ...

[Gerco]

DieterVDW schreef op zaterdag 17 november 2007 @ 22:37:
Ter informatie: het gaat hier over zeer complexe code van +-20000 lijnen code ...
Om de assembly output daarvan te beginnen analyseren ...

Dat doe je dan ook niet natuurlijk. Je draait de profiler over de code en analyseert hooguit de paar subroutines die buitensporig veel tijd lijken te kosten.

[DieterVDW]

Ter informatie: dezelfde code gecompileerd en uitgevoerd onder Knoppix op mijn Windows machine neemt 21s in beslag. Een tikje beter, allicht door de krachtiger CPU (?) , maar nog steeds stukken trager dan de code gecompileerd met de VS compiler dus ...