Du verwendest einen veralteten Browser. Es ist möglich, dass diese oder andere Websites nicht korrekt angezeigt werden. Du solltest ein Upgrade durchführen oder einen alternativen Browser verwenden.
Man muss sich z.B. schonmal entscheiden, ob nun der 14nm (++) Prozess antiquiert ist (dann schmälert das im Gegenzug die Effektivität des TSMC 7nm Prozesses, weil dieser es eben trotz vermeinlicher Verkleinerung im Full Node es in keiner Weise schafft, die Konkurrenz deutlich hinter sich zu lassen), oder der Prozess von 14nm als so weit optimiert zu bezeichnen ist, dass es selbst mit einer Struktuverkleinerung schwierig wird, gegen diesen Prozess groß anzustinken.
Sehe ich nicht so. Meiner Meinung nach ist AMD in allen Belangen besser. Intel erkauft sich die immer noch gute (!) Endperformance durch mehr Stromverbrauch, heißere Komponenten und Brute-Force bei der Taktfrequenz. Technologisch gesehen sehe ich absolut überhaupt keinen Grund derzeit Intel auch nur annähernd in Betracht zu ziehen.
Aber natürlich spielt das am Ende für die meisten Nutzer keine Rolle. Da zählt halt das konkrete Anwendungsgebiet. Und da gibt es ja durchaus noch Einsatzszenarien für Intels Produktreihe. In diesen Fällen kann man ruhig zu Intel greifen, ansonsten ist man schlichtweg besser bei AMD dran.
ZeroZerp schrieb:
Die Problematik ist, dass viele denken, sie würden ihn brauchen, weil sie z.B. nicht berücksichtigen, dass
in vielen der ausgedachten Einsatzszenarien z.B. für Video- Encoding, Rendering etc. deutlich schnellere Berechnungsvarianten in Form von GPGPU- Nutzung existieren.
Da ich in dem Bereich kaum etwas mache, kann ich dazu nicht wirklich viel sagen. Meine aber gesehen zu haben, dass bspw. gerade beim Einsatz von DaVinci Resolve und/oder beim Arbeiten mit RED-Aufnahmen das Rendern über die GPU (noch) keine Option ist, oder man trotzdem eine starke Mehrkern-CPU zur Seite stellen sollte. Gerade LTT hatte dazu einige interessante Videos.
Und natürlich gibt es auch noch andere Einsatzszenarien, bei denen die hohe Mehrkernleistung der TR Plattform glänzt. Bspw. der Einsatz von Virtuellen Maschinen, Mathematische Berechnungen (Wenn das Tool nicht gerade MKL nutzt. ) etc..
Wenn sich jemand falsch beraten lässt, hat das eigentlich wenig mit der Diskussion hier zu tun. Oder auch nur allgemein mit dem Forum hier. Es ist ja vorwiegend ein Consumer-Forum. Und entweder man hört als Käufer dann auf die Empfehlung seines Fachhauses (!) oder man kennt sich selbst so gut aus, um Für und Wider abzuwägen bzw. zu wissen, welches die beste Wahl für das eigene Einsatzszenario ist. Dass eure Kunden sich da falsch beraten lassen, mag für diese traurig sein, aber dafür können wir hier doch nichts!?
Ursprung meiner Einlassung war meine Zustimmung zum Kommentar Smartins,
dass es sinnlos sei sich an technischen Rahmenbedingungen wie z.B. der Fertigungsgröße
zu orientieren, sondern dass es im Fazit wichtiger sei, was in der Praxis an Leistung am Ende herausspringt.
Dann gab es den Einwurf von Pocketderp, der direkt einen Zusammenhang zwischen der Bezeichnung eines
Fertigungsnodes und der Größe des L3 Caches herstellt.
Was schließlich in seinem Beitrag mündet, dass hohe Taktraten nicht die Zukunft, sondern es eine Größe,
die er Diffus "Skalierbarkeit" nannte ginge mit Verweis auf Big/Little Prinzip.
Daraufhin wandte ich ein, dass aber unter anderem die Taktzahl eines DER Faktoren ist, die eine Skalierbarkeit
über alle Anwendungsbereiche sicherstellen würde.
Mit Verweis/Beispielen auf das begrenzte Potenzial aller Anwendungen auf eine hohe parallelisierbarkeit.
Weiterhin wurde dann von Pocketderp der Ausdruck benutzt, dass Intel mit seiner Produktlienie nun "abgewatscht" worden wäre.
Woraufhin ich die Ebenbürtigkeit der Designs pro Kern herausgestellt habe.
Er verschiebt dann das Thema in Richtung TDP.
Ich bleibe beim Thema Bezeichnung des Fertigungsprozesses und erkläre daraufhin, dass Intel dadurch, dass sie die Miniaturisierung
noch nicht vollzogen hat dadurch aber auch das Potenzial eines zukünftigen Shrinks noch vor sich hat.
Er versucht mir daraufhin (weshalb auch immer) zu unterstellen, dass ich bei meinen Ausführungen als Hintergedanken wohl Spiele im
Hinterkopf hätte, dass TR durch den L3 Cache enorm profitieren könne und deshalb das Design noch mehr durch noch größeren L3 Cache
profitieren wird.
Ich wiederum verneine, dass ich mich auf Spiele beziehe (Erinnerung- Es geht immernoch um den ursprünglich aufgegrabenen Haufen der Skalierung),
sondern auf Anwendungen, da auch diese nur im Spezialfall massiv von großen Kernzahlen profitieren können.
Ich bringe zudem, um seine vorhergehende Argumentation zu widerlegen ein Beispiel eines vor 5 Jahren in 22nm gefertigten Chips, der pro Kern eine
höhere Menge an L3 pro Kern zu bieten hatte, als es die neuen AMD Prozessoren in einigen Bereichen jetzt tun.
Damit widerlege ich den vorher durch ihn hergestellten direkten Zusammenhang, dass derartige Cachegrößen auf der Fertigungsgröße basieren.
Zudem führe ich als Praxisbeweis auf, dass die derzeitige GPU Generation von AMD trotz fortschrittlicherer Fertigung trotzdem im Endeffekt langsamer als
das Produkt sei, welches von der Konkurrenz in einem "älteren" Prozess gefertigt wird, um zu unterstreichen, dass die nm Zahl nicht alles sei.
Ich greife daraufhin nochmals, um die Diskussion wieder an den Ursprungsgedanken heranzuführen, den Faden wieder auf und wiederhole,
dass die Bezeichnung eines Fertigungsprozesses realtiv irrelevant wären, sondern am Ende nur die Leistung zählt.
Pocketderp zieht meine Aussage in Zweifel, dass es verhältnismäßig wenige Anwendungen gibt, die einen derartigen Grad an Paralellisierung zulassen,
der eine solche CPU wie den TR von dem wir hier die ganze Zeit sprechen, überhaupt komplett auslasten könne.
Daraufhin bringt er ein Beispiel, bei dem nicht zu erkennen ist, worauf er hinaus will.
Er spricht davon, dass es eben schon erheblich sei, ob TR bei einem Video nur noch die Hälfte (von was?) bräuchte.
Zudem stellt sich heraus, dass er mein Beispiel mit den GPUs und der Unabhängigkeit derer Leistung von der Bezeichnung eines Nodes
nicht verstanden hat.
Worauf ich als Denkanstoß, um bei seinem Beispiel von Effizienz beim Rendern von Videos, die er als Beispiel brachte, zu bleiben nebenbei zu bedenken gab,
dass es für diverse Aufgabenstellungen in eingen Bereichen effizienter und schneller ist, Berechnungen über die GPU durchführen zu lassen.
Und es war hier aus dem Zusammenhang klar, dass ich nicht von Quicksync, NVENC etc. spreche...
Dann erkläre ich ihm die Hauptbereiche an Software, für die eine solche CPU wie der TR in der Praxis überhaupt zum Tragen kämen und stelle damit
den Nischennutzen im Pool der verfügbaren Anwendungen heraus. Bringe auch zeitglich noch ein Praxisbeispiel für die tatsächliche
Nachfrage, die in dieser "Liga" herrscht.
Pocketderp lässt nun den Kern der Diskussion liegen und steigt auf meinen Denkanstoß in Sachen GPGPU ein und behauptet, dass das simultane Verarbeiten
von unterschiedlichen Prozessen kein Gebiet der GPU sei.
Mit einem Vermerk, dass sich die GPU- Kerne nicht für alle Aufgabenstellungen der massiv parallelen Verarbeitung eignen.
Dann gibt es Zwischeneinwürfe von Usern, worauf ich klarstelle, dass ich solchen Prozessoren wie dem Threadripper keineswegs seine Daseinsberechtigung streitig machen will,
dass sich aber oft ausgemalt wird, wie sehr nicht die zusätzlichen Kerne eine Beschleunigung herbeiführen würden, die in vielen Anwendungsszenarien niemals stattfinden wird.
Dazu habe ich zur Veranschaulichung noch diverse Szenarien aufgezählt, in welchen unsere Kunden eben von solchen multicorezahlen wie beim neuen Threadripper profitieren, aber eben auch "hereinfallen" können.
Dann kam auch schon Dein Fragenkatalog zum Ankreuzen, wo völlig aus dem Zusammenhang und ohne Einleitung, Erklärung oder sonstigen Anhaltspunkten teils Diskussionsfremde
Themen ins Spiel gebracht werden. Also Dinge, die hier nie ein Thema waren oder genauer behandelt wurden, wurden von Dir in Einsätzern ins Forum "gekotzt".
Was ich auch sogleich bemäkelt habe. Denn was sollte man mit so einem Post schon "anfangen".
Woraufhin ich darauf hingewiesen habe, dass man sich doch bitte die Entwicklung des Threads ansehen solle, damit man wisse, wo die aufgegriffenen Themanfäden überhaupt ihren Ursprung haben.
So- Das wars auch schon. Noch Klärungsbedarf?
LG
Zero
Ergänzung ()
MaverickM schrieb:
Sehe ich nicht so. Meiner Meinung nach ist AMD in allen Belangen besser. Intel erkauft sich die immer noch gute (!) Endperformance durch mehr Stromverbrauch, heißere Komponenten und Brute-Force bei der Taktfrequenz.
Der Stromverbrauch in Relation zur Oberfläche bedingt ja heißere Komponenten. Die neuen Ryzens sind dort und gerade was die Hitze anbelangt aber auch keine Kostverächter. Der Bruteforce- Methode, was die Taktfrequenz anbelangt, bedienen sich beide Hersteller.
Technologisch gesehen sehe ich absolut überhaupt keinen Grund derzeit Intel auch nur annähernd in Betracht zu ziehen.
Es gibt im Mischbetrieb eines Standardusers auch keinen Grund, das zu tun. In die Richtung gibts aus unserem Haus auch keine Empfehlung mehr Richtung Intel (mit Ausnahmen für spezielle Anwendungsfälle).
Aber natürlich spielt das am Ende für die meisten Nutzer keine Rolle. Da zählt halt das konkrete Anwendungsgebiet. Und da gibt es ja durchaus noch Einsatzszenarien für Intels Produktreihe. In diesen Fällen kann man ruhig zu Intel greifen, ansonsten ist man schlichtweg besser bei AMD dran.
Genau so ist es. Es gibt eben den ein oder anderen Ausreißer auf der Anwendungsfront. Wenn man zu 99% mit diesem zu tun hat, ist die CPU, die diesen Fall optimal abdeckt, dafür aber anderweitig kleine Schwächen zeigt, trotzdem zu empfehlen.
Ansonsten gehe ich auch mit Dir konform. Nicht alle Anwendungen können gewinnbringend durch eine GPU beschleunigt werden und zum Teil sind für eine Schnelle GPU Berechnung je nach Anwendung auch viele CPU Kerne gefragt.
Und natürlich gibt es auch noch andere Einsatzszenarien, bei denen die hohe Mehrkernleistung der TR Plattform glänzt. Bspw. der Einsatz von Virtuellen Maschinen, Mathematische Berechnungen (Wenn das Tool nicht gerade MKL nutzt. ) etc..
Und entweder man hört als Käufer dann auf die Empfehlung seines Fachhauses (!) oder man kennt sich selbst so gut aus, um Für und Wider abzuwägen bzw. zu wissen, welches die beste Wahl für das eigene Einsatzszenario ist. Dass eure Kunden sich da falsch beraten lassen, mag für diese traurig sein, aber dafür können wir hier doch nichts!?
Wir sind leider zu oft genau dann gefragt, wenn eben aufgrund von allgemeinen Weisheiten eine Fehlanschaffung getätigt wurde (erst gestern wieder passiert).
Da hat einer seinen DATEV Terminalserver mit einer hochtaktenden 8- Kern CPU gegen ein niedrig taktendes 24- Kern Modell ersetzt, da dieses ja nun 3x schneller sein müsste....
Tja- So kann man sich irren. Viel Geld ausgegeben und nun spürbar langsamer unterwegs.
Deshalb hake ich auch hier im Forum immer ein, wenn der Kernewahn unkritisch wieder überhand nimmt und die Anzahl an Kernen an Wichtigkeit kategorisch über IPC+Takt angesiedelt wird.
Tja- So kommt das halt, wenn man in Diskussionen einsteigt, ohne sich den Verlauf des Threads zu Gemüte zu führen und den Ursprünglichen Sinn einer Einlassung zu berücksichtigen....
Wie lautet denn Deine Analyse des Informationsgehaltes und der Argumentationsführung von Piledrivers obigen Beiträgen?
Wie nett, du hast mir noch immer nicht erklärt warum du auf GPU gesprungen bist obwohl es hier um CPU's geht, auch nicht warum du Leuten vorwirfst warum sie so eine CPU kaufen obwohl du solche die Existenz solcher Prozessoren gar nicht absprechen willst? Alles was du hier bisher in diesen Thema gebracht eiert hast derart Meilenweit um ein wirkliches Argument herum wie ein besoffener um eine Atemprobe.
Wenn dein ach so heiliges 14+++++++ (Dramatisch Überspitzt und so) Verfahren noch eine Nummer wäre, so hätte Intel sicherlich nicht den 10 nm Prozess angestoßen der leider Missglückt ist, ebenso hätte man nicht einer ältere 22nm Haswell aus der Mottenkiste geholt um den Markt zu bedienen. Jetzt noch auf ein 10nm Verfahren zu setzen ist so als wenn Intel nun ein totes Pferd reiten wollen, es wäre in diesen Umstand eher angebracht direkt gleich auf 7 nm zu wechseln. Warum? Weil Know-How dazu nun mal da ist. Fertig.
Deshalb hake ich auch hier im Forum immer ein, wenn der Kernewahn unkritisch wieder überhand nimmt und die Anzahl an Kernen an Wichtigkeit kategorisch über IPC+Takt angesiedelt wird.
Ich ziehe hier mal selbst den Schuh an, weil ich selbst durchaus der Ansicht bin, dass die Kernanzahl zukünftig immer weiter an Bedeutung gewinnen wird. In erster Linie sind das - zumindest von meiner Seite aus - vor allem Überlegungen, die die nächsten Jahre betreffen. Man sieht ja selbst im Consumer-Bereich, wo die Entwicklung hingeht. Dass wir bei den Taktraten im Groben am Limit angekommen sind, ist ja hinlänglich bekannt. Bleiben also nur noch Skalierbarkeit durch mehr Kerne und Optimierungen für höhere IPC-Leistung. Meiner Meinung nach gibt es hier deutlich mehr Potential durch die steigende Parallelsierung der Aufgaben, sprich durch mehr Kerne.
Die Probleme die sich dadurch ergeben (Aufgaben sind nicht unendlich parallelisierbar), scheinen dabei letztendlich doch nicht so unlösbar, wenn man sich mal tiefer mit aktueller Software-Entwicklung befasst.
Zudem führe ich als Praxisbeweis auf, dass die derzeitige GPU Generation von AMD trotz fortschrittlicherer Fertigung trotzdem im Endeffekt langsamer als
das Produkt sei, welches von der Konkurrenz in einem "älteren" Prozess gefertigt wird, um zu unterstreichen, dass die nm Zahl nicht alles sei.
Nein- Ich stelle dar, warum ich davor warne, die Kernanzahl als Größe über alles andere zu stellen.
Ich weiss aber auch nicht, wie oft ich das noch betonen muss, dass es Dich erreicht.
Wenn dein ach so heiliges 14+++++++ (Dramatisch Überspitzt und so) Verfahren noch eine Nummer wäre, so hätte Intel sicherlich nicht den 10 nm Prozess angestoßen
Ich mache mir auch so meine Gedanken, ob es nicht besser gewesen wäre bei 10nm einfach irgendwann die Notbremse zu ziehen. Jedoch ist die Frage, ob das Firmenpolitisch und auch verpflichtungstechnisch (es gibt ja auch Verträge), als auch im Shareholderbereich nicht tatsächlich zwingend notwendig war, um sich nicht Schadensersatzforderungen, oder Klagen wegen Falschinformation ausgesetzt zu sehen.
Es muss triftige Gründe geben, dass man gerade so handelt, wie man es eben tut.
Es geht nicht darum, dass AMD mit 12 oder 16 Kernen schneller ist, als Intel mit 8Kernen, es geht darum, was Intel bei gleichen Voraussetzungen leistet.
Und mit gleichen Voraussetzungen meinst du natürlich genau genommen NUR die Kernzahl.
Preis egal, Strukturgröße egal, Leistungsaufnahme egal, Effizienz egal.
Merkst es selber oder? Ich befürchte nicht.
Und dann willst du noch zusätzlich kein Intel Fanboy sein?
Zumindest bist du ein Faktenverdreher und Faktenignorierer. Womöglich einfach gerne in einer alternativen, entgegengesetzten Realität unterwegs.
Es wäre deutlich schöner solche post hier nicht mehr zu lesen sondern wirklich mal nüchtern die Fakten zu betrachten.
Ich frage mich für welche Produkte genau Intel die 22nm auskramt.
Womöglich sind diese so belanglos, dass sich die ganze Diskussion hier mal wieder erübrigt hat.
Meiner Meinung nach gibt es hier deutlich mehr Potential durch die steigende Parallelsierung der Aufgaben, sprich durch mehr Kerne.
Die Probleme die sich dadurch ergeben (Aufgaben sind nicht unendlich parallelisierbar), scheinen dabei letztendlich doch nicht so unlösbar, wenn man sich mal tiefer mit aktueller Software-Entwicklung befasst.
Alle Programmierer, mit denen ich mich unterhalte sagen genau das Gegenteil, nämlich dass man in der Programmierung bereits weitestgehend alles in Richtung Parallelisierung treibt/getrieben hat, was nicht Niet- und Nagelfest ist, weil man eben weiss, dass man die nächste Zeit mit mehr Kernen vorlieb nehmen muss.
Sicherlich ist immer in gewisser Weise noch ein Optimierungspotenzial vorhanden, aber "große Würfe" verspricht sich mit der vorhandenen CPU Architektur/Arbeitsprinzip da keiner mehr.
Das Gebiet ist schon hinreichend ausgeforscht und viele Kluge Köpfe haben sich da schon an einigen Problemstellungen die Zähne ausgebissen.
Wie gesagt- Natürlich ist noch was machbar. Aber die Hoffnung, dass man noch große Zuwächse bei Umlagerung auf Multicore erzielen könnte, kann zumindest mein Umfeld von Leuten, die sich da auskennen, nicht teilen.
Denn eine Parallelisierung nur um des Selbstwillens zu erzwingen, nur um dann ein par % mehr rauszuquetschen, wäre sicherlich auch nicht der Königsweg.
Abwiegeln, rausreden, und vage Vermutungen, deine Reaktion ist voll davon, und dann das hier ist der sprichwörtliche Kracher. Beim verwischen deiner eigenen Aussagen bist du schon ziemlich gut aber hierfür würde ich dir jedenfalls nicht zu einer Glaskugel raten. Wie stark der Schuh im übrigen diesbezüglich brennt ist daran zu erkennen das Intel bereits schon seit 2018 Chipsätze teils wieder im 22er Verfahren produzieren lässt. Das kommt ja alles nicht so aus dem heiteren Himmel, aber he, man kann ja noch einfach weiter vermuten. Gell?
@ZeroZerp
Also jede Anwendung lässt sich nicht bis ins Detail parallelisieren.
Anwendungen, Mehrzahl, kann man parallelisieren.
Desweiteren, wenn man mal AMD wegblendet.
7700k > 8700k > 9900k und bald 10 Core.
Jeder Prozessor schlägt seinen Vorgänger und bei jedem top Intel wurde behauptet, man bräuchte doch nicht mehr threads. Wieso bringt dann Intel ein 10 Core Prozessor und ein Line Up, welches jeweils die Top CPU seit Zen Release entspricht?
i3 7700k
i5 8700k
i7 9900k
i9 10 Core
Intel selbst hat vor Jahren auf einer Veranstaltung zugegeben, dass im Bereich Parallelisieren noch viele Möglichkeiten gibt, allein was die Last Verteilung angeht.
Und die meisten Programmierer verwenden objekt orientierte Programmierung und sind vermutlich im Web Bereich, welche meist auf Server laufen, die virtuell sind und zur Stabellisierung mehrfach Instanziert sind. Kurz, vllt ist zum Bsp ein Micro Service nur ein dummes weiterreichen, wird aber vllt 1000 mal in der Sek aufgerufen und das kann man parallelisieren.
Der Konsument selbst kann sich die Frage stellen, habe ich nicht vllt mehre Programme am laufen?
Ich persönlich sehe noch großes Potential bei KI-gestützten Compilern, die Code automatisch parallelisieren. Das macht gut optimierte Anwendungen nicht unbedingt besser, kann aber bei nicht optimiertem Code greifen oder den Optimierungsaufwand reduzieren.
Ein Teil befindet sich hier auf dieser Seite worauf ich im übrigen hingewiesen habe und der andere in diesen Ding was sich Internet nennt. (Zum Bleistift: hier und hier) aber es ist ja allzu leicht und etwas einfältig den Eiertanz den man selbst vollführt den anderen vorzuwerfen.
Genau das ist ja eines der Bereiche, die ich ausgeführt und als Beispiel für ein sinnvolles Einsatzszenario genannt hatte.
Desweiteren, wenn man mal AMD wegblendet.
7700k > 8700k > 9900k und bald 10 Core.
Jeder Prozessor schlägt seinen Vorgänger und bei jedem top Intel wurde behauptet, man bräuchte doch nicht mehr threads.
Ja- Weil man wie ich auch bereits vorher ausgeführt habe auch in Standardszenarien noch einen stärkeren Impact von mehreren Kernen hat, der mit zunehmender Kernzahl abflacht.
Wieso bringt dann Intel ein 10 Core Prozessor und ein Line Up, welches jeweils die Top CPU seit Zen Release entspricht?
Weil es der Markt hergibt bzw. man sieht, dass es verlangt wird. Die Gründe warum das so ist sind aus rein wirtschaftlichen Gesichtspunkten erstmal egal.
Du musst Dir schon mal genau ansehen, was da als Optionen angezeigt wird:
-Software Occlusion Culling
-Global Illumination
-Realistic destruction
-Realistic ragdoll
-Detailed animation
-advanced particles
-Wind-/Weather Simulation
-3D Audio
-Additional rendering passes
-More Details of distant model
-Decorative content
-Ambient animation and background life
Was fällt uns auf? Fast alle der genannten Punkte sind inzwischen auf die GPU ausgelagert bzw. werden gerade ausgelagert, weil die das erheblich effektiver und schneller erledigt.
Bleibt noch:
-Wind-/Weather Simulation
-Ambient animation und background life
Das kann man in der Tat durch etliche Threads bis zum erbrechen detailiert steigern. Nur stellt sich mir auch dort relativ schnell die Frage, ob eine Background- Simulation, die dann 100x Komplexer ist, als z.B. die von Red dead redemption 2, dem tatsächlichen Spielerlebnis überhaupt entsprechend signifikant zuträglich wäre.
Der Konsument selbst kann sich die Frage stellen, habe ich nicht vllt mehre Programme am laufen?
Der Konsument muss für sich die Frage aber auch präzisieren. Wie viel davon muss zwingend parallel mit realtime- Berechnungen laufen. Du kannst auf schwachen Kisten viele Programme laufen lassen. Die kosten im Zweifel nur Speicher.
Anders sieht es aus, wenn ein Programm rechnet und man zeitgleich mit dem aktiven Datenstamm aber noch etwas anderes (z.B. in einem anderen Modul) erledigen möchte.
LG
Zero
Ergänzung ()
Piledriver schrieb:
Du ergibst dich also lieber dem Gigahertzwahn und der daraus resultierenden Abwärme/Hitze. Jetzt haben es wohl viele verstanden!
Das ist eine unzulässige Verallgemeinerung. Ich habe schon sehr genau ausgeführt, worum es mir geht.
Es geht darum, dass vordergründig IPC und Takt die Musik spielen, wie universell und Anwendungsunabhängig ein System beschleunigt wird.
An zweiter Stelle kommen Kerne, die mit zunehmender Zahl einen immer eingeschränkteren Kreis an Appliaktionen beschleunigen können.
IPC gepaart mit Takt bringt im Gegensatz zur Kernzahlerhöhung also IMMER und in jedem Szenario einen Leistungszuwachs. Ist das denn wirklich so schwer zu verstehen?
Man kann ja auch vernünftige Wege gehen und neue Technologien entwickeln, die höher Takten und weniger Abwärme-/Hitze erzeugen und dabei noch Energie sparen. Da liegt weit mehr universal nutzbares Zukunfts- Potenzial als in der Kerneschlacht: https://www.popularmechanics.com/technology/a28838017/what-are-carbon-nanotubes/
LG
Zero
Ergänzung ()
Pocketderp schrieb:
Ein Teil befindet sich hier auf dieser Seite worauf ich im übrigen hingewiesen habe und der andere in diesen Ding was sich Internet nennt.
Danach habe ich aber nicht gefragt. Spekulationen, die Du hier als Wahrheit und Fakten deklarierst, mögest Du bitte entsprechend Deines hier so selbstsicheren Auftretens dann auch bitte mit offiziellen Quellen, die diese als Fakten belegen, auch anführen.
Derzeit erreichst Du mit Deinen Links nämlich eher das Gegenteil. -> Stochern im Trüben und Vermutungen
Ich habe zudem keine Ahnung, warum Du hier permanent versuchst, das Diskussionsniveau zu senken und auf die persönliche Ebene zu gehen.
@Pocketderp
Da ich (wohl im Gegensatz zu Dir) die verlinkten Artikel vollständig gelesen habe, stellt sich die Situation folgendermaßen dar:
Schon der erste Link, denn Du lieferst hat ein Fragezeichen in der Überschrift stehen und spricht ganz offen von Gerüchten.
Der verlinkte Golem Artikel wiederum verbreitet gänzlich ohne Quelle bzw. Bestätigung die eigenen Mutmaßungen als Fakt.
Hintergrund für den Rückschritt von 14 nm auf 22 nm ist, dass Intel erst ab Ende 2019 seine 10-nm-Prozessoren, genannt Ice Lake, in Serie liefern kann. Bis dahin ist die 14-nm-Kapazität am Limit, ergo versucht sich Intel durch weitere 22-nm-Modelle etwas Luft zu verschaffen. Mit CPUs, vor allem den Xeons, macht der Hersteller viel mehr Umsatz und Gewinn als mit Chipsätzen.
Das einzige, was tatsächlich das aktuelle Thema betrifft (nicht Chipsätze auf die sich die Golem Quelle vor einem Jahr beruft) und aus gesicherter Quelle stammt ist dazu das hier (von Intel aus eine product change notification):
"Cancelling this Product Discontinuance completely per new roadmap decision and enabling the product long term once again."
Daraus leitet natürlich jede Publikation wieder für sich selbst spekulativ ab, warum das so sein könnte.
Nur einer nicht (Pocketderp), der vorgibt die Fakten bezüglich der Beweggründe genau zu kennen.
Der G3420 um den es hier geht ist so unfassbar weit davon entfernt, logisch einen Engpass in der 14nm Fertigungstechnik überbrücken zu können (wie hier spekuliert wird), dass man bezüglich dieslautender Spekulationen einfach nur den Kopf schütteln kann.
Nach dem Motto- Oh! Der 8- Kern 9900K ist nicht verfügbar- Egal! Kauf ich mir anstatt dessen einfach den G3420, den Intel aus reiner Verzweiflung augrund des Engpasses nun weiterlaufen lässt.
Echt jetzt?
Weil sie Quartal um Quartal Rekordgewinne einfahren, nehme ich an. Wie das möglich sein soll bei anhaltenden signifikanten Lieferschwierigkeiten und seit Jahren stockender Innovation, ist mir ein unerklärliches Rätsel.
Ich habe aber auch schon gegenteiliges gelesen. Es erfordert meist eben unorthodoxes Denken. Ich bin durchaus überzeugt, dass, wenn man grundlegend anders an das Problem heran geht, diese Probleme zu lösen sind. Werden sie letztendlich ja auch sein müssen, denn der Physik sind Grenzen gesetzt, und wir sind ja bereits jetzt in eine der Grenzen (Taktraten) gestoßen.
) etc..
