Welches strlen ist schneller?

[udok (Gast)]

Hallo,

Und zum Schluss die Ergebnisse der Performance Tests für die strlen 
Funktion,
ohne viel Kommentar.

Wenn Interesse besteht, das ganze auf dem eigenen Rechner 
auszuprobieren,
dann stelle ich die Sourcen und die Exe hier rein.

Gruss,
Udo

[Wilhelm M. (wimalopaan)]

Besser std::string benutzen, da entfällt das Problem ;-)

[Jobst Q. (joquis)]

strlen ist dann am schnellsten, wenn es nicht gebraucht wird. ZB wenn 
man es durch eine einfache Pointersubtraktion ersetzt. Dazu benutzt oder 
schreibt man Stringfunktionen, die das Stringende zurückgeben, statt dem 
eh schon bekannten Stringanfang, wie stpcpy statt strcpy.

[Irgendwer (Gast)]

Wie kannst Du Dir sicher sein, dass Du nicht einfach nur aktuelle RAM- 
und Cache-Performance getestet hast?

Mikrobenchmarks korrekt durchführen ist eine Wissenschaft für sich. 
Heutige Betriebssystem und CPU-Architekturen sind da ganz schön 
spannend...

[D00fi (Gast)]

Im guten VHDL kann man auch ein strlen schreiben, was nach
einem Takt schon einen Returnwert hat!
Das soll mal einer in C nachmachen...

[Purzel H. (hacky)]

Es ist aber schon klar dass sich die Strings gewandelt haben ? Zum einen 
gibt es Wide Strings, UTF-8, usw, wo ein char mehr als ein byte belegt. 
Und dann sollte man nicht mehr mit 0 terminierten Strings arbeiten, 
sondern sich die Laenge separat mitfuehren.
Das Schlimmste geschieht, wenn man Strings aus einzelnen Character 
zusammenhaengt im Sinne von :
- Laenge bestimmen
- alloc laenge + 1
- bestehenden stron kopieren
- neues byte hinten dran
- dispose bestehden string.

[Mark B. (markbrandis)]

Ich hab jetzt ehrlich gesagt noch nie von einem Programm gehört, das zu 
langsam gelaufen wäre, weil ein strlen() zu viel Rechenzeit verbraucht 
hätte. 🤔

[Le X. (lex_91)]

Mark B. schrieb:
> Ich hab jetzt ehrlich gesagt noch nie von einem Programm gehört, das zu
> langsam gelaufen wäre, weil ein strlen() zu viel Rechenzeit verbraucht
> hätte. 🤔

Weißt du denn von jedem trägen Programm den Grund, warum es träge ist?

[temp (Gast)]

Mark B. schrieb:
> Ich hab jetzt ehrlich gesagt noch nie von einem Programm gehört, das zu
> langsam gelaufen wäre, weil ein strlen() zu viel Rechenzeit verbraucht
> hätte.

Klar, wenn man nur 'Hello World' programmiert.
Wer mit wirklich großen Datenmengen und Formaten umgehen muss die er 
nicht selbst bestimmen kann, kann durchaus in die Verlegenheit kommen 
dass ein langsames strlen() darüber entscheidet ob die Analyse 1 Stunde 
oder 3 Stunden braucht. Mit irgendwelchen dynamischen Sachen ala 
str::string brauchst du dann überhaupt nicht anfangen. Für den 6er 
Compiler von Microsoft habe ich auch eine eigene strlen() verwendet weil 
die damalige Version in der lib schnarch langsam war.

[temp (Gast)]

Stell bitte mal deine Quellen hier ein, ich würde das gern mal gegen 
testen.

[Mark B. (markbrandis)]

Le X. schrieb:
> Weißt du denn von jedem trägen Programm den Grund, warum es träge ist?

In den Beiträgen vom Themenersteller war meines Wissens nach nie die 
Rede davon, dass irgendwas zu langsam wäre.

Ansonsten halte ich es mit Donald Knuth: "The real problem is that 
programmers have spent far too much time worrying about efficiency in 
the wrong places and at the wrong times; premature optimization is the 
root of all evil (or at least most of it) in programming."

[temp (Gast)]

temp schrieb:
> Stell bitte mal deine Quellen hier ein, ich würde das gern mal gegen
> testen.

ok, nicht mehr nötig. Mir recht das was es zu memcpy im anderen Thread 
gibt

[Rolf M. (rmagnus)]

