Wie lange können die Strukturbreiten der Prozessoren noch verkleinert werden? [Archiv]

BlacKi

2024-01-11, 00:33:56

Da wird in Zukunft auch mit laser gearbeitet werden. Oder wie habe ich mir das vorzustellen?

Interessiert mich schon Jahre, kann mir hier jemand einen kleinen Überblick über dieses spannende Feld geben, welches irgendwann an Grenzen stoßen wird. Spätestestens auf der kleinsten Ebene, dem Atom geht's eben nicht mehr kleiner.

man arbeitet glaube ich seit her mit licht. ein laser wäre zu langsam. und sichtbares licht wäre zu breit. die wellenlänge wäre zu breit, deswegen nimmt man mittlerweile sogar extrem ultraviolettes licht (EUV), das hat viel kleinere wellenlängen als normales licht.

aber selbst das würde nicht reichen für heutige prozesse. deshalb muss man die fläche verlassen und sozusagen übereinander die verbindungen legen. so kann man fläche sparen obwohl man garnicht kleiner fertigen kann.

die namen der fertigungsprozesse bilden nichtmehr die strukturbreite ab wie früher, sondern wie gut man fläche einsparen kann. man bleibt bei der namensgebung, aber die strukturbreiten bleiben recht breit, weil man garnicht kleiner kann. man ist praktisch schon am finanziell machbaren gelandet was die strukturbreite angeht. aber es stehen schon andere materialien in der warteschlange, zb. Galliumnitirit und Siliziumkarbid. die könnten silizium ablösen.

latiose88

2024-01-11, 03:15:18

also wird nur durch sehr viele Tricks die struktur indirekt verkleinert.Neue Materiealien könnten also dafür sorgen das man noch etwas kleiner machen kann,aber die Speicherzellen sind schon ein Limiterender Faktor.Nehmen sie doch 25 % der Fläche ein.So das selbst mit neueren Materialien hier eine Grenze herscht.Vielleicht geht aber auch da noch was,aber viel gewiss auch nicht.Das erklärt auch warum es bei der Größe der Festplatten nicht mehr so weiter wächst wie zu erwarten ist.Ich warte ja noch auf die 28 bzw 27 TB Festplatten aber die scheinen sich für die Consumer Menschen zu verzögern. Bei GPUS wird es ineressant wie es da so weiter geht.Gehen die GPUS ja eh schon in die Breite und der Stromverbrauch ist ja eh schon ein neuer Rekord angestiegen.Und immer noch viel Größer wird auch bei GPU auf dauer uninteressant.

Klar könnte und wird sich AMD und Nvidia sowie vielleicht auch Intel,ein paar Funktionen aus der heutigen GPUS raus werfen.Ewig geht das aber auch nicht.Und wie viel man rauswerfen und an Stromverbrauch durch das einsparen können wird,ne andere Frage.
Aber Nvidia wird da keine kosten und mühen scheuen da weiter zu entwickeln bis da nix mehr geht.

Skysnake

2024-01-11, 07:18:46

aber es stehen schon andere materialien in der warteschlange, zb. Galliumnitirit und Siliziumkarbid. die könnten silizium ablösen.

Die eignen sich aber wegen zu geringer Schaltgeschwindigkeit nur für Leistungselekteonin und nicht für Logik.

mboeller

2024-01-11, 07:21:21

eher noch das hier:
https://www.refractorymetal.org/molybdenum-disulfide-mos2-chip-revolution/

Molybdenum disulfide (MoS2) is considered the most promising alternative to silicon because of its unique monolayer atomic structure and excellent optoelectronic properties and becomes one of the ideal materials for future applications in semiconductor, transistors, chips, and other advanced science and technology fields

][immy

2024-01-11, 07:58:42

Man muss sich halt langsam mal vom verdoppeln der Transistoren (auf gleicher Fläche) verabschieden. Auch ein Grund warum AMD versucht zu stapeln. Damit ist ein Verdopplung allerdings auch nur begrenzt möglich, schon wegen der Durchkontaktierung.
Die thermischen Probleme kommen dann noch oben drauf.

ChaosTM

2024-01-11, 08:29:45

Mit den Marketingnamen nähert man sich dem Atomradius schon an. Das hat aber nicht unbedingt viel mit der Realität zu tun.

Beispiel:
Die Intel 4 HPC Zellen sind 240nm x 50nm groß. Das ist von der Fläche her so viel wie 1 Mio. Atome.

Trotzdem merkt man, dass die Entwicklung spürbar eingeschlafen ist und die Roadmap stimmen auch nicht unbedingt optimistisch wenn sieht dass ein Node Shrink (nach klassischer Definition) über 10 Jahre gestreckt wird mit 5 neuen Namen.
Und die Kosten pro Wafer steigen auch noch munter weiter.
Nach 3nm sind wir an einem Punkt wo es nur mehr Fortschritte bei der Energieeffizienz gibt aber die Kosten pro Transistor steigen was dies für viele Produkte wie GPU extrem uninteressant macht.

Der Atomradius war nur zur Verdeutlichung der allgemeinen Situation gedacht. Dass es viel, viel komplexer ist steht außer Frage und die Kosten werden bald komplett durch die Decke gehen. Das ist auch unausweichlich.
Vielleicht schaffen wir es ja irgendwann Rechner zu konstruieren, die auf Quark Ebene arbeiten können. :) (Extrem unwahrscheinlich)

Der Fortschritt wird sich im klassischen (Turing) Computing immer mehr Richtung AI unterstützter Softwareoptimierung verlagern.
Prominenteste/bekannteste Beispiele sind DLSS/FSR und Frame Generation.

Bis das alles ausgereizt ist haben Quantencomputer auch schon eine gewisse Reife erlangt und dann geht die Kurve steiler nach oben denn je.

drkohler

2024-01-11, 17:52:57

Im Physikstudium läuft das für alle Studenten auf die Frage heraus:
Löse die Schrödingergleichung für ein Elektron in einem Potentialtopf

Abgesehen von der Frage, wie man solche kleinsten Strukturen überhaupt erzeugen kann (Reflexions- statt Transmission-Belichtung weil die Maken das kürzestwellige Licht absorbieren. Extrem kurzwelliges Licht = Sauteure, grosse Maschinen), ist auch das grosse Problem, dass die Leckströme explodieren.

Bei immer geringeren Abmessungen sind wir im Bereich, wo die Quantenphysik übernimmt. Wer die obige Frage gelöst hat, weiss das Elektronen bei kleinsten Dimensionen des Potentialtopfes nicht mehr "in der Leiterbahn bleiben" sondern durch die Wände tunneln, was zu extremen Leckströmen führt (sowohl in den Leiterbahnen als auch in den Transistoren selbst). Ich schätze wir reden hier von >>100 Ampere bei extrem kleinen Strukturen mit konventionellen Technologien. Und nicht vergessen P=I^2*R).

Deshalb suchen die Halbleiterhersteller verzweifelt nach neuen Materialien mit höchsten Dieelektrizitätskonstanten. In der obigen Frage bedeutet das, die Potentialwände werden wieder "höher" und die Elektronen "bleiben lieber im Potentialtopf" und somit sinken die Leckströme drastisch und das Ganze wird wieder kühlbar.

Irgend wann werden wir wohl erste Versuche mit Nanoröhrchen und AFM-Assembly gefertigte Chips sehen. Ist aber wohl noch Zukunftsmusik und wird wohl sauteuer werden. Wer dann Grafikkarten im mittleren vierstelligen Bereich noch kaufen will, sei dahin gestellt.

Badesalz

2024-01-11, 21:12:14

latiose88

2024-01-11, 23:22:10

ja sehe ich auch so,besonders wenn man so starke CPUs hat aber die meiste Software nicht nutzen kann.Ich habe zwar noch ne Steigerung aber die ist halt wenig.Wenn man 24 Kerner anstatt 16 Kerner braucht um noch ne kleine Steigerung zu erhalten,ist es echt merkwürdig.Alles drüber aber dann aus die Maus ist.Ich bin zwar ein viel Nutzer aber das alles reicht dennoch nicht aus für noch mehr Kerne bei der CPU.
Bei der GPU wenn man nicht gerade WQHD oder 4k oder UHD Nutzt ,dann kommt man erst garnicht in diese Grenze wo Probleme hat.Aber selbst ich merke es in der untereren Riege das es so langsam Probleme gibt immer noch 75 Watt GPUS mit mehr Leistung raus zu hauen.Machen kann man da nur wenig weil die Fertigung so langsam an einen Punkt kommt wo nicht mehr so rasch voran geht.Vielleicht erwarte ich einfach zu viel,das kann sein.
Jedoch auch ich muss mich so langsam ungewöhnen.

Tobalt

2024-01-12, 04:31:43

Badesalz volle Zustimmung beim Thema Software.

Aber deinen Hype bezüglich Photonik teile ich nicht. was bringt die denn die Band-"Breite", wenn weder Sender noch Empfänger was damit anfangen können. Also Speicher und ALU. Oder gibt es auch photonische Konzepte für Computing, die deutlich mehr OPS als Silizium ALUs schaffen auf einer Fläche von ~cm²?

Badesalz

2024-01-12, 08:38:33

Aber deinen Hype bezüglich Photonik teile ich nicht. was bringt die denn die Band-"Breite", wenn weder Sender noch Empfänger was damit anfangen können. Also Speicher und ALU. Oder gibt es auch photonische Konzepte für Computing, die deutlich mehr OPS als Silizium ALUs schaffen auf einer Fläche von ~cm²?
Hmm... Den PR-Meldungen nach scheint es wirklich so zu sein, daß man sich da vorerst größtenteils auf die... ähh... Zwischenkommunikation konzentriert. Imho schätzt du das also nicht ganz richtig ein.
Die vorerst bearbeiteten wie auch noch die "rohen" Daten hin und her zu bewegen scheint vom Anfang an bis heute der klassische Flaschenhals zu sein. Sonst würde man nicht fortlaufend soviel Zauber mit z.B. L-Caches veranstalten. Oder halt mit Sachen wie NVlink usw. usw.

Und dafür Hunderte über Hunderte Millionen an Forschungskohle ausgeben. Jemand muss wohl ordentlich vorgerechnet haben wieviel von bereits vorhandener Leistung dadurch wortwörtlich auf der Strecke bleibt. Wofür es übrigens auch klare Beweise gibt die auch allgemein verständlich sind. SMT gehört dazu ;)

@latiose88
Du kannst schon mit starken CPUs die Software nutzen. Nur sie selbst nutzt die CPUs nicht aus :wink: Ein Thema was ich schon ewig anspreche. Parallelisierung von heimischen Anwendungen hat klare Grenzen. Selbst wenn sie fallweise theoretisch bisschen weiter weg sind, sind sie spätestens praktisch wesentlich enger.
Der Statusabgleich der Threads pro Rechenschritt (ergo Synchronisierung) wird irgendwann selbst rechenintensiv-relevant. Und in den Fällen wo er sich prinzipbedingt eher weniger auswirkt, hätte man es eigentlich auch GPGPU überlassen können...
Jemand muss es schreiben. Ein ausgeklügelter Managments der Thread-Ergebnisse fällt wie der Nutzcode selbst nicht vom Himmel. Ist nicht selten schwieriger zu machen als die eigentliche Aufgabe. Dafür braucht man Zeit und Fähigkeiten. Im Kleinen. Im Großen will dann jemand auch einen Batzen Geld dafür haben. Privat schätzt man aber ein, daß der Benutzer dafür nicht soviel ausgeben will, weil es ihm zu allermeist die 180€ statt 120€ nicht wert wäre, ob seine Soft an etwas 65min. oder 40min. rechnet.

IPS ist und bleibt daheim der King ;)

basix

2024-01-12, 08:49:59

Das schöne an Photonic Computing wäre, dass man in eine zusätzliche Dimension parallelisieren kann: Wellenlänge des Lichts. Wenn man das auch für die Rechenwerke realisiert (was es bereits in diversen Umsetzungen gibt), kann man "virtuell" shrinken.

Zu Software und Compilern: Ja da liegt noch sehr viel Potential brach. Die heutige HW ist extrem schnell, wird leider bei weitem nicht mit vollem Potential genutzt.
Ich hatte mal selbst Erfahrungen mit schlecht optimiertem Code gemacht. Mein eigener Code :D Ich habe einen Simulator für Algorithmenentwicklung gebaut. Das wuchs dann organisch über die Zeit und an einem gewissen Punkt dauerte das laden der Messdaten, Prozessierung, usw. etwa 10min für eine einzelne Parametrierung. Unbrauchbar für iterative Optimierungsschritte. Habe es dann umgebaut und optimiert und auf dem gleichen Rechner dauerte es am Schluss <2sec für das selbe. Ist jetzt ein Extrembeispiel aber es veranschaulicht, wie schlecht geschriebene Software sehr viel ausmachen kann.

Tobalt

2024-01-12, 09:25:49

Diese Mrd Forschungsgelder werden ja nicht nur in photonik investiert sondern in alle möglichen beyond-CMOS oder beyond-Neumann computing Proposals.

Es kann sein dass es photonisches Computing gibt, aber ich habe davon lediglich noch nichts gehört. Photonische interconnects schon. Aber der overhead von el-phot-el interconnects macht da eher für längere interfaces sinn, also sicher CPU-RAM, evtl. auch Core-to-core, mglw. sogar ALU-L3C.

Wenn die Alus und Speicher aber selbst nicht mehr Durchsatz bringen, dann wäre dies in erster Linie eine Technik zum Energiesparen Gegenüber gleichschnellen elektronischen Interconnects.

Für schnelleres Computing hingegen (mehr OPS) habe ich persönlich eher noch nichts zu Photonik gehört aber das muss ja nichts heißen. Dinge die ich aber gehört habe:

- superconducting interconnects (hohe clocks, geringe Leckströme, aber halt Kühlung nötig)
- analoge Einheiten oder vorher multilevel logic. Insbesondere als dedizierte lowprec Einheiten für AI. Deutlich dichter und energieärmer als CMOS. Eher maue Kompatibilität mit CMOS. Braucht auch angepasste Algos also auch Entwicklung für software und compiler nötig.
- probabilistic computing. Hier werden vereinfacht gesagt sehr viele Rechnungen zeitgleich auf der selben einheit ausgeführt und das ergebnis ist eine gewichtung. Ähnlich wie QC. Anwendbar für spezielle Probleme, wie Krypto oder AI. Gute Kompatibilität mit CMOS aber auch andere Algos + Software logischerweise.

Letzlich kommt man hier immer wieder auf den Punkt SOFTWARE zurück. Wenn wir den Determinismus ein kleines Stück weit aufgeben zumindest für bestimmte Probleme können wir "OPS" und Energieeffizienz massiv steigern. Hardwareumsetzungen dafür sind denkbar und möglich. Aber vorher muss dafür eine Akzeptanz in der Software geschaffen werden.

basix

2024-01-12, 09:40:55

Das mit dem Aufgeben von Determinismus machen wir mit DNN ja genau.

Edit:
Zu Photonic Computing gibt es bspw. Lightmatter https://lightmatter.co/products/envise/
https://techcrunch.com/2021/05/06/lightmatters-photonic-ai-ambitions-light-up-an-80m-b-round/

Die haben erst Ende letztes Jahr in einer Finanzierungsrunde 1.2b$ eingenommen und ihre Miterbeiterzahl hat sich seit Mai anscheinend auf 150 Leute verdoppelt.
Sie haben zwei Chips und einen eigenen Software Stack (primär für ML/AI).

Badesalz

2024-01-12, 10:07:20

Es kann sein dass es photonisches Computing gibt, aber ich habe davon lediglich noch nichts gehört. Photonische interconnects schon. Aber der overhead von el-phot-el interconnects macht da eher für längere interfaces sinn, also sicher CPU-RAM, evtl. auch Core-to-core, mglw. sogar ALU-L3C.Korrekt.

Wenn die Alus und Speicher aber selbst nicht mehr Durchsatz bringen, dann wäre dies in erster Linie eine Technik zum Energiesparen Gegenüber gleichschnellen elektronischen Interconnects.Den sich ergebenden Watbenefit kannst du dann samt und dank paar neuer Stoffverbindung wieder ordentlich in den Takt stecken :wink:

Für schnelleres Computing hingegen (mehr OPS) habe ich persönlich eher noch nichts zu Photonik gehört Wenn man sich auf die ALUs selbst nicht so versteift wird das in Summe schon ordentlich zum schnelleren "Computng" beitragen. Nochmals mehr als die PCIe SSD.

Ich sehe ehrlich gesagt einen HeimEpyc :wink: in realen ~1,6nm mit photonischen Interconnects bis zum Hauptspeicher, mit gleicher Threadanzahl zigfach schneller als Genoa, bei immernoch um die 110W unter Last. Und im Idle bei aktuellen Notebook x86.
Da will mir doch keine erzählen, wir werden bald an mangelnder Leistungssteigerung verhungern :|

Denkt einfach an die Fernseher. Erstmal hat man sich ewig mit PAL in 4:3 - daheim auch lange in S/W - gequält, dann ging es aufwärts bis Loewe/Hitachi und nun sind wir bei 4k OLED mit Pana/Sony DSPs.
Es dauert nur noch 2 Generationen von OLED mit Meta-Tech und auch da ist der Drops schlicht gelutscht.
Danach geht es nur noch persönlich darum, ob nicht 55" schon reichen oder es bis 75" gehen soll. Ggf. möchte man das in OLED-T haben (durchsichtig, wenn aus) und ab da ist die Story beendet.
(und auch hier sind Forenblasen aus möchtegern Nerds wirtschaftlich komplett vernachlässigbar)

Durch das bis jetzt fortlaufende Rennen nach bedarfsgerecht Optimalem, scheinen manche verängstigt darüber zu sein, daß manches schon zu ihren Lebzeiten sein optimal-nötiges Entwicklungszustand erreicht :|

Ich bin vor paar Jahren auf Michelin PilotSport 4 umgestiegen, begeistert, und es kam mir nicht in den Sinn zu nörgeln oder mich zu sorgen, weil es gegenüber dem Vorgänger nicht 40% mehr Grip bei 20% weniger Spritverbrauch liefert.

Könnte es sein, daß was IT angeht viele Foristen völlig Überwöhnt sind? :tongue:

Tobalt

2024-01-12, 10:26:15

Die Website von lightmatter ist leider unbenutzbar langsam :ulol: Nicht angemessen für ein unicorn.

Ich hatte eher wenig Berührungspunkte mit photonischem Computing. Ich weiß man kann mit gewissen waveguides da gates bauen. Aber die Dichte ist halt unterirdisch. Muss mir mal ansehen wenn deren Seite wieder läuft.

In meinem "Dunstkreis" gab es eher Konzepte auf Dünnschichtbasis.. In-memory-computing, hardware-zellen für multi-input-multi-output computing. Also eher konzepte, die sich stark vom boolschen Neumann Prinzip abgrenzen (aber kein QC)

latiose88

2024-01-12, 10:27:59

@Badesalz
Ja habe ich schon gemerkt.Wärend ein 16 Kerner mit SMT bei rund 90 % Auslastung ist,also auch keine 100%.Sind es beim 24 Kerner laut info von wen der das für mich getestet hatte nur bei 60 % Auslastung.Ohne SMT wäre es also beim 24 Kerner gewiss auch richtung 90 %.
Damit hast du recht,selbst ich der dies unter den Idealsten Bedingung schafft es nicht die CPU ganz auszulasten.
Und ich schreibe von Videoumwandlung.Selbst mit GPU scheine ich auf Grenzen gestoßen zu haben.Habe alles mögliche ausprobiert.Ich stoße wohl gegen ne Wand oder ne unsichtbare Schranke wenn man es so sieht.Wenn also selbst ne GPU es nicht mehr vermark zu beschleunigen,dann schafft das ne CPU auch bald nicht mehr.Man kann halt eben keine Wunder erwarten.Aber was sicher ist,das irgendwann mal es auch bei CPU so schnell sein wird wie bei der GPU,genau da mag ich ja auch hin kommen.
Das Problem ist das die Quelldateien also Videos unterschiedlich schnell ist.Bei H264 spielt die größe der Aufnahme eine Rolle und kann man da was beeinflussen oder ist genau das der Faktor wo dann limitert?
Ich selbst habe gemerkt das das VIdeoumwandeln CPU Takt gerne mag.So ist bei wem wo ich habe testen lassen sogar ein 14900k schneller als ein 13900k obwohl nur die E Kerne nen höheren CPU Takt haben obwohl die P Kerne vom Takt her gesenkt worden sind.Beim Stromverbrauch ist auch massiv gesenkt worden.Von 350 watt auf 315 Watt. Intel ist auf den richtigen Weg,aber noch immer sehr Strom durschtig.

Also kann am Ende ne größere Aufnahme niemals so schnell wie ein Video das kleiner ist sein,weil das einfach Technsich nicht möglich ist gleich schnell umzuwandeln?
Und stoßen wir nun an eine Taktgrenze oder ist mit guter Optimierung über 6 GHZ Allcore möglich und es ist noch Kühlbar oder braucht es dafür andere Materialien?

Und was heiß Überwöhnt auf gut Deutsch?

Zossel

2024-01-12, 10:37:00

latiose88

2024-01-12, 10:39:41

ja wird nur aufwendiger je mehr Programme ich gleichzeitig offen habe.Habe das auch mal versucht,aber da limitere ich dann.AB einen gewissen Punkt limitert dann nicht die Software sondern der Mensch selbst.Ab 4 Programmen gleichzeitig überstieg es mich bei weiten.Zudem muss man ja jedes Programm mit Videos füttern und so schnell geht das auch nicht von statten.Habe daher mich nur für 2 gleichzeitig Entschieden.Solche Faktoren wie ich sie nannte kann man also nicht so einfach aushebeln ,also beschleunigen?

Zossel

2024-01-12, 10:54:36

Badesalz

2024-01-12, 11:01:07

In meinem "Dunstkreis" gab es eher Konzepte auf Dünnschichtbasis.. In-memory-computing, hardware-zellen für multi-input-multi-output computing. Also eher konzepte, die sich stark vom boolschen Neumann Prinzip abgrenzen (aber kein QC)Da ist ebenfalls noch nichts davon endgültig begraben ;)

Lass einfach mehrere Jobs gleichzeitig laufen, wie ich dir bereits schon mal geraten habe.Das ist dann ein trade-off den man sich anschauen sollte, weil die behindern sich ja auch gegenseitig. Und das ist auch nur der Spezialfall einer Massenabarbeitung.
Das Gefühl was in den entsprechenden Unterforen oder den Benches der PR-Journalie vermittelt wird, daß mind. die Hälfte der Komputernutzer entweder Videos umwandelt/schneidet oder 3D-Modelle erstellt, ist natürlich völliger Schwachsinn.
Die PR-Journalie weiß nur nicht was sie sonst machen soll um die gelegentlichen paar Prozent Leistungsunterschied auszuarbeiten, um am Ende eine nutzlose Krone zu vergeben. Ich bin davon schon länger abgegangen mich dagegen zu wehren, das als absolut kindisch zu bezeichnen.

Wenn ähnliche Journalie Autos testet, und deren Bremsleistung, dann geben sie den Bremsweg wenigstens noch und nur in xx,x Meter an. Würden sie das wie die PR-Journalie der IT machen, müssten sie es exakt in cm angeben. Wenn nicht sogar in mm...

Man sollte langsam anfangen all den Mumpitz einfach nur realistisch zu sehen. Und belächeln. Dafür dürften die meisten auf 3DC sogar auch endlich ausreichend weit gealtert zu sein :tongue:

latiose88

2024-01-12, 12:50:23

Ja das kann ich nur bestätigen.Die meiste Zeit wandle ich nicht Videos um,auch wenn ich es sollte.Aber um das anzustoßen ist ne kleine Vorbereitung notwenig.Und da ich das direkt von und zum Netztlaufwerk umwandle kann ich nicht einfach so machen.Weil wenn ich das mache,dann kann ich alles andere nicht mehr machen also Vergessen.Ich schneide auch noch von und zum Netzlaufwerk.Ich mache das um die teilweise defekte SSD zu Entlassen.Es klappt mehr oder weniger schon ganz gut,aber optimal ist das nicht,ist nur ne Notlösung,keine Dauerlösung.

Und ja klar behindern die sich ein wenig.Beim 8 kerner verdoppelt sich dann die Zeit,bei mir ist es nur zu 25 % langsamer als Einzeln.Aber dafür schaffe ich die doppelte Zeit.
Mein 5950x ist halt langsamer als die neuen 16 kerner.Bei mir war das noch so gewesen das ein Video 1:20 Minuten einzeln braucht.Wenn ich 2 paralell Umwandle dann brauche ich so 1:38 Minuten.Dafür habe ich zwei umgewandelt.
Würde ich die hinter einnander Umwandeln wäre ich in 2:40 Minuten fertig.Ergo bin ich mit 2 Paralell noch schneller unterwegs.
Bei einem 8 Kerner sieht die sache schon anderst aus.Da merkt man es deutlich.Von 2 Minuten EInzeln auf fast 4 Minuten.Da bremsen die sich wirklich vollkommen aus.
Bei noch mehr Kerner war das Ergebnis ob einzeln oder zu zweit gleichzeitig auch sehr wenig Unterschied.
2 Paralellel scheinen also ab 16 Kernen kaum eine Rolle zu spielen.
Wobei man es auch bei den neuen CPUS auch etwas merkt.Scheinbar bringt in der hinsicht eine Optimierung der CPU leider nix.Ich hatte gehofft neue Archtektur könnte das Problem abfangen aber das scheint wohl nicht der fall zu sein.
Wobei die aktuellen CPUS hier bei 50 Sekunden bei einem Video sind und 1:10 bei zwei gleichzeitig.Ist also die Differenz beim aktuellen 16 Kerner von AMD sogar größer geworden.Statt kleiner also schlechter.Vielleicht können ja neuere CPUS das Problem lösen,wer weis.
Ich selbst besitze keinen Zen 4,aber wer getestet hat es schon.Vielleicht können Zen 5 und neuer an der Sache was machen.Das da noch was geht,sieht man ja das die GPU mit 2x H264 bei 43 Sekunden bei zwei Videos kann man so sagen gelandet ist.Selbst bei ner GPU kostet ein zweites Video gleichzeitig Zeit.Das problem haben also nicht nur CPUS.
Wenn ich alle settings auf so low wie möglich gestellt hatte,verlor die GPU auch keine Leistung mehr.
Ich könnte es ja mal auf die teureste GPU auch mal ausprobieren.Erwarte jedoch zwischen gtx 1650 zu rtx 3050 zu rtx 4090 allerdings keine Steigerung.
Mein bester Kumpel hat ebenso einen 16 Kerner allerdings nur einen Ryzen 9 3950x mit ner rtx 3050.Und ich habe einen Ryzen 9 5950x mit gtx 1650.Meine Erwartung war das die rtx 3050 doch schneller sei beim Videoumwandeln.

Habe nur gleichzeitig vergessen gehabt das die GPU von der CPU doch Abhängig ist.
Mein 5950x habe ich auf 3,8 ghz stehen,den 3950x ist auf 3,5 ghz.Damit ich die selbe Leistung habe,müsste ich den 3950x also auf 4,3 ghz stellen.Dann habe ich aber nur gleiche Leistung auch bei der GPU.

Ich dachte die Wand wäre noch nicht ereicht aber die Schranke ist schon viel früher da.
Ich hoffe also das die neue Technik hier mir weiter helfen kann.Damit die CPU noch mehr Leistung hat.Das die CPU so schnell wie die GPU sein wird,das wird noch dauern.
Vielleicht gibt es ja mal irgendwann nen Material das hier 16 x 7 ghz möglich ist.Dann steigt die Leistung wieder und dann können 24 Kerner einpacken.Wobei gewiss ein 8 Kerner mit 8 ghz gewiss hier auch noch mal was raushauen könnte.Einfach halt den Takt nach oben Pushen.
Das gleicht zumindest etwas bei mir die Kerne aus.
Das ich beim Takt ne gute Steigerung hat,zeigt nur das Kerne nicht immer die Wunderwaffe ist für mehr Leistung.Ich schaue das ich nach möglichkeiten hier mehr Takt bekomme,bei gleichen Stromverbrauch.
Intel ist zwar Takt gut,aber die Leistung ist nicht mehr so viel mehr.Mag ja geil sein 5,7 ghz Allcore zu haben,aber wenn dann der Stromverbrauch sich fast Verdoppelt,ist das nicht mehr so Lustig.

Die Ausbeute ist nicht sehr gut.Man merkt die Ausbeute bei AMD von 4,8 auf 5,1 ghz ist noch das höchste gewesen.Der Kippt Punkt ist also ab da dann schon erreicht.600 mhz für rund 9 % mehrleistung ist halt nicht mehr viel.
Ich denke mal wenn man den 13900k oder 14900k auf 5,1 ghz herunter drosselt,käme dann ein ähnlicher Stromverbrauch heraus und die Leistung sinkt dann auf das Level von AMD dann.
Aber eines ist klar,obwohl es nur E Kerne sind half auch da der Allcore Takt weiter.

