Cascade Lake-AP: Nach AMDs Epyc "klebt" jetzt auch Intel CPUs zusammen
- Ersteller PCGH-Redaktion
- Erstellt am
AW: Cascade Lake-AP: Nach AMDs Epyc "klebt" jetzt auch Intel CPUs zusammen
Das Gleiche wie mit meinem aktuellen PC: So gut wie alles was man mit einem PC machen kann. Ergo - wie vermutlich 100% aller PC-User - nichts was eine solche Leistung auch nur ansatzweise zwingend erfordern würde. Aber ich muß dir sicher auch nicht erklären, dass das kein Kriterium für einen "HEDT-PC" (bzw. auch "nur" das primäre Hobby PC) ist. Hier geht es einzig darum, in einem - aus individueller Kundensicht - finanziell gerade noch "sinnvollem" Rahmen so viel Leistung für sein Geld zu bekommen, wie irgendwie möglich. Deswegen machen in solchen Fällen auch Diskussionen bzgl. "brauchen" o.ä. keinen Sinn, denn "brauchen" ist hier absolut kein Kriterium. Der Großteil der Menschen "braucht" privat gar keinen PC zum über-leben, und fast alle (>90%?) "brauchen" keinen so leistungsfähigen wie sie ihn am Ende gekauft haben. ^^
Daher sprach ich auch von einer CPU mit "nur" 16 Kernen, und nicht von 32, 48, oder gar 56 bzw. 64 Kernen. Ich denke, dass die 16 Kerne der aktuelle Sweet-Spot für einen PC mit einer angedachter Nutzungszeit von (in meinem Fall wieder) 5-7 Jahren sind. Und da bzgl. Takt und IPC (oder Latenz) alles mögliche getan wird, ich also keine +30% IPC oder 6GHz Takt in nächster Zeit erwarten kann (gerade bei einem 16-Kerner), wünsche ich mir bei anderen, die Performance tlw. massiv beeinflussenden, CPU-Komponenten einen deutlichen Zuwachs. Und das sind nun mal Dinge wie die Speicherbandbreite (meine aktuelle CPU ist fast 7 Jahre alt, und hat mit 60GB/s fast 50% mehr Bandbreite als der nagelneue 9900K), und L3/L4 Cache (siehe die Cache-Monster, die tlw. CPUs wie Gras nieder reiten die 1GHz mehr Takt haben - von Einflüssen die kaum/viel zu selten getestet werden, wie zb. die Gleichmäßigkeit der umgesetzten Leistung, mal ganz zu schweigen - ein (leider auch relativ teurer) Monster-Cache ist quasi immer von Vorteil).
Ich würde eine solche "Wunsch-CPU" daher ganz genau so einsetzen wie meine aktuelle CPU. Und zum ersten mal seit Ende 2006 (QX6700) nicht die Flaggschiff-CPU, oder ein Modell darunter (3930K) kaufen. 2012 kostete die zweitschnellste CPU von Intel noch 500€, und war bis auf den Takt (den man mit Übertaktung ausgleichen kann) komplett mit der 1000€ CPU identisch. Schon heute ist das Flaggschiff (AMD = 2990WX 32-Kerner für 1800€, Intel = 9980XE 18-Kerner für 2200€) totaler (gerade finanzieller) Overkill, mit den nächsten Generationen 2019 werden es dann selbst die ersten (tlw. paar) kleineren Brüder sein. Von den nächstes Jahr kommenden Flaggschiff-CPUs mit bis zu 56 Kerne (Intel) bzw. 64 Kerne (AMD) mal ganz zu schweigen.
Deswegen reicht mir (auch beim Kauf in 2019), wie erwähnt, schon eine CPU mit "nur" 16 Kernen, und entsprechend höherem Takt. Wenn sie dann noch mehr als Quad-Channel bietet (mehr schadet nie, und 12 Speicherkanäle sind schon ein richtiger Sprung^^), alle Kerne ordentlich am RAM angebunden sind (logisch, weil es sonst massiv Performance kostet), und mindestens 100MB "Allcore-Cache" hat (neben IPC und Takt die wichtigste Komponente, und gerne jeweils L3+L4^^), auf den alle Kerne gleich schnell zugreifen können - komm zu Papa.
Da ich glaube zu wissen worauf du hinaus willst, daher direkt das "Wichtigste" vorweg:
Das Gleiche wie mit meinem aktuellen PC: So gut wie alles was man mit einem PC machen kann. Ergo - wie vermutlich 100% aller PC-User - nichts was eine solche Leistung auch nur ansatzweise zwingend erfordern würde. Aber ich muß dir sicher auch nicht erklären, dass das kein Kriterium für einen "HEDT-PC" (bzw. auch "nur" das primäre Hobby PC) ist. Hier geht es einzig darum, in einem - aus individueller Kundensicht - finanziell gerade noch "sinnvollem" Rahmen so viel Leistung für sein Geld zu bekommen, wie irgendwie möglich. Deswegen machen in solchen Fällen auch Diskussionen bzgl. "brauchen" o.ä. keinen Sinn, denn "brauchen" ist hier absolut kein Kriterium. Der Großteil der Menschen "braucht" privat gar keinen PC zum über-leben, und fast alle (>90%?) "brauchen" keinen so leistungsfähigen wie sie ihn am Ende gekauft haben. ^^
Daher sprach ich auch von einer CPU mit "nur" 16 Kernen, und nicht von 32, 48, oder gar 56 bzw. 64 Kernen. Ich denke, dass die 16 Kerne der aktuelle Sweet-Spot für einen PC mit einer angedachter Nutzungszeit von (in meinem Fall wieder) 5-7 Jahren sind. Und da bzgl. Takt und IPC (oder Latenz) alles mögliche getan wird, ich also keine +30% IPC oder 6GHz Takt in nächster Zeit erwarten kann (gerade bei einem 16-Kerner), wünsche ich mir bei anderen, die Performance tlw. massiv beeinflussenden, CPU-Komponenten einen deutlichen Zuwachs. Und das sind nun mal Dinge wie die Speicherbandbreite (meine aktuelle CPU ist fast 7 Jahre alt, und hat mit 60GB/s fast 50% mehr Bandbreite als der nagelneue 9900K), und L3/L4 Cache (siehe die Cache-Monster, die tlw. CPUs wie Gras nieder reiten die 1GHz mehr Takt haben - von Einflüssen die kaum/viel zu selten getestet werden, wie zb. die Gleichmäßigkeit der umgesetzten Leistung, mal ganz zu schweigen - ein (leider auch relativ teurer) Monster-Cache ist quasi immer von Vorteil).
Ich würde eine solche "Wunsch-CPU" daher ganz genau so einsetzen wie meine aktuelle CPU. Und zum ersten mal seit Ende 2006 (QX6700) nicht die Flaggschiff-CPU, oder ein Modell darunter (3930K) kaufen. 2012 kostete die zweitschnellste CPU von Intel noch 500€, und war bis auf den Takt (den man mit Übertaktung ausgleichen kann) komplett mit der 1000€ CPU identisch. Schon heute ist das Flaggschiff (AMD = 2990WX 32-Kerner für 1800€, Intel = 9980XE 18-Kerner für 2200€) totaler (gerade finanzieller) Overkill, mit den nächsten Generationen 2019 werden es dann selbst die ersten (tlw. paar) kleineren Brüder sein. Von den nächstes Jahr kommenden Flaggschiff-CPUs mit bis zu 56 Kerne (Intel) bzw. 64 Kerne (AMD) mal ganz zu schweigen.
Deswegen reicht mir (auch beim Kauf in 2019), wie erwähnt, schon eine CPU mit "nur" 16 Kernen, und entsprechend höherem Takt. Wenn sie dann noch mehr als Quad-Channel bietet (mehr schadet nie, und 12 Speicherkanäle sind schon ein richtiger Sprung^^), alle Kerne ordentlich am RAM angebunden sind (logisch, weil es sonst massiv Performance kostet), und mindestens 100MB "Allcore-Cache" hat (neben IPC und Takt die wichtigste Komponente, und gerne jeweils L3+L4^^), auf den alle Kerne gleich schnell zugreifen können - komm zu Papa.
AW: Cascade Lake-AP: Nach AMDs Epyc "klebt" jetzt auch Intel CPUs zusammen
Also ich muss am 2ten Tag immer noch Lachen.
Intel...
Über die Preise und das geringe Leistungsplus weint man sonst immer, aber das hier ist der Brüller.
Vor einem jahr noch siegesbewusst rumposaunt, nun muss man wieder wie schon beim AMD 64 kleinlaut wie ein getretener Köter den Schwanz einziehen, nachziehen und abkupfern.
Aber sicherlich nennt das Marketing einen wichtigen Unterschied: hier klebt man nicht, hier wird geschweißt. ^^
Wie geht es euch?
Also ich muss am 2ten Tag immer noch Lachen.
Intel...
Über die Preise und das geringe Leistungsplus weint man sonst immer, aber das hier ist der Brüller.
Vor einem jahr noch siegesbewusst rumposaunt, nun muss man wieder wie schon beim AMD 64 kleinlaut wie ein getretener Köter den Schwanz einziehen, nachziehen und abkupfern.
Aber sicherlich nennt das Marketing einen wichtigen Unterschied: hier klebt man nicht, hier wird geschweißt. ^^
Wie geht es euch?
JanJake
BIOS-Overclocker(in)
AW: Cascade Lake-AP: Nach AMDs Epyc "klebt" jetzt auch Intel CPUs zusammen
Wo sind die ganzen AMD Hater die über den TR gemeckert habe?
Komisch, Intel darf sich jeden Scheiß erlauben! Erst meckert Intel über die zusammen geklebten CPUs von AMD und jetzt selber machen. Lächerlich!
Dann kommt der 28 Kerner von Intel auch noch für einen neuen Sockel, 3647 oder wie auch immer, für schlappe 10.000$.
Achja, ich vergaß, ist Intel, die laut den ganzen Fan Boys ach so tolle Sachen in der Schublade haben um zu kontern.
8000er Reihe zu überhastet, 9000er überhastet, und dann noch ein Z370 wo die alten nicht drauf laufen obwohl gleicher Sockel und welche bewiesen haben das es geht!
Schade, die ganzen Million die die über Jahre geschäffelt haben sind also einfach so zum Fenster heraus geworfen.
Intel noch kein 10nm der eh an den Nagel gehängt wird, 4 Jahre zu spät! AMD kommt dieses Jahr noch mit 7nm.
Wo sind die ganzen AMD Hater die über den TR gemeckert habe?
Komisch, Intel darf sich jeden Scheiß erlauben! Erst meckert Intel über die zusammen geklebten CPUs von AMD und jetzt selber machen. Lächerlich!
Dann kommt der 28 Kerner von Intel auch noch für einen neuen Sockel, 3647 oder wie auch immer, für schlappe 10.000$.
Achja, ich vergaß, ist Intel, die laut den ganzen Fan Boys ach so tolle Sachen in der Schublade haben um zu kontern.
8000er Reihe zu überhastet, 9000er überhastet, und dann noch ein Z370 wo die alten nicht drauf laufen obwohl gleicher Sockel und welche bewiesen haben das es geht!
Schade, die ganzen Million die die über Jahre geschäffelt haben sind also einfach so zum Fenster heraus geworfen.
Intel noch kein 10nm der eh an den Nagel gehängt wird, 4 Jahre zu spät! AMD kommt dieses Jahr noch mit 7nm.
G
gaussmath
Guest
AW: Cascade Lake-AP: Nach AMDs Epyc "klebt" jetzt auch Intel CPUs zusammen
@JanAttacke: Man sollte ein bisschen vorsichtig sein. Wenn Intel mit ihrem performanten Mesh verkleben, dann ist das was anderes. Im Moment sind sie bei Durchsatz und Latenz um den Faktor 2 besser.
@JanAttacke: Man sollte ein bisschen vorsichtig sein. Wenn Intel mit ihrem performanten Mesh verkleben, dann ist das was anderes. Im Moment sind sie bei Durchsatz und Latenz um den Faktor 2 besser.
AW: Cascade Lake-AP: Nach AMDs Epyc "klebt" jetzt auch Intel CPUs zusammen
Mesh ist nur für Die-interne Kommunikation geeignet. Die MCM-Verbindung wird über UPI laufen, sich allenfalls im Takt von heutigen Dual-LGA-3647-Systemen unterscheiden. Trotzdem sollte man eine kompaktere Bauform für bisherige Quad-24-Kern-Xeon-Server nicht mit einem beschnittenen Epyc-Ableger für Heimanwender vergleichen. Gegebenenfalls werden auf ersterem gar keine Spiele gezockt, sondern NUMA aware Software eingesetzt, die mit heterogenen Zugriffsstrukturen umgehen kann?
Sagt jedenfalls meine Glaskugel. aber vielleicht ist die auch falsch kalibriert, 10.000 US-Dollar zeigt sie beispielsweise noch nicht an.
Mesh ist nur für Die-interne Kommunikation geeignet. Die MCM-Verbindung wird über UPI laufen, sich allenfalls im Takt von heutigen Dual-LGA-3647-Systemen unterscheiden. Trotzdem sollte man eine kompaktere Bauform für bisherige Quad-24-Kern-Xeon-Server nicht mit einem beschnittenen Epyc-Ableger für Heimanwender vergleichen. Gegebenenfalls werden auf ersterem gar keine Spiele gezockt, sondern NUMA aware Software eingesetzt, die mit heterogenen Zugriffsstrukturen umgehen kann?
Sagt jedenfalls meine Glaskugel. aber vielleicht ist die auch falsch kalibriert, 10.000 US-Dollar zeigt sie beispielsweise noch nicht an.
D
DBGTKING
Guest
AW: Cascade Lake-AP: Nach AMDs Epyc "klebt" jetzt auch Intel CPUs zusammen
Hi ich weiß das ht nur virtuelle kerne sind. Aber brauchen die nicht such bandbreireite, sowie cache. Wenn man die abschaltet dann müssten die restlichen ja mehr zur verfügung haben.
Ich hatte mal ein test gemacht beim h264 umwandeln. 10 kerne mit ht vs 10 kerne ohne ht. Die leistung war gleich gewesen. Ob es sich bei 2* die selben programme mit jeweils unterschiedliche videos, ob da ht wieder vom vorteil ist, das eeis keiner.
Darum besitze ich ja ein xeon 22 kerner mit(aber noch nicht im einsatz), schalte ht ab und die kerne optimal zu belasten. Keine sicherheitsrisko zu riskieren. Bei spielen wird das gutvsein. Bei der anwendung werdevich auch profitieren. Auch wenn das 22 x 2,8 vs 10 +10 ht x 4 ghz sind. Der 22 kerner wird klar gewinnen bei mehr als 1 anwendung zumindest. Wenn ich die beiden umwandlungsprogramme dann noch mitbeinem spiel kombiniere dann fallen zumindest mindestens 16 kern marke. Da würde ht ja nur bremsen. Irgendwann ist ht auch mal am ende. Und wenn ich behrlich bin, bisher habe ich von ht nix profitiert. Vereende wohl die falsche software. Wird sich bei mir auch langfristig nimmer änderen.
Hi ich weiß das ht nur virtuelle kerne sind. Aber brauchen die nicht such bandbreireite, sowie cache. Wenn man die abschaltet dann müssten die restlichen ja mehr zur verfügung haben.
Ich hatte mal ein test gemacht beim h264 umwandeln. 10 kerne mit ht vs 10 kerne ohne ht. Die leistung war gleich gewesen. Ob es sich bei 2* die selben programme mit jeweils unterschiedliche videos, ob da ht wieder vom vorteil ist, das eeis keiner.
Darum besitze ich ja ein xeon 22 kerner mit(aber noch nicht im einsatz), schalte ht ab und die kerne optimal zu belasten. Keine sicherheitsrisko zu riskieren. Bei spielen wird das gutvsein. Bei der anwendung werdevich auch profitieren. Auch wenn das 22 x 2,8 vs 10 +10 ht x 4 ghz sind. Der 22 kerner wird klar gewinnen bei mehr als 1 anwendung zumindest. Wenn ich die beiden umwandlungsprogramme dann noch mitbeinem spiel kombiniere dann fallen zumindest mindestens 16 kern marke. Da würde ht ja nur bremsen. Irgendwann ist ht auch mal am ende. Und wenn ich behrlich bin, bisher habe ich von ht nix profitiert. Vereende wohl die falsche software. Wird sich bei mir auch langfristig nimmer änderen.
AW: Cascade Lake-AP: Nach AMDs Epyc "klebt" jetzt auch Intel CPUs zusammen
SMT ermöglicht es, Leerlaufphasen in einem Thread mit Berechnungen eines anderen zu füllen. In linear ablaufenden, gut vorhersehbaren Anwendungen wie Video-Transcoding reicht aber schon sehr wenig Optimierung, um Leerlauf-/Wartezeiten beinahe gänzlich zu vermeiden. HT kann dann keinen Leistungsvorteil mehr bringen, aufgrund des zusätzlichen Verwaltungsaufwandes sogar Leistung kosten. Das wäre übrigens ein typisches Beispiel für Leistungscharakteristiken die man in einer Anwendung sehr deutlich messen kann, die aber gar nichts über die Spieleleistung heute oder in Zukunft aussagen.
SMT ermöglicht es, Leerlaufphasen in einem Thread mit Berechnungen eines anderen zu füllen. In linear ablaufenden, gut vorhersehbaren Anwendungen wie Video-Transcoding reicht aber schon sehr wenig Optimierung, um Leerlauf-/Wartezeiten beinahe gänzlich zu vermeiden. HT kann dann keinen Leistungsvorteil mehr bringen, aufgrund des zusätzlichen Verwaltungsaufwandes sogar Leistung kosten. Das wäre übrigens ein typisches Beispiel für Leistungscharakteristiken die man in einer Anwendung sehr deutlich messen kann, die aber gar nichts über die Spieleleistung heute oder in Zukunft aussagen.
JanJake
BIOS-Overclocker(in)
AW: Cascade Lake-AP: Nach AMDs Epyc "klebt" jetzt auch Intel CPUs zusammen
Ich sprach nicht von Leistung!
Und so viel schneller ist der Intel nicht das es den Preis rechtfertigt.
Ein 1920X isr für 400€ und paar zerquetschte zu haben. Das sind 12 Kerne, 24 Threads. Bei Intel gibt es dafür gerade einmal 6 Kerne und 12 Threads. Klar in Spielen etwas schneller, aber dafür in Anwendugen deutlich langsamer.
Der 9900K ist ein Witz! Keine Verfügbarkeit, 650- 1000€ je nach Shop! Für unter 750€ gibt es bei AMD 16 Kerne mit 32 Threads.
Und der 28 Kern Cascade Kake Xeon 28 Kerner ist wohl die Höhe dabei! 10.000$ für eine CPU auf dem Sockel 3647 oder wie der heißt.
Klar, hier und da ist der schneller als der 2990WX, aber dafür, was der Xeon kostet, bekomme ich drei komplette! Systeme mit einem 2990WX und hätte in der Summe 96 Kerne mit 192 Threads.
Absolut gesehen mag Intel schneller sein, aber so viel teurer sein als die Konkurrenz für die paar % mehr Leistung?
Ich kritisiere nicht die Leistung sondern die Firmen Poltik von Intel! Erst meckern über AMD jetzt selber machen und in den Himmel loben! Papier Launche bei den 8K und 9K CPUs und einen neuen Sockel den keiner braucht! Jetzt kommt noch ein Sockel dazu und eine CPU die 4 mal so teuer isr wie ein 2990WX.
Für mich sieht das nach Verzweiflung aus bei Intel! Kein 10nm keine Ideen mehr(bis heute haben wir noch Skylake!)
Ich sprach nicht von Leistung!
Und so viel schneller ist der Intel nicht das es den Preis rechtfertigt.
Ein 1920X isr für 400€ und paar zerquetschte zu haben. Das sind 12 Kerne, 24 Threads. Bei Intel gibt es dafür gerade einmal 6 Kerne und 12 Threads. Klar in Spielen etwas schneller, aber dafür in Anwendugen deutlich langsamer.
Der 9900K ist ein Witz! Keine Verfügbarkeit, 650- 1000€ je nach Shop! Für unter 750€ gibt es bei AMD 16 Kerne mit 32 Threads.
Und der 28 Kern Cascade Kake Xeon 28 Kerner ist wohl die Höhe dabei! 10.000$ für eine CPU auf dem Sockel 3647 oder wie der heißt.
Klar, hier und da ist der schneller als der 2990WX, aber dafür, was der Xeon kostet, bekomme ich drei komplette! Systeme mit einem 2990WX und hätte in der Summe 96 Kerne mit 192 Threads.
Absolut gesehen mag Intel schneller sein, aber so viel teurer sein als die Konkurrenz für die paar % mehr Leistung?
Ich kritisiere nicht die Leistung sondern die Firmen Poltik von Intel! Erst meckern über AMD jetzt selber machen und in den Himmel loben! Papier Launche bei den 8K und 9K CPUs und einen neuen Sockel den keiner braucht! Jetzt kommt noch ein Sockel dazu und eine CPU die 4 mal so teuer isr wie ein 2990WX.
Für mich sieht das nach Verzweiflung aus bei Intel! Kein 10nm keine Ideen mehr(bis heute haben wir noch Skylake!)
G
gaussmath
Guest
AW: Cascade Lake-AP: Nach AMDs Epyc "klebt" jetzt auch Intel CPUs zusammen
Nein, das sind keine Leerphasen, höchsten Leerressourcen. Ein Thread kann auch bei konstanter Last eines anderen Threads auf Einheiten desselben Kernes zugreifen, wenn diese nicht genutzt werden. Es ist zudem dann positiv effizient, wenn der gemeinsam genutzte Cache ausreicht und keine Re-Reads nötig sind.
Nein, das sind keine Leerphasen, höchsten Leerressourcen. Ein Thread kann auch bei konstanter Last eines anderen Threads auf Einheiten desselben Kernes zugreifen, wenn diese nicht genutzt werden. Es ist zudem dann positiv effizient, wenn der gemeinsam genutzte Cache ausreicht und keine Re-Reads nötig sind.
Zuletzt bearbeitet von einem Moderator:
AW: Cascade Lake-AP: Nach AMDs Epyc "klebt" jetzt auch Intel CPUs zusammen
Ich weiß nicht, ob Intel bei aktuellen Implementationen Detailänderungen vorgenommen hat, aber klassischerweise werden bei HT mehrere Elemente (meiner Erinnerung Decoder, Cache- und Queue-Zugriffe, Rename,...) nicht parallel, sondern alternierend genutzt. Auch die eigentlichen Recheneinheiten können zwar µOps beider Threads gemischt verarbeiten, aber jede Pipeline nur eine µOp zu einem Zeitpunkt. Ergeben zwei Threads µOps, die nur eine Pipeline beherrscht, ist eine parallele Verarbeitung also unmöglich. Natürlich kann die CPU einen Thread0, der sequentiell geteilte Einheiten konstant auslastet, auch einfach zugunsten von Thread1 unterbrechen. Dadurch verbessern sich Leistung und Effizienz aber nicht, da Thread0 eben entsprechend länger wartet. Viel Leistung gewinnt man durch SMT nur, wenn Thread1 beispielsweise auf Daten aus dem L3 Cache oder gar RAM wartet und Teile der CPU solange nur Däumchen drehen können. In Einzelfallen mag auch die Verzögerung von Thread0 zugunsten von Thread1 auch Nettogewinne erbringen, wenn hierdurch weniger spekulative Berechnungen nötig und dementsprechend auch weniger verworfen werden, aber das kann auch ganz schnell nach hinten losgehen, wenn Thread1 nämlich auf die Ergebnisse von Thread0 aufbauen möchte und jetzt seinerzeit zusätzliche branch misses produziert.
Ich weiß nicht, ob Intel bei aktuellen Implementationen Detailänderungen vorgenommen hat, aber klassischerweise werden bei HT mehrere Elemente (meiner Erinnerung Decoder, Cache- und Queue-Zugriffe, Rename,...) nicht parallel, sondern alternierend genutzt. Auch die eigentlichen Recheneinheiten können zwar µOps beider Threads gemischt verarbeiten, aber jede Pipeline nur eine µOp zu einem Zeitpunkt. Ergeben zwei Threads µOps, die nur eine Pipeline beherrscht, ist eine parallele Verarbeitung also unmöglich. Natürlich kann die CPU einen Thread0, der sequentiell geteilte Einheiten konstant auslastet, auch einfach zugunsten von Thread1 unterbrechen. Dadurch verbessern sich Leistung und Effizienz aber nicht, da Thread0 eben entsprechend länger wartet. Viel Leistung gewinnt man durch SMT nur, wenn Thread1 beispielsweise auf Daten aus dem L3 Cache oder gar RAM wartet und Teile der CPU solange nur Däumchen drehen können. In Einzelfallen mag auch die Verzögerung von Thread0 zugunsten von Thread1 auch Nettogewinne erbringen, wenn hierdurch weniger spekulative Berechnungen nötig und dementsprechend auch weniger verworfen werden, aber das kann auch ganz schnell nach hinten losgehen, wenn Thread1 nämlich auf die Ergebnisse von Thread0 aufbauen möchte und jetzt seinerzeit zusätzliche branch misses produziert.
G
gaussmath
Guest
AW: Cascade Lake-AP: Nach AMDs Epyc "klebt" jetzt auch Intel CPUs zusammen
Na, du gehst aber ins Detail. Selbst wenn der µOps nur sequentiell von Thread0 und Thread1 angesprochen werden kann, muss doch nicht zwingend ein Leerlauf vorliegen. Der Thread kann doch währenddessen irgendwelche Daten aus dem RAM oder L3 Cache ranschaufeln.
Na, du gehst aber ins Detail. Selbst wenn der µOps nur sequentiell von Thread0 und Thread1 angesprochen werden kann, muss doch nicht zwingend ein Leerlauf vorliegen. Der Thread kann doch währenddessen irgendwelche Daten aus dem RAM oder L3 Cache ranschaufeln.
D
DBGTKING
Guest
AW: Cascade Lake-AP: Nach AMDs Epyc "klebt" jetzt auch Intel CPUs zusammen
Wenn er das machen würde, dann müsste es ja eine geschwindigkeitssteigerung geben. Die gab es aber nicht. Mit oder ohne ht, es gab vielkeicht wenn man es genau nimmt eine differenz von 1-2 sekunden. Bei so um die 4 minuten macht das nichts aus. Man könnte es als abrundunfsfehler sehen. Oder gewöhnliche abweichung bzw differenz im normalen bereich. Ändert aber nix das ich da keinen unterschied festgestellt hatte. Weil sonst hat sich ja nix geändert. Bei hochauflösenden sachen wie full hd umwandeln usw, da habe ich dann aber zwischen ht aus und ein aber sehr wohl einen unterschied festgestellt. Wenn ht so richtig ausgenutzt wird, dann bringt das ne ordentliche leistungssteigerung. Ansonsten verliert ht an stärke. Das könnte durchaus seine theorie bestägigen.
Wenn er das machen würde, dann müsste es ja eine geschwindigkeitssteigerung geben. Die gab es aber nicht. Mit oder ohne ht, es gab vielkeicht wenn man es genau nimmt eine differenz von 1-2 sekunden. Bei so um die 4 minuten macht das nichts aus. Man könnte es als abrundunfsfehler sehen. Oder gewöhnliche abweichung bzw differenz im normalen bereich. Ändert aber nix das ich da keinen unterschied festgestellt hatte. Weil sonst hat sich ja nix geändert. Bei hochauflösenden sachen wie full hd umwandeln usw, da habe ich dann aber zwischen ht aus und ein aber sehr wohl einen unterschied festgestellt. Wenn ht so richtig ausgenutzt wird, dann bringt das ne ordentliche leistungssteigerung. Ansonsten verliert ht an stärke. Das könnte durchaus seine theorie bestägigen.
bofferbrauer
Volt-Modder(in)
AW: Cascade Lake-AP: Nach AMDs Epyc "klebt" jetzt auch Intel CPUs zusammen
Jo, das war der 287er/387er, ein Fließpunktkoprozessor; bis dahin waren alle X86 quasi reine Integer Maschinen. Der Chip ist seit dem 486 im Chip integriert, ein 487er board gabs allerdings schon noch: Dieser beinhaltete einen 486er DX, um einem fest verlötetem SX (wo der integrierte Coprozessor abgeschaltet war) zu ersetzen. Wiki weiß mehr: x87 – Wikipedia
Edit: Ist überhaupt gesichert, dass es sich dabei um 2 XCC Chips mit jeweils 4 deaktivierten Kernen handelt? Könnten es nicht auch genauso 6 i7 9700 oder genauer, deren Xeon Versionen sein? Wûrde schliesslich auch passen, sowohl das fehlen vom SMT als auch die 12 Speicherkanäle. Angesichts des Verbrauchs und der Abwärme eines XCC wären 6 theoretische i7 9700T wohl deutlich sparsamer
Jo, das war der 287er/387er, ein Fließpunktkoprozessor; bis dahin waren alle X86 quasi reine Integer Maschinen. Der Chip ist seit dem 486 im Chip integriert, ein 487er board gabs allerdings schon noch: Dieser beinhaltete einen 486er DX, um einem fest verlötetem SX (wo der integrierte Coprozessor abgeschaltet war) zu ersetzen. Wiki weiß mehr: x87 – Wikipedia
Edit: Ist überhaupt gesichert, dass es sich dabei um 2 XCC Chips mit jeweils 4 deaktivierten Kernen handelt? Könnten es nicht auch genauso 6 i7 9700 oder genauer, deren Xeon Versionen sein? Wûrde schliesslich auch passen, sowohl das fehlen vom SMT als auch die 12 Speicherkanäle. Angesichts des Verbrauchs und der Abwärme eines XCC wären 6 theoretische i7 9700T wohl deutlich sparsamer
Zuletzt bearbeitet:
wolflux
Lötkolbengott/-göttin
AW: Cascade Lake-AP: Nach AMDs Epyc "klebt" jetzt auch Intel CPUs zusammen
Ich habe in FarCry5 mit abgeschalteten Threads flüssigere Performance.
Ich habe mich schon immer gefragt warum man Threads nicht einfach in Windows selber hinzu oder ganz abschalten kann.
Erinnert mich an CBR15 wo ich unter Preferences soviel Threads zuschalten kannst wie man möchte. Ich weiß natürlich das das eine mit dem anderen nichts zu tun hat. Ist mir nur gerade so eingefallen.
Ich habe in FarCry5 mit abgeschalteten Threads flüssigere Performance.
Ich habe mich schon immer gefragt warum man Threads nicht einfach in Windows selber hinzu oder ganz abschalten kann.
Erinnert mich an CBR15 wo ich unter Preferences soviel Threads zuschalten kannst wie man möchte. Ich weiß natürlich das das eine mit dem anderen nichts zu tun hat. Ist mir nur gerade so eingefallen.
AW: Cascade Lake-AP: Nach AMDs Epyc "klebt" jetzt auch Intel CPUs zusammen
Dadurch, dass viele Berechnungen auch mal ein paar Takte dauern können, sollte es möglich sein, falls ein Thread stallt, weil die nötigen Einheiten für seine Berechnungen gerade alle beschäftigt sind, auf einen anderen zu wechseln, der andere Einheiten braucht. Dazu müssen die Thread natürlich entsprechend verschiedene Anforderungen haben.
Ich würde sagen, dass hier der Trade-Off ganz klar auf Singlethreadleistung und Multithreadleistung ist. Wenn man Threads wechselt, statt spekulative Berechnungen auszuführen, wird, wie du schon sagst, weniger umsonst gerechnet, aber die Singlethreadleistung lässt halt nach. Wenn man auf Multithreaddurchsatz aus ist, kann man dann aber direkt auch die einzelnen Kerne einfacher gestalten und sich die ganze Spekulation sparen. In bestimmten Anwendungsbereichen sicher eine sinnvolle Herangehensweise. Ich meine die frühen Atom-CPUs haben versucht mit SMT die Schwächen der simplen Kerne auszugleichen. SMT sollte deutlich weniger Chipfläche brauchen als Out-of-Order-Execution, kann beim Gesamtdurchsatz der CPU aber eine ähnliche Wirkung haben.
Das Ranschaufeln von Daten kostet die CPU minimal Zeit, danach ist das das Problem des Speichercontrollers und die CPU läuft sogesehen leer. Zumindest ab dem Punkt, ab dem eine Abhängigkeit zu den aufgerufenen Daten aufkommt, was in der Regel ziemlich fix passiert.
Dadurch, dass viele Berechnungen auch mal ein paar Takte dauern können, sollte es möglich sein, falls ein Thread stallt, weil die nötigen Einheiten für seine Berechnungen gerade alle beschäftigt sind, auf einen anderen zu wechseln, der andere Einheiten braucht. Dazu müssen die Thread natürlich entsprechend verschiedene Anforderungen haben.
Ich würde sagen, dass hier der Trade-Off ganz klar auf Singlethreadleistung und Multithreadleistung ist. Wenn man Threads wechselt, statt spekulative Berechnungen auszuführen, wird, wie du schon sagst, weniger umsonst gerechnet, aber die Singlethreadleistung lässt halt nach. Wenn man auf Multithreaddurchsatz aus ist, kann man dann aber direkt auch die einzelnen Kerne einfacher gestalten und sich die ganze Spekulation sparen. In bestimmten Anwendungsbereichen sicher eine sinnvolle Herangehensweise. Ich meine die frühen Atom-CPUs haben versucht mit SMT die Schwächen der simplen Kerne auszugleichen. SMT sollte deutlich weniger Chipfläche brauchen als Out-of-Order-Execution, kann beim Gesamtdurchsatz der CPU aber eine ähnliche Wirkung haben.
Das Ranschaufeln von Daten kostet die CPU minimal Zeit, danach ist das das Problem des Speichercontrollers und die CPU läuft sogesehen leer. Zumindest ab dem Punkt, ab dem eine Abhängigkeit zu den aufgerufenen Daten aufkommt, was in der Regel ziemlich fix passiert.
G
gaussmath
Guest
AW: Cascade Lake-AP: Nach AMDs Epyc "klebt" jetzt auch Intel CPUs zusammen
Hast du eigentlich Shadow of the Tomb Raider? Wenn ja, läuft das bei dir auch ohne HT besser?
Hast du eigentlich Shadow of the Tomb Raider? Wenn ja, läuft das bei dir auch ohne HT besser?
G
gaussmath
Guest
AW: Cascade Lake-AP: Nach AMDs Epyc "klebt" jetzt auch Intel CPUs zusammen
Auch wenn ich es ziemlich radikal finde, könnt ihr gerne solche Zugriffslatenzen als Leerlauf bezeichnen.
Auch wenn ich es ziemlich radikal finde, könnt ihr gerne solche Zugriffslatenzen als Leerlauf bezeichnen.
wolflux
Lötkolbengott/-göttin
AW: Cascade Lake-AP: Nach AMDs Epyc "klebt" jetzt auch Intel CPUs zusammen
Ne, leider nicht. Warum?
Ne, leider nicht. Warum?
G
gaussmath
Guest
AW: Cascade Lake-AP: Nach AMDs Epyc "klebt" jetzt auch Intel CPUs zusammen
Der Unterschied zwischen SMT on/off ist auf meinem Threadripper ziemlich groß.
Der Unterschied zwischen SMT on/off ist auf meinem Threadripper ziemlich groß.
Ähnliche Themen
