Eigener Benchmark: CubeCrypt! - BUGFIX mit besserer Performance!

[GBoos]

AW: Eigener Benchmark: CubeCrypt! - Bitte testen und Performance mitteilen!

Mir ist noch, solange wir den Code nicht "begutachten" koennen, die Bedeutung von <Multi-CPU> nicht ganz klar. Sollte es vielleicht <Multi-Core> heissen bzw gemeint sein. Darueber hinaus scheint mir in der Bench-Routine einiges implementiert worden zu sein, von denen "neuere" Prozessoren nicht so richtig profitieren koennen. Aber alles hypothetisch solange wir nicht die Source kennen.

@Mastermaisi777 ....

Deswegen lass uns mal abwarten .... Der Bench muss nicht komisch sein. (PS ... muss mal nachher meine Machine mit Q9650 auf EVGA 790i mit 8GB 1600er reaktivieren ... dann ist es vielleicht vergleichbar). Bist Du 64bit-User oder 32bit-User@ Wenn er schon von vornherein sagt, dass 32bit schneller geht, kann das ebenfalls Einfluss haben. Also abwarten. Nix gleich "komisch" .... Ich bin auf WinServ2008R2Sp1x64 unterwegs.

Hier mal kleines schnelles Update. Mal sehen was bis 5.5 Ghz geht. Weiter war ich noch nicht. Allerdings scheint sich Die Kurve der Abhaengikeit (Taktrate etc) zum Bench-Ergebnis zunehmend zu verflachen. Denn mit 4.
5Ghz war ich genauso schnell. Waere auch mal interessant zu sehen, was ehrliche <Multi-CPU> Set-up's damit anfangen koennen. Muss leider noch auf die Ruecksendung von Anfi-Tec warten. Aber dann .....

 

[GR-Thunderstorm]

AW: Eigener Benchmark: CubeCrypt! - Bitte testen und Performance mitteilen!

So bin zu Hause und hab grad meinen Q6600 durchlaufen lassen , @ 3,8Ghz(denkt euch Multi 9) , der Bench ist wirklich eigenartig
Es sind 4GB RAM verbaut (DDR3).

edit: kleines Update, ein wenig mehr ginge noch , aber ich habe gerade keine Zeit mehr ^^

Hmm in der Tat.... Ich kann mir das nur so erklären, dass der Compiler von VC++2008 nicht ganz optimal auf die Core I5 und I7 ausgelegt ist. Oder den aktuellen Intel CPUs liegen lange Schleifen einfach nicht so....

 

[GR-Thunderstorm]

AW: Eigener Benchmark: CubeCrypt! - Bitte testen und Performance mitteilen!

Mir ist noch, solange wir den Code nicht "begutachten" koennen, die Bedeutung von <Multi-CPU> nicht ganz klar. Sollte es vielleicht <Multi-Core> heissen bzw gemeint sein. Darueber hinaus scheint mir in der Bench-Routine einiges implementiert worden zu sein, von denen "neuere" Prozessoren nicht so richtig profitieren koennen. Aber alles hypothetisch solange wir nicht die Source kennen.

Ehrlich gesagt geht Assemblerprogrammierung über mein Wissen hinaus... Ich habe das Programm nur geschrieben und so wie es war durch den Compiler gejagt. Ich könnte allenfalls mal VC++2010 installieren und damit erneut kompilieren. Dort sollten dann evtl. aktuelle CPUs besser supportet werden.
Ich hatte ein paar Probleme es hochzuladen, aber bald sollte es online stehen.

Wegen Multi-CPU: Ja eigentlich wollte ich es Multi-Core-CPU nennen. Aber (rein theoretisch) sollte es, so wie ich es geschrieben habe, auch auf Systemen mit mehreren CPU-Sockeln laufen.

Ich habe das Programm zum Benchen so eingestellt, dass es mit 8 Threads läuft und habe die Buttons deaktiviert, um dies umzuändern, damit bei den Benches wirklich jeder gleiche Chancen hat. Theoretisch kann das Programm hunderte oder mehr Threads verarbeiten, wenn man die Menge der Würfel entsprechend einstellt.

 

[bingo88]

AW: Eigener Benchmark: CubeCrypt! - Bitte testen und Performance mitteilen!

Du meinst sicherlich "Multi-Threading", oder?

