Einloggen
[c] [test] [fefe]

/c/ – Pufferüberlauf


Antwort erstellen

(≤ 4)



[Zurück]

  • [l] Wir optimieren Fefes Blog Felix Sat, 18 Apr 2020 02:48:34 GMT Nr. 27355
    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, ErnstFelix?
  • [l] Felix Sun, 19 Apr 2020 09:42:25 GMT Nr. 27389 SÄGE
    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 schwanzzeitverglichen 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
    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.


[Zurück]
[c] [test] [fefe]