Das nennt sich dann die Takt Keule.Wenn man mit Kernen nix mehr machen kann,muss halt der CPU Takt es richten.Das hilft halt den meisten Anwendung immer.

Nur die anderen Probleme,hoffe ich doch das neue Materialien hier abhilfe schaffen können.
Denn Leistung haben ist wunderbar,nur eben nicht auf kosten des Stromverbrauchs und der Temperartur.

In dieser hinsicht mag ein Threadripper und größere CPUS keine Probleme haben,allerdings sind diese halt um einiges Teuer.Alles hat halt so seine vor und Nachteile.

Badesalz

2024-01-12, 13:28:53

Und ja klar behindern die sich ein wenig.Beim 8 kerner verdoppelt sich dann die Zeit,bei mir ist es nur zu 25 % langsamer als Einzeln.Aber dafür schaffe ich die doppelte Zeit.Du meinst doppelte Arbeit :wink:
Ist auch ok und auch sinnvoll. Das sind aber pure Rechenjobs. Du arbeitest in dem Moment bzw. Fall wie ein Rechenzentrum. Würdest du so auch schneiden, würde das entweder garnicht funktionieren oder dich bekloppt machen.
Der Schuh drückt meist bei den Aufgaben die zum Weggehen zu kurz und zum Dabeisitzen zu lang sind :tongue:

Wobei die aktuellen CPUS hier bei 50 Sekunden bei einem Video sind und 1:10 bei zwei gleichzeitig.Ist also die Differenz beim aktuellen 16 Kerner von AMD sogar größer geworden.Statt kleiner also schlechter.Interessant. Heißt - wenn das PS selbst nicht unterschiedlich mit reinspuckt - nutzen sie die Resourcen effizienter. Ein Job wird pro Takt wesentlich schneller, dafür der zweite nicht mehr soviel schneller als davor.

Ich schätze, daß spätestens mit Photonik auch SMT endgültig aussterben wird. Es wird keine Leerläufe mehr geben um da dazwischen noch was zu machen :up: (bis auf IBM Mainframes vielleicht)

Mickeysoft z.B. nimmt für Azure HX, Epycs mit 3D-Cache, aber SMT machen sie aus. Macht sie in allen Fällen langsamer. Auch etwas was außer einer effizienten Programmierung Durchsatz bzw. random access als Flaschenhals aufzeigt -> Photonik-Kommunikation lockert das erheblich:wink:

latiose88

2024-01-12, 13:38:01

Ah ok was ist denn diese Photonik und das scheint wohl besser zu sein als SMT oder HT?

Der 24 Kerner ist auch nur schneller weil er ohne SMT oder HT 24 Threads hat.Diese sind auch schneller als 32 Threads vom 16 Kerner.Wenn nun aber es nur noch schnelle Threads gibt,dann sieht die Sache anderst aus.Dann wären alle die noch mehr Kerne haben nichts mehr.
Ich lasse mich da einfach überraschen.Ich finde es schade das ab einer gewissen Anzahl SMT /HT der Gewinn verpufft.Denn so kann man ja ne CPU nie ganz voll Auslasten.Dabei wollte ich eigentlich alles aus der CPU an Leistung herausholen.Dies scheint nicht möglich zu sein.Würde ich also die letzen 10 % auch noch von der CPU nutzen können wenn ich sonst nicht mehr davo,wäre das Videoumwandeln um einiges schneller. Vielleicht ändert sich mit der Technik dann auch die Archetekur,damit ich hier auch wirklich alles ausschöpfen kann.

Und das mit PS,meinst du damit die CPU damit? Und echt wie ein Rechenzentrum,wusste ich nicht,naja das scheint wohl bei mir andest zu sein als bei den meisten.

Und bei GPU das geheimnis das es so schnell ist,ist der das aus einer 650 mb Video dann eine 600 MB Video wird.Das heißt die Packdichte ist um einiges weniger.Also nix mit Magie sondern sehr schlechte Kompression.Nur damit ich da die selbe Qulität wie bei CPU habe.Ein Video von einer CPU ergibt so 300-350 MB also fast ne halbierung die größe.
Bei GPU würde man also um einiges an Bildquliät verlieren.Um diese auch bei CPU zu erreichen,einfach niedrige Settings EInstellen und fertig ist das selbe Level.Die CPU ist dann mindestens genauso schnell wie bei der GPU.
Ich war da echt entäuscht gewesen als ich diese Erkenntnisse am Ende raus bekommen hatte.Um also auch bei CPU schneller umzuwandeln also auf GPU level gibt es zwei Optionen.
Entweder 300 MB Aufnahmen an Serie verwenden oder die schlechte Bildqulität in Kauf nehmen.
Bin gespannt ob man das auch mit größeren Videos auch so noch hin bekommt,oder ob die Steigerung nur schleppend weiter gehen wird.

Tobalt

2024-01-12, 13:40:44

Rabiata

2024-01-12, 14:09:08

Ich schneide auch noch von und zum Netzlaufwerk.Ich mache das um die teilweise defekte SSD zu Entlassen.Es klappt mehr oder weniger schon ganz gut,aber optimal ist das nicht,ist nur ne Notlösung,keine Dauerlösung.

Das klingt als ob die Not groß ist (Risiko von Datenverlust). Ich denke eine frische SSD ist da wichtiger als jedes andere Upgrade :freak:

latiose88

2024-01-12, 14:25:29

SMT hat doch nichts damit zu tun, wie schnell du Data und Instr rankarren kannst.. Es hat was damit zu tun, dass ein Stream an rangekarrten Data und Instr die vorhandenen ALUs logisch nicht belegen kann.

Wenn du jetzt noch mehr Data und Instr rankarren kannst (Photonik), und dann noch breitere ALUs baust, dann steigt eher auch der mögliche Sinn von SMT4 usw.

Klar ist auch: wenn du eng umrissene Aufgaben hast, die perfekt zur Arch passen dann brauchst du kein SMT. Z.B. GPUs

Ja super wenn die GPU das nicht optimal macht so wie ich mir das vorstelle.Nur geringe einsparung beim Umwandeln.Da kann ich es auch gleich so lassen bevor ich es mit der GPU mache.Die scheint probleme mit so kleinen Videos zu haben.Wenn Nvidia das nicht kann,können es AMD und Intel erst recht nicht.
Das ist einfach für mich der falsche Einsatz Zweck.Ich weis das welche davon Profitieren,aber wenn man so wenig SPeicher nur einsparrt,beweist es GPU ist überfordert damit.
Dann hoffe ich mit breitere ALUS und so das die Zeit zum Umwandeln bei zwei gleichzeitig Optimiert ist.Mir würde es also schon helfen,das zwei Parallel so schnell sind wie einer alleine.Dann wäre das ein riesen Sprung. Damit würde ich also mit sicherheit mich zu einer neuen Plattform gewinnen.Es werden auch bei Zen 5 neue Berchnungs Einheiten die ja auch das Videoumwandeln ebenso super nutzt erweitert.Das sollte das Problem lösen.Bin einfach gespannt wie es weiter geht.Dafür ist also noch kein neues Material fällig,das kommt erst noch.

Und dann wird es sehr interessant.Wenn mit der Methode SMT 4 dann kommt,dann sind aus 8 Kernen nicht 16 Threads sondern 32 Threads und aus 16 Kernen mit 32 Threads dann 64 Threads. In dem Sinne bringt mir 64 Threads dann nix mehr.Bin ich doch zwischen 24 und 32 Threads am besten gefahren.

Allerdings so wie ich das festgestellt hatte ist ein Thread nicht gleich ein Thread.Wenn diese durch SMT oder HT erreicht worden sind ,schlechter als Threads ohne SMT oder HT.Das ist die erkenntnis von mir.
Scheinbar bringt es ab einer gewissen Punkt für mich kein gewinn mehr.Ich weis noch als die 24 und 32 Threadripper SMT abgeschaltet hatte,wo beide an Boost bekommen.Als dann fest jeder Software also bei 2 gleichen Anwendung wo je jeder als Thread im Taskmanger 12 Kernen fest zu geordnet hatte,Stieg die Leistung des 24 Kerner ohne SMT auf level vom 32 Kerner an (ohne SMT).
Mal sehen ob mir das breiter machen einen Vorteil dann bringt.

latiose88

2024-01-12, 14:32:24

Das klingt als ob die Not groß ist (Risiko von Datenverlust). Ich denke eine frische SSD ist da wichtiger als jedes andere Upgrade :freak:
Jap ist es.Ich plane ja eh im Juli einen neuen PC.Zum reinen Zocken tut es die SSD aber noch.Mir egal ob Spiele Dateien flöten gehen,kann man ja wieder nach Installieren.Anonsten traue ich der nix.War halt eine Oem SSD gewesen.Den Fehler mache ich nicht mehr.War wohl zu billig für eine NVME SSD gewesen.Dachte damals ich mache damit einen guten kauf,war auch günstiger als die meisten anderen NVME SSD gewesen.Die erkenntnis kam halt reichlich spät.Mitte letztes jahres ging es so richtig abwärts.DIe Anzeichen eines Defekts waren schon Anfang letztes Jahres gewesen.Und zwar als es dann 0 kb dateien immer wieder auf der Platte drauf waren.Als ich diese löschen wollte,stürzte der Explorer ab und schloss alle Fenster Automatisch.

Nun weis ich warum das es getan hatte,es ist nicht die schuld von Windows sondern von der SSD.
Zen 5 wird denke ich mal im Juli kommen.ALso noch rund 6 Monate durchalten.Die SSD bleibt dann drinnen und Pc wird dann nur noch zum zocken verwendet.Bis dann der Pc auseinander fällt.SOllte bis dahin mal die SSD ganz hin sein,wird sie mal ersetzt.SSD scheint schon kleiner geworden zu sein.Naja bis Juli wird die Platte schon noch durchhalten.Habe ja Geld bezahlt.Will kein Geld weg werfen.Klar könnte es sich wer anschauen,aber da es seid Anfang an keine Firmware gab,denke ich mal war es das.

Badesalz

2024-01-12, 17:29:20

@Tobalt
Du karrst die Sachen nicht nur an, sondern auch weg. Dann mit 120kmh statt 30kmh. Momentan kostet SMT auf x86 an Logik, nen Furz. Der Sinn dahinter bei zu der Zeit billigen echten 16 Threads diese Logik auszubauen könnte ggf. fraglich erscheinen. Jedenfalls für alles was nicht in einen Rack soll.

Es ist ja auch schon die Frage, ob man die ALUs auch gleich "breiter" machen wollen wird. Momentan ist alles um die ALUs rum der Flaschenhals. Ich komm leider nur nicht an die Untersuchungen ran im welchem Verhältnis das zueinander steht.

Man sieht aber (wie bei latiose), daß je besser die Einheiten ausgelastet sind, desto weniger der Benefit von SMT. Das ist schon ziemliches Zeichen, daß dies mit der bisherigen SMT-Logik immer enger wird. Und die Fahren da in solchen Fällen alle auch nur mit 50 rum ;)
Wenn sie mit 180 unterwegs sind, dann ist SMT bei gleichbleibenden Aufwand an der dafür nötigen Logik, imho tot. Das macht in jedem Szenario langsamer. Quasi wie jetzt bei Azure HX jetzt schon, erstmal.

Zu der Zeit sind 16 Threads aber normal. Ob sich da für Server noch ein Bedarf an SMT ergibt, wird man mal sehen. Daheim wahrscheinlich kaum. Das Zeug wird zig mal über dem heutigen liegen. Was will man denn damit alles machen?

Filme umwandeln? :usweet:

edit: @all
Bisschen PR, aber halt Photonik-bezogen
https://gf.com/de/blog/making-electronics-photonics-integration-a-reality/

vinacis_vivids

2024-01-12, 17:44:54

Alte Filme von Kassette, DVD oder 1080p auf 4K umzuwandeln braucht extrem viel CPU-GPU-Leistung bei hoher Präzision bzw. Bildqualität.
Oder irgendwelche Animes von 720p auf 4K. Von 8K brauchen wir erst gar nicht sprechen. Da gibs fast keine Filme bzw. Content.

latiose88

2024-01-12, 17:45:44

naja was noch geht,aber ebenso sinnlos sein wird:
Prime anschmeisen mit Benchmark,3d Mark,Cinebench rauf und runter oder auch Rendern also für die wo selbst FIlme machen.Ich sehe da auch sonst nix was noch mehr brauchen könnte außer WIssenschaftliche Sachen.ABer das macht eben kein Privater User.
Dann wird es aber schon eng mit breiter und so alles.Es sei denn es gibt noch was ,was auch so dermaßen viel CPU Leistung braucht das damit Profitiert.
Die Server brauchen meist nicht so viel CPU Leistung,sondern eher mehr Kerne.Davon haben wir aber echt schon genug davon.Oder Workstation wo mehrere Nutzer gleichzeitig den selben Pc verwenden können.Haben aber meist nur Firmen und nicht privat User.
Wenn dann wird das vielleicht ein eigenständige Firma dann.
Standard ist das aber nicht.Wenn man nur auf das Private Umfeld ohne Firma sondern nur für eine Person,dann ist das Anwendungs Profil sehr eng.
Ich sehe da jedenfalls nicht viele Anwendungs Optionen.Games als solche Anzuführen ist eine sehr schlechtes Argument.Denn an Games wird sich nicht so viel tuen.Und ich glaube auch nicht mal selbst dran das es da eine Kern Explosion geben wird.So wie die Entwickler Programieren,sofern sie das denn überhaupt selbst noch machen.Da sehe ich in naher Zukunft nichts in dieser Richtung.

Vielleicht ändert sich das ja im Jahre 2028,aber jetzt noch nicht.

Aber das mit dem SMT bzw HT da müsste es dann schon sehr harte Arbeiten sein wie Wetter berechnen,Filme Macher wie die wo ins Kino gehen.Aber ist die Frage ob es da noch eine Boost Explosion gibt wenn man da dann 16 kerne und 48 Threads draus macht.

Skysnake

2024-01-12, 17:48:57

Bis 1nm werden wir uns noch irgendwie durchschleppen. Dann stehen noch paar neue Materialien an und dann halt Photonik-ICs.

Das Packaging für Stappeln und Photonik sind die eigentlichen Herausforderungen. Nicht mehr die Miniaturisierung.

Und das ganze entstand und entsteht durch den Bedarf. Der muss nicht mehr durch noch und nöcher Miniaturisierung befriedigt werden. Die Gamer schieben das nicht mehr nenneswert an. 4k Monitor und VR wird wohl bei 5k enden. Das wars schon. Eine ewig lange Reise seit Tennis for Two, die sich langsam ihrem Ende nähert. (nein, paar Zockernerds bestimmen überhaupt nichts)

Noch 2 Gens an GPUs und CPUs dann ist der Drops langsam ausgelutscht. Danach wird erstmal ne Weile nur der Verbrauch fürs Gleiche - mit kleinen Verbesserungen ala must-have-features ;) - reduziert. Sonst wie oben.

Mit Photonik kann man halt schonmal die Zugriffe auf die z.B. L3-Caches oder den Hauptspeicher oder "interne" Schnittstellen ala PCIe 9.0 :wink: auf mehrer TB/s zu steigern. Das wird alles noch ORDENTLICH SCHUB bringen.

Das Geheule wegen dem Ende der Welt weil wir mit den Nanometern nicht mehr weiter runtergehen können sollte aber langsam auch aufhören. Irgendwann hörte man ja auch zu fragen welche Diesel noch ohne Turbolader kommen.

Die... Rechenindustrie dagegen juckt das nicht ganz so stark. Damit was sie machen können sie meist ohne Verrenkungen schlicht in die Breite gehen. Sie stellen zur Not halt zwei Racks noch dazu, wenn sie mehr Bedarf haben.
Multisockel und SLI daheim ergaben dagegen schnell wenig Sinn.

Im Gründe sind die meisten aus der Bevölkerung und außerhalb der Forenblasen jetzt schon satt.

PS:
Das eigentliche Problem ist eigentlich eh das was für einen Shice die Leute programmieren und was für einen Shice die Compiler draus machen.
Das wird sich ggf. schon mit generischen KI-Ansätzen ändern, bei der Assemblierung .

Ist nicht gleich ganz so einfach zu verklickern, aber wer mal Routinen neben dem Quellcode auch vom fertig gebackenen Code zur ersten Analyse und Optimierung in die Hände bekam - und sie erstmal wieder einmal über dem Kopf schlug - der weiß direkt was gemeint ist :ubash3:

Nur macht selbst das die Softwareindustrie schon sehr selten :wink: Ich hoffe da sehr auf den KI-Ansatz bei Compilern. Allgemein, hat die Codequali in den letzten zig Jahren echt übelst abgenommen. Hier liegt echt weit mehr brach als man mit einem shrink-step erreichen kann :frown:
Der Rand auf Compiler ist in meinen Augen unbegründet. Compiler müssen sich halt an die Semantik der Sprache halten und die Sprachen haben einfach oft ne schwache Semantik bzw die Entwickler drücken sich einfach schlecht aus und machen es damit dem Compiler scher. Zumal der ja in endlicher Zeit fertig werden soll....

C/C++ als auch Fortran haben in der Semantik leider Schwächen. Es wäre sehr gut über Pragmas mehr Infos an den Compiler zu geben, aber das könnten viele Entwickler da nicht nutzen weil sie es nicht wissen..

Und btw gerade OOP bricht leicht jedem Compiler das Genick, weil man Probleme aus seinem Scope entfernt und er sich eben an die Semantik der Sprache halten muss und nicht raten darf was gemeint sein könnte...

Daher funktionieren leichte Beispiele ja auch in der Regel gut bei der Optimierung und bei den Millionen Zeilen Code fliegt dann alles in die Luft. Das liegt aber eben ganz oft an den Entwicklern die es nicht verstehen.

Aber auch kein Wunder. Die verstehen ja noch nicht mal wie CPUs funktionieren. Wie wollen die da bitte die Prosa von Fortran oder auch C++ verstehen?

Wer von euch hat denn schon mal im Sprachstandard nachgeschlagen wie etwas definiert ist und was der Compiler machen darf oder eben auch nicht?

Ich habe es schon ein paar mal machen müssen und das ist wirklich grausig....

Badesalz

2024-01-12, 20:15:01

@Skysnake
Zwar nicht wie immer, aber wie so oft, hast du eigentlich schon Recht :wink: Es gibt aber auch wenig was einen davon abhalten könnte das halt als Gemeinschaftsarbeit zu sehen =)

Ich komm noch aus der Zeit wo man sich die wirklich rechenrelevanten Sachen paar mal anschaute und die eigentlichen Routinen in ASM unterschob. Und zwar so oft bis man endlich der Meinung war, daß es sich auch wirklich gelohnt hat das getan zu haben.

Ich habe es schon ein paar mal machen müssen und das ist wirklich grausig....
:up: :up:

PS:
Anekdote aus dem RL. Mein ehemaliger Weggefährte hat sich eine Garfiksoft gekauft und es gefiel ihm was am Ablauf nicht. wie er so ist - und da es kein Bug war - hat er solange auf das hyper-hyper geschützte Compilat eingedroschen bis er reinkam. Sein Bericht war im O-Ton:
1. "Ich brauchte echt ne halbe Stunde um erst zu schnallen durch welchen Wunder deren Soft überhaupt in der Lage ist zu starten. Irre."

2. Während der Analyse über eine erst interessante Funktion (Mathe) gestolpert an der er zulange hängen blieb, die sich aber am Ende nur als ein schnöder Farbenzähler rausstellte.
3. Eine Woche immer mal dran, um den Ablauf (das um was es ihm ging) zu ändern. Das war ihm nach brauchbar und stabil gelungen. Ok. Kein Ding.
4. Am Ende leider wieder kurz an den Zähler erinnert und nochmal nur noch aus Freude am Spaß rangesetzt.
5. Die Funktion brauchte nach anschliessend 2h 1/4 der vorherigen (Rechen)Zeit...
6. Alles bis auf das geänderte Zeug gelöscht! "Ich kann mich sonst nicht zurückhalten und ich schreibe deren shic Software jetzt nicht 2 Monate lang komplett um!"

Aber hey, nächster Shrink und nächster CPU-Design-Zauber steht an. Was interessiert all diese Minderbemittelten die Effizienz ihres Codes? Im Compiler paar fake-Flags setzen und sonst rennt der Kunde eh zum Händler und ordert die nächste hyper CPU. Dann läuft auch die Soft schneller.

Die s.g. Softwareindustrie ist ein äußerst ekeliger Sumpf.

Deswegen bin ich nicht bei den Brüdern gelandet. Schon damals nicht. Ich würde den ersten Ahnungslosen ("Produktmanager") nach einem Monat Ohrfeigen und das wars mit der Karriere im Metier :tongue: Bin daher im komplett anderem Berufszweig gelandet, aber dafür wenigstens ziemlich weich :wink:

Skysnake

2024-01-12, 22:01:18

@Badesalz ich habe für nem Hardware Treiber mal online Assembler geschrieben um Daten übers Netz zu kopieren. Der Trick war hier den Write Combining buffer zu umgehen, indem immer 512Bit geschrieben wurden. Also ne komplette Cacheline. Der Witz dabei war, das man wusste das ja die Cacheline komplett ist ;) das war schon sehr cool. Leider hatte der GCC keinen Support für die AVX512 Instruktionen und die Kernel Modules ließen sich mit ICC trotz vehementen Treten einfach nicht dazu bewegen zu compilieren. Jetzt nach rund 10 Jahren hätte ich noch ne Idee. Dem ICC die glibc unterjubeln per flags. Da weiß ich nicht ob das damals schon ging und ob ich es getestet hatte. Aber wie dem auch sei. Damals war wohl die Meinung das es nicht geht den Kernel mit dem ICC zu kompilieren.

Ich habe aber auch später immer wieder Assembler gelesen und das nicht nur für x86. Einfach um zu verstehen warum Code nicht die Performance zeigt die man erwartet. Aber dafür muss man ja erst mal überhaupt ganz handwaving abschätzen wie schnell es denn überhaupt sein soll/muss. Aber daran scheitern ja die meisten schon....

Die sind Größenordnungen in der Performance von Peak weg und erkennen das Problem nicht.... is halt so....

Und mit Containern und vor allem der Cloude und Serverless sind die Layer noch mehr geworden und die Leute noch inkompetente was performanten Code anbelangt...

Man muss es ja teils echt nicht so übertreiben wie ich, der für ne Summierungsaufgabe in nem Übungszettel 40h Zeit oder so aufgewendet hat. Die war dann am Ende aber auch optimal ohne GPu Assembler zu schreiben und Faktoren schneller als die Musterlösung vom Dozenten der uns gechallanged hat ob jemand schafft so schnell zu sein wie seine Lösung....

Aber hey zumindest etwas drauf achten sollten man zumindest schon. Aber was sieht man? OOP wo dann ne Klasse gebaut wird bei der für +1 ein Objekt erzeugt wird....

Da wurde dann aus einer einzelnen Asembler Instruktion tausende von Instruktionen -_-

amdfanuwe

2024-01-13, 03:28:50

Dozenten der uns gechallanged hat ob jemand schafft so schnell zu sein wie seine Lösung....

Guter Mann, hat dich getriggert bei deiner Arbeit auf solche Problematik zu achten.
Programmieren kann man als Wissenschaft betrachten, gibt ja die Informatik.
Nur sind die wenigsten "Programmierer" auch Informatiker.
Wie die Autofahrer; die wenigsten haben Ahnung wie die Technik funktioniert und schon gar keine physikalische Ausbildung um die Fahrdynamik zu verstehen. Selbst die Rennfahrer sind mehr oder weniger nur trainierte neuronale Netze.
Und selbst wenn man einen gewissen Level und Können als Programmierer erreicht hat, bekommt man kaum sie Zeit um ein Programm zu optimieren. Bis es kracht, dann muss man sich die Zeit nehmen.
Da muss man sich nicht wundern, dass so viel Scheiß unterwegs ist, man muss sich eher wundern, dass überhaupt noch was funktioniert.

Skysnake

2024-01-13, 07:34:43

Ja klar, das war extrem und ging zum Teil eben auch nur wegen der Einfachheit der Problemstellung. Ich habe da ja nen bösen Hack genutzt das Wave frontal echt parallel ausgeführt werden und das es innerhalb eines Blocks auch sonst keine Racecondition gibt. Aber gut. Dafür muss man halt die Hardware wirklich gut kennen.

Wenn ich aber x mal verschachtelte Schleifen sehe oder das für Pupskack ein Objekt erzeugt wird, dann ist das einfach dumm. Eine simpelste Komplexitätsanschätzung sagt einem da sofort das das nicht gut geht...

Oder Divisionen durch Konstanten in der inneren Schleife statt eine Multiplikation mit dem Inversen....

Row vs column Major ordering...

Memory Alignment.

Branching in heißen loops

Usw usf. Also Dinge wo ich auf den erst Blick binnen Sekunden erfasse, dass das einfach Mist ist...

DAS muss halt echt nicht sein. Schönes Beispiel aus der Arbeit auch Anwender die hibderttausende von Simulationen laufen lassen, die aber alle nur 10-20 Sekunden laufen.... wo da eigentlich Die Zeit für drauf geht müssen wir nicht drüber reden oder? Also für alles nur nicht um das eigentliche Problem zu lösen -_-

Bei solchen Sachen bekomme ich halt schon einen Kotzkrampf und schüttle nur noch mit dem Kopf. Das ist einfach nur völlige Ignoranz Marke "Öh Compiler sind heute so gut, das kann kein Mensch besser höhöhö"

Wenn man wirklich optimieren würde wie vor 30 Jahren, dann brüchten wir wahrscheinlich nur 1/10 der Systeme für die gleiche Aufgabe und das ist jetzt eher konservativ geschätzt.

@Badesalz wegen dem Dozent. Ja an sich schon. Ich hatte das Problem aber schon vorher mal gelöst und wusste halt das man da noch mehr raus bekommt. Und ihn dann auch gegengechallanged. Wusste ja das ich ne ziemlich gute Lösung hatte. Er hatte uns seine aber nicht vorher gezeigt... sprich ich wusste nicht wie schnell ich sein sollte und war nur minimal schneller oder langsamer als er und das obwohl ich ihn ja gechallanged hatte so marke was wenn wir schneller sind. Ich glaub dann musste man keinen Übungszettel mehr machen oder so. Wie auch immer. Das hatte mich dann natürlich total gewurmt also nochmals ran gesetzt und die Woche drauf mein dann wirklich optimiertes Ergebnis abgegeben und da war ich halt 30-50% schneller oder so. Wie auch immer. Der hatte dich die Lösung angeschaut und dann auch gemeint, dass das ja schon ein sehr böser Hack von CUDA gewesen sei da da der Standard das so eigentlich nicht als Validen Code hergibt. Also eigentlich rein nach Code kein deterministisches Ergebnis erzeugen sollte... was er aber tat, weil die HW halt war wie sie ist :D

Geil war da auch unsere Tutorin für parallele Rechnerarchitektur. Die hatte Ahnung, aber weniger als 50% ihrer Teilnehmer. Das war immer sehr lustig. Sie ist nach den Übungen immer mit mehr Wissen raus als rein :D war extrem geil, weil wir uns halt gechallanged haben in der Gruppe. Wobei wir waren glaub 10 äh ganz schnell 8 Leute und von denen haben 4 sich dann das Zeug um die Ohren gehauen.

Platz 3 ging immer an ne Gruppe aus zwei Leuten (bis auf einmal, wo sie "betrogen" haben da ihre Rechnung zur Compilezeit gelöst wurde und das Programm quasi nur noch eine statische Ausgabe gemacht hat.... konnten wir aber in der Übung nachweisen weil Stift und Papier uns sagte das ihre Lösung zu schnell ist. Das konnten Platz 2 und 1 nicht auf sich sitzen lassen :D)
Platz 2 ging eigentlich immer an mich, ein oder zweimal auch Platz 1
Platz 1 war nen Bekannter, der es einfach immer etwas übertrieben hat. Der hat andere Algorithmen verwendet oder ist mit InlineAssembler gekommen oder sonst was. Das war mir dann doch immer ne Spur zu extrem und Aufwändig. Der war wirklich richtig gut, macht in dem Bereich aber glaub leider nichts mehr. Wirklich schade drum. Der hatte ein Auge für. Auch wenn er die Spielregeln maximal frei interpretiert hat ziehe ich da bis heute meinen Hut vor und das mache ich nicht bei vielen.

War aber halt immer lustig, weil die Tutorin dann bei der Besprechung gesagt hat, sie hätte zwar auch ne Lösung, aber die Platz 1-3 wären halt deutlich besser deswegen sollen wir die doch einfach mal für alle erklären.

