AMD Zen: Erste Vorserienmodelle im Umlauf

[mr.dude]

Betrachten wir mal 2008:
Budgetlösung:
E4500@3-3,2Ghz für <90 Euro
Was wäre die amd Lösung? x2 6400+ für 110 Euro?

Falsch. Der E4500 taktet erst mal nur mit 2,2 GHz. Für Übertaktung gibt es keine Garantie und ist auch nicht im Kaufpreis enthalten.

Ich zitiere dazu mal Au-Ja! von damals mit dem kleineren E4300 Modell:

Soviel zum regulären Betrieb, kommen wir zum Übertakten: Hier hatten wir große Erwartungen an den Core 2 Duo E4300, doch leider entpuppte sich unser Testmuster als Flopp. Sicher, eine Taktsteigerung um 458 MHz ist mehr als nichts, doch wir hatten zumindest FSB1066 erwartet und mit Taktraten um die 3,0 GHz geliebäugelt.

Kleinere und preiswertere X2 konnte man mit entsprechend gut gehenden Exemplaren genauso auf 3 GHz oder gar mehr takten. 2008 gab es dann schon entsprechende X2 für unter 50 Euro. Da müsstest du den E4500 also so weit übertaktet haben, um mehr als doppelte Performance zu erreichen, um auf ein besseres P/L-Verhältnis zu kommen. Das wage ich mal stark zu bezweifeln. Der X2 5000+ hatte da ja schon unübertaktet ein besseres P/L-Verhältnis.

aber immer wenn ich upgraden wollte, führte kein weg an intel vorbei

Interessiert nur keinen, wenn man allgemein und objektiv AMD und Intel vergleichen will. Übertaktung interessiert nicht mal 1% des gesamten Marktes. Ist ja schön, wenn "für dich" kein Weg an Intel vorbei führt. Nur, was trägt das zu diesem Thread bei? Absolut gar nichts!

 

[mastergamer]

Ich habe mich immer nur auf OC vs OC bezogen, wie du in jedem meiner Beiträge nachlesen kannst. Von stock Settings war nie die Rede.

 

[mr.dude]

Schon klar. Deshalb habe ich meinen Beitrag auch nochmal etwas editiert. Aber selbst OC vs OC ist deine Aussage Quatsch und hat auch keinerlei Relevanz für den Thread.

 

[Holt]

mir persönlich möglicherweise eine APU 4C/8T mit Haswell IPC und 4GB HBM RX470 Power, für 2017 entgangen ist. Also alles rein egoistisch

4C mit der IPC von einer Haswell CPU könnte es wohl durchaus geben, ob die auch die Taktraten eines Haswell i7 haben werden, steht auf einem anderen Blatt. Aber der RX470 werden bisher 110W TDP nachgesagt und die Spekulationen im Forum von Anandtech sprechen für die 65W TDP Version des 4 Kerners nur von um die 3GHz, zusammen wären das dann aber 175W TDP, während für den AM4 nur maximal 95W in der Gerüchteküche gekocht werden. Also würde ich so eine APU so bald nicht erwarten.

 

[SamSerious]

Ich will unbedingt ein Seasonic Prime Titanium kaufen, aber es gibt sie ja nur ab 650 Watt aufwärts. Dank der neuen 14nm/16nm Grakageneration MUSS dann wenigstens eine dicke CPU möglichst jenseits der 100 Watt her

Mal gucken, ob man die Opteron vielleicht auch im Heimrechner einspannen kann...

 

[Phantomias88]

Nein. Dass mehrere Threads überhaupt genutzt werden, darum kümmerte sich bisher der Programmierer. Wie diese Threads dann aufgeteilt werden, darum kümmert sich das Betriebssystem. Bzw hat auch der Programmierer noch etwas Einfluss darauf.

Doch, wenn es ein Flag für CMT und SMT gibt, dann muss der Quell Code halt zwei mal seperat durch mit entsprechendem Flag.
Es gibt nicht umsonst immer mehr Quell Code 4 free um ihn selbst zu Compilieren.
Das wäre noch was OpenCompiler für jedermann, damit auch der OS Kernel Hardware nah arbeitet!

 

[Holt]

Und welcher Compiler hat so ein Flag und wie heißt es? Mir ist da keiner bekannt und es würde auch nur etwas nutzen, wenn der Programmierer oder ersatzweise der Compiler die Thread explizit auf bestimmte Cores zwingen, da es sonst dem Scheduler des OS obliegt wie die Prozesse/Threads auf die Cores/Threads der CPU verteilt werden.

 

