Intel kondigt jaar na introductie pensioen aan voor Lakefield-cpu's

Intel heeft het einde aangekondigd van de twee Lakefield-socs die het bedrijf vorig jaar introduceerde. Bedrijven kunnen de chips nog tot oktober bestellen. In april volgend jaar stoppen de leveringen. Ook de Comet Lake-U- en Ice Lake-U-serie gaan eruit.

De Lakefield-cpu's waren Intels eerste processors met een big.Little-ontwerp. Deze hadden een enkele, snelle Sunny Cove-core en vier zuinige Tremont-cores. Daarnaast hadden de socs een Gen11-gpu. In de Lakefield-serie bracht Intel een Core i5-L16G7 en een Core i3-L13G4 uit. Beide socs zijn nu uit productie genomen.

Met de Lakefield-chips mikte Intel op de markt voor zuinige apparaten die niet veel processorkracht nodig hebben. De processors bleken onder laptop- en tabletfabrikanten echter niet zo populair. De Lakefield-chips verschenen in apparaten als de Samsung Galaxy Book S en de ThinkPad X1 Fold. Ook had de Microsoft Surface Neo-tablet ermee uitgerust moeten worden. Naar verwachting kondigt Intel dit jaar nog Alder Lake aan, met processors die ook een big.Little-ontwerp krijgen.

Ook Comet Lake-U- en Ice Lake-U-processors gaan uit productie. Het gros van deze processors krijgen dezelfde deadlines als de twee Lakefield-cpu's. Alleen de i7-10810U, -10610U, i5-10310U en Celeron 5205U worden nog iets langer geleverd. Deze chips worden nog tot eind juli geleverd. De Comet Lake- en Ice Lake-cpu's zijn iets ouders dan de Lakefield-cpu's. Intel kondigde deze chips in 2019 aan.

Reacties (38)

[RedPixel]

Heeft dit niet meer te maken met tekorten op fabriekscapaciteit en dat hier minder vraag en dus marge te halen valt?

[xavalon]

Intel heeft genoeg fabrieken, maar in geen één kunnen ze onder de 10nm produceren omdat ze geen EUV procedure ondersteunen (noch EUV lithography machines in productiestraten in gebruik hebben). Daarom kunnen ze nog geen CPUs onder de 10nm maken (7/6/5/4/3nm zoals TSMC en Samsung dat al wel kunnen). Intel investeert de komende jaren veel geld om EUV machines en procedures om dat alsnog te ondersteunen. De eerste EUV productiestraat wordt binnen het jaar verwacht.

Lakefield-cpu's zijn op 10nm geproduceerd, maar de energiezuinigheid wordt bereikt door een lagere 'overall' performance. Dit maakt dat er weinig vraag naar deze chips is.

Apple weet met de M1 een SOC neer te zetten die en hoge performance biedt en energiezuinig is. Ook AMD weet net als Apple prima CPUs te maken, die Apple SOC's naderen in energiezuinigheid maar soms een betere performance weten neer te zetten dan de M1 (vooral de Ryzen 4000 en 5000 series mobiele chips). Als AMD ook overgaat naar 5nm, dan is de strijd weer geheel aan (mijn mening). Ook Intel zal de komende jaren weer aansluiting vinden.

Intel overweegt om Intel i3's op 7 of 5nm te laten produceren door concurrent TSMC. Op de i3's is de meeste margedruk. Daarnaast is dit dan de 'test' of 'referentie' CPU van gemaakt op <10nm. Op basis van learnings rondom energie efficientie in de praktijk kun je je toekomstige CPUs creëren en produceren.

Als je CPUs maakt onder de 5nm moet je ook kijken naar de gebruikte transistors. Intel schakelt bijvoorbeeld om van FinFet- naar GAA-transistors rond 2023 als ze hopen 5nm CPUs te kunnen maken.

[obimk1]

Intel maakt CISC processors

Apple maakt RISC processors, en dat doen ze ruim al 10 jaar.

[Huismus]

Ugh, kunnen we een keertje stoppen met dit soort tegeltjeswijsheid over CPUs? Intel CPUs decoderen al sinds de P6 (1995!) CISC instructies tot meerdere micro-operations, wat de CPU zelf loskoppelt van de ISA. Tuurlijk heeft dit een overhead, maar zo significant is die overhead niet.

Er zijn nog heel wat andere verschillen tussen de ISAs, zoals het memory model, hoe synchronisatie werkt, hoe IO werkt, en al dat heeft niks met RISC vs CISC te maken.

https://www.extremetech.c...mpare-modern-x86-arm-cpus

[obimk1]

Intel CPU's => 10-12 uur op batterij

M1 CPU => 20 - 22 uur op een batterij.

En de eerste RISC processors konden werken op de reststroom aanwezig in de meet apparatuur.

Waarom heeft Intel recentelijk een bedrijf overgekocht die ARM RISC CPU's kan ontwerpen?

Dat was toch "gemakkelijk"?

Maar als voormalige ASML engineer zal ik er compleet langs zitten.

He?

[Huismus]

Als voormalige ASML engineer zou je dan moeten weten dat Apples M1 en Intels Tiger Lake op compleet verschillende nodes gemaakt worden, met andere ideeen achter de microarechitectuur. M1 wordt op een 5nm(-class) node door TSMC gemaakt -- een proces wat ook geoptimaliseerd is voor energie-efficientie. Daarnaast maakt de M1 gebruik van een big+little architectuur om energieverbruik verder te temmen.

Intels 10nm SuperFin proces is best indrukwekkend, en weet tot hoge frequenties redelijk goed te schalen. Maar energiezuinig is het niet. Tel daarbij op dat Intel compleet afhankelijk is van DVFS om het energieverbruik in de perken te houden, en je hebt een chip die gewoon niet zo lang mee kan op een accu. Zelfs AMDs Renoir en Cezanne laptopchips doen het beter, en die zijn gemaakt op TSMCs 7nm process (en ook afhankelijk van DVFS).

