Zehn Kerne bei Intel: Interne Dokumente sollen Leistung des Core i9-10900K zeigen

Aber nur bei Dinge auf die es doch gar nicht ankommt, Benchmarks wie Cinebench und Prime die alle Kerne voll auslasten. Dafür ist aber weder der 10900K noch der 3900X, den er mit genug Takt und entsprechender Leistungsaufnahme (also der Brechstange) vielleicht erreichen kann, die richtigen CPUs. Wer wirklich viel mehr solche Anwendungen arbeitet, der wird keine Mainstream CPU kaufen und wenn, dann den 3950X.....
Für was sind die dann gedacht? Für Browserspiele? Oder um mal mit dem Rechner bei Windows 23 x 56 auszurechnen?
Hast du irgendwelche handfeste Zahlen die deine Meinung bestätigen, dass es nur Menschen gibt, die entweder einen 10/12 Kerner brauchen für ?. Du hast ja kein einziges Beispiel genannt. Kannst du auch Zahlen vorlegen die zeigen, dass es dann nur Menschen gibt, die einen 16 und noch höher unbedingt brauchen, anstatt 10, oder 12 Kerne? Wie sieht es dann mit den 14, 18 Kerne bei Comet Lake X aus?
 
Wenn Du diese Anzeige nicht sehen willst, registriere Dich und/oder logge Dich ein.
Also AMD wird auch irgendwann mit dem immer mehr werden der Kerne aufhören, denn mit steigenden Kern Zahl da sinkt dann auch der takt. Da werden die CPUs dann ineffizienter.

Wenn man ein Chaos oder extreme hitzeenwicklung haben will, dann nehme man eine CPU deren Fläche kleiner als ne Münze ist, auch außen drum rum auch kleiner als die meisten anderen CPUs, packt dort 10 oder gar 20 Kerne drauf, mit am besten 5 oder gar 6 GHz. Dann wird es ne Heizung werden und dann hilft auch ne Wasserkühlung mit 3x 570er Radiatoren nicht mehr. Stromverbrauch dürfte dann 1000 Watt bei der CPU sein und die 100 Grad sind dann auch sicher. Die CPU würde also ständig Dauer runter takten bzw dropen.
Das kann sich wohl keiner mehr antunen.

So was wird wohl kein hersteller machen. Also werden langfristig wohl die CPUs größer. Auch bei Intel werden langfristig die CPUs dann größer. Wobei ich bezweifele das wir 100 Kerne oder mehr auf so einen kleinen Raum jemals sehen werden.
Und ich glaube auch das wenn es Hard wird, auch der 10 Kerner mit dem takt nicht mehr dauerhaft 4,8 allcore schaffen wird, nicht bei 125 Watt.

Wobei ich nicht verstehen kann warum mein 10 Kerner trotz 4 GHz nur 60 Watt verbeauch anzeigt. Nagut ich verwende garkein einziges avx, dennoch wird der doch wohl mehr als 60 Watt verbraten oder irre ich mich denn da etwa?
 
Also AMD wird auch irgendwann mit dem immer mehr werden der Kerne aufhören, denn mit steigenden Kern Zahl da sinkt dann auch der takt. Da werden die CPUs dann ineffizienter.

Effizenz kommt mit der Fertigungsgröße... (14+++++++++++++++++++++++++++ funktioniert nicht, kannst mit 10 Kernen das Wohnzimmer heizen...)
Wo soll der Weg denn sonst hingehen anstelle von Multikern CPUs?

Den 10 Ghz Traum hatten diverse x86 Hersteller schon vor 25 Jahren...
Mit der aktuellen CPU Technik bleibt nur die Parallelisierung...
 
Es gibt Software wie CAD-Programme (ich spreche nicht von Simulationen/FEM) da kannst du nichts parallelisieren. Da werden 1-2 Kerne vielleicht ausgelastet, dann ist schluss. Da ist man auf andere Optimierungen angewiesen, die zb. dann über die GPU geht.
 
Wo soll der Weg denn sonst hingehen anstelle von Multikern CPUs?

...

Mit der aktuellen CPU Technik bleibt nur die Parallelisierung...
Meine Prognose, man wird sich auf Befehlserweiterungen zur besseren Problemlösung hin ausrichten (müssen), eben da ich auch meine dass man nicht endlos in die Breite gehen kann. Zusätzlich dazu wird zumindest Intel mit Foveros einen anderen Ansatz ggü. AMDs MCM Lösung versuchen und wie bei Smartphones üblich eine Art BigLittle Prinzip zu etablieren. Gerade die Befehlserweiterungen aber bieten noch riesiges Potential. Allerdings wird das nicht ohne Softwareanpassungen gehen - das wird also eher träger Fortschritt, aber wenn Software mal mitspielt, dann können das auch mal easy 15-20% und mehr sein...
 
Meine Prognose, man wird sich auf Befehlserweiterungen zur besseren Problemlösung hin ausrichten (müssen), eben da ich auch meine dass man nicht endlos in die Breite gehen kann. Zusätzlich dazu wird zumindest Intel mit Foveros einen anderen Ansatz ggü. AMDs MCM Lösung versuchen und wie bei Smartphones üblich eine Art BigLittle Prinzip zu etablieren. Gerade die Befehlserweiterungen aber bieten noch riesiges Potential. Allerdings wird das nicht ohne Softwareanpassungen gehen - das wird also eher träger Fortschritt, aber wenn Software mal mitspielt, dann können das auch mal easy 15-20% und mehr sein...

Es gäbe bzw gibt noch einen weiteren Ansatz. Man erweitert den Cache, also l1 - l3 und macht l4 als Standard. Man könnte auch hbm als cache hernehmen oder RAM Bausteine auf CPU mit gddr6 extra. Es gäbe soviele Möglichkeiten. Was davon wohl die bessere Option ist. Auf jedenfall ist das die wesentlich bessere Option als nur die ganze Zeit befehltserweiterungen dran zu hängen. Hm vielleicht gibt es ja auch ein Cluster befehltserweiterung. Wo man es zersplitten kann, um wirklich dafür zu sorgen die ganze CPU auszulasten. Oder man findet ne völlig andere Option, die wir noch nicht auf dem Schirm gehabt hatten.
 
Cache ist nicht unbedingt klein.
Wenn du noch größere Mengen Cache mit drauf klatschen willst, wird die CPU preislich unattraktiv, solange es weiterhin 14++++++++++ ist.
Und die gesamte Architektur der CPU muss damit auch was anfangen können, sonst wird die CPU teurer ohne große Mehrleistung.

Cache ist gut, aber leider kein Allheilmittel.
 
