struct nach elementen ordnen



  • DirkB schrieb:

    Und File-I/O und malloc ist schneller als ein paar Zeiger zu verbiegen?
    Ich möchte kein Programm von dir haben wollen.

    Auch von mir:
    Du schreibst Unsinn. Nicht nur in diesem Thread.

    Mit so blöden Sprüchen ist nichts gesagt.

    Was willst du denn sagen?

    Daß man Sekundenbruchteile noch in Bruchteile von Sekundenbruchteilen umformen kann?

    Und wenn ja wie oder was? (LACH)

    Anstatt hier herumzuschwätzen, setz doch mal Code rein.

    Code ist die Basis.



  • Das größte Problem ist, dass die Funktion im Fehlerfall Speicher verliert - so was verbietet sich einfach.

    Direkt dahinter kommt, dass der Algorithmus quadratisch skaliert, im Gegensatz zu n * log(n) bei Quicksort. Man könnte diese Vorgehensweise höchstens dann verteidigen, wenn man vorher weiß, dass die Eingabedaten schon annähernd sortiert ankommen. Ferner entsteht ein riesiger Overhead dadurch, dass du dich für kleinste Speichermengen dauernd an den Heap wendest - zweimal pro Element, und wenn du da vernünftige Fehlerbehandlung reinpatchst, wird diese Fummelei den größten Aufwand bedeuten.

    Nach Bugs hab ich jetzt noch nicht gekuckt. Kann ich vielleicht eine Beispieldatei kriegen, um das mal auszuprobieren?


  • Mod

    SeppJ schrieb:

    Erklär mal bitte den Vorteil dieses gequirlten Unsinns gegen qsort.

    alex2010 schrieb:

    ...Schlechter Code...leeres Geschwätz...eingeschnapptes Verhalten...ein paar falsche Aussagen...

    Zusammenfassend: Deine Funktion ist also langsamer, hat Fehler und ist nicht auf große Datenmengen anwendbar. Und du erklärst das sogar selber so. Wieso war der Vorschlag doch gleich kein Blödsinn?

    Und wenn du eine Kritik an deinen Aussagen persönlich nimmst: Willkommen im Internet.



  • seldon schrieb:

    Das größte Problem ist, dass die Funktion im Fehlerfall Speicher verliert - so was verbietet sich einfach.

    Direkt dahinter kommt, dass der Algorithmus quadratisch skaliert, im Gegensatz zu n * log(n) bei Quicksort. Man könnte diese Vorgehensweise höchstens dann verteidigen, wenn man vorher weiß, dass die Eingabedaten schon annähernd sortiert ankommen. Ferner entsteht ein riesiger Overhead dadurch, dass du dich für kleinste Speichermengen dauernd an den Heap wendest - zweimal pro Element, und wenn du da vernünftige Fehlerbehandlung reinpatchst, wird diese Fummelei den größten Aufwand bedeuten.

    Nach Bugs hab ich jetzt noch nicht gekuckt. Kann ich vielleicht eine Beispieldatei kriegen, um das mal auszuprobieren?

    Im Fehlerfall Speicher verlieren? 100 Jahre dauert es, bis ich 8 GB Speicher gefressen habe, mit diesem Programm, von 2000 Datensätzen, aber nur mal zur Orientierung, interessehalber: ERKLÄR MAL.

    Zweitens ist es ja so, daß wir nicht die Anflugdaten eines Kampfflugzeuges in ECHTZEIT berechnen, und was an einem

    SORTIERALGORITHMUS

    auszusetzen ist, der seinen Job in

    BRUCHTEILEN VON SEKUNDEN

    erledigt, müßte anhand der REALEN ERLEBNISDATEN DER WELT DES JAHRES 2012 erstmal erklärt werden.

    Performance und Optimierung immer und jederzeit, aber 0.x Sekunden erzwingen das nicht.

    Vielleicht:

    Wenn wir von Beschimpfungen mal übergehen zu sachlicher Aussage, hätten auch die Mitleser was davon,

    REIN THEORETISCH,

    nicht wie man 0.05 Sekunden in 0.04 Sekunden verwandelt (das eine reicht, das andree ist in 100 Jahren noch genug), sondern,

    WORAN ICH AUCH IMMER INTERESSE HABE:

    Wie man sauber programmiert.

    That´s it. 😉

    LG Alex



  • Und ja, sie ist quadratisch.

    Bei 1000 Datensätzen ist der Zugriff 1000*1000 = 1 Mio.

    So what? Was sind 1 Mio Datenzugriffe?

    Sekundenbruchteile.

    Worüber reden wir hier?

    Daß der Ferrari, wenn man aus dem Kofferraum den Kasten Bier rausnimmt, noch schneller beschleunigt? 😉

    LG Alex



  • DirkB schrieb:

    Und File-I/O und malloc ist schneller als ein paar Zeiger zu verbiegen?
    Ich möchte kein Programm von dir haben wollen.

    Auch von mir:
    Du schreibst Unsinn. Nicht nur in diesem Thread.

    Du bist ja wirklich ganz schlau.

    File i/o denken wir uns weg. Für uns ist das File sozusagen nicht vorhanden, die Daten hängen frei zugänglich in der Luft? Wir atmen sie ein wie Sauerstoff, oder was wolltest du sagen?

    Und seit wann hat malloc() was mit der Rechenzeit zu tun?

    Wirklich witzig.



  • So, da Code scheinbar König ist - ich habe das mal zusammengestrichen. Ich kann den Kram hier natürlich nicht testen, weil mir große Teile des Drumherums fehlen, also ist das mehr als Kladde zu verstehen. Ich bitte kleinere Fehler deshalb zu entschuldigen.

    So etwa würde ich das anfangen:

    #include <stdlib.h>
    
    int compare_strc_bsatz(void const *lhs_p, void const *rhs_p) {
      strc_bsatz const *lhs = (strc_bsatz const *)lhs_p;
      strc_bsatz const *rhs = (strc_bsatz const *)rhs_p;
    
      return datindex(lhs->data.datum) - datindex(rhs->data.datum);
    }
    
    void sortiere_buchungsdatei_chronologisch()
    {
      FILE *bdp;
      size_t anz_ds;
      size_t elem_read;
      strc_bsatz *data;
    
      bdp = fopen(dn_buchungen_bin,"rb");
      if(bdp == NULL) return;
    
      fseek(bdp, -1 * (long) sizeof(strc_bsatz), SEEK_END);
      anz_ds = ftell(bdp) / sizeof(strc_bsatz);
    
      if(anz_ds <= 1) {
        fclose(bdp);
        return;
      }
    
      fseek(bdp, 0, SEEK_SET);
      data = malloc(sizeof(strc_bsatz) * anz_ds);
      if(data == NULL) return;
      elem_read = fread(data, sizeof(str_bsatz), anz_ds, bdp);
      fclose(bdp);
    
      if(elem_read == anz_ds) {
        qsort(data, elem_read, sizeof(strc_bsatz), compare_strc_bsatz);
        bdp = fopen(dn_buchungen_bin, "wb");
        fwrite(data, sizeof(strc_bsatz), elem_read, bdp);
        fclose(bdp);
      }
    
      free(data);
    }
    

    Was den Rest angeht: Bitte beruhige dich zunächst wieder; ich lasse mich nicht gern anschreien.

    Speicherlecks sind kein Kavaliersdelikt. Als Programmierer muss man darauf gefasst sein, mal in Situationen zu geraten, in denen die eigenen Programme nicht nur 150 Kilobyte Daten verarbeiten müssen, nicht nur zehn Sekunden am Stück laufen und nicht nur auf PCs. Zumal dieser Thread nicht mit der Diskussion deines Programms, das vielleicht wirklich mit begrenzten Parametern zurechtkommt, begonnen hat. Allerdings: auch wenn in einem konkreten Fall die Anforderungen begrenzt sind, läuft heute auf einer Maschine nicht mehr nur ein Programm zur selben Zeit, und ich gebe zu bedenken, dass dein Programm gerade dann Speicher wegwirft, wenn dieser eh schon knapp ist. Auch zeigt die Erfahrung, dass Anforderungen im Laufe der Zeit mal wachsen können, und - sei ehrlich, bist du der Ansicht, dass du dich durch dieses Listengewurstel in zwei Jahren noch durchfinden wirst?

    Übrigens sprachst du anfangs noch von 10000 Datensätzen, da sind wir schon in der Größenordnung von 100 Millionen Vergleichen. Mit Stringauseinanderklamüserei und Sprüngen in die Wallachei (das gibt cache-misses ohne Ende, soviel ist mal klar). Das ist ja das Problem bei quadratischer Skalierung - der Aufwand steigt schnell stark an.



  • Mit deiner Hardware bist du im Jahr 2012 angekommen.
    Nur mit deinem Datenvolumen bist du in den 1980ern hängengeblieben.



  • alex2010 schrieb:

    Und seit wann hat malloc() was mit der Rechenzeit zu tun?

    Okay, jetzt bin ich überzeugt, dass wir es hier mit einem Troll zu tun haben.


  • Mod

    seldon schrieb:

    Okay, jetzt bin ich überzeugt, dass wir es hier mit einem Troll zu tun haben.

    Schiebe nicht auf Trollerei, was sich auch befriedigend durch normale Dummheit erklären lässt.



  • seldon schrieb:

    alex2010 schrieb:

    Und seit wann hat malloc() was mit der Rechenzeit zu tun?

    Okay, jetzt bin ich überzeugt, dass wir es hier mit einem Troll zu tun haben.

    Ist klar.

    Wenn wir malloc() nicht verwenden, ist der Rechner schneller.

    Er frißt dann die Daten mit Überlichtgeschwindigkeit.

    (LACH)



  • SeppJ schrieb:

    seldon schrieb:

    Okay, jetzt bin ich überzeugt, dass wir es hier mit einem Troll zu tun haben.

    Schiebe nicht auf Trollerei, was sich auch befriedigend durch normale Dummheit erklären lässt.

    Du bist Moderator, du Pfeife?

    Also für mich war es das jetzt hier.

    Und Tschüss


  • Mod

    alex2010 schrieb:

    SeppJ schrieb:

    seldon schrieb:

    Okay, jetzt bin ich überzeugt, dass wir es hier mit einem Troll zu tun haben.

    Schiebe nicht auf Trollerei, was sich auch befriedigend durch normale Dummheit erklären lässt.

    Du bist Moderator, du Pfeife?

    Hmm, jemand wirft dir vor, dass du ein Arsch bist und ich verteidige dich, dass du einfach nur Unrecht hast. Hmm, da hatte ich wohl Unrecht.

    Also für mich war es das jetzt hier.

    Und Tschüss

    Tja.



  • roflmao the three of you made my day! 😃



  • alex2010 schrieb:

    Und ja, sie ist quadratisch.

    Na dann rechne dir doch mal aus, wieviel mehr an Daten du mit einem 1000-fach schnelleren Rechner bearbeiten könntest. Ziemlich enttäuschend, was? Ein besserer Algorithmus bringt dir hier ganz schnell mehr.


Anmelden zum Antworten