/c/ – Pufferüberlauf

[Zurück]

[l] Wir optimieren Fefes Blog Felix Sat, 18 Apr 2020 02:48:34 GMT Nr. 27355
hacker.jpg
JPG 724×407 196.4k
Aus gegebenem Anlass wegen der Diskussion hier >>27130 hat Felix mal verschiedene Varianten getestet. [0] Einmal die Original-switch-Variante, zwei strcmp-Varianten und eine einfache if-Variante. Die Ergebnisse haben Felix überrascht – beide strcmp-Varianten waren weit abgeschlagen. Die anderen beiden waren in etwa gleichauf. Felix hatte erwartet, dass der Compiler die strcmp-Aufrufe besser optimiert.
```
FEFE:    1.450s
SIMPLE:  1.529s
STRCMP0: 4.307s
STRCMP1: 3.322s
```
(kompiliert mit gcc -O2)

Vielleicht können wir ja hier einen kleinen Optimierungswettbewerb starten :3 Felix wird seine Lösung später pfostieren.

[0] https://pastebin.com/fdDGYMZb

[l] Felix Sat, 18 Apr 2020 08:30:11 GMT Nr. 27359
>>27355
>Felix hatte erwartet, dass der Compiler die strcmp-Aufrufe besser optimiert.
Trägt nicht eher strstr() die Schuld?

Auch: Hab mal schnell eine PHP-Variante mit preg_match_all() gebastelt:
https://pastebin.com/SbJjYnGS
Die kommt so etwa auf 3 Sekunden Laufzeit.

[l] Felix Sat, 18 Apr 2020 12:24:11 GMT Nr. 27360
>>27359
>Trägt nicht eher strstr() die Schuld?
Stimmt, STRCMP1 hätte eigentlich STRSTR heißen müssen. War schon spät. STRCMP0 ist aber korrekt benannt.

>Die kommt so etwa auf 3 Sekunden Laufzeit.
2.4 sind es hier. Dein Skript zählt allerdings nur die Wörter und berechnet nicht den Score. Aber schon mal ein guter Anfang.

[l] Felix Sat, 18 Apr 2020 16:22:57 GMT Nr. 27368
Tägliche Erinnerung, jede Zeitmessung mehrfach zu machen und den kleinsten Wert zu nehmen (bei dem war der Rechner am wenigsten abgelenkt).

[l] Felix Sat, 18 Apr 2020 22:15:34 GMT Nr. 27377
>>27368

Den kleinsten? Ich habe da immer den Durchschnitt genommen

[l] Felix Sat, 18 Apr 2020 22:20:58 GMT Nr. 27378
>>27368
>>27377
Ohne Angabe der Standardabweichung alles nutzlos.

[l] schlag den felix do i win? Sun, 19 Apr 2020 04:02:29 GMT Nr. 27382
wie von >>27368 empfohlen, jede messung 10x und kleinsten wert genommen.

wer sich den code tatsächlich angetan hat, wird bemerkt haben, dass der fefehash auch für wörter über 4 zeichen läuft, und zwar eine iteration pro zeichen. sinnlose verschwendung. sind sogar noch resten auskommentierten codes da, wo er wohl über einen vorzeitigen abbruch nachdachte. wenn man das zeugs lesbar schreiben und ordentlich kommentieren würde, wär sowas nicht passiert.

jedenfalls kann man den fefehash recht einfach zu einer optimalen anzahl if-else konvertieren, da code-lesbarkeit definitiv kein kriterium zu sein scheint. ausserdem, wenn man pointer verstanden hat, braucht man auch kein bitweises reinschieben in einem loop.

bonus: sogar mit den zusätzlichen ntohs/ntohl ist das schneller als fefe. bin grad zu faul, die werte im switch-statement auf korrekte endianness umzumappen und dabei die ntohX und den bitshift im case wortlänge=3 zu sparen. vielleicht morgen. gäb aber extra-stilpunkte wegen noch üblerer lesbarkeit.

