Extreme Geschwindigkeitsunterschiede

Übersicht

Sonstiges

Smalltalk

Gehe zu Seite 1, 2 Weiter

	ByteCroc Betreff: Extreme Geschwindigkeitsunterschiede	Di, Jul 17, 2007 22:37 Antworten mit Zitat
Ich habe gestern bemerkt das MinGW DLL Funktionen langsamer rechnen als interne Blitz3D Funktionen, es handelt sich dabei um exakt die gleiche Berechnung, da hab ich zuerst PellesC und dann noch VisualC++ 8.0 Express(heute gezogen) dagegen verglichen. Irgendwie war ich dann doch erleichtert etwas schnelleres wie Blitz3D gefunden zu haben. Das der Unterschied aber so krass ist hätte ich nie gedacht. Es ist keine sinnvolle Funktion, ich wollte zuerst nur die Grundrechenarten zwischen Blitz3D und MinGW testen, da gab es ohne interne Schleife bei 10.000.000 Funktionsdurchläufen keinen Gewinner. Dann hab ich eine Schleife mit 3 Durchgängen dazu geben und MinGW wurde langsamer, Ok noch eine Cos() welche intern eine kleine Berechnung hat und Typumwandlung, dann war der Unterschied 3-3,5 mal langsamer als Blitz3D. Was mich etwas wundert ist die Zeit von VisualC++, der erste Durchgang ist immer der langsamste, danach ist es blitzschnell, 100 mal schneller als Blitz3D und noch viel schneller als MinGW. Evtl. Puffert VC die Übergabewerte und wenn die identisch sind, gibts nur noch das Ergebniss, sonst verstehe ich den Unterschied zwischen erster Schleife von VC und den nächsten nicht. Evtl. kennt einer von euch das Geheimnis. Alle Compiler wurden auf beste Optimierung eingestellt, kein Debug Modus. Die Ergebnisse: Code: [AUSKLAPPEN] [EINKLAPPEN] MinGW-DLLFunktion: 5012 PellesCfunc: 1624 VisualC-DLLFunktion: 247 Blitz-Funktion: 1788 MinGW-DLLFunktion: 4976 PellesCfunc: 1622 VisualC-DLLFunktion: 19 Blitz-Funktion: 1787 MinGW-DLLFunktion: 4962 PellesCfunc: 1628 VisualC-DLLFunktion: 18 Blitz-Funktion: 1791 MinGW-DLLFunktion: 4967 PellesCfunc: 1625 VisualC-DLLFunktion: 18 Blitz-Funktion: 1791 MinGW-DLLFunktion: 4975 PellesCfunc: 1626 VisualC-DLLFunktion: 18 Blitz-Funktion: 1795 MinGW-DLLFunktion: 4971 PellesCfunc: 1626 VisualC-DLLFunktion: 18 Blitz-Funktion: 1793 Die Funktion in Blitz3D Code und C++ Code Code: [AUSKLAPPEN] [EINKLAPPEN] Function bbmathetest( a, b ) Local c Local d,e Local result d = a e = b c = a + b b = c / a a = c - b b = a * c For i = 0 To 100 a = d b = e c = a + b b = c / a a = c - b b = a * c result = Int(Cos (Float(b)3.14/180.0)) Next Return result End Function BBDECL int BBCALL VCmathetest( int a, int b ) { int c; int d,e; int result; d = a; e = b; c = a + b; b = c / a; a = c - b; b = a c; for (int i = 0 ;i <= 100 ; i++ ) { a = d; b = e; c = a + b; b = c / a; a = c - b; b = a * c; result = int(cos (float(b)*3.14/180.0)); } return result; }

ByteCroc

Betreff: Extreme Geschwindigkeitsunterschiede

Di, Jul 17, 2007 22:37
Antworten mit Zitat

Ich habe gestern bemerkt das MinGW DLL Funktionen langsamer rechnen als interne Blitz3D Funktionen, es handelt sich dabei um exakt die gleiche Berechnung, da hab ich zuerst PellesC und dann noch VisualC++ 8.0 Express(heute gezogen) dagegen verglichen.
Irgendwie war ich dann doch erleichtert etwas schnelleres wie Blitz3D gefunden zu haben. Das der Unterschied aber so krass ist hätte ich nie gedacht.

Es ist keine sinnvolle Funktion, ich wollte zuerst nur die Grundrechenarten zwischen Blitz3D und MinGW testen, da gab es ohne interne Schleife bei 10.000.000 Funktionsdurchläufen keinen Gewinner.
Dann hab ich eine Schleife mit 3 Durchgängen dazu geben und MinGW wurde langsamer, Ok noch eine Cos() welche intern eine kleine Berechnung hat und Typumwandlung, dann war der Unterschied 3-3,5 mal langsamer als Blitz3D.

Was mich etwas wundert ist die Zeit von VisualC++, der erste Durchgang ist immer der langsamste, danach ist es blitzschnell, 100 mal schneller als Blitz3D und noch viel schneller als MinGW.
Evtl. Puffert VC die Übergabewerte und wenn die identisch sind, gibts nur noch das Ergebniss, sonst verstehe ich den Unterschied zwischen erster Schleife von VC und den nächsten nicht.
Evtl. kennt einer von euch das Geheimnis.

Alle Compiler wurden auf beste Optimierung eingestellt, kein Debug Modus.

Die Ergebnisse:

Code: [AUSKLAPPEN]

MinGW-DLLFunktion:    5012
PellesCfunc:       1624
VisualC-DLLFunktion:    247
Blitz-Funktion:    1788

MinGW-DLLFunktion:    4976
PellesCfunc:       1622
VisualC-DLLFunktion:    19
Blitz-Funktion:    1787

MinGW-DLLFunktion:    4962
PellesCfunc:       1628
VisualC-DLLFunktion:    18
Blitz-Funktion:    1791

MinGW-DLLFunktion:    4967
PellesCfunc:       1625
VisualC-DLLFunktion: 18
Blitz-Funktion:    1791

MinGW-DLLFunktion:    4975
PellesCfunc:       1626
VisualC-DLLFunktion:    18
Blitz-Funktion:    1795

MinGW-DLLFunktion:    4971
PellesCfunc:       1626
VisualC-DLLFunktion:    18
Blitz-Funktion:    1793

Die Funktion in Blitz3D Code und C++ Code
Code: [AUSKLAPPEN]

Function bbmathetest( a, b )
Local c
Local d,e
Local result
d = a
e = b
c = a + b
b = c / a
a = c - b
b = a * c
For i = 0 To 100
a = d
b = e
c = a + b
b = c / a
a = c - b
b = a * c
result = Int(Cos (Float(b)*3.14/180.0))
Next