[Aaargh!]

Als AMD ook overgaat naar 5nm, dan is de strijd weer geheel aan (mijn mening). Ook Intel zal de komende jaren weer aansluiting vinden.

Zowel Apple als Intel gaan als eerste gebruik maken van TSMC's 3nm process. Dus dat wordt nog interessant.

Waar ik vooral benieuwd naar ben is hoe lang Intel nog blijft aanmodderen met x86, vooral nu Apple heeft laten zien wat je met een RISC ontwerp kan doen is wel pijnlijk duidelijk dat x86 zo langzaamaan een blok aan het been van Intel begint te worden.

[bjp]

dat RISC gedoe van Apple (M1 vermoed ik?) is nog verre van de beste CPU. Het werkt soms redelijk, met specifieke HW (rondom) en SW. Dus eigenlijk enkel in een Apple ding, met redelijk wat beperkingen dus. Nog effe afwachten of de killer CPU uit hun kamp komt met de Pro reeks. Hoe dan ook gaan ze het de hemel in prijzen, dan pas in echte benchmarks zien hoe het zit (niet zo een of andere speciaal gepikte benchmark).

En eigenlijk moet je de credit geven aan ARM, en alle andere ARM cores makers/gebruikers. Die hebben na lang ervoor gezorgd dat er snelle cores zijn en ook degelijke compilers zijn, en ook stilaan meer programma's natief ermee.

Zoals hierboven aangegeven is er geen inherent voordeel van RISC vs. CISC. De instructieset is maar dat, een instructieset. RISC-V zou het ook wel eens kunnen worden op termijn (maar daar zal het nog effe wachten zijn voor je een compleet ecosysteem hebt). AMD toont dat je dus ook heel goeie CPUs kan maken (zelf op x86). Intel heeft dus vooral een process-issue (geen volume 10nm of kleiner). Trouwens x86 heeft al tal van uitbreidingen gekregen...

Het blijft verrassend dat Intel van voortrekker van nieuwe processen, eigenlijk volger geworden is. Straks gaan ze dus bij TSMC aankloppen, mooi.

[Aaargh!]

dat RISC gedoe van Apple (M1 vermoed ik?) is nog verre van de beste CPU. Het werkt soms redelijk, met specifieke HW (rondom) en SW.

Wat een onzin, je kan zo'n ding gewoon testen met standaard benchmarks, niks 'specifieke software'.

En eigenlijk moet je de credit geven aan ARM, en alle andere ARM cores makers/gebruikers. Die hebben na lang ervoor gezorgd dat er snelle cores zijn

Apple staat aan de wieg van ARM, en heeft eind jaren 80 mee ontwikkeld aan de ARM architectuur.

Apple heeft ook z'n eigen ARM cores ontworpen, i.t.t. alle andere grote spelers die gewoon een reference design van ARM gebruiken. Apple gebruikt de ARM instructieset maar niet de cores van ARM.

en ook degelijke compilers zijn

Je weet dat de compiler die Apple (en heel veel anderen) gebruiken voor het overgrote deel door Apple ontwikkeld is ? LLVM is ontwikkeld oor Chris Lattner, welke toen door Apple in dienst genomen is als werknemer bij Apple o.a. de Clang C/C++ compiler en de Swift taal en compiler heeft gemaakt.

Zoals hierboven aangegeven is er geen inherent voordeel van RISC vs. CISC

Onzin. RISC maakt het vanwege de vaste instructie groote mogelijk om makkelijk parallel instructies te decoderen (je weet immers precies waar de volgende instructie staat). Hierdoor kan de M1 een 8-brede instructie decoder gebruiken. Bij x86 kom je niet verder dan 4 instructies tegelijk, met een heel erg complexe decoder, en meer dan dat lijkt niet te lukken (google op "x86 decode bottleneck").

Die parallelle decoder maakt het mogelijk een enorme re-order buffer (ROB) gevuld te houden (maar liefst 630 entries in de M1) wat het weer mogelijk maakt een ontzettend brede CPU core (heel veel execution units) efficient bezig te houden. Hierdoor heeft de M1 een hele hoge IPC (instructions-per-clock), hij kan heel veel werk per kloktik verzetten en dat is een direct gevolg van het feit dat het een RISC processor is.

AMD toont dat je dus ook heel goeie CPUs kan maken (zelf op x86).

Dat is ondanks x86, niet dankzij. En AMD's cores zijn lang niet zo efficient als de M1. Ze vreten meer energie, worden warmer, en draaien op hogere kloksnelheden.

[bjp]

en welke benchmarks heb je dan op de M1? Want behalve een Cinebench (ben ik niets mee) vindt je weinig. Games uiteraard niet, maar er zijn zat andere leuke benchmarks in CPU review wat je nu niet vindt voor de M1 sorry. Geef me anders wat benchmarks...ik vindt ze niet.

vergelijken van aantal instructies zonder wat de instructies doen (RISC = heel minimale) is onzin. Sorry.

De M1 hoge IPC? ja natuurlijk, met minimale instructies dat bijna niets doen. RISC-V doet dat ook. Je hebt wel veel meer instructies nodig om iets gedaan te krijgen (simpele instructie vs. een complexe). A propos, x86 doet dat ook, het decode in micro-ops en dat reorderen en zoveel meer. Dus feitelijk wordt de CISC in RISC vertaald, en dan wordt hetzelfde gedaan... oeps.

Het idee van ARM = efficient... leuk ja omdat het vooral in phone gebruikt wordt. Maar eens je performance opschroeft, worden ze wel warm en verbruiken ze meer. Een intel/AMD kan je ook zonder koeling gebruiken, maar moet je dan gewoon undervolten/underclocken... werkt gewoon. De performance per Watt is niet lineair (je kan niet gewoon een core 2x zo snel klokken en hopen dat het maar 2x het verbruik is...).

