DerGoldeneMesia
Enthusiast
- Mitglied seit
- 21.05.2007
- Beiträge
- 4.439
Na seh ich nicht ganz so, wenn ein smartphone was kann würde ich auch 400 Euro ausgeben.
AMD Carrizo - Kaveri-Nachfolger im Detail
- Ersteller iToms
- Erstellt am
Na seh ich nicht ganz so, wenn ein smartphone was kann würde ich auch 400 Euro ausgeben.
mir ist grad aufgefallen das computerbase die steamroller kerne nachträglich mit den Piledriver kernen verglichen haben.
AMDs APU
vereinzelt gleiche ipc, aber auch mal bis zu 24% mehr ipc, 7% mehr ipc im durchschnitt. (alles jeh nach anwendung halt)
also das man in vielen anwendungen (zb games) +10% ipc durch die neue architektur bekommt, ist schon was feines.
um so interessanter wird die 4rte generation des bulldozer weil sich ja quasi keiner den steamroller kauft, und die meisten von Phenom/Bulldozer/Piledriver auf Excavator wechseln werden. wenn excavator nochmal so einen ipc sprung hinlegt wie amd es schon bei der 2ten und 3ten gen geschaft hat, kann sich das schon sehen lassen mit dem neuen fertigungs prozess.
fehlt nur noch das amd dann auch mal wieder pure CPU,s macht, und keine APU,s die das takt potential verringern.
@ Asuka. D finde die signatur störend. würdest mir damit einen gefallen tun wenn du eine andere verwenden würdest
AMDs APU
vereinzelt gleiche ipc, aber auch mal bis zu 24% mehr ipc, 7% mehr ipc im durchschnitt. (alles jeh nach anwendung halt)
also das man in vielen anwendungen (zb games) +10% ipc durch die neue architektur bekommt, ist schon was feines.
um so interessanter wird die 4rte generation des bulldozer weil sich ja quasi keiner den steamroller kauft, und die meisten von Phenom/Bulldozer/Piledriver auf Excavator wechseln werden. wenn excavator nochmal so einen ipc sprung hinlegt wie amd es schon bei der 2ten und 3ten gen geschaft hat, kann sich das schon sehen lassen mit dem neuen fertigungs prozess.
fehlt nur noch das amd dann auch mal wieder pure CPU,s macht, und keine APU,s die das takt potential verringern.
@ Asuka. D finde die signatur störend. würdest mir damit einen gefallen tun wenn du eine andere verwenden würdest
Stechpalme
Enthusiast
Traurig, dass die aktuellsten CPUs nicht an den alten X4 vorbeiziehen können.... XD. Da helfen selbst 30% mehr IPC nicht um mit Intel aufzuschließen.
poeci
Enthusiast
kennst du soundkarten?
aktuell ist die 3te generation IPC technisch mindestens auf Phenom II niveau. auch mal drüber, aber mindestens halt gleich schnell pro takt. das ist für die modulbauweise echt gut. im vergleich zu Intel fehlen halt leider noch 40% IPC.
Stechpalme
Enthusiast
Ok, die IPC des FX mit dem X4 direkt zu vergleichen aufgrund der Modulbauweise ist kaum wirklich möglich. Aber die reine IPC ist eben Intel leider noch zu weit hinter her.
Dies ist nicht korrekt, habe ich selbst mehrfach gemessen auf meinem Benchtable: Sie hinkt immernoch ~ 5% zurück. Dafür gibts einen klaren Taktvorteil. Von Intel ist AMD Lichtjahre entfernt bei gleichen Takt, dort sind es auf Haswell ~ 50%.
Zuletzt bearbeitet:
hm evtl waren die bulldozer bei deinen programmen schlechter.
schau mal die average gaming performance
2te generation FX4350 läuft mit 4200 mhz. der X4 ohne L3 (athlon) ist mit 4300 mhz deutlich unterlegen. der 4 ghz Phenom II mit L3 ist knapp langsamer.
und die 3te Bulldozer gen legt wie gesagt laut Computerbase noch bis zu 24% mehr ipc jeh nach software oben drauf (im schnitt 7%). somit wären das 30-50% jeh nach software die zu intel fehlen.
Habe @4 GHz einen FX6300 vs PII X4 955 in Cinebench (Single Thread) verglichen auf identischen Board, SSD, RAM (gleicher Takt und Timings) unter Windows 8.1 und der FX6300 ist von der IPC definitiv langsamer als der PII X4 955 und dies gerundet ~ 5%.
Was ist da deutlich unterlegen!?
Ich sehe dort 137% avg. für den 4GHz 965BE und 141% für den stock 4350. -> der wohl noch nen Turbo oben drauf aktiv hat.
Das ist ein Unterschied von 2% -> was man schon fast als Messtoleranz abtun kann. Bei 5% Taktunterschied + Turbo!
Auch stellt sich die Frage nach dem OC. Mit NB OC? Oder ohne... Unter welchen Bedinungen und wie und was wurde eingedreht!? -> solch ein Vergleich hinkt idR irgendwie...
Nimmt man aus deinem obigen CB Review die Turbobereinigten 3,7GHz Werte, legt Kaveri ca. 6% im Schnitt auf Piledriver zu. Nur findet sich dort auch ein Stock 965BE mit 3,4GHz und aktivem Turbo -> der auf den Kaveri schon 7% mehr Spieleperformance liefert. Und auf Piledriver 13% mehr.
Das ist zwar durchaus Phenom II Niveau, aber es ist schon für die IPC Sprünge der letzten Jahre zwischen den Generationen ziemlich viel Unterschied. Und das immernoch. Denn die Technik des 965BE ist im Grunde "Asbach" und gibts seit Anfang 2009! Das sind fünf Jahre und es bewegt sich aktuell kein Stück nach oben...
cinebench ist Bulldozer natürlich schwach. aber cinebench ist auch kein IPC maßstaab bench. IPC kann jeh nach software anders ausfallen. und cinebench ist quasi das worst chase szenario für BD. daher eig doch eine gute leistung.
genauer lesen
ich schrieb das hier
mein unterlegen bezog sich also nicht auf den Phenom.
sehe ich anders. du vergleichst nun IPC. Bulldozer war nie für hohe IPC ausgelegt, sondern für Hohe Leistung Pro Watt. also Effizienz. und Bulldozer ist defenetiv Effizienter als Phenom. ob das jetzt an den 32nm oder am design liegt, will ich aber nicht beurteilen
Phenom II war die ausgereifte ausbaustufe des K8, und Bulldozer in 32nm (2te gen) hat noch viele flaschenhälse. die effizenz des designs wird noch zum vorschein kommen, da bin ich sicher. evtl wird Intel das modul konzept grob eines tages auch übernehmen, wer weiß.
Zuletzt bearbeitet:
Das Gegenteil ist eigentlich der Fall. Der Cinebench zeigt sehr gut, wo der Hase lang läuft... Das BD darin keine gute Figur macht zeigt doch gerade, das die IPC Leistung eben nicht sooo gut ist. Was man ein Stück weit mit Takt kompensiert. Aber eben auch nur ein Stück weit. Gerade der SingleThread Wert profitiert noch gut vom Turbo.
Die Frage ist eher, was definierst du als IPC?
Ich muss da nicht genauer lesen. Denn die Aussage wird dadurch nicht richtiger...
Du musst deine Prozentrechnung nochmal überdenken. Deutlich ist was anders. Es sind 3% für den X4 750K -> was Trinity und somit BDv2 ist. Der 4350 ist Vishera und somit ebenso BDv2. Nur eben mit L3 Cache und eine andere Plattform.
Das ist Messtoleranz gepaart mit dem OC Unsicherheitsfaktor, da wir nicht wissen, was alles eingedreht wurde. Auch beim 4350 könnte der Turbo aktiv gewesen sein!? Oben drauf kommt der L3 Cache, der mal mehr, mal weniger stark Performance bringt.
Zuletzt bearbeitet:
ah ok danke. dachte das war k10,5.
wenn das so wäre, hätte CB keine unterschiede von 6-24% IPC bei unterschiedlichen programmen im vergleich zwischen BD MK2 & BD MK3 gehabt.
IPC mit singlethread benchs kann ganz anders sein als mit multi core benchs.
Sie treten seit 5 Jahren auf der Stelle was Leistung pro Takt betrifft. Der Mangel an Leistung wird derzeit nur durch hinzufügen von Modulen kompensiert, folglich höheren Verbrauch. Weitere Vorraussetzung ist, die Software muss gut Multithreaded optimiert sein, sonst verpufft das Leistungsplus, weil die Mehrzahl an Threads nicht genutzt wird. Cinebench R15 ist ein guter Indikator für die Single bzw. Multithreaded IPC der CPU.
Zuletzt bearbeitet:
Mick_Foley
Semiprofi
- Mitglied seit
- 10.02.2008
- Beiträge
- 15.045
Was der Punkt ist, wo AMD mit dem Prinzip halt auf die Fresse fällt.
Aber das Kind ist eh schon längst im Brunner ersoffen, ohne Konsolen-Chips würde AMDs x86-Marktanteil wohl eher noch gesunken sein. Bleibt zu hoffen, dass AMD sich zumindest auf dem Level der Vier-Threader etwas erholen kann, nur leider klafft da eine immense Lücke zwischen Kabini und den beiden Kaveris, die bei dem Preis schon fas Werbung für Intel machen. Schaun mer mal...Neja wenn in einzelnen Programmen die Unterschiede mal größer oder mal weniger groß ausfallen liegt das wohl daran, das es verschiedene CPUs mit verschiedenen Bedinungen sind. Manch eine Software skaliert stark über den L3 Cache, andere gar nicht. Manch eine Software verwendet neue Befehlssätze, andere nicht usw. usf.
Unterschiede kommen da zwangsweise auf...
Cinebench aber eignet sich aufgrund der idR eher mauen Unterstützung was Befehlssätze angeht für den Quervergleich unter gleichen Bedinungen schon ganz brauchbar... Auch spiegelt die Leistungssteigerung zwischen den CPUs anhand der Punkte grob das wieder, was man gemittelt im Schnitt über viele verschiedene Software auch real bekommt... Nicht auf das Prozent genau, aber in etwa passt das.
Das die BD CPUs (egal welche) mit neuesten Befehlssätzen zum Teil gut zulegen bzw. auf Intel aufholen ist kein Geheimnis. Das Problem ist viel eher, das diese Abhängigkeit in Software gegeben ist und der Softwaremarkt wie so oft bei AMDs "Ideen" einfach nicht auf der Welle mitschwimt. Nur die wenigsten Zuhause werden sich ihre Software selbst programmieren bzw. selbst kompilieren, sofern der Code verfügbar ist. Man ist also an das gebunden, was einem der Markt vorschießt.
Um mal ein Beispiel zu nennen, ich wüsste aus dem Hut nichtmal ne Hand voll Programme, die auf AVX setzen. Der mPlayer kann es wohl... Und so Sachen wie Prime95 oder Boinc. Aber das ist nix, mit was man tagtäglich arbeitet. Es stellt sich also zwangsweise die Frage, was einem Benches mit Benutzung "spezieller" Befehlserweiterungen nutzen, die die Balken länger machen, wenn man davon Zuhause keine Software hat, die es kann!?
Unterm Strich bin ich gespannt, was AMD als nächstes bringt.
Die kleinen 2GHz AM1 CPUs machen für mich nen sehr potenten Eindruck und ich bin drauf und dran meinen Plan, Kaveri im HTPC zu verbauen zugunsten dieser AM1 Teile zu kippen. Bei einem baldigen Nachfolger von Kaveri wäre aber FM2+ doch nicht uninteressant. Wobei wohl der Nachfolger gerade bei der GPU seine Stärken erst mit DDR4 ausspielen wird. Kaveri ist jetzt schon massiv Bandbreitenlimitiert. Da hilft nur Quadchannel oder GDDR5/DDR4 um das zu kompensieren. Auch der HSA Ansatz ist an der Stelle total für die Katz. Auf dem Papier toll, in der Praxis scheinbar quasi irrelevant, weil nicht genutzt/genommen...
Knights Landing kommt mit 4threads/core, softwareseitig hat Intel damit das Konzept übernommen und erweitert^^
Eigentlich nur wenn man einen Teil eines Moduls und dann das ganze Modul misst, denn ein "echter" core skaliert mit 100%.
Soweit ich weis setzt Knights Landing auf 4-way SMT.
Das ist quasi SMT wie wir es bei den CPUs kennen nur mit doppelter Threadanzahl davon. Ein Core = vier Threads.
Die CMT Bauweise von AMD ist da schon ein ganz anderes Konzept...
das ist ja interessant.
so wie ich das interpretiere ist das ein echter Physischer Kern, und 3 x SMT für diesen einen Kern = vier Threads.
4-way SMT ist da aber etwas verwirrend weil das auch auf 4 x SMT pro Kern schließen lassen könnte
fragt sich nur wie gut dieses SMT im vergleich zum CMT sein wird.
besonders leistung pro watt wird interessant. SMT benötigt ja weniger strom, leistet aber auch weniger. bin mal gespannt.
Sieh es nicht getrennt...
Also nicht ein Kern + 3x "SMT", sondern sieh vier Threads die physisch von einem Core abgebildet werden. Deswegen 4-way SMT.
Aktuelle Intel CPUs setzen auf 2-way SMT. Es gibt somit zwei Threads die von einem physischen Core abgebildet werden.
Wenn du so willst sind das zwei Ebenen übereinander. Die Hardware Ebene mit dem einen physischen Kern. Und die logische Ebene mit den zwei oder vier Threads obendrüber
Das "Problem" am SMT ist, es setzt halt "nur" dort an, wo der Code ineffizient die Hardware auslastet. Hast du derart effizienten Code, das deine Ausführungseinheiten vollends am Limit tuckern, bringt dir SMT keine Performancevorteile. Hast du hingegen Code, der eher ineffizient ist. Bspw. weil diverse Abbruchbedingungen die Pipeline häufiger zum "entleeren" zwingen, kann dir SMT schon im Rahmen des möglichen ne Menge Punkte bringen.
CMT ist dennoch der im Grunde leistungsfähigere Ansatz. Weil man damit eben mehr Ausführungseinheiten abbildet anstatt das ganze nur auf der logischen Ebene aufzutrennen. Nur ist dort halt der Nachteil, das die Software auch in der Lage sein muss, diese "Breite" entsprechend ansprechen zu können. Wärend die CPU bei SMT quasi fast keine Leistung verliert, wenn man die Ausführungseinheiten nicht entsprechend ans Limit fährt, büßt man mit CMT definitiv Leistung ein, weil Einheiten brach liegen... Kommt dann noch der Umstand zum tragen, das der CMT Ansatz in Summe nur bei absolutem Multithreading in etwa gleich schnell agiert, wie der SMT Ansatz, entsteht zwangsweise ein starkes Ungleichgewicht zugunsten des SMT Ansatzes bei Teillast. Der womöglich dann noch ineffiziente Code kommt sogar noch oben drauf und schmälert ggf. sogar noch die Performance des CMT Ansatzes.
Also nicht ein Kern + 3x "SMT", sondern sieh vier Threads die physisch von einem Core abgebildet werden. Deswegen 4-way SMT.
Aktuelle Intel CPUs setzen auf 2-way SMT. Es gibt somit zwei Threads die von einem physischen Core abgebildet werden.
Wenn du so willst sind das zwei Ebenen übereinander. Die Hardware Ebene mit dem einen physischen Kern. Und die logische Ebene mit den zwei oder vier Threads obendrüber
Das "Problem" am SMT ist, es setzt halt "nur" dort an, wo der Code ineffizient die Hardware auslastet. Hast du derart effizienten Code, das deine Ausführungseinheiten vollends am Limit tuckern, bringt dir SMT keine Performancevorteile. Hast du hingegen Code, der eher ineffizient ist. Bspw. weil diverse Abbruchbedingungen die Pipeline häufiger zum "entleeren" zwingen, kann dir SMT schon im Rahmen des möglichen ne Menge Punkte bringen.
CMT ist dennoch der im Grunde leistungsfähigere Ansatz. Weil man damit eben mehr Ausführungseinheiten abbildet anstatt das ganze nur auf der logischen Ebene aufzutrennen. Nur ist dort halt der Nachteil, das die Software auch in der Lage sein muss, diese "Breite" entsprechend ansprechen zu können. Wärend die CPU bei SMT quasi fast keine Leistung verliert, wenn man die Ausführungseinheiten nicht entsprechend ans Limit fährt, büßt man mit CMT definitiv Leistung ein, weil Einheiten brach liegen... Kommt dann noch der Umstand zum tragen, das der CMT Ansatz in Summe nur bei absolutem Multithreading in etwa gleich schnell agiert, wie der SMT Ansatz, entsteht zwangsweise ein starkes Ungleichgewicht zugunsten des SMT Ansatzes bei Teillast. Der womöglich dann noch ineffiziente Code kommt sogar noch oben drauf und schmälert ggf. sogar noch die Performance des CMT Ansatzes.
Auf der theoretischen Ebene könnte man sagen, wenn die Pipeline durch diverse Bedinungen nicht optimal befüllt ist und somit "Lücken" entstehen kann dir SMT Punkte bringen.
Hast du hingegen höchstoptimierten Code der quasi keine Luft in der Pipeline lässt, wird dir wohl SMT auch keine Vorteile bringen. Einfach weil SMT dort ansetzt, wo die Auslastung der Ressourcen zu wünschen übrig lässt. Hast du das halt nicht, weil der Code hochoptimiert ist, macht es SMT auch nicht besser. Ggf. wird es sogar langsamer aufgrund des Threadschedulers des OSes.
Die Frage ist wo stehen wir heute... Aus meiner Sicht ist der Code alles andere als hochoptimiert
Das hatten wir ggf. mal, wo man mit Assembler direkt angepassten "Maschinencode" erzeugt hat.
Zeigt auch die durchschnittliche Leistungssteigerung von SMT im Bereich 15-25% sozusagen überall, wo man die Threads belastet. -> und das ohne das die Hardware überhaupt mehr Ausführungseinheiten hat/bekommt. Sondern einfach durch gesteigerte Effizienz in der Abarbeitung/Auslastung der Einheiten.
Hast du hingegen höchstoptimierten Code der quasi keine Luft in der Pipeline lässt, wird dir wohl SMT auch keine Vorteile bringen. Einfach weil SMT dort ansetzt, wo die Auslastung der Ressourcen zu wünschen übrig lässt. Hast du das halt nicht, weil der Code hochoptimiert ist, macht es SMT auch nicht besser. Ggf. wird es sogar langsamer aufgrund des Threadschedulers des OSes.
Die Frage ist wo stehen wir heute... Aus meiner Sicht ist der Code alles andere als hochoptimiert
Das hatten wir ggf. mal, wo man mit Assembler direkt angepassten "Maschinencode" erzeugt hat.
Zeigt auch die durchschnittliche Leistungssteigerung von SMT im Bereich 15-25% sozusagen überall, wo man die Threads belastet. -> und das ohne das die Hardware überhaupt mehr Ausführungseinheiten hat/bekommt. Sondern einfach durch gesteigerte Effizienz in der Abarbeitung/Auslastung der Einheiten.
DragonTear
Legende
Glaube Schaffe wollte ein echtes Beispiel für solchen Code. Kann man effizienten und ineffizienten z.B. in C++ erzeugen?
Dachte Compiler holen da auch schon automatisch das bestmögliche raus...
Dachte Compiler holen da auch schon automatisch das bestmögliche raus...
Aus unser Software holt HTT 25% heraus, bei Cinebench R15 sinds fast 30%. Zeigt sich der Vorteil von 8 gegenüber 4 Threads. Ergebnisse so wie von Intel angepriesen und gewollt.
Zuletzt bearbeitet:
Mick_Foley
Semiprofi
- Mitglied seit
- 10.02.2008
- Beiträge
- 15.045
Du kannst mit jeglicher Programmiersprache ineffizienten Code erzeugen.
Wenn die Compliler immer das bestmögliche rausholen würden, würde man wohl AMDs Compiler nicht wie einen Pestaussetzigen behandeln. Ansonsten ist fdsonnes Beispiel doch gut. Wenn eine CPU in einem bestimmten Zeitintervall eine bestimmt Menge Operationen durchführen kann nutzt guter Code dies halt höchst möglich aus und "schlechter" bzw gängiger Code nicht in der Gänze. Beschäftige die mal mit Rechenaufwand in der Programmierung. Diese Softwareseite zeigt eigentlich schon wie wichtig Optimierung ist, das ist auf CPU-Seite nicht anders.
DragonTear
Legende
Das was du hier beschreibst ist aber doch nur einfach ausgeglichenes Multithreading bzw. die Programmstruktur die natürlich unterschiedlich efizient sein kann.
Dadurch profitiert man aber doch nur mehr von Hyperthreading - Code der davon profitiert ist aber doch eher der der als "inefizient" zu bezeichnen ist.
Ich dachte aber eher an das erwähnte Gegenbeispiel. Nämlich wie Code aussehen muss, so dass die echten, physikalischen Kerne bereits perfekt ausgelaset sind, so dass man eben nicht mehr von Hyperhreading profitiert.
Dabei kommt es aber ja auf die Sprungvorhersage an, und meines Wissens nach versuch ein guter Compiler den Assemblercode so zu formulieren dass die CPU bei ihrer Vorhersage so oft wie möglich richtig liegt und deswegen nicht die Pipeline "leeren" muss.
Zuletzt bearbeitet:
Stechpalme
Enthusiast
Mich würde hier mal interessieren, ob es überhaupt "immer" möglich ist den Code so effizient zu gestalten, dass dieser immer 100% der CPU auslastet. Offengestanden glaube ich das nämlich überhaupt nicht. Selbst extrem parallelisierte Programme profitieren von SMT.
Mick_Foley
Semiprofi
- Mitglied seit
- 10.02.2008
- Beiträge
- 15.045
CPUs funktioniere in der Vertikalen wie in der Horizontalen aber identisch.
SMT greift an dem Punkt auf, dass die CPU oder besser gesagt die Software Rechenleistung auf dem Kern liegen lässt, weil sie ihn aus unterschiedlichen Gründen nicht abruft. Die freien Ressourcen nutzt halt SMT. Einen konkreten Code zu nennen ist ja nicht wirklich möglich, gäbe es dieses Code, den es theoretisch geben muss, so würde in diesem kein Leistungsunterschied bei "totalem" Multithreading zwischen i5 und i7 existieren. Da ist dieses Phänomen so nicht in der Praxis gibt, zeigt, doch, dass es den sehr effizienten Code nicht gibt. Wobei sich bei vielen Arten von Software auch die Frage stellt wie nahe man ans Optimum heran reichen kann..