Return result
End Function

BBDECL int BBCALL VCmathetest( int a, int b ) {
int c;
int d,e;
int result;
d = a;
e = b;
c = a + b;
b = c / a;
a = c - b;
b = a * c;
for (int i = 0 ;i <= 100 ; i++ ) {
a = d;
b = e;
c = a + b;
b = c / a;
a = c - b;
b = a * c;
result = int(cos (float(b)*3.14/180.0));
}
return result;
}

	hectic Sieger des IS Talentwettbewerb 2006	Mi, Jul 18, 2007 1:29 Antworten mit Zitat
Bei jedem Geschwindigkeitstest sollte man kurz vor der Messung ein Delay 4000 oder so hinpacken. Denn gleich nach dem compilieren wird hier und da im Speicher noch ein bisschen rumgeschaufelt, und die Messung als solches bleibt ungenau. Noch besser ist folgendes: ~Delay 4000, dann 100mal die Schleife durchlaufenlassen, dann ~Delay 1000, dann Messung durchführen. Der ganze Umstand soll verhindern, dass eine Hochoptimierte Programmiersprache, die nach dem Start sich selber ordnet um schneller zu sein, am Anfang dadurch logischer weise langsamer wird, gegenüber einer unoptimierter Programmiersprache 'verliert', weil die gleich von Anfang an gleich schnell bleibt, aber langsamer im Enddurchlauf und somit die unoptimierte gewinnt, weil die Messung nur 5 Sekunden ging... Hatte ich alles schon gehabt. Hinzu kommt noch, dass Geschwindigkeitsmessungen im Bereich von > 100'000 Durchläufe in < 5 Sekunden völlig irelevant sind, da selbst 5 fache Geschwindigkeitsunterschiede kaum ein Unterschied im Gesamtergebnis ergeben. Dagegen Geschwindigkeitsunterschiede mit zB Grafik, wo 1000 Durchläufe grad ein Unterschiedsfaktor von 1,5 erreichen, viel mehr ins Gewicht fallen aber durch die geringe 1,5 Relation gern ignoriert werden.
Download der Draw3D2 V.1.1 für schnelle Echtzeiteffekte über Blitz3D

hectic

Sieger des IS Talentwettbewerb 2006

Mi, Jul 18, 2007 1:29
Antworten mit Zitat

Bei jedem Geschwindigkeitstest sollte man kurz vor der Messung ein Delay 4000 oder so hinpacken. Denn gleich nach dem compilieren wird hier und da im Speicher noch ein bisschen rumgeschaufelt, und die Messung als solches bleibt ungenau. Noch besser ist folgendes: ~Delay 4000, dann 100mal die Schleife durchlaufenlassen, dann ~Delay 1000, dann Messung durchführen.

Der ganze Umstand soll verhindern, dass eine Hochoptimierte Programmiersprache, die nach dem Start sich selber ordnet um schneller zu sein, am Anfang dadurch logischer weise langsamer wird, gegenüber einer unoptimierter Programmiersprache 'verliert', weil die gleich von Anfang an gleich schnell bleibt, aber langsamer im Enddurchlauf und somit die unoptimierte gewinnt, weil die Messung nur 5 Sekunden ging... Hatte ich alles schon gehabt.

Hinzu kommt noch, dass Geschwindigkeitsmessungen im Bereich von > 100'000 Durchläufe in < 5 Sekunden völlig irelevant sind, da selbst 5 fache Geschwindigkeitsunterschiede kaum ein Unterschied im Gesamtergebnis ergeben. Dagegen Geschwindigkeitsunterschiede mit zB Grafik, wo 1000 Durchläufe grad ein Unterschiedsfaktor von 1,5 erreichen, viel mehr ins Gewicht fallen aber durch die geringe 1,5 Relation gern ignoriert werden.

Download der Draw3D2 V.1.1 für schnelle Echtzeiteffekte über Blitz3D

	David	Mi, Jul 18, 2007 7:56 Antworten mit Zitat
Hast du bei MinGW und Visual C++ wenigstens Codeoptimierung eingestellt? Unoptimierter Code ist logischerweise relativ langsam.
http://bl4ckd0g.funpic.de

David

Mi, Jul 18, 2007 7:56
Antworten mit Zitat

Hast du bei MinGW und Visual C++ wenigstens Codeoptimierung eingestellt? Unoptimierter Code ist logischerweise relativ langsam.

http://bl4ckd0g.funpic.de

	BtbN Betreff: Re: Extreme Geschwindigkeitsunterschiede	Mi, Jul 18, 2007 10:31 Antworten mit Zitat
ByteCroc hat Folgendes geschrieben: Alle Compiler wurden auf beste Optimierung eingestellt, kein Debug Modus.

BtbN

Betreff: Re: Extreme Geschwindigkeitsunterschiede

Mi, Jul 18, 2007 10:31
Antworten mit Zitat

ByteCroc hat Folgendes geschrieben:

Alle Compiler wurden auf beste Optimierung eingestellt, kein Debug Modus.

	ByteCroc	Mi, Jul 18, 2007 12:57 Antworten mit Zitat
