http://www.pronix.de -> Forum -> Knobelecke

Forum: Knobelecke

Moderatoren: broesel, juergen

Thema: strlen()

Re: strlen()

Patrick am 16.07.2010 um 07:07

Wolfgangs, deinen ersten Ansatz hätte ich vermutlich als nächstes gebracht, aber deinen zweiten Ansatz konnte ich leider nicht mehr toppen.
Philip, auch deine Lösung hätte ich niemals gebracht.

Danke euch beiden, wieder was gelernt Grafik: Smilie Juchuh

--
To follow the path: look to the master, follow the master, walk with the master, see through the master, become the master.

 

Re: strlen()

icefire am 16.07.2010 um 17:32

Zitat:

Hat sich jemand mal die glibc-Version angeschaut? Die ist zwar kommentiert, aber ich bezweifle dass man aus den Kommentaren und dem Code ohne weiteres die Funktionsweise herauslesen kann, wenn man sie nicht bereits vorher kennt.


Habs mir gerade angeschaut ... und jetzt ist mir schwindlig Grafik: Smilie Juchuh

--
Hex, Bugs and Rock 'n Roll

 

Re: strlen()

broesel (webmaster) am 20.07.2010 um 00:33

Hier also als "definitive Lösung" die Erklärung zur glibc-Version:

Wir schauen uns zunächst folgende Konstante an: 0x7efefeffL
In binärer Darstellung wird die Magie offensichtlicher:
01111110 11111110 11111110 11111111

Die Stellen mit 0 nennen wir die Lochbits. Addiert man die magische Konstante mit einer Zahl X ungleich 0, dann wird in einem oder mehreren der vier Bytes ein Überlauf erzeugt und das Carry-Bit landet im Lochbit des nächsthöheren Byte. Nur wenn ein Byte in X ausschliesslich Nullen enthält (Stringende!), kommt kein Überlauf zustande und das Lochbit im nächsten Byte bleibt unverändert 0.

Der Trick besteht jetzt einfach darin, den String wortweise in ein int zu casten und das Ergebnis mit der magischen Konstante zu addieren. Mit einer Bitmaske prüfen wir danach, ob eins der Löcher unverändert geblieben ist. Falls das der Fall ist, haben wir mit hoher Wahrscheinlichkeit ein Stringende gefunden und müssen nur noch herausfinden, um welches der vier möglichen Bytes im String es sich gehandelt hat.

Der Code sähe also ungefähr so aus:


size_t
strlen (const char *str)
{
   const char *char_ptr;
   const unsigned long int *longword_ptr;
   unsigned long int longword, magic_bits;

   longword_ptr = (unsigned long int *) char_ptr;
   magic_bits = 0x7efefeffL;

   for (;;) {
       longword = *longword_ptr++;
 
       if (
       /* Add MAGIC_BITS to LONGWORD.  */
       (((longword + magic_bits)
 
         /* Set those bits that were unchanged by the addition.  */
         ^ ~longword)
 
         /* Look at only the hole bits.  If any of the hole bits
            are unchanged, most likely one of the bytes was a
            zero.  */
         & ~magic_bits)
         != 0) {
           /* Which of the bytes was the zero?
 
           const char *cp = (const char *) (longword_ptr - 1);
 
           if (cp[0] == 0)
             return cp - str;
           if (cp[1] == 0)
             return cp - str + 1;
           if (cp[2] == 0)
             return cp - str + 2;
           if (cp[3] == 0)
             return cp - str + 3;
        }
    }
}




Soweit die Theorie. :)


1) False Positives

Es gibt aber den ungünstigen Fall, dass ein Wort das dritte Byte zum Überlauf bringt und dass die Bits 24-30 (im vierten Byte) alle 0 sind und Bit 31 eine 1 enthält. Dann bleibt das Lochbit unverändert. Das ist aber nicht so tragisch, da es bei Gleichverteilung der Eingaben nur in einem von 256 Fällen auftritt und sowieso erkannt wird, wenn bei einem Positiv nach der genauen Position des Nullbytes gesucht wird.


2) Alignment

Vergleiche sind am Effizientesten, wenn man Wörter vergleicht die bei einem Vielfachen der Wortgrösse beginnen. Deshalb fügt man am Anfang der Funktion noch byteweise Tests durch, bis man bei einem Vielfachen der Wortgrösse angekommen ist, um dann zu den wortweisen Tests wie oben beschrieben überzugehen.


3) Wortgröße

Da heute Rechner mit 32 Bit und 64 Bit in Umlauf sind, muss man an verschiedenen Stellen entsprechende Massnahmen ergreifen.


4) Effizienter Vergleich

Der etwas mühselige Test if((((longword + magic_bits) ^ ~longword) & ~magic_bits) != 0) lässt sich noch erheblich optimieren. Wir führen zwei neue Konstanten ein:

himagic = 0x80808080 /* 10000000 10000000 10000000 10000000 */
lomagic = 0x01010101 /* 00000001 00000001 00000001 00000001 */

Dann können wir den Test effizienter formulieren mit if(((longword - lomagic) & himagic) != 0) und sparen dabei 3 Operationen. In diesem Fall ist das immerhin die Hälfte, verglichen mit der vorherigen Version.


Wendet man dies alles an, so landet man bei folgendem Monster, direkt aus den tiefsten Höllen der glibc:


  1 /* Copyright (C) 1991, 1993, 1997, 2000, 2003 Free Software Foundation, Inc.
  2    This file is part of the GNU C Library.
  3    Written by Torbjorn Granlund (tege@sics.se),
  4    with help from Dan Sahlin (dan@sics.se);
  5    commentary by Jim Blandy (jimb@ai.mit.edu).
  6 
  7    The GNU C Library is free software; you can redistribute it and/or
  8    modify it under the terms of the GNU Lesser General Public
  9    License as published by the Free Software Foundation; either
 10    version 2.1 of the License, or (at your option) any later version.
 11 
 12    The GNU C Library is distributed in the hope that it will be useful,
 13    but WITHOUT ANY WARRANTY; without even the implied warranty of
 14    MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
 15    Lesser General Public License for more details.
 16 
 17    You should have received a copy of the GNU Lesser General Public
 18    License along with the GNU C Library; if not, write to the Free
 19    Software Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA
 20    02111-1307 USA.  */
 21 
 22 #include <string.h>
 23 #include <stdlib.h>
 24 
 25 #undef strlen
 26 
 27 /* Return the length of the null-terminated string STR.  Scan for
 28    the null terminator quickly by testing four bytes at a time.  */
 29 size_t
 30 strlen (str)
 31      const char *str;
 32 {
 33   const char *char_ptr;
 34   const unsigned long int *longword_ptr;
 35   unsigned long int longword, magic_bits, himagic, lomagic;
 36 
 37   /* Handle the first few characters by reading one character at a time.
 38      Do this until CHAR_PTR is aligned on a longword boundary.  */
 39   for (char_ptr = str; ((unsigned long int) char_ptr
 40             & (sizeof (longword) - 1)) != 0;
 41        ++char_ptr)
 42     if (*char_ptr == '\0')
 43       return char_ptr - str;
 44 
 45   /* All these elucidatory comments refer to 4-byte longwords,
 46      but the theory applies equally well to 8-byte longwords.  */
 47 
 48   longword_ptr = (unsigned long int *) char_ptr;
 49 
 50   /* Bits 31, 24, 16, and 8 of this number are zero.  Call these bits
 51      the "holes."  Note that there is a hole just to the left of
 52      each byte, with an extra at the end:
 53 
 54      bits:  01111110 11111110 11111110 11111111
 55      bytes: AAAAAAAA BBBBBBBB CCCCCCCC DDDDDDDD
 56 
 57      The 1-bits make sure that carries propagate to the next 0-bit.
 58      The 0-bits provide holes for carries to fall into.  */
 59   magic_bits = 0x7efefeffL;
 60   himagic = 0x80808080L;
 61   lomagic = 0x01010101L;
 62   if (sizeof (longword) > 4)
 63     {
 64       /* 64-bit version of the magic.  */
 65       /* Do the shift in two steps to avoid a warning if long has 32 bits.  */
 66       magic_bits = ((0x7efefefeL << 16) << 16) | 0xfefefeffL;
 67       himagic = ((himagic << 16) << 16) | himagic;
 68       lomagic = ((lomagic << 16) << 16) | lomagic;
 69     }
 70   if (sizeof (longword) > 8)
 71     abort ();
 72 
 73   /* Instead of the traditional loop which tests each character,
 74      we will test a longword at a time.  The tricky part is testing
 75      if *any of the four* bytes in the longword in question are zero.  */
 76   for (;;)
 77     {
 78       /* We tentatively exit the loop if adding MAGIC_BITS to
 79      LONGWORD fails to change any of the hole bits of LONGWORD.
 80 
 81      1) Is this safe?  Will it catch all the zero bytes?
 82      Suppose there is a byte with all zeros.  Any carry bits
 83      propagating from its left will fall into the hole at its
 84      least significant bit and stop.  Since there will be no
 85      carry from its most significant bit, the LSB of the
 86      byte to the left will be unchanged, and the zero will be
 87      detected.
 88 
 89      2) Is this worthwhile?  Will it ignore everything except
 90      zero bytes?  Suppose every byte of LONGWORD has a bit set
 91      somewhere.  There will be a carry into bit 8.  If bit 8
 92      is set, this will carry into bit 16.  If bit 8 is clear,
 93      one of bits 9-15 must be set, so there will be a carry
 94      into bit 16.  Similarly, there will be a carry into bit
 95      24.  If one of bits 24-30 is set, there will be a carry
 96      into bit 31, so all of the hole bits will be changed.
 97 
 98      The one misfire occurs when bits 24-30 are clear and bit
 99      31 is set; in this case, the hole at bit 31 is not
100      changed.  If we had access to the processor carry flag,
101      we could close this loophole by putting the fourth hole
102      at bit 32!
103 
104      So it ignores everything except 128's, when they're aligned
105      properly.  */
106 
107       longword = *longword_ptr++;
108 
109       if (
110 #if 0
111       /* Add MAGIC_BITS to LONGWORD.  */
112       (((longword + magic_bits)
113 
114         /* Set those bits that were unchanged by the addition.  */
115         ^ ~longword)
116 
117        /* Look at only the hole bits.  If any of the hole bits
118           are unchanged, most likely one of the bytes was a
119           zero.  */
120        & ~magic_bits)
121 #else
122       ((longword - lomagic) & himagic)
123 #endif
124       != 0)
125     {
126       /* Which of the bytes was the zero?  If none of them were, it was
127          a misfire; continue the search.  */
128 
129       const char *cp = (const char *) (longword_ptr - 1);
130 
131       if (cp[0] == 0)
132         return cp - str;
133       if (cp[1] == 0)
134         return cp - str + 1;
135       if (cp[2] == 0)
136         return cp - str + 2;
137       if (cp[3] == 0)
138         return cp - str + 3;
139       if (sizeof (longword) > 4)
140         {
141           if (cp[4] == 0)
142         return cp - str + 4;
143           if (cp[5] == 0)
144         return cp - str + 5;
145           if (cp[6] == 0)
146         return cp - str + 6;
147           if (cp[7] == 0)
148         return cp - str + 7;
149         }
150     }
151     }
152 }
153 libc_hidden_builtin_def (strlen)


Das ist zwar deutlich effizienter als die naive Implementation, man darf sich allerdings fragen ob sich der ganze Aufwand letztendlich auch lohnt. Die Lesbarkeit hat unterwegs stark gelitten, und auch der Portabilität wurden Grenzen auferlegt, was in Zeile 70 zu den denkwürdigen Worten geführt hat:


if (sizeof (longword) > 8)
     abort ();


Der Code ist natürlich grauenhaft, aber das Prinzip mit den magic_bits finde ich schon irgendwie faszinierend.

Gruss,
Philip

--
The C Programming Quiz (externer link) - bitte Fragen einreichen :)

 

Re: strlen()

Anonym am 20.07.2010 um 21:48

Hallo Philip,

Danke für die ausführliche Erklärung!

mfg, Wolfgang