En over Chris Lattner... die heeft veel andere dan Apple dingen gedaan. Hij was trouwens niet alleen voor LLVM. En LLVM is van 5 jaar *voor* hij bij Apple werkte. Oeps.

Apple heeft idd in de jaren 80 iets met ARM gedaan... voor een PDA (de Newton)... En eigenlijk hebben ze ook gewoon NXP chips (van ARM M3 en afgeleide) gebruikt later. (zie bijvoorbeeld de motion coprocessor). Weet je nog dat Apple ook gewoon PowerPC gedaan heeft? Da's toch ook RISC, dus zou het perfect efficient moeten zijn? Vraag eens de Playstation3... En zijn ze dan niet daarna terug naar Intel gegaan, wegens performance en efficientie?

Sorry echt sorry, maar je argumenten zijn ook maar wat flauw naar mijn mening.

[Reactie gewijzigd door bjp op 23 juli 2024 18:04]

[Aaargh!]

en welke benchmarks heb je dan op de M1? Want behalve een Cinebench (ben ik niets mee) vindt je weinig.

Gewoon hele standaard benchmarks zoals SPECint. Zie daar de performance van de M1 in vergelijking met een Ryzen 9 5950x met een TDP van 105W en een veel hogere klokfrequentie.

De M1 hoge IPC? ja natuurlijk, met minimale instructies dat bijna niets doen (…) A propos, x86 doet dat ook, het decode in micro-ops en dat reorderen en zoveel meer. Dus feitelijk wordt de CISC in RISC vertaald, en dan wordt hetzelfde gedaan... oeps.

Mooi dat je eerst zegt dat de M1 minder doet per instructie en daarna dat x86 precies hetzelfde werkt..

En CISC wordt niet in RISC vertaald, RISC/CISC gaat over de instructieset, niet over hoe deze geïmplementeerd is, µops zijn niet vergelijkbaar met RISC instructies.

Het gaat hier dus om micro-ops, niet op macro-ops. De decoder decodeert macro-ops naar micro-ops, vanaf dat punt werken de CPU’s op vergelijkbare manier, alleen in het geval van een x86 met een veel kleinere ROB vanwege de decode bottleneck (352 entries in sunny cove). De M1 kan altijd 8 macro-ops tegelijk decoderen, hoeveel µops dit per macro-op zijn ligt natuurlijk aan de instructies, maar dit zullen er inderdaad minder zijn van voor een complexe x86 instructie. De x86 kan echter alleen het meest optimale geval 4 instructies tegelijk decoderen. De pre-decoder werkt met een buffer van 16 bytes en vult deze pas aan als ie helemaal leeg is. De pre-decoder verwerkt maximaal 6 instructies per kloktik. Als er dus 7 instructies in de buffer staan dan kost het 2 tikken om deze alle 7 te verwerken, en aangezien x86 instructies tot 15 bytes lang kunnen zijn kan het ook zijn dat er maar 1 instructie tegelijk in past. De typische decode throughput is dan ook maar 2.5 macro-ops per kloktik (bron: wikichip).

Het klopt dat RISC cpu’s meer macro-ops nodig hebben om hetzelfde te bereiken, maar je kan natuurlijk 1 enorme macro-op in x86 niet direct vergelijken met een 1 kleinere macro-op in ARM. Zo’n complexe macro-op emit natuurlijk meer µops dan 1 simpelere RISC macro-op, maar neemt ook veel meer geheugenruimte (en plek in de decoder buffer) in. Om het meest extreme geval te nemen: een Intel CPU kan maar 1 hele complexe 15-byte instructie per kloktik decoderen, in dezelfde kloktik doet de M1 8 macro-ops. Daarnaast heeft de x86 ook nog verschillende decoders: meerdere decoders voor simpele en 1 voor complexere instructies. Dus als er toevallig 2 complexe instructies in de buffer zitten kan ie die niet tegelijk in 1 kloktik decoderen.

Het complexe design van x86 maakt dus dat de daadwerkelijke throughput (in µops) nogal afhangt van de specifieke code die er gerund wordt. In een RISC processor zal dit veel consistenter zijn.

Waar CISC wel een voordeel heeft (had?), is in de totale grootte van de code. Hoewel de M1 dus meer macro-ops per kloktik kan verwerken, nemen deze wel flink wat meer ruimte in dan vergelijkbare x86 code. 8 ARM macro-ops nemen altijd 32 bytes in. Een RISC processor is dus meer afhankelijk van geheugenbandbreedte dan een CISC processor. Dit was vooral vroegen een issue omdat cache geheugen erg duur was, tegenwoordig is het veel minder een probleem: RISC processoren zijn nu voorzien van vrij grote L1/L2 caches.

Een intel/AMD kan je ook zonder koeling gebruiken, maar moet je dan gewoon undervolten/underclocken... werkt gewoon.

Alleen performed een M1 met nauwelijks koeling en stroomverbruik bijna net zo goed als de stroom zuipende heethoofdjes van Intel en AMD. Ja, je kan een Intel of AMD CPU underclocken en undervolten, en intel heeft ook een aantal van dat soort SKU’s. Het hele artikel waar deze discussie mee begon gaat over nu net over zo’n CPU van Intel, waar ze na een jaar al mee stoppen omdat niemand zit te wachten op zo’n slecht presterende CPU.

En over Chris Lattner... die heeft veel andere dan Apple dingen gedaan. Hij was trouwens niet alleen voor LLVM. En LLVM is van 5 jaar *voor* hij bij Apple werkte. Oeps.

Hij begon aan LLVM voordat ie bij Apple kwam, inderdaad, maar LLVM was toen meer een research projectje en geen volledige compiler. Hij heeft de Clang C/C++ compiler (op basis van LLVM) gebouwd toen ie bij Apple werkte.

Weet je nog dat Apple ook gewoon PowerPC gedaan heeft? Da's toch ook RISC, dus zou het perfect efficient moeten zijn?