@hectic danke das du das sagts, ich hatte immer das Gefühl konnte es aber nicht erklären warum Ich hatte bei einfachen Messungen immer eine volle 100000 er- 10000000 er Schleife ohne Zeitmessung davor geschaltet. Bei der obigen Messung nicht, das sieht man daran, daß der MinGW Wert, also die erste Messung immer höher ist als alle nachfolgenden, das ist bei allen durchgängen so. Vor und nach den Print und WriteLine Befehlen nach jedem Schleifendurchgang hatte ich ein Delay 100 rein gepackt. Ich habe nun deine Ratschläge mal genau befolgt, ein Delay 4000 vor und nach jedem Schleifendurchgang, eine leere Schleife zu Beginn und ein zusätzliches Delay 4000 am Anfang, aber die Ergebisse bleiben die selben, ausser das MinGW nun nicht mehr seinen höchsten Wert unbedingt in der ersten Schleife hat. Aber die anderen Schleifendurchgänge sind praktisch identisch. Als ich den Rechner eingeschaltet hatte, habe ich als erstes nochmal einen Test durchlaufen lassen, bevor ich irgend ein anderes Programm angerührt hatte. Da gab es ein selstsames Phänomen welches ich bis jetzt nicht wiederholen konnte. (habe allerdings den Rechner noch nicht wieder neu gestartet) VisualC++ hatte dort in der ersten Schleife einen doppelt so hohen Wert wie Blitz oder Pelles, wobei alle anderen Werte praktisch die selben sind wie immer. Und MinGW besitzt die erste Schleife, wenn da noch was im Hintergrund unbemerkt gearbeitet hat, dann hat es jedenfalls die anderen DLLs und Blitz nicht beeinflusst. Alle weitern Starts gehen immer gleich aus, wie oben. Ich habe da nur so eine Idee, ich vermute das Microsoft Vorteile hat, da es sein Betriebssystem ja genau kennt, die könnten einige Dinge wie Speicherverwaltung effizienter nutzen, wie es kein anderer Compilerbauer tun kann. Allerdings verstehe ich es bei Berechnungen nicht ganz, alle Compiler optimieren da i.d.R. so gut das man es mit Assembler direkt kaum besser hin bekommt. Und VC rechnet viel schneller. Bevor ich diesen Beitrag nun abgeschickt habe, habe ich noch einen weiteren Test gemacht und hab in der 100000er Schleife dem ersten Parameter der Funktion einen Zufallswert zugewiesen ( Rand(1, 20) ) also zwischenspeichern ist damit ausgeschlossen. Aber immernoch das selbe Verhältnis wie oben, der erste Durchgang beim VC ist bei 100000 Schleifendurchgängen ca. 10 mal schneller als Blitz und die nächsten fünf 100 mal schneller. Ich hab nun mal die Schleife auf 10000 gekürzt und bekomme nun ein überraschendes Ergebnis, alle Werte von Blitz, Pelles und MinGW sind wie zu erwarten um den 10 fachen Wert niederer, ausser die von VC. Ich habe nicht vergessen den Schleifenzähler bei VC zu ernidrigen, ich benutze eine Variable welche ich nur einmal für alle ändern muss. Code: [AUSKLAPPEN] [EINKLAPPEN] MGfunc: 492 PellesCfunc: 161 VCfunc: 233 BBfunc: 177 ------------------------- MGfunc: 493 PellesCfunc: 160 VCfunc: 2 BBfunc: 179 ------------------------- MGfunc: 492 PellesCfunc: 162 VCfunc: 2 BBfunc: 176 ------------------------- MGfunc: 497 PellesCfunc: 160 VCfunc: 2 BBfunc: 176 ------------------------- MGfunc: 492 PellesCfunc: 161 VCfunc: 2 BBfunc: 177 ------------------------- MGfunc: 492 PellesCfunc: 162 VCfunc: 1 BBfunc: 178 ------------------------- Ich glaube ich hab die Lösung, da die Testfunktion nicht besonders intelligent ist, rechnet sie 100 mal mit den selben Werten, der VC Compiler hat das sicherlich entdeckt und rechnet nur eine Runde, da ja eh immer das selbe berechnet wird. Ich werde mal ein paar intelligentere Testfunktionen schreiben und werde es euch mitteilen ob VC immer noch der schnellste bleibt. Edit: hectic hat Folgendes geschrieben: Hinzu kommt noch, dass Geschwindigkeitsmessungen im Bereich von > 100'000 Durchläufe in < 5 Sekunden völlig irelevant sind, da selbst 5 fache Geschwindigkeitsunterschiede kaum ein Unterschied im Gesamtergebnis ergeben. Dagegen Geschwindigkeitsunterschiede mit zB Grafik, wo 1000 Durchläufe grad ein Unterschiedsfaktor von 1,5 erreichen, viel mehr ins Gewicht fallen aber durch die geringe 1,5 Relation gern ignoriert werden. Ich brauche die DLLs um viel Rechnerei auszulagern, wenn ich also das ganze Programm ausser die Grafik (geht ja nicht anders) in die DLL auslagere, dann hab ich bei jedem Hauptprogramm Schleifendurchlauf eine Verbesserung um x%, das will ich ja nun genauer heraus finden.

ByteCroc

Mi, Jul 18, 2007 12:57
Antworten mit Zitat

@hectic
danke das du das sagts, ich hatte immer das Gefühl konnte es aber nicht erklären warum
Ich hatte bei einfachen Messungen immer eine volle 100000 er- 10000000 er Schleife ohne Zeitmessung davor geschaltet.
Bei der obigen Messung nicht, das sieht man daran, daß der MinGW Wert, also die erste Messung immer höher ist als alle nachfolgenden, das ist bei allen durchgängen so.

Vor und nach den Print und WriteLine Befehlen nach jedem Schleifendurchgang hatte ich ein Delay 100 rein gepackt.

Ich habe nun deine Ratschläge mal genau befolgt, ein Delay 4000 vor und nach jedem Schleifendurchgang, eine leere Schleife zu Beginn und ein zusätzliches Delay 4000 am Anfang, aber die Ergebisse bleiben die selben, ausser das MinGW nun nicht mehr seinen höchsten Wert unbedingt in der ersten Schleife hat.

Aber die anderen Schleifendurchgänge sind praktisch identisch.

Als ich den Rechner eingeschaltet hatte, habe ich als erstes nochmal einen Test durchlaufen lassen, bevor ich irgend ein anderes Programm angerührt hatte.
Da gab es ein selstsames Phänomen welches ich bis jetzt nicht wiederholen konnte. (habe allerdings den Rechner noch nicht wieder neu gestartet)
VisualC++ hatte dort in der ersten Schleife einen doppelt so hohen Wert wie Blitz oder Pelles, wobei alle anderen Werte praktisch die selben sind wie immer. Und MinGW besitzt die erste Schleife, wenn da noch was im Hintergrund unbemerkt gearbeitet hat, dann hat es jedenfalls die anderen DLLs und Blitz nicht beeinflusst.
Alle weitern Starts gehen immer gleich aus, wie oben.

Ich habe da nur so eine Idee, ich vermute das Microsoft Vorteile hat, da es sein Betriebssystem ja genau kennt, die könnten einige Dinge wie Speicherverwaltung effizienter nutzen, wie es kein anderer Compilerbauer
tun kann. Allerdings verstehe ich es bei Berechnungen nicht ganz, alle Compiler optimieren da i.d.R. so gut das man es mit Assembler direkt kaum besser hin bekommt. Und VC rechnet viel schneller.

Bevor ich diesen Beitrag nun abgeschickt habe, habe ich noch einen weiteren Test gemacht und hab in der 100000er Schleife dem ersten Parameter der Funktion einen Zufallswert zugewiesen ( Rand(1, 20) )
also zwischenspeichern ist damit ausgeschlossen.
Aber immernoch das selbe Verhältnis wie oben, der erste Durchgang beim VC ist bei 100000 Schleifendurchgängen ca. 10 mal schneller als Blitz und die nächsten fünf 100 mal schneller.