Ich glaub das war für die anderen ne ziemlich deprimierende Übungsgruppe. Aus meiner Sicht aber wirklich anspornend, weil man dann doch richtig was lernen konnte obwohl man in dem Stoff schon richtig fit war.

Das hat mir auch das erste mal gezeigt, wie wichtig ein Performantes Umfeld ist an dem man sich reiben kann um selbst Spitzenleistungen zu zeigen.

Tobalt

2024-01-13, 09:09:28

Jaja die Erlebnisse von Optimierungen kennt wohl jeder. Ich denke aber dass die Erwartung sowas vom Durchschnittsmonkey zu verlangen nicht realistisch ist. Es ist wie uwe sagt: selbst fähigen Leuten fehlt die Zeit, sie kommen in halbfertige Projekte, man kriegt OOP nicht mehr aus den Köpfen der Leuten usw.

Dagegen gibt es nur das Mittel dass es zwischen menschlichem Progger und Kompilat künftig bessere automatische Schritte gibt.

Also konkret: Dass im Rahmen des Compilers vielleicht durch AI auch Verbesserungen vorgenommen werden (sofern man es erlaubt) die semantisch unzulässig sind, aber wahrscheinlich so gedacht waren vom Progger.

Generell sehe ich hier tatsächlich vielehe Potential als bei der Hardware in den nächsten 10-20 Jahren Zeithorizont.

Noch konkreter: Ich habe letztens erst Student erklärt, dass was er da tut kein Programmieren ist, sondern Coden. Er produziert code, der irgendwas tut. Er denkt nicht über das Programm nach, über das große Ganze. Zum Programmieren braucht man nichtmal die Tastatur, sondern Kopf, Zettel, Stift.

Ich habe ihm gesagt er soll erstmal die State machine aufmalen, und die state machine optimieren, redundanzen eliminieren mit Logik usw. und wenn ich damit zufrieden bin, darf er mit coden anfangen.

Mein Punkt ist: Die state machine ist das was der Programmierer wirklich verlangt und möchte. Alles ab da auf dem Weg zum Kompilat kann durch den Mensch prinzipiell nur noch verschlimmbessert werden. Deswegen finde ich, dass man künftig vielleicht nur noch in einer Art Chat GPT Dialog mit dem Compiler die State machine diskutiert, der Compiler stellt Rückfragen, wie was gemeint ist etc. Und that's it, raus kommt das Assembly.

PS: state machine ist jetzt hier einfach stellvertretend für den programmatischen Logikfahrplan

Zossel

2024-01-13, 09:57:19

Man sollte allerdings beachten das die ganzen von Hand optimierten Assemblerroutinen z.b. im Linuxkernel/opensssl/libc gerne mal CVEs bekommen.
Beim Optimieren wird gerne mal im Eifer des Gefechts der eine oder andere Cornercase übersehen.

BTW: Das Compilat der innersten Schleife von gzip zum komprimieren sieht in meinen Augen ziemlich schrecklich aus. Mit breiten Registern, shiften, ausmarkieren von Bytes und evtl. auch expliziten Prefetch könnte da was drin sein, es kann allerdings auch sein das die Bandbreite vom Cache da limitiert. Früher hätte man die Muße gehabt sich da ein paar Tage reinzufressen, aber die monatliche Überweisung fordert Tribut ........

Badesalz

2024-01-13, 10:16:44

@Zossel
:up:
Auch wenn dabei erwähnt geht es aber leider bei weitem nicht einfach nur darum, daß die Völker zu blöd sind auch mal ASM-Routinen dazwischen zu schieben. Wenn es nur noch das wäre, wäre das schon fast der Idealfall.
Nur noch eine leichte Erkältung, gegenüber der Tuberkulose die wir auf den Platten liegen haben.

Für den Rest :freak:
Ich hab das hier eingeschoben, nicht um den Thread zu kapern. Das hängt schon sehr wohl mit dem Thema und damit warum man sich die Frage (Threadtitel) stellt.

Die stehen zwar noch nicht vor der Tür, aber jetzt wo wir langsam das Ende der Shrinks im klassischen Sinne am Horzont sehen, sollte man sich eben auch andere Fragen stellen wie es weiter schneller gehen könnte.

Und da stellt man imho fest, daß die Softwareindustrie der Hardwareindustrie Lichtjahre hinterher hinkt.
Das ist ein Geschwür welchen die Hardwareindustrie paradoxerweise durch ihre eigenen Fähigkeiten mitgezüchtet hat. Sie hat all diese Wucherungen ausgebadet.

Vas uns dadurch gänzlich abhanden gekommen ist, ist die Diskussionskultur über Codequalität. Die existiert aktuell nur noch bezüglich seiner Sicherheit.

ich spreche das immer wieder mal an, weil das zukünftig von alleine wohl nicht besser wird. Grad Photonik, wie hier angesprochen, beschäftigt sich eigentlich damit diese wuchernde Masse am schwachsinnigen Müll schneller hin und her zu bewegen. Es geht da ja nicht nur um die real "echten" Nutzdaten.

Tumor-Codes gehen damit leider noch besser unter :frown:

PS:
Ich gehe aber auch mit der Meinung von Leuten die bemängeln, daß schon die Entwicklungswerkzeuge Schrott sind, da sie kaum restrektiv sind. Wofür wie Skysnake aber schon ansprach, so manche Programmiersprache aber auch selbst generell dazu beiträgt.

latiose88

2024-01-13, 11:22:54

wow ihr kennt euch aber aus.Ich verstehe nur ein teil davon.Ich selbst habe mal mich wo bei Beworben gehabt die machen nix anderes als den ganzen Tag ne Fehlersuche von einem fertigen Programm zu suchen.ALso den fertigen Code abzusuchen um wenn es Probleme gibt es zu verbessern.Dafür wird die Firma bezahlt.Besonders Autisten sind dafür gegeeignet weil Inselbegabung.Ich dachte eben ich hätte auch eine.Naja dann kamen unterschiedliche Tests dran.Am Ende habe ich versagt gehabt,aber ein kleiner teil von dem ganzen habe ich gelernt gehabt,wie C+,C++ und so.
Ich merkte aber wie Komplex das ganze doch am Ende ist.Ist nicht jedermanns Sache.Wer sowas kann,da kann man echt nur Respekt davor haben.Das da am Ende nicht doch Fehler entstehen und so.Nur die wirklich guten können das.
Das erklärt auch warum so manche keine Chance haben,weil so einfach ist Programmieren ja nicht.

Achja wenn man eine Software Jahre Lang die selben gleiche verwendet,dann gibt es von Software aus keine Verbesserung.Denke mal das es nur bis zu einem gewissen Grad die Hardware ausgleichen kann das ganze.
Warum meine 5 Jahre alte Software schaffte bei einem aktuellen Threadripper 7960x schlechter ab als der Vorgänger.Mit ner Aktuellen Version wurde das Umwandeln schneller.Also Software hat selbst bei so was Simples auch Einfluss auf die Zeit.
Es hat nur ein Problem bei der neueren Software,es merkt sich gewisse Einstellung nicht mehr.Das heißt man muss diese immer wieder neu Einschalten.Bei jeder Aufnahme neu.ALso wer das Programmiert hat,der hat schlampig Programmiert.Ich selbst kann das nicht machen und weis nicht ob ich da einen dieser Freien Entwickler überhaupt Fragen kann oder geschweige denn eine Nummer zum Anrufen überhaupt gibt.Wäre das Problem nicht,würde ich schon auf die neueste Version wechseln.Denn dann würde es auch bei mir zu einen Boost kommen.

Die anderen neueren Versionen gab es noch Probleme mit WIndows 11 und führte zu merkwürdigen Verhalten.Wie halt das nur einer dieser Chiplet ganz ausgelastet wird und der zweite nur die Logischen Kerne und SMT nicht angerührt.So wurden dann am Ende dann nur 24 Threads bei einem 16 Kerner zu 100 % Ausgelastet und das war es dann auch schon.Die restlichen Threads zu 0 %.Sehr merkwürdig.Auch bei Intel gab es immer wieder Schwankungen bei der Auslastung.Irgendwas haben die Verpfuscht gehabt,weis nur nicht eben was genau.

Skysnake

2024-01-13, 14:33:12

Was die Leute nicht verstehen ist, das man die groben Fehler vor dem programmieren verhindern muss durch Komplexitätsanslyse usw.

Wirklich optimieren tut man aber auf Grundlage von Profiling. Denn meist sind es nur ein paar Routinen oder Schleifen die man optimieren muss. Also zumindest wenn man eben vor dem Programmieren nachgedacht hat.

Das Profiling ist aber wichtig egal wie gut man ist. Code ist einfach extrem komplex und man hat eben Abhängigkeiten zur Laufzeit. Multiple Code Pfade machen jedwede statische Analyse bezüglich Performance zunichte.

Zudem gibt es Effekte die kann man nur zur Laufzeit sehen, weil sie HW spezifisch sind. Das kann man dann zwar wie Cache blocking parametrisieren aber das im Voraus machen ist unmöglich vom Aufwand her.

Aber zwei allgemeine Punkte noch.

1. Co Design wird stärker nachgefragt weil sich eben immer weniger tut
2. Spezialisierte HW schlägt überall auf. Relevante Leistungssteigerungen abseits von mehr Cores gibt es nur noch durch neue Features.

amdfanuwe

2024-01-13, 16:09:33

Ich habe ihm gesagt er soll erstmal die State machine aufmalen,
Mit aufmalen kommt man nicht weit, Statecharts muss man interaktiv erleben um da richtig reinzukommen.
Hier gibt es ein für Hobby Bereich kostenloses Tool, dass mir gut gefiel:
https://www.itemis.com/en/products/itemis-create/licenses#standard-edition-non-commercial-use

Parallel Programmieren hab ich erst in einem SPS Kurs gelernt. Da merkt man erst, wieviel bei einer simplen Ampel Steuerung schief gehen kann.
War nach Jahren langem C/C++ schon ein Umdenken erforderlich.

Richtig Spaß gemacht hat mir dann die Programmierung in Labview.
Wieder ein Umdenken von Prozeduraler Programmierung auf grafische Datenfluss orientierte Programmierung. Hieß einfach: "Sie können doch programmieren, machen sie mal".

So läuft das in der Industrie, für alles braucht man einen Schein bloß programmieren darf jeder, der ein "Hello World" auf den Bildschirm bringt.
................................................................................ ........................
Um mal zum Thema zurückzukommen: Noch ist etwas Luft für kleinere Strukturen. Neu Ansätze wie CFETs, Nanoröhrchen etc.

Vielleicht kommen danach biologische Computer. Man sieht ja, was mancher mit seinen paar Pfund Gehirnmasse so anstellt.

Quantencomputer sind auch nicht das Allheilmittel, für bestimmte Aufgaben spitze aber nicht für alles. Ebenso wie neuronale Netze oder herkömmliche Computer.

amdfanuwe

2024-01-13, 16:15:55

Komplexitätsanslyse usw.
Profiling
statische Analyse
Erzähl das mal den Leuten, die vom Arbeitsamt auf ein 3 Monatige C, JavaScript, Java oder C++ Schulung geschickt werden und meinen sie könnten dann programmieren.

Tobalt

2024-01-13, 16:43:12

Bzgl "Aufmalen". Das war jetzt gar nicht das entscheidende Wort in meinem Satz, sondern "student" ;) Und es war auch ein übersichtliches Problem, was, wenn übersichtlich programmiert, locker auf eine Seite passt.

Hätte man dem "coden" da keinen Einhalt geboten, wären es wohl 10 Seiten geworden, voller grauenhafter Redundanzen und Abhängigkeiten. Blöderweise wäre wohl was rausgekommen, was zu 90% sogar noch funktioniert hätte. Also fügt man nochmal 10 seiten "code" hinzu um Bugs zu fixen, sodass am ende 99% alles funktioniert.

Für mich ist gut vorstellbar, dass in industriellem code sehr oft genau diese Qualität steckt..

Würden sich Leute mehr aufs Programmieren konzentrieren und das fehleranfällige weil semantisch feinschichtige Coden bereits dem Compiler überlassen, wären wir von der Performance wohl schon eine Größenordnung weiter.

Skysnake

2024-01-13, 17:18:31

Erzähl das mal den Leuten, die vom Arbeitsamt auf ein 3 Monatige C, JavaScript, Java oder C++ Schulung geschickt werden und meinen sie könnten dann programmieren.

Tja coden ist halt nicht richtiges Programmieren. Für irgendwelchen wegwerfcode reicht das ja, aber wenn etwas Bestand haben soll dann sollte man das auch richtig machen. Nen Schuppen kann jeder Depp irgendwie zusammenzimmern. Nen 80 stöckiges Hochhaus in net Erdbebenzone eher wenige...

The_Invisible

2024-01-13, 17:24:04

Badesalz

2024-01-13, 18:24:09

@Tobalt
Einmal noch: :up:

Ihr seid ja witzig, bei welcher Firma bekommt man noch Zeit für die Optimierung eines Programmes? Siehe aktuelle Spiele- und Softwareindustrie, da gibts eine Deadline und dann hat das fertig zu sein, Funktionalität steht vor Optimierung wobei nicht mal das anständig funktioniert.Ich hab zwar erst die Programmierer beschimpft, aber dann auch hinzugefügt, daß die "Softwareindustrie" ein Sumpf ist :wink:

Funfact für Leute die keine Berührungspunkte mit dieser Krebsforschung haben:
In C(++) aber nicht nur da, ist es nicht selten so, daß der Compiler eine längere Codezeile für die gleich gedachte Funktion besser umsetzt als eine kürzere (!) Sagen wir einfach salopp, der Quelltext kauft ihm das besser vor was denn eigentlich zu tun wäre.
In etwa wenn dir einer 15s lang etwas erklärt, ist das bestimmt verständlicher als wenn er es auf 5s verkürzt. Deine Verarbeitung für die Interpretation dauert samt Zuhören zwar länger, ist am Ende aber genauer bzw. für dich verständlicher, um damit exakt das richtige anzufangen.

Und eines der Probleme damit ist, die Pfuscher haben teils sogar trotz des besseren Wissens einfach keine Lust für solche "15s-Zeilen". Die "5s" funktionieren ja auch. Mehr Zeichen sind auch mehr Tippos. Mehr Fehler die man korrigieren muss. Schlecht.

Es gab sogar eine Ausarbeitung die sich nur mit den Zeichen in der Semantik beschäftigte und schon da hatte man solche Treffer, daß die Leute manche Konstrukte halt weniger nutzen, weil sie in C für so eine Zeile auch 4x Shift zusätzlich drücken müssten. Das wäre sehr lästig...
Und es gibt auch wirklich Sprachen bei welchen man bei der Semantik wenigstens bisschen auf sowas achten wollte (!)

Wer damit nichts zu tun hat und es für "Kaninchenbau" hält: Nein. Ja der Einstieg ist tatsächlich ein Loch, man sollte sich das aber eher als eine Senkgrube vorstellen.

Und um am Ende klarer die Kurve zum Topic herzustellen:
Wir geben Milliarden für den nächsten Shrink aus und all diese Penner fressen das unmittelbar danach wieder auf.
Und lügen uns dabei auch noch direkt ins Gesicht, daß man eben schnellere Hardware braucht, weil die "Komplexität" der Programme eben steigt.

Na klar steigt sie. Der Haufen an Spaghetticode wird mit jeder Version eben größer. Komplexität am A... :mad:

Skysnake

2024-01-13, 21:28:16

Ihr seid ja witzig, bei welcher Firma bekommt man noch Zeit für die Optimierung eines Programmes? Siehe aktuelle Spiele- und Softwareindustrie, da gibts eine Deadline und dann hat das fertig zu sein, Funktionalität steht vor Optimierung wobei nicht mal das anständig funktioniert.

Immer dann wenn man es muss. Ich hatte z.b. recht viel Zeit in die Optimierung unseres Management Systems gesteckt weil man schlecht interaktiv arbeiten konnte bzw auch bei was anderes weil es ne harte Zeitanforderung gab.

Man muss halt nur Anforderungen definieren, dann bekommt man auch Zeit. Muss man im Zweifel aber dann halt auch bezahlen...

War bei mir btw ne Mischung aus Perl legacy Anwendung, Python und Bash. Hat die Anforderungen erfüllt und ist schneller umgesetzt als mit C++.

Das ist halt der Punkt. Wenn man eine gescheite Architektur hat, geht für ganz viel Python oder sonst ne Script Sprache.

latiose88

2024-01-13, 21:34:51

Aber zwei allgemeine Punkte noch.

1. Co Design wird stärker nachgefragt weil sich eben immer weniger tut
2. Spezialisierte HW schlägt überall auf. Relevante Leistungssteigerungen abseits von mehr Cores gibt es nur noch durch neue Features.

Naja es scheint wohl ne Ausnahme zu geben,wo es trotz fehlender neuen Future es zu mehr Leistung gegeben hat,trotz das es keine neuen Feature raus gekommen war.Scheint wohl bis zu einer gewisse Grad doch noch zu gehen.

Skysnake

2024-01-14, 06:45:10

Wo denn? Meinst du die 5% Mehrleistung beim Wechsel der CPU Generationen?

Ganz im Ernst, ich verprobe seit ca 10 Jahren CPUs und Beschleuniger. Einige Jahre mal mehr andere mal weniger, aber wenn weniger bin ich nah an ganzen Teams die nichts anderes machen und tausche mich mit denen aus.

Worauf ich hinaus will. Wenn du deinen Code nicht anpasst oder mindestens neu compilierst, damit er neue Instruktionen nutzen kann, dann läuft es bis auf paar Prozent auf
- mehr Cores
- mehr Takt
- mehr Speicherbandbreite raus

Da gibt es für bestehenden Code einfach keine großen Sprünge. In den tollen Folien von Intel und AMD sieht man ja auch immer wie wenig ein großer Teil der Tests profitiert. Und dann einige die stark profitieren und die nutzen halt neue Features.

Das Problem ist vor 10 Jahren hatten die neuen Features noch eine Relevanz für die Allgemeinheit und/oder HPC. Heute sind es im Wesentlichen noch zwei Gruppen die davon profitieren

1. VM/cloud Betreiber die ihre VMs besser gegeneinander absichern wollen. Als confidential Computing bzw Zero Trust also z.b. Verschlüsselung auf allen Ebenen. Intel bewirft einen da ja auch aktuell mit Beschleunigern in den CPUs.
2. AI Leute die noch weniger Precision wollen und noch mehr Fixed Function Blöcke.

Für HPC geschweige denn Wald und Wiesen Code hast du da genau 0, in Worten, Null Benefit von.

Ich überleg mir im HPC ja inzwischen selbst ob man die ganzen Encryption Sachen nicht nutzen soll weils halt da ist und die Sicherheitsvorgaben immer weiter ansteigen und man damit dann an sich mal Ruhe hätte zu einem gewissen Grad.

Und das obwohl es am Ende Leistung kostet. Nur eben nicht mehr so prohibitiv viel wie Früher...

Aber wie gesagt im Wesentlichen drehen sich meine Gedanken nur noch darum ob man nicht etwas nutzt was es an sich schon ewig gibt aber immer zu langsam war und einem für compute an sich nichts bringt.

Ebenso VMs. Total bannane, aber ich spiele mit dem Gedanken Sie zu verwenden weil man so wie die Cloud und SaaS Anbieter das OS haargenau auf eine Anwendung in einen Anwendungsfall aufbauen kann. Gibt nämlich genug Softwarehersteller die nicht in der Lage sind mehrere ihrer Softwarestände über 3-5 Jahre zu supporten während sich Linux weiterentwickelt.

Die Kadenz an Anpassungen wegen Security ist denen einfach zu hoch. Die packen das nicht. Ich finde das echt erschreckend wenn man bedenkt wie OpenSource Prpjekte das schaffen, die ja oft genug sogar nur nebenher laufen. Ich will hier nur exemplarisch mal Curl erwähnen. Da ist es einfach ziemlich transparent und ich kann inzwischen seine Aussagen bezüglich der Erwartungshaltung von großen Firmen absolut nachvollziehen.

Wenn man aus dem HPC Bereich kommt und da auch über OS Grenzen hinweg entwickelt hat über Jahre und dann sieht was nicht wenige Unternehmen mit Hunderten Millionen oder gar Milliarden abziehen, dann wird einen schlecht.

Ich habe das Gefühl das so einige Closed Source Anbieter so langsam richtig richtig heftige Probleme bekommen, weil sich Linux eben wie ein Parasit in deren Strukturen gefressen hat und die davon überfordert sind.

Der Punkt ist. Linux ist heute oft einfach gesetzt. Selbst Microsoft hat das ja ganz massiv in ihrer Cloud eingesehen.

Das wird die nächsten Jahre echt spannend. Insbesondere mit dem Umstieg auf RedHat9 könnte das ein paar Knaller geben, wenn ich mir so ein paar erste Erfahrungsberichte anhöre.

Und RedHat 10 time wird dann bestimmt noch schlimmer wenn die aktuelle Pace beibehalten wird. Insbesondere halt im Hinblick auf Securityanforderungen und deren Seiteneffekte.

Badesalz

2024-01-14, 09:58:06

Worauf ich hinaus will. Wenn du deinen Code nicht anpasst oder mindestens neu compilierst, damit er neue Instruktionen nutzen kann,
Ich bin mir nicht sicher inwiefern das neue "Instruktionen" betrifft, aber man erinnert sich an die Sache mit XPsp3, was mit dann neuen MSVC gemacht wurde.

Keine reale Anwendung konnte imho etwas nennenswertes (?) dazu gewinnen, aber die Schwupdizität eines frisch aufgesetzten XPsp3 war für 3 von 4 Benutzern feststellbar höher als von frischen XPsp2, XPsp1 doer XP.

Ich hab es zwar nicht wirklich verfolgt, meine aber obwohl es ne Weile in aller Munde war hat MS nie über gezielte solche Optimierungen gesprochen :rolleyes:
Es gab sogar Gerüchte, daß sie es heimlich mit ICC kompiliert haben :tongue:
Hier bleibt also auch oft einiges liegen.

Das meiste an den Shrinks frisst aber ohne Frage Bungler-Code auf, welchen die Hersteller mit "Komplexität" begründen.

Tobalt

2024-01-14, 10:47:50

Ihr seid ja witzig, bei welcher Firma bekommt man noch Zeit für die Optimierung eines Programmes? Siehe aktuelle Spiele- und Softwareindustrie, da gibts eine Deadline und dann hat das fertig zu sein, Funktionalität steht vor Optimierung wobei nicht mal das anständig funktioniert.

Es läuft so weil es geht.

Hardwareanforderungen rauf setzen war bislang der billigere Weg gegenüber besser zu programmieren für die Studios.

Wenn die Nutzer wegen Hwatdware-Preisen immer zurückhaltender werden, dann geht dies nicht ewig weiter. Irgendwann wird der Druck auf die Studios wachsen, mehr abzuliefern mit gleicher Hardware.

Und wie die Vergangenheit gezeigt hat, reichen ein zwei games aus, die Durchbrüche in der Programmierung erzielen, um die Nutzer und die Studios für die Zukunft aufzuklären.

ChaosTM

2024-01-14, 11:40:00

Ich sehe die besten Entwicklungsmöglichkeiten für effizientere Software/Spiele eher bei den Engine- und Chip-Produzenten. Die haben es in der Hand den Spieleentwicklern effizientere Tools zur Verfügung zu stellen, die weniger Aufwand erfordern.

Eigene Engines zu pflegen wird immer teurer und das werden können sich bald nur mehr die großen Studios leisten können.

Siehe NV/AMD + Epic und Konsorten.

Tobalt

2024-01-14, 11:45:47

In der besten Engine gibt's genug Möglichkeiten Schindluder zu treiben. Aber insgesamt stimmt schon. Der (dumm)menschliche Faktor muss an mehr Stellen eliminiert werden, dann wirds besser.

latiose88

2024-01-14, 13:26:03

@Skysnake
Wenn ich das aufliste,dann sind es sogar 6% mehrleistung.Aus folgende sind diese 20 % mehrleistung entstanden:
VOn Zen 3 auf Zen 4 16 Kerner,12 % von 3,8 ghz auf 5,1 ghz als Vergleich(bei 4,8 ghz sind es immerhin noch immer 7% Leistungsunterschied),2% von DDR4 auf DDR5 und 6 % durch die Verbesserung der CPU Archetekur.
Würde ich den Ryzen 9 7950x also auf 4 ghz senken,so hat es wer getestet gehabt,dann sinkt der Stromverbrauch auf denke mal das es 90-100 Watt waren herab.Darum weis ich so genau die IPC Steigerung.
Ob es in Zukunft noch solche Explosion beim Allcore Takt gibt,denke ich mal so schnell nicht mehr.Würde ich noch weiter aufschlüssel das ein 24 Kerner ohne SMT(7960x) ganze 7% schneller bei meiner Anwendung war als der 7950x.
Dann noch das AVX nur in Kombi einer gewissen Einstellung dann ganze 7% zulegen konnte.Also AVX generell.
Dann habe ich alles aufgeschlüsselt.Ich weis AVX kann weit mehr steigern wenn die Software es beherscht,wie auch SMT,genauso wie wenn es mehr Kerne auch die Leistung massiv steigert.
Mit dieser kenntnis was ich herausgefunden hatte von mir,kann man durchaus für die Zukunft ableiten.
Das verhalten mit den Kernen ist über mehrere unterschiedliche Generationen von CPUS Serien hinweg immer gleich gewesen.Bei AVX war die Steigerung bei mir immer sehr gering.Ich konnte machen was ich wollte,aber änderte sich nicht.Ram Steigerungen wurden auch immer weniger je höhere die Bandbreite wurde.
Ich muss es wohl akzeptieren das die Sprünge immer kleiner werden.Wenn also nur noch die CPU hier das Wort hat,dann wird das alles nicht ausreichen ,für ne massive Steigerung.Scheinbar erwarte ich einfach zu viel.Und das ganze wenn es die Software nicht mit macht,einfach mit noch mehr CPU Leistung zu zu kleistern auch nicht immer klappen wird.
Ich merke das ja sehr deutlich das so starke Threadripper nur mit neueren Software Version noch was bewegt wird.Die wo ich habe,sinkte die Leistung sogar gegenüber dem Vorgänger.

IPC kann also nicht alle Workloads gleich gut Steigern.Es gibt sogar einen Rückstand.Sowas habe ich früher noch nie erlebt gehabt.Kann es echt kaum glauben,wenn ich die Ergebnisse nicht vor mir hätte.
Naja ich hoffe das es in Zukunft besser wird,aber das ist wohl eher mehr hoffen als das es wirklich ein Treten könnte.Hoffen kann man doch immer oder nicht?

PS: was heißt denn Bungler-Code?

Skysnake

2024-01-14, 14:15:54

IPC Steigerung kannst du in Heimanwederbereich quasi komplett in die Tonne treten. Mehr als 2-3 ist einfach nicht drin. Wo mehr geht kannst du fast immer SIMD verwenden. Was noch ne gewisse Einschränkung ist, ist der Dateizugriff. Da sind Vektorrechner mit HW scatter und gather im Vorteil. Wenn man sich aber anschaut welchen Aufwand das bedeutet un den Nutzen dagegen stellt sind einfach mehr Cores in der Regel die bessere Alternative.

Und da wo es was bringt bist du ganz schnell in der Situation das GPUs effizienter sind.

Sprich wird sind da einfach echt in einer Sackgasse mit der aktuellen HW und den aktuellen Programmiermodellen. Teils aber leider sogar mit den Problemen an sich. Gerade bei Molekulardynamik mit langreichweitigen Kräften bist du bei der Simulation bei einem Knoten eigentlich inzwischen am Ende mehr HW drauf werden bringt einfach nichts und macht es nur noch langsamer. Wenn muss man mit eigenen ASICs ran. Den Schritt ist man aber auch schon gegangen. Sprich da hilft nur noch mehr Takt für mehr Leistung und das geht nicht mehr. Sprich man ist dq GameOver und das kommt in immer mehr Bereichen.

Im Prinzip musst du einfach mehr von dem gleichen machen. Also trivial parallele Probleme werden wirklich noch schneller aber das wars dann eigentlich auch abseits von Weak Scaling.

Strong scaling geht kaum noch was.

Meine ganz bescheidene Meinung als Betreiber von Clustern mit insgesamt Tausenden von Usern und Tausenden von Nodes also Hunderttausenden cores und Dutzenden wenn nicht hunderten Anwendungen.

latiose88

2024-01-14, 15:27:22

achso stimmt ja,du bist da was größeres gewöhnt als ich.Da bin ich wohl echt was kleines,bei solchen Dimensionen,von dem du da schreibst.Naja kleine verbesserungen wird es vielleicht noch geben,man kann das nur hoffen,aber ob da eintritt ist was anderes.Hoffen kann man ja bekanntlich immer.

Skysnake

2024-01-14, 16:27:19