PowerPC was van IBM, en is een wat uitgeklede versie van de POWER architectuur, Met die architectuur is op zich niks mis, maar IBM was echter vooral geïnteresseerd in het gebruik van POWER voor zware servers. Deze architectuur is dus met een heel ander doel ontwikkeld, en deze terugschalen naar een desktop/laptop CPU werkte gewoon niet.

Een RISC processor hoeft niet per see super efficient te zijn, Een van de oorspronkelijke ideeen achter RISC was juist dat door het simpel maken van de CPU (ten koste van performance) je de kloksnelheid enorm kan verhogen en zo de lagere performance compenseren.

Again, RISC of CISC zegt niets over hoe een CPU geïmplementeerd is, het is maar een deel van het plaatje. RISC maakt hele efficiënte superscalar CPUs zoals de M1 mogelijk, maar dat wil niet zeggen dat je geen andere kanten op kan met RISC.

Vraag eens de Playstation3... En zijn ze dan niet daarna terug naar Intel gegaan, wegens performance en efficientie?

Dat heeft echt helemaal niets met dit verhaal te maken. Ja, er zat toevallig ook een PPC core in de Cell processor (omdat het ding nu eenmaal van IBM was dus logisch dat ze hun eigen cores gebruikten), maar dat was niet waar de rekenkracht van de Cell vandaan moest komen.

[bjp]

ok dus de architectuur telt idd eerder dan de RISC/CISC discussie Daar zijn we het over eens.

Correct met je RAM - iets grotere code, geen groot issue vandaag de dag.

Laat niet staat dat ik zeker respect heb voor de M1 chip (en alle andere ARM). Concurrentie is zeker fijn, en laat de beste winnen.

Ok nu hebben we Cinebench en SPECint resultaten. Bij de laatste grote CPU review van T.net hadden ze ook andere zaken: reviews: AMD Ryzen 5 5600X, Ryzen 7 5800X, Ryzen 9 5900X en 5950X

Photoshop, audio/video testen, helemaal andere compute/rendering resultaten, encryptie, webbrowser en compression. En uiteraard een massa games, maar daar zullen we de M1 niet voor vergelijken vermoed ik (hoewel, rosetta2?).

[Aaargh!]

ok dus de architectuur telt idd eerder dan de RISC/CISC discussie Daar zijn we het over eens.

RISC/CISC is idd maar een deel van het plaatje, maar het is wel een keuze die gevolgen heeft op de rest van de implementatie, o.a. de veel ingewikkeldere decoder die nodig is bij CISC en de gevolgen daarvan.

Een andere manier om tegen het RISC/CISC verschil aan te kijken is CISC zien als een vorm van compressie van code. In plaats van vaste instructie grootte worden veel gebruikte/simpele instructies in weinig bytes gecodeerd en minder gebruikte/complexere instructies als meer bytes, analoog aan wat datacompressie doet met veel/weinig voorkomende stukken data. Als je er zo naar kijkt is duidelijk dat de ‘decompressie’ van de instructies complexiteit in de CPU toevoegt.

Vroeger was dit een goede trade-off, kleinere code en minder afhankelijkheid van geheugenbandbreedte, waren dingen die de performance ten goede kwamen. Tegenwoordig is die trade-off een stuk minder gunstig richting CISC.

Photoshop, audio/video testen, helemaal andere compute/rendering resultaten, encryptie, webbrowser en compression.

Met dat soort testen test je meer dan puur de CPU cores, ook interessant maar dat geeft een vertekend beeld. De M1 SoC heeft nog wat andere verschillende met traditionele CPUs die ‘m een performance voordeel geven, b.v. het gebruik van unified memory, de Neural Engine, etc.

[knirfie244]

Procédés vergelijken op naamgeving heeft geen enkel nut. Er is geen enkel onderdeel in TSMC's 5nm proces dat daadwerkelijk 5nm is. Intel z'n 10nm heeft ongeveer vergelijkbare afmetingen als de 7nm+ (EUV) van TSMC, wat best knap is gezien Intel nog geen EUV gebruikt in productie.
Hier ligt misschien ook het probleem dat Intel nu heeft, net als bij de introductie van DUV probeert Intel het onderste uit de kan te persen met de voorgaande lithografie techniek, en waarschijnlijk hebben ze met hun 10nm process meer geprobeerd te realiseren dan mogelijk is met DUV.

Intel investeert de komende jaren veel geld om EUV machines en procedures om dat alsnog te ondersteunen.

Dat geld is al lang geïnvesteerd: Intel heeft in 2014 4 miljard in ASML geïnvesteerd voor de ontwikkeling van EUV. De eerste EUV apparaten heeft Intel rond 2019 al ontvangen. Er wordt al jaren gewerkt aan 7nm. En de EUV machines die nodig zijn voor productie staan natuurlijk al lang in Fab 42.

De aankondiging van Maart dit jaar, om $20 miljard extra te investeren in Fab 42, is voor 2 additionele EUV productiestraten. Deze zullen naar verwachting pas in 2024 klaar zijn (en waarschijnlijk gebruikt gaan worden voor 5nm).

Overigens kunnen TSMC en Samsung ook nog geen "4nm" en "3nm" produceren.

[Reactie gewijzigd door knirfie244 op 23 juli 2024 18:04]

[kidde]

Intel z'n 10nm heeft ongeveer vergelijkbare afmetingen als de 7nm+ (EUV) van TSMC,

Niet bepaald, dat gold alleen voor het gefaalde Cannon Lake 10nm-procedé uit 2018.

TSMC N7 (DUV, multi patterning) had een metal poly pitch (MPP) van 40nm.

Intel Cannon Lake 10nm had een MPP van 36nm, had vijf- tot zesvoudige belichting nodig (tot dan toe was 3- tot 4-voudig de max, oa Samsung LELELE), had ook nog eens problemen met de Kobalt en met de Contact over active gate.