Ich hab nun mal die Schleife auf 10000 gekürzt und bekomme nun ein überraschendes Ergebnis, alle Werte von Blitz, Pelles und MinGW sind wie zu erwarten um den 10 fachen Wert niederer, ausser die von VC.
Ich habe nicht vergessen den Schleifenzähler bei VC zu ernidrigen, ich benutze eine Variable welche ich nur einmal für alle ändern muss.

Code: [AUSKLAPPEN]

MGfunc: 492
PellesCfunc: 161
VCfunc: 233
BBfunc: 177
-------------------------
MGfunc: 493
PellesCfunc: 160
VCfunc: 2
BBfunc: 179
-------------------------
MGfunc: 492
PellesCfunc: 162
VCfunc: 2
BBfunc: 176
-------------------------
MGfunc: 497
PellesCfunc: 160
VCfunc: 2
BBfunc: 176
-------------------------
MGfunc: 492
PellesCfunc: 161
VCfunc: 2
BBfunc: 177
-------------------------
MGfunc: 492
PellesCfunc: 162
VCfunc: 1
BBfunc: 178
-------------------------

Ich glaube ich hab die Lösung, da die Testfunktion nicht besonders intelligent ist, rechnet sie 100 mal mit den selben Werten, der VC Compiler hat das sicherlich entdeckt und rechnet nur eine Runde, da ja eh immer das selbe berechnet wird.
Ich werde mal ein paar intelligentere Testfunktionen schreiben und werde es euch mitteilen ob VC immer noch der schnellste bleibt.

Edit:

hectic hat Folgendes geschrieben:

Hinzu kommt noch, dass Geschwindigkeitsmessungen im Bereich von > 100'000 Durchläufe in < 5 Sekunden völlig irelevant sind, da selbst 5 fache Geschwindigkeitsunterschiede kaum ein Unterschied im Gesamtergebnis ergeben. Dagegen Geschwindigkeitsunterschiede mit zB Grafik, wo 1000 Durchläufe grad ein Unterschiedsfaktor von 1,5 erreichen, viel mehr ins Gewicht fallen aber durch die geringe 1,5 Relation gern ignoriert werden.

Ich brauche die DLLs um viel Rechnerei auszulagern, wenn ich also das ganze Programm ausser die Grafik (geht ja nicht anders) in die DLL auslagere, dann hab ich bei jedem Hauptprogramm Schleifendurchlauf eine Verbesserung um x%, das will ich ja nun genauer heraus finden.

	TheShadow Moderator	Mi, Jul 18, 2007 19:11 Antworten mit Zitat
Solche Tests wo Mathe-Formeln in For-Schleife stehen, sind sinnlos... da einige Compiler das erkennen und die Schleife dann optimieren... Außerdem ist MinGW langsamer als VC weiterhin ist nicht zu erkennen ob du C++ oder C code hast... C++ ist ebenfalls langsamer... Ich weiß auch nicht welchen Optimierungsschalter du in MinGW nutzt... Ich weiß aber dass MinGW unter Windows irg. weniger gut ist... z.B. die ganzn Prozessor-Optimierungsschalter scheinen sinnlos zu sein, da ich keinen unterschied sehen konnte... hier ein Vergleich: http://shootout.alioth.debian....;lang2=gpp ich hatte auch eigene tests gemacht, wo es um function-calls ohne berechnungen ging und da war blitzmax native function langsamer als wenn ich eine DLL-Funktion aus C aufrufen würde...
AMD64 3500+ \| GeForce6600GT 128MB \| 1GB DDR \| WinXPsp2

TheShadow

Moderator

Mi, Jul 18, 2007 19:11
Antworten mit Zitat

Solche Tests wo Mathe-Formeln in For-Schleife stehen, sind sinnlos... da einige Compiler das erkennen und die Schleife dann optimieren... Außerdem ist MinGW langsamer als VC

weiterhin ist nicht zu erkennen ob du C++ oder C code hast... C++ ist ebenfalls langsamer...

Ich weiß auch nicht welchen Optimierungsschalter du in MinGW nutzt... Ich weiß aber dass MinGW unter Windows irg. weniger gut ist... z.B. die ganzn Prozessor-Optimierungsschalter scheinen sinnlos zu sein, da ich keinen unterschied sehen konnte...

hier ein Vergleich:
http://shootout.alioth.debian....;lang2=gpp

ich hatte auch eigene tests gemacht, wo es um function-calls ohne berechnungen ging und da war blitzmax native function langsamer als wenn ich eine DLL-Funktion aus C aufrufen würde...

AMD64 3500+ | GeForce6600GT 128MB | 1GB DDR | WinXPsp2

	ByteCroc	Mi, Jul 18, 2007 20:30 Antworten mit Zitat
TheShadow hat Folgendes geschrieben: Solche Tests wo Mathe-Formeln in For-Schleife stehen, sind sinnlos... da einige Compiler das erkennen und die Schleife dann optimieren... Außerdem ist MinGW langsamer als VC Ich werde mal versuchen verschiedene Rechenoperationen in verschiedene Funktionen zu packen, diesmal werde ich auch darauf achten das in jeder Schleife neue Zahlen zum Zuge kommen, damit da nicht etwas wegoptimiert wird und ich schnellere ergebnisse bekomme als ich nachher tatsächlich habe. MinGW benutzt ja noch die 3.xx Reihe des GCC man kann zwar auf 4.1.2 updaten, aber da hatte ich im Netz schon von einigen Problemen gelesen. Ich werde es mal mit einer 2. Installation ausprobieren. Was mich etwas irritiert sind die Geschwindigkeitsunterschiede beim VC++ der erste Durchgang ist immer der langsamste und dann gibt er Gas. TheShadow hat Folgendes geschrieben: weiterhin ist nicht zu erkennen ob du C++ oder C code hast... C++ ist ebenfalls langsamer... C++ Code Filename.cpp ausser bei PellesC. Auch die Schalter (sofern welche vorhanden) stehen auf C++ Code ausführen. Die Berechnung ist eh für beide Arten fast identisch bei PellesC sieht nur eine Zeile anders aus result=(int)(cos(((float)b)*3.14/180.0)); Wenn C Code mit dem selben Compiler wirklich schneller sein sollte werd ich das dann auch mal testen. TheShadow hat Folgendes geschrieben: ich weiß auch nicht welchen Optimierungsschalter du in MinGW nutzt... Ich weiß aber dass MinGW unter Windows irg. weniger gut ist... z.B. die ganzn Prozessor-Optimierungsschalter scheinen sinnlos zu sein, da ich keinen unterschied sehen konnte... Ich optimiere auf schnellsten Code, bei allen Compilern, sofern ich alle Schalter gefunden hab. Die Vergleichsliste hab ich heute auch schonmal angeschaut, leider sind da keine verschiedenen C++ Compiler drin und Vergleiche zwischen GCC und VC++ finde ich keine, da gibts ja noch Digital Mars und Open Watcom, das dauert eine weile bis ich mich da durch getestet hab.

