Benchmarkergebnisse, Teilnehmer Benchmark gesucht

[larslrs]

3.1s auf dem i3.

L4-Cache würde mich noch interessieren. Schaut so aus, als ob Python (bei den bisher getesteten Systemen) nur wenig Nutzen aus dem Cache ziehen kann.

Ich werde die Ergebnisse etwas sortieren im ersten Post.

 

[larslrs]

@gaussmath:
sind die Threadripper 54.8s (python3) und die 13.3s (csV1) auch nur mit 16MByte L3-Cache, oder mit mehr? Siehe erster Post.

 

[gaussmath]

Das war mit Legacy=On. Voll aktiviert ist der TR leicht langsamer.

 

[Olstyle]

Mal der Bratwell i5 mit und ohne Spectre. Da der L4 nur Victim-Cache ist dürfte er für die Anwendung hier nicht soo spannend sein, schließlich liegt der Witz im Programm ja darin dass es Daten nicht mehrfach nutzt.

 

[larslrs]

Mal der Bratwell i5 mit und ohne Spectre. Da der L4 nur Victim-Cache ist dürfte er für die Anwendung hier nicht soo spannend sein, schließlich liegt der Witz im Programm ja darin dass es Daten nicht mehrfach nutzt.

Interessante Ergebnisse.
...wobei das Problem aber in den L4-Cache passen würde und dies der Laufzeit durchaus zuträglich sein könnte, insofern die Cache-Lines nicht gelöscht werden.

 

[Olstyle]

Generell sind interpretierte Sprachen und JIT nicht gerade ideal für sowas da noch ein unbekannter Anteil Runtime dazu kommt. Nur so zum Spaß hab ich es gerade auch mal auf einem MotoZ Play laufen lassen.https://uploads.tapatalk-cdn.com/20180716/72a6241e37e5c5255c2f238ef7159ccb.jpg

 

[larslrs]

Mir geht es jedoch nicht um Längenvergleich, sondern um die Vergleichbarkeit von RealeWelt-Szenarien. Ich nutze viel Python. gaussmath nutzt c#.
Man kann das Python-Script auch vorkompilieren, dann wäre es schneller. Dann kann man noch dies und jenes machen...oder den Algo Cache-freundlich umschreiben, usw. ...oder man bemüht sich um Computer, die Python-Scripte "schnell" ausführen. Teilweise kann man raten, was nutzbringend ist, aber Performance-Vergleiche sind auch sehr hilfreich.

 

[Olstyle]

Der 5675 läuft übrigens @Stock (Dank H97 geht auch nichts Anderes), boostet also auch über die 3,1GHz hinaus (bis 3,6GHz).

 

[gaussmath]

Ich verstehe nicht, warum der TR bei der 16MB Variante so viel schneller ist, bei der 64MB Variante hingegen deutlich langsamer.

 

[_LS_]

Hab die SC_bench_memcs16mb.exe bei mir mal getestet (11 Durchläufe in kurzen Abständen):
(Davor hab ich mal mit Hintergrundprogrammen getestet und hatte etwa 0,3s mehr)

Mittelwert: 2,673805064s
Minimum: 2,5925139s
Maximum: 2,8438305s

System: Windows 10 (Build 1803), CPU: i7 6700k@4,3GHz(Allcore), Cache@4,2GHz, RAM: DDR4@2400MHz CL14-14-14-36-1T



Morgen teste ich nochmal die anderen Varianten

 

[cann0nf0dder]

das python script will leider nicht wie HisN schon geschrieben hatte, Ubuntu Server 16.04

 

[amdahl]

Sehe ich richtig dass der Benchmark letzten Endes zufällige Speicherzugriffe testet? Bzw. ob das ganze Array in den Cache passt? Bei einer Sprungweite von maximal 255 bencht man zusätzlich was der Hardware-Prefetcher macht.

Das würde auch erklären warum der Threadripper mit einem 16MB Array deutlich schneller ist als mit 64MB. Die 16MB passen in den L3-Cache eines einzelnen dies, 64MB eben nicht mehr.

 

[gaussmath]

Das würde auch erklären warum der Threadripper mit einem 16MB Array deutlich schneller ist als mit 64MB. Die 16MB passen in den L3-Cache eines einzelnen dies, 64MB eben nicht mehr.

Aber genau auf Kante? Es liegen doch noch andere Daten im L3.

 

[amdahl]

Selbst wenn das Array nicht komplett rein passt betrifft es vielleicht ein paar Prozent der Zugriffe. Das macht den Kohl wirklich nicht fett so wie der Algorithmus arbeitet.

 

[gaussmath]

Selbst wenn das Array nicht komplett rein passt betrifft es vielleicht ein paar Prozent der Zugriffe. Das macht den Kohl wirklich nicht fett so wie der Algorithmus arbeitet.

Ok, dann teste ich jetzt nochmal die 64MB Variante mit 2400Mhz RAM Takt und geringen Latenzen.

 

[larslrs]

das python script will leider nicht wie HisN schon geschrieben hatte, Ubuntu Server 16.04

Du sollst Python ab Version 3.5 nehmen. Steht im Eingangspost, im Sourcecode und im Dateiname.

Ich arbeite sonst ja auch mit dem 2er. Aber gab bereits Leute, die nur das 3er installiert haben. Deshalb habe ich eine 3er Version gemacht. Durchläufe mit 2er und 3er sind nicht vergleichbar. Für das eine Script kann mal man schon mal das 3er starten

 

[gaussmath]

Ok, dann teste ich jetzt nochmal die 64MB Variante mit 2400Mhz RAM Takt und geringen Latenzen.

Das läuft quasi mit dem Faktor 2400/3466 schlechter... Ich kapier's nicht.

 

[larslrs]

Das läuft quasi mit dem Faktor 2400/3466 schlechter... Ich kapier's nicht.

Da bräuchte es nun noch die Zeiten für cycles={128,256,512,1024}

EDit: ne, moment. Passt doch. Ich sehe bei Dir kaum noch durch. Poste doch mal bitte immer komplett, was Du hast gerade laufen lassen sowie im Vergleich vollständig dazu, was unstimmig ist.

 

[gaussmath]

Da bräuchte es nun noch die Zeiten für cycles={128,256,512,1024}

Ich fange morgen an mit einer UI und biete diese Option an + Thread Pinning. Fällt dir noch was ein, was die UI können sollte?

 

[larslrs]

Fällt dir noch was ein, was die UI können sollte?

Per CLI benutzbar bleiben.