[flxmmr]

Das wäre noch was OpenCompiler für jedermann, damit auch der OS Kernel Hardware nah arbeitet!

Linux ist dir entgangen

 

[DerGoldeneMesia]

Betrachten wir mal 2008:
Budgetlösung:
E4500@3-3,2Ghz für <90 Euro
Was wäre die amd Lösung? x2 6400+ für 110 Euro?

Performancelösung:
Q6600@3,6Ghz (180 Euro)
Amdlösung? x4 9850/9650?

Auf die Übertaktbarkeit dieser beiden amd beispiele gehe ich jetzt mal nicht ein.

die diskussion gibts ja auch bei den Grafikkarten, wer das Geld hat kauft sich was besseres einige hatten ja einen Intel 8Kerner um 1000Euro.

Wenn ich die aktuellen Daten höre denke ich das die neuen Amd's wie seine zeit der x4 940 wird, also nicht absolut top.

 

[Holt]

Absolut top müssen die auch nicht werden, die RX480 ist es auch nicht, entscheidend ist erst einmal, dass AMD damit Geld verdienen kann um nachhaltig in die Gewinnzone zu kommen und dann auch Mittel für die Weiterentwicklung zu haben. Es wäre ja auch sehr viel erwartet, dass gleich bei der ersten Version der neuen Architektur alles optimal gemacht sein soll. Das Verbesserungspotential zeigt sich dann meist erst mit dem praktischen Einsatz der Produkte und sollte dann in den nachfolgenden Überarbeitungen genutzt werden.

 

[fdsonne]

AMD war schon immer der Überzeugung, dass ein Kern auch nur ein Thread erhalten und Abarbeiten soll.
Da Intel mit SMT schneller war bei den Entwickler, haben natürlich alle auf Multi-Threading gesetzt.
Das ist bei Intel auch notwendig den anders bekommen sie ihre Fetten Cores nicht ausgelastet, es müssen mindestens zwei Threads auf einem Kern laufen um die hohe Single-Core Leistung zu erhalten.
Zwei Threads werden bei AMD aber auf zwei Kerne verteilt, schon erreicht der Single Core bei AMD nur noch 50% der Leistung.

Ich glaube du hast da ein paar elementare Basissachen nicht ganz verstanden...
SMT aka HT ist von Intel eingeführt wurden mit den Xeon Netburst Modellen. Und dort wohl mitunter wegen der langen Pipeline und dem entstehenden Leerlauf der Einheiten durch diese lange Pipeline. Das hat nichts mit Überzeugung oder ähnlichem zu tun. Auch nix mit AMD war zu langsam. Es war die Zeit, da gab es nur SingleCore CPUs und Dual/Multi Prozessor/Sockel im Serverbereich. Die P4 Modelle haben es gebert, nachdem es die Xeon Vertreter im Serverbereich erhalten haben.
Es müssen auch nicht zwei Threads auf einem Kern laufen um hohe Single-Core Leistung zu erhalten... Woher nimmst du diese Aussage? Im Profibereich schaltet man SMT häufig sogar aus bei den Xeons, weil der Code so gut optimiert ist, das SMT eher Nachteile bringt.

Glücklicherweiße wird ZEN doppelt so viel Cache haben wie Intel ohne SMT.

Nach aktuellen Infos sollen es doch zwei L3 Caches werden? Also pro vier-Core Modul einen L3 Cache. Macht beim Oktacore 2x L3 Cache... Und damit eher vergleichbar mit den Core2Quad oder Pentium D Prozessoren und ihrem eigenen Cache pro DIE.
Mal davon ab, die Cachegröße als solches muss nichtmal was aussagen... Es ist entscheidend, dass die verschiedenen Cachestufen insich gut funktionieren und natürlich der Spaß zusammenpasst. Ist der L1 Cache zu lahm, bringt mir mehr davon auch nix um ein Beispiel zu bringen.

Denn in der Praxis meint man mit "Single-Core" eigentlich immer nur einen einzigen Thread - und auch da ist Intel sehr stark, wenn es sich eben um den Haupt-Thread des Kerns handelt (wie immer beim erwähnten i5) und nicht um den der durch SMT virtualisiert wird.

Was ist denn ein "Hauptthread"?
Da gibts keine Haupt- oder Nebenthreads... Die Last, die durch aktives SMT von beiden dem OS Sichtbaren Threads beim Prozessorcore ankommt, ist perse erstmal gleich priorisiert...