ByteCroc

Mi, Jul 18, 2007 20:30
Antworten mit Zitat

TheShadow hat Folgendes geschrieben:

Solche Tests wo Mathe-Formeln in For-Schleife stehen, sind sinnlos... da einige Compiler das erkennen und die Schleife dann optimieren... Außerdem ist MinGW langsamer als VC

Ich werde mal versuchen verschiedene Rechenoperationen in verschiedene Funktionen zu packen, diesmal werde ich auch darauf achten das in jeder Schleife neue Zahlen zum Zuge kommen, damit da nicht etwas wegoptimiert wird und ich schnellere ergebnisse bekomme als ich nachher tatsächlich habe.

MinGW benutzt ja noch die 3.xx Reihe des GCC
man kann zwar auf 4.1.2 updaten, aber da hatte ich im Netz schon von einigen Problemen gelesen.
Ich werde es mal mit einer 2. Installation ausprobieren.

Was mich etwas irritiert sind die Geschwindigkeitsunterschiede beim VC++
der erste Durchgang ist immer der langsamste und dann gibt er Gas.

TheShadow hat Folgendes geschrieben:

weiterhin ist nicht zu erkennen ob du C++ oder C code hast... C++ ist ebenfalls langsamer...

C++ Code Filename.cpp ausser bei PellesC.
Auch die Schalter (sofern welche vorhanden) stehen auf C++ Code ausführen.
Die Berechnung ist eh für beide Arten fast identisch bei PellesC sieht
nur eine Zeile anders aus

result=(int)(cos(((float)b)*3.14/180.0));

Wenn C Code mit dem selben Compiler wirklich schneller sein sollte werd ich das dann auch mal testen.

TheShadow hat Folgendes geschrieben:

ich weiß auch nicht welchen Optimierungsschalter du in MinGW nutzt... Ich weiß aber dass MinGW unter Windows irg. weniger gut ist... z.B. die ganzn Prozessor-Optimierungsschalter scheinen sinnlos zu sein, da ich keinen unterschied sehen konnte...

Ich optimiere auf schnellsten Code, bei allen Compilern, sofern ich alle Schalter gefunden hab.

Die Vergleichsliste hab ich heute auch schonmal angeschaut, leider sind da keine verschiedenen C++ Compiler drin und Vergleiche zwischen GCC und VC++ finde ich keine, da gibts ja noch Digital Mars und Open Watcom, das dauert eine weile bis ich mich da durch getestet hab.

	David	Do, Jul 19, 2007 8:08 Antworten mit Zitat
ByteCroc hat Folgendes geschrieben: Wenn C Code mit dem selben Compiler wirklich schneller sein sollte werd ich das dann auch mal testen. So ein Unsinn.
http://bl4ckd0g.funpic.de

David

Do, Jul 19, 2007 8:08
Antworten mit Zitat

ByteCroc hat Folgendes geschrieben:

Wenn C Code mit dem selben Compiler wirklich schneller sein sollte werd ich das dann auch mal testen.

So ein Unsinn.

http://bl4ckd0g.funpic.de

	ByteCroc	Mo, Jul 23, 2007 18:34 Antworten mit Zitat
Ich hab jetzt TurboC++, VisualC++, PellesC und MinGW mit GCC 4.1.2 gegeeinander getestet. Wenn ich die Funktionen in 100000er Schleifen gegeneinander teste kommen zum Teil schon erhebliche Unterschiede dabei heraus. Allerdings ist z.B. der MinGW in den Mathe Tests der langsamste, dafür bei den C-Strings der schnellste. Wenn ich nun ein kleines 3D Programm erstelle, in dem ich die Maus abfrage einen Würfel alle 100 Durchgänge mit einem anderen Brush belege und den Würfel mit TurnEntity drehe, in dieses Programm die Funktionen in kleinen 25er Schleifen rein packe, dann sind alle in etwa gleich schnell ( bei 3000 Hauptprogramm Durchgängen) Auf einem Computer sind die Blitz-Funktionen leicht vorne auf zwei anderen sind sie etwas langsamer, dabei habdelt es sich aber nur um 0.1% bis 0.4 % Der MinGW schein mir der einsteigerfreundlichste zu sein, er compiliert fast alles und gibt dazu noch das richtige Ergebnis aus, TurboC++ schluckt auch eine Menge, aber VC++ meckert ziemlich oft und compiliert vieles nicht. Dafür ist die Exe bei MinGW ein vielfaches größer, PellesC generiert die kleinste. z.B. gibt MinGW hier einen String an Blitz3D zurück const char * funcname() { string MyString; .... ... return MyString.c_str(); } TurboC++ einen halben Kryptischen und die andere Hälfte richtig. VC++ gar nichts. PellesC ist nur C, da geht es nicht. -------------------------------------------- Bei den reinen C Strings rechnet MinGW am schnellsten und ist in der Funktions-Schleife doppelt so schnell wie Blitz aber wenn man die Zeit mit 3000 3D-Programmdurchläufen vergleicht, sind alle sogut wie gleich schnell. TurboC++ gibt in zusammenarbeit mit Blitz3D einen " blizcc.exe Domain-Error asin (acos) " aus wenn man die math.h Funktionen asin() und acos() verwendet, alle anderen funktionieren. Zum arbeiten gefällt mir der Turbo C++ 2006 ab besten, aber der MinGW schluckt alle C++ Beispiele die man finden kann und scheint mir von der Norm her derjenige zu sein der alles so umsetzt wie es in den Büchern steht.

ByteCroc

Mo, Jul 23, 2007 18:34
Antworten mit Zitat

Ich hab jetzt TurboC++, VisualC++, PellesC und MinGW mit GCC 4.1.2 gegeeinander getestet.

Wenn ich die Funktionen in 100000er Schleifen gegeneinander teste kommen zum Teil schon erhebliche Unterschiede dabei heraus.
Allerdings ist z.B. der MinGW in den Mathe Tests der langsamste, dafür bei den C-Strings der schnellste.

Wenn ich nun ein kleines 3D Programm erstelle, in dem ich die Maus abfrage einen Würfel alle 100 Durchgänge mit einem anderen Brush belege und den Würfel mit TurnEntity drehe, in dieses Programm die Funktionen in kleinen 25er Schleifen rein packe, dann sind alle in etwa gleich schnell ( bei 3000 Hauptprogramm Durchgängen) Auf einem Computer sind die Blitz-Funktionen leicht vorne auf zwei anderen sind sie etwas langsamer, dabei habdelt es sich aber nur um 0.1% bis 0.4 %