Was soll der Cache bringen? Cache gibt nicht mehr Geschwindigkeit - zumal GDDR6 oder HBM oder keine Ahnung, lahm ist im Vergleich zu L1 oder L2 Cache. Selbst die L3 Cache Ausbauten nehmen weiter (vereinfacht gesagt) vom Speed her massiv ab, wenn man die Größe stark erhöht. Cache hilft lediglich, die Rechenwerke vor Wartezeit zu schützen, indem die Daten, die dort verarbeitet werden, schneller verfügbar gemacht werden sollen. Das geht halt bis zu dem Punkt, wo kein Leerlauf mehr vorhanden ist - dann bringt es wenig bis keine Punkte, da noch weiter mit Cache drauf zu kloppen. Stell dir mal die Frage, warum im GPU Umfeld GDDR6 oder HBM nicht als Cache in deinem Sinne genutzt wird, sondern als RAM (und damit letzte aka langsamste Stufe von Zwischenspeicher)? GPUs nutzen genau so intern viel viel schnellere Cachestufen, weil GDDR6 und HBM auch zu lahm sind. Der Zugriff auf die Speichercontroller in aktuellen GPUs wandert bspw. durch nen L2 Cache von ein paar wenigen MB absolute Größe.

Mal im Vergleich, der i7-5775C Boardwell mit L4 Cache schafft um die 50GB/sec bei um die 40ns Latenz für eben jenen 128MB EDRAM als Cache, wenn mich nicht alles täuscht. Ein aktueller Ryzen oder Intel Skylake based Prozessor kommt auf ebenso um die 50GB/sec Durchsatz bei 3200er RAM und ansatzweise brauchbaren Timings - die Latenz ist bei um die 50ns, wenn ich das richtig sehe. Beim Ryzen prinzipbedingt etwas langsamer, aber das tut ihm auch keinen Abbruch, wie bekannt sein dürfte.
Die Frage wäre also, was außer nakte Theorie soll der Cache für einen greifbaren Vorteil bringen um den Aufwand zu rechtfertigen??

Befehlserweiterungen hingegen sind gängige Praxis. Man schaue sich einfach mal das Basisbefehlswerk von x86 an und vergleiche das mit heute. Reiner x86 Code ist durch all die Anpassungen der CPUs über die Jahrzente nicht um sonst wie viele Faktoren gestiegen. Leistung kommt dort vom Takt (aber da ist ein Ende in Sicht) und von Anpassungen in der Ausführung, OoO Execution, Pipelining, SMT usw. Nimmt man das alles zusammen und rechnet das auf eine Pro Takt Performance runter, so hat sich zwar viel getan seit den Anfängen, aber es ist dennoch überschaubar. Befehlserweiterungen, die dafür sorgen, dass angepasste Rechenwerke konkrete Aufgaben eben in x-Facher Geschwindigkeit zu vorher (der Software Implementierung) durchführen, bringt allerdings teils drastisch mehr Performance.

Ein ganz klassisches Beispiel dafür ist bspw. AES-NI. Man kann den Spaß in Software auf den CPU Cores rechnen lassen oder man bemüht einfach ein paar dedizierter Einheiten mit einer Befehlserweiterung, die das dann einfach um Größenordnungen schneller hinbekommen. Gleiches gilt für die diversen SSE und AVX Implementationen. Das Resultat am Ende bleibt ja quasi identisch, die Recheneinheiten im Prozessor aber können es viel viel schneller als eben ohne. Das Potential an der Stelle ist aktuell nicht bezifferbar, weil theoretisch endlos. Takt, Cache, Cores, CPU Anzahl usw. hingegen ist endlich.
 
Ich erinnere mich, das Broadwell-Desktop sich damals in manchen Games gerade wegen des als L4-Cache genutzten eDRAM sehr gut gegen den deutlich höher getakteten Devils Canyon halten konnte. Hier. Oft ein paar % schneller als der 4770K und die Xeons mit 4C/8T, etwas langsamer als der 4790K, aber auch mal minimal schneller. Dann auch mal wieder deutlich langsamer als alle anderen. Trotzdem, der eDRAM gleicht gut 500-600MHz Taktnachteil ggü 4790K gut aus.
Das war damals auch kein Grund, auf Broadwell zu setzten, weil OC eben auch eher mau war und so der Taktnachteil deutlich überwog, aber so nutzlos ist eDRAM nicht. Nur sieht Intel berechtigerweise keinen Grund darin, langsamere, sparsamere CPUs mit stärkerer (zum Zocken aber noch meist unbrauchbarer) IGP auf den Desktop zu bringen. Broadwell Desktop war damals ein Reinfall.
 
Zuletzt bearbeitet:
Was soll der Cache bringen? Cache gibt nicht mehr Geschwindigkeit - zumal GDDR6 oder HBM oder keine Ahnung, lahm ist im Vergleich zu L1 oder L2 Cache. Selbst die L3 Cache Ausbauten nehmen weiter (vereinfacht gesagt) vom Speed her massiv ab, wenn man die Größe stark erhöht. Cache hilft lediglich, die Rechenwerke vor Wartezeit zu schützen, indem die Daten, die dort verarbeitet werden, schneller verfügbar gemacht werden sollen. Das geht halt bis zu dem Punkt, wo kein Leerlauf mehr vorhanden ist - dann bringt es wenig bis keine Punkte, da noch weiter mit Cache drauf zu kloppen. Stell dir mal die Frage, warum im GPU Umfeld GDDR6 oder HBM nicht als Cache in deinem Sinne genutzt wird, sondern als RAM (und damit letzte aka langsamste Stufe von Zwischenspeicher)? GPUs nutzen genau so intern viel viel schnellere Cachestufen, weil GDDR6 und HBM auch zu lahm sind. Der Zugriff auf die Speichercontroller in aktuellen GPUs wandert bspw. durch nen L2 Cache von ein paar wenigen MB absolute Größe.

Mal im Vergleich, der i7-5775C Boardwell mit L4 Cache schafft um die 50GB/sec bei um die 40ns Latenz für eben jenen 128MB EDRAM als Cache, wenn mich nicht alles täuscht. Ein aktueller Ryzen oder Intel Skylake based Prozessor kommt auf ebenso um die 50GB/sec Durchsatz bei 3200er RAM und ansatzweise brauchbaren Timings - die Latenz ist bei um die 50ns, wenn ich das richtig sehe. Beim Ryzen prinzipbedingt etwas langsamer, aber das tut ihm auch keinen Abbruch, wie bekannt sein dürfte.
Die Frage wäre also, was außer nakte Theorie soll der Cache für einen greifbaren Vorteil bringen um den Aufwand zu rechtfertigen??