Nein, denn die Bulldozer "Module" bestehen nicht aus zwei vollständigen Kernen. Nur Bestandteile wie die Integer-Einheit gibt es doppelt. Daher gibt es auch dort in den meisten Anwendungen einen stärkeren thread. Verhältnis etwa 60-65% zu 35-40%. bei Intel ist es mit SMT eben 80-85% zu 15-20%.

Siehe oben, das stimmt so nicht... Der Core mit SMT hat keine Verteilung mit 80-85/15-20%. Sobald "Last" durch den zweiten Thread erzeugt wird, ist es normal 50/50%. Theoretisch wäre sogar 100/100% denkbar (volle ALU Load + volle FPU Load)
Was meinst du warum bspw. Vista/2008 Server und älter so massive Leistungsprobleme mit Multicore SMT Prozessoren (aka i7) haben? -> sie legen unüberlegt Last auf beide Threads eines Cores. Hätte der zweite Thread nur das an Performance bekommen, was "über" bleibt, würde es derartige Probleme mit Threadschedulern, die SMT nicht verstehen, nicht geben... Die gibt es aber nachweislich und zweitelfsfrei Stichwort "SMT Parking", falls du dich da informieren willst...
Entsprechend der gleichen Verteilung büßen somit BEIDE Threads potentiell Leistung ein. Die Summe der Leistung von beiden Threads mag zwar höher liegen, aber das bringt dir eben nix, wenn durch bescheidene Threadverteilung trotzdem Leistung verloren geht. Denn die ~15-25% SMT Skalierung im Schnitt sind eben nicht sooo viel. Um das zu erreichen büßt der eigentlich sonst allein laufende Thread pro Core eben ~40% +-x ein. Es geht also von vormals 100% mögliche Leistung auf ~60% runter. Und der zweite Thread erzeugt dann die anderen ~60% = ~115-125% in Summe. (alles unter der Annahme, dass beide Threads natürlich gleiche Last erzeugen)
Mittlerweile, bei den neuesten i3 Modellen skaliert SMT teils auch deutlich über 15-25%. Mit Haswell wurde nämlich eine vierte ALU eingeführt. Das kann den Effekt etwas verbessern, sowohl was die Skalierung nach oben als auch den Einbruch nach unten angeht. Kommt aber klar auf die Instructions an. Auch für Haswell gibt es Code, der einfach mit SMT nicht gut skaliert...

Wo SMT klar punktet ist der Umstand, wenn du ALU und FPU Last über zwei Threads auf einem Core laufen lassen kannst... Denn das (zumindest auf dem Papier) wäre effektiv die technische Vollauslastung beider Rechenwerke.
Intel höchstselbst spricht in den Whitepapern zum Xeon mit HT damals zur Einführung bspw. von so einem Fall und nennt Skalierungsfaktoren bis fast 2!

Wobei es da tatsächlich interessant zu wissen wäre ob Windows schon zu Bulldozer Zeiten gut mit dem ebenfalls etwas stärkeren und etwas schwächeren Thread beim AMD zurecht kam.

Was sind etwas stärkere und etwas schwächere Threads bei AMD? Die Threads, welche das OS "sieht" sind auch bei AMD grundlegend gleichberechtigt... Sie basieren nur nicht auf vollends gesharter Hardware, sondern sind in Teilen dediziert. Was ungünstige Skalierungseffekte hervorrufen kann, dafür unter MT Load auch garantiert für Skalierung sorgt.

Soweit mir bekannt gab es seitens MS einen Patch für den Threadscheduler für Win7. Win8 und neuer können es wohl von Haus aus. Viel Unterschied ist das aber in der Praxis nicht... Denn der CMT Ansatz bei AMDs Bulldozer besagt, dass eben zwei Threads notwendig sind um die ALUs auszufahren. Ob diese nun links oder rechts oder links und rechts laufen, ist generell erstmal fast egal. Der Decoder/Prefetcher kann wohl normal entsprechend viele Instructions durchschubsen, dass auch beide INT Cores (also alle vier ALUs) befüttert werden könnten.
Das was MS aber soweit ich das in Erinnerung habe, nachgepatcht hat, war der Umstand, wenn möglicherweise freie Module vorhanden sind, die Last NICHT auf den zweiten Thread schon belasteter Module gelegt wird... Das bringt wohl bei ALU Last eher wenig Punkte (vielleicht durch den dann alleinigen L2 Cache ein bisschen) -> bei FPU Load hingegen kann das schon was bringen. Denn ein Thread am Bulldozer kann die ganze FPU auslasten, entsprechende Instructions vorrausgesetzt... Das OS hingegen kennt grundsätzlich aber die Arbeit an der Stelle nicht. Sprich reichen 128Bit der FPU oder muss es die zusammengeschaltene 256Bit Breite sein?
Beim BD deckelt wohl der Decoder/Prefetcher in gewissen Teilen früher oder später bei zu viel Last. Mit Steamroller wurden die Decoder verdoppelt. Das verbessert das Problem natürlich... Wie genau sich das am Ende auswirkt, müsste man dediziert mal prüfen/nachlesen.

 