Der MinGW schein mir der einsteigerfreundlichste zu sein, er compiliert fast alles und gibt dazu noch das richtige Ergebnis aus, TurboC++ schluckt auch eine Menge, aber VC++ meckert ziemlich oft und compiliert vieles nicht. Dafür ist die Exe bei MinGW ein vielfaches größer, PellesC generiert die kleinste.

z.B. gibt MinGW hier einen String an Blitz3D zurück

const char * funcname() {

string MyString;
....
...
return MyString.c_str();
}

TurboC++ einen halben Kryptischen und die andere Hälfte richtig.
VC++ gar nichts.
PellesC ist nur C, da geht es nicht.
--------------------------------------------

Bei den reinen C Strings rechnet MinGW am schnellsten und ist in der Funktions-Schleife doppelt so schnell wie Blitz
aber wenn man die Zeit mit 3000 3D-Programmdurchläufen vergleicht, sind alle sogut wie gleich schnell.

TurboC++ gibt in zusammenarbeit mit Blitz3D einen " blizcc.exe Domain-Error asin (acos) " aus wenn man die math.h Funktionen asin() und acos() verwendet, alle anderen funktionieren.

Zum arbeiten gefällt mir der Turbo C++ 2006 ab besten, aber der MinGW schluckt alle C++ Beispiele die man finden kann und scheint mir von der Norm her derjenige zu sein der alles so umsetzt wie es in den Büchern steht.

	David	Mo, Jul 23, 2007 18:37 Antworten mit Zitat
Code: [AUSKLAPPEN] [EINKLAPPEN] const char * funcname() { string MyString; .... ... return MyString.c_str(); } Das ist im Grund genommen auch keine wirklich gute Idee! Zitat: aber der MinGW schluckt alle C++ Beispiele die man finden kann und scheint mir von der Norm her derjenige zu sein der alles so umsetzt wie es in den Büchern steht. G++ ist ziemlich Standardkonform, ja. Aber er weicht z.T. auch vom Standard ab.
http://bl4ckd0g.funpic.de

David

Mo, Jul 23, 2007 18:37
Antworten mit Zitat

Code: [AUSKLAPPEN]

const char * funcname() {

string MyString;
....
...
return MyString.c_str();
}

Das ist im Grund genommen auch keine wirklich gute Idee! Smile

Zitat:

aber der MinGW schluckt alle C++ Beispiele die man finden kann und scheint mir von der Norm her derjenige zu sein der alles so umsetzt wie es in den Büchern steht.

G++ ist ziemlich Standardkonform, ja. Aber er weicht z.T. auch vom Standard ab.

http://bl4ckd0g.funpic.de

	TheShadow Moderator	Mo, Jul 23, 2007 19:37 Antworten mit Zitat
Im übrigen sollte man bei MinGW noch folgendes einschalten: -Wall (zeigt mehr Fehler an) -pedantic (ultrastreng, zeigt alle Fehler nach ISO an - nur so schreibt man korrekte codes) -s (macht exe kleiner) -O3 oder -Os (1. macht schneller, 2. macht kleinere exe) >>>Wenn C Code mit dem selben Compiler wirklich schneller sein sollte werd ich das dann auch mal testen. >>>So ein Unsinn. bei MinGW gibt es einen separaten C (gcc.exe) und C++ (g++.exe) compiler. C++ ist meistens langsamer als C. C++ exe ist meistens größer als C.
AMD64 3500+ \| GeForce6600GT 128MB \| 1GB DDR \| WinXPsp2

TheShadow

Moderator

Mo, Jul 23, 2007 19:37
Antworten mit Zitat

Im übrigen sollte man bei MinGW noch folgendes einschalten:
-Wall (zeigt mehr Fehler an)
-pedantic (ultrastreng, zeigt alle Fehler nach ISO an - nur so schreibt man korrekte codes)
-s (macht exe kleiner)
-O3 oder -Os (1. macht schneller, 2. macht kleinere exe)

>>>Wenn C Code mit dem selben Compiler wirklich schneller sein sollte werd ich das dann auch mal testen.

>>>So ein Unsinn.

bei MinGW gibt es einen separaten C (gcc.exe) und C++ (g++.exe) compiler.
C++ ist meistens langsamer als C.
C++ exe ist meistens größer als C.

AMD64 3500+ | GeForce6600GT 128MB | 1GB DDR | WinXPsp2

	David	Mo, Jul 23, 2007 20:06 Antworten mit Zitat
TheShadow hat Folgendes geschrieben: bei MinGW gibt es einen separaten C (gcc.exe) und C++ (g++.exe) compiler. C++ ist meistens langsamer als C. C++ exe ist meistens größer als C. C++ hat fast den kompletten C Umfang. D.h. C Codes mit g++ compiliert sind genauso schnell wie C Codes mit gcc compiliert. Es muss natürlich auf die Standardlibrary verzichtet werden (z.B). Wobei letztere auch keine Garantie für langsameren Code ist. Zum Teil ist die C++ Standard Library langsamer als alte C Funktionalität, dafür kommt sie mit genug Vorteilen her das die paar Millisekunden verschmerzbar sind (ich sag nur Typsicherheit) TheShadow hat Folgendes geschrieben: -pedantic (ultrastreng, zeigt alle Fehler nach ISO an - nur so schreibt man korrekte codes) Das stimmt mal garnicht. Wenn man sich im C++ Standard auskennt schreibt man auch so standardkonforme Programme (wie du sagst korrekte Codes). Das Problem ist nur das viele den Standard nicht hinreichend gut kennen.
http://bl4ckd0g.funpic.de

David

Mo, Jul 23, 2007 20:06
Antworten mit Zitat

TheShadow hat Folgendes geschrieben:

bei MinGW gibt es einen separaten C (gcc.exe) und C++ (g++.exe) compiler.
C++ ist meistens langsamer als C.
C++ exe ist meistens größer als C.

C++ hat fast den kompletten C Umfang. D.h. C Codes mit g++ compiliert sind genauso schnell wie C Codes mit gcc compiliert. Es muss natürlich auf die Standardlibrary verzichtet werden (z.B).

Wobei letztere auch keine Garantie für langsameren Code ist. Zum Teil ist die C++ Standard Library langsamer als alte C Funktionalität, dafür kommt sie mit genug Vorteilen her das die paar Millisekunden verschmerzbar sind (ich sag nur Typsicherheit)

TheShadow hat Folgendes geschrieben:

-pedantic (ultrastreng, zeigt alle Fehler nach ISO an - nur so schreibt man korrekte codes)

Das stimmt mal garnicht. Wenn man sich im C++ Standard auskennt schreibt man auch so standardkonforme Programme (wie du sagst korrekte Codes). Das Problem ist nur das viele den Standard nicht hinreichend gut kennen.