Ja Verbesserungen wird es noch geben, aber wie man an der Top500 auch sieht halt immer langsamer, was dazu führt das man Systeme immer länger nutzen kann bevor es sich wirklich lohnt was Neues zu kaufen. Früher waren es alle 2 Jahre, dann drei und inzwischen ist man bei 5-8 Jahren perspektivisch. Auch wenn viele noch immer alle 3 Jahre wechseln.

Die Option auf Wartungsverlängerung von 4 oder 5 Jahren wird immer häufiger angefragt und auch tatsächlich auch gezogen.

Oft genug wird geupdated weil man das ja so macht. Man bekommt ja auch das Geld dafür. Warum also nicht durchbringen? Sonst bekommt man ja nächstes mal weniger.

PS: sooo groß ist das jetzt auch nicht. Wirklich große Systeme sind ja Faktor 10 größer. Ich hatte halt durch die Arbeit bei nem Hersteller solcher Systeme halt auch die Sicht auf viele Systeme. Mein größtes wigenes Systeme hatte keine 2.000 Knoten. Da geht also noch was. Als Nutzer waren es jetzt auch "nur" 8.000 ist aber schon ein paar Jahre her.

Badesalz

2024-01-14, 18:21:32

In der besten Engine gibt's genug Möglichkeiten Schindluder zu treiben.
Erinnert sich noch jemand an den Hack samt... Codeanalyse und folgenden Rants bei Assassins Creed? :wink:

Ich sagte schon, daß wir mit Photonic-Com den nächsten fetten Schub erleben werden. Das wird wie SATA3 HD auf SATA3 860pro sein. Und die Pfuscher freuen sich schon nen Keks drauf :P

@Chaos
Wenns denn nur um die paar Spielereien gehen würde...

Tobalt

2024-01-14, 18:32:32

Skysnake ich denke, dass künftig man einfach die Algos für bestimmte Problemklassen ändern muss. Bsp Optimierungsaufgaben. Ein iterativer Algo ist vielleicht effizient was die Anzahl an ops angeht und auch die Task Energy.

Ein paralleler nichtiterativer kann aber möglicherweise ne geringere Latenz haben.
Traditionell gab es quasi überall nur die sequentielle Algos, weil die zum sequentielle Code und Computerdesign gepasst haben.

Wenn du aber die Präzisionsanforderungen runterschraubst, wirst du bei einer bestimmten Zahl paralleler Trials immer ein ausreichend präzises Optimum finden.

Darüberhinaus gibt es ja noch neue Computingkonzepte die intrinsich simultan rechnen und damit parallele Algos massiv bevorzugen. ZB Quantum Computing, aber auch das etwas reifere Probabilistic computing.

Die Grundfrage, die man sich stellen muss: Wenn ich eine unbegrenzte Einheitenzahl hätte, mit welchem Algos kriege ich die geringste Latenz für ein bestimmtes precision target? Iterativ ist quasi nie die Antwort. Man braucht viele parallele Einheiten und eine intrinsische Auswahl des richtigsten Ergebnisses. 1-2 Schritte also und keine branches.

Skysnake

2024-01-14, 19:18:45

Keine Ahnung was du meinst, aber serielle Algorithmen gibt es in meinen Bereich nicht.

Das eine was du beschreibst ist quasi steong scaling und das andere embarasing parallel. Also was z.b. bei MonteCarlo gemacht wird.

Also das ist alles schon da und bringt uns da hin wo wir heute sind.

latiose88

2024-01-14, 19:28:56

Und diese Photonic-Com was geschrieben habts,ist lichtbasierte Verbindung.Damit erhöht man ja die Bandbreite.Kann man damit auch durch das die Transistoren Dichte erhöhen oder wird da was anderes damit gemacht und würde so Element Platine also Natürliche Material wie Organischen Platine die Leistung der Hardware verbessern,oder geht das nicht?

Tobalt

2024-01-14, 19:43:05

Skysnake, dann redest du aber nur von Hpc, oder in welchem Bereich werden nur parallele Algos genutzt?

Was ich meine, sind die "nicht parallelisierbaren" Probleme des Wald u Wiesencodes. Die werden explizit lösbar, wenn man eine präzision und eine Zielwahrscheinlich vorgibt, vorausgesetzt ihre Lösung lässt sich leicht überprüfen.

Und ich schätze, dass man bei vielem Kram irgendwann diesen Weg gehen wird, weg von völligem Determinismus dafür schneller.

Skysnake

2024-01-14, 20:19:06

Skysnake, dann redest du aber nur von Hpc, oder in welchem Bereich werden nur parallele Algos genutzt?

Ja, aber auch im ingenieurswissenschaftlichen Bereich werden eigentlich nur parallele Algortihmen verwendet. Überhaupt fast überall wird paralleliisert, außer vielleicht im Buisness Umfeld.

Wirklich seriellen Code gibt es doch nur noch ziemlich eingeschränkt. Also nur bei Dingen, die wirklich keine Performance brauchen und in Sekundenbruchteilen fertig sind, oder halt einfach null Effort dahinter steckt.

Was ich meine, sind die "nicht parallelisierbaren" Probleme des Wald u Wiesencodes. Die werden explizit lösbar, wenn man eine präzision und eine Zielwahrscheinlich vorgibt, vorausgesetzt ihre Lösung lässt sich leicht überprüfen.

Also entweder ist etwas parallelisierbar oder nicht.

Es gibt btw wirklich Probleme die einfach nicht oder nicht weiter paralleliserbar sind. Wie gesagt Stron scaling ist hier das Stichwort. Irgendwann bist du einfach am Ende.

Hier ist das Beispiel mit der Fernwirkung bei der Molekulardynamik so ein Beispiel. Die haben parallele Algorithmen und werfen so viel Hardware drauf, bis die zusätzliche Hw die Lösung langsamer macht. Also zumindest oft. Wenn du halt x Monate auf ein Ergebnis warteste, dann bist du irgendwann auch bereit die doppelte Menge HW drauf zu werfen um 10% schneller zu sein. Die sind da ziemlich hardcore drauf. Aber ist halt auch irgendwo egal. ob du jetzt 1, 2 oder 4 Rechner für drei Monate belegst.

Deren Problem ist halt, das sie teils lange Zeitskalen simulieren müssen und da müssen sie halt sequenziell dran. Die wollen das eine einzlene Event simulieren und nicht irgend ne Statistik. Die wollen wissen ob etwas überhaupt geht.

Und ich schätze, dass man bei vielem Kram irgendwann diesen Weg gehen wird, weg von völligem Determinismus dafür schneller.

Badesalz

2024-01-14, 20:42:47

Was ich meine, sind die "nicht parallelisierbaren" Probleme des Wald u Wiesencodes.Wenn das mal wirklich ordentlich geschrieben ist - oder geschrieben worden wäre - gäbe es da noch ein Leistungsproblem mit derartigen?
Vielleicht ist das nur meine Blase, aber ich hab ab SandyBridge sowas nicht mehr gehabt.

edit:
Verzeiht kurz das OT. Wir waren ja grad kurz bei Molekular... :usad:

Skysnake, MPi sollte doch 3Q XH3000 Genoa/300A (300X?) bekommen. Hast du was gehört, ob das schon produktiv läuft?

latiose88

2024-01-14, 22:02:30

@skysnake
So so die doppelte Menge an Hardware.Das wäre so als ob ich anstatt den 16 Kernen auf 32 Kene gehen würde um noch Leistung zu erhalten.
Wie sieht es da aus wenn schon Zen1 + und Zen 2 Threadripper mit 32 Kernene schon Probleme mit SMT gehabt hatte und auch sonst nicht zu 100 % sondern schon ohne SMT 32 Kernen nur zu 75 % ausgelastet werden,wird das dann auch für Zukünftige Generationen das selbe Problem sein oder kann man sowas mit reiner Hardware Optimierung ausgleichen um die Software die nicht ganz optimial auslastet dazu zu bewegen dies auf einmal zu schaffen oder kann das egal wie gut auch die Optimierung sein mag auch nicht ausgleichen?
Und 75 % von einem 32 Kernen,entspricht ja dann einem 24 Kerner ohne SMT.Kann man das denn so sehen oder nicht?
Dann bringt in dem fall die doppelte Kernzahl leider auch nix mehr dann oder täusche ich mich da?

Skysnake

2024-01-15, 02:56:13

Scheiß Software bleibt scheiß Software und wir abseits von Takt, Latenz und IPC Gewinnen nicht schneller durch neue Hardware. Sprich irgendwo einstelligen Gewinne.

Du musst ja überlegen, man vor 8 Jahren noch 24 vor nodes hatte. Sprich wenn heute eine Anwendung auf einem 128 Core node skaliert müsste sie das vor 8 Jahren über 6 nodes tun.

Und es gab damals schon genug Software die gerade so über 6 nodes skaliert hat oder nicht mal. Aber eben auch Software die über hunderte oder tausende.

Wobei je langsamer ein Code desto einfacher skaliert er gut... das ist ja der Witz...

Skalieringsfähigkeit sagt erst mal nichts über die Codequalität aus.

Aber bezüglich der Hoffnung das Anwendungen ohne mindestens einen recompile relevant schneller werden abseits von schlicht mehr Cores oder Speicherbandbreite zu haben kann ich den Zahn ziehen. Das ist definitiv unter 10% zwischen den Gens bis nicht existent.

Das war schon zick Jahren so das man ohne Recompile nichts gerissen hat.

@Bsdesalz: irgendwo wird das sicherlich schon laufen, aber das sind ungelegte Eier, darüber rede ich nicht auch wenn ich das Ding definitiv als so ziemlich die spannendste HW seit Jahren sehe.

Am Ende wird es aber wohl darauf raus laufen wie gut die Software getuned wird dafür. Eventuell bekommt man damit aber so manche hinterm Ofen vor überhaupt mal GPUs zu nutzen.

Ich würde mich auf jeden Fall freuen wenn Sie damit erfolgreich sind und diesen Pfad pushen. Hat meiner Meinung nach einfach gewisse Architektonische Vorteile was es für HPC aber auch andere Bereiche interessanter macht als dedizierte GPUs. Egal wie schnell die sein mögen. Einfach mal Amdahls und Gustavsons law anschauen. Man hat einfach die Chance schon bei kleinen Problemen die GPU sinnvoll nutzen zu können und genau da wäre mal wieder ein echter Speedup sehr erstrebenswert.

Badesalz

2024-01-15, 06:45:44

@Skysnake
Das primär spannende daran ist für mich, ob die Inbetriebnahme nach Plan verläuft/verlief :wink: Wir beide hatten das Thema schonmal bei den blauen exascale Projekten...

Eventuell bekommt man damit aber so manche hinterm Ofen vor überhaupt mal GPUs zu nutzen.Nehme an mit der Anschaffung macht man auch entsprechende Ansagen. Wobei es auch viel Gerede über "HPC Cloud" gibt. Die externe Kundschaft kann man halt nicht beeinflussen.
Schön wäre es aber in der Tat, wenn jemand sein Musterprojekt drauf abfeuert und den ewig Hinterherlaufenden zeigt wie das bei ihm ballert ;)

Laufen kann das aber noch nicht. wcctech hat gleich oben paar genauere Angaben
https://wccftech.com/amd-epyc-genoa-cpu-instinct-mi300-apu-powered-atos-bullsequana-xh3000-to-power-mpcdf-supercomputer/

Allgemein scheint es, daß AMD nicht soviel und so schnell von 300A liefern kann wie sie es eigentlich müssten...

OT-Ende

Skysnake

2024-01-15, 07:30:16

HPC Cloud schreiben einige, ich habe bis jetzt aber nur ziemlich schwache Ergebnisse gesehen, wo man den Eindruck gewinnt die haben keinen Plan was echtes HPC, also cspability Computing, bedeutet. Das größte der Gefühle was man so sieht ist throughput Computing, wobei die Flexibilität auch nicht wirklich gegenen ist/war. Einfach mal 1000 cores nehmen ist da auch eher nicht der Fall. Von 10.000+ reden wir mal nicht.

Spot Instanzen nehme ich hier aus. Da sind 1000 Kerne durchaus machbar, aber die hat man halt nicht verlässlich für längere Zeit...

Und um die Kurve zum Thema zu bekommen...

Ich für meinen Teil finde es nicht so deutlich spannend was da noch kommt an neuen Nodes, denn die allein retten dir nicht dem Arsch. Ohne advanced packaging bist du einfach tot.

Neuere nodes helfen dir mal hier mal dort noch, aber das muss echt überlegt sei. Ob man den nächsten Node noch nimmt oder lieber sein lässt.

Badesalz

2024-01-15, 08:58:20

Ich für meinen Teil finde es nicht so deutlich spannend was da noch kommt an neuen Nodes, denn die allein retten dir nicht dem Arsch.Nicht mehr jedenfalls. Davor ging das noch mit dem Takt und den Caches einher, was sich schon feststellbar auswirkte (aus der HomePC Sicht).
Packaging, Photonic-Com, paar wenige neue Materialien.

Und ich wiederhole mich, daß wir im klassischen "Computing" erstmal keine echten Leistungsprobleme mit HW mehr haben. Daheim nicht, industriell nicht und in der Forschung auch nicht. Man muss es sich halt anschaffen, aber die Möglichkeiten haben sich bereits extrem gesteigert.

Im Gegensatz zu KI. Wo NV aber noch ganz entspannt B100 und X100 nachschiebt, wo AMD ab den 300ern endlich auch mitmischen kann und wo vor allem die Sachen von Cerebras keineswegs eine Eintagsfliege sind. Auch hier sehe ich keine PRobleme, wenn man es halt machen möchte (Preise, Verfügbarkeit)

Und man kann nun auf AMD wie NV auch mit GamingHW KI auf dem Desktop fahren. Jedenfalls reicht das - und es wird ja mehr mit der nächsten Generation - um das bei Compilern nutzen zu können. Wenn man da endlich die Ansätze durch hat verspreche ich mir ebenfalls bisschen was davon, den Bullshitcode der Pfuscher wenigstens feststellbar besser in den Griff zu bekommen.

PS:
HPC Cloud ist wohl eher nur Kommunikation ;) Der Versuch die Rolle als Rechendienstleister zu vermitteln, mit einem Buzzword. Kann man machen :wink:
Andererseits ist die Konkurrenz nicht grad klein
"„In letzter Zeit hat sich ein deutlicher Anstieg in der Nachfrage bemerkbar gemacht. Dies gilt insbesondere für Anfragen aus Deutschland, wo Energie knapp und die Kosten im Vergleich zu unserem Angebot fast drei Mal so hoch sind."
https://www.datacenter-insider.de/bmw-verlagert-hpc-computing-an-den-nordpol-a-527247/

DREI MAL. Und die News ist von 2016 :freak: Nach Industriestrom kommt nun Rechenzentrenstrom? :usweet:

Skysnake

2024-01-15, 09:52:17

Mag sein, aber wie gesagt mit echtem HPC sind alle Cloud Angebote total uninteressant. Es sei den du nutzt zu 50%+ deine Ressourcen nicht durchgehend. Also sobald du dauerhafte Last hast bist du mit eigenen Systemen günstiger ab paar hundert Knoten auf jeden Fall.

Badesalz

2024-01-16, 08:49:41

Shrinks mal in kontraproduktiv :tongue:
https://www.emcstandards.co.uk/moores-law-die-shrinks-and-cost-effective-emc

Allgemein OnT
https://www.ieee.org/ns/periodicals/EDS/EDS-JANUARY-2021-HTML-V5/index.html

https://www.aeaweb.org/articles?id=10.1257/aer.20180338

https://spectrum.ieee.org/a-better-way-to-measure-progress-in-semiconductors

https://www.reddit.com/r/hardware/comments/jol5ny/for_over_10_years_now_people_have_been_saying/?rdt=43001

https://www.youtube.com/watch?v=D--sSNKiVXg

https://www.youtube.com/watch?v=Uh4QGey2zTk

2016 :cool:
https://spectrum.ieee.org/transistors-will-stop-shrinking-in-2021-moores-law-roadmap-predicts
https://www.hpcwire.com/2016/07/28/transistors-wont-shrink-beyond-2021-says-final-itrs-report/

2019
https://www.youtube.com/watch?v=NlO9F-gl9e4

davidzo

2024-01-16, 10:58:40

Scheiß Software bleibt scheiß Software und wir abseits von Takt, Latenz und IPC Gewinnen nicht schneller durch neue Hardware. Sprich irgendwo einstelligen Gewinne.

Und das Wirthsche Gesetz nicht zu vergessen:
"Software is getting slower more rapidly than hardware becomes faster."

Shrinks mal in kontraproduktiv :tongue:
https://www.emcstandards.co.uk/moores-law-die-shrinks-and-cost-effective-emc

Naja, das ist ein bisschen reißerisch, der Typ will halt Geld verdienen mit EMC Beratung, also macht er groß Panik und tut so als wäre es das wichtigste der Welt. Die chips in kleineren Nodes haben nicht nur Nachteile sondern auch Vorteile, auch im Embedded-Bereich.

Zum Beispiel haben wir gerade ein Messgerät mit einer brandneuen STM MCU umgesetzt die nur noch ein Bruchteil dessen verbraucht wie die vorherigen. Dadurch konnten wir kleinere und billigere Pmics nehmen und die Batterien halten jetzt über ein jahr standby-Zeit statt vorher nur Wochen. Das spart schon etwas an Customer-Service.

Auch wenn sich das EMC verhalten natürlich ändert ist meist keine Steigerung der Emissionen, sondern eine Verringerung. Klar, wenn sich die switching Frequenz ändert, dann steigen auch die relevanten Frequenzbänder für EMC und dort gelten eventuell andere Grenzwerte. Je höher die Frequenz, desto höher allerdings auch die Dämpfung. Außerdem brauchen kleinere Strukturbreiten weniger Spannung und häufig auch weniger Current. Schnellere Schaltregler haben weniger energiereiche Spitzen und kommen auch mit kleineren Filtercaps aus. Die absolut emmissierten Leistungen sind also schonmal von Anfang an geringer, nur ist der Frequenzbereich ein anderer. Klar, die Tracelängen müssen auch schrumpfen, sonst steigen die parasitären induktivitäten. Aber da die IC-Packages in der Regel auch kleiner sind und das ganze auch PCBgröße und PnP Kosten spart ist das ein nobrainer das layout einfach neu zu machen. In place ersatz ohne neues layout ist natürlich selten optimal.

Was aber totaler Bullshit ist dass alle ICs angeblich alle 2 Jahre einen neuen Node bekommen. Ein Nodewechsel ist im embedded Bereich und bei Standard ICs eher alle 10-15 Jahre der Fall und dann ist es eher eine Abkündigung bzw kompletter Chip Redesign mit neuer SKU.

Ich kenne zudem keine namhaften Hersteller die einfach mal mitten drin den Node eines Chips ändern ohne den Kunden bescheid zu sagen und nicht zumindest die SKU-Nummer oder Revision zu aktualisieren. Meist steht der alte Chip dann eher auf Auslauf, kann aber noch ein paar Monate bestellt werden, während schon ein direkter replacement-Chip verlinkt ist.

Badesalz

2024-01-16, 11:17:14

Ja. Das Beispiel war recht dürftig :frown: Ging auch eher darum auch mal ein Problemfeld zu zeigen :redface:
Und ich schätze das ist schon real, nur man schaut sich das ja schon in der Konstruktion/Design an.

Die Shrinks der TopEnd-Projekte interessieren mich persönlich auch weniger. Ich reg mich eher gelegentlich auf, daß der Rest da nicht 1-2 Schritte nachkommt.
Die GS108GE Plattform der Switche z.B. Ich hab hier schon ordentlich einen abgelästert warum die vermeintlichen 2,5Gbit Pendants Strom wie Sau fressen. Und dabei auch sauteuer sind...

davidzo

2024-01-16, 11:48:05

Ja in meinem Bereich ist 28nm schon ein cutting Edge node, aber ich verstehe was du meinst.

In rein digitalen Anwendungen wo es um Bandbreite und Leistung geht kann ich das auch nicht verstehen wieso so lange gewartet wird auf neue Nodes zu wechseln. Sicher hängt das mit den Initialinvestitionen zusammen, aber die sind letzendlich sowieso irgendwann fällig.

Ein anderes Beispiel sind ja SSD Controller. Da rennt der Phison-CTO herum und erzählt jedem dass PCIe Gen5 M2. SSDs hauptsächlich ein Problem der Wärmeentwicklung sind, weil sie grundsätzlich etwa das doppelte verbrauchen wie das alte Phison E18 Gen4 Flaggschiff. Dass das aber ein hausgemachtes Problem ist was einfach damit zutun dass Phison weiterhin auf 12nm TSMC setzt, mit einem leicht aufgebohrten E18 design um als Erster im Markt zu sein, während fast alle anderen Controller-Hersteller auf 8nm oder 7nm setzen um den Zuwachs an Komplexität ausleichen zu können. Mittlerweile sind die ersten 7nm Controller da, sowie erste 4 Channel Designs mit PCIe Gen5 und die verbrauchen genau soviel wie die Gen4 Vorgänger. Es stellt sich also heraus dass die Wärmeentwicklung nichts mit PCIe Gen5 zutun hatte.

demklon

2024-01-17, 18:58:28

Ja, nun haben wir wirklich viel fundierte Fachkenntnis beisammen getragen, und sind aber immer noch nicht zur Threadtitelfrage durchgedrungen.

Ist das nur Spekulation, wieviel Jahre kann das noch weitergehen fragte i ch mich schon öfters.

:confused:

Grüße

Daniel

Tobalt

2024-01-17, 19:06:25

Ich schätze mal es wird auch in 50 Jahren noch weitere Erfolge bei der Miniaturisierung und bei der Kontrolle von Schaltungen im nm Bereich geben. (Mit genug Geld kannst du Materialien auch heute schon gezielt Atom für Atom aufbauen, mit STMs.)

ABER: Schon lange vorher, nämlich ungefähr ~heute, wird die Strukturbreite der Fertigung aufhören maßgeblich für die Performance zu sein.

Stellvertretend werden dann die Softwarealgos zum Fortschrittsmotor der Performance. Und dann folgend auch neue Hardwareeinheiten, die nicht unbedingt kleiner sind, aber "anders" rechnen. Ist nicht so schön messbar wie Transistoranzahl oder Gatelänge oder Takt, aber ist halt so.

Deshalb wurde hier auch eben über das diskutiert, was künftig den Ton angeben wird. Wenn du sowas hören willst wie "5 Jahre noch und dann ist Ende", muss ich dich enttäuschen;)

boxleitnerb

2024-01-17, 19:21:25

Skysnake

2024-01-17, 19:57:05

Ki wird da teilweise schon eingesetzt für digitale Designs. Für analoge Designs habe ich so meine Zweifel weil du quasi unendlich viele Parameter hast an denen du drehen kannst.

Aber wir werden sehen was da noch kommt. Go wurde ja auch gemeistert und das sollte wohl ähnlich sein.

demklon

2024-01-17, 21:35:03

:D

Also abwarten, und Tee trinken....
Mal wieder. Gehört dann wohl in die Spekulations Ecke.

Aber wir sind uns alle Sicher, die Wand kommt unerbittlich, und bei so wenig Spielraum, dass sogar mit Photonen gearbeitet wird, richtig krass.Wer wagt hier eine Annahme, weil der Raum immer kleiner wird, und wie Wand immer näher kommt. Es wurde schon gesagt, die Ströme die da nicht auf die Nebenbahn "Überspringen".

Kniffliger Job, so ein Entwickler am Chipdesign. Es wird garantiert immer weitergehen, weil da Geld reingepustet werden wird.

Wer ist das führend, Intel, oder Nvidia?

Grüße Dich Forum

klon

Skysnake

2024-01-17, 22:39:13

Schau dir OnChip Optics an. Da wird mit Rwaonatoren zum ein und auskoppeln der Signale gearbeitet und das Zeug ist riesig....

Ich bin jetzt 40 und gehe davon aus die ökonomische Wand bei den Chips noch während meines Arbeitslebens zu erleben sofern man nicht auf Superconduktive Computing geht. Wenn man darauf geht wird es aber wohl trotzdem noch zu meiner Lebzeit soweit sein.

Technologisch sind wir wohl schon da, denn wenn Geld keine Rolle spielt, bewegen wir schon seit vielen Jahren einzelne Atome so wie es uns gefällt....

davidzo

2024-01-17, 22:55:32

Was ist mit KI-unterstützter Optimierung von Code?
KI könnte auch beim Chipdesign zukünftig eine große Rolle spielen. Ein Mensch kann das doch gar nicht mehr überblicken, auch kaum noch ein großes Designteam.
Das OpenAI Konzept von Reinforcement Learning ist gut um Durchschnittsarbeiten zu beschleunigen und dabei Menschen zu ersetzen, aber ganz sicher nicht besser als der Mensch. Die Krux ist ja dass es mit menschlichen Daten gefüttert wurde und zwar nicht nur von hochintelligenten sondern auch durchschnittlichen Ingenieuren. Dementsprechend trifft es auch sehr menschliche Entscheidungen.

Wenn du eine KI haben willst die Übermenschliche Lösungen findet, dann musst du eher fachspezifische KI entwickeln die mit monte carlo algorithmen sich selbst trainiert und nicht nur imitation learning anwendet. Das ist aber im moment nicht en vogue. Alle hippen Proogrammierer beschäftigen sich nur noch mit imitation und reinforcement learning, da die Ergebnisse da für den Durchschnittsmenschen gut verstehbar sind.

Es ist wie immer mit Zukunftstechnologien: Es wird in das investiert womit sich Geld einsammeln lässt. Und Geld einsammeln lässt sich nur mit profanen Alltagsthemen die jeder MBA in 5 Minuten versteht. Da Investoren und Banker leider nicht zu den schlausten Menschen zählen bleibt Hochtechnologie in unserem freien Markt der Investments also meist auf der Strecke.

Ich bin jetzt 40 und gehe davon aus die ökonomische Wand bei den Chips noch während meines Arbeitslebens zu erleben sofern man nicht auf Superconduktive Computing geht. Wenn man darauf geht wird es aber wohl trotzdem noch zu meiner Lebzeit soweit sein.

Naja, wir haben noch eine ganze Dimension an der wir bisher nur an der Oberfläche kratzen. Entlang der planaren Achsen packen wir auf einen Chip zehntausende Transistoren nebeneinander.

In X-Y mag die Transistordichte also ausgereizt sein, aber in der Z-Achse haben wir es noch nichtmal versucht. Aktuelle Chipprozesse haben vielleicht 16,17 Layer, von denen viele einfach nur RDL sind. Die eigentlichen Logiklayer sind meist unter 8x. Die Transistoren sind trotzdem nur wenige Atome hoch. In so einem 0.7mm dicken DIE wäre also noch sehr sehr viel Platz, geschweige denn in einem Würfel wo die Leitungslängen optimal kurz wären. Ein X3DCache wie bei Ryzen mit 128MB ließe sich in unter einem Kubikmillimeter realisieren und hätte Latenzen eher wie ein L1 Cache.

Sicher ist das eine Kostenfrage und eine Frage wie flexibel man den Prozess machen kann um auch Power delivery, Kühlungsvias etc. zwischen den Metal Layern für so richtig dicke 3D Chips zu lösen. Aber das ist eben Technologie die noch nicht existiert. Das wird alles teuer, aber Luft nach "Oben" im wahrsten Sinne des Wortes ist noch für eine ganze Weile genug.

latiose88

2024-01-17, 23:36:31

Sehr gut ,bis dahin ist die Software dann dank der Hardware zu tode Optimiert worden.Also denke mal das wird vor dem Ende der Fertigung sein.ALso IPC Steigerung 5-6 Generation überspringen und schon kommt dabei sehr viel raus.ALso rund 10 Jahre warten.

Skysnake

2024-01-18, 05:11:55

@davidzo du unterschätzt das Kühlungsthema. Schon heute sind die Energiedichten höher als bei ner Herdplatte. Du kannst da nicht hunderte von layern an Logil übereinander packen so lange du nicht supraleitend bist.

Realistisch sind irgendwo zwischen 2 und 5 Layern bei high Perf Chips. Die low Perf sind es vielleicht 10-20 aber auch dann bist du da am Ende. Für ultra low Perf, wo di in weak inversion die Transistoren betreibst schaffst du dann die 100+ Player an Logik. Aber die ist dann nur noch im Bereich von MHz schnell. Für Logik gewinnst du da nicht wirklich viel. Lass es Faktor 2 oder 4 sein aber mehr nicht.

Also nur für ein zwei Moore Zykeln.

Tobalt

2024-01-18, 06:24:39

Herdplatte hat ne viel geringere Leistungsdichte als ein CPU/GPU. Ein besserer Vergleich ist die Oberfläche eines Kernreaktorbrennstabes ;)

Deshalb: Wenn man in 3d bauen will, dann geht das nicht mit einfach mehr Logik. Man kann mur das vorhandene klüger staffeln um ein paar gains in der Energieeffizienz zu erzielen. 3d cache ist ein Bsp dafür. Das Budget könnte man dann in Performance re-investieren.