Befehlserweiterungen hingegen sind gängige Praxis. Man schaue sich einfach mal das Basisbefehlswerk von x86 an und vergleiche das mit heute. Reiner x86 Code ist durch all die Anpassungen der CPUs über die Jahrzente nicht um sonst wie viele Faktoren gestiegen. Leistung kommt dort vom Takt (aber da ist ein Ende in Sicht) und von Anpassungen in der Ausführung, OoO Execution, Pipelining, SMT usw. Nimmt man das alles zusammen und rechnet das auf eine Pro Takt Performance runter, so hat sich zwar viel getan seit den Anfängen, aber es ist dennoch überschaubar. Befehlserweiterungen, die dafür sorgen, dass angepasste Rechenwerke konkrete Aufgaben eben in x-Facher Geschwindigkeit zu vorher (der Software Implementierung) durchführen, bringt allerdings teils drastisch mehr Performance.

Ein ganz klassisches Beispiel dafür ist bspw. AES-NI. Man kann den Spaß in Software auf den CPU Cores rechnen lassen oder man bemüht einfach ein paar dedizierter Einheiten mit einer Befehlserweiterung, die das dann einfach um Größenordnungen schneller hinbekommen. Gleiches gilt für die diversen SSE und AVX Implementationen. Das Resultat am Ende bleibt ja quasi identisch, die Recheneinheiten im Prozessor aber können es viel viel schneller als eben ohne. Das Potential an der Stelle ist aktuell nicht bezifferbar, weil theoretisch endlos. Takt, Cache, Cores, CPU Anzahl usw. hingegen ist endlich.
Hm,wenn weder Takt,Cache und Cores für eine echte Leistungssteigerung sorgen werden langfrsitig,dann sehe ich es schon sehr eng.Es gibt sehr viele Entwickler die Faul sind,es zu teuer ist oder was anderes.Die Software ist nämlich teuer als Hardware.
Das scheinst du außer acht zu lassen.Ich habe ne SOftware wo AVX keine wirkung hat.Also habe ich keine großen Optionen für ne echte Leistungssteigerung.Beim Takt sehe ich auch keine große steigerung mehr.Ab einen gewissen Punkt ist halt dann sense im Gelände.
Wenn uns wirklich nur noch Befehlserweiterung weiterhelfen,dann ist das schon armselig.DIe Entwickler brauchen manchmal sehr lange bis da mal ne Optimierung stattfindet.Also ne andere Option wäre also besser,aber nur halt welche.Ich sehe halt keine mehr.
Shrinken bis nichts mehr get,bringt uns ja auch nicht automatisch mehr Leistung.Wenn wir also nicht unsere neuen CPU´s verglühen sehen wollen,dann brauchen wir halt ne andere Option in Zukunft.Da müssen sich halt dann die CPU hersteller etwas neues einfallen lassen.Was das kann ich nicht sagen,auf jedenfall was neues.

Geplant hatte ja Intel mal,die x86 Einheiten zu streichen und über x64 zu simulieren zu lassen.Aber aus dem Plan scheint ja wohl nix draus geworden zu werden.Auf jedenfall verkleinern um mehr Platz für mehr Transistoren zu haben.x86 ist doch eigentlich schon längst tot,die meiste Software hat doch schon längst x64 als standard,oder irre ich mich da etwa?
 
@Tigerfox

Dann schau aber halt auch mal was passiert, wenn der Takt deutlich niedriger ausfällt. Der 3,5GHz Base, Boost 3,8-3,9 1C bis 4C, 4770k ist gleich schnell, der 4GHz Base, Boost 4,2-4,4GHz 1C bis 4C 4790k 3% schneller, der 5775C mit 3,3GHz Base, 3,6-3,7GHz Boost 1C bis 4C, dafür aber Broadwell Architektur, also minimal. verbessert ggü. Haswell, "gleicht" damit im Schnitt im CPU Limit bei 640x480 brachiale 200MHz "aus". Das sind 5, 6, lass es 7% sein, trotz neuerer Architektur. Ist das jetzt wirklich der Rede wert???

Im Endeffekt ist das exakt die gleiche Nummer wie dem Ding anstatt Stock RAM eben RAM mit scharfen Timings und hohem Durchsatz anzuhängen. Das bringt dir an der Stelle auch genug um das bisschen Auszugleichen. Wenn du den RAM halt annähernd in die L4 Cache Performance bekommst, dann bringt die zusätzliche Stufe halt auch nix mehr. Broadwell supportet offiziell 1600er DDR3, genau so wie die Haswells. Stopf da 2400er Low Latency Sticks rein und das bringt dir überall dort nen Boost, wo der Broadwell von seinem Cache potentiell performt.

Hm,wenn weder Takt,Cache und Cores für eine echte Leistungssteigerung sorgen werden langfrsitig,dann sehe ich es schon sehr eng.Es gibt sehr viele Entwickler die Faul sind,es zu teuer ist oder was anderes.Die Software ist nämlich teuer als Hardware.
Das scheinst du außer acht zu lassen.
Falsche rangehensweise. Was die Softwareindustrie macht und was die Hardware Hersteller machen, sind generell erstmal zwei paar Schuhe. Ich muss da nichts außer acht lassen was nicht zusammen gehört. Wenn ein Hersteller meint, Befehlserweiterungen zu bringen, die einen Mehrwert bieten, wie bspw. SSE in den diversen Ausführungen, wie bspw. AVX, wie bspw. AES-NI usw. usf., dann wird es früher oder später eben auch Software geben, die darauf aufbauen. Eben weil es einen Vorteil bringt, diese Erweiterungen zu nutzen anstatt es sein zu lassen. Unterm Strich wird der Fortschritt somit über die Zeit kommen.

Die Leier mit zu Faul und bla ist halt auch nur ausgedachter Kaffee ohne wirklich praktischen Bezug. Mit Faulheit hat das wenig bis gar nix zu tun. Eher mit dem Fokus auf ein gewisses Ziel. In den Foren meinen die "Profis" immer der Nabel der Welt zu sein. Sind sie aber idR nicht. Die Software muss viel mehr erreichen als ein paar Selbstschrauber, die immer den neuesten Shice im PC haben wollen... Entsprechend auch die Ausrichtung. Es hat ewig und drei Tage gedauert bis die gesunde Basis mal bei SSE2 bzw. mittlerweile SSE4/4.1/4.2 angekommen ist, eben weil viele viele viele User noch mit Assbach Hardware durch die Gegend laufen und die Software dann halt einfach nicht funktioniert... Siehe dazu die ganzen "Beschwerden" in den Foren über bspw. Games, die auf Phenom CPUs von AMD wegen SSE4 nicht laufen usw. Sowas hemmt halt den Fortschritt ungemein. Ein radikaler Schritt funktioniert nur mit Schmerzen und massivem Gegenwind. Auf Dauer wird man sich da was einfallen lassen müssen.

