Befehlssätze heutiger Cpus

Xanari

Lt. Junior Grade
Registriert
Okt. 2010
Beiträge
287
Hallo,
ich habe folgende Frage und zwar was bringen die zusätzlichen Befehlssätze die Sandy Bridge haben oder Bulldozer jetzt bringt? Weil ein 5 Jahre alter Prozessor läuft ja auch und in tests wird nie verwiesen das es wegen dieses Befehlsätzen ist.
Bedanke mich jetzt schon mal für antworten.
 
Warum wird wohl ein AMD X6 mit 3,3GHz von einem Sandy mit nur 2,5GHz leicht abgehängt?

Am Takt kann es ja nicht liegen und der Sandy hat sogar noch 2 Kerne weniger.
Dafür können aktuelle AMD CPUs kein SSE4.1, kein SSE4.2 und kein AVX (auch wenn das momentan keine Rolle spielt).

Erst mit BD wird AMD bei den Befehlssätzen gleichziehen bzw. mit FMA sogar vor Intel liegen (da kommt das erst mit Haswell, also der Generation nach Ivy).
 
Ach also ist das eigentlich so die neuerungen Grundlegend in der Architektur. Deswegen sind in den Test die kleinen Sandy ohne AES so abgeschlagen. Aber in welchen Szenarios bringt den AES was?
 
AES beschleunigt nur die Verschlüsselung (z.B. mit TrueCrypt ab Version 7.0).

Aber auch wenn man nur Spiele nimmt, liegt der i5-2400S vor dem X6 1100T, obwohl er nur mit 2,5GHz taktet und 2 Kerne weniger hat. Man kann also Spiele speziell auf Intel optimieren und dann liegt eine AMD CPU eben hinten.

Genauso kann man auf mehr als 4 Kerne optimieren und dann kann ein X6 vor einem Intel Quadcore landen.
 
Aso, ok danke hab das jetzt verstanden^^
 
was bringen die zusätzlichen Befehlssätze die Sandy Bridge haben

Wobei man ganz klar sagen muss: neue Befehlsätze bringen nur dann etwas, wenn die Programme diese explizit ansprechen (und dafür auf bisherige Algorithmen / Befehle verzichten) - höhere Geschwindigkeit durch neue Befehlssätze ist kein Automatismus.
Bei SSE(1) hat das noch Jahre gedauert und erste optimierte Programme lagen bei geschätzt+10% Performance.

Tools die Hardware-AES nutzen kannste an einer Hand abzählen - per GPU (CUDA / OpenCL) geht das noch mehrfach schneller, muss aber ebenfalls aufwendig neu programmiert werden.

Bei SSE-Befehlen über Version SSE3 sieht das ähnlich aus.

Warum wird wohl ein AMD X6 mit 3,3GHz von einem Sandy mit nur 2,5GHz leicht abgehängt?
Zum einen hängt der Vergleich etwas, weil im verlinkten Szenario beide CPUs öfter im Turbotakt 3,7GHz vs. 3,2 GHz arbeiten und kaum neuere Befehle zum Einsatz kommen. (Intel CPUs seit dem Nehalem i7 arbeiten praktisch NIE bei Nominaltakt!)
Die höhere proTakt (IPC) Leistung gegenüber älteren CPU-Generationen wird durch Verbesserungen in der Verarbeitung älterer Befehle, schnellerer Speichercontroller und besserer Anknüpfung der Funktionseinheiten untereinander (z.B. Ringbus) erreicht.

Hier hat Intel in den letzten Jahren mehr investiert und ist auch ohne Nutzung neuerer Befehle im Schnitt 30% schneller (Sandy Bridge vs. AMD PhenomII).

Wie das Ranking aussieht, wenn das Potential beider Prozessoren voll ausgeschöpft wird sieht man eher bei den Multithreading Benchmarks (und dann stimmt auch der Taktvergleich mit 6x3,3 GHz vs. 4x2,6 GHz wieder).
Immer noch wenig schmeichelhaft für AMD aber immerhin nachvollziehbar.;)