De onderste laag met metaal verbindingen, M1, kreeg Intel niet werkend. Die werd daarom opgesplitst in 2 lagen, als work-around. Daarom was een redesign nodig. Het schijnt dat de rechtheid van de verbindingen, zogenaamde Line Edge Roughness, zeer slecht was. Daarom was de yield in het begin ~9%, dus 91% van wat gemaakt was kon gelijk de prullenbak in als DOA.

Intel publiceerde de MPP voor Cannon Lake.

Daarna kwam TSMC met N7+ EUV (single patterning): Die had 36nm MPP en werkte. Maar daarvoor was een complete redesigns nodig van de chip, dus Huawei bleef de enige klant.

Intel kwam met Ice Lake, hetgeen natuurlijk gewoon 10nm+ had moeten heten. Maar Intel wilde het gefaalde Cannon Lake laten vergeten. En de nieuwe MPP wilden ze niet publiceren; maar die is naar verluidt 40/44nm, en daarmee dus slechter dan TSMC N7 DUV, en al helemaal slechter dan TSMC N7+ (EUV).

TSMC kwam nog met N7P (DUV), een zeer kleine verbetering.

Intel kwam daarna weer met Tiger Lake op de proppen en noemde het 10nm+ wat natuurlijk gewoon een je reinste leugen is, want dat was Ice Lake immers al als opvolger van Cannon Lake. Maar die moesten we van Intel dus vergeten.

Naar ik heb gelezen is de Line Edge Roughness, LER, zelfs voor Tiger Lake niet fatsoenlijk opgelost tov Cannon Lake. Dus een deel van dezelfde problemen als in 2018 heeft Intel nu nog.

Slechte LER kan zorgen voor onbedoelde kortsluiting. Hoe hoger het oppervlakte hoe groter die kans. Dan heb je dus een slechte yield op grote chips, dat is enorm duur om ze te maken.

Dat moet de reden zijn dat er nog steeds geen 10nm server chips zijn bij Intel; en de desktop nog maar mondjesmaat: Er wordt nog steeds enorm veel 10nm defect geproduceerd en gelijk in de prullenbak gesmeten, dus dat proces maakt gewoon geen winst.

Kleine prullen zoals Lakefield kan je dan wel maken, maar dat is dan erg duur vergeleken met de concurrentie waar de yield _wel_ op orde is. Aan de onderkant van de markt telt iedere cent, dus dan zijn er geen klanten.

[Reactie gewijzigd door kidde op 23 juli 2024 18:04]

[CH4OS]

Intel heeft eigen fab's, dus ik denk niet dat fabriekscapaciteit een issue is.

[SED]

Juist wel. Je zet je capaciteit in op de productlijnen met het hoogste winstpercentage. Weinig populaire chips beperken die productie capaciteit.

[foppe-jan]

lakefieild chips zijn zo klein als ze worden -- een 7700k was 37x37mm, terwijl een lakefield chip 12x12mm was, dus 9x kleiner. Dit zal niet de reden zijn -- waarschijnlijk was het vooral a. dat ze niet goed werken ivm eerste generatie, en b., slecht verkopen, vanwege de relatief slechte prestaties.

[n4m3l355]

Dit is toch wel ietwat erg kort door de bocht. De reden om wel of niet te produceren hangt van een tal van punten af. Jou opmerking is enkel sprake van wanneer Intel overal op volle productie draait en dus capaciteits problemen heeft. Dan zou je kunnen kiezen om een batch te stoppen maar dat is enkel het geval wanneer je dus capaciteitsproblemen hebt, iets waar bij Intel op dit moment denkelijk geen sprake van is (dit zou je terug kunnen vinden in de annual reports).

Dus indien capaciteits problemen geen probleem is, is het eerder een economische keuze dat het zich gewoon niet loont om te produceren of dat Intel verwacht dat ze klanten iets anders kunnen verkopen waar ze een betere marge op maken.

Uiteindelijk is het allemaal koffie dik kijken waarom Intel dit doet.

[SED]

Er is wereldwijd een chip tekort. Productie van populaire chips geniet dus nu de voorkeur.

[n4m3l355]

Een chip tekort wilt nog niet zeggen specifiek voor Intel of specifiek die productielijnen. Het is niet alsof Intel een pers heeft staan die diverse chips .aakt. deze zijn wereldwijd, verschillende straten met verschillende opstellingen.

[SED]

Zeker, dus nogmaals richt je de productie op de veelgevraagde lijnen..
Of de nu afgebouwde lijn daarvoor geschikt is kan zelfs onbelangrijk zijn. Je hebt ook personeel en logistiek nodig.
Produceren is meer dan een chip lijn.

[bjp]

de chiptekorten zijn vooral in de auto/medische industrie, niet bij Intel dus. Denk dan aan Renesas en zo bijvoorbeeld... TSMC kan niet volgen met de allerlaatste nodes (en dan voor smartphones en PS5/Xbox, maar ook voor Nvidia).

Er zijn tal van designs voor tal van fabs in tal van technologieën. Zover ik weet maakt Intel weinig auto-chips, medische-chips of PS5/Xbox/Nvidia chips.

[kidde]

10nm capa is wel degelijk een probleem: vziw draaien 2,5 fabs 10nm.

Met lage yield gaat vrij veel direct de prullenbak in; als je 50% defect weggooit heb je 2x zoveel capa nodig als bij 14nm++++ voor hetzelfde aantal wafers.

Daarom maakte Intel jaren lang alleen maar laptop chipjes op 10nm, en dus de Lakefield-prullen.

Maar nu wordt er voortaan ook desktop spul gemaakt op 10nm, en in de kwartaal cijfers zie je al posten opgenomen voor ongekwalificeerde 10nm server-voorraad. Dus ook 10nm server meuk wordt al geproduceerd; vaak als de yield slecht is wordt dat opgehamsterd om bij de intro een vooraad te hebben en de schijn te kunnen wekken dat de productie goed loopt.

[Dennism]