ausserdem, ich zitiere https://blog.fefe.de/?ts=a8c95274 : "NEHMT DIE BUILTINS."
wenn man sich an solch weise vorschläge hält und __builtin_expect einsetzt, spart man nochmal relevant zeit ein.
```
$ gcc -DVARIANT=FEFE -O2 fefe.c && time ./a.out
Sample 1: -20 (de)
Sample 2: 7 (en)

real    0m1.192s
user    0m1.188s
sys     0m0.004s

$ gcc -DVARIANT=OWN -O2 fefe.c && time ./a.out
Sample 1: -20 (de)
Sample 2: 7 (en)

real    0m0.919s
user    0m0.916s
sys     0m0.000s

$ gcc -DVARIANT=OWNB -O2 fefe.c && time ./a.out
Sample 1: -20 (de)
Sample 2: 7 (en)

real    0m0.734s
user    0m0.732s
sys     0m0.000s
```
https://0bin.net/paste/6MC1JM9Rvbd2BWxs#0LIDMsKr1qOYfChu+BvsKl9pUlX6kMsbYtoWk-dAq71

[l] Felix Sun, 19 Apr 2020 04:13:17 GMT Nr. 27384 SÄGE
>>27382
mir fällt da grad noch das sys 0m0.004s auf. keine ahnung, wo das herkommt, zufall wohl. hier nochmals eine messung, bei der das nicht aufgetreten ist:
```
Sample 1: -20 (de)
Sample 2: 7 (en)

real    0m1.193s
user    0m1.188s
sys     0m0.000s
```
wär ausserdem nett, wenn jmd anderes (im idealfall >>27355) messungen machen kann auf seiner maschine zur validierung.

[l] Felix Sun, 19 Apr 2020 07:14:55 GMT Nr. 27385
>>27377
https://stackoverflow.com/questions/33588041/timeit-module-get-fastest-and-slowest-loop/33589102#33589102

>>27378
Wenn du immer nur den schnellsten Durchlauf nimmst, interessiert keine Standardabweichung.

[l] Felix Sun, 19 Apr 2020 07:26:55 GMT Nr. 27386
>>27360
>2.4 sind es hier. Dein Skript zählt allerdings nur die Wörter und berechnet nicht den Score.
Würde ich den "Score berechnen" statt naiv alle Treffer durchzuzählen, besteht die Gefahr, dass das PHP-Script schneller läuft als deine schnellste detect_language()-Implementierung. Das können wir beide (ebenso wie fefe) nicht wollen. 😜

>Aber schon mal ein guter Anfang.
Meine Motivation, das Ganze zu optimieren sank leider in dem Moment, als ich feststellen musste, dass ein bisschen PHP-Gefrickel nicht signifikant langsamer ist als handoptimiertes™️ C.

[l] Felix Sun, 19 Apr 2020 07:34:15 GMT Nr. 27387
>>27382
>https://0bin.net/paste/6MC1JM9Rvbd2BWxs#0LIDMsKr1qOYfChu+BvsKl9pUlX6kMsbYtoWk-dAq71
Führt zu:
>This pastebin uses client-side encryption. Therefore, it needs JavaScript enabled.
Per JavaScript handgefrickelte Krypto?
Für die Anzeige von ein paar Zeilen irrelevanten aber mikrooptimierten C-Quellcodes?
Im Bernd, ~~Ernst~~Felix?

[l] Felix Sun, 19 Apr 2020 09:42:25 GMT Nr. 27389 SÄGE
isdn.briefmarke.png
PNG 1019×610 372.1k
>>27387
Ja, Felix hat auch den Brauser gleich geschloſsen als er das sah. Auf den zweiten Blick jedoch ist die Idee, die Paste mit aes256 zu verschlüſseln und den Schlüſsel im HackfleischteilIch lutsche übrigens gerne Schwänze. PENIS des Elfenjungen mitzuliefern gar nicht so doof, weil der Servierer diesen Teil nicht sieht. Aber irgendetwas ist ja immer.

[l] OP Sun, 19 Apr 2020 14:20:34 GMT Nr. 27394
Ok, hier ist OPs Lösung: https://pastebin.com/raw/gupJwSj5 Sie benutzt einen deterministischen, endlichen Automaten und kommt daher komplett ohne Sprünge aus.
```
FEFE            1.260s
DFA             0.685s
SIMPLE          1.245s
STRCMP0         3.577s
STRCMP1         2.730s
OWN (>>27382)   0.771s
OWNB (>>27382)  0.514s
```
(Die Zahlen sind zwar alle etwas niedriger als letztes mal, vermutlich weil die Lauerstation zwischendrin neugestartet wurde, aber alle Messungen wurden mehrfach durchgeführt und es gab beide Mal so gut wie keine Schwankungen)