Aber so eine Fertigung ist eben auch enorm aufwändig und ab dem 2. Layer wird der Benefit mkt jedem Layer geringer. Ich glaube ehrlich gesagt nicht, dass wir da viel sehen werden.

Ich denke dass die Arbeit an Computingkonzepten und Software in den nächsten 20-30 Jahren das bestimmende Thema sein wird für große Fortschritte in der Performance.

Badesalz

2024-01-18, 08:30:47

Dies als Würfel sehe ich irgendwie nicht als eine physikalische Wand die man lieber verwerfen sollte.

Man kann den "Chip" von der Mitte aus in mind. 5 Richtungen bauen (STAPELN) und nicht einfach nur nach oben. Das sind nur andere Herstellungsprozesse (und andere Sockel und andere Mechanik drumherum) und ich bin mir ziemlich sicher, daß ich jetzt nicht der erste bin dem das eingefallen ist...

Den Kühler mechanisch so zu machen, daß es nicht nur aufliegt, sondern den Würfel umschließt, ist eine Aufgabe, aber imho keine bei der sich keiner auch nur theoretisch vorstellen kann wie das realisiert werden könnte. Sind halt nur paar Schrauben mehr die man bei der Montage nachziehen muss :tongue:

Vom Die-Design zum Cubus-Desing :up: Wobei auch der Waffer-Chip funktioniert ja und nebenher, fährt er NV bei KI in Grund&Boden...

PS:
Schön, daß andere das jetzt wiederholen, mit der KI-Unterstützung beim Proggen, der Photonik usw. usw. :wink:

edit:
Wenn du eine KI haben willst die Übermenschliche Lösungen findet, dann musst du eher fachspezifische KI entwickeln die mit monte carlo algorithmen sich selbst trainiert und nicht nur imitation learning anwendet. Das ist aber im moment nicht en vogue.TOP!

Altehardware

2024-01-18, 23:17:05

So hoch werden die chips nie eher wird der heatspreader seitlich mit Kühlrippen bestückt.
Ob das dann bei gerade mal 5mm geht ist völlig offen
Die Lösung für gestapelte chips wird die sein die schon angedeutet wurde Mittels durchleitende wärmebrücken ab a14 node.
Mehr als 2 Schichten wird es ab a18 nicht geben und n2x hat erstmal gaa.
Bis dahin sind noch gut vierfache Leistung bei gpu's möglich.
bei cpu allerdings nur doppelte Leistung da dies klar nach Takt geht.

Am ende komt es auf die kosten an wann udn wie gpu und cpüu designt werden bei cpu bin ioch mir siocher da wir ab 2028 7,5ghz cpu sehen werden
bei gpu ist noch offen amd sicherlich 5,0ghz. nvidia unklar da ein design Wechsel sich andeutet
Das maxed sehe ich ab a18 node bei amd gpu's bei 5,1ghz und bei a14 5,0ghz
das wäre der Zeitraum
2024 n4x 3,55ghz
2026 n3p 4,0ghz
2028 n2x 5,1ghz
2030 a18 5,0ghz

nvidia so
2025 n4x 2,8ghz
2026 n4x 3,1ghz
2027 n2x 3,1ghz neue Architektur doppelte alu
2029 a18 2,9ghz doppelte alu
2031 a14 3,2ghz kurz Taktsteigerung

amd grenze der Architektur derzeit sind das 2 render engines da maxed dürfte 6 sein
3 gcd zu je 2 renderengines
nvidia kann nur 12gpc in 6 renderengines nutzen daher muss nvidia die alu per sm erhöhen
die menge an sm per gpc ist frei festlegbar
geplant derzeit sind 16sm per gpc bis zu 192 alu mit rubin (rtx60)

Die nächste gen wird blackwell gb2xx mit
12gpc haben mit je 16sm per gpc und 64 +16+8fp32 per sm haben wie ada und ampere auch schon also 16*88*12=16896 alu die fp32 rechnen insgesamt sind es 24576 alu die fp16 können
das wird in folgende chips umgesetzt.

gb207 2gpc 32sm (50er sku) 25$ chip 128bit 8gb und später 12gb
gb206 4gpc 64sm (60er sku 60ti sku 70 sku) 50$ chip 192bit 12gb und später 18gb
gb205 6gpc 96sm (70ti sku 80 sku) 90$ chip 256bit 16gb und später 24gb
gb203 8gpc 144sm (90er sku) 150$ chip 320bit 20gb und später 30gb
gb202 12gpc 192sm (Titan sku) 300$ chip 384bit 36gb

Wieviel sm per sku ist noch offen der Takt kann nicht über 3,1ghz gehen wird an sich aber aufschieben bis amd konkurrieren wird mit rdna5 ab 2026
bis dahin sind die 2,8ghz gesetzt mit deutlich reduzierter tbp je sku.
Anfangen wird das ab q1 2025
Offen ist nur ob nvidia noch ne rtx4060ti super bringt um die rtx4070 zu ersetzen
amd wird sehr bald die rdna4 rx8600 und rx8600xt vorstellen mit je 28cu und 32cu ab 3,55ghz
das wird die rx7700xt und die rx7600xt ersetzen das si schätze ich auf 128bit
Das große update kommt mit rx8700xt mit dem n48 ab q4 2024 das die rx7800xt, rx7900xt und rx7900xtx ersetzen wird.

Da die ps5 pro überraschenderweise langsamer läuft als gedacht 2,0ghz sind nur 16,7tf drin
Und die soll sept 2024 vorgestellt werden ich vermute zeitgleich zum release des n48 am desktop.

Das gute die neue gpu muss nicht mehr min 20tf erreichen um mitzuhalten für 1080p das schlechte die Auswahl dieser wird schwierig.

Gpu bis 2027 zur ps 6 also

rtx4060ti 16gb mit abstrichen bei der Bandbreite grob 14tf von 16,5tf 430€ jetzt q1 2024
rtx4060ti super ideal etwa 20tf 460€ q3 2024 (unklar ob das kommt)
rtx5060 ideal etwa 22tf 400€ q1 2025 (ab q1 2026 gibt nen super mit 24tf und 18gb statt 12gb)
rx8600xt ideal etwa 17tf 300€ q2 2024
rx8700 ideal etwa 28tf 500€ q4 2024
rx8700xt ideal 34tf 650€ q4 2024
rtx5060ti 26tf 500€ q1 2025

cpu bis dahin zen5 +20% ipc
arrow lake unklar es sollen +30% ipc sein

Das ist nur der Anfang mit rtx60 erwarte ich min in low end falls diese noch kommt da ai ne rolle spielt.
Wenn sind das gr207 mit 2gpc ab 400€ als rtx6060 32sm je 152gp32 bei 3,1ghz = 30tf an 192bit si (18gb) =864gb/s drin
Der chip dürfte um die 80mm² sein in n2x node
Sku ab 400€

Es hängt davon ab wie amd ihre apu puschen wird. Sicher ist eine sku mit 40cu ab der 9000g Serie ab 2025.(Strix halo)
60cu ab der radeon x Serie unklar. Kann aber sein, der Takt bemisst sich auf 4,0ghz grob ab 23tf bis 34tf sind drin ab 2027
Das bestimmt aber die am6 Plattform sicher weis ich nur das amd die cpu stärker die ram anbinden wird ob quadchannel ddr6 128bit per channel hat oder man ganz von ddr weggeht (hbm auf cpu)
ist mir nicht bekannt den sie müssen was an der Bandbreite an der cpu ändern.
Das passiert erst ab radeon x Serie ab 2027 mit Sockel am6, npu spielen auch ne große rolle dabei.

Die nächsten Jahre wird gpu Leistung je sku min verdoppeln bis verdreifachen high end ist sicher das es sich verdoppeln wird.
Die cpu Leistung steigt bis letzten am5 cpu auf +50%
Mit am6 auf +100%
und das ist nur bis 2027
2030 kann am nochmal Verdoppelung ausgehen durch mehr alu
Software nun alles wird pathtracing ohne upscaler werden das steht sicher
ps6 wird etwa 30tf erfordern für 1080p 2160p braucht das vierfache also 120tf
darum wird upscaling Thema bleiben.

bsp rtx7060ti an 8gpc ab 3,0ghz mit 152fp32 =120tf ab 2030 als rtx7060ti ab 500€ 2030
Den verbrauch tippe ich auf etwa 210w
Mit a14 node als refresh dann 185w als rtx8060ti
Kann sein das nvidia dann wieder ne rtx7060 bringt mit nur 90sm statt 108 dann sollte die 180w nicht gesprengt werden.
90*152*2*3,1 =84tf mit 192bit und 24gb vram die dann sehr knapp werden maxed 960gb/s
Die ps6 pro sollte dann da sein mit ihren 60-70tf und min 2tb/s Bandbreite

Das ist noch weit weg und kann sich ändern aktuell gehe ich nur von den ersten annahmen aus bis 2025.
Der Rest ist spekulativ möglich.

also mein ziel immer etwa die gleiche tbp des PC zu halten könnte klappen bis 2030
womit drei sku infrage kommen
2024 rtx4060ti super 180w 20tf 12gb
2026 rtx5060 super 163w 24tf 18gb
2028 rtx6060ti 182w 42tf 18gb (neue cpu board ram erforderlich)
Mal sehen was passiert

Badesalz

2024-01-19, 06:25:52

Habs doch gewusst ich bin nicht der erste ;)

https://semiconductor.samsung.com/emea/news-events/tech-blog/how-samsungs-3d-ic-cube-is-reshaping-the-foundry-world/

amdfanuwe

2024-01-19, 07:30:25

Habs doch gewusst ich bin nicht der erste ;)

https://semiconductor.samsung.com/emea/news-events/tech-blog/how-samsungs-3d-ic-cube-is-reshaping-the-foundry-world/
Der Artikel ist von letztem Jahr und beschreibt Samsungs Favores Variante.
Also nichts neues.
Nach Intel und TSMC kann jetzt auch Samsung stapeln.

Man arbeitet aber an neuen realen 3D Chips die nicht nur aus gestapelten Dies bestehen:
https://www.scinexx.de/news/technik/erster-computerchip-mit-drei-lagen/

Badesalz

2024-01-19, 07:53:36

Das kommt auch davon, wenn man 8 Tabs auf hat :mad: Danke.

Ja das ist real, die Namen sind aber PR-Namen. "2,5D", "3D". Alles gut. Ich meinte aber schon wirklich nahezu einen Cubus :tongue:

Funfact am Rande (also imho): Die reden alle immernoch von Mikroelektronik, obwohl das schon ewig und 3 Tage Nanoelektronik ist :wink:

Badesalz

2024-01-22, 12:52:33

2nm (alt)
https://www.heise.de/news/Modernste-Transistoren-IBM-erprobt-2-Nanometer-Chips-6040072.html
https://www.computerbase.de/2022-12/mehr-unabhaengigkeit-ibm-und-rapidus-bauen-2-nm-chips-fuer-japan/
https://www.computerbase.de/2022-12/mehr-unabhaengigkeit-ibm-und-rapidus-bauen-2-nm-chips-fuer-japan/

Wie ich meinte, wir werden uns bis 1nm noch halbwegs "durchschleppen" :tongue:
Packaging, Photonic-Com und die Zurückbesinnung auf effizientere Codes sind die eigentlichen Herausforderungen.

Bis das wirklich wieder ausgereizt ist sind wir bei klassischen Systemdesigns vielleicht auch mit Photonic-Log paar Schritte weiter :smile:

Ich persönlich sehe bis dahin noch reale zigfache Steigerungen der Leistung bei gleichen TDPs. Bei CPUs. Und, pro Thread. Core-Flood ist ja der generelle Heilsbringer nur in den Rechenzentren.

Und nur KI, läuft auch nicht einfach nur gegen die Shrink-Wall. Außer dem obigen gibt es da auch interessantere Architeturen. Auch neben Cerebras WSE-2
https://www.golem.de/news/ki-inferencing-mit-northpole-will-ibm-den-ki-beschleuniger-neu-erfinden-2310-178761.html

Und es wurden auch heute noch nicht alle non-von-Neumann Architekturen als Sackgassen verworfen :up: Selbst wenn sie nur spezeillere Dinge erledigen würden. Diese, sind meist auch jene wo die klassischen System am wenigsten effizient sind.

OgrEGT

2024-01-22, 16:33:42

https://fudzilla.com/news/pc-hardware/58300-georgia-tech-boffins-claim-to-make-the-first-graphene-chip
In sog. Epigraphen können Elektronen offenbar sehr viel schneller bewegt werden als in herkömmlichen Silizum... Damit sollen Frequenzen im Terahertz Bereich möglich sein...

mboeller

2024-01-22, 17:37:12

@davidzo du unterschätzt das Kühlungsthema. Schon heute sind die Energiedichten höher als bei ner Herdplatte. Du kannst da nicht hunderte von layern an Logil übereinander packen so lange du nicht supraleitend bist.

die Kühlung könnte man mit "Reverse-Logic" in den Griff bekommen.

https://en.wikipedia.org/wiki/Reversible_computing

mehr Infos hier:
https://www.forum-3dcenter.org/vbulletin/showpost.php?p=13460058&postcount=3570

Ob das wirklich funktioniert, kann ich als Laie aber nicht einschätzen.

Tobalt

2024-01-22, 17:56:30

Das hat doch nichts mit Kühlung zu tun.. :conf:

mboeller

2024-01-22, 19:58:02

Das hat doch nichts mit Kühlung zu tun.. :conf:

naja, wenn die CPU nicht mehr 100w verbrät sondern nur mehr 0,1w, dann tut man sich mit der Kühlung doch ein wenig leichter und kann dafür "Sachen" ein wenig dichter packen, ua. in 3D.

Tobalt

2024-01-22, 20:11:43

Ja dies erlaubt, nebst anderen computing konzepten, sehr viel effizientere Lösungen von bestimmten Problemklassen, aber mit Kühlung hat es trotzdem nichts zu tun ;)

Und wie hier schon vielfach beschrieben: Vorher Software!

Unsere aktuelle Software schafft es ja (abgesehen von sehr gut zugeschnittenen Problemen wie HPC oder Grafik) aktuell noch nicht mal volldeterministische klassische Computer sinnvoll zu nutzen.

Wenn du Programmierern jetzt noch nichtdeterministische Einheiten mit zupackst, wird die Software noch schlechter :usad:

Badesalz

2024-01-23, 06:26:13

Vielleicht kriegen wir das mit der besser kodierten Soft durch die Hintertür geboten? :usweet:
https://sites.google.com/view/energy-efficiency-languages

Skysnake

2024-01-23, 06:41:40

Tja leider nicht zugreifbar. Hätte mich schon interessiert, wobei man aufpassen muss. High level Sprachen bieten einfach viel mehr Raum für schlechten Code.

Bei Sachen wie Rust und Go wäre ich aber interessiert wie sich diese Schlagen im Vergleich zu C.

Zossel

2024-01-23, 06:47:31

][immy

2024-01-23, 07:07:16

Sprachen mit Müllsammler können nur schlechter als Sprachen ohne Müllsammler sein.

Nicht zwangsläufig. Ja, sie haben ggfs. einen Performance Nachteil, aber dafür kann man Speicherlecks etc leichter identifizieren/verhindern. Bei Interpretersprachen allgemein würde ich dir zustimmen.
Das Problem ist ja eher, das Sprachen wie C bei sehr großen Projekten schneller zu Fehlern neigen können und damit zu Performance Einbußen, weil irgendwann die Komplexität einfach zu hoch ist. Und dann verwendet man in der Regel auch Frameworks die gewisse Dinge nach Möglichkeit für einen erledigen was natürlich auch Ressourcen kostet.

Aber hat mit dem Thema hier eigentlich nichts zu tun.

Man merkt schließlich schon an den letzten Jahrzehnt das die Entwicklung ziemlich schleppend voran geht. Die großen Sprünge von einst (quasi jährlich eine neue deutlich bessere Fertigung) sind vorbei. Nun kommt es vor allem auf effiziens beim Design an. Da ist zwar bestimmt auch noch einiges zu holen aber das ist dann noch eine Stufe schwieriger. Die letzten paar Generationen lrlebten vor allem vom vergrößern der Caches was die effiziens deutlich gesteigert hat, aber gleichzeitig führt dies dazu das Rechenwerke nun Dauerlast haben wir sie vorher noch Pausen zum Abkühlen hatten. Der Ryzen 5800x3d ist da ein gutes Beispiel für.

Man muss natürlich auch sagen, das die single Thread performance grundsätzlich schon ein ziemlich hohes Niveau erreicht hat, wo dann die Frage ist, ob sich das noch Verhältnismäßig gut steigern lässt oder ob es nicht doch eher wieder eine Zeit der Spezialisierungen geben wird wo mehr in fixed purpose units gesteckt wird um bestimmte Dinge schneller zu erledigen (sowas wie aktuell mit den NPUs). Ist zwar erst mal nicht so zuträglich wie die allgemeine Performance zu verbessern, aber die Anforderungen ändern sich gerade ja auch.
Will gar nicht wissen wie viele Sicherheitslücken noch aufgrund von ki auftreten werden.

Zossel

2024-01-23, 07:21:09

[immy;13476615']Nicht zwangsläufig. Ja, sie haben ggfs. einen Performance Nachteil, aber dafür kann man Speicherlecks etc leichter identifizieren/verhindern. Bei Interpretersprachen allgemein würde ich dir zustimmen.
Das Problem ist ja eher, das Sprachen wie C bei sehr großen Projekten schneller zu Fehlern neigen können und damit zu Performance Einbußen, weil irgendwann die Komplexität einfach zu hoch ist. Und dann verwendet man in der Regel auch Frameworks die gewisse Dinge nach Möglichkeit für einen erledigen was natürlich auch Ressourcen kostet.

Wenn man keine korrekte Implementierung voraussetzt ist so ein Vergleich wertlos, weil Äpfel und Birnen.
Und mit "Battery included" Sprachen fängt man sich auch jede Menge Bugs und Löcher ein, auch weil die im Regelfall mehr Corner-Cases implementieren als für Aufgabe nötig ist.
Mehr Code -> mehr Bugs.

Tobalt

2024-01-23, 07:31:28

Zossel

2024-01-23, 08:00:57

Wer die letzten 25% Performance will, kann dann immer noch C oder assemblen. Hier in der Diskussion geht's aber nicht um die letzten 25%, sondern darum, dass die Durchschnittsapps wohl noch nichtmal 10% ihrer optimierten Performance erreichen, weil der Programmierer versagt hat.

Optimierter Code ist energieeffizienter Code.

Und Frameworks und Codegeneratoren sind alles andere als fehlerfrei, insbesondere wenn eine Anwendung aus mehreren von diesen Dingern (am besten noch von verschiedenen Herstellern) zusammengeschustert wurde ist ein Lifecycle der Anwendung im Regelfall nicht mehr zu gewährleisten.

Und das Externalisieren von Problemen die man selbst nicht gebacken bekommt in die berühmte Kiste die mit "Hier geschieht ein Wunder" beschriftet ist funktioniert äußerst selten :-)
Irgendwas mit KI scheint im Moment die Kiste zu sein die am lautestesten trötet.

Badesalz

2024-01-23, 08:43:34

Tja leider nicht zugreifbar.
Hä?
https://sites.google.com/view/energy-efficiency-languages/results

Was ist da bei euch los? ;)

Skysnake

2024-01-23, 09:23:25

Sorry Leute. Aber die Diskussion über Programmiersprachen finde ich völlig deplatziert. Man kann mit low level sicher super Effizienz erreichen mit viel Zeit, aber das Hauptproblem ist doch der megaschlechte Durchschnittsprogrammierer, der von der Hardware kein Plan hat.

Das ist aber ein Problem der Bildung das selbst verursacht wird. So Sprüche wie
- der Compiler kann das eh viel besser als jeder Mensch
- HW nah programmieren ist nicht realistisch und wartbar
- für Programmieren muss man nicht studieren sondern learning bei Doing ist ausreichend
- ist doch egal wie HW funktionieren. Ich benutze serverless LOL!!!111elf

Helfen da halt überhaupt nicht...

Ich bin froh über mein Physik und technische Informatik Studium jeden Tag froh.

Um die Durchschnittsapps besser zu machen muss man den Faktor Mensch so weit wie irgend möglich eliminieren, also das komplette Gegenteil von low level. Eher eine Art chatgpt on steroids. man diskutiert mit det Maschine. Sie stellt Rückfragen zur korrekten Programmier-Absicht.

Ne sehe ich nicht so. Die KI wird anhand des Durchschnitts trainiert.

Zum garbage in garbage out....

Wer von euch hat denn schon mal Cache line wäre und mit padding gearbeitet für große multidimensionale arrays? Bzw wer weiß der überhaupt was das ist und warum man das macht?

Wer die letzten 25% Performance will, kann dann immer noch C oder assemblen. Hier in der Diskussion geht's aber nicht um die letzten 25%, sondern darum, dass die Durchschnittsapps wohl noch nichtmal 10% ihrer optimierten Performance erreichen, weil der Programmierer versagt hat.
Ne, da geht es oft genug um Faktoren.... ich hatte schon C++ reviewed der um Faktor 2 oder 3schneller wurde weil OOP aus Performance Sicht dumm gemacht wurde...

Und bei Sprachen mit noch höherem Level sind es auch mal Geößenordnungen....

Beliebt auch Biologenworkflows wo man dann Faktor 1000 oder so findet....

Genau das ist halt das Problem. Du kannst high level Sprachen nutzen wo es nicht schmerzt um deinen Output zu steigern, aber du musst das Fundament in low Level haben um zu erkennen eines dir Schmerzen bereitet und dann eben das auch in nem niedrigeren Level implementieren können.

Wir reden hier ja meist von 1-20% vom Code wo es wirklich drauf ankommt. Die muss man aber natürlich sehen...

Exxtreme

2024-01-23, 09:47:24

Sprachen mit Müllsammler können nur schlechter als Sprachen ohne Müllsammler sein.

Nicht unbedingt. Google und Micros~1 sagen, dass ca. 70% aller Sicherheitslücken durch Speicherfehler verursacht werden. Mit Müllsammlern und Laufzeitchecks eliminierst du diese Fehlerklasse. Und selbst die Sicherheitsbehörden sind aufgewacht und die NSA empfiehlt ganz offen speicherunsichere Sprachen ala C und C++ zu meiden:
https://media.defense.gov/2022/Nov/10/2003112742/-1/-1/0/CSI_SOFTWARE_MEMORY_SAFETY.PDF

Was in der C++-Community für Panik gesorgt hat.

Badesalz

2024-01-23, 09:52:42

latiose88

2024-01-23, 09:55:08

Nun man merkt wie schlecht die software ist.
Darum schrumpft bei mir der Abstand zu den Vielmehr Kerner immer mehr.
Das liegt daran das ich auch eine schlechte Software verwende.

Es gibt Spiele wo echt sehr schwer sind. Mein Bruder sagte dazu das ist eine einfache ki und die sind nun mal deutlich schwerer als ne komplexere ki als Gegner.
Alleine also bei Spielen gibt es schon erhebliche Unterschiede.
Und um ne richtige Steigerung zu haben ist es eben unerlassig das ohne ne gute Software wir nicht weiter kommen werden. Wenn sich nix dran ändert heißt es Hardware ist einer Sackgasse aber nur wegen der Software.
Die Hardware alleine kann also steigern wie sie will, das Problem bekommen wir allerdings nicht in den Griff.
Es gibt auch so viele schlechte Programmierer das man sagen kann das man erst mal diese schlechte verbessern müssen also optimiert, ehe man die Software optimieren kann. Dann wird sich auch an dem Problem sich was ändern.

Das Ende haben wir also bald aufgrund der schlechten Software erreicht, wenn man es rein von der Hardware betrachtet dann stehen wir noch lange nicht vor dem Ende. Da geht noch so vieles. Wenn man es richtig aufbaut dann bekommt man auch die Temperatur Probleme in den Griff. Das mit dem Stromverbauch damit dann ebenso.
Einfach nur weiter zu steigern wird das Problem mit den Temperatur und Stromverbauch erhöhen.

Also einfach mal die doppelte und dreifache Menge zusammen auf einer platine zu setzen, macht es also nicht besser.
Je mehr Transistoren da drauf sind desto schlechter zum kühlen und den Stromverbauch unten zu halten geht es dann.

Also klar könnte man die aktuelle CPU einfach die doppelte Menge setzen, warum weil die eigentliche dichte die hersteller noch nicht mal ansatzweise voll nutzen.
Man stelle sich die dichte die laut tsmc und Co angegeben haben als cpu sich mal vor.
Aktuell ja 104 Mrd Transistoren pro mm². Das könnte man nicht mehr kühlen.
Geil wäre das aber durchaus.
Damit könnte man so manche Programme damit erschlagen. Einfach noch mehr auf das Problem drauf hauen, bis das Programm die Leistung annimmt.
Wäre ein geiler Gedanken. Die Wahrheit sieht da halt leider anderst aus.

Somit kann man sagen wir sind noch lange nicht am Ende. Ende erst wenn man diese dichte auch erreichen würde.

Zossel

2024-01-23, 09:57:24

Nicht unbedingt. Google und Micros~1 sagen, dass ca. 70% aller Sicherheitslücken durch Speicherfehler verursacht werden. Mit Müllsammlern und Laufzeitchecks eliminierst du diese Fehlerklasse. Und selbst die Sicherheitsbehörden sind aufgewacht und die NSA empfiehlt ganz offen speicherunsichere Sprachen ala C und C++ zu meiden:
https://media.defense.gov/2022/Nov/10/2003112742/-1/-1/0/CSI_SOFTWARE_MEMORY_SAFETY.PDF

Was in der C++-Community für Panik gesorgt hat.

Der Bezug ist Energieeffizienz von Sprachen, und das in diesem Kontext nur korrekte äund vollständige Implementierungen vergleichbar sind sollte eigentlich klar sein und ich hatte darauf auch schon hingewiesen.

Und das "Battery included" Sprachen auch ihre Probleme haben hatte ich auch schon gesagt, vielleicht will das nur im Moment einfach niemand hören.
Siehe Java, was es ja auch über ein Vierteljahrhundert gibt, log4j war ja works as designed.

Exxtreme

2024-01-23, 10:03:14

Der Bezug ist Energieeffizienz von Sprachen, und das in diesem Kontext nur korrekte äund vollständige Implementierungen vergleichbar sind sollte eigentlich klar sein und ich hatte darauf auch schon hingewiesen.

Zum Glück hat Google so eine Messung durchgeführt:
https://sites.google.com/view/energy-efficiency-languages/results

Java, als "battery included"-Sprache schlägt einige Nicht-GC-Sprachen.

Zossel

2024-01-23, 10:10:59

Zum Glück hat Google so eine Messung durchgeführt:
https://sites.google.com/view/energy-efficiency-languages/results

Java, als "battery included"-Sprache schlägt einige Nicht-GC-Sprachen.

Ein JIT-Compiler kann Vorteile bei der Optimierung haben, weil der auf Sachen optimieren kann die sich erst zur Laufzeit offenbaren.

Skysnake

2024-01-23, 10:13:03

@Badesalz immer dran denken das man aus dem DFN einfach so drauf zugreifen kann ;)

Aber danke.für den Link. Rust sieht ja ganz gut aus. Fortran tendenziell meiner Meinung nach etwas zu schlecht insbesondere bei nBody. Kann gut sein das da entweder ein schlechter Compiler verwendet wurde oder aber sonst ein Problem vorlag.

Aber das ist halt immer so ein Problem. Man kann sooooo viel falsch machen... aus meiner Wicht müsste man eigentlich bei solchen Messungen mit angeben was rein theoretisch das untere Limit ist. So kann man das halt nur bedingt abschätzen.

Weißt du ob z.b. CPU und Memory Pinning gemacht wurde? Wenn nein sind die Werte absolut wertlos in meinen Augen.

Exxtreme

2024-01-23, 10:15:43

Ein JIT-Compiler kann Vorteile bei der Optimierung haben, weil der auf Sachen optimieren kann die sich erst zur Laufzeit offenbaren.

Das ist korrekt. Es ist aber trotzdem so, dass ein Müllsammler keinen so großen Effekt auf den Stromverbrauch hat. Die Art der Typisierung hat ganze Größenordnungen mehr an Auswirkung was das angeht.

Weißt du ob z.b. CPU und Memory Pinning gemacht wurde? Wenn nein sind die Werte absolut wertlos in meinen Augen.

Keine Ahnung. Aber hier ist der Sourcecode:
https://github.com/greensoftwarelab/Energy-Languages

Ich kann mir gut vorstellen, dass sie idiomatischen Code nutzten und keinen superoptimierten.

Zossel

2024-01-23, 10:42:07

Badesalz

2024-01-23, 10:55:48

Leute... Die Ergebnisse dürfen sich wohl soweit voneinander unterscheiden, daß man sich doch traute damit eine generelle Tendenz aufzuzeigen. Nicht eine absolute...
Da ist auch das mit dem "idio-matischen" ;) Code, keine gleich ganz schlechte Idee.