[mr.dude]

Und welcher Compiler hat so ein Flag und wie heißt es?

Würde mich auch mal interessieren.


@Phantomias88
Multithreading mussten die Entwickler bisher explizit implementieren. Das macht ein Compiler nicht einfach so für einen.

 

[Luebke]

@mastergamer:

Nicht erst seit 2011... schon mit der einführung von den C2D cpus (2006?) wars vorbei mit amd.

mit dem c2d hat intel amd die führung abgenommen, aber ein athlon x2 war nach wie vor wettbewerbsfähig, wenn auch nicht gegen einen X6800, aber im mainstream durchaus eine ernstzunehmende alternative. die erste phenom gen hat dann deutlich geschwächelt, aber mit deneb hatte amd ebenfalls wieder ein ordentliches produkt am markt, dass eine gute alternative zu intel bot. und war besser aufgestellt als intel vor c2d. seit sandy ist es aber mit guten amd-alternativen äußerst dünn geworden. wärend man einen carizzo noch einem pentium vorziehen kann, ist ab i3 aufwärts intel äußerst dominant.

@Digi-Quick:

Und Auf Kosten welchen Verbrauches?

ich habs nicht gemessen, aber solange er sich noch passiv kühlen lässt, gehe ich mal von einem vertretbaren rahmen aus. die vcore liegt ja noch innerhalb den offiziellen specs...

@mr.dude:

Das könnten sie im Moment auch gar nicht mehr. Der schrumpfende PC-Markt ist da nur eines von mehreren Problemen für Intel. Zudem verschlingen neue Fertigungen immer mehr Ressourcen. Auch Intel muss sich im Moment gesundschrumpfen. Oder glaubst du die entlassen etwa 10% der Mitarbeiter grundlos?

ich bin mir sicher, intel könnten wenn sie unter druck wären deutlich mehr in die entwicklung stecken. und sie haben mit sicherheit schon einiges in der schublade liegen, dass sie jetzt häppchenweise rausbringen, um jede kleinigkeit als neue generation verkaufen zu können und so die entwicklung von potentiell vllt 2-3 generationen auf 10-20 generationen zu strecken. so wie haswell vs. devils canyon: neue wlp unter den heatspreader: yeay en cpu refresh und neue highend cpus. beim nächsten mal bringen die das als ganz neue generation und nennen sie dann zb. "kaby lake"
ist zwar jetzt ganz stark vereinfacht, aber ich glaube es wird deutlich was ich damit ausdrücken will, oder?

 

[Phantomias88]

Und welcher Compiler hat so ein Flag und wie heißt es? Mir ist da keiner bekannt und es würde auch nur etwas nutzen, wenn der Programmierer oder ersatzweise der Compiler die Thread explizit auf bestimmte Cores zwingen, da es sonst dem Scheduler des OS obliegt wie die Prozesse/Threads auf die Cores/Threads der CPU verteilt werden.

Da das Multithreading unterschiedlich ist (SMT und CMT) woher willst du als Programmierer(in) wissen was nun genutzt wird?
Die meisten Compiler sind für SMT ausgelegt, weil kaum einer die Software auf CMT Hardware compiliert, sind ja zu wenig user die damit erreicht werden.

Es gibt einfache Optimierungs Flags z.B. bei GCC sind es -bdv1 und -bdv2: AMD Bulldozer "bdver1" Compiler Performance - Phoronix
Für ZEN gibt es auch schon zusammengefasste Optimierungs Flags.

Die These wird noch gestützt von Boinc, wo ein und die selbe Aufgabe in der VM Ware mit Linux 50% schneller fertig ist als mit Windows Boinc Version.
Wissenschaftlich nachgewiesen: http://www.abload.de/img/universehome_lubuntuxi9k38.jpg

 

[flxmmr]

Sry, aber wenn man keine Ahnung und noch nicht mal mehr die Lust hat, sich reinzulesen, sollte man irgendwann mal erkennen, dass man nichts sinnvolles mehr beitragen kann.
Wie du selbst schreibst: der Programmierer weiß nicht, ob er da CMT/SMT-Threads hat, genauso wenig, wie das OS weiß, ob der Thread den es da erstellt wegen der Programmlogik nun auf CMT oder SMT performanter wäre.

