4 buchstaben als ints vergleichen dauert sehr lange

Meep Meep

ahoi

wollte mal austesten, ob man mit dem vergleichen von 4 buchstaben als ints schneller ist als mit strcmp. hab komisches ergebnis bekommen.

strcmp: 41 ticks
mit ints: ca. 500 ticks

code:

char temp1[] = "test";
   char temp2[] = "tewt";
   int c = 0;
   long long int start, ende;

   start = rdtsc();
   unsigned int a = *((unsigned int*)temp1);
   unsigned int b = *((unsigned int*)temp2);

   if(a == b)
      ++c;

   ende = rdtsc();

hab ich mal wieder die grippe oder was is da los ? ich kann mir das nicht ganz erklaeren.

Meep Meep

Meep Meep schrieb:

unsigned int a = *((unsigned int*)temp1);
   unsigned int b = *((unsigned int*)temp2);

...im Debugmodus und ohne eingeschaltete Optimierungen viel Zeit kosten

Meep Meep

hola

habs im release modus kompiliert.
einstellungen: Anweisungs-Set : Pentium Pro
Datenausrichtung: Quad word
Codeoptimierung: Geschwindigkeit

Meep Meep

otze

ist das konstant so?

ansonsten: versuchs mal so, kann sein, dass in deinem test windows dazwischengefunkt hat und einem andren thread grad priorität gab.

char temp1[] = "test";
char temp2[] = "tewt";
int c = 0;
long long int start, ende;
long long minimumZeit=0;//in minimumzeit ist hinterher der kleinste messwert

for(int i=0;i<10000;++i){
   //dein test
   start = rdtsc();
   unsigned int a = *((unsigned int*)temp1);
   unsigned int b = *((unsigned int*)temp2);

   if(a == b)
      ++c;

   ende = rdtsc();

   //schauen ob die gemessene Zeit kleiner ist
   if((ende-start<minimumZeit)||minimumzeit==0){
       minimumzeit=ende-start;
   }
}

Meep Meep

re

bissl besser ist es. 240 ticks. noch immer gnomisch

Meep Meep

-Foo-

also mit dem gcc4.0 benötigt der int vergleich bei mir nur 41ticks, der strcmp vergleich 3200ticks...

ohne optimierung... wenn ichs optimiere, dann wird der ganze vergleich wegoptimiert...

Ponto

Vielleicht kann der Compiler den Stringvergleich wegoptimieren und den Int Vergleich nicht, da der einen etwas komplizierteren Weg geht. Für zwei vorher bekannte Strings kann er das ja selbst ausrechnen.

Der ganze Vergleich ist sinnlos, da nicht praxisnah. Wenn man es aber ein wenig besser machen will, muss die Vergleichsfunktion die Strings per Argument erhalten. Sie muss in einer anderen Übersetzungseinheit als die Strings liegen. Und es müssen die Linkzeitoptimierungen ausgeschaltet werden.

camper

selbst wenn der compiler nicht versteht (und das tut er wenn man alle optimierungen einschaltet), was genau da passiert und damit den vergleich durchführt, kann er leicht feststellen, dass dieser nur von temp1 und temp2 abhängt und diese sich innerhalb der schleife nicht ändern. folglich kann er den gesamten vergleich aus der schleife herausbewegen - und weil der rest der schleife nichts tut diese gleich ganz eliminieren. das mindeste, was zu tun wäre, ist temp1 und temp2 als volatile zu deklarieren. wobei mir nicht ganz klar ist, ob das etwas ändert, wenn man volatile für strcmp einfach wegcastet. der aufruf von rdtsc() kann ebenfalls so gut wie überall stattfinden (und rdtsc selbst hat ja das problem, dass es nicht serialisiert) - auch hier müsste man mit volatile nachhelfen (na gut, das wäre nur der fall, wenn der compiler versteht, was rdtsc macht - für die compiler die ich kenne ist inline assembler immer undurchsichtig, evtl. abgesehen von der registerverwendung). anderseits verhindert volatile andere sinnvolle optimierungen - wie bereits erwähnt, diese art von test ist sinnlos und ohne aussagekraft.