Variante B von >>27382 ist tatsächlich bislang die schnellste. Schätze mal, es liegt daran, dass die Schlagwörter relativ selten auftreten und deshalb trotz der gelegentlichen Branch-Mispredictions unterm Strich Arbeit eingespart wird.

[l] Felix Sun, 19 Apr 2020 15:12:12 GMT Nr. 27397
>>27394
an einen DFA hatt ich nicht gedacht, sehr nett!
ich nehm an, dass da die verschachtelten speicherzugriffe noch relevant laufzeit verursachen.
und ja, wenn man wörter >4 zeichen einfach ignoriert, spart man doch ordentlich rechenleistung. da das im original aber auch nicht gemacht wird, gratuliere ich zum besseren code. auch für dich extrabonus für unlesbarkeitmachung eines simplen problems.

[l] Felix Sun, 19 Apr 2020 15:17:28 GMT Nr. 27399
>>27377
Die Überlegung ist, daß der schnellste Durchlauf der ist, bei dem der Computer am wenigsten mit etwas anderem beschäftigt war (Bittorrent, Trojaner, Virenscanner...).

[l] Felix Sun, 19 Apr 2020 15:44:37 GMT Nr. 27401
>>27385
>Wenn du immer nur den schnellsten Durchlauf nimmst, interessiert keine Standardabweichung.
Klingt nach solider Statistik. Wenn man eine klinische Studie unternimmt, reportiert man auch immer nur den gesündesten Patienten.

[l] Felix Sun, 19 Apr 2020 20:51:28 GMT Nr. 27406
>>27382
>ausserdem, wenn man pointer verstanden hat, braucht man auch kein bitweises reinschieben in einem loop.

Vorsicht bei pointers in einen String!

Alles außer char* und void* ist in C undefined behaviour.

Wenn man da zu uint32_t* cast, kann das durchaus abstürzen: https://pzemtsov.github.io/2016/11/06/bug-story-alignment-on-x86.html

>>27387
>Per JavaScript handgefrickelte Krypto?
>Für die Anzeige von ein paar Zeilen irrelevanten aber mikrooptimierten C-Quellcodes?

Das können wir besser. Der C-Quellcode muss in die Blockchain!

[l] Felix Sun, 19 Apr 2020 20:59:46 GMT Nr. 27407
>>27406
>https://pzemtsov.github.io/2016/11/06/bug-story-alignment-on-x86.html
C hält immer wieder Überraschungen parat.

[l] Felix Mon, 20 Apr 2020 00:55:02 GMT Nr. 27410
>>27406
argh drecksundefined, dann mach ich eben eine neue version mit memcpy. immernoch schneller als viermal reinshiften.

[l] Felix Mon, 20 Apr 2020 07:33:02 GMT Nr. 27414
>>27406
>But why didn’t the compiler go straight for movdqu option? Is there any reason to do movdqa at all?
Weil du Sepp dem Compiler gesagt hast, die Daten wären auf 4 Bytes angeordnet! Garbage in, garbage out.

>>27410
Jeder anständige Compiler optimierte kleine memcpy[code/] zu einem/mehreren [code]mov (und umgekehrt: große Kopieraktionen werden zu memcpy). Auf Plattformen, auf denen Alignment egal ist (x86), sogar wenn das Alignment nicht stimmt.

P.S: -fsanitizer=undefined regelt hart.

[l] Felix Mon, 20 Apr 2020 07:54:00 GMT Nr. 27415
>>27394
> kommt daher komplett ohne Sprünge aus.
Felix will ja an dieser wirklich schönen Lösung nicht zu sehr rumkritteln, aber "ohne Sprünge"?
>if (*s == 0)