Ook Intel kampt al tijden (jaren) met leveringsproblemen vanwege capaciteitstekorten in de eigen fabs, dus ik verwacht zeker dat dit meespeelt. Al zal dat voor Lakefield, dat een niche product is, niet heel veel uitmaken, want veel capaciteit zal daar sowieso niet voor gebruikt zijn.

Maar ook Intel (net als AMD) zal momenteel de producten met de hoogste marges, waar mogelijk (binnen de contracten die ze hebben met hun afnemers) uiteraard meer prioriteit geven.

[Astennu]

Ik denk dat er vooral weinig interesse was en dat ze relatief duur waren om te maken door het complexe productie proces met het stapelen.

[Pinkys Brain]

Ik snap dat big little gedoe niet voor laptops of zelfs voor tablets. Een moderne grote core op de laagste stand waar hij nog werk kan doen gaat dagen mee op de accu, superlichte workloads zijn gewoonweg nooit de beperkende factor voor accuduur. Dus waarom zou je ruimte voor een extra grote core opgeven voor wat nutteloze kleine cores? Alles wat de kleine cores kunnen kan de grote ook tussendoor even doen op zijn sloffen, met irrelevante hoeveelheden energie.

[dmantione]

Slapend silicium is de toekomst!

Wat we de laatste jaren zien bij procestechniek is dat de transistordichtheid wel toeneemt, maar het energieverbruik van een transistor maar beperkt afneemt. Dat heeft onder andere te maken met lekstromen en dat de gate van een transistor niet kleiner meer gemaakt kan worden. Anders gezegd, de Wet van Moore is geschiedenis.

Dat betekent dat je weliswaar meer transistoren kwijt kunt, maar ze niet optimaal kunt benutten zonder dat je chip smelt. Iets wat je er wel mee kunt doen is gespecialiseerde hardware bouwen die alleen geactiveerd wordt indien nodig. Een vroeg voorbeeld daarvan was dat chips hardwarematige videodecoding kregen. Processoren kunnen krachtig genoeg gemaakt worden om video in software te decoderen, dus je kunt je afvragen waarom je dat silicium niet aan meer kernen besteedt. Het antwoord is dat de videodecoder normaal slaapt en geen stroom trekt, terwijl als hij wel gebruikt wordt, de processorkernen kunnen slapen. Resultaat: Langer op je batterij video kunnen kijken.

Big.little is een volgende stap: Meerdere typen kernen aan boord en zet enkel de kernen in die op dat moment het meest geschikt zijn. De helft van je processor zal wellicht altijd aan het slapen zijn, maar het resultaat is dat je toch meer rekenkracht en/of minder hitte hebt.

[The Zep Man]

Met de Lakefield-chips mikte Intel op de markt voor zuinige apparaten die niet veel processorkracht nodig hebben. De processors bleken onder laptop- en tabletfabrikanten echter niet zo populair.

Ik denk dat Intel de adem van ARM in de nek voelt. Minder behoefte om per se x86 code (native) te draaien is een directe bedreiging voor Intel.

Recentelijk heb ik wat gespeeld met een notebook die een Rockchip RK3399 SoC bevat. Eigenlijk is zoiets voor dagelijks (kantoor)werk voldoende, en dat betreft een ARM SoC van vijf jaar oud. Met nieuwere ARM SoC's zal dit waarschijnlijk nog beter zijn.

[Reactie gewijzigd door The Zep Man op 23 juli 2024 18:04]

[Rob Coops]

Inderdaad, intel heeft de markt voor lower end laptops eigenlijk al verloren de verkopers zijn nog niet zo ver men heeft langdurige contracten met intel en nog niet direct de mogelijkheid om volledig te vertrouwen op de leveranciers van de ARM chips. Dit is de reden dat er nog niet heel erg veel van dit soort laptops op de markt zijn op dit moment.

Maar iedereen die er een tijdje mee werkt merkt al snel dat je echt geen intel nodig hebt om normaal kantoor werk te doen zeker de nieuwere chips die ontworpen zijn voor dit soort taken uit te voeren zijn gewoon meer dan voldoende voor de gemiddelde kantoor laaf. En Intel weet dat zelf natuurlijk ook al lang. Men probeert van Intel kant om de boot af te houden en bedrijven zo als Samsung, HP, Lenovo etc er van te overtuigen dat ze voor al geen ARM chips willen gebruiken maar het lijkt er niet op dat dat echt zal werken. Immers als ik een zelfde laptop ervaring kan maken met een ARM chip waarbij de batterij een stuk langer mee gaat dan met een intel chip en er voor de eindgebruiker geen merkbaar verschil is waarom zou ik dan als fabrikant niet voor ARM kiezen.

Het zal een tijdje duren voor bedrijven hier ook aan mee doen maar met dat ze dat doen zal Intel heel erg snel heel erg veel markt aandeel in de low end laptop markt verliezen (waarschijnlijk ook de desktop/thin client markt die nu ook al vaak mobiele chips gebruiken) simpel weg omdat Intel een inferieur product heeft.

Natuurlijk zal intel proberen met hun x86 producten te concurreren maar dat gaat niet lukken simpel weg omdat de CISC (x86) architectuur niet geschikt is voor een low power chip, in ieder geval niet zo als de RISC architectuur dat kan.
En ja dat is een fundamenteel architectuur probleem. Dat is ook de reden waarom al sinds mensen heugenis de RISC architectuur gezien wordt als superieur aan de CISC architectuur. Het probleem met RISC is dat het geoptimaliseerd is voor de meest gebruikte instructies en bepaalde andere instructies helemaal niet heeft en dus daar veel langzamer is. Intel had een voorsprong in de markt en kon door de chips steeds sneller te maken en steeds meer speciaal voor bepaalde taken geoptimaliseerde instructies toe te voegen (MMX, SSE, etc) de RISC architectuur voor blijven. Maar in middels is het hogere klok verhaal al weer jaren achterhaald en nog meer nieuwe instructies toevoegen is ook niet echt nuttig meer de instructie set is al zo complex dat nog meer instructies niet echt veel gaat doen anders dan een hele specifieke niece helpen.
Ik ben dan ook bang dat Intel uiteindelijk zal verliezen tenzij ze echt de x86 wereld achter zich durven laten en alleen voor legacy producten de instructie set nog een jaar of 20 a 30 in leven te houden. Maar ik geloof daar niet helemaal in, misschien dat de nieuwe CEO wel voldoende durf heeft dit te doen maar of hij dat ook echt kan weet ik niet zo zeker.

