WordCount lernen

[nouseforname]

Sorry, war canlot.

Die Beschwerde war ja auch nicht ganz ernst gemeint

[nufan]

Ich finde die Diskussion hier sehr interessant und habe eine NASM-Version ins Rennen geschickt

[canlot]

Ich finde die Diskussion hier sehr interessant und habe eine NASM-Version ins Rennen geschickt

O.o

[Xin]

Ich finde die Diskussion hier sehr interessant und habe eine NASM-Version ins Rennen geschickt

Ich sitze gerade an eine Version für gnu-asm... blödes Forum hier... ich dachte, damit noch etwas beeindruckendes reißen zu können. ^^

Meine Version lief als Assembler-Version gegen 22 Uhr?, als ich das die erste Zeile schrieb. Nur der Aufruf aus C, der gelang mir nicht, läuft aber nun endlich.. ich hasse es, ins Bett zu gehen, wenn ich was nicht geschafft habe. (1:30 Uhr)

Zu Dani: Ich brauche einen anderen Aufruf für nasm: /usr/bin/ld: i386 architecture of input file `wcdani.o' is incompatible with i386:x86-64 output - bin aber zu faul jetzt noch nachzugucken.

Der Schnellste ist bisher lollinger, dafür findet er aber die wenigsten Worte. Da muss er wohl nochmal ran. ^^
canlot habe ich von "int i' auf 'unsigned int i' gesetzt, damit er die 3,6GB durchschreiten kann statt abzuschmieren. Auch aus cloidnerux zweiten Algorithmus habe ich den Vergleich auf '\n' entfernt, um gleiche Bedingungen zu schaffen.

Neue Versionen haben cloidnerux, Mr. Mail (ich verrat jetzt mal, dass es bbl ist, so schlecht sind die Werte ja nicht) und NoUseForName eingereicht. Neu dabei ist lollinger mit dem Code, der hier im Thread steht.

Code: Alles auswählen

xin@trinity:/data/home/xin/Personen/xin$ time ./wc
File geöffnet
Size: -534303076
xin   : 598752090 Wörter - Zeit: 16760000
xin++ : 598752090 Wörter - Zeit: 15530000
xinasm: 598752090 Wörter - Zeit: 10120000
cloid : 598752090 Wörter - Zeit: 16290000
cloid2: 598752090 Wörter - Zeit: 17450000
nouse : 598752090 Wörter - Zeit: 19710000
nouse2: 598752090 Wörter - Zeit: 17970000
mail  : 598752090 Wörter - Zeit: 21090000
mail2  : 598752090 Wörter - Zeit: 16490000
dirty : 606372480 Wörter - Zeit: 20770000
dirty2: 606372480 Wörter - Zeit: 22400000
lollinger: 9 Wörter - Zeit: 0
canlot: 598752090 Wörter - Zeit: 21580000

real    4m0.912s
user    3m36.166s
sys     0m3.304s

Um die Ergebnisse mal deuten zu können: Die Algorithmen liegen alle recht nah beieinander. Die Funktion clock() ist viel zu ungenau, um klare Aussagen abzulesen. So ist xin++ mal schneller, mal langsamer als xin. Dass Cloidnerux mit seiner neuen Version langsamer ist, wundert mich nicht. Er scheint in seiner ersten Version einen Ausdruck gefunden zu haben, der vom Compiler perfekt gefressen wird. An der Zeit sieht man, dass bbl im 2. Versuch ähnliche Zeiten hat und der Code ist nahezu identisch - für die CPU wird er vermutlich auch identisch sein. Trotzdem verbrät bbl im 2. Versuch unnötig massiv Zeit, in dem er die Länge des Strings ermittelt (der ist immerhin 3,6GB groß...).
Das scheint ihm die CPU aber nicht allzu übel zu nehmen. Das ganze läuft auf einem Intel i7 860@2.8GHz mit 8GB RAM. Ich hätte trotzdem deutlich mehr Zeitverlust erwartet.
Die Assemblerversion (xinasm) ist erwartungsgemäß schneller als die C-Versionen. Ich habe ja den Faktor 2 geschätzt, aber da komme ich nicht ganz ran.

Ich warte noch Dirty Oerti ab und dani mit seiner Nasm-Version. Kerli hat keine Lust auf ein Duell? ^^
Dann würde ich sagen, veröffentliche ich hier alle Quellen, sofern keiner sich sträubt.

[lolliger]

Außerdem:
Warum brauchst du einen 2. Parameter für die Funktion?!
"words" wird der Funktion übergeben und dann auf 1 gesetzt, wohl gemerkt aber nur das "words" innerhalb der Funktion wordCount! Das "words" in main wird dadurch NICHT verändert!

Hast Recht, Danke!

Es können beliebig viele Leerzeichen zwischen den Wörtern sein!

Ändere deinen String zu diesem (kopier ihn einfach von hier) :

" Ich bin."

Und teste, wie viele Wörter gezählt werden.

Ich habe jetzt das Problem so gelöst, dass jetzt sogar " Ich bin . " möglich ist:

Code: Alles auswählen

#include <stdio.h>
#include <stdlib.h>
#include <string.h>


unsigned int wordCount( const char *str)
    {
        unsigned int words;
        int i;
        words=1;

        for ( i=0; str[i]==' ' ;i++ )
        {
        }

        for (; (str[i+1]!='.' && str[i+1]!='!' && str[i+1]!='?') ;i++ )
        {

            if ( (str[i]==' ') && (str[i+1]!=' ') )
                words++;
        }

        return words;
    }


int main( void )
{
    char const * str = "  Ich   bin   . ";
    unsigned int words;

    words = wordCount( str );

    printf( "Der String enth\x84lt %d W\x94rter\n", words );

    return 0;
}

[cloidnerux]

Was soll hier geschehen loliger:

Code: Alles auswählen

for ( i=0; str[i]==' ' ;i++ )
        {
        }

?

Dann würde ich sagen, veröffentliche ich hier alle Quellen, sofern keiner sich sträubt.

Ich hab nix dagegen. Vlt können wir dann gemeinsam einen Algorithmus entwickeln, der an sich schneller ist.
Mal ne Frage am Rande, hatte dein Text Worte mit nur 1 Zeichen?

Um die Ergebnisse mal deuten zu können: Die Algorithmen liegen alle recht nah beieinander. Die Funktion clock() ist viel zu ungenau, um klare Aussagen abzulesen. So ist xin++ mal schneller, mal langsamer als xin. Dass Cloidnerux mit seiner neuen Version langsamer ist, wundert mich nicht. Er scheint in seiner ersten Version einen Ausdruck gefunden zu haben, der vom Compiler perfekt gefressen wird. An der Zeit sieht man, dass bbl im 2. Versuch ähnliche Zeiten hat und der Code ist nahezu identisch - für die CPU wird er vermutlich auch identisch sein. Trotzdem verbrät bbl im 2. Versuch unnötig massiv Zeit, in dem er die Länge des Strings ermittelt (der ist immerhin 3,6GB groß...).
Das scheint ihm die CPU aber nicht allzu übel zu nehmen. Das ganze läuft auf einem Intel i7 860@2.8GHz mit 8GB RAM. Ich hätte trotzdem deutlich mehr Zeitverlust erwartet.
Die Assemblerversion (xinasm) ist erwartungsgemäß schneller als die C-Versionen. Ich habe ja den Faktor 2 geschätzt, aber da komme ich nicht ganz ran.

Hast du Optimiert compiliert?
Mich wundert es auch nicht, ich habe gestern Abend auch noch etwas herumgespielt, aber kein gescheites Ergebnis bekommen, außer das ich eine Instabile Änderung gemacht habe, der mit bei 7,6MB Lorem Ipsum einen Geschwindigkeitsvorteil gegenüber meinen alten Algorithmen hatte, aber eben ein großes Problem hat, das zum Glück nicht aufgetreten ist mit meinem Test-Text.
So wie es jetzt aussieht, hat XIN die Vordersten beiden Plätze, dann komme ich und bbl.
Und ein Dirty Oerti, der mehr Wörter zählt als wir.
Macht langsam spaß hier^^

MfG cloidnerux

[nouseforname]

Hab auch nix gegen. Finde es allerdings sehr interessant wie die zeitlichen Unterschiede sind wo doch sicher alle ähnlich arbeiten.

Vorallem interessiert mich aber was man noch optimieren kann, speziell natürlich ich selbst. Oder ob das im prinzip eine Frage des Compilers ist.

[bbbl]

Also ich muss schon sagen dass ich ein wenig überrascht bin noch so weit vorne gelandet zu sein. Vor allem auch, weil ich nur etwas Halbwissen in puncto C hatte und mir vieles erstmal anlesen musste.

Trotzdem verbrät bbl im 2. Versuch unnötig massiv Zeit, in dem er die Länge des Strings ermittelt (der ist immerhin 3,6GB groß...).

Mein Hauptgedanke dabei war halt, Dekrement ist ja schneller als Inkrement. An größere Einbußen durch strlen (bei so langen Strings) hab ich dabei irgendwie nicht gedacht..

BTW, ich hab ebenfalls nix gegen eine Veröffentlichung der Codes..

[canlot]

Wartet auf mich ich will noch meine Pointer Version schicken.

[Xin]

Ich hab nix dagegen. Vlt können wir dann gemeinsam einen Algorithmus entwickeln, der an sich schneller ist.

Kann man gerne ausprobieren, aber dafür brauchen wir noch eine eindeutige Methode, um die Performance zu testen. clock() ist nur ein Näherungswert und wenn zur Ausführung des Programms swappen muss, dann bringt das nicht mehr viel.

(Ja, ich weiß, dass man den Text auch 10 oder 100mal durchgehen kann, aber aktuell dauert der Test schon 4 Minuten...)

Mal ne Frage am Rande, hatte dein Text Worte mit nur 1 Zeichen?

Es ist nur ein Lorem Ipsum... oder besser... tausende..

Möglich, den Text habe ich aus wikipedia kopiert, dort gibt es eine eigene Seite dafür, wo nur der Text drauf steht. Bei Bedarf schicke ich Dir aber den Originaltextblock

Hast du Optimiert compiliert?

Nein.

So wie es jetzt aussieht, hat XIN die Vordersten beiden Plätze, dann komme ich und bbl.

Du und bbl seid öfter mal schneller als ich. Wie gesagt, ich brauche noch eine exaktere Zeitmessung unter Linux. Ich habe es mit der Kernel-Zeit versucht, aber da findet der Compiler die Deklarationen nicht. ^^

Du und bbl habt quasi identischen Code.

Und ein Dirty Oerti, der mehr Wörter zählt als wir.

Er hat eine sehr scharfe Beschreibung von dem, was ein Wort ist.
Die Aufgabenstellung war Wörter in einem String zu zählen, die zwischen Leerzeichen sind, es ging nicht um Sätze und auch nicht um Zeilenwechsel. "Dies ist ein\nSatz." sind drei Worte: "Dies", "ist", "ein\nSatz."
Die einzigen Trennsymbole sind Stringanfang, Stringende ('\0') und das Leerzeichen.

Also ich muss schon sagen dass ich ein wenig überrascht bin noch so weit vorne gelandet zu sein. Vor allem auch, weil ich nur etwas Halbwissen in puncto C hatte und mir vieles erstmal anlesen musste.

Mach Dir nix draus. Mit der Aktion bin ich derzeit ganz vorne (sofern dani nicht nachlegt). Assembler für x86 habe ich zuletzt programmiert, da begannen die Jahreszahlen noch mit einer 1 vorne...

Obwohl es schon irgendwie bedenklich ist, wenn diejenigen, die keine Ahnung haben ganz vorne sind. *grins*

Trotzdem verbrät bbl im 2. Versuch unnötig massiv Zeit, in dem er die Länge des Strings ermittelt (der ist immerhin 3,6GB groß...).

Mein Hauptgedanke dabei war halt, Dekrement ist ja schneller als Inkrement. An größere Einbußen durch strlen (bei so langen Strings) hab ich dabei irgendwie nicht gedacht..

Inkrement und Dekrement sind gleichschnell (oder ich lerne bald etwas ganz Neues). Was Du meinst ist vermutlich ++i und i++, was bei Integern ebenfalls gleichschnell ist.
Nur bei Klassen solltest Du nach Möglichkeit ++instance statt instance++ verwenden.