Geplant hatte ja Intel mal,die x86 Einheiten zu streichen und über x64 zu simulieren zu lassen.Aber aus dem Plan scheint ja wohl nix draus geworden zu werden.Auf jedenfall verkleinern um mehr Platz für mehr Transistoren zu haben.x86 ist doch eigentlich schon längst tot,die meiste Software hat doch schon längst x64 als standard,oder irre ich mich da etwa?
Hää? IA64 hat nix mit irgendwelchen "x86 Einheiten" zu tun. Man versuchte in gewissen Marktbereichen, vllt auch mal global, lässt sich heute nicht belegen, eine IA32 inkompatible Architektur zu etablieren, die aber per Emulation IA32 ausführen hat können sollen. Ein Fehler wie man erkannte, deswegen ist das Projekt auch massiv gegen den Baum gegangen und die IA32 kompatible Lösung von AMD hat sich durchgesetzt. Nur wo ist hier jetzt der Zusammenhang zum Rest der Aussage? Ob Software heute in 32Bit oder 64Bit ausgeliefert wird, ist in erster Linie erstmal Entscheidung des Entwicklers, denn es läuft eben beides auf einem "64Bit" OS. Bis auf ein paar Ausnahmen, wo entsprechende Anforderungen gestellt sind/werden, bspw. im Treiberumfeld.
 
@Tigerfox

Dann schau aber halt auch mal was passiert, wenn der Takt deutlich niedriger ausfällt. Der 3,5GHz Base, Boost 3,8-3,9 1C bis 4C, 4770k ist gleich schnell, der 4GHz Base, Boost 4,2-4,4GHz 1C bis 4C 4790k 3% schneller, der 5775C mit 3,3GHz Base, 3,6-3,7GHz Boost 1C bis 4C, dafür aber Broadwell Architektur, also minimal. verbessert ggü. Haswell, "gleicht" damit im Schnitt im CPU Limit bei 640x480 brachiale 200MHz "aus". Das sind 5, 6, lass es 7% sein, trotz neuerer Architektur. Ist das jetzt wirklich der Rede wert???

Im Endeffekt ist das exakt die gleiche Nummer wie dem Ding anstatt Stock RAM eben RAM mit scharfen Timings und hohem Durchsatz anzuhängen. Das bringt dir an der Stelle auch genug um das bisschen Auszugleichen. Wenn du den RAM halt annähernd in die L4 Cache Performance bekommst, dann bringt die zusätzliche Stufe halt auch nix mehr. Broadwell supportet offiziell 1600er DDR3, genau so wie die Haswells. Stopf da 2400er Low Latency Sticks rein und das bringt dir überall dort nen Boost, wo der Broadwell von seinem Cache potentiell performt.


Falsche rangehensweise. Was die Softwareindustrie macht und was die Hardware Hersteller machen, sind generell erstmal zwei paar Schuhe. Ich muss da nichts außer acht lassen was nicht zusammen gehört. Wenn ein Hersteller meint, Befehlserweiterungen zu bringen, die einen Mehrwert bieten, wie bspw. SSE in den diversen Ausführungen, wie bspw. AVX, wie bspw. AES-NI usw. usf., dann wird es früher oder später eben auch Software geben, die darauf aufbauen. Eben weil es einen Vorteil bringt, diese Erweiterungen zu nutzen anstatt es sein zu lassen. Unterm Strich wird der Fortschritt somit über die Zeit kommen.

Die Leier mit zu Faul und bla ist halt auch nur ausgedachter Kaffee ohne wirklich praktischen Bezug. Mit Faulheit hat das wenig bis gar nix zu tun. Eher mit dem Fokus auf ein gewisses Ziel. In den Foren meinen die "Profis" immer der Nabel der Welt zu sein. Sind sie aber idR nicht. Die Software muss viel mehr erreichen als ein paar Selbstschrauber, die immer den neuesten Shice im PC haben wollen... Entsprechend auch die Ausrichtung. Es hat ewig und drei Tage gedauert bis die gesunde Basis mal bei SSE2 bzw. mittlerweile SSE4/4.1/4.2 angekommen ist, eben weil viele viele viele User noch mit Assbach Hardware durch die Gegend laufen und die Software dann halt einfach nicht funktioniert... Siehe dazu die ganzen "Beschwerden" in den Foren über bspw. Games, die auf Phenom CPUs von AMD wegen SSE4 nicht laufen usw. Sowas hemmt halt den Fortschritt ungemein. Ein radikaler Schritt funktioniert nur mit Schmerzen und massivem Gegenwind. Auf Dauer wird man sich da was einfallen lassen müssen.


Hää? IA64 hat nix mit irgendwelchen "x86 Einheiten" zu tun. Man versuchte in gewissen Marktbereichen, vllt auch mal global, lässt sich heute nicht belegen, eine IA32 inkompatible Architektur zu etablieren, die aber per Emulation IA32 ausführen hat können sollen. Ein Fehler wie man erkannte, deswegen ist das Projekt auch massiv gegen den Baum gegangen und die IA32 kompatible Lösung von AMD hat sich durchgesetzt. Nur wo ist hier jetzt der Zusammenhang zum Rest der Aussage? Ob Software heute in 32Bit oder 64Bit ausgeliefert wird, ist in erster Linie erstmal Entscheidung des Entwicklers, denn es läuft eben beides auf einem "64Bit" OS. Bis auf ein paar Ausnahmen, wo entsprechende Anforderungen gestellt sind/werden, bspw. im Treiberumfeld.
Ok ich merke schon,das ist also auch nicht die Lösung.Es war halt nur ein Gedanke gewesen.Das hatte ja weil intel selbst festgestellt hatte,das man halt limitiert wird,weil was von neuer Achetektur und da das Weglassen von x86 die Rede gewesen war.Aber anscheinend ist das Thema ja wieder bei Intel geschichte.Nun wenn also der ansatz also auch nix hilft,dann läuft also wirklich alles auf Befehlsatzerweiterungen hin.Aber du weist fall schon,Befehlsatzerweiterungen bedarf an Rechenwerke und nimmt auch dann einen gewissen Platz dann weg.Wenn also diese neuen Befehlsatzerweiterungen dann nicht genutzt werden können,dann hieße es ja das diese Rechnwerke dann däumchen drehen können oder können diese Rechenwerke dann auch andere Aufgaben dann machen.Denn ich finde die Rechenwerke sollten dann schon flexible sein.
Denn wenn einer so wie ich dann AVX nicht nutzen kann,dann würden ja 30 % der Rechenleistung brach liegen.Also müssten die ja auch andere Aufgaben erledigen können.Sonst wäre es ja unfair für andere Menschen dann.
 