[l] Felix Mon, 20 Apr 2020 12:40:01 GMT Nr. 27454 SÄGE
>>27415
Naja, die äußere Schleife ist halt immer da, das lässt sich nicht verhindern. Aber innerhalb der Schleife gibt es keine Sprünge. Der Sprung am Ende der Schleife ist auch nicht schlimm, weil er – bis auf das letzte mal – immer genommen wird und deshalb – bis auf das letzte mal – korrekt vorhergesagt wird.

[l] Felix Mon, 20 Apr 2020 13:21:44 GMT Nr. 27456
>>27382
Nitpick: Fefes Variante benutzt isalnum, deine isalpha, Ziffern am Wortende werden also nicht als Teil des Wortes betrachtet.

P.S: Literatur:
https://www.researchgate.net/publication/257472241_Fast_Multiple_String_Matching_Using_Streaming_SIMD_Extensions_Technology
>This study introduces a filter based exact multiple string matching algorithm, which benefits from Intel’s SSE (streaming SIMD extensions) technology for searching long strings. Our experimental results on various conditions show that the proposed algorithm outperforms other solutions, which are known to be among the fastest in practice.

http://0x80.pl/articles/simd-strfind.html
>SIMD-friendly algorithms for substring searching

https://trent.me/is-prefix-of-string-in-table/
>Goal: given a string, determine if it prefix-matches a set of known strings as fast as possible. That is, in a set of known strings, do any of them prefix match the incoming search string?

P.P.S: SSE 4.2 hat String-Verarbeitungsbefehle, die möglicherweise langsam sind, aber vielleicht immer noch schneller als handgeschriebener Code? https://software.intel.com/sites/landingpage/IntrinsicsGuide/#techs=SSE4_2

[l] Felix Mon, 20 Apr 2020 15:28:57 GMT Nr. 27458 SÄGE
>>27456
> Nitpick: Fefes Variante benutzt isalnum, deine isalpha, Ziffern am Wortende werden also nicht als Teil des Wortes betrachtet.
ja, war absicht, hätt ich noch dazuschreiben können. bzw. ich nehm an, dass das keinen guten grund hat, die ziffern mitzuzählen.

> P.P.S: SSE 4.2 hat String-Verarbeitungsbefehle
hab ich mir auch schon angeschaut, war mir zu doof. magst du daraus etwas koten? sonst mach ich mir halt selber nochmals die mühe.

[l] Felix Mon, 20 Apr 2020 15:41:37 GMT Nr. 27461
>>27458
>bzw. ich nehm an, dass das keinen guten grund hat, die ziffern mitzuzählen.
Ich denke schon, damit etwa "DES3" (der etwas betagte Verschlüsselungsalgorithmus) nicht als "des" als Indiz für Deutsch gewertet wird.

>magst du daraus etwas koten? sonst mach ich mir halt selber nochmals die mühe.
Ich passe, will dich aber von nichts abhalten ;_;

[l] Felix Mon, 20 Apr 2020 17:22:46 GMT Nr. 27470
>>27461

> Ich denke schon, damit etwa "DES3" nicht als "des" als Indiz für Deutsch gewertet wird.
ahja, denkfehler. habs bei mir fixiert. aufstelldichein in kürze(tm).

[l] neuer anlauf do i win? Mon, 20 Apr 2020 19:16:45 GMT Nr. 27481
ok, OWN macht jetzt isalnum statt isalpha, OWN2 ist mit fixierter endianness im switch-statement und somit ohne ntoh{s,l}, MCP ist mit memcpy statt pointer-fuckery.
```
FEFE:  1.192s
OWN:   0.923s
OWNB:  0.731s
OWN2:  0.866s
OWN2B: 0.680s
MCP:   1.126s
MCPB:  0.977s
DFA:   0.752s
```
bin schon ziemlich enttäuscht, dass memcpy so viel schlechter abschneidet. wenn ich mir die compiler-ausgabe anschaue, macht der ständig noch paar mov-instruktionen mehr für längenkonvertierung (mov %ecx %al udgl.). hab diverse dinge versucht wie union mit uint32_t und uint8_t[4], im memcpy() zielpointer konvertieren, nicht konvertieren, nach void* konvertieren; half alles nix, immer etwa gleich schnell. wenn jmd optimierungspotenzial sieht OHNE inline-assembly (=cheating), bitte mitteilen.

für universell portablen code ist DFA also momentan die schnellste lösung.