Das Ergebnis kann auch je nach HW anders ausfallen, aber irgendwie diese Sicherheit einiger, es wäre relevant, weil es grundlegend anders ausfallen könnte, hab ich nicht. Kommt die aus dem RL? Weil sonst wäre sie ja "absolut wertlos" ;)

mksn7

2024-01-23, 11:41:48

Gut zu messen ist ähnlich schwierig wie gut zu programmieren.

Skysnake spricht schon so Kram wie pinning an. Zusätzlich gibt es noch jede Menge andere Konfigurationsparameter, die die performance beeinflussen. Compileroptionen? Gerade Sprachen mit denen ein Programmierer nicht so vertraut sind, haben vielleicht unbekannte Möglichkeiten/Gefahren.

In jedem Fall muss ich die erreichte performance gründlich analysieren, und herausfinden warum es langsamer performed als mein performance model (wie Skysnake schon sagt, ein "lightspeed" estimate).

Ich seh eigentlich keinen Grund, warum ein gutes Fortranprogram langsamer sein sollte als ein C Program. Und wenn man spitzfindig sein will, kann man auch behaupten dass C++ gar nicht langsamer sein kann als C. Der Programmiere hätte ja auch das schnellere C Programm als C++ schreiben können.

Das "idiomatisch" find ich immer etwas schwierig an der Stelle.

Zossel

2024-01-23, 11:54:15

davidzo

2024-01-23, 12:36:51

@davidzo du unterschätzt das Kühlungsthema. Schon heute sind die Energiedichten höher als bei ner Herdplatte. Du kannst da nicht hunderte von layern an Logil übereinander packen so lange du nicht supraleitend bist.
TSMC experimentiert schon mit quasi "supraleitenden" Diamantschichten zwischen den gestackten, abgeschliffenen DIEs. Die verteiolen die Wärme dann erstmal horizontal.

Aber ohne effizientere Architekturen geht es wahrscheinlich nicht. Ich habe ehrlich gesagt nachdem der pentium4 gegen eine thermische Wand gefahren ist auch nicht mehr damit gerechnet dass sich das nochmal wiederholt. Für mich war klar dass die Chips immer effizienter werden, Conroe->Westmere->Nehalem->Sandy->Ivy ... der Trend war eigentlich vernünftig, wenn auch langsamer als ich angenommen hatte.
Im Moment scheinen Apple aber die einzigen zu sein die diese Kurve verlängern. - Wahrscheinlich auch ein grund wieso man von x86 weg ist, die haben die Zukunft von Chipdesign auch anders Interpretiert und waren einfach nur enttäuscht wie es dann wirklich lief.

Ich denke über kurz oder Lang wird es wieder um effizienteres computing gehen. Wenn man Power spart sind mehr Layer möglich, das wiederum erlaubt mehr Transistoren, mehr Cache pro Waferfläche. Die Latenzen sind außerdem geringer weil die Leitungslänge vertikal viel kürzer ist als Horizontal.

Realistisch sind irgendwo zwischen 2 und 5 Layern bei high Perf Chips. Die low Perf sind es vielleicht 10-20 aber auch dann bist du da am Ende. Für ultra low Perf, wo di in weak inversion die Transistoren betreibst schaffst du dann die 100+ Player an Logik. Aber die ist dann nur noch im Bereich von MHz schnell. Für Logik gewinnst du da nicht wirklich viel. Lass es Faktor 2 oder 4 sein aber mehr nicht.

Genau, 22FDX hat schon 6x identische Fet-Layer und der ist bald 10 Jahre alt. Ich denke abseits des cutting edge werden dass die neuen Massen-Verfahren.
ggf. noch mit adiabatischen circuits, was nochmal massiv power spart und dann exzellente Latenzen, niedriger takt.

Dass das mit Hochtaktdesigns kaum skaliert ist klar. Das geht nur mit gravierenden Paradigmenwechseln.

Ich persönlich sehe bis dahin noch reale zigfache Steigerungen der Leistung bei gleichen TDPs. Bei CPUs. Und, pro Thread. Core-Flood ist ja der generelle Heilsbringer nur in den Rechenzentren.

Ja, ich denke auch. Wir sind gerade am Anfang von etlichen sehr spannenden neuen Technologien. Klar, die bisherigen Optimierungsvektoren sind langsam am Ende, aber es kommen eben auch neue dazu.

Sprachen mit Müllsammler können nur schlechter als Sprachen ohne Müllsammler sein.

Linus ist dem eigentlich ganz positiv gegenüber eingestellt, daher wird da schon was dran sein.

Der Bezug ist Energieeffizienz von Sprachen, und das in diesem Kontext nur korrekte äund vollständige Implementierungen vergleichbar sind sollte eigentlich klar sein und ich hatte darauf auch schon hingewiesen.
Da bin ich anderer Meinung. Es zählt der durchschnittliche Code den durchschnittliche Entwickler damit zu produzieren imstande sind, nicht irgendwelche hehren Ziele. Die Leute werden halt leider nicht intelligenter in dem maße wie unsere Welt komplexer wird. Insofern ist mehr Integration mit dem Ziel die Komplexität auf Entwicklerseite verringern zu wollen schon ein guter Ansatz. Den heiligen Grahl im Elfenbeinturm aufzubewahren bringt uns nicht voran.
Ich würde eher vorschlagen den Vergleich mit LLM generiertem Code zu machen der basierend auf Learnings von tausenden echten Enwicklern erstellt wurde und damit maximal durchschnittlich sein sollte.:freak:

Tobalt

2024-01-23, 12:46:28

Der letzte Punkt ist das worauf ich auch hinaus wollte. Skysnake nannte es Biologencode :ulol:

Sowas versteckt sich halt in jedem mittelgroßen Projekt und erzeugt etliche Bottlenecks und Bugs. Und dies kann man mit KI zumindest auf ein Level eines brauchbaren Durchschnittsprogrammierers bringen.

Es geht nicht im die letzten Prozent, sondern um die Größenordnungen davor.

Beispiel. Irgendein game kommt wieder raus, unter Zeitdruck fertig. Kratzt an der 50 fps marke mit Top end CPUs.. Bei sowas liegen immer brachiale Schnitzer vor. Die könnte rin Mensch mit mehr Zeit vermeiden oder aber mit einem entsprechenden Tool (KI oder anderes high level Zeug) gar nicht erst machen. Dann ist es auch egal, wenn die Performance am ende 50% unter "perfekt programmiert" rauskommt. Immer noch besser als nur <10% von perfekt optimiert, was wohl eher der Realität entsprechen könnte.

Exxtreme

2024-01-23, 12:58:21

Beispiel. Irgendein game kommt wieder raus, unter Zeitdruck fertig. Kratzt an der 50 fps marke mit Top end CPUs.. Bei sowas liegen immer brachiale Schnitzer vor. Die könnte rin Mensch mit mehr Zeit vermeiden oder aber mit einem entsprechenden Tool (KI oder anderes high level Zeug) gar nicht erst machen. Dann ist es auch egal, wenn die Performance am ende 50% unter "perfekt programmiert" rauskommt. Immer noch besser als nur <10% von perfekt optimiert, was wohl eher der Realität entsprechen könnte.

Sobald du solche Tools einführst, werden die Softwareentwickler noch weniger Zeit zur Verfügung haben. Denn weil sie ja diese Tools haben, wird das Management denken, man könne jetzt Personalkosten einsparen etc.

Badesalz

2024-01-23, 13:02:33

Ich muss zuigeben mir ist grad nicht klar, warum man eine KI nur so anfuttern sollte, daß sie einen durchschnittlichen Code bringt.

Gibt es, übrigens, zwischen Durschnitt und Top keine sonstigen Stufen? Durchschnitt ist für mich nach Schulnoten 4+ bis 3. Was ist mit dem 3+ bis 2 Code?
(es geht halt nicht gleich um 1 oder 1+)

Aber ok. Bei dem Müll was da verzapft wird ist wahrscheinlich ne 3 schon ein ordentlicher Gewinn ;)

@Tobalt
Nochmal ;)
Das DrawCall-Massaker bei AssasinsCreed. Der Hack. Die Nachbesserungen der Hacker. Das neue Ergebnis :wink:

Skysnake

2024-01-23, 13:21:41

Das ist korrekt. Es ist aber trotzdem so, dass ein Müllsammler keinen so großen Effekt auf den Stromverbrauch hat. Die Art der Typisierung hat ganze Größenordnungen mehr an Auswirkung was das angeht.

Keine Ahnung. Aber hier ist der Sourcecode:
https://github.com/greensoftwarelab/Energy-Languages

Ich kann mir gut vorstellen, dass sie idiomatischen Code nutzten und keinen superoptimierten.
Danke. Hab drauf geschaut. Kannst du direkt in die Tonne treten. Beim C Code kein pinning soweit ich das sehen kann und auch kein statischer Compile usw.

Also da geht noch so einiges wenn man will würde ich sagen. Bei Fortran schaue ich dann lieber erst hat nicht drauf.

Zudem super simple Beispiele die es den Compilern und Laufzeitumgebungen einfach machen. Sprich die high level Sprachen funktionieren besser als sie es in realen Größen Projekten machen.

Die Studie kannst du wahrscheinlich nach Herzenslust zerpflücken wenn du Spaß dran hast...

Badesalz

2024-01-23, 16:41:52

Ich glaub - wie gesagt - daß die sich der allgemeinen Komplexität bewusst waren und eine Art ... generische Umstände vergleichen wollten.

Und imho wer Fortran macht, dem ist das da eh völlig egal ;)

Skysnake

2024-01-23, 17:47:52

Naja, aber damit werden Sachen suggeriert die so nicht stimmen. Vielleicht steht es ja im Paper, ich kann es aber nicht lesen.

Was du mit FORTRAN meinst verstehe ich jetzt nicht.

davidzo

2024-01-23, 23:22:16

Ich muss zuigeben mir ist grad nicht klar, warum man eine KI nur so anfuttern sollte, daß sie einen durchschnittlichen Code bringt.
Ganz einfach weil das sortieren und qualifizieren der Trainingsdaten viel Geld kostet. Du brauchst ja schon eine gewisse Masse damit das Modell annähernd kapiert worum es geht. Deshalb nimmt man dafür eben auch AIs oder wenigstens elaborierte statistische kriterien um den Code vor zu qualifizieren mit dem man die neue AI trainiert. Mit Menschen würde das zu lange dauern und zu kompliziert sein und ich denke die hochkaräter haben da auch kein bock drauf auf so stupide arbeit. Das wenige was da menschlich ist sourced man lieber schön an indische Informatikstudenten in den ersten Semestern aus. Und die neue AI bekommt ggf. auch Code den eh schon eine AI geschrieben hat, wie soll man das filtern? Und dann haben wir ggf. ein sich selbst aufrechterhaltendes System.

Im Zweifelsfalle ist es z.B. für OpenAI aber derzeit wichtiger dass der Code den die KI ausspuckt möglichst direkt lauffähgig ist. Stil-Punkte für Eleganz ist die Kür, nicht die Pflicht. Daher ist es einfacher die KI mit mehr durchschnittscode zu füttern der wenigstens läuft damit sie möglichsdt wenig Fehler macht als mit weniger hochqualitätscode.

Zossel

2024-01-24, 00:15:02

Und die neue AI bekommt ggf. auch Code den eh schon eine AI geschrieben hat, wie soll man das filtern? Und dann haben wir ggf. ein sich selbst aufrechterhaltendes System.

War es nicht so das die KIs dümmer werden wenn man die mit KI-Output füttert?
Bei dem ganzen Theater gehen halt Infos flöten, und letztendlich ist der ganze Kram Statistik.

amdfanuwe

2024-01-24, 02:31:21

Ganz einfach weil das sortieren und qualifizieren der Trainingsdaten viel Geld kostet.
Dafür gibt es doch Afrika.
https://www.n-tv.de/wirtschaft/Google-NASA-und-BMW-lassen-ihre-KI-in-Afrika-trainieren-article24675122.html

Badesalz

2024-01-24, 06:34:00

Und die neue AI bekommt ggf. auch Code den eh schon eine AI geschrieben hat, wie soll man das filtern?
Hört sich an als wenn man am Ende eine Lösung dafür hätte wie man den gleichen Müll viel schneller und billiger produzieren könnte :uup:

@Skysnake
Ich meinte, wer mit C unterwegs ist den kann u.a. soetwas mal zusätzlich neugierig auf z.B. Rust machen. Meine bisherigen Erfahrung sagen aber auch, wer heute seine Probleme mit Fortran löst, der schaut sich nicht um, ob es auch anders gehen könnte (vielleicht ist das aber nur meine Blase hier).
Find ich jetzt aber auch nicht irgendwie schlecht.

@all
Einmal OT. Auch wenn sie im Verlauf zugeben einen Bias zu haben, für nur allgemein Interessierte fand ich das recht unterhaltsam. Vor allem das Video kannte ich bis dato nicht :)
https://kruschecompany.com/de/rust-programmiersprache-uberblick/

https://kornel.ski/rust-c-speed

][immy

2024-01-24, 10:06:42

Das ist aber ein Problem der Bildung das selbst verursacht wird. So Sprüche wie
- der Compiler kann das eh viel besser als jeder Mensch
- HW nah programmieren ist nicht realistisch und wartbar
- für Programmieren muss man nicht studieren sondern learning bei Doing ist ausreichend
- ist doch egal wie HW funktionieren. Ich benutze serverless LOL!!!111elf

Helfen da halt überhaupt nicht...

Ich bin froh über mein Physik und technische Informatik Studium jeden Tag froh.
...
Das macht dich nicht automatisch zu einem besseren Programmierer.
Je mehr Code du selbst schreibst, desto mehr Fehler werden sich automatisch einschleichen, weil deine Test Ressourcen deutlich geringer sind. Durch Frameworks etc wird dir für gewöhnlich viel dieses Testaufwands abgenommen. Klar ist es dann nicht immer der optimale weg, aber zumindest wird man auch mal fertig.

Da gibt es doch die Story (hatte damals ein prof von mir erzählt) von dem prof der darüber glücklich war das er nach ~15 Jahren seit Mini-Algorithmus perfektioniert hat. Auf die Frage wer ihm so einen gigantischen Arbeitsaufwand denn bezahlen würde war er ein wenig sprachlos. Klar ist es toll etwas bis zum Ende durch optimieren zu können, aber in der Programmierung muss man letztlich auch immer Kompromisse eingehen.
Oder will jemand heutzutage ernsthaft komplett eigene Oberflächen ohne html/ein forms/... bauen?
Ja, meistens kommt es darauf an das einige wenige Stellen quasi optimal laufen, aber selbst dort ist es immer eine Frage wie viel Zeit man reinstecken möchte.
Eigene engine oder von der Stange um Jahre Programmieraufwand zu sparen?
Benutze ich java, c++ c#, ... Oder emtwickle ich in Jahrzehnten im Assembler (was dann nicht mal portierbar ist).
Immer alles eine Frage der Kompromisse. Wenn ihr hochoptimierte Spiele wollt, beschwert euch nicht das die Preise extrem steigen. Nur die wenigsten Entwickler haben da eine hohe Marge.

Nicht desto trotz geht es ja eigentlich um Strukturbreiten hier oder muss der threadtitel angepasst werden?

Badesalz

2024-01-24, 10:21:30

Ne... Um Oberflächen ging es eher nicht. Es ging erstmal um die Codequali der eigentlichen Rechenaufgabe des Programms. Das war auch die Überleitung beim Thema Strukturbreiten, weil mein Vorschlag , wir werden sich da bis 1nm noch halbwegs absehbar hinquälen, auf wenig Gegenmeinung traf.

Da das mit den Shrinks auf eben Geschwindigkeit/Effizienz(*) bezogen war, fing der Thread sich Gedanken zu machen wie man SONST NOCH der Frage nach mehr (*) begegnen kann.
Und mein Punkt, das da ein ziemlicher Batzen an Leistung durch Pfuscherprogger liegen bleibt, wurde irgendwie gern angenommen. Es scheint als wenn da irgendwas dran wäre...

====
Sonst aber wurden auch so einige weitere Technologien besprochen die der starken Verlangsamung des Shrinks wohl mehr als brauchbar unter die Arme greifen könnten.
WEIL, das Problem ist nicht gleich generell die Unmöglichkeit kleiner gehen zu können, sondern, weil die Wall mit Si irgendwo um 1nm rum sich ab da signifikant bemerkbar mit Tunneleffekten zeigt (Quantenmechanik). Und damit ganz einfach gesagt, man die Möglichkeiten verliert einen Transistor gesichert AUSzuschalten.

Daraus besteht aber dieses Spiel. Man schaltet Transistoren ein und aus.

An sich war der Thread also schon ok und recht informativ. Dafür muss man an seinem quasi Epilog nicht noch am Titel rumpfuschen. Alles gut :comfort:

Eigentlich aber gibt es erstmal noch keine Gründe aufzugeben und den engeren Sinn des Topic zu vernachlässigen :wink:
https://www.youtube.com/watch?v=oIG9ztQw2Gc

edit:
Wobei hier muss man auch genauer schauen was hier und da gequaselt wird und was die jeweilige Glaskugel für Bezugspunkte nimmt. Daheim bringt uns z.B. eine weitere Core-Flood (Thread-Flood) nicht mehr wirklich weiter. Ich bin aber der Meinung, daß bis dahin RT in 4k/HDR butterweich mit 144 laufen wird. Es ist bereits jetzt schon so, daß wenn man das ausklammert, bei egal was sonst der Schuh kaum noch drückt und es nur die Frage des Geldes ist. Nicht mehr der technologischen Möglichkeiten.

Ob ich das vermisse - da mir das schon seit langen nicht mehr passiert - dem 2jährlichen technologischen Sprung entgegenzufiebern, damit etwas endlich wieder flinker vonstatten geht, weil eben der Schuh drückte? Ich weiß nicht...

Zossel

2024-01-26, 19:04:24

Sobald du solche Tools einführst, werden die Softwareentwickler noch weniger Zeit zur Verfügung haben. Denn weil sie ja diese Tools haben, wird das Management denken, man könne jetzt Personalkosten einsparen etc.

https://www.heise.de/news/Schlechte-Code-Qualitaet-durch-die-KI-Assistenten-GitHub-Copilot-und-ChatGPT-9609271.html

Ich bin zwar eher selten am programmieren, aber das bestätigt meine ursprünglichen Befürchtungen wenn man Spatzenhirne an solche Sachen ran lässt:

https://www.heise.de/forum/heise-online/Kommentare/Schlechte-Code-Qualitaet-durch-die-KI-Assistenten-GitHub-Copilot-und-ChatGPT/Projektalltag-mehr-Zeit-den-GPT-Quatsch-auszubessern-als-Nutzen/posting-43591870/show/

Oft genug werden auch von Menschen Corner-Cases ausgeblendet oder Annahmen gemacht die nicht zutreffen.

Und die Verblödung geht sogar noch weiter: https://labs.ripe.net/author/kathleen_moriarty/the-llm-misinformation-problem-i-was-not-expecting/

Badesalz

2024-01-27, 08:12:48

Auch wenn GitHub die Studie kritisiert (Update im ersten Link) halte ich sie für 100% zutreffend.

Skysnake

2024-01-27, 12:49:18

Für mich klingt es auch plausibel.

Zossel

2024-01-27, 15:24:04

Für mich klingt es auch plausibel.

Mit jedem Lernvorgang dürfte ein Informationsverlust einhergehen.

demklon

2024-02-18, 12:04:23

Wie lange kann die Strukturbreite noch verkleinert werden, das ist die Eingangsfrage? :confused:

Weil die Wand kommt immer näher.
Wird das am Ende auf molekularer Ebene ablaufen?

Habe doch keinen Plan, beantworte mal bitte einer die Frage, welche zum erstellen des Freds geführt hat.

Danke Dir Forum

klon

basix

2024-02-18, 13:25:19

Mit jedem Lernvorgang dürfte ein Informationsverlust einhergehen.

Ist es ein Verlust oder eine Kondensierung / Komprimierung? DNN sind aus meiner Sicht primär komprimierte Information. Umso mehr Daten und Rechenleistung man drauf wirft, desto "mehr potentielles Wissen" ist da drin und desto höher der Kompressionsgrad.

Oder bezieht sich dein Satz auf den positiven Feedback-Loop, der sich ergeben könnte? Also man füttert schlechten LLM-generierten Code wieder ins Training der LLM, was dessen Output langfristig immer mehr verschlechtern wird?

demklon

2024-02-18, 15:10:18

Spekulation, wie viel kleiner geht das noch, weil da einfach die Wand kommt.

Also, der Fred wurde ins Spekulationen Eck verschoben,
die Wand kommt immer und immer näher, Auf der untersten Ebene kann es denke ich auch nicht gehen, weil da Ja ströme fließen sollen, und die nicht auf benachbarte "Bahnen" springen dürfen.

Bin völliger Noob, was dieses Feld anbelangt, wagt mal einer zu Spekulieren, wie lange das noch kleiner werden kann?

Zossel

2024-02-18, 17:26:48

Bin völliger Noob, was dieses Feld anbelangt, wagt mal einer zu Spekulieren, wie lange das noch kleiner werden kann?

42

demklon

2024-02-19, 00:42:21

Ein echter Witzbold unter uns, der ernstgemeinte Beiträge.

Die Frage lautet, sogar Fred Titel:

*Wie lange können die Strukturbreiten der Prozessoren noch verkleinert werden?*:confused: :confused:

Tobalt

2024-02-19, 06:25:45

Wurde doch schon zigmal beantwortet.

Du kannst schon heute atomare Strukturen gezielt aufbauen, Atom für Atom. Kleiner als das wird es auch künftig nicht werden.

Zossel

2024-02-19, 06:58:40

Du kannst schon heute atomare Strukturen gezielt aufbauen, Atom für Atom. Kleiner als das wird es auch künftig nicht werden.Oder mit einzelnen Atomen Filme drehen:

https://www.youtube.com/watch?v=oSCX78-8-q0

Orko

2024-02-19, 14:27:49

Die Frage lautet, sogar Fred Titel:
Wie lange können die Strukturbreiten der Prozessoren noch verkleinert werden?

Vielleicht lässt sich die Frage besser beantworten, wenn du sie etwas präziser stellst.

Was meinst du mit "Strukturbreiten von Prozessoren" genau?

- Die Node-Bezeichnungen: z.B. 22nm, Intel7, N3
- Die Größe einer Funktionseinheit, z.B. den Footprint
--- einer SRAM-Zelle
--- eines NAND / NOR / NOT gates
- Die mittlere Größe eines Transistors, ermittelt aus Transistordichteangaben (Anzahl Transistoren pro Waferfläche)
- die kleinsten herstellbaren Struktur-Pitches, z.B. Metal-1-Pitch
- die kleinstmögliche Auflösung von Lithographietools
- ...

Was meinst du mit "wie lange" genau?

- Anzahl in Jahren ab jetzt
- Anzahl an zukünftigen Nodes
- Anzahl an kommenden CPU Generationen
- oder unkonkret als Umschreibung für "Was ist die kleinstmögliche irgendwann erreichbare Strukturbreite?"
- ...

Geht es dir darum, was rein technologisch möglich ist? Oder um das was unter Berücksichtigung von massenproduktionstechnischen und wirtschaftlichen Aspekten voraussichtlich in Produkten (z.B. Desktop Consumer CPUs) umgesetzt werden wird bzw könnte?

Das Bild (aus dem Tomshardware-Artikel zu Hyper-NA EUV aus der Linkliste von Leos heutigen News) gibt meiner Meinung nach einen schönen Überblick was sich wie wann wo verkleinern wird bzw könnte:

https://cdn.mos.cms.futurecdn.net/GAAR625DcjfgtcvEbZz7Pg-1200-80.png

Zossel

2024-02-19, 16:06:15

Das Bild (aus dem Tomshardware-Artikel zu Hyper-NA EUV aus der Linkliste von Leos heutigen News) gibt meiner Meinung nach einen schönen Überblick was sich wie wann wo verkleinern wird bzw könnte:

https://cdn.mos.cms.futurecdn.net/GAAR625DcjfgtcvEbZz7Pg-1200-80.png

Wobei stapeln in die dritte Dimension *eigentlich* keine Verkleinerung ist.

Ansonsten ist das so simpel wie einfach: es wird solange "verkleinert" und "verbessert" solange es Kunden dafür gibt die da für bezahlen.
Beispiel: Es wird keine signifikante Menge an Kunden geben die 10K€ für ein Telefon bezahlen wird.

Platos

2024-02-19, 21:46:24

Wobei stapeln in die dritte Dimension *eigentlich* keine Verkleinerung ist.

Ansonsten ist das so simpel wie einfach: es wird solange "verkleinert" und "verbessert" solange es Kunden dafür gibt die da für bezahlen.
Beispiel: Es wird keine signifikante Menge an Kunden geben die 10K€ für ein Telefon bezahlen wird.

Laut dem Tomshardwareartikel (https://www.tomshardware.com/tech-industry/manufacturing/asml-explores-hyper-na-chipmaking-tools-as-the-next-step-in-shrinking-transistors-tools-would-debut-in-2030-but-significant-technology-and-cost-hurdles-remain) und der dort gezeigten Roadmap ist die Verkleinerung noch bis ~ 2032 gegeben (2030, wenn man nur nach "klassischer" Verkleinerung geht). Danach wird (anscheinend) alles davon abhängig sein, ob ASML "hyper-NA" EUV Maschinen rechtzeitig zur Verfügung hat und auch, ob die dann bezahlbar sind. ASML hat aber auch interesse daran, dass man damit weiterhin Massenproduktion machen will/kann, denn niemand kauft sich eine (z.B) 500Millionen Dollar Maschine, wenn man damit nicht in die Massenproduktioin geht.

Also ASML wird das Ding gerade noch so wirtschaftlich raus bringen, denke ich. Hart an der Grenze kalkuliert.

basix

2024-02-20, 07:15:32

Die Margen von ASML sprechen eine andere Sprache ;)

Wenn du der einzige bist, der ein stark nachgefragtes Produkt hat, wird man das nicht zum Selbstkostenpreis raushauen.

Platos

2024-02-20, 11:25:45

Nein, ich meinte ja eig. eher das Gegenteil: Genauestens kalkuliert, so dass es gerade noch so wirtschaftlich ist (für die Abnehmer), die Maschine zu kaufen/nutzen.

Die Margen werden aber auf jeden Fall sinken müssen. Man gelangt irgendwann an einen Punkt, wo man die Maschinen nicht mehr loskriegt. Wenn die Dinger wieder doppelt so teuer werden, wird man das vlt. nicht mehr bezahlen können/wollen als Chipfertiger. Irgendwann sind die kosten so hoch, das kein foundry-Kunde mehr so ein teuren Prozess bezahlen will. Die Waferstückzahlen sinken und es wird noch unwirtschaftlicher, eine teure Maschine zu kaufen.

Daher sage ich: ASML wird den Preis so ansetzen, dass es für die Chipfertiger gerade noch so lohnenswert ist, die Maschine zu kaufen.

ASML will auch nicht, dass sie von 3 Abnehmer (Intel, TSMC, Samsung) einen verlieren. Ja, sie haben ein Monopol, aber sie wissen auch, dass die Waferpreise auch extrem steigen würden, somit sich so eine Maschine nicht mehr lohnt, wenn man sie zu teuer macht.

Also nochmals: Der Preis wird m.M.n genaustens kalkuliert aein, so dass es gerade noch so gekauft wird. Momentan ist das eher nicht der Fall. Momentan wird gefühlt einfach alles mitgemacht.

Tobalt

2024-02-20, 19:39:19

ASMLs Monopol endet halt auf natürliche Weise dann, wenn sich in Teilen der Semibranche eine Abkehr vom klassischen Weg - CMOS deterministic boolean computing - breit macht. Egal ob das neue Hardware oder Software oder was dazwischen ist. Dann endet auch vorerst die Miniaturisierung.

Badesalz

2024-02-20, 20:02:27

@Tobalt
Aber nicht der Bedarf nach dem bis dato erreichten... Und dahin auch erstmal kommen (wo ASML sein wird), das muss man auch noch schaffen.
Es sei denn man macht das wie die Chinesen, die das bis zu dem größten (dem kleinsten sowieso :tongue:) Schräubchen nachbauen.

Daher sage ich: ASML wird den Preis so ansetzen, dass es für die Chipfertiger gerade noch so lohnenswert ist, die Maschine zu kaufen.WOW. Da hast du mal was herausgefunden... JEDER der nicht einen Massenmarkt bedient, macht das so.

Platos

2024-02-20, 20:20:06

Mal was zu EUV:

https://www.iof.fraunhofer.de/de/presse-medien/pressemitteilungen/2023/euv-quelle-tabletop-format.html
https://www.vdi-nachrichten.com/technik/forschung/neue-euv-strahlquelle-macht-chip-herstellung-effizienter-und-mikroskope-genauer/

wurde das hier schonmal gepostet? Muss man das als (potentieller) Anfang einer Konkurrenz für ASML sehen ?

WOW. Da hast du mal was herausgefunden... JEDER der nicht einen Massenmarkt bedient, macht das so.

Wäre dem so, würden die Maschinen jetzt schon teurer sein. ASML könnte auch noch mehr verlangen. TSMC und co würden es bezahlen. Irgendwann, ab einem bestimmten Preis ist aber Schluss und dann hört die Verkleinerung auf (auf dem Massenmarkt). Und ASML wird diese Grenze genau ausloten. Bei dieser Grenze sind wir aber noch nicht. ASML verlangt noch lange nicht alles, was sie könnten ;)