D00fi schrieb:
> Im guten VHDL kann man auch ein strlen schreiben, was nach
> einem Takt schon einen Returnwert hat!

Egal wie lang der String nachher zur Laufzeit ist?

[D00fi (Gast)]

> Egal wie lang der String nachher zur Laufzeit ist?

Sicher, wenn der FPGA genuegend Swapspace hat.

SCNR.

[Mark B. (markbrandis)]

@udok
Darf man fragen, was die Motivation dafür ist so genau auf die 
Rechenzeit zu schauen? Hast Du sehr große Datenmengen zu verarbeiten?

[udok (Gast)]

Die Motivation war zu wissen, wie gross die Unterschiede in den Libc 
memcpy/strcpy Funktionen sind, bzw. ob es nennenswerte Unterschiede 
gibt.
Das ist erst mal ausreichend geklärt.

[udok (Gast)]

Hier ein Update der Ergebnisse der Performance Tests für
die strlen Funktion.  Das Diagram zeigt die verarbeiteten Bytes / Takt
in Abhängigkeit der String Länge.

- Der Microsoft cl.exe compiler stolpert manchmal über seine eigenen
  Optimierungen.  Die Compiler eigenen Builtin Funktionen sind
  mit der -O2 Optimierung eingeschaltet.
  Leider sind diese "Intrinsic" Funktionen langsamer als
  die Funktionen der MS Runtime MSVCRT...
  Daher wurde jetzt mit "-Oi-" (Intrinsics aus) compiliert.
- Die MSVCRT schlägt sich ziemlich gut, wenn sie der Compiler verwendet.
- Der Intel Compiler v19 hat hier ein Problem
  mit der Erkennung des Host Prozessors (-QxHost).
  Am schnellsten ist der Code nur mit -O2, und nicht der Host spezifische.
- AVX2 in Assembler bringt noch mal einen Faktor 2x gegenüber der SSE2 Lib
  von Agner Fog.  Damit erreicht man bis zu 25 Bytes / Takt.
  Nicht schlecht für die seit Zen3 totgesagte Intel CPU.
- die kurze Assembler Schlefe "rep; scasb" ist brutal langsam,
  leider optimiert Intel nur die "rep; movsb" Schleife.

Gruss,
Udo

[mh (Gast)]

udok schrieb:
> AVX2 in Assembler bringt noch mal einen Faktor 2x gegenüber der SSE2 Lib
>   von Agner Fog.  Damit erreicht man bis zu 25 Bytes / Takt.

Hast du das auch mal getestet, wenn der CPU warm wird? Taktet die CPU 
bei den AVX2 Befehlen runter, wenn du die CPU richtig belastest?

[udok (Gast)]

mh schrieb:
> Hast du das auch mal getestet, wenn der CPU warm wird? Taktet die CPU
> bei den AVX2 Befehlen runter, wenn du die CPU richtig belastest?

In meinen Tests sehe ich keinen Effekt.

Jeder der Tests läuft in einer Schleife öfters durch, und alle Tests
dauern eine gute Minute.
Ich habe die Tests noch mal mit den Windows Energieeinstellungen auf 
Maximum
durchlaufen lassen, und das ganze 3 mal wiederholt.
Die Ergebnisse sind sehr reproduzierbar, da ändert sich nicht viel.

Der Lüfter vom Notebook läuft hörbar, aber noch nicht auf Maximum.
Es wird aber auch nur eine der 6 CPUs beansprucht.

Hier noch die Programmgrösse:

test_0_intel_icl_19.exe           22528
test_1_AgnerFog_cl_15.exe          6656
test_2_strlen_avx_cl_15.exe        6656
test_3_strlen_sse_cl_15.exe        6656
test_4_msvcrt_cl_15.exe            6656
test_5_forloop_cl_15.exe           6656
test_6_strlen_scasb_cl_15.exe      6656
test_7_strlen_forloop_gcc_9.exe   43008

Der Mingw gcc linkt noch mit seinen eigenen Supportlibs,
und die Exe hat 11 (!) Sektionen, keine Ahnung was da der macht...
Alle exe sind ohne Debugging Infos, und gestrippt,
und linken dynamisch auf die MSVCRT.DLL

[mh (Gast)]

Du benutzt aber nur einen Kern?

[udok (Gast)]

Ja.  Die Tests laufen hintereinander auf einem Kern.

[Carl D. (jcw2)]

D00fi schrieb:
>> Egal wie lang der String nachher zur Laufzeit ist?
>
> Sicher, wenn der FPGA genuegend Swapspace hat.
>
> SCNR.