Zum Compiler: Große Performance-Unterschiede sind mir zwischen VC2008 und 2010 nicht aufgefallen, daher würde mich das doch stark wundern.

Zu den Threads: Du hast also immer 8 Threads, egal welche CPU drinnen steckt? Falls ja, hätten wir da auch schon nen potentiellen Performancekiller gefunden.

Edit: Ausgehend von den VC-Runtime Dateien in deinem Archiv hast du den DEBUG Build ausgeliefert. Dieser ist aber x-mal langsamer als der Release Build (hatte schon mal Faktor 100) weil keinerlei Optimierungen durchgeführt werden und enthält außerdem jede Menge Debugging-Informationen wie Runtime-Checks. Also bitte die Projektkonfiguration auf Release umstellen, dann brauchst du auch evtl. diese DLLs nicht mehr mitliefern (werden durch das VC Runtime Packet installiert, braucht man für viele Spiele)

 

[GR-Thunderstorm]

AW: Eigener Benchmark: CubeCrypt! - Bitte testen und Performance mitteilen!

Du meinst sicherlich "Multi-Threading", oder?

Zum Compiler: Große Performance-Unterschiede sind mir zwischen VC2008 und 2010 nicht aufgefallen, daher würde mich das doch stark wundern.

Zu den Threads: Du hast also immer 8 Threads, egal welche CPU drinnen steckt? Falls ja, hätten wir da auch schon nen potentiellen Performancekiller gefunden.

Edit: Ausgehend von den VC-Runtime Dateien in deinem Archiv hast du den DEBUG Build ausgeliefert. Dieser ist aber x-mal langsamer als der Release Build weil keinerlei Optimierungen durchgeführt werden und enthält außerdem jede Menge Debugging-Informationen wie Runtime-Checks. Also bitte die Projektkonfiguration auf Release umstellen, dann brauchst du auch evtl. diese DLLs nicht mehr mitliefern (werden durch das VC Runtime Packet installiert, braucht man für viele Spiele)

Wegen dem Debug-Build siehe hier:
C/C++ Forum :: VC++2008: Andere Compiler-Einstellung --> Extrem niedrige Performance + Rechenfehler?
Ich suche noch nach der genauen Lösung.

Ich kann auch gern erneut eine Version mit 16 Threads oder so liefern.


PS: Codedateien sind online! Im Startpost steht der Downloadlink.

 

[GBoos]

AW: Eigener Benchmark: CubeCrypt! - Bitte testen und Performance mitteilen!

Du meinst sicherlich "Multi-Threading", oder?

Zum Compiler: Große Performance-Unterschiede sind mir zwischen VC2008 und 2010 nicht aufgefallen, daher würde mich das doch stark wundern.

Zu den Threads: Du hast also immer 8 Threads, egal welche CPU drinnen steckt? Falls ja, hätten wir da auch schon nen potentiellen Performancekiller gefunden.

Edit: Ausgehend von den VC-Runtime Dateien in deinem Archiv hast du den DEBUG Build ausgeliefert. Dieser ist aber x-mal langsamer als der Release Build (hatte schon mal Faktor 100) weil keinerlei Optimierungen durchgeführt werden und enthält außerdem jede Menge Debugging-Informationen wie Runtime-Checks. Also bitte die Projektkonfiguration auf Release umstellen, dann brauchst du auch evtl. diese DLLs nicht mehr mitliefern (werden durch das VC Runtime Packet installiert, braucht man für viele Spiele)

 

[bingo88]

AW: Eigener Benchmark: CubeCrypt! - Bitte testen und Performance mitteilen!

Wegen dem Debug-Build siehe hier:
Ich kann auch gern erneut eine Version mit 16 Threads oder so liefern.

Ich meinte eher das Gegenteil
Angenommen du hast nen Dualcore und ein Programm das 4 Threads intensiv rechnen lässt. Was passiert? Es dauert länger, als wenn nur zwei Threads arbeiten würden! Warum? 4 Threads müssen auf 2 Kerne verteilt werden, das kostet halt zusätzliche Performance (vereinfacht ausgedrückt, bin atm zu faul das detailiert zu beschreiben ^^)

Edit: Sehe mir gerade mal den Code an...

 

[MrSniperPhil]

AW: Eigener Benchmark: CubeCrypt! - Bitte testen und Performance mitteilen!