Cinebench R11.5
Autodesk 3ds Max 2011 und MainConcept H.264/AVC Pro
 
Zuletzt bearbeitet:
Xanari schrieb:
Aber in welchen Szenarios bringt den AES was?

verschlüsselte Verbindungen deines Browsers mit deiner Bank basieren z.B. auf AES (und RSA um den AES-Key zu verschlüsseln).

Sunnyvale schrieb:
Wobei man ganz klar sagen muss: neue Befehlsätze bringen nur dann etwas, wenn die Programme diese explizit ansprechen (und dafür auf bisherige Algorithmen / Befehle verzichten) - höhere Geschwindigkeit durch neue Befehlssätze ist kein Automatismus.
Bei SSE(1) hat das noch Jahre gedauert und erste optimierte Programme lagen bei geschätzt+10% Performance.
solche neuen Befehlssätze werden heute aber viel schneller in Compiler eingebunden ;) Die Entwickler hinter dem gcc sind da z.B. recht flott.
Somit liegt es nur noch an den Entwicklern die Software auch mit den Optionen zu kompilieren.
 
Also zum einen wird bei der Webseite der Banken ganz bestimmt nicht Hardware AES verwendet ( Tut mir leid, aber dafür muss einfach ein :lol: herhalten )
Und dazu kommt das zum einen grade bei Spiele und anderer Kommerzieller Software oft der Intel C/C++ Compiler genutzt wird oder aber die .NET bzw. Java Plattform.
Außerdem bringen neue Befehlssätze wie SSE 4.1 natürlich nur in bestimmten Szenarien etwas.

Das Intel eine höhere IPC hat ist Architektur bedingt und hat weniger etwas mit den Befehlssätzen zu tun.
 
Fonce schrieb:
Also zum einen wird bei der Webseite der Banken ganz bestimmt nicht Hardware AES verwendet ( Tut mir leid, aber dafür muss einfach ein :lol: herhalten )

du willst nicht verstehen was ich sage oder?
Sowohl der Server der Bank als auch dein Browser müssen die Verbindung mit AES verschlüsseln, und dein Browser wird da Hardware-AES einsetzen, wenn man es implementiert oder die Windows-Crypto-Funktionen nutzt, denn da ist es schon drinne.
Und Banken verwenden sehr wohl Hardware AES!
Aber nicht von so "popeligen Intel CPUs" sondern von spezialisierten PCIe-Karten dafür.

Fonce schrieb:
Und dazu kommt das zum einen grade bei Spiele und anderer Kommerzieller Software oft der Intel C/C++ Compiler genutzt wird oder aber die .NET bzw. Java Plattform.
Da der Intel-Compiler schweineteuer ist, gibt es sehr viel Software, die nicht mit diesem kompiliert wird. Vor allem bei OpenSource-Projekten oder kleine Software.
Bei der .NET-Platform weiß ich nicht, wo dort die Crypto-Algorithmen herkommen, aber ich habe die starke Vermutung, dass diese direkt aus der Windows-Crypto-API kommen, die bereits AES-NI kann.
Bei Java wird es noch länger dauern, bis AES-NI supportet wird, da gibt es aber bereits erste Projekte, die ein JNI-Wrapper einsetzen um mit C AES-NI zu nutzen.
 
webseiten sind jetz aber nicht gerader gigantische datenmengen die von hardwarebeschleunigung profitieren. die geschwindigkeit aktueller AES implementierungen reicht sogar ohne beschleunigung für eine einzelne schnelle festplatte aus, da zieht dann aber das stromspar- und multitaskingargument. aber für läppisches ssl musste ich noch nie spürbar länger warten.

PS: ich möchte auch anmerken dass die performance/takt im vergleich nehalem/K10.5 bei weitem nicht an den befehlssätzen sondern an den schaltungen ansich liegt, latenz- und durchsatzoptimierung vom feinsten. hängt natürlich immer sehr davon ab was man damit genau anstellt.
 
Zuletzt bearbeitet von einem Moderator:
Zurück
Oben