Wenn das FPGA eine 8x unendlich breites RAM Interface hat, dann schafft 
man das in einer "Speichertransaktion". Die internen Resourcen werden ja 
immer reichen, denn die nötigen Anschlüsse ermöglichen ja beliebige 
Chipfläche. Problematisch wird die Physik. Blöder Einstein.

[cppbert3 (Gast)]

Mark B. schrieb:
> Ansonsten halte ich es mit Donald Knuth: "The real problem is that
> programmers have spent far too much time worrying about efficiency in
> the wrong places and at the wrong times; premature optimization is the
> root of all evil (or at least most of it) in programming."

Das KANN ein Problem sein ist aber in der heutigen Zeit aber auch 
manchmal überholt, so wie auch Aussage das Assembler nicht mehr 
schneller oder immer schneller ist, solche Sätze kommen von Leuten die 
es schon zu bunt, falsch oder nie Optimierung Betrieben haben oder 
mussten

Die Float String Konvertierung hat auch irgendwie kaum jemand gejuckt, 
mit der neuen MSVC STL zieht z.B. der neue Ryu Algorithmus ein der 
faktisch alle alten Messwerte bedeutungslos macht, und auch bei memcpy 
und Konsorte gibt es immer noch regelmässig Verbesserung an der glibc, 
musl usw. Nur sind die Optimierungen nicht einfach automatisch auf allen 
Platformen, Kompilern gleichmässig gut verfügbar

Wenn es wirklich um Performanz geht und kein Anfänger am Werk ist der 
diletantische Gründe für Performanzprobleme sieht hat auch heute noch 
relevanz

[Carl D. (jcw2)]

Intel weiß übrigens, welche SIMD-Befehle da besonders nützlich sein 
können. Wobei auch der x64-GCC dem Assemblerleser schnell klar macht, 
daß er einen gewissen Rüchstand bei den Vokabeln hat.

Gerade mal ge-google-t:
mit VPCMPUB kann man 64Bytes am Stück mit '\0' vergleichen und das 
Ergebnis in ein Mask-Register schreiben. Dann mit CLZ den Index der 
ersten '1' im Ergebnis finden. Das ist viel schneller als Null-Bytes in 
einer Schleife suchen.

[schlaubischlumpf (Gast)]

> Wenn es wirklich um Performanz geht und kein Anfänger am Werk ist der
> diletantische Gründe für Performanzprobleme sieht hat auch heute noch
> relevanz

Versuchs nochmal mit ein paar Kommas.

[cppbert3 (Gast)]

schlaubischlumpf schrieb:
> Wenn es wirklich um Performanz geht und kein Anfänger am Werk ist
> der diletantische Gründe für Performanzprobleme sieht hat auch heute
> noch relevanz
>
> Versuchs nochmal mit ein paar Kommas.

Wirds damit schneller ;)

[Pandur S. (jetztnicht)]

Falls die Stringlange zu zaehlen ein Problem wird, nimmt man besser ein 
Array of char und fuehrt die laenge als variable mit. Dann faellt das 
zaehlen weg... tsss.

[cppbert3 (Gast)]

Pandur S. schrieb:
> Falls die Stringlange zu zaehlen ein Problem wird, nimmt man
> besser ein Array of char und fuehrt die laenge als variable mit. Dann
> faellt das zaehlen weg... tsss.

Wenn man das ändern kann...

[Jemand (Gast)]

Pandur S. schrieb:
> Falls die Stringlange zu zaehlen ein Problem wird, nimmt man
> besser ein Array of char und fuehrt die laenge als variable mit. Dann
> faellt das zaehlen weg... tsss.

Adieu API-Kompatibilität und Konsistenz

[D00fi (Gast)]

Wir sind hier bei C und nicht bei Pascal!

[Pandur S. (jetztnicht)]

Es soll Leute geben, welche repetitiv an einen String appenden. Dies 
geht dann als

 len= stlen(thestring);
 pluslen = strlen(plusstring);
 newstring = alloc(len+pluslen);
 newstring = copy(thestring)+copy(plusstring)

wenn man das ein paar Millionen mal macht, um sich einen Text 
zusammenzustueckeln, ist der Rechner beschaeftigt.

[nicht BWLer (Gast)]

> Es soll Leute geben, welche repetitiv an einen String appenden.

Das kann ich mir bei BWL-Software lebhaft vorstellen.
Da es damit aber nur BWLer trifft, ist es mir egal.