Einfach nur noch lächerlich ist Compiler-Flags anzuführen, die CPU-Befehlssätze (also das, was du in den Thread an Code reinpackst) einschalten: ich zitiere:

‘bdver2’
AMD Family 15h core based CPUs with x86-64 instruction set support. (This supersets BMI, TBM, F16C, FMA, FMA4, AVX, XOP, LWP, AES, PCL_MUL, CX16, MMX, SSE, SSE2, SSE3, SSE4A, SSSE3, SSE4.1, SSE4.2, ABM and 64-bit instruction set extensions.)

Du sorgst also einfach dafür, dass die Rechenwerke von deiner .exe richtig genutzt werden können.

Sehr simplifiziert ist der Ablauf meiner Laienansicht (der ich immerhin in der Diskussion mit dir voll vertraue ) so: der Programmierer erstellt Threads → das OS verteilt dieses auf die HW-Threads, evtl. bei Lastsituationen mit dem Wissen darüber, dass "virtuelle"-Kerne nicht so viel leisten können → Logik in der CPU spaltet die Instruktionslisten/Thread auf und verteilt diese auf teilweise geteilte Rechenwerke (wo dann die Instruktionen verabeitet werden und die bdver-Optimierung ihre Wirkung zeigt) – wie diese Verteilung passiert unterscheidet jetzt SMT/CMT.

CMT und SMT werden also nie genauso viel leisten, wie echte Kerne und es ist einfach nicht die Zielstellung des ganzen, dafür Programme zu programmieren! Denn beide Techniken versuchen einfach nur auf HW-Ebene – eben ohne, dass der Programmierer tätig wird – das Ausführen mehrerer unspezifierter Threads zu optimieren, um Leerlauf in den Rechenwerken zu vermeiden und die Performance von nicht speziell optimierter Software (wie sie eben selten vorkommt) zu maximieren und so die unschöne Siliziumverschwendung, die ein Mikroprozessor an sich schon darstellt, etwas abzuschwächen .

 

[Phantomias88]

@flxmmr
Ja genau, nur weil ich eher Laie bin und doch schon recht viel kapiert habe, habe ich keine Ahnung!
Das sind nicht alle Flags die im Test von Phoronix getestet wurden.

Wie was am besten läuft sollen die Leute entscheiden die Ahnung haben, ich mach es nicht!
Was bedeuten den die Abkürzungen CMT und SMT evt fällt da ein Unterschied auf?

 

[flxmmr]

Ich weiß immer noch nicht, ob du weißt, was die Flags machen.

Hierhttps://en.wikipedia.org/wiki/File:AMD_Bulldozer_block_diagram_(CPU_core_bloack).PNG (ich spare mir jetzt den Kreis) siehst du gut, wo die Compiler/Assembler-Optionen wirken. In den Blocks 'FPU' und 'Integer Cluster'.

Bei SMT ist imho einfach der zweite Integer-Cluster gestrichen und das drumherum anders, sodass 2 Threads parallel abgearbeitet werden können und, wenn aus dem langsamen L1-Cache neue Instruktionen geholt werden müssen und die CPU idlet, einfach der andere Thread abgearbeitet werden kann.

Da siehst du dann auch, warum die erreichbare Performance bei CMT recht stark schwankt – wird die FPU nicht gebraucht, ist das tatsächlich ein "2-Kerner", sonst eben auch nur ein Prozessor, der nur einen Thread abarbeiten kann, welcher noch dazu immer noch an den Cache gebunden ist. Daher erklärt sich auch der inhärente Vorteil des SMT, wo du (in optimal skalierenden Anwendungen, in denen kein Thread die UI blockt, wie bspw. in Spielen) immer einen Performancegewinn durch die Überbrückung der Cachelatenz haben wirst, während bei CMT im schlechtesten Fall halt wirklich nur ein "Kern" zur Verfügung steht.

(Ich hoffe, das ist soweit richtig und da ich nicht anfange, mir über die CPU im Detail Gedanken zu machen, bringt das auch jemanden weiter)

 

[Holt]

Ja genau, nur weil ich eher Laie bin und doch schon recht viel kapiert habe

Genau den Eindruck habe ich nicht und bin da auch nicht alleine. Du meinst etwas zu wissen, hast aber in Wahrheit eben nichts kapiert und wirst alles durcheinander.