Die Frage wäre eher, warum deine Software kein AVX nutzt - vllt bringt es da einfach mal unlängen mehr die Software zu wechseln als an eben dieser festzuhalten und sich über den Fortschritt zu beschweren? Video Encoding per Software profitiert nämlich sehr wohl von AVX und das auch nicht zu knapp. Lässt sich bspw. mit den verschiedenen auf gewisse Befehlserweiterungen hin kompilierten Versionen von ffmpeg oder mencoder 1a nachweisen.

Btw. unfair ist da nix dran, wenn eine Software was nutzt was eine andere nicht zu nutzen im Stande ist. Vor allem nicht ggü. irgendwelchen "Menschen" ;)
 
Die Frage wäre eher, warum deine Software kein AVX nutzt - vllt bringt es da einfach mal unlängen mehr die Software zu wechseln als an eben dieser festzuhalten und sich über den Fortschritt zu beschweren? Video Encoding per Software profitiert nämlich sehr wohl von AVX und das auch nicht zu knapp. Lässt sich bspw. mit den verschiedenen auf gewisse Befehlserweiterungen hin kompilierten Versionen von ffmpeg oder mencoder 1a nachweisen.

Btw. unfair ist da nix dran, wenn eine Software was nutzt was eine andere nicht zu nutzen im Stande ist. Vor allem nicht ggü. irgendwelchen "Menschen" ;)
Ja oder auch von der Auflösung abhängig.Zwischen 720x576 null mehr leistung zu 1920x1080 VIdeos wo es dann fast 50 % Mehrlseitung gegeben hatte.Also nicht immer ist es die Schuld der Software sondern auch von der Quelldatei abhängig.In meinem Fall würde also Befehlsatzerweitung auch nicht mehr wirklich was bringen.Hier bringt dann wirklich nur noch der Takt etwas.ALso ich merke da schon noch nen leistungsunterschied.
 
@fdsonne: Hast recht, im CPU-Limit ist der 5775C maximal gleichschnell oder 1% schneller als der 4770K, was dann in realen Frames quasi nix ist, der 4790K ist fast immer 2-9% schneller. Nur in Metro ist der 5775C 4-7% schneller als beide, dafür in Borderlands, CoD und F1 auch 2-3% langsamer als der 4770K und 3-5% langsamer als der 4790K, was die 100-200MHz weniger ggü 4770K und 500-600MHz ggü 4790K gut widerspiegelt.
Nicht umsonsonst sind aber in dem Vergleich auch Xeon-x1230/31-V3, die sind nämlich nahezu taktgleich mit dem 5775C, der eine 100MHz langsamer bei vier Kernen, aber gleichschell in allen anderen Fällen, der andere gleichschnell mit vier Kernen und 100MHz schneller in allen anderen Fällen. Dazu hat der 5775C übrigens noch 2MB L3-Cache weniger. In BF3 ist er 5-7% schneller als die Xeons, in Borderlands 5-8%, in CoD 2%. Crysis 2-3%, F1 2-4%, Skyrim 3-6% und Metro 10-11%.
Es ging mir ja nur darum, zu zeigen, dass da Potential drinsteckt. Die Verwendung des eDRAM als L4-Cache war nicht der ursprüngliche Zweck, kaum eine Software ist darauf abgestimmt. Wenn das zum Standard würde, könnte man da sicherlich mehr rausholen, siehe Metro. Und auch wenn das bewirkt, dass der Vorteil von schnellem RAM wieder geringer wird, bringt es doch mehr als dieser und ist auch günstiger.
 
Effizenz kommt mit der Fertigungsgröße
Effizienz kommt neben der Fertigung vor allem vom Betriebspunkt, also dem Takt und der dafür nötigen Spannung mit der die CPU betrieben wird! Schau mal hier dies bei Zen2 aussieht:

Zen2_Watt_Performance.png


Ab so 3,3GHz fällt die Effizienz dort massiv ab und wenn man sich nun mal die Taktraten der EYPC Rome CPUs ansieht, so findet man dort maximal 3,4GHz in den Datenblättern, warum wohl?

Wo soll der Weg denn sonst hingehen anstelle von Multikern CPUs?
Genau wie fdsonne sehe ich da die Befehlserweiterungen an erster Stelle, da mehr Takt schwer ist und die Skalierung über mehr Kerne auch imso schwerer wird, je mehr Kerne es sind. Außerdem lassen sich nicht alle Probleme parallelisieren, dies geht schlicht und einfach nicht immer.
Es gibt Software wie CAD-Programme (ich spreche nicht von Simulationen/FEM) da kannst du nichts parallelisieren. Da werden 1-2 Kerne vielleicht ausgelastet, dann ist schluss.
Eben, immer wenn die Ergebnisse einer Berechnungen von dem Ergebnis einer vorher ausgeführten Berechnung abhängt, kann man beide nicht parallel ausführen und bei CAD ist allenfalls das Render parallel möglich, bei der Konstruktion hängt aber alles aneinander und kann daher nur der Reihe nach berechnet werden. Auch bei Simulationen und Datenbanken ist es ist oft so, dass Daten voneinander abhängen bzw. bestimmte Daten eben geschützt sind und immer nur von einem Thread zur Zeit verändert werden dürfen. Dann wird z.B. ein Mutex verwendet und wenn noch mehr Threads auf den geschützten Bereich zugreifen wollen, müssen nur noch mehr Threads warten bis der eine den Bereich wieder freigegeben hat, die Performance steigt dann mit mehr Thread und damit CPU Kernen eben nicht.
Befehlserweiterungen, die dafür sorgen, dass angepasste Rechenwerke konkrete Aufgaben eben in x-Facher Geschwindigkeit zu vorher (der Software Implementierung) durchführen, bringt allerdings teils drastisch mehr Performance.