http://bl4ckd0g.funpic.de

	ByteCroc	Mo, Jul 23, 2007 20:46 Antworten mit Zitat
@TheShadow danke für die Flags, der -s lässt den Code ja um 2/3 schrumfen, ich hab ihn bis jetzt noch nicht in der Liste vom GCC gefunden. Ja, das C oft schneller ist hab ich schon bemerkt, aber wenn dann benutze ich es im C++ code um auf die Vorteile von C++ nicht verzichten zu müssen. Zitat: Zitat: Code: const char * funcname() { string MyString; .... ... return MyString.c_str(); } Das ist im Grund genommen auch keine wirklich gute Idee! Smile Was ist falsch daran ? Aus einem string ein char-Array machen und dann raus damit.

ByteCroc

Mo, Jul 23, 2007 20:46
Antworten mit Zitat

@TheShadow
danke für die Flags, der -s lässt den Code ja um 2/3 schrumfen, ich hab ihn bis jetzt noch nicht in der Liste vom GCC gefunden.

Ja, das C oft schneller ist hab ich schon bemerkt, aber wenn dann benutze ich es im C++ code um auf die Vorteile von C++ nicht verzichten zu müssen.

Zitat:

Zitat:

Code:

const char * funcname() {

string MyString;
....
...
return MyString.c_str();
}

Das ist im Grund genommen auch keine wirklich gute Idee! Smile

Was ist falsch daran ? Aus einem string ein char-Array machen und dann raus damit. Rolling Eyes

	David	Mo, Jul 23, 2007 20:52 Antworten mit Zitat
Was falsch daran ist? Ohje... Du erzeugst ein std::string Objekt mit der Speicherklasse auto. Und was passiert mit einem auto Objekt wenn der Scope verlassen wird? Es wird zerstört, genau. Nun wird der Compiler nicht die geringste Möglichkeit finden einen dynamischen String irgendwie in den statischen Speicher zu bekommen, d.h. c_str() liefert dir wiederum einen dynamischen String (im Normalfall sogar einfach der, der vom std::string Objekt verwaltet wird). Und genau diese Daten werden beim Zerstören des std::string Objekts mit ins Nirvana gerissen! Was du also zurückgibst? Einen danglingpointer, der beste Freund den du haben kannst wenn du auf undefiniertes Verhalten stehst.
http://bl4ckd0g.funpic.de

David

Mo, Jul 23, 2007 20:52
Antworten mit Zitat

Was falsch daran ist? Ohje...

Du erzeugst ein std::string Objekt mit der Speicherklasse auto. Und was passiert mit einem auto Objekt wenn der Scope verlassen wird? Es wird zerstört, genau. Nun wird der Compiler nicht die geringste Möglichkeit finden einen dynamischen String irgendwie in den statischen Speicher zu bekommen, d.h. c_str() liefert dir wiederum einen dynamischen String (im Normalfall sogar einfach der, der vom std::string Objekt verwaltet wird). Und genau diese Daten werden beim Zerstören des std::string Objekts mit ins Nirvana gerissen! Was du also zurückgibst? Einen danglingpointer, der beste Freund den du haben kannst wenn du auf undefiniertes Verhalten stehst. Rolling Eyes

http://bl4ckd0g.funpic.de

	BtbN	Mo, Jul 23, 2007 21:19 Antworten mit Zitat
Der 4.1.2er des MinGW ist eh langsam wie sonst was, nimm den offiziellen 3.4er.

BtbN

Mo, Jul 23, 2007 21:19
Antworten mit Zitat

Der 4.1.2er des MinGW ist eh langsam wie sonst was, nimm den offiziellen 3.4er.

	ByteCroc	Di, Jul 24, 2007 11:20 Antworten mit Zitat
Wie einfach ist doch Basic Danke für eure Tipps, das C++ lernen wird mich die mächsten Jahre begleiten, bis man alles mitbekommen hat.

ByteCroc

Di, Jul 24, 2007 11:20
Antworten mit Zitat

Wie einfach ist doch Basic Smile

Danke für eure Tipps, das C++ lernen wird mich die mächsten Jahre begleiten, bis man alles mitbekommen hat.

	Randall Flagg	Di, Jul 24, 2007 12:24 Antworten mit Zitat
hab heute auch eine unerfreuliche Entdeckung machen müssen... Ich fange an Spiele mit C++ und Allegro zu lernen, und Allegro hatte ich schonmal im Zusammenhang mit MinGW benutzt, allerdings konnte ich es nicht mehr installieren, bei der ausführung von make kam immer ein Fehler... alles ausprobiert, nix ging. Dann habe ich mir so gedacht: "Hey, du hast doch VC8, damit könnte es klappen!" Tja, damit ging es dann auch schließlich... aber die Geschwindigkeitsunterschiede sind enorm... z.B. Code: [AUSKLAPPEN] [EINKLAPPEN] #include <allegro.h> int main() { allegro_init(); install_keyboard(); set_color_depth(16); if (set_gfx_mode(GFX_AUTODETECT_WINDOWED,800,600,0,0) < 0) { allegro_message("Unable to set graphic mode"); exit(0); } for (int r= 0;r<255;r++) { for (int g= 0; g<255;g++) { for (int b=0; b< 255;b++) { putpixel(screen,r,g,makecol(r,g,b)); } } } while(!keypressed()); }END_OF_MAIN() kompiliert man diesen Code in MinGW wird sofort ein rechteck aus den den drei rgb werten erstellt... bei VC8 braucht der Compiler für Jede Senkrechte Linie eine (!!!) Sekunde! Da sitzt man für 255 Linien also 4 Minuten bis es fertig ist... ich prüf mal die Einstellungen, ob da irgendwas nicht in Ordnung ist, denn ich will gar nicht daran denken wie es erstmal sein wird, wenn ich Spiele damit mache oO
Meine Parodien & Geschichten

Randall Flagg

Di, Jul 24, 2007 12:24
Antworten mit Zitat

hab heute auch eine unerfreuliche Entdeckung machen müssen...
Ich fange an Spiele mit C++ und Allegro zu lernen, und Allegro hatte ich schonmal im Zusammenhang mit MinGW benutzt, allerdings konnte ich es nicht mehr installieren, bei der ausführung von make kam immer ein Fehler... alles ausprobiert, nix ging. Dann habe ich mir so gedacht: "Hey, du hast doch VC8, damit könnte es klappen!" Tja, damit ging es dann auch schließlich... aber die Geschwindigkeitsunterschiede sind enorm...
z.B.

Code: [AUSKLAPPEN]

#include <allegro.h>