>>27394
wird der code schneller, wenn du das assert weglässt? oder brauchts das? hab den automaten noch nicht 100% verstanden.

für den rekord:
offenbar können alle 3 major compiler mit dem undefined behaviour / missing alignment umgehen:
https://godbolt.org/z/PTooR-

auch: hat jmd im kopf, was unser geliebter geschäftsführer gerade als lieblingskompiler verwendet? der hat das sicher mal pfostiert, so wie ich den kenne. wenns clang ist, muss halt nochmals neu ~~schwanz~~zeitverglichen werden.

[l] anhang vergessen(tm) Felix Mon, 20 Apr 2020 19:18:34 GMT Nr. 27482 SÄGE
>>27481
https://0bin.net/paste/7z81Kdy6xjk+e+CE#cEqObGl1b2MHqw96n9TTY9sqxirh461N37YQn9L-S2e

[l] Felix Mon, 20 Apr 2020 20:14:47 GMT Nr. 27486
>>27481
>wird der code schneller, wenn du das assert weglässt? oder brauchts das? hab den automaten noch nicht 100% verstanden.
Das assert wird nur bei der Initialisierung ausgeführt, ist also irrelevant. Gebraucht wird es natürlich nicht, ich war bloß zu faul, mir zu überlegen, wie viele Tabellen ich genau brauche und habe einfach als Bounds-Check ein assert reingeschmissen, damit es knallt, wenn es zu wenige sind.

>hab den automaten noch nicht 100% verstanden.
Zuerst werden alle Zeichen (0 - 255) auf einen kleineren Bereich (0 - 31) gemappt, um die Zustandstabellen kleiner zu halten. Dabei gilt 1 = A/a, 2 = B/b, ... 26 = Z/z, 31 = Wortgrenze (Interpunktionszeichen, Leerzeichen und Stringende), und dann noch 0 für alles andere.

Es gibt mehrere Tabellen (tables), wobei jede Tabelle einem Zustand entspricht. Die ersten beiden sind reserviert für die Zustände „ungültiges Wort“ also alles, was nicht in der Liste ist, insbesondere Wörter der Länge > 4 (Tabelle 0) und „Wortanfang/Wortende“ (Tabelle 1). Von Tabelle 0 aus zeigt also alles wieder auf Tabelle 0 wenn das Präfix ungültig ist, ist alles was danach kommt auch ungültig, außer es ist ein Interpunktionszeichen oder Leerzeichen, in welchem Fall der Zustand auf Tabelle 1 zurückgesetzt wird. Die restlichen Tabellen entsprechen halt jeweils einem Präfix aus der Wortliste. Präfix + neues Zeichen = neuer Zustand und neuer Score. Alles startet von Tabelle 1.

Noch zu der Score-Berechnung: Ursprünglich war das mit dem Score so gedacht, dass in jedem Schritt einfach nur dazuaddiert wird, wobei der Addend in den meisten Fällen einfach 0 ist (außer am Ende eines erkannten Wortes). Dann fiel mir aber auf, dass bei HvL in der einen Zeile =-10 stand und nicht -=10, wie ich erst dachte, und ich musste es noch mal aufbohren und mask reinfrickeln. Kann man sich als guter Informatiker aber denken, wie das funktioniert.

[l] Felix Tue, 21 Apr 2020 10:18:04 GMT Nr. 27501
>>27482
>// e9d2b99770ed1a0687b6f932c2f11101ed31ec81594b902d70423d49f0126098
>// JkMIlTQx9PBf05qCiz1M4uac43YE1ipx
>// 351843817f6e712ccc21b59643f10c69e14d617d190ffb9e4ef5f19498a84ead
>// d50b5ddc114851e5b0618e45fa6ac35a93dbf5f3a995d104540850b5e1ae8f4b
>// 2889a98df29e10b108538d4766ec8dca229f7d97f9a7cdad001186d7e904f20b
>// d80709176286e0ec93cf77d72e7cecc5989e12478c60e356b156f76f2753f176
>// 2e9df94771aa5347fc071a53f5f56ec1bace715de96d25c5d57631099a6d094b
>// c9d47b9407d87930714d7a611e533cf79ed454159686880dce1442f4b3005324
>// 3dc2c0f0f3d2cd2da1bf910a4154a102799543972f6489a07930c60eaf24ca41
>// bda487a88422d21912fcc1045d0279649c07ae8ae95538da1b8e90f8b734444c
inneressant...

