C++ Modulo Zeit

[T_55]

Hallo,

ich hab zur Ermittlung der Stunde des Tages aus dem Unixstempel die Performance zwischen struct tm und modulo vergleichen. Von 0 bis heute iteriert (mit volatile). Modulo ist nach meiner Messung 77x schneller als struct tm. Für mich ist damit klar das ich modulo nutzen will.
Um zu prüfen ob Modulo und struct tm übereinstimmen hab ich was geschrieben und natürlich stimmt es nicht überein wegen der Sommerzeit die struct tm scheinbar einbezieht. Jetzt ist der Zeitstempel UTC und +1 wäre MEZ und für Sommer also MESZ bräuchte man +2.

Wie findet man per modulo raus ob Sommerzeit ist oder nicht?
Ziel wäre eine Lösung sodass nach der Schleife die variable "keineuebereinstimmung" auf 0 steht also struct tm und die modulo variante immer das gleiche rausgeben. Hat jemand eine Idee? dann könnte ich struct tm endlich ad acta legen

Gruß

#include <iostream>
#include <time.h>

int main()
{

    time_t endzeit = 1494172759;
    struct tm *tmnow;
    time_t z = 0;

    time_t stunde_modulo;
    time_t stunde_tm;

    time_t uebereinstimmung = 0;
    time_t keineuebereinstimmung = 0;


    while(endzeit>z)
    {

        stunde_modulo = ((z % 86400)/3600)+1;

        tmnow = localtime(&z);
        stunde_tm = tmnow->tm_hour;

        if(stunde_modulo == stunde_tm)
        {
            uebereinstimmung++;
        }
        else
        {
            keineuebereinstimmung++;
        }

        // std::cout << stunde_tm << "  " << stunde_modulo << std::endl;
        z++;
    }

    std::cout <<  "uebereinstimmung  " << uebereinstimmung << std::endl;
    std::cout <<  "keineuebereinstimmung  " << keineuebereinstimmung << std::endl;

    return 0;
}

 

[NemesisFS]

Keine wirklich Antwort, aber:
Bist du dir sicher, dass die Performance an der Stelle so relevant ist? Wie du ja schon gemerkt hast machen dir Sachen wie Sommerzeit, aber auch Schaltsekunden, -minuten und weiteres die simple Rechnung kaputt. Imho wäre der bessere Ansatz, die gut getestete Bibliothek zu nehmen, die das alles korrekt handhabt. Deine Fragestellung klingt stark nach premature optimization.

 

[T_55]

Ja die Performance ist sehr relevant weil es in einer Simulation eingesetzt wird wo die Abfrage permanent stattfindet

 

[Piktogramm]

@NemesisFS
Naja, premature optimization betreibt der TE auch, angefangen hat es ja aber mit ganz fürchterlichen Konzepten und später entsprechender Umsetzung...


@T_55
Kannst du nicht einfach deine alten Threads wiederverwenden? Da hätte man dann auch den Kontext zum nachlesen. Bei deinen Fragen die im größeren Wochenabstand erfolgen ist das hilfreich.

Ansonsten ist es wie NemesisFS schon sagt, dass es ein sehr guter Ansatz ist fertige, gut optimierte und gut getestete Bibliotheken zu verwenden anstatt den Kram selber zu schreiben. Da es bei dir um simple Datenanalyse geht wirst du dabei früher oder später etwas bauen, was von der Verwaltung der Daten her ausschaut wie der Unterbau einer Datenbank. Entsprechend wiederhole ich meinen Tip aus deinem ersten Thread zum Thema:
Nimm eine Datenbank!
Da haben sich bereits Andere mit deinen jetzigen sowie zukünftig zwangsweise auftretenden Problemen beschäftigt und sie besser gelöst als du es lösen können wirst.

Ansonsten: Zum rechnen mit unixtime und entsprechenden Performancegewinnen -> Told you so

 

[NemesisFS]