habe ich keine Ahnung!

Das sieht man doch an Deinen Kommentaren und ganz offenbar willst Du nicht dazulernen, weil Du z.B. immer noch auf der falschen Vorstellung beharrst, dass die Threadverteilung habe etwas mit Compilerflags zu tun oder der Compiler würde Einfluss auf die Aufteilung der Threads der SW auf die Kern/Threads der CPU haben.

 

[NasaGTR]

Ist es nicht so das beim programmieren sowieso neue Threads erzeugt werden/ in Threads ausgelagert wird z.B. als ganz einfaches Beispiel damit das Fenster während einer Berechnung nicht einfriert, und das Betriebssystem sich dann um die Verteilung auf die Prozessorkerne kümmert? Multithreading Programmieren ist ja dann versuchen so viel wie möglich in separate Threads auszulagern um mehr Leistung zu erhalten. Und bei manchen Dingen geht das einfacher, bei manchen schwerer und bei manchen gar nicht.

Und über die optimale Verteilung/Ausnutzung der Kerne kümmert sich dann AMD und Intel mit den OS Herstellern (Microsoft).

 

[smoothwater]

Zumindest ist es bei meinen Java-Programmen so.
Man legt fest, ob eine Aufgabe parallel als eigener Thread abgearbeitet werden kann (z.B. permanente Sensorerfassung und Speicherung als Log-File).
Welcher Kern dann was bekommt regelt der Scheduler vom OS.

Oder man schiebt es per gleich auf die Graka, insofern möglich...

 

[flxmmr]

aber normalerweise muss man Threads ja schon explizit erzeugen?! Die meisten GUI-Frameworks bieten halt eine Event-Struktur, die evtl. auch ein bisschen multithreaded wird, ohne dass man es als User des Frameworks direkt mitbekommen muss.

Um die optimale Ausnutzung der Kerne/Hardwarethreads kümmert sich der Scheduler des OS und wie gesagt wird da nicht fürs AMD/Intel optimiert, außer dass vllt. die Verteilung "ganzer Threads" angepasst wird, um der typischen Charakteristik der jeweiligen "HT"-Technik gerecht zu werden (also zu verhindern, dass 4 90%-Threads auf 2 "Kerne" geschoben werden).