[g4wx3]

als intel fpga integreerd, kan je on-the-fly instructies toevoegen. Dat zal de volgende doorbraak zijn, na alle "DSP"-geinspireerde-technieken (aes,neural, AI, enzoverder)

Technische achtergrond
Veelvoorkomende bewerkingen in de signaalbewerking zijn FIR en IIR-filters, alsook FFT-berekeningen. Deze kunnen door deze processor zeer snel uitgevoerd worden dankzij een MAC-unit (multiply accumulate). Deze maakt het mogelijk om een vermenigvuldiging en optelling in 1 klokcyclus uit te voeren.

Waar gewone processors met de Von Neumann-architectuur het programma en data in hetzelfde geheugen opslaan, gebruikt de DSP de Harvard-architectuur. Dit wil zeggen dat het geheugen opgesplitst wordt naargelang de functie van de gegevens. Dit is zeer belangrijk bij het verwerken van een continue signaalstroom, omdat de gegevens in verschillende cache-geheugens van de processor kunnen worden opgeslagen. Een programmasprong zal dus niet de volledige cache leegmaken. Bij een traditionele processor moeten hierdoor de data steeds terug in het cache geladen worden.

[xavalon]

Hoe verklaar je dan de 7nm AMD 5800U CPU van 15 watt TDP versus de Apple M1 5nm van 15,1 Watt TDP.

In single core wint M1 nipt, in multicore is de AMD stukken sneller. En dat voor een X86/64 architectuur chip.

[Rob Coops]

Stukken sneller maar niet op een zelfde OS... en zo als vele mensen al hebben gezien is de M1 chip van Apple zeer geoptimaliseerd voor de meest gebruikte apps op MacOS. En laat dat nu niet een benchmark tool zijn.

Het is dan ook niet zo moeilijk uit te leggen dat in een synthetische benchmark er weinig verschil te merken is. Als je daar in tegen de het zelfde OS en de zelfde applicatie de zelfde taak uit zou laten voeren dan zul je zien dat de M1 chip dat werk een stuk efficiënter voor elkaar krijgt zonder dat het werk merkbaar langzamer gaat.
Het grote probleem met benchmarks is dat ze hele specifieke dingen testen en zo als de voorkeuren van Intel voor bepaalde benchmarks en AMD voor andere benchmarks al laat zien is het resultaat van een benchmark niet veel meer dan een indicatie of een chip in een zeer specifieke set taken beter zal presteren dan een andere chip. Nvidia kiest ook bepaalde benchmarks uit en laat andere achterwegen net als Apple dat doet en Samsung ook liever een specifieke benchmark gebruikt om hun chips te vergelijken met die van de concurrentie.

Maar in de echte wereld is het veel meer van belang dat de tools en apps die iemand steeds maar weer gebruikt goed werken en als het even kan zo min mogelijk energie gebruiken terwijl ze zo goed werken. En dat is toch echt iets waar de M1 chip laat zien dat RISC in het voordeel is.
Als je je bedenkt dat het grootste verschil tussen CISC en RISC is dat de eerste alles kan en zeer veel instructie opties heeft en de tweede veel meer gespecialiseerd is dan zie je al snel waarom RISC in het voordeel is. Het is het zelfde concept als een topsporter die zich specialiseert in hardlopen, die zal niet ook op top niveau kogelstoten, hoogspringen en handballen. Dat heeft er alles mee te maken dat specialisatie nu eenmaal de mogelijkheid bied om meer te optimaliseren en dus beter te presteren dat is precies waarom RISC die vergelijking altijd zal winnen zolang de nodige instructies maar relatief beperkt zijn.
En wat blijkt in de echte wereld zijn de meeste gebruikers een stuk minder gevarieerd dan Intel's CISC dominantie je zou doen geloven. Sterker nog Apple is er van overtuigt dat zij zeker omdat ze de gehele hardware en OS stack in handen hebben net zo als met hun telefoons en tablets hun laptops en zelfs workstations een stuk zuiniger kunnen maken dan de concurrentie zonder dat ze wat prestaties betreft onder hoeven te doen voor de concurrentie.

Nu kan Apple er natuurlijk helemaal naast zitten en de vele onderzoekers en professoren die al jaren roepen dat de CISC dominantie voor personal computer werk onzinnig is ook iets belangrijks gemist hebben maar ik gok er op zeker gezien de successen van Apple in de telefoon en tablet markt dat ze het bij het juiste eind hebben en dat CISC voor de personal computer wereld echt zijn langste tijd gehad heeft.

[Pinkys Brain]

Als je Intel/AMD net zo hard afknijpt in performance dan is ARM buiten M1 niet zuiniger, en dat heeft meer te maken met het uitkopen van EUV capaciteit dan ARM.

[Rob Coops]

Maar vergeet niet dat ARM zich in een x86 wereld staande moet houden en de meeste (zo niet alle) applicaties/compilers niet geschreven zijn voor de ARM chipset. Kijk naar het verschil tussen de gcc compiler van nu en die van 10 jaar geleden zelfs als je de compiler voor de zelfde instructie set de zelfde code lat compileren zul je merken dat de moderne gcc compiler een stuk verder geoptimaliseerde code af zal leveren dan de zelfde compiler 10 jaar geleden deed. En dat je dus op de zelfde CPU betere performance zult zien met de nieuwe compiler in verhouding tot de oude compiler.