Moin, habs mir auch mal geladen und ausprobiert...
Ergebnisse:
Benötigte Sekunden zum Verschlüsseln: 20,498 mit Multi-Thread ohne Rekursiv
Benötigte Sekunden zum Verschlüsseln: 20,577 mit Multi-Thread mit Rekursiv
Ohne Multi-Thread hängt sichs bei mir auf...
Sys in der Signatur, OS is Win7 64 bit
PS: Nebenbei liefen noch Steam (Download) und FF
MfG

 

[bingo88]

AW: Eigener Benchmark: CubeCrypt! - Bitte testen und Performance mitteilen!

So, ich kann schon mal bestätigen, dass der Debug Build hier tatsächlich schneller ist (VC2010). Das darf eigentlich nicht sein, daher ist irgendwo ein "Fehler". Mir ist allerdings noch nichts aufgefallen, beim ersten drübergucken.

 

[GR-Thunderstorm]

AW: Eigener Benchmark: CubeCrypt! - Bitte testen und Performance mitteilen!

Ich meinte eher das Gegenteil
Angenommen du hast nen Dualcore und ein Programm das 4 Threads intensiv rechnen lässt. Was passiert? Es dauert länger, als wenn nur zwei Threads arbeiten würden! Warum? 4 Threads müssen auf 2 Kerne verteilt werden, das kostet halt zusätzliche Performance (vereinfacht ausgedrückt, bin atm zu faul das detailiert zu beschreiben ^^)

Edit: Sehe mir gerade mal den Code an...

Also sollte ich das Programm so programmieren, dass die Threadzahl auf die Anzahl der CPU-Kerne angeglichen wird?

Edit: Gerade mal getestet.

4 * 1 Thread: 70 Sekunden
4 * 2 Threads: 41 Sekunden.
4 * 3 Threads: 38 Sekunden

Der Geschwindigkeitszuwachs wird immer geringer (habe ja auch nur 4 Kerne in meinem Lappy mit Llano 3410MX).

 

[bingo88]

AW: Eigener Benchmark: CubeCrypt! - Bitte testen und Performance mitteilen!

Also sollte ich das Programm so programmieren, dass die Threadzahl auf die Anzahl der CPU-Kerne angeglichen wird?

ja, wäre besser.