int main() {
allegro_init();
install_keyboard();

set_color_depth(16);
if (set_gfx_mode(GFX_AUTODETECT_WINDOWED,800,600,0,0) < 0) {
   allegro_message("Unable to set graphic mode");
   exit(0);
}

for (int r= 0;r<255;r++) {
   for (int g= 0; g<255;g++) {
      for (int b=0; b< 255;b++) {
         putpixel(screen,r,g,makecol(r,g,b));
      }
   }
}
while(!keypressed());
}END_OF_MAIN()

kompiliert man diesen Code in MinGW wird sofort ein rechteck aus den den drei rgb werten erstellt... bei VC8 braucht der Compiler für Jede Senkrechte Linie eine (!!!) Sekunde! Da sitzt man für 255 Linien also 4 Minuten bis es fertig ist... ich prüf mal die Einstellungen, ob da irgendwas nicht in Ordnung ist, denn ich will gar nicht daran denken wie es erstmal sein wird, wenn ich Spiele damit mache oO

Meine Parodien & Geschichten

	ByteCroc	Di, Jul 24, 2007 12:41 Antworten mit Zitat
Ich hatte da auch ein seltsames Erlebnis mit VC++ und OpenWatcom, den OpenWatcom hatte ich einen Tag vor VC++ installiert aber nie angerührt. Einen Tag später dann VC++ installiert und meine Tests ganz oben gemacht, dann wollte ich DirtyBasic kompillieren, das ging aber nicht, denn ich habe dort 2 WinAPI zugriffe, also musste ich die PSDK einbinden und hab das auch gemacht wie bei MS beschrieben, als ich dann abermal kompillieren wollte tauchte unten im Fenster eine Fehlermelung auf, den genauen Wortlaut kenne ich nicht mehr, aber in etwa der Sinn. Pfad Open Watcom/cl.exe Open Watcom can not compile xxx da hab ich alle Pfade bei VC++ durch gesehen, aber nirgends wo war ein Pfad Richtung OpenWatcom gesetzt, ich hab jede einzelne Datei im VC Verzeichnis geöffnet welche man lesen konnte, aber es war nichts zu finden. Ich hab Open Watcom runter geschmissen, VC++ deinstalliert und neu installiert. Ich kann allerdings nicht ausschliesen das VC++ sich aus irgend einem anderen Ordner make, Compiler oder Linker schnappt und damit compiliert, das merkt man wohl erst wieder dann wenn sich das entsprechende File zu Wort meldet. Vielleicht hast du ein ähnliches Problem und VC macht deshalb so seltsame Probleme

ByteCroc

Di, Jul 24, 2007 12:41
Antworten mit Zitat

Ich hatte da auch ein seltsames Erlebnis mit VC++ und OpenWatcom,
den OpenWatcom hatte ich einen Tag vor VC++ installiert aber nie angerührt.
Einen Tag später dann VC++ installiert und meine Tests ganz oben gemacht, dann wollte ich DirtyBasic kompillieren, das ging aber nicht, denn ich habe dort 2 WinAPI zugriffe, also musste ich die PSDK einbinden und hab das auch gemacht wie bei MS beschrieben, als ich dann abermal kompillieren wollte tauchte unten im
Fenster eine Fehlermelung auf, den genauen Wortlaut kenne ich nicht mehr, aber in etwa der Sinn.
Pfad Open Watcom/cl.exe Open Watcom can not compile xxx
da hab ich alle Pfade bei VC++ durch gesehen, aber nirgends wo war ein Pfad Richtung OpenWatcom gesetzt, ich hab jede einzelne Datei im VC Verzeichnis geöffnet welche man lesen konnte, aber es war nichts zu finden.
Ich hab Open Watcom runter geschmissen, VC++ deinstalliert und neu installiert.
Ich kann allerdings nicht ausschliesen das VC++ sich aus irgend einem anderen Ordner make, Compiler oder Linker schnappt und damit compiliert, das merkt man wohl erst wieder dann wenn sich das entsprechende File zu Wort meldet.

Vielleicht hast du ein ähnliches Problem und VC macht deshalb so seltsame Probleme

	Randall Flagg	Di, Jul 24, 2007 12:53 Antworten mit Zitat
hm, ich weiß es nicht... hab grade eine Übung aus nem Buch übernommen, in dem ein Bild sich bewegt und immer am Bildschirmrand abprallt... bei MinGW hats damals geklappt, bei VC8 hab ich zwar das Bild, aber es bewegt sich kein Stück... wenn das so weiter geht darf ich mich wieder 2 Wochen hinsetzen und den Fehler bei MinGW suchen, damit ich dann damit programmieren kann Neuinstallation von VC8: Hab ich gestern schon gemacht... brachte nix.
Meine Parodien & Geschichten

Randall Flagg

Di, Jul 24, 2007 12:53
Antworten mit Zitat

hm, ich weiß es nicht... hab grade eine Übung aus nem Buch übernommen, in dem ein Bild sich bewegt und immer am Bildschirmrand abprallt... bei MinGW hats damals geklappt, bei VC8 hab ich zwar das Bild, aber es bewegt sich kein Stück... wenn das so weiter geht darf ich mich wieder 2 Wochen hinsetzen und den Fehler bei MinGW suchen, damit ich dann damit programmieren kann Crying or Very sad

Neuinstallation von VC8: Hab ich gestern schon gemacht... brachte nix.

Meine Parodien & Geschichten

	ByteCroc	Di, Jul 24, 2007 12:59 Antworten mit Zitat
Probier doch mal den TurboC++ 2006 aus, der ist auch kostenlos und frei wenn du dein Prg. kommerziell verkaufen willst. http://www.turboexplorer.com/cpp hast du VC vorher deinstalliert, das drüberinstallieren brachte bei mir auch nichts, und alle Dateien der vorherigen installation in Eigene Dateien und C:\Dokumente und Einstellungen... löschen.

ByteCroc

Di, Jul 24, 2007 12:59
Antworten mit Zitat

Probier doch mal den TurboC++ 2006 aus, der ist auch kostenlos und frei wenn du dein Prg. kommerziell verkaufen willst.
http://www.turboexplorer.com/cpp

hast du VC vorher deinstalliert, das drüberinstallieren brachte bei mir auch nichts, und alle Dateien der vorherigen installation in Eigene Dateien und C:\Dokumente und Einstellungen... löschen.

Gehe zu Seite 1, 2 Weiter

Übersicht

Sonstiges

Smalltalk

Nach Oben

BlitzBasic Portal

Extreme Geschwindigkeitsunterschiede

Betreff: Extreme Geschwindigkeitsunterschiede

Betreff: Re: Extreme Geschwindigkeitsunterschiede