De ARM compiler is nog maar heel erg jong er zijn nog maar zeer weinig mensen (procentueel gezien) die ontwikkelen voor ARM desktop/server processoren. De OS'en die je er op kunt draaien zijn ook zeker niet geschreven met de ARM chips in het achterhoofd en de x86 code is dus simpel weg door de compiler gecompileerd voor de ARM chip. Dit terwijl er bijvoorbeeld in de Linux kernel tot op de dag van vandaag code te vinden is die speciaal voor de itanium processor architectuur bedoeld is, of juist voor de 486 en beter etc...
Als in al die stukjes waar het OS is geoptimaliseerd voor bepaalde processoren een zelfde stukje code zou zijn voor de ARM chips dan zou je een veel groter verschil merken.
Als je daar dan ook nog eens een extra 10 a 20 jaar aan compiler optimalisatie aan toe zou voegen dan kun ga je het verschil helemaal merken.

Dit is waarom M1 zo'n speciale status lijkt te hebben, Apple heeft heel bewust de keuze gemaakt om hun OS en daarmee een zeer groot deel van de gebruikte calls gemaakt door om het even welke app die er op het OS draait te optimaliseren voor hun nieuwe ARM processor.
Om deze reden lijk de M1 zo'n speciale processor in werkelijkheid is de processor niet heel erg veel anders dan de rest van de ARM chip bakkers zouden kunnen maken. Maar het OS, de compiler en daarmee zeer veel van de meest gebruikte system calls zijn geoptimaliseerd voor de ARM architectuur (en deze specifieke ARM chip is geoptimaliseerd voor dit OS natuurlijk). Het resultaat is een heel erg snelle combinatie waarbij zo wel de chip als de compiler en het OS allemaal worden geoptimaliseerd om zo efficient en snel mogelijk te presteren.

Het is al sinds de jaren '70 van de vorige eeuw bewezen dat CISC simpel weg nooit zo efficient kan zijn als RISC omdat de architectuur een ander doel na streeft. Dat heeft helemaal niets met afknijpen of magische processoren te maken maar alles met de architectuur en de keuzes die daar zijn gemaakt. RISC is hoe dan ook sneller/efficienter maar alleen in de diepte niet in de breedte. CISC is hoe dan ook beter in de breedte maar kan onmogelijk de snelheid en of efficientie van een RISC processor bieden door dat het een veel bredere instructie set bied.

Dit heeft helemaal niets te maken met EUV, process nodes of welke andere techniek dan ook. Zo als ik hier boven ook zei, zie het als een topsporter. RISC is gespecialiseerd in een sport, waar CISC meer een all-rounder is. RISC zal in die ene specialisatie hoe dan ook beter presteren dan CISC maar CISC zal als het op een triatlon aankomt altijd winnen van RISC.
Als je de twee zo vergelijkt zie je waarom ik met zo veel overtuiging durf te roepen dat RISC hoe dan ook efficienter zal zijn dan CISC. En omdat de hoeveelheid instructies die nodig blijken voor een gemiddelde desktop gebruiker nu eenmaal heel erg veel kleiner is dan de instructies die de CISC (x86) instructie set bied zal CISC de strijd gaan verliezen.

[xavalon]

Dit is waarom M1 zo'n speciale status lijkt te hebben, Apple heeft heel bewust de keuze gemaakt om hun OS en daarmee een zeer groot deel van de gebruikte calls gemaakt door om het even welke app die er op het OS draait te optimaliseren voor hun nieuwe ARM processor.

Spot-on. Ze hebben heel veel geïntegreerd in één SOC, en dat hebben ze fantastisch gedaan. Maar ze hebben natuurlijk speciale use cases gekozen waarin ze willen excelleren. Bijvoorbeeld het renderen van video's.

Om deze reden lijk de M1 zo'n speciale processor in werkelijkheid is de processor niet heel erg veel anders dan de rest van de ARM chip bakkers zouden kunnen maken.

Hier ligt denk ik ook de reden waarom ARM nog lang niet dominant in de laptop/PC gaat zijn. Apple verkoopt zijn M1 niet aan fabrikanten als Dell en HP. De wereld, het zakenleven, koopt in de regel geen dure laptops. Qualcomm claimt een M1 competitor te kunnen maken, maar die is er voorlopig nog niet. En dan begint het pas bij een eerste 'test' modelletje om te kijken hoe het werkt. Microsoft moet dan meedoen met deze nieuwe Qualcomm ARM CPU te ondersteunen in Windows voor ARM. Volgende probleem is dat er nauwelijks voor ARM geoptimaliseerde software is; zelfs de eigen MS Office suit is beperkt in functionaliteit. Het zal nog wel jaren wachten zijn voordat je de perfecte laptop met ARM en Windows hebt. Denk ook aan alle software die nog naar ARM moet komen waarmee je bedrijfslaptop van is voorzien. Dat is toch iets meer dan effe opnieuw compileren omdat je moet werken met andere securityonderdelen en niet zo werkt als bij Intel en AMD. Ook loopt ARM volgens mij achter als het gaat om virtualisatie (en nee gaat niet omdat je Parallels kunt draaien op je M1) maar gevirtualiseerde I/O e.d. Windows zie je meer en meer gebruik maken van virtualisatie om de security te vergroten. Intussen zitten Intel niet stil. AMD laat eigenlijk zien dat het best in staat is om een M1 competitor te ontwikkelen, en ik denk dat Intel dat ook wel kan binnen een paar jaar als zij naar 7/5/3nm weten te komen in hun eigen fabrieken.

[MdBruin]

Dit verklaard misschien ook waarom de Intel Nuc gen 11 zo slecht leverbaar is, bij de meeste staat een leveringsverwachting van 10+ weken. Ik ga maar eens naar wat anders kijken, met dit bericht verwacht ik dat ze nog slechter leverbaar worden.

[Tweddy]

Verkooppensioen. Niet pensioen in de zin dat ze niet meer zullen werken.