|
Anzeige
|
Welches strlen ist schneller?
Gast
#6487660
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
Angehängte Dateien:
Besser std::string benutzen, da entfällt das Problem ;-) 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.
Gast
#6487886
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...
Gast
#6487930
Im guten VHDL kann man auch ein strlen schreiben, was nach einem Takt schon einen Returnwert hat! Das soll mal einer in C nachmachen... 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. 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. 🤔 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?
Gast
#6488490
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.
Gast
#6488506
Stell bitte mal deine Quellen hier ein, ich würde das gern mal gegen testen. 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."
Gast
#6488568
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 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?
Gast
#6489059
> Egal wie lang der String nachher zur Laufzeit ist? Sicher, wenn der FPGA genuegend Swapspace hat. SCNR. @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?
Gast
#6490640
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.
Gast
#6528195
Gast
#6528202
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?
Gast
#6528250
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:
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
Gast
#6528254
Du benutzt aber nur einen Kern?
Gast
#6528258
Ja. Die Tests laufen hintereinander auf einem Kern. 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.
Gast
#6528417
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 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.
Gast
#6528444
> 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.
Gast
#6528475
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 ;) 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.
Gast
#6528704
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...
Gast
#6528705
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
Gast
#6528813
Wir sind hier bei C und nicht bei Pascal! 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.
Gast
#6530543
> 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.
Antwort schreibenBitte melde dich an, um einen Beitrag zu schreiben. |
Anzeige
|