Dazu nochmal @Phantomias: Wirkliche Optimierungen bspw. für CMT würden halt so aussehen, dass von 8 Threads 4 reine ALU-Threads sind, da kann man dann, wenn der Programmierer sich darauf einstellt mit Compilerflags maximal warnen, dass der Code nicht läuft oder halt Soft-Float reinlinken, was jeden Performance-Vorteil effektiv auffressen wird (und da ist man dann effektiv wieder im Zeitalter eines 486er mit optionaler FPU). Nur wenn man dann ALU+FPU-Threads hat, laufen die auf SMT eben auch genauso gut (und ganz normale Rechenthreads ohne besondere Cache-Optimierungen auch) [um im 486er Bild zu bleiben, kannst du dir den Bulldozer-Kern also als SMP-System von 2 i486ern mit einer geteilten FPU vorstellen

 

[fdsonne]

Ist es nicht so das beim programmieren sowieso neue Threads erzeugt werden/ in Threads ausgelagert wird z.B. als ganz einfaches Beispiel damit das Fenster während einer Berechnung nicht einfriert, und das Betriebssystem sich dann um die Verteilung auf die Prozessorkerne kümmert? Multithreading Programmieren ist ja dann versuchen so viel wie möglich in separate Threads auszulagern um mehr Leistung zu erhalten. Und bei manchen Dingen geht das einfacher, bei manchen schwerer und bei manchen gar nicht.

Nicht perse "sowieso"
Du als Programmierer musst das natürlich wollen und entsprechend umsetzen... Einige (viele) der Standard Bibliotheken basieren schon auf MT. Sprich für simple Geschichten wo man sich diesen Bibliotheken bedient, hat man in Teilen also MT Code. Im Gesamten muss/sollte das aber eben für die Anwendung konsistent sein. Dir nutzt es ja bspw. nix, wenn sagen wir ein simples OpenFileDialog via MT die Infos aus dem Filesystem zieht, du dann beim Lesen der xxGB großen Datei aber die Read Anweisung im GUI Thread durchführst. -> und die Anwendung trotzdem hart ist während des Lesens.

Und über die optimale Verteilung/Ausnutzung der Kerne kümmert sich dann AMD und Intel mit den OS Herstellern (Microsoft).

Ich denke, man interpretiert da einfach zu viel rein.
Es geht in erster Linie einfach nur darum, vorhandene Ressourcen quasi optimal zu nutzen... Und da eben das OS die Sachen "verteilt", weis es entsprechend natürlich auch, wo da gerade etwas am tuckern ist. Nicht im Detail, aber generel. Wenn das OS also sieht, da sind zwei Threads, die Last erzeugen, wird es klar versuchen diese auf physisch getrennte Cores/Threads/Einheiten auszulagern, damit optimaler Speed bei rum kommt. Das klappt mal mehr mal weniger gut, idR aber recht brauchbar.
Ansonsten kannst du als Programmierer natürlich noch per Hand in die Sache eingreifen... Allerdings hat das auch klar ein paar Nachteile, denn damit obliegt es deinen Gedanken, wo du was wie hinschubst. Mögliche externe Einflüsse könnten den Spaß dann wieder zunichte machen usw.

Dazu nochmal @Phantomias: Wirkliche Optimierungen bspw. für CMT würden halt so aussehen, dass von 8 Threads 4 reine ALU-Threads sind, da kann man dann, wenn der Programmierer sich darauf einstellt mit Compilerflags maximal warnen, dass der Code nicht läuft oder halt Soft-Float reinlinken, was jeden Performance-Vorteil effektiv auffressen wird (und da ist man dann effektiv wieder im Zeitalter eines 486er mit optionaler FPU). Nur wenn man dann ALU+FPU-Threads hat, laufen die auf SMT eben auch genauso gut (und ganz normale Rechenthreads ohne besondere Cache-Optimierungen auch) [um im 486er Bild zu bleiben, kannst du dir den Bulldozer-Kern also als SMP-System von 2 i486ern mit einer geteilten FPU vorstellen

Nicht zwingend... CMT in der Bauweise der AMD Bulldozer Modelle benötigt einfach pro Modul aka zwei Kernen zwei Threads, die Last auf die ALUs legen können, damit die vorhandenen ALUs auch ausgefahren werden. Bei Intels aktuellem SMT Ansatz ist das nicht so. Dort gibt es nur eine Anzahl an ALUs pro Core und SMT sorgt dafür, dass alle ALUs von beiden Threads bedient werden könnten. -> das heist im Umkehrschluss, SMT bei Intel sorgt bspw. auch dafür, dass Code, der nicht die komplette ALU Anzahl ausfahren kann mit einem zweiten zusätzlichen Thread mehr Gesamtleistung rausholt. (unabhängig der FPU), während beim AMD CMT Ansatz eben diese zwei Threads notwendig sind um die Auslastung überhaupt erstmal zu erreichen... Denn nur vier Threads mit Load für die ALUs auf dem vier Moduler AMD = 50% mögliche Performance. 50% Load auf den Quadcores von Intel = im Optimalfall schon 100% mögliche Performance. SMT sorgt für eine Steigerung obenraus.

Der Part mit Intels SMT Ansatz dürfte fast identisch zur kommenden Zen SMT Umsetzung werden... Sprich ich gehe davon aus, dass es ähnlich den Intel Ansätzen aktueller Modelle performen wird und sich zumindest vom Grundverhalten her nicht wirklich was ändert. Interessant dürfte maximal werden, ob die Betriebssysteme da ab Start mitmachen oder ob erst neue OS Scheduler notwendig werden.

 

[JackDrake]

... Interessant dürfte maximal werden, ob die Betriebssysteme da ab Start mitmachen oder ob erst neue OS Scheduler notwendig werden.

Der Linux Kernel Patch ist ja schon länger drin. Also dort sollte der Scheduler problemlos mitmachen. Das Betriebssystem kann ja am Prozessor auslesen, ob SMT vorhanden ist. Windows 10 wird auch kein Problem sein, auch wenn vielleicht Redstone 2 etwas nachhilft. Bei Windows 8 und vor allem Windows 7 hat ja Microsoft den Support für neue CPUs eingestellt.

 

[fdsonne]

Das meine ich ja, ist SMT Parking aktiv unter Win7/8/8.1 oder nicht bei einem Zen Prozessor? Theoretisch spricht nichts dagegen, wenn AMD nicht einen komplett anderen Ansatz fährt -> und danach siehts aktuell nicht aus.

 

[smoothwater]

aber normalerweise muss man Threads ja schon explizit erzeugen?!

Richtig, man muss explizit einen Thread als solchen deklarieren. Durch die übliche Vorgehensweise der höheren Sprachen Module anzulegen ist das aber nicht so schwierig, wie es sich anhört. Muss halt nur Sinn machen. Nicht das man gleichzeitig eine Datei lesen und schreiben will ^^

 

[flxmmr]

Threads ansich sind jetzt auch nicht soo schlimm . Ich wollte nur vermeiden, den Eindruck aufkommen zu lassen, dass man einfach die passende Bibliothek verwendet und schon ist die Anwendung Multithreaded (vllt. nutzen zwar manche Bibliotheken Threads, aber für die eigentlich Applikation muss man schon irgendwo noch die Parallelisierung festlegen).

@fdsonne, ja der Mischbetrieb ist natürlich auch möglich. Irgendwie wollte ich klar machen, dass halt CMT (2 Threads -> 2 ALU, 1 FPU) einfach nicht, wie die 2 Integer Cluster ALUs suggerieren, 2 Kernen gleichkommt, sondern effektiv von der FPU limitiert wird und man für die ALUs nicht sinnvoll extra programmieren kann, außer man wirft einige "Grundprinzipien" der Verwendung eines modernen x64-basierten-Mikroprozessors über Board (man hat halt eine FPU).

 

[Mmichel]

Was mich interessieren würde: Wird der Prozessor und die nötigen Boards richtig mit Win7 laufen ?

 

[Holt]

Ist es nicht so das beim programmieren sowieso neue Threads erzeugt werden/ in Threads ausgelagert wird

Nein, die Threads entstehen immer erst durch einen Aufruf an den Kernel des OS, so wie es beim Start eines Programms immer erstmal einen Thread für dieses Programm erzeugt. Ob dieser Systemaufruf um einen neuen Thread zu starten nun im Programm selbst vom Programmierer gemacht wird oder in einer Bibliotheken erfolgt, ist dabei erstmal nicht sehr relevant. Der Compiler selbst kann und darf keine solche Aufrufe irgendwo einstreuen, denn wenn man einen weiteren Thread erzeugt, dann muss man sich auch darum kümmern, es kann Probleme mit den Zugriffen auf gemeinsame Variabel geben, diese müssen dann eben durch entsprechende Absicherungen vermieden werden und wird so ein Thread ja nicht zum Spaß gestartet, sondern der soll ja was sinnvoller berechnen und das Ergebnis muss dann ja auch irgendwo verwendet werden und dazu muss der man dann also schauen ob es schon vorliegt und ggf. warten bis dieses da ist, da ist also vieles nötig was ein Compiler gar nicht selbst machen könnte und was leider selbst nicht wenige Programmierer überfordert.

Und über die optimale Verteilung/Ausnutzung der Kerne kümmert sich dann AMD und Intel mit den OS Herstellern (Microsoft).

Es gibt ja nicht nur Windows und ja, AMD und Intel arbeiten natürlich zumindest bei den bekannten OS auch mit am Scheduler, also dem Teil des OS welches sich um die Threads der Software und deren Aufteilung auf die Kerne/Threads der CPU kümmert. Zumindest bei Windows und Linux hat der SW-Entwickler aber eben auch die Möglichkeit selbst Hand anzulegen und zu bestimmten auf welchen (virtuellen) Kernen seine Threads laufen dürfen. Um überhaupt eine Chance zu haben damit einen Vorteil zu erzielen, sollte der Entwickler dann schon einiges von den CPUs verstehen und muss natürlich vorher auslesen wie viele (virtuelle) Kerne die CPU bietet und am Besten auch was für eine CPU es denn ist. Wenn es nicht richtig gemacht wird, schießt man sich da auch ganz schnell ins Knie und wenn dann zwei Programme auf einem Rechner laufen deren Entwickler unbedingt meinten einen sehr aktiven Threads unbedingt nur auf dem ersten virtuellen Kern laufen lassen zu müssen, dann wird der Anwender vor dem Rechner sicher alles andere als erfreut sein, selbst wenn es einen Vorteil ist dies zu machen solange es nur eines der Programme läuft.

 

[mr.dude]

ich bin mir sicher, intel könnten wenn sie unter druck wären deutlich mehr in die entwicklung stecken.

Intel ist doch mehr als unter Druck. Die haben schliesslich nicht nur AMD als Konkurrenz. Unter der Voraussetzung, dass es auch wirtschaftlich sinnvoll ist, halte ich es für wenig wahrscheinlich, dass Intel im Moment die Entwicklungskosten deutlich erhöhen könnte.

 

[Sir Diablo]

Intel ist doch mehr als unter Druck.

Du meinst also Intel steht mit dem Rücken an der Wand?
Klar, man kann sich alles einreden....