Zum Geschwindigkeitszuwachs: Das hängt davon ab, wie gut du parallelisierst und wie gut das Problem an sich parallelisiert werden kann (Amdahl's Law)

 

[GR-Thunderstorm]

AW: Eigener Benchmark: CubeCrypt! - Bitte testen und Performance mitteilen!

ja, wäre besser.

Zum Geschwindigkeitszuwachs: Das hängt davon ab, wie gut du parallelisierst und wie gut das Problem an sich parallelisiert werden kann (Amdahl's Law)

Jeder Thread (abgesehen vom "Manager") führt exakt die gleichen Aufgaben durch, nur eben an einem jeweils anderen Würfel.

 

[Mastermaisi777]

@Mastermaisi777 ....

Deswegen lass uns mal abwarten .... Der Bench muss nicht komisch sein. (PS ... muss mal nachher meine Machine mit Q9650 auf EVGA 790i mit 8GB 1600er reaktivieren ... dann ist es vielleicht vergleichbar). Bist Du 64bit-User oder 32bit-User@ Wenn er schon von vornherein sagt, dass 32bit schneller geht, kann das ebenfalls Einfluss haben. Also abwarten. Nix gleich "komisch" .... Ich bin auf WinServ2008R2Sp1x64 unterwegs

Komisch war keineswegs negativ gemeint, nur hats mich ein wenig erstaunt dass eine relativ alte CPU mit weniger Takt wesentlich neuere CPUs schlägt.
Ich hoffe ich schaffe es morgen mal den Intel Compiler zu testen.

Ich bin auf win 7 x64, sollte der gleiche Kernel sein wie unter server 2k8.

 

[GR-Thunderstorm]

AW: Eigener Benchmark: CubeCrypt! - Bitte testen und Performance mitteilen!

Ich bin auf win 7 x64, sollte der gleiche Kernel sein wie unter server 2k8.

Server 2008 = Vista
Server 2008 R2 = Win7


Ich arbeite an einer Erweiterung, die automatisch die Anzahl der CPU-Kerne ausliest und die Threads entsprechend einstellt. Den größten Geschwindigkeitsboost scheint es zu geben, wenn die Anzahl der Threads dem doppelten der CPU-Kerne entspricht. Wenn beide Werte gleich sind, wird die Leistung (zumindest auf meinem Rechner) nahezu halbiert.

 

[GBoos]

AW: Eigener Benchmark: CubeCrypt! - Bitte testen und Performance mitteilen!

Komisch war keineswegs negativ gemeint, nur hats mich ein wenig erstaunt dass eine relativ alte CPU mit weniger Takt wesentlich neuere CPUs schlägt.
Ich hoffe ich schaffe es morgen mal den Intel Compiler zu testen.

Ich bin auf win 7 x64, sollte der gleiche Kernel sein wie unter server 2k8.

Ich habe das auch gar nicht so negativ aufgefasst

 

[Sonntagsfahrer]

AW: Eigener Benchmark: CubeCrypt! - Bitte testen und Performance mitteilen!

Benchmark ohne "MultiCPU" - und ohne "Rekursiv" - Option: 59,623 Sekunden (Verschlüsselung: 59,514)
Benchmark mit "MultiCPU" - und ohne "Rekursiv" - Option: 18,392 Sekunden (Verschlüsselung: 18,283)

CPU Multi14,5 * 269FSB = 3900,4Mhz HT2421Mhz RAM 717

Gleich geht es erstmal nach Hamburg aber Sonntag nacht bin ich ja wieder da also Montag mal weiter testen mit
bisschen mehr Takt

 

[bingo88]

AW: Eigener Benchmark: CubeCrypt! - Bitte testen und Performance mitteilen!

Jeder Thread (abgesehen vom "Manager") führt exakt die gleichen Aufgaben durch, nur eben an einem jeweils anderen Würfel.

Gut, in dem Fall müsste es relativ brauchbar skalieren. Du hast bei Multi-Core allerdings das Problem, dass jeder Core auf denselben Speicher zugreifen muss (ist bei Multi-CPU anders; NUMA - non-uniform memory architecture). Sprich, es kann z. B. der Speicherzugriff irgendwann der limitierende Faktor sein - und Amdahls Gesetz

 

[GBoos]

AW: Eigener Benchmark: CubeCrypt! - Bitte testen und Performance mitteilen!

Ich denke so lange die Bench-Routine nicht die jeweilige CPU richtig skaliert, bringt ein Bench relativ wenig. Bin mal auf die Ergebnisse gespannt nach dem Fix.

Viel Glueck.

 

[GR-Thunderstorm]

AW: Eigener Benchmark: CubeCrypt! - Bitte testen und Performance mitteilen!

Bisher habe ich es soweit gefixt, dass beim Benchen die Anzahl der Threads auf den jeweiligen Prozessor angepasst werden. Ich weiß nur leider nicht, wie sich das bei Intel-CPUs mit SMT verhält...

Generell habe ich festgestellt, dass die Performance fast doppelt so hoch ist, wenn man die Anzahl der Würfel verringert und gleichzeitig die Kopien pro Würfel erhöht. Kurz gesagt: 2*4 Würfel liefert mehr Leistung als 4*2. Deshalb habe ich es so programmiert, dass die Anzahl der Würfel fortan "2" beträgt und die Anzahl der Kopien nun der Anzahl der CPU-Kerne.

Das Programm ist leider noch im Teststadium und ich hatte leider nicht die Möglichkeit, es auf vielen unterschiedlichen Systemen zu testen, um zu sehen, wo es am besten performt.

Ich stelle die aktuelle Version am besten mal online und ihr probiert, wie sie jetzt performt. Wenn ich die aktuelle Performance des Programms auf meinem Lappy mit der Bestenliste vergleiche, wäre ich etwa auf dem ersten Platz und mit der zuvor hochgeladenen Version brauche ich etwa doppelt so lang im Benchmark.

 

[GBoos]

AW: Eigener Benchmark: CubeCrypt! - Bitte testen und Performance mitteilen!

Im Grunde genommen kannst Du eigentlich nur die CPU's je nach Spezifikation unterteilen und dann untereinander vergleichen. Solange

Generell habe ich festgestellt, dass die Performance fast doppelt so hoch ist, wenn man die Anzahl der Würfel verringert und gleichzeitig die Kopien pro Würfel erhöht. Kurz gesagt: 2*4 Würfel liefert mehr Leistung als 4*2.

Sieht fuer mich nach fehlerhafter Parallelisierung aus.