[l] Felix Tue, 21 Apr 2020 18:43:53 GMT Nr. 27539 SÄGE
>>27501
Damit wird Code schneller, basiert auf Orgonit-Technologie. Alternativmedizinische Variante der klassischen Satanismusrituale, die in paralleler Programmierung häufig eingesetzt werden.

[l] SSE do i win? Wed, 13 May 2020 20:23:22 GMT Nr. 28814
Jetzt auch mit SSE4.2. Surprise, SSE macht alles langsamer. Dreckszeugs. Hier meine Timings auf SSE-supportierender CPU:
```
FEFE:     0.321s
STRCMP0: 11.993s
STRCMP1:  1.201s
SIMPLE:   0.447s
OWN:      0.235s
OWNB:     0.187s
OWN2:     0.216s
OWN2B:    0.193s
MCP:      0.244s
MCPB:     0.237s
DFA:      0.586s
SSE:      0.936s
SSEC:     1.332s
SSEC2:    1.071s
SSEC2B:   1.081s
SSES:     0.372s
```
DFA ist hier (andere CPU, andere GCC-Version) deutlich langsamer als FEFE. KA wieso. Ausserdem OWNB und OWN2B praktisch gleich schnell, OWNB sogar 6ms schneller. Ich nehm an, dass der Compiler da die ntohx() besser wegoptimiert.

SSE4.2 ist mühsam, aber wenns jemand doch interessiert, aus dem Code sollte einigermassen ersichtlich sein, wie man das einsetzt. Hat sogar ~~erklärende~~ verwirrende Kommentare. Allerdings hab ich teilweise auch cargocult-mässig Instruktionen verwendet, ohne genau zu wissen, wanns die braucht; insbesondere die unaligned loads für 128bit-Werte.

@OP: Erbitte um Gegentests für Timings.

Nach Eingang von Gegentests werd ich den Herrn Sicherheitsspezialexperten über die Existenz dieses Kodes informieren, wenn @OP nix dagegen hat (ansonsten schick ich nur meine OWNx-Lösungen). Freue mich auf dessen Reaktion.

https://0bin.net/paste/IMPJB0NYJ0qTK3gy#bSvOs+WUyAghcTUBh6h52M-Tw9EbBsbatp/J51xgBQy

[l] Felix Sat, 16 May 2020 14:40:01 GMT Nr. 28930
>>28814
Interessant, das sind ja doch ziemlich andere Ergebnisse. Was ist das für eine CPU?

Entschuldigung für die späte Antwort. Felix konnte sich jetzt erst dazu durchringen, deinen Benchmark laufen zu lassen, weil es hier doch recht lange dauert und Felix natürlich währenddessen keine anderen Programme laufen lassen konnte. Aber hier nun die Ergebnisse:
```
FEFE    1.432s
STRCMP0 4.312s
STRCMP1 3.279s
SIMPLE  1.512s
OWN     0.919s
OWNB    0.628s
OWN2    1.442s
OWN2B   1.454s
MCP     1.030s
MCPB    0.824s
DFA     0.816s
SSE     1.468s
SSEC    1.463s
SSEC2   1.457s
SSEC2B  1.456s
SSES    1.457s
```
>Nach Eingang von Gegentests werd ich den Herrn Sicherheitsspezialexperten über die Existenz dieses Kodes informieren, wenn @OP nix dagegen hat (ansonsten schick ich nur meine OWNx-Lösungen). Freue mich auf dessen Reaktion.
OP hat nichts dagegen.

[l] Felix Mon, 18 May 2020 18:50:37 GMT Nr. 28979
>>28930
Das war Core i7-2640M, also 2nd Gen Mobile i7.
Kompiliert mit gcc 8.3.0.

Erbitte CPU-/Compilerinfo deiner Messungen.

[l] Felix Mon, 18 May 2020 19:52:09 GMT Nr. 28981
>>28979
>Das war Core i7-2640M
Was zum Fick? Ich dachte, das wäre der neueste Ryzen oder so. Deine CPU ist nur ein Jahr jünger als meine. Ob es an unterschiedlichen Stromspareinstellungen liegt?