basix

2024-02-20, 21:57:05

Mal was zu EUV:

https://www.iof.fraunhofer.de/de/presse-medien/pressemitteilungen/2023/euv-quelle-tabletop-format.html
https://www.vdi-nachrichten.com/technik/forschung/neue-euv-strahlquelle-macht-chip-herstellung-effizienter-und-mikroskope-genauer/

wurde das hier schonmal gepostet? Muss man das als (potentieller) Anfang einer Konkurrenz für ASML sehen ?

Interessantes Projekt. Eine Konkurrenz für ASML sehe ich aber nicht. 10mW vs. 200W Lichtleistung. Da ist noch 20'000x Unterschied dazwischen. Für kleinere Anwendungen aber sicher interessant. In ferner Zukunft ist dieses Prinzip evtl. eine Ablösung für den 40kW CO2 Laser in EUV-Anlagen und erhöht die Energieeffzienz der Anlagen. Würde EUV insgesamt günstiger machen.

Badesalz

2024-02-21, 06:24:07

Wäre dem so, würden die Maschinen jetzt schon teurer sein. ASML könnte auch noch mehr verlangen. TSMC und co würden es bezahlen.Du hast RICHTIG Ahnung wie man mit dem eigenen Markt so umgeht was? :wink: Ich meinte nicht, es so zu machen wie Nvidia es macht. Wo dann beim ersten Anzeichen, daß AMD es gleich gut wenn nicht gar besser macht, alle eine Migration wenigstens schonmal vorsichtig ausloten.

Wie soll diese Grundlagenforschung den Anfang vom Ende für ASML einläuten? Check ich nicht. Wenn denn, freut man sich über eine baldige finanzreiche Kooperation :wink: Und wie ich das sehe (eher Laie) trägt das primär zur Steigerung der Ausbeute (nicht schneller, aber eben weniger Defekte) und revolutioniert nicht gleich die Nodes (?)

basix

2024-02-21, 11:28:43

Ja, eine EUV Anlage besteht aus viel, viel mehr als nur der EUV-Quelle. Ist absoluter wahnsinn, wenn ich die Beschleunigungen und Positioniergenauigkeiten der Wafer- & Mask-Stages sehe. Das ist absolut abartige Steuerungs- und Regelungstechnik. Dazu die ganzen Tools hinsichtlich Metrologie, Anlagensteuerung usw.

Ich denke ASML würde sehr gerne eine neue und viel bessere EUV-Quelle einkaufen, wenn es eine geben würde. Oder eben Zeiss und TRUMPF, die die aktuellen EUV-Quelle herstellen.

Badesalz

2024-02-21, 12:57:35

Es ist schon Wahnsinn, wenn man mal begreift wie das EUV überhaupt erzeugt wird :D

Platos

2024-02-21, 14:00:58

Wie soll diese Grundlagenforschung den Anfang vom Ende für ASML einläuten? Check ich nicht. Wenn denn, freut man sich über eine baldige finanzreiche Kooperation :wink: Und wie ich das sehe (eher Laie) trägt das primär zur Steigerung der Ausbeute (nicht schneller, aber eben weniger Defekte) und revolutioniert nicht gleich die Nodes (?)

Weil die Kooperation nicht nur mit ASML geschehen könnte, sondern auch mit anderen grösseren Firmen. Ich meinte hier aber auch nicht in den nächsten 10 Jahren. Eher dann in 10Jahre+

Irgendwann wird man sich am Monopol (so) stören, dass irgendwer eine Konkurrenz aufbaut. Es kann natürlich auch so kommen, dass ASML (jetzt, wo sie Kohle haben), alles aufkaufen, was auch nur die geringste Konkurrenz bedeuten würde. So, wie es grosse Unternehmen eben tun...
Aber es kann auch anders rum passieren.

mboeller

2024-02-21, 14:09:23

Weil die Kooperation nicht nur mit ASML geschehen könnte, sondern auch mit anderen grösseren Firmen. Ich meinte hier aber auch nicht in den nächsten 10 Jahren. Eher dann in 10Jahre+

Glaubst du wirklich dass das so lange dauern wird?

Da "der Westen" bzw. die USA China von der Technologie abgeschnitten hat werden die schon jetzt mit Hochdruck daran arbeiten.

Platos

2024-02-21, 14:21:14

Du meinst jetzt allgemein gesehen oder explizit auf den Artikel bezogen, den ich verlinkt habe?

Weil ich meinte nicht allgemein gesehen, sondern jetzt explizit auf den Artikel bezogen. Es wird aber vermutlich da draussen auch noch viele andere Ansätze (im Labor) geben, die vlt. schon früher "Reif" sind.

Bezüglich China wird das aber alles China-Intern sein, denke ich.

ChaosTM

2024-02-21, 14:32:44

China wird sich früher oder später all das Know How "holen" oder selbst entwickeln.

Was jetzt passiert ist nur ein verzweifelter Versuch um etwas unvermeidliches aufzuhalten.
ASML gibt (ang.) 25% ihres Umsatzes für "Security" aus.

Vor allem ist es mittlerweile relativ egal, ob supercomputer /AI Rechner mit 7 oder 3nm laufen.
Das kann man mit "brute force" recht gut ausgleichen. Und China hat jede Menge davon..

Nvidias ist momentan führend im AI -Race, aber auch hier werden proprietäre System bald nachziehen.

Badesalz

2024-02-22, 06:32:46

Nvidias ist momentan führend im AI -Race, aber auch hier werden proprietäre System bald nachziehen.Hää :confused: Was ist das? Und was ist NV?

Weil die Kooperation nicht nur mit ASML geschehen könnte, sondern auch mit anderen grösseren Firmen. Wer soll das sein, der EUV-Maschinen baut?

@all
Ein technisch ziemlich uninteressantes Thema, wie lange ASML sich ganz oben halten kann...

Welches Material wird euch nach nun das Rennen machen, als Ersatz für Silicon?

Zossel

2024-02-22, 08:15:08

Welches Material wird euch nach nun das Rennen machen, als Ersatz für Silicon?

Kochsalzimplantate :-)

Badesalz

2024-02-22, 09:33:49

Wäre eine Idee, aber sie behalten nicht lange genug ihre Form :wink:

Badesalz

2024-02-23, 10:40:39

Ou... Ich glaub nicht, daß es im Massenmarkt ankommt. Wegen dem nicht-bornitrid Anteil :freak:
https://www.industr.com/de/mit-forscher-entdecken-halbleitermaterial-mit-einzigartigen-eigenschaf-2659998

Wie immer sind die Militärs und die NASA sehr interessiert :usweet:

mboeller

2024-02-24, 21:07:05

was interessantes:

https://www.nextbigfuture.com/2024/02/breakthrough-pseudo-cmos-transistors-for-1000-times-more-efficient-computing.html

https://www.msn.com/en-us/news/technology/an-architecture-for-sub-picowatt-logic-computing-based-on-self-biased-molybdenum-disulfide-transistors/ar-BB1iA6Tl

Skysnake

2024-02-25, 18:57:21

Ähm schlechter Scherz oder?

dynamic delay time of around 200 µs,*

Orko

2024-02-26, 03:30:58

Den beiden pseudo-CMOS Artikeln fehlen mir zu viele Informationen, um die Praxisrelevanz einzuordnen.

Generell begrüße ich die Forschung an 2D Channel Materialien, da absehbar ist dass 3D Channel Materialien bei weiterer Minituarisierung an Grenzen stossen werden (Leitfähigkeit, mechanische Toleranzen). MoS2 wird hier in letzter Zeit ja häufiger genannt, während an Graphen schon länger rumdiskutiert wird.

Eine wesentliche Information die mir hier fehlt: erzielte Beweglichkeiten von Elektronen und vor allem Elektronen-Löchern. (Da finde ich den Artikel zu BAs schon interessanter: Nach Channel Materialien mit höherer Loch-Beweglichkeit als Si:Ge wird ja schon seit Jahrzehnten gesucht.)

In den Artikeln liegt der Fokus auf "static power" also Leckströmen. Zu "dynamic power" also Kurzschluss-Ströme im Umschaltzeitpunkt und dem Umladen von Gate/Leitungskapazitäten wird nichts ausgesagt.

Auch fehlen Angaben zur Größe der Implementierung und Effekten möglicher Minituarisierung. Wodurch genau ergeben sich die genannten 200us dynamic delay time? Können diese durch Minituarisierung (oder andere Maßnahmen) auf eine für CPU / GPU vernüftige Größenordnung gesenkt werden? Erlauben die geringen Leckströme das aktuelle tunneleffekt-dominierte Channel-Längenlimit weiter zu reduzieren (das wäre interessant), oder nicht?

(edit nach Post von Tobalt: 4x das Wort Gate durch das Wort Channel ersetzt)

Tobalt

2024-02-26, 06:08:56

Hö? Meinst du Channel Materialien? Weil du von SiGe und Beweglichkeit sprichst..

Orko

2024-02-26, 08:27:13

Wo du Recht hast, da hast du Recht. Bei mir im Umfeld verwenden wir die Begriffe Gate und Channel manchmal arg flapsig synonym bzw meinen beides zusammen (insbesondere im Zusammenhang der Dimensionierung im Sinne von Gatebreite ~ effektive Channellänge). Aber richtig formuliert steuert der Gate Kontakt den Channel. Ich bessere es im Post oben aus.

Tobalt

2024-02-26, 08:48:13

Ok danke, ich war verwirrt.

Aber mal eine grundsätzliche Frage zur Forschung an Channel-Materialien:

Am Ende unterliegt dies aber alles dem thermodynamischen Transkonduktanz Limit von 60 mV/dec, unabhängig von den Materialien. Man braucht eine Supply Spannung von wenigstens vielen 100 mV, weil sonst der Kontrast zwischen off-leakage und on-resistance nicht groß genug werden *kann*. Und diese Supply Spannung impliziert dann ein Mindestmaß an dielektrischen Leckströmen und kapazitiven Schaltverlusten.

Wie sollen andere Materialien hierbei helfen? Am ehesten würde hier doch Verbesserungen der dielektrischen Materialien was bringen ? Niedriges ε und große Bandlücke. Und hier ist man doch schon extrem spezialisiert unterwegs was das Gatedielektrikum angeht ?!

Laut Wiki liegt man bei Si MOSFETs bei 70 mV/dec, also relativ nahe am Limit von 60 mV/dec. Zielt die Forschung an anderen Channel Materialien auf diese letztmögliche leichte Verringerung von VDD ab oder was ist der Grund ?

EDIT: Eine Frage mal ernsthaft zu formulieren hilft einem direkt selber die Antwort zu finden ;)
Es gibt eine Reihe von Channel-Materialien, auf deren Basis letzlich kein MOSFET gebaut werden soll, sondern das Material wird über andere quantenmechanische Prozesse leitend/nicht leitend gechaltet und unterliegt somit auch nicht dem 60 mV/dec Limit, z.B. https://en.wikipedia.org/wiki/Tunnel_field-effect_transistor

Badesalz

2024-02-26, 09:36:55

Intel-Folien... Wie immer ein Fall für sich. Sie behaupten aber nun in 18A produzieren zu können. Also in etwa 1.8nm.

Die machen auch immer TapeOuts, aber einkaufen kann es irgendwie keiner (Sierra Forest, Intel 3). Jetzt ist halt auch Clearwater Forest durch den Tape-Out. Was auch imemr das bei Intel heißt. Man sieht da meist von lauten Bäumen den Forest nicht mehr.

14A dagegen auch schon 2026. Und dann, soll es weitergehen...
"Schatz, ich hab die Atome geschrumpft" :|

Orko

2024-02-26, 09:57:24

@ Tobalt: Kurz im Netz dazu gesucht:
https://www.sciencedirect.com/science/article/abs/pii/S0038110122002362

Zu den theoretischen Hintergründen kann ich nichts beisteuern.

Ich kenne die Argumentation folgendermaßen:

Die Leitfähigkeit des geöffneten Kanals hängt (bei gegebener Abmessung & gegebener Spannung aka lateraler Feldstärke) von der Elektronen bzw Elektronenlöcher Beweglichkeit ab.

Für n-FETs kann die Beweglichkeit durch die Materialwahl erhöht werden, der gängige Weg in der Hochfrequenzelektronik ist Si -> Si:Ge -> GaAs -> InP um so hohe Frequenzen zu ermöglichen (hohe Elektronen Beweglichkeit - schnelles Umladen der Gate und Leitungskapazitäten).

Für p-FETs ist aktuell bei Si:Ge Schluss und es wird seit Jahrzehnten nach Halbleitermaterialien gesucht die eine Elektronenlochbeweglichkeit grösser als Si:Ge aufweisen.

Für CMOS ist die Elektronenlochbeweglichkeit der frequenzlimitierende Faktor. p-FETs werden deshalb z.T. mit größerem Querschnitt bzw mehr Fins gebaut um dies auszugleichen.

Bisherige CMOS Transistoren verwenden "dasselbe" Halbleitermaterial für NMOS und PMOS Transistoren, da diese räumlich nebeneinander angeordnet sind.

Zukünftige gestapelte Gaa-CMOS Implementierungen, bei denen NMOS und PMOS Transistoren übereinander angeordnet werden, könnten es ermöglichen, für die Transistortypen jeweils unterschiedliche Halbleitermaterialien zu verwenden. Für NMOS von Si:Ge auf GaAs zu wechseln würde einen Leitfähigkeitsvorteil um einen Faktor von etwa 3 bis 6 bringen, und damit entsprechend höhere Frequenzen ermöglichen. Gesucht wird das geeignete Halbleitermaterial-Gegenstück auf PMOS Seite.

Die ganze Diskussion spielt sich im einem Bereich von Beweglichkeiten kleiner Faktor 10 ab. Aber mal flapsig formuliert: Die Versorgungsspannung um ~35mV (Hälfte der Decade) zu erhöhen um dadurch 2 bis 5-fach höhere (Ströme und) Frequenzen zu erhalten wäre ein grosser Fortschritt.

Orko

2024-02-26, 10:21:00

Weitere Gedanken zu dem 60mV/Strom-Decade Limit:

1)

Es scheint mir dass der Arbeitspunkt von CPUs / GPUs wichtig für die Betrachtung ist.

Werden die Prozessoren weit unterhalb der üblichen Arbeitsfrequenz betrieben, mag es sein dass einzelne Transistoren oder auch der gesamte Prozessor auf +70mV Versorgungsspannung mit 10-fach höheren Strömen und dadurch mit ~10 fach höheren Frequenzen reagieren.

Der üblichen Arbeitsbereich (z.B. CPU Vf - Frequenz - Kurve) ist aber weit von 60mV/Strom-Decade entfernt. +60mV mehr Versorgungsspannung hebt die Frequenz vielleicht von 5.0 auf 5.1 GHz an, das ist aber weit entfernt von einem Faktor 10.

2)

Ein Artikel über TFETs: https://www.google.com/url?q=https://elib.uni-stuttgart.de/bitstream/11682/10538/1/Ge-GeSn-GAA-TFET-iht-corp-ident_Deckblatt_Endfassung_Juli_2.pdf&sa=U&ved=2ahUKEwj5sZTG28iEAxVd7AIHHfqWCIwQFnoECAQQAg&usg=AOvVaw0yhorWwFRWZ-cnt_vYpdWV

Die genannte Herleitung des 60mV/dec Limits sitzt hinter einer Paywall.
J. R. Brews, W. Fichtner, E. H. Nicollian, und S. M. Sze, „Generalized guide for MOSFET miniaturization“, in Electron Devices Meeting, 1979 Internationa, 1979, Bd. 25, S. 10–13

Es wird aber angedeutet, dass sich dieses unter anderem aus der Coulomb bzw Rutherford Streuung (https://en.wikipedia.org/wiki/Rutherford_scattering) herleitet und nur für "herkömmliche" MOSFET Transistoren gilt.

Wenn dies zutrifft, gilt das Limit für 3D Channel Materialien, aber vielleicht
nicht unbedingt für 2D Channel Materialien bei denen die Leitungsbandelektronen Interaktion bzw Reaktion in einer Raumdimension unterdrückt wird.

latiose88

2024-02-26, 10:21:48

OK cool noch höhere allcore takt, da bin ich dabei und es erhöht die Leistung bei allen Programmen, aber danach wird es sehr schwer noch weiter zu erhöhen weil auch wenn man das Limit durch das auflockert, kommt man mit der Methode dennoch nicht noch weiter als das was du so geschrieben hast. Naja das reicht ja auch eigentlich aus und so 10 GHz ja da hätte echt schon was.

basix

2024-02-26, 10:37:40

Weiterer Gedanken zu dem 60mV/Strom-Decade Limit:

Es scheint mir dass der Arbeitspunkt von CPUs / GPUs wichtig für die Betrachtung ist.

Werden die Prozessoren weit unterhalb der üblichen Arbeitsfrequenz betrieben, mag es sein dass einzelne Transistoren oder auch der gesamte Prozessor auf +70mV Versorgungsspannung mit 10-fach höheren Strömen und dadurch mit ~10 fach höheren Frequenzen reagieren.

Der üblichen Arbeitsbereich (z.B. CPU Vf - Frequenz - Kurve) ist aber weit von 60mV/Strom-Decade entfernt. +60mV mehr Versorgungsspannung hebt die Frequenz vielleicht von 5.0 auf 5.1 GHz an, das ist aber weit entfernt von einem Faktor 10.

Es sind halt nicht nur die MOSFETs an sich relevant. Auch die Leitungen dazwischen und andere Timing Geschichten. Die Transistoren an sich könnte man wohl mit 100 GHz betreiben, wenn man wollte.

Tobalt

2024-02-26, 10:51:16

Ich sprach jetzt gar nicht unbedingt von höheren Frequenzen, sondern von höherem on/off Kontrast. Wenn dieser Kontrast größer ist, dann kann VDD runter, was an allen Ecken und Enden massiv Verluste spart. Man könnte das zwar theoretisch wieder in Mehrtakt umwandeln, aber soweit ich das gesehen haben, sind die zwei führenden Konzepte für sub-60mV/dec subthreshold swing FETs (NC-FETs und Tunnel-FETs) im Maximalstrom deutlich limitiert, und eignen sich im aktuellen Entwicklungsstand gerade so für Low power sachen - im Labor ;)

Orko

2024-02-26, 11:34:38

Ah, OK.

Die Suche nach Halbleitermaterialien mit höherer Elektronen- bzw Elektronenloch-Beweglichkeit ziehlt nicht auf eine Spannungsverringerung oder Verlustleistungsreduzierung ab, sondern darauf um bei gleicher Spannung die Gate/Leitungskapazitäten schneller umzuladen und dadurch höhere Frequenzen zu erreichen, wodurch natürlich auch die dynamische Verlustleistung entsprechend mit ansteigt.

Tobalt

2024-02-26, 11:52:14

Ok danke, ich hatte irgendwie nicht verinnerlicht, dass die CMOS MOSFETs soweit in die starke Inversion getrieben werden, dass sich da die Mobilität ernsthaft bemerkbar machen würde. Aber klar, dann würde natürlich auch SiGe keinen Sinn machen. Da muss ich mal ein paar fehlerhafte Synpasen überschreiben im Hirn ;)

basix

2024-02-26, 12:16:24

Wenn man schneller umladen kann, kann man natürlich auch die Spannung senken und dementsprechend effizienter werden bei gleichbleibendem Takt ;)

Wobei auch ein sehr gute Wärmeleitung bei gestapelten Chips oder "echten 3D-Strukturen in einem monolithischen Chip" sehr wertvoll wäre. Langfristig ist dieser Punkt evtl. sogar wichtiger als die Elektronenmobilität.

Badesalz

2024-02-26, 13:23:56

Materialien. Inwiefern betreffen sie die im Thread besprochenen Strukturbreiten?

basix

2024-02-26, 13:46:07

Weil es nicht ohne Materialien geht? In den letzten 20 Jahren hat man gefühlt 90% des Periodensystems abgegrast, um kleinere Strukturbreiten zu ermöglichen. Kupfer-Metalstack, HKMG, Kobalt, SOI, Titaniumoxid Insulator, whatnot. Alles materialwissenschaftliche Durchbrüche. Materialien, Lithographie, chemische Prozesse, geometrische Designanpassungen wie FinFET usw. usw. in einem multidimensonalen Raum ermöglichen kleinere Strukturgrössen.

Badesalz

2024-02-26, 16:15:45

Hat soetwas wie z.B. SOI etwas mit der Strukturgröße zu tun gehabt? Leckströme, Schwellspannung, Floating-Body... Ok. Hat das aber DIREKT etwas mit den Nodes zu tun gehabt?

Skysnake

2024-02-26, 17:10:47

Es sind halt nicht nur die MOSFETs an sich relevant. Auch die Leitungen dazwischen und andere Timing Geschichten. Die Transistoren an sich könnte man wohl mit 100 GHz betreiben, wenn man wollte.

Streich das könnte.

Nen einzelner Transistor ist heutzutage extrem schnell nur sind die halt so klein dass die Leitungskapazitäten nicht vernachlässigbar sind. Ich habe selbst high frequency Design in 28nm gemacht und da sind die minimalen Leitungen schon mehr Last als der gleiche Transistor dahinter.... das killt dich einfach.

Zudem muss man sich ja klar machen das man mindestens die dritte eher fünfte Oberwelle mitnehmen muss um auch nur irgendwie halbwegs in die Nähe von einem Rechtecksignal zu kommen.

Ich habe für 12.5GHz DDR Signal Designer, also 6.25GHz Basefrequenz. Die Dritte Oberwelle ist da schon bei 18.75GHz und die fünfte bei 31.25GHz. Die 31.25GHz waren bei mir glaub schon über dem -3dB Punkt, oder war es "nur" die Unitygain Frequency??? Keine Ahnung ist schon 8 Jahre her.

Was ich sagen will ist das man bei den Frequenzen nicht mehr von digitalen Signalen sprechen kann. Und wenn du es doch so richtig digital machen willst bei 6.25GHz dann säuft das Zeug wie ein Loch. Du hast da richtig fette Transistoratufen und nur kleine effektive Lasten zu treiben. Nen Fanout von 2 ist da schon echt böse.

Ich hatte noch keine FIN Fets, mit denen ist es besser, aber trotzdem säuft das Zeug übelst.

Schaut euch einfach mal die Gm/ID Designmethode an. Da sieht man recht schnell das heutige CPUs schon gut über dem Effizientsweetspot drüber sind. Aber ohne Strom nichts los....

Ist halt alles Brechstange, aber wer würde denn einen 100MHz Prozessor akzeptieren????

Skysnake

2024-02-26, 17:28:33

Hat soetwas wie z.B. SOI etwas mit der Strukturgröße zu tun gehabt? Leckströme, Schwellspannung, Floating-Body... Ok. Hat das aber DIREKT etwas mit den Nodes zu tun gehabt?
Naja, SOI gibt dir halt ne ruhigere Ground. Damit mehr Rauschabstandsmarge für die Transistoren, womit man die Schaltung schneller betreiben kann.

Mal ganz davon ab das man backgate Biasing betreiben kann um das Matching der Transistoren zu verbessern. Das taugt wegen dem Aufwand und der Größe wer Wells aber eher nur für high percision low speed Zeug die ADC/DAC mit 32 Bit und so Späße. Also Dinge bei denen du Common Centroid Design und den ganzen Rest der analogen "Black Magic" machen musst damit es überhaupt funktioniert.

Für Highfreq hilft dir das aber nur bedingt was abseits von der besseren Groundisolierung. Du hast halt bei 10GHz+ bei jedem Scheiß die nicht vernachlässigbaren Kapazitäten im Dutzend frei Haus....

Das macht echt keinen Spaß. Meine paar tausend 1.25GHz Mixed Signal Schaltung musste ich schon mit <1ps min Zeitschritt simulieren damit es physikalisch noch sinnvolle Ergebnisse produziert hat...

Das macht am Ende vom Tag alles keinen Spaß mehr. Und ein einzelner Designer der nen Bock schießt macht aus deinem teuren Silizium nen Briefbeschwerer....

basix

2024-02-26, 17:32:28

Hat soetwas wie z.B. SOI etwas mit der Strukturgröße zu tun gehabt? Leckströme, Schwellspannung, Floating-Body... Ok. Hat das aber DIREKT etwas mit den Nodes zu tun gehabt?
Verweis auf meinen eigenen Post:
[...] in einem multidimensonalen Raum ermöglichen kleinere Strukturgrössen.
Es gibt keine Exklusivität. Das eine ermöglicht das andere. Der eine Schritt ermöglicht den nächsten. z.B. HKMG braucht man nicht unbedingt. Half aber ungemein. Genauso wie Kupfer im Metalstack.

Badesalz

2024-02-27, 08:22:27

Wir hatten hier schonmal
" weil die Wall mit Si irgendwo um 1nm rum sich ab da signifikant bemerkbar mit Tunneleffekten zeigt (Quantenmechanik). Und damit ganz einfach gesagt, man die Möglichkeiten verliert einen Transistor gesichert AUSzuschalten."

Intel & Co. machen ihre... Roadmaps, aber eigentlich sind das einige anderen Techniken, unabhängig von Shrinks.
Wie die schon erwähnten Borverbindungen deren Wärmeleitfähigkeit ums Zigfache die mit Si übersteigt.
Das es zukünftig einen Mix von Materialien geben wird um die Leistungsfähigkeit/Effizienz zu steigern: check. Hatten wir schon. Genauso wie Photonik.

Themabezogen geht es bei der Shrink-Wall mit Si aber nur um daa obige. Nah 1.2nm rutschen wir in Strukturgrößen wo die Quantenmechanik uns einholt und wir die Transistoren wegen den Tunneleffekten nicht mehr sicher ausschalten/sperren. DARUM geht es eigentlich. DAS hat mich grad interessiert, mit welchem Zeug man JENES Problem angehen möchte.

Die Sicht themabezogen also bisschen klären. Ohne den ganzen Rauch drumherum grad :wink:

Tobalt

2024-02-27, 08:28:03

Nee da widerspreche ich..Um ausschalten/einschalten ging es nie. Es ging um Strukturgrößen. Wir können natürlich bis in den atomaren Bereich miniaturisieren und das wurde auch schon demonstriert. Aber CMOS geht dann natürlich nicht mehr. Bezieht sich die Frage auf CMOS?

Badesalz

2024-02-27, 08:56:42

Natürlich geht es um CMOS. Oder warte:

"Strukturbreiten der Prozessoren" :|

Zossel

2024-02-27, 10:51:13

Badesalz

2024-02-27, 12:53:28

Dann gehts aber direkt ans Eingemachte :wink: Und ist nicht verkehrt, aber wir konnten noch nichtmal den groben Umriss durchkauen.

Womit wir erst Richtung andere Materialien schwenkten (auch nicht verkehrt), aber eher mit dem Kontext für allgemeine Verbesserungen und nicht für die Shrinks selbst.

Intel tönt jetzt rum, sein 18A funktioniert. Damit sind wohl in etwa 1.8nm gemeint (?) Wobei man hier ruhig zwischen "Fertigstellung" und "Massenproduktion" unterscheiden darf.
"„We know how to make 10nm chips“ erzählte man 2012. Den Kofferraum eines Kombis mit 18A Chips für MS hinzubekommen ist noch nicht

TSMC sagt, wir kommen an 18A schon mit N3P quasi dran und bekommen es auch hin noch N2 in FinFET zu machen. BSPDN bei TSMC erst 2026 mit N2P.
N2 ist schon in... Validierung. ~1.4nm wird entwickelt. Bis etwa 1nm traut man sich noch was vorauszusagen (2030).

imec erzählt GAA reicht bis A7 (0.7nm?) und da würde auch noch reichen was wir bisher schon haben (haben und teils noch nicht nutzen).
Danach wohl eher nur CFET. Und nur, wenn uns schon genug Sachen ("Materials") einfallen womit wir das machen könnten. Mit bisschen Glück steht der Plan dafür - noch keine Massenproduktion - auf um 2032 rum.

Ab A10 ändert sich der Metall-Pitch nicht mehr. bzw. ist heute noch nicht vorhersagbar. A10 soll bei 16nm landen, A7 16-14nm, danach geht man variabel nur noch von 16-12 aus. Konstant. Dimensional scaling (2D) hört damit auf.