Ein ganz klassisches Beispiel dafür ist bspw. AES-NI.
Eben und und nach dem DL Boost für die Cascade Lake kommen mit für Tiger Lake gibt es die nächste Erweiterung:
Intel pusht die Befehlserweiterungen massiv voran, AMD übernimmt sie meist erst, wenn die Software die dieser nutzen kann, weiter verbreitet ist.
Ich erinnere mich, das Broadwell-Desktop sich damals in manchen Games gerade wegen des als L4-Cache genutzten eDRAM sehr gut gegen den deutlich höher getakteten Devils Canyon halten konnte.
Aber nur bei bestimmten Anwendungen / Spielen, bei anderen bringt das eDRAM auch nichts, es hängt eben immer davon ab wie gut die Performance mit der RAM Bandbreite und Latenz skaliert.
Trotzdem, der eDRAM gleicht gut 500-600MHz Taktnachteil ggü 4790K gut aus.
Manchmal, aber lange nicht immer. Schau Dir die einzelnen Anwendungen an, dann siehst Du das der 5775C immer mal wieder vor oder hinter anderen CPUs liegt, je nachdem wie viel das eDRAM da bringt. Die 3,3GHz sollte man übrigens wie immer nicht ernst nehmen, die Boads übertakten die CPUs ja schon im Default und daher müssten in den Reviews für jeden Benchmark für jede CPU Takt und Leistungsaufnahme angegeben sein, wenn man die Ergebnisse wirklich einordnen will. So schlecht übertaktbar war die CPUs im Review bei CB ja nun nicht:
Was die Softwareindustrie macht und was die Hardware Hersteller machen, sind generell erstmal zwei paar Schuhe.
Deswegen hängt es ja auch sehr von der Unterstützung ab, die die Hardware Hersteller den Softwareentwicklern bieten. Intel ist da weit vorne, man schau sich an wie viele verschiedene und optimierte Libs es von Intel gibt, vor dem Intel Compiler nicht zu reden. AMD bot in der Vergangenheit ein trauriges Bild, die 3DNow Befehlserweiterung wurde dann auch wieder gestrichen und bei Fusion bot AMD ein ganz trauriges Bild, die SW Unterstützung kam viel zu spät und erst Kaveri hatte die volle HSA-Unterstützung auf der Hardwareseite, mit RYZEN wurde auch hier alles wieder über Bord geworfen. Die Verbreitung der Nutzung und damit der Erfolg neuer Befehlserweiterungen hängt eben sehr von der Unterstützung der SW Anwender mit Tool und fertigen libs ab.
weil viele viele viele User noch mit Assbach Hardware durch die Gegend laufen und die Software dann halt einfach nicht funktioniert... Siehe dazu die ganzen "Beschwerden" in den Foren über bspw. Games, die auf Phenom CPUs von AMD wegen SSE4 nicht laufen usw. Sowas hemmt halt den Fortschritt ungemein.
Da kann die Lösung nur in alternativen Codepfaden liegen, die Software auch noch auf den alten CPUs laufen kann. Das gibt dann natürlich wieder böses Blut, weil gerade Intel natürlich die Optimierungen nur für seine CPUs aktiviert, aber niemand hindert AMD daran selbst optimierte libs und einen gut optimierenden Compiler anzubieten.
Die Verwendung des eDRAM als L4-Cache war nicht der ursprüngliche Zweck, kaum eine Software ist darauf abgestimmt.
Der ursprüngliche Zweck des eDRAM war die iGPU zu beschleunigen und dies macht es ja auch sehr gut, wenn man sich die Performance der iGPUs mit und ohne eDRAM ansieht, denn es gab ja nicht nur bei Broadwell so ein eDAM, auch wenn es meines Wissens nach nur dort auch als L4-Cache für die CPU funktioniert hat. Software jetzt auch noch auf die jeweiligen Cachegrößen hin optimieren zu wollen, ist aber wohl etwas zu viel verlangt, den Aufwand kann nur jemand treiben, der die Software auf eine konkrete Hardware hin optimieren kann oder muss.
 
Hää? IA64 hat nix mit irgendwelchen "x86 Einheiten" zu tun. Man versuchte in gewissen Marktbereichen, vllt auch mal global, lässt sich heute nicht belegen, eine IA32 inkompatible Architektur zu etablieren, die aber per Emulation IA32 ausführen hat können sollen. Ein Fehler wie man erkannte, deswegen ist das Projekt auch massiv gegen den Baum gegangen und die IA32 kompatible Lösung von AMD hat sich durchgesetzt.
Der Hardware Emulator war beim Itanium ein Fehler und wurde beim Itanium2 bereits weggelassen, da HP (der wichtigste Kunde und am Ende einzige Kunde) einen besseren JIT Emulator für x86 Code auf IA64 geschrieben hatte. IA64 scheiterte am VLIW Design, da die Compiler perfekten Code hätten erzeugen müssen, damit die CPUs richtig ausgelastet werden können. IBM hatte den richtigen Riecher und die Entwicklung von einem Itanium basierten UNIX mit SCO eingestellt, und weiter auf die eigene Power Plattform gesetzt. Leider hat der Itanium drei UNIX Plattformen (auch CPU Plattformen) das Leben ausgehaucht: IRIX (MIPS CPUs), Tru64 (Alpha) und HP-UX (HP-PA). SGI hatte sich mit der Portierung von IRIX auf IA64 verzettelt, anstatt konsequent die eigene MIPS Plattform weiter zu entwickeln. HP hat nach der Übernahme von Compaq Alpha plattgemacht und HP-PA zu Gunsten von IA64 eingestellt. All diese RISC CPUs hatten eine ganze Reihe von guten Ansätzen, wie man CPUs generell schneller bekommt als x86. Leider hat AMD die Welt mit AMD64 bestraft und wird müssen weiterhin mit diesem Dreck (es ist die schlechteste CPU ISA die noch auf dem Markt vertreten ist) leben.

Am Anfang der 2000er war Windows immer noch total von x86 abhängig, und deshalb sind alle Hersteller schnurstracks auf AMD64 umgeschwenkt und IA64 war in diesem Moment tot. Der aufgebrezelte 4004 Nachfahre beglückt uns immer noch mit grauenhaften Befehlssätzen und Adressmodi. Man kann nur hoffen, dass entweder ARM64 oder RISC-V das Rennen macht, und x86 komplett verschwindet.
 
Der aufgebrezelte 4004 Nachfahre beglückt uns immer noch mit grauenhaften Befehlssätzen und Adressmodi.
Das interessiert doch nur noch Assemblerprogrammierer, aber wie viele oder eher wenige gibt es davon noch? Immer mehr Software wird sogar in interpretierten Sprachen wie C# oder JAVA geschrieben, da ist man von der Plattform weitgehend unabhängig und es liegt nur in der Hand des Anbieters des Frameworks hier neuste Hardwarefeatures wie Befehlserweiterungen zu unterstützen.

ARM oder RISC-V werden x86 nicht ablösen, davon bin ich überzeugt und schon gar nicht wegen der "grauenhaften Befehlssätzen und Adressmodi".
 
Das interessiert doch nur noch Assemblerprogrammierer, aber wie viele oder eher wenige gibt es davon noch?
Da irrst Du. Der Befehlssatz wirkt sich dramatisch auf die Ausführung des Codes aus. Ein CISC Prozessor hat sehr stark unterschiedliche Befehlslängen, was ein Problem für die Sprungsvorhersage wird. Wo hat Intel noch einmmal massive Probleme? Bei der spekulativen Auswertung von Befehlen! Ein RISC-Prozessor hat sehr stark vereinheitlichte Befehle, alle sind Vielfache eines Words. Faktisch alle sind direkt in Hardware umgesetzt, während wegen der Komplexität bei CISC ein Großteil der Befehle als Microcode ausgeführt werden muss, auch das wirkt sich auf die Caches aus.
 
