Integer ist deutlich der schnellste Datentyp
-
Mit diesem kleinen Programm kann man es selbst testen:
static void Main(string[] args)
{
double test;
const long max = 100 * 1000 * 1000;
Stopwatch stopwatch = new Stopwatch();
stopwatch.Start();
for (int i = 1; i < max; i++) ;
// test = Math.Sin(i*Math.PI/180);
stopwatch.Stop();
double Seconds = stopwatch.ElapsedTicks / (float)Stopwatch.Frequency;
string strzahl = String.Format("{0:0.0000}", Seconds * 1000.0);
string ausgabe="Benötigte Zeit in ms: " + strzahl;Console.WriteLine(ausgabe);
Console.ReadKey();
}Für 100*1000*1000 = 100 Mio Rechenvorgänge ergibt sich folgendes:
1: Setzt man for (int i = 1; ... -> 270 ms
2: Setzt man for (long i = 1; ...-> knapp 400 ms (!!!)
Setzt man statt const long max --> const int max,
wird die Zählschleife wieder langsamer: (!!!)
3: for (int i=1; ... -> 301 ms
Nimmt man keinen vorberechneten Wert, sondern verlegt die Berechnung in die Schleife:
4: for (int i=1;i<100*1000*1000;i++); -> ca. 300 ms
Aus 4: schließe ich, daß der Compiler die Abbruchbedingung nicht etwa jedesmal neu berechnet (wie man befürchten könnte !), sondern einmalig zuvor berechnet und als Zahlenwert ablegt. Und wie? Nun, als int.
Beweis:
5: for (int i=1;i<(int)100*1000*1000;i++); -> ca. 300 ms
6: for (int i=1;i<(long)100*1000*1000;i++) ;-> ca. 270 ms (!!!)Für rechenintensive Progamme nicht ohne Bedeutung!
Long gegenüber int um ca. 30 Prozent langsamer. 30 Prozent sind kein Pappenstiel!
Nochmal 10 Prozent schneller geht es mit Zählschleife in int, Abbruchbedingung in long (verstehe das, wer will, im Moment fällt mir zu dem nichts ein, ist aber zweifellos so).
Interessant, nicht wahr?
pascal
-
CodeTags!
Ansonsten weiß ich nicht was Du mit Deinem Vergleich willst. Wie oft wurde die SW gestartet ? Im VHost oder alleinstehend etc.
-
Knuddlbaer schrieb:
CodeTags!
Ansonsten weiß ich nicht was Du mit Deinem Vergleich willst. Wie oft wurde die SW gestartet ? Im VHost oder alleinstehend etc.
Wie oft der gestartet wurde? Einige Dutzend mal, alleinstehender Rechner.
Ich wollte damit feststellen, ob bei Zählschleifen der Datentyp eine Rolle spielt.
Offenbar ist das der fall.
Die Zeitmessungen über den Prozessor-Takt sind ja relativ, so wie bei mir auf dem PC gelaufen, aber die Relation zwischen long und int sollte konstant sein.
Also ist es bei zeitkritischen Anwendungen das beste, immer mit int zu arbeiten, da diese offenbar von allen Wertetypen am schnellsten verarbeitet werden.
Interessant wäre es übrigens, nach dieser Stopp-Uhr Methode sämtliche String-Operationen mal zu testen, Arrays und so weiter.
Damit man beim Programmieren nicht durch falsche Wahl der Datentypen bis zu 40 Prozent Laufzeit verschenkt.
Oder unnötigen Code produziert z. B. diesen:
1: int max_zaehler=100*1000*1000;
2: for (int i=0;i<max_zaehler; ...ist völlig gleichbedeutend, von der performance, mit:
1: for (int i=0;i<100*1000*1000; ...
Hat aber eine Code-Zeile weniger. Das hätte ich im übrigen nicht gedacht, daß der Compiler so schlau ist.
Pascal
-
pascal2009 schrieb:
Hat aber eine Code-Zeile weniger. Das hätte ich im übrigen nicht gedacht, daß der Compiler so schlau ist.
Das ist doch Heutzutage das mindeste was man vom Compiler erwarten darf...
-
David_pb schrieb:
pascal2009 schrieb:
Hat aber eine Code-Zeile weniger. Das hätte ich im übrigen nicht gedacht, daß der Compiler so schlau ist.
Das ist doch Heutzutage das mindeste was man vom Compiler erwarten darf...
Ich hätte gedacht, wenn man den Wert vorher errechnet, ablegt und als Variable einsetzt, daß das schneller ist.
Bleibt aber noch das Phänomen, daß long langsamer verarbeitet wird, als Abbruchbedingung aber seltsamerweise 10 Prozent schneller, nämlich:
for (int i=0;i<(long)100*1000*1000 ist 10 Prozent schneller als
for (int i=0;i<(int)100*1000*1000
Der Compiler ist zwar schlau, aber auch rätselhaft
pascal
-
pascal2009 schrieb:
Mit diesem kleinen Programm kann man es selbst testen:
static void Main(string[] args)
{
double test;
const long max = 100 * 1000 * 1000;
Stopwatch stopwatch = new Stopwatch();
stopwatch.Start();
for (int i = 1; i < max; i++) ;
// test = Math.Sin(i*Math.PI/180);
stopwatch.Stop();
double Seconds = stopwatch.ElapsedTicks / (float)Stopwatch.Frequency;
string strzahl = String.Format("{0:0.0000}", Seconds * 1000.0);
string ausgabe="Benötigte Zeit in ms: " + strzahl;Console.WriteLine(ausgabe);
Console.ReadKey();
}Für 100*1000*1000 = 100 Mio Rechenvorgänge ergibt sich folgendes:
1: Setzt man for (int i = 1; ... -> 270 ms
2: Setzt man for (long i = 1; ...-> knapp 400 ms (!!!)
Super, auf meinem 64 Bit Rechner sieht das aber anders aus:
int: >170 ms
long: ~139 ms
(
)
Der Thread ist fürn Arrsch.
-
tollewurst schrieb:
(
) Der Thread ist fürn Arrsch.Deine Antwort ist fürn´Arrsch (sind hier eigentlich nur Proleten unterwegs, die bei der kleinsten Kleinigkeit offenbaren, aus welchem Milieu die kommen ????
???
Also Willkommen auf meiner IGNORE Liste.
Klar ist, daß die Performance vom Betriebssystem und vom Rechner abhängig und dementsprechend unterschiedlich ausfällt.
Das muß hier nicht gesagt werden, ich erwarte, daß die Leute, die hier lesen, LOGISCH DENKEN können.
Da meine Programme aber auf meinem Rechner laufen, ist es für´n Arrsch zu sagen, hätte ich einen anderen Rechner, würde das anders aussehen. Ich habe einen ganz stinknormalen Win32 Rechner, was für ungefähr 90 Prozent aller anderen PC-User mit WinXP WELTWEIT auch zutreffen dürfte.
Mein Gott, was ist das für ein Proletenauflauf hier!
Tss Tss ...
-
Um mal wieder zur Sache zurückzukommen:
Dieses kleine Programm-Fragment (hab ich mir übrigens von hier aus dem Forum kopiert und ausprobiert) ermöglicht es, daß jeder für SEINEN RECHNER austesten kann, wie er die beste Performance hinbekommt.
30 - 40 Prozent Performance sind kein Pappenstiel.
Im übrigen bietet es sich an, auf diese Weise (das wurde oben schon gesagt) auch mal andere Datentypen zu testen.
Und insbesondere auch Typ-Umwandlungen, und String-Operatoren. Da wird man schnell sehen, was "geht" oder was man besser vermeiden sollte.
Pascal
-
pascal2009 schrieb:
Ich hätte gedacht, wenn man den Wert vorher errechnet, ablegt und als Variable einsetzt, daß das schneller ist.
Der Compiler rechnet konstante Ausdrücke in der Regel zur Übersetzungszeit aus.
Bleibt aber noch das Phänomen, daß long langsamer verarbeitet wird, als Abbruchbedingung aber seltsamerweise 10 Prozent schneller, nämlich:
for (int i=0;i<(long)100*1000*1000 ist 10 Prozent schneller als
for (int i=0;i<(int)100*1000*1000
Der Compiler ist zwar schlau, aber auch rätselhaft
Ich würde hier erwarten, dass er im oberen Codeteil eine long-Konstante (was ist das in .net, System.Int64?) und im unteren Codeteil eine int-Konstante (System.Int32?) mit je dem Wert 100000000 anlegt. Dann vergleicht er mit einer int-Variablen, d.h. er müsste im oberen Code diese erst nach long umwandeln und dann vergleichen. Genauso könnte ich mir vorstellen, dass er diese ganze Wandelei als sinnlos erkennt und nicht durchführt, also die Konstante auch gleich als int ablegt, aber dass es mit long sogar schneller ist, ist in der Tat rätselhaft.
Was mich ein bisschen beunruhigt: Deine Schleifen tun ja nichts beobachtbares, außer i auf den Schleifenendwert zu setzen. Ein Compiler sollte sowas auch erkennen und die Schleife komplett wegwerfen. Übersetzt du vielleicht ohne Optimierung?
BTW, darauf, was irgendwelche Unregistrierten hier von sich geben, würde ich nicht allzuviel Wert legen.
-
pascal2009 schrieb:
Da meine Programme aber auf meinem Rechner laufen, ist es für´n Arrsch zu sagen, hätte ich einen anderen Rechner, würde das anders aussehen. Ich habe einen ganz stinknormalen Win32 Rechner, was für ungefähr 90 Prozent aller anderen PC-User mit WinXP WELTWEIT auch zutreffen dürfte.
Mein Gott, was ist das für ein Proletenauflauf hier!
Tss Tss ...
was wirklich für´n [sic] arrsch [sic] ist, ist deine naiven mutmaßungen zu tatsachen zu erklären und andere dann dumm anzumachen, wenn sie dich auf diesen fehler hinweisen.
deine schlussfolgerung gilt nur für deinen rechner und nur für deinen code.
darüberhinaus ist sowieso eine binsenweisheit, dass int auf einem 32-bit rechner tendenziell am schnellsten ist. dass du mal nachmisst ist löblich, das ergebnis überrascht aber außer dir wahrscheinlich niemanden.
-
Bashar schrieb:
BTW, darauf, was irgendwelche Unregistrierten hier von sich geben, würde ich nicht allzuviel Wert legen.
...weil?
-
immer locker schrieb:
was wirklich für´n [sic] arrsch [sic] ist, ist deine naiven mutmaßungen zu tatsachen zu erklären und andere dann dumm anzumachen, wenn sie dich auf diesen fehler hinweisen.
Du weißt vielleicht was Semantik ist?
Ich habe mich nicht darüber beschwert, daß jemand darauf hingewiesen hat, daß meine Beobachtung nicht allgemeingültig ist. Das war aber auch niemals behauptet worden, sondern ist eine böswillige UNTERSTELLUNG, denn implizit geht ja zwanglos aus meinem Beitrag hervor, daß ich etwas auf MEINEM RECHNER gemessen habe, auf welchem denn sonst!
Sondern ich habe mich über die FÄKALSPRACHE hier im Forum beschwert.
Ich kenn das normal nur so, daß man freundlich miteinander umgeht und sich nicht in Fäkalien äußert.
Wenn diese dann noch als [sic] gekennzeichnet werden, dann bist du wohl auch von der Truppe, die anstatt einer freundlichen Diskussion nur darauf lauert, eine Fäkalie loszulassen.
Mit SOWAS diskutiere ich nicht, das macht keinen Sinn.
Willkommen also als #3 auf meiner IGNORE Liste.
Gibt es hier im Forum eine Standard-Funktion für IGNORE, daß man SOWAS gleich ausblenden kann?
-
ich habe keine ahnung, warum du mich jetzt auch noch angreifst und beleidigst. wenn du nicht ordentlich argumentieren kannst bzw. sachlich bleiben kannst, schreib lieber gar nichts.
-
sondern ist eine böswillige UNTERSTELLUNG, denn implizit geht ja zwanglos aus meinem Beitrag hervor, daß ich etwas auf MEINEM RECHNER gemessen habe, auf welchem denn sonst!
Das hier ist ein Diskussionsforum kein Tagebuch. Was Du für Dich für Deine speziellen Fälle herausfindest interessiert niemanden. Mit dieser Annahme und Deinem Text ist es eine Verallgermeinerung.
http://www.c-plusplus.net/forum/viewtopic-var-p-is-1657617.html#1657617
-
Knuddlbaer schrieb:
http://www.c-plusplus.net/forum/viewtopic-var-p-is-1657617.html#1657617
oooh achso, ein berufstroll. sogar ein registrierter.
-
Knuddlbaer schrieb:
sondern ist eine böswillige UNTERSTELLUNG, denn implizit geht ja zwanglos aus meinem Beitrag hervor, daß ich etwas auf MEINEM RECHNER gemessen habe, auf welchem denn sonst!
Das hier ist ein Diskussionsforum kein Tagebuch. Was Du für Dich für Deine speziellen Fälle herausfindest interessiert niemanden. Mit dieser Annahme und Deinem Text ist es eine Verallgermeinerung.
http://www.c-plusplus.net/forum/viewtopic-var-p-is-1657617.html#1657617
Es steht drin: auf meinem Rechner habe ich 275 ms erzielt.
Und nicht: auf allen rechnern der Welt läuft es so.
Ich denke die Leute, die das Lesen, brauchen keinen Gehirnkrückeninterpreter, sondern können selbst lesen, was exakt da steht.
Es steht da:
Jeder kann testen, wielange sein PC braucht, mit dem abgebildeten Programmsnippet.
Und auf meinem PC hat das soundsolange gebraucht.
Das ist keine allgemeingültige Aussage, sondern eine konkrete Messung.
Konkrete Messungen sind NICHT ungefähr das Gegenteil von Verallgemeinerungen.
Sondern das EXAKTE Gegenteil davon.
-
Bashar schrieb:
...
Was mich ein bisschen beunruhigt: Deine Schleifen tun ja nichts beobachtbares, außer i auf den Schleifenendwert zu setzen. Ein Compiler sollte sowas auch erkennen und die Schleife komplett wegwerfen. Übersetzt du vielleicht ohne Optimierung?Muss er wohl, sonst würde genau das eintreten was du vermutest. Der Compiler würde so eine Schleife die nichts tut, wegoptimieren.
Aber abgesehen von dieser Nachlässigkeit ist das Ergebniss von so einem Vergleich von int und long auf nem 32 Bit System, wie es der Threadersteller ja nach eigenen Aussagen hat, von Anfang an klar. long wird langsamer sein als int. Der Grund liegt einfach daran das der Prozessor nunmal nur 32 Bit gleichzeitig kopieren kann und die CPU für Operationen mit long mit seinen 64 Bit mindestens doppelt soviel Taktzyklen benötigt um die gleichen Instruktionen auszuführen. Klar dass da Operationen mit long länger dauern.
Aber der Testcode ist echt Schwachsinn. Leider sieht man solche "Performancetest" in der Art dass leere Schleifen benutzt werden immer wieder. Was solln die für ne Aussagekraft haben? Gar keine! Am Typ der Laufvariablen einer Schleife zu optimieren ist vollkommen sinnlos. Was wichtig ist, ist was in der Schleife steht. Mach zwei Schleifen, eine mit von mit aus 4 Additionsoperationen mit long und die andere mit ner Multiplikation und ner Division mit nem Integer. Na, welche ist schneller? Die mit den ints ist nicht! Hmm, dabei dachten wir doch grad noch das int schneller ist. Komisch komisch..., wie kommt das nur? Ahh, Operationen brauchen unterschiedliche viele Taktzyklen um von der CPU ausgeführt zu werden... Guck einer an. Int ist also doch nicht schneller als long, oder doch?
-
[quote="Talla"]
Bashar schrieb:
1.) Aber der Testcode ist echt Schwachsinn. Leider sieht man solche "Performancetest" in der Art dass leere Schleifen benutzt werden immer wieder. Was solln die für ne Aussagekraft haben? Gar keine! Am Typ der Laufvariablen einer Schleife zu optimieren ist vollkommen sinnlos.
2.) Was wichtig ist, ist was in der Schleife steht.
Schwachsinn ist das, was du Schreibst. Offenbar ist hier Pöbeln an der Tagesordnung.Dann sollen sich die Schwachmaten auch nicht beschweren, wenn sie auch mal einen abkriegen.
Siehst du nicht, daß da was auskommentiert wurde, Sinus_Berechnung? Der stand innerahlb der Schleife, wurde auskommentiert.
Einige Leute hier können offenbar nicht logisch denken oder wollen nur rummosern.
Natürlich addiert sich die Zeit von der leeren Schleife zum Code innerhalb der Schleife auf. Wenn man das messen will, was sich aufaddiert, muß man auskommentieren.
Wer herumpöbelt, sollte wenigstens ein bißchen (nur ein bißchen) Grips in der Birne haben. Damit er sich nicht völlig lächerlich macht.
-
pascal2009 schrieb:
Natürlich addiert sich die Zeit von der leeren Schleife zum Code innerhalb der Schleife auf. Wenn man das messen will, was sich aufaddiert, muß man auskommentieren.
Das stimmt (höchstens) für deaktivierte Compileroptimierung.
Wer herumpöbelt, sollte wenigstens ein bißchen (nur ein bißchen) Grips in der Birne haben.
Du lehnst dich gerade ziemlich weit aus dem Fenster ...
-
[quote="Bashar"]
pascal2009 schrieb:
Wer herumpöbelt, sollte wenigstens ein bißchen (nur ein bißchen) Grips in der Birne haben.
Du lehnst dich gerade ziemlich weit aus dem Fenster ...
Mir gefällt der ruppige Ton hier nicht.
Ganz ohne Fenster.
Können sich die Leute nicht normal unterhalten ohne Fäkalsprache und Beleidigungen? Wenn nicht dann gehört auf einen groben Klotz ein grober Keil.