Und spätestens ab A2 muss man schon auf einzelne Atome achten. Keine Ahnung wie sie das um 2036 rum hinbekommen wollen. 0.2nm sind 200 Pikometer. Da geht schon ewig nichts mehr mit Silizium.
Van-der-Walls Radius von Gallium ist auch schon 187pm. Was ist da Vcc? 5mV? :wink:

Wir werden uns da also noch wie es schon im Thread steht in Größenordnungen von Tausenden steigern können (StarTrek-Techno am Horizont), aber das wird nicht mehr so stark von den Shrinks selbst abhängen.

Vom Gefühl her - und mehr nicht :tongue: - macht aber schon die vorhandene reine Rechenleistung auf mich nicht den Eindruck, als wenn man es in-chip richtig auslasten könnte. Es wird irgendwie immer viel gewartet bis neues nachkommt oder/und berechnetes wegkommt. Fühlt sich an wie ein Nvme Raid0 über 2.5Gbit Ethernet.

PS:
Natürlich nur, wenn die Welt bis dahin nicht erstmal für paar Jahrzehnte zusammenklappt... Ergo, sinnig ist so ein Thread heutzutage eher nicht :freak:

Zossel

2024-02-27, 13:18:24

Natürlich nur, wenn die Welt bis dahin nicht erstmal für paar Jahrzehnte zusammenklappt... Ergo, sinnig ist so ein Thread heutzutage eher nicht :freak:

Denk da mal lieber in geologischen Zeiträumen.

Badesalz

2024-02-27, 13:20:04

Ja das wird wahrscheinlich wohl so sein :frown:

Technologisch glaub ich noch an A10. Um A7 rum und weiter hört sich das alles eher - und erstmal - mehr nach SF an als nach Technologie. Es sei denn die KI die dann auf Photonic und A10 läuft kann was dazu beitragen :D

mboeller

2024-03-13, 13:12:52

Weil ihr hier in diesem Thread darüber diskutiert habt:

Next-gen AI software developer spawns and trains its own AIs (https://newatlas.com/technology/devin-ai-software-engineer/)

In essence, this new AI is designed to act like an entire software team – tell it what you want, and it'll put its project management and business analysis hats on to devise a plan and build requirements.

But this is the most advanced form we've seen yet of what certainly seems to be coming: the end-to-end AI programmer that simply figures out what you want and goes and does it, then fixes whatever you don't like about it – in a fraction of the time, and at a fraction of the cost that a human software team needs. Inspiration to results with 0% perspiration.

Platos

2024-03-13, 16:14:59

Am Ende versteht nur noch ein kleiner, winziger Teil etwas von Coding, wenn mal die AI alles übernimmt.

latiose88

2024-03-13, 17:10:40

kommt halt drauf an was man so codiert.Ging es um Allgemein das ganze?

Zossel

2024-03-13, 20:09:02

Skysnake

2024-03-13, 22:31:14

Platos

2024-03-14, 04:12:29

kommt halt drauf an was man so codiert.Ging es um Allgemein das ganze?

Ja, allgemein. Spiele, Programme (also "andere"), Internet (Webseiten) usw, Betriebssystem, GUI-Sachen.

Platos

2024-03-14, 04:14:10

So schaut es aus.

Der Punkt ist doch woher soll die KI wissen was man wirklich will? Ach das wird schon. Muss man halt Iteration der KI sagen was man will oder halt nicht. Wieviel Iterationen können das schon sein?

Wer Sarkasmus findet darf ihn behalten.

Ich sehe das jetzt auch nicht grad morgen kommen, wenn ich mir ansehe, wie dumm ChatGPT eigentlich ist.

Aber in 10 Jahren? Why not.

Das mit den selbst fahrenden Autos wird vlt. nicht so schnell was (im deutschsprachigen Raum), aber selbstfahrende Züge. Wer weiss. Die DB droht ja gerne damit xD

Zossel

2024-03-14, 06:24:36

Ich sehe das jetzt auch nicht grad morgen kommen, wenn ich mir ansehe, wie dumm ChatGPT eigentlich ist.

Aber in 10 Jahren? Why not.

In welcher Sprache willst du das einer KI erklären?
Und wie kannst du verhindern das man einer KI die falschen Fragen stellt? (Mehr Transistoren werden das ganz bestimmt nicht verhindern)

mboeller

2024-03-14, 09:12:06

Bla, schwafel, sülz. Auto sollten doch schon seit 10 Jahren alleine fahren können.

Wieso, funktioniert doch... nur noch nicht "so gut"

Der Link hier kommt gerade recht. ;)

Selbstfahrende Autos im Praxis-Test durchgefallen: Nur ein Autopilot erreicht Mittelmaß (https://www.notebookcheck.com/Selbstfahrende-Autos-im-Praxis-Test-durchgefallen-Nur-ein-Autopilot-erreicht-Mittelmass.812765.0.html)

edit:
auf vox mobile.tv kommen öfters Tests mit den ganzen Sicherheits-Assistenten in den neuen Autos. Mein Resümee aller bisherigen Test: wer sich auf den "Dreck" verlässt ist verlassen. Mal funktioniert es, mal nicht... so eine 30%-70% Chance dass es funktioniert. Also ähnlich wie bei den KI's LLMs, da ist das Ergebnis auch manchmal gut und manchmal auch nicht. Wenn man sich dann auf das Ergebnis verlässt...

Fliwatut

2024-04-25, 15:02:33

demklon

2024-05-11, 16:16:44

Wann kommen *Graphen Akkus* für die Breite Masse in die Geräte, bzw zum Nachrüsten?

mboeller

2024-05-16, 09:45:39

wenn es nicht mehr kleiner geht, dann macht man es halt wieder ein "wenig" größer:

https://www.cerebras.net/product-chip/

Jetzt als WSE-3

Chip Size]__________46,225 mm²
Cores_____________900,000
On-chip memory____44 Gigabytes
Memory bandwidth__21 Petabytes/sec
Fabric bandwidth____214 Petabits/sec

basix

2024-05-16, 21:52:56

Ab 2027 kann man jegliche Chips bei TSMC mit "Wafer Scale" packagen ;)
https://www.anandtech.com/show/21372/tsmcs-system-on-wafer-platform-goes-3d-cow-sow

https://images.anandtech.com/doci/21372/tsmc-sow-cowos-evolution.png

iamthebear

2024-05-16, 23:09:41

Das mag zwar für AI Workloads in riesigen Datacentern toll sein, nützt dem normalen Durchschnittsanwender aber wenig.

Das was die Entwicklung bisher getrieben hat war nicht die Transistordichte sondern dass die Kosten und Energieverbrauch pro Transistor gefallen sind.

basix

2024-05-17, 07:40:59

Wobei die Transistordichte hier die Voraussetzung war. Aber seit dem Ende von Dennards Scaling ist der "einfache Weg" eh Geschichte, also seit ca. 15-20 Jahren. Dichte konnte man ab dann noch steigern, aber Energieverbrauch nicht im gleichen Masse. Ergo wurden Kosteneinsparungen immer niedriger, weil man nicht mehr "alle" Transistoren gleichzeitig schalten kann und die Lithographie-Prozesse immer teurer wurden.

Um zum Thema Wafer-Scale zurückzukommen:
Ja, das ist primär für Datacenter / HPC interessant. Für Consumer Produkte sehe ich TSMCs InFO sowie 3D-SoIC die Treiber für erhöhte "Dichte". Damit lässt sich in die Höhe und Breite gehen. Für 0815 SoCs / APUs ist das mMn nach nicht zwingend nötig. Mehr IPC, mehr Takt, verbesserte Architekturen und vor allem auch: Verbesserte und optimierte Software. Hier liegt so viel Potential brach. Viele Systeme fühlen sich so langsam an, weil mit Bloatware überladen oder alles mögliche übers Netzwerk gehen muss (MS Teams, Sharepoint, Office etc. lassen grüssen). Das verlangsamt Systeme enorm. Dazu Software, die einfach generell langsam läuft, weil organisch zu irgendwas gewachsen und mit Features überladen, wobei der Core der SW initial nicht für das designed war. Schrecklich, was da aus massig Rechenleistung gemacht wird.

Zossel

2024-05-17, 08:10:16

Verbesserte und optimierte Software. Hier liegt so viel Potential brach. Viele Systeme fühlen sich so langsam an, weil mit Bloatware überladen oder alles mögliche übers Netzwerk gehen muss (MS Teams, Sharepoint, Office etc. lassen grüssen). Das verlangsamt Systeme enorm. Dazu Software, die einfach generell langsam läuft, weil organisch zu irgendwas gewachsen und mit Features überladen, wobei der Core der SW initial nicht für das designed war. Schrecklich, was da aus massig Rechenleistung gemacht wird.

Das nennt sich "Time to market".

Tobalt

2024-05-17, 08:14:15

Software hatten wir ja schon viel. Es klingt immer für Laien wie eine Floskel, aber es ist halt wirklich so. Im Hardware Bereich freut man sich über 10% hier, 10% da.

Im Software Bereich kann man noch im 90er Jahre Style "Faktoren" besser werden. Und wird dies aus ökonomischen Gründen künftig auch tun, weil bessere Hardware nicht mehr der easy way out ist.

Waferscale oder größere Chips allgemein ist überall da ein wichtiges Puzzle Stück, wo man 24/7 rechnet. Mehr Einheiten bei niedrigerem Takt verbessern die Task Energy. Zwar steigen die Herstellungskosten, aber über die Lebensdauer lohnt sich das dann trotzdem.

Skysnake

2024-05-17, 15:58:02

Was heißt hier Faktoren? Selbst Größenordnungen ains nichts ungewöhnliches.

iamthebear

2024-05-17, 18:29:54

Die letzten 4 Jahre ist Software immer nur langsamer geworden und nie schneller.
In der Regel kümmert sich ein Softwarehersteller erst um Performance wenn sie so schlecht ist, dass es die Verkaufszahlen massiv negativ beeinträchtigt.

demklon

2024-05-18, 11:49:38

Die Wand ist doch schon da, Miniaturisierung ist gefragt.
Wie viele Schritte kann das denn noch kleiner gemacht werden, weil wand ist schon da.

demklon

2024-05-20, 18:38:33

Ich denke, Moores Law kam zum erliegen, jetzt scheint eine Art Grenze erreicht. :confused:

Es gibt doch mit Sicherheit einen einen Begriff für die Jetzige Zeit. :confused:

Badesalz

2024-05-21, 19:53:26

Ich denke, Moores Law kam zum erliegen, jetzt scheint eine Art Grenze erreicht. :confused:1.6nm ist schon hart nah dran. Jedenfalls wenn man die Angström-Fantasien entsprechend skeptisch betrachtet...

Es gibt doch mit Sicherheit einen einen Begriff für die Jetzige Zeit. :confused:Der wird erst vergeben von der folgenden Zeit :wink:

Jetzt kommt bzw. ist schon eine Zeit in der die Weiterenwicklung der Elektronik nicht zu 50% von ASML erledigt wird.
Und eigentlich schwimmt man aktuell in Leistung. Wenn nicht gar ersäuft. Nadelöhre sind eher die Datenschieberei als deren Berechnung. Da wird man noch einiges freischaufeln können.

Pirx

2024-05-21, 20:16:01

vllt. gehts ja Richtung Licht-CPU oder zumindest optischer links

Badesalz

2024-05-22, 06:57:54

@Pirx
Das möchte ich zu 100% bestätigen :wink: Das hatten wir aber schon. Gar eine ganze Liste mit noch anstehenden Baustellen, wo man mehr rausholen kann als mit mehreren Nodeshrinks.

demklon

2024-05-22, 10:32:06

vllt. gehts ja Richtung Licht-CPU oder zumindest optischer links

Das wird einen spannende zeit :)

Extrem

mboeller

2024-07-15, 13:12:42

https://www.notebookcheck.com/Weniger-als-1-Nanometer-Neue-Technik-macht-winzige-Chips-moeglich.863209.0.html

<1nm ... wow aber IMHO auch ein wenig verrückt

Badesalz

2024-07-16, 08:13:12

@mboeller
"Durch den molekül-weisen Aufbau einer solchen Struktur wurde es möglich, fast um den Faktor Zehn kleiner zu bauen, also bisher möglich."

Das ist der 3D-Drucker der molekülweise Elektronik aufbaut. Das ist imho was für 2055 oder so :wink:

Erstmal werden richtige 3D-Nodes kommen, dann ~2nm, dann Photonics für den Datenverkehr.
Was den Ansatz angeht mit Photonics auch zu rechnen bin ich mir noch nicht sicher inwiefern das verwertbar ist.

Imho reden aber alle die da mitmischen überwiegend von memory-wall. Jeder so unter seinem Aspekt und dem was er grad macht, aber allgemein scheint mir das der usus.

Dafür gibt es auch verschiedene Ansätze.
https://www.reddit.com/r/singularity/comments/vwv321/50x_performance_gain_darpamit_demonstrated_the/?rdt=59979

Die Latenzen selbst verbessern sich ja sonst nicht so wirklich
https://www.anandtech.com/show/16143/insights-into-ddr5-subtimings-and-latencies

Ist imho die wichtigere wie auch größere Baustelle als nur nodes nodes nodes... für die CPU.

Platos

2024-07-16, 14:14:05

"Photonics für den Datenverkehr"? Auf welcher Ebene? Redest du hier von solchen Dingen wie PCI-E, Speicher Anbindung (RAM & VRAM) und Chip-Chip Verbindung oder redest du vom Datenverkehr innerhalb von Chips?

Es gab ja vor ein paar Jahren irgend eine Firma, die behauptete, sie könne logik (also nicht nur Datenverkehr) auf "photon"-basis herstellen (also gemeint sind nicht Quantencomputer). Aber irgendwie hat man nie mehr was von der Firma gehört...

Skysnake

2024-07-16, 20:39:47

Analogrechner waren das.

Und bezüglich den von dir genannten Punkten bezüglich photonics kannst du bei allem ein ja machen.

Tobalt

2024-07-16, 22:20:53

Die Photonic links sind da relevant wo du a) viel Bandbreite bewegen willst und b) nicht auf das letzte Quäntchen Latenz angewiesen bist. L1/L2 sind also nichts. L3 vermutlich nicht.

Nicht umsonst nutzt man es schon bei Ethernet. Der nächste Schritt sind dann die Peripherie Interfaces.

latiose88

2024-07-16, 22:37:12

schade aber gut dann sind wir ja zumindest bei CPU Cache und so schon am Ende angelangt.Weil man das nur sehr schwer verkleinern kann.Dummerweise nimmt Cache sehr viel Platz ein.ALso ist da dann bei der CPU Grenzen gesetzt.Irgendwann wird der Cache das shrinken bei der CPU zu Nichte machen.Noch sind wir ja nicht am Ende angelangt aber wenn uns die Alternativen ausgehen,sehe ich da schon das Ende angelangt.Auch Stapeln beim cache ist nicht immer Optimal.Weil es dann Hitze Stau bei der CPU verursachen könnte.

Badesalz

2024-07-17, 08:02:31

Ich weiß nur nicht wie lange das dauert :rolleyes: (photonic) Imho kommt das eher in vielen kleinen Schritten. Im-Die ist halt schon eine andere Nummer als am-Die.

Hier wird noch nach den trade-offs gesucht. Die Teile welche die Lichtstrecke bedienen - also die Umwandlung Transceiver-like - nehmen schon ordentlich mehr Platz ein als einiges an SRAM.
Die LWL-Strecke selbst lässt sich dagegen signifikant schmaler bauen und insgesamt braucht die Aufrechterhaltung des Signals doch nennenswert weniger Energie als das wie wir es heute mit im-Die Kupferstrecken machen. (tatsächlich)
Es erscheint trotzdem fortlaufend lohnenswert, weil keiner jener die in der Lage sind damit rumzubasteln ignoriert es.

Shrinks für sich selbst werden halt uninteressant. Was die Konstruktion angeht waren sie das schon länger. Imho so ab spätestens 90nm rum (!) kommt der im-chip Durchsatz nicht entsprechend mit der Rechenleistung der Logik mit.
Wenn man so möchte, sind Shrinks und sonstige Maßnahmen dagegen, mehr oder weniger Brechstangen um das aufzuwiegen.

Ging auch so halbwegs bisher. Jetzt wo das mit dem schlichten Schrumpfen vom Aufwand her immer kolossaler wird, widmet man sich endlich den eigentlichen Problemen zu :wink:

PS:
Wir sind grad an sehr vielen Stellen bereits wieder an irgendeinem "Ende". Leben weiterhin davon was Opa und Vater sich ausgedacht haben und drehen da nur an paar Stellschräubchen nach. Meist lässt sich dabei, ehrlicherweise, nicht wirklich von neuen Technologien sprechen.

Machen dann das Gleiche in grün nur in breiter und kippen immer mehr Watt drauf. Bis aufs Zocken in 4k/RT/HDR/144 :rolleyes: ersaufen wir aber sonst in Leistung. Daher heule ich auch nicht rum, aber man merkt es immer öfters an immer stärkeren Verzögerungen gegenüber anfänglichen Fantasieroadmaps.

Plakatives Beispiel aktuell: PCI-SIG. Specs von 6.0 sind seit mehr als 2 Jahren fertig. Ist die "vorläufige Testphase" doch schon gestartet? ;) Auch für 6.0 wird noch - oder schon - über optische Verbindungen gegrübelt. Sonst hat man ja schon über spezielle Kühlung von PCIe-Slots geschwafelt. Die Konformitätstests von 7.0 sind auf 2028 verschoben...

DDR5 muss nun schon intern eine Art ECC machen - und eben ständig korrigieren - damit es stabil läuft.

Die Glasfaser, die aus Plastik :tongue:, (und um den Kreis zu LWL zu schließen, betrifft aber nicht zwingend Photonics on Die) ist auch kein Wundermedium mehr. Wieviel bekommt man zivilisiert über EINE Faser durch? Jemand die Stecker für 400Gbit, 800Gbit und 1.6Tbit gesehen? Das wird alles primär schneller nur durch "breiter". Und verlangt mittlerweile nach extremen Fertigungstoleranzen.
Und dann hängt das auch nicht nur am "Glas" selbst, sondern auch der Wandlung (Photonen <-> Elektronen). Transceiver 10Gbit unter 0.7W. Transceiver 800Gbit, 25W. Transceiver 1.6Tbit, um die 35W. Ja ja, "Effizienz". Das Perf/Watt-Thema ändert aber nichts am Slot/Watt-Problem.

So ähnlich wie mit WiFi7 jetzt...

Platos

2024-07-21, 15:49:42

Ja, bei LWL ist vor allem die Wandlung das Problem. Zu Hause ist ja noch nicht mal das Internet wirklich Glasfaser (ab dem Router bis zum PC ist es ja weiterhin Kupfer oder spätestens ab der Dose bis zum PC).

Wenn man nun an tausend Orten Stückchenweise "Photonics" einsetzt (gibt es da irgendwie einen Fachbegriff?), braucht es auch an tausend Orten die Uwandlung von Elektron zu Photon. Ich denke, hier wird das Potential (Energieeffizienz) oft direkt wieder vernichtet.

Aber wieso ist bei photonics Latenz schlecht? Liegt das daran, dass man am Ende immer irgendwo das Signal wieder umwandeln muss oder an was liegt das?

Und bezüglich Cache stapeln: Stapeln ist doch so eine Sache... Mehr Fläche ist mehr Fläche. Ob es nun gestapelt ist oder nebeneinander angeordnet, ist doch relativ egal aus Sicht der benötigten Waferfläche. Also das heisst die benötigte Waferfläche sinkt durch stacking nicht. Auch unterschiedliche Fertigungsverfahren kann man auch ohne Stacking nutzen (Intel macht das ja nun). Also ich sehe bei Stacking keine wirklich finanziellen Vorteile (und um die geht es ja, es muss besser werden bei gleichen Kosten und das lässt Stacking so nicht zu. Es ist eher ein technischer Vorteil).

Ausser man kann vlt. irgendwann "echte" 3D-Chips fertigen und zwar so, so dass es von der Waferfläche wieder günstiger wird. Also die Waferfläche, die man ohne 3D-Chip benötigen würde, müsste (in Chiplets gedacht, nicht in einem riesigen Die) signifikant teurer sein, wie dann der 3D-Chip.

Könnte man bei echten 3D-Chips nicht vlt. den Speicher sogar unter der Logik verbauen (damit die grosse Hitzequelle oben ist)?

mocad_tom

2024-07-22, 12:17:26

Kurnalsalts schaut sich Samsung W1000 Chip an.

https://x.com/Kurnalsalts/status/1814278353698033970

Er ist im Samsung SF3 Prozess.

Samsung hat jetzt 2 Jahre lang nur Krypto-Mining-Chips mit diesem Prozess gemacht.
Krypto-Mining, weil die Chips in sich selbst unheimlich redundant/repititiv sind, dann konnte man Teildeaktivieren und dann kamen da noch lauffähige Chips raus.

Der Exynos 2500 kommt nicht ins Samsung S24 rein.
Der kommt jetzt in gar kein Smartphone rein.

Damit sie die Yield-Probleme in den Griff bekommen haben sie jetzt einen kleinen Smartwatch Chip, den Exynos W1000 genommen und in diesen Prozess reingesetzt.
Der Chip ist 4,84mm x 3,65mm also 17,66mm^2 groß.
Er ist also winzig.
Und bei diesem Chip haben sie eine Ausbeute von 55%.

Kurnalsalts spekuliert, dass Gate All Around besonders gefährlich ist.
Hat man 55% yield bei bei 17,66mm^2, dann hat man bei 120mm^2 eine Ausbeute von 5%.

Ich hoffe man hört bald konkretes(bessere Nachrichten) von Intel.

Der erste, der GAA packt, der hat die nächsten 4 Jahre Ruhe und den fertigungstechnischen Vorteil auf seiner Seite.

latiose88

2024-07-22, 12:54:30

Na würde ich so nicht sagen. Wenn aw anderen selbst ohne um einiges voraus bzw Im Vorteil haben, dann wäre diese der es dann mit GAA geschafft hat nur minimal vorne. Und warum weil die anderen schon vorher besser waren. Der Vorteil ist dann somit nur ein kleiner vorsprung. Oder ist die Technik so stark das es alle Sachen die man zurück liegt komplett egal weil man damit jeden davon rennt obwohl man zuvor zurück lag.
So als ob man 1 - 2 Runden zurück liegt und mit der super Technik eben gleich 3 Runden durch fliegt und somit dann auf einmal vorne liegt?

mboeller

2024-07-22, 13:28:48

So als ob man 1 - 2 Runden zurück liegt und mit der super Technik eben gleich 3 Runden durch fliegt und somit dann auf einmal vorne liegt?

doch doch... wenn GAA funktioniert hat derjenige, der es beherrscht einen massiven Vorsprung vor allen Konkurrenten mit FinFET-Technologie. FinFETs sind nämlich am Ende (technologisch)

https://eepower.com/tech-insights/could-gaafets-replace-finfets/#

With GAAFET transistors still in the testing phase, we cannot declare final performance or efficiency improvements. Samsung estimates that at the same lithographic process of 3nm, the figures are 50% power savings, [or] 30% performance improvement, and 45% area reduction.

das [or] stammt von mir

KarlKastor

2024-07-22, 18:35:08

So oder so ist das ein Armutszeugnis für Samsung. Seit zwei Jahren sind die ja mit 3GAE in "Massenproduktion". Und das Einzige was die bisher fertigen ist ein Smartwatch Chip der winzig klein ist und wohl maximal 1 GHz taktet. Ein mäßig herausfordernder Smartphone SoC kommt hingegen nicht.

Wäre ja alles kein Problem, wenn sie nicht alles stehen und liegen gelassen hätten um GAA als erstes am Start zu haben.
Das beste was sie der Kundschaft zu bieten haben ist immernoch 4LPP+, ein 7nm Node.

Badesalz

2024-07-22, 19:34:35

Wenn man nun an tausend Orten Stückchenweise "Photonics" einsetzt (gibt es da irgendwie einen Fachbegriff?)Hab ich schon einmal gesucht, aber nichts eindeutiges gefunden. Es ist halt erst der Anfang :rolleyes: Ich behelfe mir da manchmal selbst mit Compute-Photonics und Transport-Photonics.
Das erste gefiel mir sofort :tongue: Beim Zweiten bin ich mir noch nicht sicher...

Aber wieso ist bei photonics Latenz schlecht? Liegt das daran, dass man am Ende immer irgendwo das Signal wieder umwandeln muss oder an was liegt das?Ja. 2x halt. Mindestens. Das wird noch ne Weile dauern.

@mboeller
Also Wundertechnik ist das jetzt auch nicht oder? 50% weniger Strom UND 30% Leistung wären schon eher ein Wow :wink:
30% power savings UND 25% performance improvement? :tongue:

Das Prob bei so einer z.B. Server-CPU von max. 130W (auf x86 bezogen) wäre jetzt aber wieder die Kühlung. Minus NUR 30% weniger Saft, das aber auf 45% weniger Fläche? Macht das die Kühlung einfacher?

Skysnake

2024-07-22, 20:33:24

Definitiv nicht. Erhöht am Ende nur noch den allcore Turbo.

Single core passiert da nicht mehr viel.

Tobalt

2024-07-23, 20:20:46

Bezüglich Peak W/mm2 sind Si-VLSI Chips schon lange am Limit. Da passiert seit ca. 20 Jahren eigentlich nichts mehr und man steht bei ~1 W/mm2

Badesalz

2024-08-04, 20:42:22

Das wird einen spannende zeit :)

ExtremKönnen wir uns abschminken :rolleyes:
Da noch 2 Tage Strohwitwer und unsere Glotze per se keine Werbung auf YT zeigt, ist das grad teilweise ein Fest :uking:

Photonics-Compute ist SF. Man hat aktuell wieder aufgehört Geld auszugeben um Theorien zu entwickeln wie das gehen könnte. SO WEIT WEG ist das aktuell. Ich glaub zu unseren Lebzeiten nicht mehr. Wenn überhaupt mal.

Photonics-Link dagegen ist schon halbwegs real. Bei TSMC anscheinend zusammenhängend mit A16 und 3D. 3D und back-side power sind da wohl die Schlüsselwörter. Es gelingt wohl die Transceiver on-chip dann so kompakt zu bauen, daß es auch 0815-attraktiv wird.

Das Stichwot dagegen, ist Powerbudget. Als Beispiel wurde ein 51 Tbit/s Switch genommen. Das sind die Teile für 1,6 Tbit/s Ethernet.
So ein Ding zieht sich aktuell um die 2kW rein :freak: Würde man den komplett auf Photonics-Link Bauteile umstellen - schon bei dafür aktuell genommenen Nodes - wäre eine Reduktion auf 40% realistisch. Nicht um 40%. Auf 40%.

Photonics-Link haut also schon ziemlich rein.

Skysnake

2024-08-04, 23:14:00

Ja und je größer die Bandbreite wird desto größer wird der Unterschied. Unterhalb von min 1 TBit/s brauchst du nicht wirklich anfangen. 10TBit/s wären eher realistisch.

Badesalz

2024-08-04, 23:59:53

Wobei Netzwerk ist grad wie vieles andere auch irgendwie erstmal kurz vorm Ende :smile: Das wird auch erst nur noch breiter.
OSFP-XD zielen vielleicht auf 1.6 Tbit/s, aber an sich ist das halt nur 16x 100G. Entsprechend werden die Plastestecker immer irrer (u.a. die nötigen Toleranzen). Imho würde man da gerne bei max. 8 Lanes bleiben.

Die Transceiver knacken grad die 30W Grenze. 60W pro Strecke ist schon ein Pfund...

Da wird man sich für Core also bald auch was anderes einfallen lassen müssen. Später mal. Aktuell schreitet man mit 200Gbit/Lane brauchbar voran. Erst Ist einer guten Hoffnung bis 800Gbit/Lane und da 8-Lanes Anschlüssen. Die Endstation sind also 6.4 Tbit pro Buchse. Aus der heutigen Sicht jedenfalls.

Da rechnet man Photonics auch schon mit ein. Back-side power kommt ja bei TSMC nicht mit N2P. Erst mit A16. Ethernet Alliance sagt schon seit paar Jahren an, daß zwar bei der Kodierung und Modulation an sich noch weiter sky is the limit, aber andererseits Stromverbrauch pro Lane denen so langsam die Haare vom Kopf frisst.
Slingshot und InfiniBand laufen nun in die gleichen Limits.

Imho wird also >1.6Tbit/Buchse sinnvoll erst mit A16 + GAA + Photonics-Link nutzbar. 2027? Da landen wir mit 1.25Tbit/Lane und 10Tbit Buchse wieder in etwa bei den heutigen 2kW Switches. Erstmal überhaupt 200Gbit/Lane meistern ;)
https://ethernetalliance.org/wp-content/uploads/2024/03/2024-Ethernet-Roadmap-Digital-Version-March-2024.pdf