Da irrst Du. Der Befehlssatz wirkt sich dramatisch auf die Ausführung des Codes aus. Ein CISC Prozessor hat sehr stark unterschiedliche Befehlslängen, was ein Problem für die Sprungsvorhersage wird. Wo hat Intel noch einmmal massive Probleme? Bei der spekulativen Auswertung von Befehlen! Ein RISC-Prozessor hat sehr stark vereinheitlichte Befehle, alle sind Vielfache eines Words. Faktisch alle sind direkt in Hardware umgesetzt, während wegen der Komplexität bei CISC ein Großteil der Befehle als Microcode ausgeführt werden muss, auch das wirkt sich auf die Caches aus.
Diese krasse Trennung existiert nicht mehr!
Und die Sprungvorhersage hat erstmal nicht soviel mit CISC/RISC zu tun.
Schau dir das Blockschaltbild vom SKL-X und Zen+/2 an.
Sehr ähnlich mit vor und Nachteilen auf beiden Seiten.
 
Ja jeder weiß das man auch nicht unendlich befehlsatzerweiterungen machen kann. Ab einen gewissen Punkt würde die Geschwindigkeit abnehmen. Also sprich wenn es zu viele befehlsatzerweiterungen sind. Habe ich mir schon gedacht das es da auch nen Haken gibt. Alles hat halt seine Vor und Nachteile. Das müssen halt alle hersteller immer abwägen. Also sind wir schon an nem Punkt angelangt wo es immer schwieriger wird. Es gibt halt nix was unendlich wachsen kann. Und dank dem was ich nun gelesen habe, weiß ich dasbefehlsatzerweiterungen keinen Transistor für sich beanspruchen. Die Transistoren sind flexibel. Je weniger befehlsatzerweiterungen das Programm verwendet, desto mehr Transistoren können dann anderweitige Aufgaben erledigen. Hat halt auch wieder seine Vor und Nachteile. Also egal wie man es halt nimmt. Grenzen wird es halt immer mal wieder geben, so ist das halt nun mal im Leben.
 
Ein CISC Prozessor hat sehr stark unterschiedliche Befehlslängen, was ein Problem für die Sprungsvorhersage wird.
Da kann ich mich Jaimewolf3060 nur anschließen:
Diese krasse Trennung existiert nicht mehr!
Eher als RISC zu anzusehende Architekturen wie ARM haben im Serversegment nie ein Bein auf den Boden bekommen. Vergiss die Idee von der Ablösung der x86 also, die wird so bald nicht stattfinden, Du kannst dir sowas ja kaufen, aber die Masse der User macht es eben nicht und wenn du denen unterstellst summ zu sein, dann bist du der Geisterfahrer der im Radio vom Geisterfahrer auf seiner Stecker hört und denkt: Einer? Hunderte!
 
Eher als RISC zu anzusehende Architekturen wie ARM haben im Serversegment nie ein Bein auf den Boden bekommen.
Bitte? Der Servermarkt war einmal fast komplett von RISC Systemen (Power, SPARC, Alpha, HP-PA, MIPS, …) dominiert, nur die Mainframes waren damals CISC. x86 (meint hier auch AMD64/Intel64) im RZ ist eine noch immer relativ neue Geschichte. Da die Bedeutung von Windows auf Server wieder deutlich geschrumpft ist, ist die Abhängig von x86 ohne Bedeutung. Ob *I*X auf x86 oder irgend einem RISC läuft macht fürs Programm faktisch keinen Unterschied. Es gab nur zwei Probleme 32Bit vs. 64Bit und die Byteorder der Plattform. Ersteres ist mittlerweile ohne Bedeutung, da ohnehin nur noch für 64Bit entwickelt wird, und LE ist zum Standard geworden, weil man nichts mehr anderes kennt und man so Probleme vermeidet. Power, ARM, MIPS, Alpha, SPARC sind ohnehin bi, RISC-V LE udn HP-PA immer BE. Das Internet ist noch immer mit Byteorder BE definiert, da sieht man daran, dass damals ganz andere Systeme als x86 dominiert haben.
 
Trotzdem liest du meine Links nicht!
RISC artig!
Und was mal war, war mal und wird nicht wieder sein.
Wären all die, die du aufgezählt hast gut gewesen wäre immer noch der Zustand gegeben.
Deine persönliche Meinung zählt „null“ das wieder „RISC“ vorherrschen wird. Der Markt spricht für sich und AMD/Intel werden scheiss dreck tun um das wieder ändern zu lassen.
Im Vergleich zu reinen RISC kannst du x86 CPU für alles einsetzen auch wenn’s nur halbe Lösung sei.....
 
@jdl, ich glaube Jaimewolf und Holt meinen eher, das x86 mittlerweile eine Art Hybrid zwischen CISC und RISC geworden ist, das Front-End bricht die CISC-Instruktionen runter auf µOps, also "quasi" RISC-Instruktionen. Bin aber auch der Meinung, das man x86 nicht als die finale Lösung von CPU-Architekturen sehen darf, ARM holt bedeutend auf, PowerPC, SPARC und MIPS sind noch längst nicht begraben und dann gibt es da noch RISC-V....
 
Der Servermarkt war einmal fast komplett von RISC Systemen
War, zu Kaisers Zeiten, aber heute ist neben IBM nur noch x86 und vor allem von Intel zu finden, egal wie sehr sich unzählige Hersteller in den letzten Jahren bemüht haben mit ARM Server CPUs daran was zu ändern, auch AMD mit den Opteron 1000.
 
Wären all die, die du aufgezählt hast gut gewesen wäre immer noch der Zustand gegeben.
Die Qualität von Produkten war meistens nicht entscheidend für ihren Markterfolg. Der einzige Grund weshalb die schlechteste CPU Plattform am Markt noch immer existiert und den Markt dominiert ist DOS bzw. Windows. Denn nur auf x86 lief das. Die Bedeutung von Windows ist akut am abnehmen. Es spielt kaum eine Rolle im Servermarkt, keine im Mobile Markt und weder im IoT noch embedded Bereich ist Windows wirklich gut aufgestellt. Der Krieg der Betriebssysteme ist entschieden und der Verlierer ist Windows. Das hängt in einer immer kleiner werden Marktnische fest, und ist auch für Microsoft nur noch ein Klotz am Bein. Ich rechne damit, dass in 5-10 Jahren Microsoft Windows zu Gunsten von Linux aufgeben wird. Aktuell portiert Microsoft immer mehr Kerntechnologien auf Linux, ist der Prozess abgeschlossen wird der Kostenfaktor Windows eliminiert.