Okay: Wenn du nur Wissen möchtest ob Sommerzeit ist oder nicht würde ich so etwas hier probieren:

(time % year_duration) > mesz_start && (time % year_duration) < mesz_end

Die Variablen müsstest du entsprechend setzen, die hägenn von deinen Zeiteinheiten ab und dem Ort wo du dich befindest (ich gehe mal aus, es geht um MEZ/MESZ). Wenn performance tatsächlich derart kritisch ist würde ich aber darüber nachdenken, ein entsprechendes Flag mitzunehmen und über einen Counter die Iterationen bis zum nächsten MEZ/MESZ Wechsel zu zählen.

 

[Nolag]

Es kommt noch dazu, dass wenn man genau sein will, auch noch die Schaltsekunden zu berücksichtigen sind.

 

[T_55]

Da hab ich mir ja einen Ruf eingebrockt hehe... diesmal beruht es aber auf einer Messung mit sehr deutlichem Ergebnis. Die Vermutung das struct tm derart langsam ist hat sich ja bestätigt, die Iteration von 0 zu heute dauert mit modulo 2,5sek und mit struct tm 182,2sek. Natürlich wird modulo noch ein wenig langsamer wegen daylight saving time aber wird sicher immer noch deutlich schneller sein als struct tm.

Ich tüftle noch an dem "letzten Sonntag im März um 2:00 Uhr" und "letzten Sonntag im Oktober um 3:00 Uhr", Wochentage und Uhrzeit gehen gut aber die Definition "letzten Sonntag im Monat" ist tricky...

 

[NemesisFS]

Gerade deswegen bietet es sich an auf bestehenden code zurückzugreifen.

Kurze Frage: Hast du die Geschwindigkeitsvergleiche mit einem release oder debug build gemacht?

 

[BlackMark]

Wenn du wirklich Hilfe haben möchtest, dann tu endlich das, was dir bis jetzt in allen deinen Threads zu dem Thema schon gesagt wurde: Zeig uns die Daten auf denen du arbeiten willst und sag uns genau was du damit berechnen willst.
Nur dann können wir dir wirklich helfen, alles was du jetzt machst ist absolut premature optimization und führt zu rein gar nichts.

Gruß
BlackMark

 

[kuddlmuddl]

Schließe mich BlackMark zu 100% an.
Hier sind alle sehr hilfsbereit und haben sogar Spaß daran deine Probleme zu lösen aber du musst sie schon verraten.

 

[NemesisFS]

Das klingt für mich nach dem üblichen XY-Problem, da falle ich auch immer wieder drauf rein, vielleicht gibt es ja tatsächlich einen besseren Ansatz als der, den du gewählt hast (klingt zumindest so, ohne die anderen threads verfolgt zu haben).

Beim Schreiben von performancekritischen Anwendungen versenkt man sich häufig in Details, um dann später herauszufinden, dass der wirkliche Leistungsverlust wo anders auftaucht.
Für mich habe ich zwei Ansätze gefunden, das zu umgehen:
- einen möglichst blöden Prototypen schreiben, wenn der fertig ist, hat man das Problem und die relevanten Stellen erkannt und verstanden
- Direkt das eigentliche Programm schreiben, dabei aber nur versuchen auf einer hohen Abstraktionsebene Designentscheidungen zu treffen, die einem erlauben das Programm möglichst flexibel zu ändern.

Wenn man dann etwas funktionierendes hat, kann man mit einem Profiler darauf losgehen und schauen wo tatsächlich Performance verloren geht.

 

[Nolag]

Ich kann schon verstehen, dass man nicht mehrere Minuten nur für die Zeitbasis verschwenden möchte, wenn es auch in Sekunden geht.
Wenn es nur um den Zeitraum von 1970 bis heute geht, dann empfehle ich einfach eine Tabelle zu erstellen, die für jedes Jahr die Start und Endsekunde der Sommerzeit enhält um damit die Stundenberechnung zu korrigieren.