>Erbitte CPU-/Compilerinfo deiner Messungen.
Core i5-520M / gcc 9.3.0

[l] Selbstsäge Felix Mon, 18 May 2020 20:17:10 GMT Nr. 28983 SÄGE

>>28981
Das hat mir keine Ruhe gelassen, daher habe ich es jetzt nochmal ausgeführt, aber diesmal vorher im BIOS alles auf "Maximale Geschwindigkeit" gesetzt:

         Alt     Neu
FEFE     1.432s  1.183s
STRCMP0  4.312s  3.546s
STRCMP1  3.279s  2.691s
SIMPLE   1.512s  1.094s
OWN      0.919s  0.761s
OWNB     0.628s  0.528s
OWN2     1.442s  0.726s
OWN2B    1.454s  0.447s
MCP      1.030s  0.889s
MCPB     0.824s  0.618s
DFA      0.816s  0.668s
SSE      1.468s  1.197s
SSEC     1.463s  1.599s
SSEC2    1.457s  1.303s
SSEC2B   1.456s  1.276s
SSES     1.457s  0.724s

Erklärt immer noch nicht, warum z.B. FEFE bei dir 4x schneller ist, aber dafür STRCMP0 bei mir 4x schneller.

[l] Felix Mon, 18 May 2020 23:22:27 GMT Nr. 28985 SÄGE
>>28983
Finds auch komisch, dass die einzelnen Messungen teils komplett unterschiedlich sind relativ zueinander.

Gen1 zu Gen2 Core-i war tatsächlich ein ziemlich weiter Sprung. Ich war eher überrascht, als meine erste Messung mit deinen vergleichbar war; die fand noch auf meiner Wegwerfkiste statt mit einem uralten Core2 Duo T7500. Also überrascht weil "da hat tatsächlich einer eine ähnlich alte Kiste am laufen".

Werd mal deine neuen Werte als Referenz übermitteln.

[l] Felix Tue, 19 May 2020 19:32:56 GMT Nr. 29027
>>28981
Vergesst die Firmware der CPU nicht. Die hat auch Auswirkungen auf die Performance (*hust* Spectre-Fixes *hust*).

[l] Felix Sat, 23 May 2020 09:48:56 GMT Nr. 29168
65568749.png
PNG 300×300 76.0k
>>29027
Apropos Firmware: https://twitter.com/_markel___/status/1262697753945108480
>Finally, the casket is opened: we (+@h0t_max and @_Dmit) have extracted Intel x86 microcode! One more Intel "top secret" information gets revealed...
>https://github.com/chip-red-pill/glm-ucode

[l] Felix Sat, 23 May 2020 14:55:09 GMT Nr. 29176
antwort vom Oberfelix steht immer noch aus btw. glaub nicht, dass der noch aufs mail antworten wird. ist halt so eine sache, der beantwortet mails recht zufällig.

[l] Felix Wed, 17 Jun 2020 19:27:45 GMT Nr. 30323
VSWinIcon_100x.png
PNG 200×200 12.5k
Windows-Felix hier.
Für mich riecht das alles sehr stark nach micro benchmark der stark davon abhängt wie warm die caches sind, was der task-scheduler so treibt und mehr.
Man könnte mehr input-Daten auf den Code los lassen, sagen wir, 50mb text.

Trotzdem, der Vollständigkeit halber:

- x64
- i7-8850H
- 1. und 2. Lauf
- strings.h entsorgt, wofür soll das gut sein?

cl /DVARIANT=FEFE /O2 main.c

real 0m0.988s
user 0m0.000s
sys 0m0.031s

real 0m0.813s
user 0m0.000s
sys 0m0.015s

cl /DVARIANT=SIMPLE /O2 main.c

real 0m1.405s
user 0m0.000s
sys 0m0.000s

real 0m1.039s
user 0m0.000s
sys 0m0.015s

cl /DVARIANT=STRCMP0 /O2 main.c

real 0m4.198s <- w00t?
user 0m0.000s
sys 0m0.000s

real 0m3.789s
user 0m0.015s
sys 0m0.000s

