Durchlaufzeit einer Schleife


  • Mod

    Du machst beim compilieren irgendwas massiv falsch. vector muss bei einem Releasebuild genau so schnell sein wie ein new-Array.

    Ist er bei mir auch:

    Vector safe: 56ms.
    Vector:      40ms.
    Array:      79ms.
    
    Vector safe: 55ms.
    Vector:      39ms.
    Array:      39ms.
    
    Vector safe: 54ms.
    Vector:      39ms.
    Array:      39ms.
    
    Vector safe: 55ms.
    Vector:      39ms.
    Array:      39ms.
    
    Vector safe: 55ms.
    Vector:      39ms.
    Array:      39ms.
    

    Der massive Zeitunterschied zwischen at und operator[] bei dir deutet ebenfalls auf Unsinn beim compilieren hin. So teuer ist ein Rangecheck nun auch nicht, wie du an meinen Zahlen siehst.



  • Das hätte ich auch erwartet.
    Aber ideone sagt:

    Vector safe: 88ms.
    Vector:      86ms.
    Array:       85ms.
    
    Vector safe: 88ms.
    Vector:      86ms.
    Array:       38ms.
    
    Vector safe: 88ms.
    Vector:      86ms.
    Array:       39ms.
    
    Vector safe: 88ms.
    Vector:      86ms.
    Array:       38ms.
    
    Vector safe: 88ms.
    Vector:      86ms.
    Array:       38ms.
    

    Was mache ich jetzt falsch?


  • Mod

    Caligulaminus schrieb:

    Was mache ich jetzt falsch?

    Du nimmst an, dass ideone optimieren würde. Probier mal bei dir zuhause.



  • Das nahm ich tatsächlich an.
    Bei mir (MinGW 4.6.1) sind Vector und Array wieder gleichschnell - Danke.

    Gibt es einen Grund, warum ideone nicht optimiert?


  • Mod

    Caligulaminus schrieb:

    Gibt es einen Grund, warum ideone nicht optimiert?

    Es ist eine Codeplattform, kein Rechenzentrum.



  • Bei mir ist es MinWG 4.6.2.
    Vorher die Werte waren ohne jede Optimierung.

    Sobald ich den Compiler jedoch optimieren lasse ("-O1") komme ich auch auf vernünftige Ergebnisse.
    Dankeschön an dieser Stelle nochmal.

    TEST.txt :

    Vector safe: 30ms.
    Vector:      27ms.
    Array:      40ms.
    
    Vector safe: 32ms.
    Vector:      25ms.
    Array:      26ms.
    
    Vector safe: 29ms.
    Vector:      25ms.
    Array:      25ms.
    
    Vector safe: 30ms.
    Vector:      27ms.
    Array:      25ms.
    
    Vector safe: 31ms.
    Vector:      33ms.
    Array:      25ms.
    
    Vector safe: 30ms.
    Vector:      24ms.
    Array:      29ms.
    
    Vector safe: 30ms.
    Vector:      26ms.
    Array:      26ms.
    

  • Mod

    Bei GCC basierten Compilern kannst du auch gefahrlos auf O2 gehen. Selbst O3 macht in 99.9999% aller Fälle keine Probleme, bringt aber sehr viel. Erst Ofast wird manchmal kritisch was die Programmkorrektheit angeht. Gut kommt auch die Optimierung zur Linkzeit: flto (ist aber ein bisschen frickelig zu benutzen). Und falls es nur für einen Rechner ist, Feintuning mit march .

    Du hattest noch ein paar Fragen weiter oben:

    frmimue schrieb:

    SeppJ schrieb:

    • Warum return 0 aus main?
    • Warum nicht?

    Du zeigst damit, dass du nicht alle Feinheiten der Sprache beherrscht. Was anscheinend auch der Fall ist. Aber nun hast du eine weitere Feinheit gelernt: In main (und nur in main!) ist return 0; implizit, sofern die Funktion nicht explizit anders verlassen wird.



  • SeppJ schrieb:

    frmimue schrieb:

    SeppJ schrieb:

    Warum return 0 aus main?

    Warum nicht?

    Du zeigst damit, dass du nicht alle Feinheiten der Sprache beherrscht. Was anscheinend auch der Fall ist. Aber nun hast du eine weitere Feinheit gelernt: In main (und nur in main!) ist return 0; implizit, sofern die Funktion nicht explizit anders verlassen wird.

    Ich sehe das genau andersherum als du. Wie viele Leute hab ich bei mir an der Uni schon gesehen, die einfach bei jeder Funktion einen int als Rückgabetyp definieren, und nie etwas zurückgeben. Ich finde, jede Funktion, die nicht void als Rückgabetyp hat, hat eine return-Anweisung zu haben.



  • SeppJ schrieb:

    frmimue schrieb:

    SeppJ schrieb:

    • Warum return 0 aus main?
    • Warum nicht?

    Du zeigst damit, dass du nicht alle Feinheiten der Sprache beherrscht. Was anscheinend auch der Fall ist. Aber nun hast du eine weitere Feinheit gelernt: In main (und nur in main!) ist return 0; implizit, sofern die Funktion nicht explizit anders verlassen wird.

    Because we can? Wirklich? Das findest du ein gutes Argument?

    Also ob main() mit oder ohne return 0 ist mMn. sowas von vollkommen egal. Ich würde es grundsätzlich eher hinschreiben, weil es mMn. kaum einen guten Grund gibt überhaupt zu wissen dass return 0 implizit ist.



  • Ich hätte da noch ein kleines Proble:
    Ist es normal, dass sich die Auflösung der chrono::high_resolution_clock verändert?
    Gestern hatte ich noch eine Auflösung von 1ms, aber seid heute hatte ich nur noch 15ms Auflösung, gerade eben ist es plötzlich wieder auf 1ms gesprungen.

    #include <chrono>
    #include <iostream>
    using namespace std;
    
    int main()
    {
    	auto t1 = chrono::high_resolution_clock::now();
    	auto t2 = chrono::high_resolution_clock::now();
    
    	while(t1==t2) t2 = chrono::high_resolution_clock::now();
    
    	cout << chrono::duration_cast<chrono::nanoseconds>(t2-t1).count() << " ns.\n";
    	cout << chrono::duration_cast<chrono::microseconds>(t2-t1).count() << " us.\n";
    	cout << chrono::duration_cast<chrono::milliseconds>(t2-t1).count() << " ms.\n";
    	cout << endl;
    }
    

Anmelden zum Antworten