Deine persönliche Meinung zählt „null“ das wieder „RISC“ vorherrschen wird.
Der x86-Hardwareemulator den sowohl AMD wie auch Intel um einen RISC Core gebaut haben, wird x86 das Genick brechen. Insbesondere Intel konnte mit viel Geld immer einen Strukturgrößenvorteil bei der Produktion aufrechterhalten. Wie man aktuell sieht, funktioniert das schon nicht mehr. In Zukunft werden wir das Ende der Schrumpfkur der ICs sehen. 0,354nm ist die Siliziumgitterkonstante, d.h. zwei eher drei Atomlagen braucht man für einen funktionierenden IC. D.h. bei ca. 1nm ist endgültig Schluss und die Strukturgrößen können aus physikalischen Gründen nicht weiter schrumpfen. Dann wird das Thema Effizienz des Designs sehr viel stärker zum Tragen kommen. Die reinen RISC Systeme sind im Prozessorcore deutlich schlanker und können hier auftrumpfen und weiter schneller als x86 sein.
Beitrag automatisch zusammengeführt:

@jdl, ich glaube Jaimewolf und Holt meinen eher, das x86 mittlerweile eine Art Hybrid zwischen CISC und RISC geworden ist, das Front-End bricht die CISC-Instruktionen runter auf µOps, also "quasi" RISC-Instruktionen.
Ja, das ist alles ein alter Hut, und genau das wird x86 dss Genick brechen. Die Nachteile sind einfach nicht kompensierbar. Die Adressmodi sind bei x86 sehr komplex und fordern bei der spekulativen Ausführung ihren Tribut: Spectre und Meltdown lassen grüßen.
 
Unabhängig der generellen x86 Eigenarten und Problemchen muss man allerdings schon sagen dass ein gewisser Trend hin zu x86 eingesetzt hat, Heute mehr als vor 5 oder 10 Jahren. Das liegt aber auch in keinster Weise (mehr) an Windows sondern eher an der allgemein weit verbreiteten Technik in diesen Gefilden. Microsoft war seinerzeit vielleicht mal der Trendsetter, mehr aber auch nicht... Wenn ich mich auf dem Enterprisemarkt so umsehe und das mit Technik vor 10, 15 Jahren vergleiche, dann sehe ich damals viele Speziallösungen für allen möglichen Unsinn und heute ne ganze Menge x86 im Backend mit nem Software defined Aufsatz. Die Entwickler scheuen offenbar mehrgleisigen Support, irgendwelche Switch, Router, Storage Systeme, die früher sonstwas waren von der Technik, Heute gibt's ein angepasstes Unix oder Linux, Software oben drauf und eben den Xeon auf der Platine - und wer will bekommt exakt das gleiche Look and Feel ohne Blech als vAppliance für die Cloud oder eigene Infrastruktur. Mit irgendwelchen nicht x86 Lösungen brauchts wieder den einen passenden Anbieter mit der passenden CPU, oder ner häufig lahmen Emulation. x86 überzeugt nicht von der Funktion, sondern durch die Verfügbarkeit, Kompatibilität und eben dem Resultat, dass es "überall" genutzt wird. Solange das so bleibt, sehe ich da wenig andere Ansätze - es bräuchte ner adequaten Alternative, Alternativen gibt's nur eben wie Sand am Meer. Jede für sich mit Vorzügen und eben auch Nachteilen...

Dieser Trend hilft mMn Intel hier klar, x86 massiv weiter zu verbreiten - Keine andere Architektur oder Ansatz hat das bis dato in diesem Umfang geschafft, selbst früher nicht, wo x-Hersteller ihr eigenes Süppchen kochten. Wie lange das weiter gehen wird, werden wir sehen. Intels Fertigungsprobleme da in einen Topf mit der Architektur zu kippen halte ich für unsinnig, weil die Probleme auch ohne x86 da gewesen wären - Genau so wie physische Limits. Btw. lass dich nicht vom Marketing veralbern, bis 1nm ist es noch ein extrem weiter weg, die 7nm oder 10nm bei Intel sind nur Marketing, mit realen Größen hat das nix am Hut - der 1nm Vergleich ist also gar nicht möglich.
 
Die reinen RISC Systeme sind im Prozessorcore deutlich schlanker und können hier auftrumpfen und weiter schneller als x86 sein.
Nur sehen wir genau das Gegenteil, es werden immer mehr Befehlserweiterungen geschaffen, also gerade das Gegenteil von schlank. Auch von daher halte ich alle deine Prognosen für falsch.
Beitrag automatisch zusammengeführt:

Intels Fertigungsprobleme da in einen Topf mit der Architektur zu kippen halte ich für unsinnig,
Eben, GF und TSMC hatten massive Probleme mit ihren 20nm Prozessen, GF hat seinen nie hinbekommen und den 14nm Prozess von Samsung lizenziert, aber TSMC hat dies nich aufgehalten heute bei 7nm bestens aufgestellt zu sein. Intels 7nm Prozess muss also nicht die gleichen Probleme bekommen wie die 10nm Fertigung, sondern kann durchaus im Zeitplan bleiben und ebenso die Nachfolgeprozesse. Dies hat auch alles nichts mit der x86 CPU Architektur zu tun, die noch sehr lange dominant bleiben dürfte und sich durchgesetzt hat, obwohl es damals bessere Architekturen gab, wie z.B. die Motorola 68000.

Es setzt sich eben nicht immer die technisch beste Lösung durch, wie man es auch bei Videorecordern gesehen hat, Betamax und Video 2000 waren um Längen besser als VHS, da reichte ein Kopf und das zu erreichen wofür die letzten VHS Recorder 7 Köpfe hatten und trotzdem hat sich eben VHS durchgesetzt, weil es jeder bauen durfte und es damit billig war. Die x86 Architektur dürfte auch klar davon profitiert haben, dass eben nur Intel daran gearbeitet hat, neben AMD gab es ja auch andere Lizenznehmer, auch wenn letztlich vor allem Intel und AMD (64 Bit) die Architektur weiterentwickelt haben.
 
Zuletzt bearbeitet:
Hardwareluxx setzt keine externen Werbe- und Tracking-Cookies ein. Auf unserer Webseite finden Sie nur noch Cookies nach berechtigtem Interesse (Art. 6 Abs. 1 Satz 1 lit. f DSGVO) oder eigene funktionelle Cookies. Durch die Nutzung unserer Webseite erklären Sie sich damit einverstanden, dass wir diese Cookies setzen. Mehr Informationen und Möglichkeiten zur Einstellung unserer Cookies finden Sie in unserer Datenschutzerklärung.


Zurück
Oben Unten refresh