cl /DVARIANT=STRCMP1 /O2 main.c

real 0m0.048s
user 0m0.015s
sys 0m0.000s

real 0m0.058s
user 0m0.015s
sys 0m0.015s

Erklärung: FelixBenchmark.exe: RangeChecks instrumentation code detected an out of range array access, steigt aus mit Exception. Die Security-Features müsste man jetzt noch extra abstellen. Felix vermutet die sind auch der Grund wieso STRCMP0 so langsam ist.

[l] Felix Wed, 17 Jun 2020 19:39:43 GMT Nr. 30325
Nachtrag: Wahrscheinlich wäre es schlau den Code zum Zeit nehmen direkt in das Programm zu integrieren. Bei dem kleinen Arbeitspaket entfällt wahrscheinlich auch nicht unwesentlich Zeit auf den Loader und den overhead durch das dynamische Laden der C bibliothek. Oder man linkt statisch...

[l] Felix Wed, 17 Jun 2020 20:34:38 GMT Nr. 30330
>>30323
Danke für deine Messungen. Kannst du die anderen Varianten auch noch testen?

>Erklärung: FelixBenchmark.exe: RangeChecks instrumentation code detected an out of range array access, steigt aus mit Exception.
Das heißt also, wenn Felix es richtig verstanden hat, die Zahlen von STRCMP1 kann man bei dir nicht werten? Wo detektiert VS denn einen Pufferüberlauf?

>Nachtrag: Wahrscheinlich wäre es schlau den Code zum Zeit nehmen direkt in das Programm zu integrieren. Bei dem kleinen Arbeitspaket entfällt wahrscheinlich auch nicht unwesentlich Zeit auf den Loader und den overhead durch das dynamische Laden der C bibliothek. Oder man linkt statisch...
Könnte man machen, aber Felix war zu faul. Der Overhead dürfte bei dem einfachen Programm auch recht gering sein und außerdem ist er für alle Varianten gleich, also ist es immer noch ein fairer Vergleich.

>Man könnte mehr input-Daten auf den Code los lassen, sagen wir, 50mb text.
Würde sicherlich nicht schaden, aber dann wäre der Quellkot auch 50 MB groß, oder man müsste den Text igendwie dynamisch generieren. War einfacher, den Code einfach mehrfach auszuführen.

[l] Felix Wed, 17 Jun 2020 23:15:01 GMT Nr. 30337
>>30330

> Das heißt also, wenn Felix es richtig verstanden hat, die Zahlen von STRCMP1 kann man bei dir nicht werten? Wo detektiert VS denn einen Pufferüberlauf?

Genau, das Programm terminiert nicht korrekt, schätze er fliegt irgendwo recht weit zu Anfang raus. Ich schaue morgen bei Gelegenheit mal wo genau er den out-of-bounds Zugriff entdeckt.
Was mich etwas erstaunt ist dass das überhaupt entdeckt wurde, laut cl Doku schließen sich /O2 und /RTC aus. Mhm. Mal genauer nachforschen.

> Könnte man machen, aber Felix war zu faul. Der Overhead dürfte bei dem einfachen Programm auch recht gering sein und außerdem ist er für alle Varianten gleich, also ist es immer noch ein fairer Vergleich.

Ja vermutlich, habe jetzt auch selbst nicht getestet um das weiter untermauern zu können. Interessant wäre hier in wie weit das die Vergleichbarkeit Windows/Linux beeinträchtigt.

> Würde sicherlich nicht schaden, aber dann wäre der Quellkot auch 50 MB groß, oder man müsste den Text igendwie dynamisch generieren. War einfacher, den Code einfach mehrfach auszuführen.

Wobei ich ab dem 2. Lauf auch nur noch marginale Unterschiede gesehen habe. Ansonsten könnte man als Datensatz ein Buch von Projekt Gutenberg nehmen, die bieten soweit Felix weiß auch plain text als Format an.

[l] Felix Thu, 15 Sep 2022 11:06:21 GMT Nr. 80761
Stoss.

Passwort:

[Zurück]

[c] [meta] [fefe]

Antwort erstellen
Säge
Betreff
Name
Kommentar
Dateien (≤ 4)
Passwort

/c/ – Pufferüberlauf

Antwort erstellen