Intel lijkt Ice Lake-chips van 28W exclusief aan Apple te leveren

Intel heeft de eerder aangekondigde Core i7-1068G7, een mobiele Ice Lake-processor van 28W, van zijn site verwijderd. Tegelijk heeft de fabrikant twee andere 28W-processors van de Ice Lake-generatie toegevoegd. Het lijkt om exclusieve MacBook Pro-chips te gaan.

Intel kondigde vorig jaar de op 10nm geproduceerde Ice Lake-generatie laptopprocessors aan en de krachtigste chip van de line-up was de Core i7-1068G7. In tegenstelling tot de overige Ice Lake U-modellen had die processor geen configureerbare tdp van 15 tot 25W, maar een tdp van 28W. Die processor verscheen vervolgens in geen enkele laptop en is nu geheel verdwenen uit Intels productdatabase.

Intel heeft wel twee nieuwe processors aan die database toegevoegd. Het gaat om een Core i5 en een Core i7 met een tdp van 28W, voorzien van een N-aanduiding in de naam naast de G7-aanduiding, die aangeeft dat de chips een Iris Plus-gpu met 64 execution units hebben. De Core i7 is identiek aan de Core i7-1068G7; de enige verandering is de N in de naam.

De Core i5-1038NG7 en de Core i7-1068NG7 zijn de processors van de duurdere nieuwe MacBook Pro 13-modellen. De N-aanduiding lijkt aan te geven dat het om processors voor Apple gaat. Ook de MacBook Air van 2020 bevat N-varianten van bestaande chips: de Intel Core i3-1000NG4, Core i5-1030NG7 en Core i7-1060NG7.

Het is de vraag of andere fabrikanten nog over Ice Lake-processors van 28W kunnen gaan beschikken. Halverwege dit jaar verschijnen de Tiger Lake-opvolgers, die op een verbeterd 10nm-procedé zijn gemaakt en een krachtigere Xe-gpu hebben.

Intel Ice Lake U-processors
Processor	Cores / threads	Tdp	Kloksnelh.	Turbo (1 core)	Turbo (all core)	Cache	Gpu / eu's	Gpu-snelh.
Core i7-1068G7	4/8	28W	2,3GHz	4,1GHz	3,6GHz	8MB	Iris Plus / 64	1,10GHz
Core i7-1068NG7	4/8	28W	2,3GHz	4,1GHz	3,6GHz	8MB	Iris Plus / 64	1,10GHz
Core i7-1065G7	4/8	15/25W	1,3GHz	3,9GHz	3,5GHz	8MB	Iris Plus / 64	1,10GHz
Core i5-1038NG7	4/8	28W	2GHz	3,8GHz	3,3GHz	6MB	Iris Plus / 64	1,05GHz
Core i5-1035G7	4/8	15/25W	1,2GHz	3,7GHz	3,3GHz	6MB	Iris Plus / 64	1,05GHz
Core i5-1035G4	4/8	15/25W	1,1GHz	3,7GHz	3,3GHz	6MB	Iris Plus / 48	1,05GHz
Core i5-1035G1	4/8	15/25W	1,0GHz	3,6GHz	3,3GHz	6MB	UHD / 32	1,05GHz
Core i3-1005G1	2/4	15/25W	1,2GHz	3,4GHz	3,4GHz	4MB	UHD / 32	0,90GHz

Reacties (67)

[lastlong]

Ben benieuwd naar de tiger lake macbooks, zou graag een nieuwe 16 inch kopen. De huidige 16 inch pro's hebben 2 jaar oude cpus

[Donderr]

De huidige 16 inch MaceBook Pro bevat een Intel processor van de 9de generatie die in Q2 2019 gelanceerd is. Niet 2 maar 1 jaar oud dus

[winwiz]

Met de weinige vooruitgang die Intel de laatste jaren heeft gemaakt zal het verschil tussen een huidige en 2 jaar oude CPU niet zo heel spannend zijn. Ik denk dat de komende 2 jaar veel spannender zullen zijn.

[Black_Diamond768]

20a30% performance increase is niet nix te noemen.
singlecore benchmarks laten ze de moderne amd's achter zich.

even afwachten is de boodschap

[Twanekel]

Uhmmmm, de huidige generatie Ryzen 4000 in laptops gaat in single core gemakkelijk voorbij die 2 jaar oude cpu's

[bbob]

Ik mag idd hopen dat een ryzen van nu sneller is dan een 2 jaar oude intel. Zou dat niet zo zijn zouden ze een achterstand hebben.

[Twanekel]

Heb je de reviews gezien van Ryzen 4000? Een 35 watt Ryzen CPU presteerd op multi core beter tegenover een 95 watt 10e generatie Intel CPU. Single core word hier dan wel een kleine winst gepakt op applicaties die slechts voor korte duur in de boost zitten, want intels boost houd ook niet zo lang vast als die van AMD.

[Hackus]

Heb je de reviews gezien van Ryzen 4000? Een 35 watt Ryzen CPU presteerd op multi core beter tegenover een 95 watt 10e generatie Intel CPU. Single core word hier dan wel een kleine winst gepakt op applicaties die slechts voor korte duur in de boost zitten, want intels boost houd ook niet zo lang vast als die van AMD.

alleen gaat die wel degelijk over de 35W heen, of het moet afgeknepen zijn. maar dan is de clockspeed ook erg tam

[DLeijen]

Achter zich? Als ik de benchmarks hier bekijk scoort intel in de meest gunstige test 6% hoger dan de AMD in een aanzienlijke goedkopere laptop:
reviews: AMD Ryzen 4000-processors - Eerste tests met Ryzen 4800H en 4900HS

Bijna alle andere tests scoren de AMDs beter met een lager stroomverbruik.

[Madshark]

20a30% performance increase is niet nix te noemen

Wellicht in de meest synthetische test onder de meest optimale omstandigheden door een biased benchmaker wellicht.
Er is echt geen 20% laat staan 30% performance winst geboekt tussen Kaby Lake en Coffee Lake.

[xantilyst1]

Intel wil Apple misschien wel bevriend houden hierdoor vanwege komende ARM processoren van Apple

[Knijpoog]

ARM? wat dacht je van AMD. Als Ryzen Zen 3 op de zelfde voet verder gaat als Zen 2 kun er gewoon niet om heen.

De Apple ARM chips zijn voorlopig nog niet goed genoeg voor professioneel grafisch werk en video edditing.

[Aaargh!]

De ARM chips die Apple nu heeft (iig voor zover publiek bekend) zijn ontworpen voor gebruik in een mobiel met bijhorend stroomverbruik en warmteontwikkeling, en die komen al aardig in de buurt van Intel”s x86 chips. Een chip ontworpen voor in een laptop of desktop met actieve koeling zal voldoende snel zijn.

Het probleem zit ‘m niet zo zeer in de CPU, maar alles er omheen wat nog ontwikkeld moet worden. Denk aan PCIe support, Thunderbolt, etc.

[TechSupreme]

Dat is niet het enige, de naam ARM zegt eigenlijk al genoeg.

ARM (voor ze overgingen in ARM holding) stond oorspronkelijk voor Advanced/Acorn RISC Machine, RISC staat op zijn beurt weer op Reduced Instruction Set Computer.

x86 is een zgn CISC ofwel een Complex Instruction Set Computer.

Nou zullen de doorgewinterde tweakers onder ons zeggen dat vanaf v8 ISA de lijnen tussen RISC en CISC vervagen en dat de ARM v8 meer CISC trekjes heeft, maar feit blijft dat het een RISC is en voor het verhaal blijven we even daarbij.

Zonder hier hele college's op te houden over de verschillen tussen die twee kan het volgende gezegd worden. RISC is reduced, dus verminderd. Dat wil zeggen dat men omwille van besparing zoveel mogelijk intructies weglaat en zoveel mogelijk algemene instructies gebruikt.

Bijvoorbeeld een CISC kan een instructie vermenigvuldigen hebben die 3x3 voor je doet, dat is dus 1 instructie en 1 cyclus. Een RISC zal geen specifieke instructie hebben alleen de algemene instructie optellen. Je zult dus (3 + 3) + 3 moeten doen, dat zijn 2 instructies (plus nog eens load en store) en dus 2 cycli. Ja ik weet heel simpel uitgelegd, niet zeuren.

Maar goed een RISC heeft dus minder instructies en dat wil dus zeggen minder transistoren en dat wil weer zeggen minder energieverbruik.

Nou is dit dus een trade-off tussen energieverbruik en toepassing. Voor mobiele apparaten is dat perfect want het apparaat moet maar een beperkt aantal dingen kunnen en dat tegen een zo hoog mogelijk cost-efficiency.

Nou zijn daar over de jaren heen weer dingen ingeslopen (zoals ik al zei ARM v8 heeft CISC trekjes) omdat we iets meer zijn gaan eisen van onze mobiele apparaten.

Wat ik eigenlijk probeer te zeggen is dat een RISC heel goed is in specifieke toepassingen en een CISC heel goed is in algemene toepassingen. Dat is sowieso een van de redenen waarom ik het nog even niet zie gebeuren dat Apple een ARM chip in zijn desktop/laptop lijnen gooit.

Maar goed je kan een RISC dus wel CISC dingen laten doen, alleen dat zal je je hele OS en het framework wat erachter zit helemaal moeten optimaliseren voor die RISC toepassing. Dat wil dus zeggen dat als je zo optimaal mogelijk te werk wil gaan dat je dan heel goed moet kijken hoe je lowlevel en highlevel API's werken en met elkaar omgaan. Dat is niet iets wat je zo even 1, 2, 3 uit je mouw schudt en zeker niet als je al een volwassen OS hebt in de vorm van macOS X. Als je al een goed werkend product hebt in de vorm van een x86 en macOS, dan zullen je klanten niet zomaar accepteren dat ze een gereduceerd product krijgen voor dezelfde prijs. Een paar fanatiekelingen zullen het wel doen maar het gros zal bij het oude blijven. Zoiets heeft tijd nodig om volwassen te worden en in die tijd moet je de overgang tussen de twee zo soepel mogelijk maken anders komt het echt nooit van de grond.

Dat alles bij elkaar vind ik het verhaal over een ARM mac een beetje vergezocht, maar buiten dat al zou Apple ermee bezig zijn dan zal dat een jaartje of 10/20 in de toekomst liggen. ARM chips in het Pro segment zie ik sowieso al niet gebeuren, eerder in de goedkopere segmenten. Bijvoorbeeld in de Air lijn welke vaak voor simpelere toepassingen worden gebruikt als browsen, mailen, office, etc.

Kijk maar naar Microsoft. Zij zijn al decennia bezig met het bouwen van UWP en allerlei frameworks om dat Windows on ARM gebeuren van de grond te krijgen en dat begint nu pas een beetje de vruchten af te werpen.

[Reactie gewijzigd door TechSupreme op 22 juli 2024 13:18]

[Aaargh!]

Maar goed een RISC heeft dus minder instructies

Dat is dus een veel voorkomende misvatting. RISC heeft zeker niet minder instructies. De 'reduced' in RISC slaat niet op het aantal instructies, maar op de complexiteit van de instructies zelf.

In een CISC processor kan je b.v. een instructie hebben die betekent "laad een 32-bit integer uit het adres dat in register A staat en vermenigvuldig met de inhoud van register B, schrijf het resultaat weg naar geheugenlocatie C". Een enkele instructie kan meerdere keren het geheugen aanspreken, heeft vaak verschillende varianten met verschillende adresserings modes (laad direct uit een geheugenadres, laad uit een adres dat in een register staat, laad uit een adres dan in een register staat met offset, etc. etc.). Een enkele CISC instructie kan vele kloktikken duren en door de vele varianten is het decoderen van een instructie relatief complex. Instructies hebben vaak ook variabele lengtes om de verschillende varianten te kunnen encoden wat de decoder ook niet simpeler maakt.

Bij RISC zijn de instructies veel eenvoudiger. Een complexe vermenigvuldig instructie met een heleboel opties om aan te geven waar de data vandaan komt zoals in bovenstaande voorbeeld zal niet bestaan. In plaats daarvan gebruik je meerdere instructies: een 'load' instructie om de data uit het geheugen te halen en in een register te zetten, de vermenigvuldiging die het resultaat in een register zet, en een store instructie die het resultaat weer naar het geheugen schrijft. Dit wordt ook wel een load-store architectuur genoemd. De instructies zelf zijn veel eenvoudiger, waardoor deze ook sneller zijn: meestal maar 1 kloktik. Instructies hebben vaak ook een vaste grootte en zijn veel eenvoudiger te decoderen.

Het hele idee van RISC is de IPC hoog houden. Doordat een RISC processor simpeler is kunnen de kloksnelheden ook hoger.

Bijvoorbeeld een CISC kan een instructie vermenigvuldigen hebben die 3x3 voor je doet, dat is dus 1 instructie en 1 cyclus. Een RISC zal geen specifieke instructie hebben alleen de algemene instructie optellen. Je zult dus (3 + 3) + 3 moeten doen, dat zijn 2 instructies

Dit is dus niet het geval, op RISC is een instructie vaak 1 cyclus, maar op CISC juist niet. Een multiply die ook een load/store doet op CISC kan vele cycli duren, afhankelijk van of de data in de cache staat of niet, etc.

Wat ik eigenlijk probeer te zeggen is dat een RISC heel goed is in specifieke toepassingen en een CISC heel goed is in algemene toepassingen.

Totaal onjuist. De andere architectuur maakt CISC niet geschikter voor bepaalde toepassingen dan RISC, of andersom. Om ARM v.s x86 te nemen doen ze, zeker met ARMv8, niet veel voor elkaar onder. ARM heeft b.v. ook een uitgebreide SIMD/vector instructie set, virtualisatie instructies, etc. etc.

Uiteraard zijn er punten waarop CISC vs. RISC een trade-off is. Doordat RISC eenvoudiger is, is deze zuiniger en/of kan deze op hogere kloksnelheden draaien, maar dit gaat ten koste van een grotere afhankelijkheid van geheugen bandbreedte en met name caching. Doordat RISC instructies fixed-length zijn en je meer instructies nodig hebt voor hetzelfde werk heb je bij RISC eerder het risico dat je gebottlenecked wordt door de snelheid waarmee je instructies uit het RAM kan lezen.Dit is vooral een issue als je niet voldoende L1 cache hebt. Als je een algoritme uitvoert dat in z'n geheel in de L1 past dan is het geen probleem. Daarom wil je in een RISC processor een flinke L1 cache.

Maar goed je kan een RISC dus wel CISC dingen laten doen, alleen dat zal je je hele OS en het framework wat erachter zit helemaal moeten optimaliseren voor die RISC toepassing.

Voor 99,99999% van de code maakt het absoluut niet uit of je op CISC or RISC draait. Optimaliseren op het niveau waar we hier over praten is vooral een taak voor de compiler, en die zijn daar erg goed in.

Dat is niet iets wat je zo even 1, 2, 3 uit je mouw schudt en zeker niet als je al een volwassen OS hebt in de vorm van macOS X.

Je weet dat macOS al jaren op ARM draait in de vorm van iOS ? iOS is voor 95% hetzelfde OS als macOS, er zijn uiteraard wat andere drivers en de UI libraries zijn totaal anders vanwege de touch-based interface, maar alles daartussen is zo'n beetje hetzelfde. Hetzelfde kernel als macOS, bijna alle fundamentele libraries zijn exact hetzelfde, Foundation, Core Graphics , Core Image , Core Animation, Grand Central Dispatch, Metal, Accelerate, Networking, etc. etc.

Ga eens kijken in de developer documentatie van Apple, het is 1 set documentatie voor al hun OSen en maar heel soms staat er bij iets dat iets wel/niet beschikbaar is voor een specifiek OS. (b.v. de UI elementen voor Apple Watch zijn logischerwijs niet beschikbaar op macOS).

Kijk maar naar Microsoft. Zij zijn al decennia bezig met het bouwen van UWP en allerlei frameworks om dat Windows on ARM gebeuren van de grond te krijgen en dat begint nu pas een beetje de vruchten af te werpen.

Microsoft sleept een paar decennia aan legacy meuk met zich mee, dit is een totaal andere situatie dan waar Apple in zit. Als Apple overstapt naar ARM zal dit voor de overgrote meerderheid van applicaties niet meer inhouden dan een keer de app opnieuw compileren. De overstap zal simpeler zijn dan die van PPC naar x86 (toen ging je ook nog van big- naar little-endian) of die van 32-bit naar 64-bit.

[TechSupreme]

Dat is dus een veel voorkomende misvatting. RISC heeft zeker niet minder instructies. De 'reduced' in RISC slaat niet op het aantal instructies, maar op de complexiteit van de instructies zelf.

Je zegt dat nu wel, maar ook dat is het niet. Reduced wil zeggen dat je zoveel mogelijk weglaat omwille van de toepassing. Het concept RISC gaat eigenlijk meer over de bouw van de processor, een processor die zoveel mogelijk aansluit op je toepassing. Een RISC kan zeker complexe instructies bevatten als je toepassing erom vraagt, kijk maar naar de ARM ISA vanaf v8. Dat is dus wat ik zei:

een RISC heel goed is in specifieke toepassingen en een CISC heel goed is in algemene toepassingen

Omwille van de eenvoud had ik al gezegd: "Ja ik weet heel simpel uitgelegd, niet zeuren", jammer dat dat dan wel weer gebeurt.

Voor 99,99999% van de code maakt het absoluut niet uit of je op CISC or RISC draait. Optimaliseren op het niveau waar we hier over praten is vooral een taak voor de compiler, en die zijn daar erg goed in.

Kijk dat is wat ik ook al zei, of ja het is geïmpliceerd.

ARM chips in het Pro segment zie ik sowieso al niet gebeuren, eerder in de goedkopere segmenten. Bijvoorbeeld in de Air lijn welke vaak voor simpelere toepassingen worden gebruikt als browsen, mailen, office, etc.

Je zegt trouwens dat het de taak van de compiler is, dat is op binary niveau. Een compiler kan niet zomaar je hele framework optimizen. Kennis van het systeem helpt als bij het optimaliseren in de design fase.

In het Pro segment met de zwaardere toepassingen heb je juist die complexiteit nodig. In de goedkopere segmenten waar ze niet zo snel zware taken uit gaan voeren, dan zou een RISC inderdaad kunnen voldoen.

Microsoft sleept een paar decennia aan legacy meuk met zich mee

Dat heeft echt geen toepassing op dit verhaal. UWP en Windows on ARM hebben juist als doelstelling om die legacy uit te sluiten.

[Aaargh!]

Het concept RISC gaat eigenlijk meer over de bouw van de processor, een processor die zoveel mogelijk aansluit op je toepassing

Nee, totaal niet. RISC vs. CISC slaat alleen op hoe je je instructieset opbouwt: simpele instructies die maar 1 ding doen of complexere instructies die meerdere stappen in 1 instructie hebben. Meer niet. Waarvoor je de CPU maakt of hoeveel instructies deze heeft slaat hier compleet los van. Een PDP-8 is een CISC machine en kent maar 8 instructies.

Omwille van de eenvoud had ik al gezegd: "Ja ik weet heel simpel uitgelegd

Er is een verschil tussen iets versimpelen of iets totaal incorrects zeggen. Again, het heeft echt helemaal NIETS te maken met hoe generiek een processor is.

Een compiler kan niet zomaar je hele framework optimizen. Kennis van het systeem helpt als bij het optimaliseren in de design fase.

Voor het design maakt het geen zak uit of je op RISC of CISC draait. Waarom zou dit in hemelsnaam afhankelijk zijn van hoe de instructieset van je CPU is opgebouwd ? Dat is totaal niet relevant. Er zijn maar heel erg weinig situaties waar je hier überhaupt over hoeft na te denken en dan heb je het altijd over micro-optimalisaties van een specifiek algoritme, hele kleine stukjes super low-level code. Zeker niet iets waar je je in je design druk over maakt.

In het Pro segment met de zwaardere toepassingen heb je juist die complexiteit nodig.

Waarom ? Wat heeft het voor voordeel als iets in 1 trage, complexe instructie wordt gedaan ipv een een paar snelle, simpele ? Het resultaat is hetzelfde en het duurt even lang.

UWP en Windows on ARM hebben juist als doelstelling om die legacy uit te sluiten.

En dat is nu net wat het zo lastig maakt. Je zegt zelf dat MS al heel lang bezig is om dit van de grond te krijgen. macOS op ARM heeft zoiets helemaal niet nodig.

[Reactie gewijzigd door Aaargh! op 22 juli 2024 13:18]

[Aaargh!]

Ga maar eens een systeem van ground up ontwerpen dan kom je er vanzelf achter hoe belangrijk dat is.

Leg dan eens uit waarom het uit zou maken voor de architectuur van een willekeurige grote applicatie of het RISC of CISC is.

cost-efficienct hebben de meeste nog nooit van gehoord.

Want developer uren zijn goedkoop bedoel je ? Wat een onzin.

PARDON! Dus al die miljarden die jaarlijks wordt gestoken in optimalisatie onderzoek, e.d. alle vooruitgangen die zijn geboekt tbv van pipelining, prediction, etc. etc. etc. is allemaal voor niks.

Nou praat je echt poep, je haalt er dingen bij die er helemaal niets mee te maken hebben. Dat zijn allemaal dingen die precies net zo werken op CISC en RISC. Again, het gaat hier alleen om het ontwerp van de instructieset, niet om de implementatie ervan. Die is namelijk 95% hetzelfde. RISC processoren zijn ook gewoon superscalar, het enige verschil tussen RISC en CISC tegenwoordig is de instructie-decoder. AMD en Intel zouden bij wijze van spreken zo een andere front-end op hun CPU's kunnen zetten en ze ARM instructies kunnen laten uitvoeren. Of je nu CISC or RISC instructies omzet in micro-ops, dat veranderd niets zo veel aan de backend.

Het probleem is dat het niet aanslaat of dat bedrijven geen moeite willen steken in de overstap.

En wat jij niet lijkt te begrijpen is dat dat een cultuur is die Microsoft in de hand gewerkt heeft met hun eindeloze backwards-compatibiliteit. Op macOS is er niet zo'n cultuur. Apple staat er om bekend dat ze niet te beroerd zijn om backwards-compatibilitieit te breken en oude API's snel te deprecaten en verwijderen. Mac developers zijn dit gewend en reageren hier over het algemeen snel op.

wat ik dan helemaal niet begrijp is waarom ARM op macOS geen transitie periode nodig heeft.

Beweer ik dat dan ergens ? Tuurlijk is er een transitie periode nodig, en dat zal waarschijnlijk gaan met iets als Rosetta. Die transitie zal echter behoorlijk snel en pijnloos zijn. De meeste apps binnen een maand en na een jaar zal alles over zijn.

[TechSupreme]

Want developer uren zijn goedkoop bedoel je ? Wat een onzin.

Ga maar lekker in je abstractielaagje werken, dan knappen de echte mannen het echte werk wel op. Onder dat abstractielaagje van je zit toch echt wel een hoop optimalisatie welke architectuur specifiek is. Fundamenteel onderzoek in de wiskunde/computertechniek bestaat niet, het is allemaal Java.

Nou praat je echt poep, je haalt er dingen bij die er helemaal niets mee te maken hebben. Dat zijn allemaal dingen die precies net zo werken op CISC en RISC.

Nee, jij bent diegene die claimt dat het allemaal niks uit maakt. Waarom bouwt ARM ineens complexe instructies in z'n ISA? Het maakt toch niks uit? Waarom alle moeite doen? Slaat echt helemaal nergens op wat je nu allemaal uitkraamt. Er is wel degelijk een verschil tussen toepassing en welke architectuur je gebruikt

eindeloze backwards-compatibiliteit

Welke eindeloze backwards-compatibiliteit? Ik zeg je net dat dat niet bestaat. Windows 7 t/m Windows 10 hebben nagenoeg bijna dezelfde API en kernel waardoor het werkt, maar daarvoor is het maar afwachten.

Die transitie zal echter behoorlijk snel en pijnloos zijn.

Ohja dat ging de vorige keer ook zo... ohnee wacht...

[Aaargh!]

Onder dat abstractielaagje van je zit toch echt wel een hoop optimalisatie welke architectuur specifiek is.

Micro-optimilisaties van bepaalde hotspots, sure. Maar daar ging deze discussie niet over: volgens jou moest je in de design fase van een software architectuur al rekening houden met het type instructieset, dus niet 'onder de motorkap' maar super high-level. Totale onzin. Je blijft de doelpalen verplaatsen.

Waarom bouwt ARM ineens complexe instructies in z'n ISA?

SIMD en vector instructies zijn geen complexe instructies in de context van RISC vs. CISC. Zitten er instructies in de ARM ISA die meerdere stappen (load/compute/store) in 1 combineren ? Zo ja welke ?

Welke eindeloze backwards-compatibiliteit?

Ik zou zeggen, lees eens door de archieven in dit blog. Staat vol met talloze verhalen over hoe ver Microsoft wel niet gaat om backwards compatible te blijven.

Ohja dat ging de vorige keer ook zo... ohnee wacht...

Die ging vorige keer zo goed als vlekkeloos. Welke problemen ben jij tegengekomen dan ?

[TechSupreme]

Micro-optimilisaties van bepaalde hotspots, sure. Maar daar ging deze discussie niet over: volgens jou moest je in de design fase van een software architectuur al rekening houden met het type instructieset, dus niet 'onder de motorkap' maar super high-level. Totale onzin. Je blijft de doelpalen verplaatsen.

Je inderdaad, beter dat je daar vroegtijdig al rekening mee houdt. Zeker als je een zo optimaal mogelijk systeem wil ontwerpen met een zo hoog mogelijke cost efficiency.

SIMD en vector instructies zijn geen complexe instructies in de context van RISC vs. CISC.

Oh sorry de context is anders... maar je kan hetzelfde bereiken met een paar optel sommetjes, dus dat zou volgens jou even snel moeten zijn, toch?

[psychicist]

Het grote verschil is dat bij Apple een groot gedeelte van de applicaties al native op ARM draait via iPadOS. Ik kom net een artikel tegen waarin de benadering van Microsoft tegenover die van Apple gezet wordt.

Het is duidelijk dat Apple zijn zaken veel meer in orde heeft dan Microsoft. Niet alles zal perfect werken vanaf het begin, maar het belangrijkste is om een bruikbaar product te hebben voor eindgebruikers en dan zo snel mogelijk eventuele fouten en tekortkomingen op te lossen.

Ik draai nu zelf al 3 jaar Linux op 64-bit ARM naast x86-64 en vooral het laatste jaar is alles gewoon gaan werken. Het kleine aantal programma's dat nog niet werkt, vormt geen hindernis voor het gebruik van de computer. Emulatie heb ik tot nu ook niet nodig gehad, omdat vrijwel alles native werkt. Het is nu eigenlijk alleen maar een kwestie van wachten op krachtigere hardware en eventueel propriëtaire applicaties.

[TechSupreme]

Dat gaat niet werken.

Mobiele apps werken simpelweg niet op een tablet of op een desktop, dat hebben zowel Microsoft, Google en Apple in het verleden bewezen. De mobiele apps zullen sowieso nooit draaien op een desktop/laptop omdat Apple geen touch ondersteuning heeft en muis ondersteuning is pas een maandje geleden ingebouwd in ipadOS.

Je zegt nu 3 jaar, dat is al 3x de binnen een jaar is het klaar en het is er eigenlijk al claims. Goed, wie biedt meer, ik ga toch nog voor de 10 a 20 jaar voor de transitie.

[Reactie gewijzigd door TechSupreme op 22 juli 2024 13:18]

[koelpasta]

Bijvoorbeeld een CISC kan een instructie vermenigvuldigen hebben die 3x3 voor je doet, dat is dus 1 instructie en 1 cyclus. Een RISC zal geen specifieke instructie hebben alleen de algemene instructie optellen. Je zult dus (3 + 3) + 3 moeten doen, dat zijn 2 instructies (plus nog eens load en store) en dus 2 cycli. Ja ik weet heel simpel uitgelegd, niet zeuren.

Je legt het te simpel uit en maakt een belangrijke fout.
De CISC zal door zn complexere instructies juist meerdere klokcycli verbruiken. Die '3x3' CISC instructie duurt dus mischien wel 12 cycli. En eigenlijk zit er in een moderne CISC processor meerdere RISC-achtige cores. Die worden aangestuurd door de complexe, gelaagde instructies die uit een compiler rollen. Die CISC instructies worden intern dus opgebroken in eenvoudige instructies en na elkaar uitgevoerd. De cpu doet meerdere mini-iunstructies met 1 grote instructie, maar dat kost dus wel meer tijd.

Bij RISC worden gewoon de 'mini' instructies direct(er) uitgevoerd. RISC instructies zijn dus eenvoudiger van aard, maar worden wel sneller uitgevoerd.

Waar het op neerkomt is dat CISC instructies heeft die meer doen maar ook langer duren, terwijl RISC instructies minder doen maar dus minder tijd kosten per instructie.
Beide hebben hun voor- en nadelen.

Maar goed je kan een RISC dus wel CISC dingen laten doen, alleen dat zal je je hele OS en het framework wat erachter zit helemaal moeten optimaliseren voor die RISC toepassing.

In princiepe is dat de taak van de compiler. Op hoger nivo is het verschil redelijk transparant. Er is niet direct iets dat een CISC wel kan en een RISC niet en andersom. Er zijn wel architectonische verschillen maar die hebben op zich niet zoveel met RISC vs CISC te maken.

[TechSupreme]

Ik had al aangegeven dat ik het heel simpel en laagdrempelig ging uitleggen.

Het verhaal is dus dat een CISC een specifiek onderdeel kan hebben voor een geheel specifieke toepassing, ofwel wat in de moderne ontwerpen CISC on RISC wordt genoemd. In het specifieke voorbeeld van 3x3 (wat eigenlijk onzin is) zal de processor inderdaad een aparte stukje hebben welke geoptimaliseerd is voor die operatie en de reden waarom je dat zou hebben is meer performance. Dus ipv 2 optel operaties 1 vermenigvuldig operatie. Nou aangezien de operaties (3 + 3) + 3 heel simpel gezegd 2 cycli zullen duren dan zal de 3x3 logica toch echt maar 1 cycli moeten zijn want anders heeft het geen nut. Daar komt nog bij dat je een systeem moet hebben die heel vaak de 3x3 operatie uitvoer want anders heeft dat dan ook weer geen nut.

Je zegt complexe gelaagde instructies, maar bij een RISC is dat niet veel anders. Alleen zal je gebruik moeten maken van de algemene operaties om zo gelaagd naar hetzelfde resultaat te werken.

Het hele idee van CISC is dus we hebben een hoop operaties die handig zijn om te hebben mocht je ze willen gebruiken dan zijn ze er en het hele idee achter RISC is dat je zoveel mogelijk algemene operaties wil hebben die zoveel mogelijk worden gebruikt. Dat wil dus zeggen dat als jou toepassing erom vraagt dat jij een 3x3 operatie hebt, dan is die er en anders laat je het lekker weg.

Op hoger nivo is het verschil redelijk transparant.

Nou op hoger niveau zal het leiden tot een merkbaar verlies van performance, meer niet. Op een lager niveau is het lonend om je architectuur in je achterhoofd te houden. Een simpel iets als bit setting kan afhankelijk van je architectuur tot enorme performance winst leiden afhankelijk van welke operatie je gebruikt. Het is zelfs zo dat als de bits uiteindelijk worden weggeschreven naar een flash drive dat het destructief kan zijn voor je flash drive.

Ik had al beetje verwacht dat er mensen zouden zijn die er dieper op in willen gaan, maar daar is deze thread niet voor daarom heb ik ervoor gekozen om oppervlakkig te blijven. Deze thread gaat over Intel processoren in Apple producten. Daarbij werd ARM aangehaald en ik leg alleen uit waarom ik denk dat het voor de Pro segment niet haalbaar is vanuit een processor technisch standpunt.

[Reactie gewijzigd door TechSupreme op 22 juli 2024 13:18]

[koelpasta]

Ik had al aangegeven dat ik het heel simpel en laagdrempelig ging uitleggen.

Alleen legde je juist het essentiele verschil niet goed uit.

Dus ipv 2 optel operaties 1 vermenigvuldig operatie.

Ja, maar je zei onterecht dat die enkele vermenigvuldigingsinstructie een enkele klokcyclus in beslag neemt. De hele essentie van RISC vs CISC is juist dat een CISC instructie langer duurt. De hele redenering achter RISC is dat het soms sneller is om meerdere eenvoudige instructies te doen die elk maar 1 cyclus in beslag nemen dan een complexere CISC instructie die hetzelfe doet (maar dus meerdere cycli duurt).

Je zegt complexe gelaagde instructies, maar bij een RISC is dat niet veel anders.

Wat ik daarmee bedoelde is dat er in CISC ISA's allerlei combinatie-instructies zitten die verschillende doelen dienen. Dat is nodig om op een CISC processor fatsoenelijk aan instructieparallelisme te kunnen doen. Op een RISC is dat eenvoudiger omdat bijvoorbeeld meestal alle instructies even lang duren. Bij een CISC is het lastiger om de pipeline vol te houden (bv omdat instructies verschillede uitvoertijden hebben) en dan krijg je dus allerlei varianten van instructies die in bepaalde gevallen net iets beter performen. Een CISC heeft dan ook meer uitzonderlijke instructies.

[TechSupreme]

Ja, maar je zei onterecht dat die enkele vermenigvuldigingsinstructie

Je schijnt niet te begrijpen dat deze hypotetische situatie niet bestaat en dat het alleen maar wordt gebruikt om de fundamentele ontwerp verschillen tussen beide architecturen uit te leggen. Buiten dat zal een specifieke instrcutie misschien langer duren, maar vanwege de complexiteit zal je sneller bij het eindresultaat zijn.

[Reactie gewijzigd door TechSupreme op 22 juli 2024 13:18]

[koelpasta]

Je schijnt niet te begrijpen dat deze hypotetische situatie niet bestaat en dat het alleen maar wordt gebruikt om de fundamentele ontwerp verschillen tussen beide architecturen uit te leggen.

Ik weet niet goed waar je hier aan refereert, maar je legde het verschil juist niet uit. Het grote verschil is dat een CISC instructie meer doet maar ook meer kolkcycli in beslag neemt. Dat laatste heb je juist weggelaten.

Buiten dat zal een specifieke instrcutie misschien langer duren, maar vanwege de complexiteit zal je sneller bij het eindresultaat zijn.

Ja, dat is precies wat ik heb geschreve maar jij had weggelaten uit je verhaal.

[ikweethetbeter]

Een heel verhaal, een paar juiste zaken, en een paar dingen die even wat nuancering (zacht gezegd) nodig hebben!

Maar goed een RISC heeft dus minder instructies en dat wil dus zeggen minder transistoren en dat wil weer zeggen minder energieverbruik.

Dat is maar een deel. Minder instructies, minder grote instructietabel om de juiste instructie op te zoeken, kortere tijd (klokcycli) om één instructie uit te voeren, ...

Nou zijn daar over de jaren heen weer dingen ingeslopen (zoals ik al zei ARM v8 heeft CISC trekjes) omdat we iets meer zijn gaan eisen van onze mobiele apparaten.

En Intel Core heeft RISC trekjes, het is een soort "CISC on RISC" ontwerp.

Wat ik eigenlijk probeer te zeggen is dat een RISC heel goed is in specifieke toepassingen en een CISC heel goed is in algemene toepassingen. Dat is sowieso een van de redenen waarom ik het nog even niet zie gebeuren dat Apple een ARM chip in zijn desktop/laptop lijnen gooit.

Dat is absoluut niet waar. De migratie naar een nieuwe architectuur (hardware, maar vooral software) is het enige wat Apple tegenhoudt.

Maar goed je kan een RISC dus wel CISC dingen laten doen, alleen dat zal je je hele OS en het framework wat erachter zit helemaal moeten optimaliseren voor die RISC toepassing. Dat wil dus zeggen dat als je zo optimaal mogelijk te werk wil gaan dat je dan heel goed moet kijken hoe je lowlevel en highlevel API's werken en met elkaar omgaan. Dat is niet iets wat je zo even 1, 2, 3 uit je mouw schudt en zeker niet als je al een volwassen OS hebt in de vorm van macOS X.

Ook totaal niet waar. Apple is ooit begonnen op de MC68000 serie (CISC), toen overgestapt op de PPC serie (RISC), en nu zit Apple op Intel Core (min of meer CISC). Het is een bekend gegeven dat Apple z'n macOS al lang heeft draaien op zijn eigen ARM architectuur. Het overstappen van architectuur is een vaker uitgevoerd kunstje, ze doen het zo nog een keer.

Dat alles bij elkaar vind ik het verhaal over een ARM mac een beetje vergezocht, maar buiten dat al zou Apple ermee bezig zijn dan zal dat een jaartje of 10/20 in de toekomst liggen.

Deel dat maar door 10 of 20!

ARM chips in het Pro segment zie ik sowieso al niet gebeuren, eerder in de goedkopere segmenten. Bijvoorbeeld in de Air lijn welke vaak voor simpelere toepassingen worden gebruikt als browsen, mailen, office, etc.

Apple's A13 SoC rent rondjes om de meeste Intel CPU's. Deze is krachtig genoeg voor zware toepassingen op een desktop OS. Doe daar een versie met meer cores van en hij troeft de snelste i7's af.

Google voor de gein eens op "macOS ARM"...

Kijk maar naar Microsoft. Zij zijn al decennia bezig met het bouwen van UWP en allerlei frameworks om dat Windows on ARM gebeuren van de grond te krijgen en dat begint nu pas een beetje de vruchten af te werpen.

Microsoft sleept MS DOS 1.0 compatibiliteit mee in Windows 10. Dat is een hele andere uitdaging!

[TechSupreme]

Deel dat maar door 10 of 20!

Dus wat je zegt is dat er binnen een jaar alles is omgezet naar een nieuwe API en dat alles ook 100% wordt ondersteunt. Je zegt hetzelf als Apple is al wel eens vaker overgestapt van architectuur en dat heeft toch echt langer als een jaar geduurd en niet te vergeten alle ellende die ermee gepaard ging.

[ikweethetbeter]

Ik zeg dat Apple al bijna klaar is. Dit proces heeft jaren geduurd.

[psychicist]

Het zou me verbazen, als Apple niet bijna alles klaar heeft om over te schakelen. Ik draai zelf Debian Sid hier op mijn systeem en hooguit 10 programma's hebben echt problemen. Ook is er ondersteuning voor ARM vanuit de verschillende BSD's, dus ik kan me nauwelijks voorstellen dat er überhaupt problemen zijn onder macOS. Alleen propriëtaire applicaties dienen geport en opnieuw gecompileerd te worden, maar dat lijkt me een relatief eenvoudig proces.

Visual Studio 2019 draaiende op Windows 10 heeft een ARM64 compiler, maar de animo onder ontwikkelaars om er executables voor te maken lijkt zo goed als nul en dat is een van de redenen dat het niet van de grond komt. Zelfs open source software wordt er zo goed als niet voor gecompileerd, een uitzondering zoals VLC of Firefox daargelaten. Dit is specifiek een Windowsprobleem en bestaat niet op veel andere besturingssystemen.

[ikweethetbeter]

Het grote verschil tussen MS en Apple is dat Apple afscheid durft te nemen van het verleden. Op de huidige hardware (Intel Core i whatever) zou je in principe gewoon 32-bits x86 gecompileerde programma's kunnen draaien, maar Apple heeft daar een half jaar geleden een streep door getrokken: sinds macOS Catalina moet alles 64-bits zijn. Op zich niet heel raar als je bedenkt dat de eerste 64-bits Intel Core 2 Duo in een Mac in 2006 uitkwam. Na 13 jaar mag je wel eens verder!

MS maakt nog 32-bits versies van zijn OS en applicaties, ook al heeft iedereen al jaren 64-bits hardware. Onbegrijpelijk!

Er zijn zelfs tips op internet te vinden hoe je MS Office 95 (uit 1995, 25 jaar oud!!!) op Windows 10 kunt installeren. Triest! Als je zoiets exotisch nodig hebt (voor Office lijkt me dat ongewenst, maar misschien bepaalde onmisbare stukken maatwerk), dan draai je dat virtueel in een goed afgeschermde sandbox.

[TechSupreme]

Dat is dus iets wat jij niet wil begrijpen en wat hieronder ook al wordt aangehaald. Het is niet alleen aan Apple om die beslissing te nemen. Zolang de ondersteuning vanuit 3th parties er niet is heb je er nog niks aan. Apple zal morgen een nieuw platform neer moeten leggen en dat platform zal ook moeten werken. Maar als er van buitenaf geen draagvlak voor is dan kan het zo goed werken als je wil.

[ikweethetbeter]

Toen Apple overging van PPC naar Intel Core, toen kwamen de Universal Binaries, applicaties met zowel PPC als Intel code, en OS X (zo heette macOS toen) kwam met Rosetta, een vertaler die PPC code naar Intel vertaalde.

Op de eerste Intel Mac kon je Intel en Universal Binary applicaties met native snelheid draaien, en PPC applicaties waren wat langzamer, maar goed werkbaar. Binnen de kortste keren waren alle applicaties Intel of UB.

Mogelijk doen ze hetzelfde met de overgang naar ARM. Ze hoeven hier niemand toestemming voor te vragen, ze moeten alleen de ontwikkeltools beschikbaar maken. Het is aan Apple en aan Apple alleen om dit te beslissen.

[TechSupreme]

Wat is dan het verschil met UWP?

[koelpasta]

Maar als er van buitenaf geen draagvlak voor is dan kan het zo goed werken als je wil.

LOL, dan ken jij Apple niet. Die zijn al een paar keer van architectuur gewisseld door de jaren heen.
Ik denk dat jij onderschat hoeveel macht apple hierin heeft. Het is geen pc markt, he. Apple voert complete controle uit over hun ecosysteem. Hardware en software. Ze gaan meestal maar met een paar fabrikanten in zee die een beperkte hoeveelheid producten uitbrengen voor ze.

Tegenwoordig is dat 'draagvlak van 3rd parties' sowiso bijna geen issue meer vanwege standaarden zoals USB, thunderbolt en displayport. Ik denk niet dat Apple die zou droppen als ze op ARM gaan bouwen voor hun desktops. 3rd party support is dan een kwestie van drivers en goed te realiseren.
En in zn algemeenheid is er toch al niet echt een probleem. Als jij als HW fabrikant een product kunt bouwen voor een x86 platform dan kun je het ook bouwen voor een ander platform. Zolang er maar genoeg markt is en het economisch wordt. En Apple heeft genoeg markt.

[TechSupreme]

Ja leuk en aardig allemaal, maar de geschiedenis wijst nog steeds uit dat wat jij voorstelt niet een kwestie is van 1 jaar. Dus jah waar dat getal vandaan komt is voor mij nog steeds een vraagteken. Dr is transitie nodig, klaar uit over basta.

[PPie]

x86 is een zgn CISC ofwel een Complex Instruction Set Computer.

Sinds de Pentium Pro is de 'CISC' een RISC met een x86 naar microops vertaalunit ervoor.

Voor mobiele apparaten is dat perfect want het apparaat moet maar een beperkt aantal dingen kunnen en dat tegen een zo hoog mogelijk cost-efficiency.

Je vergeet hier dat er een heleboel andere RISC processoren zijn, zoals de POWER (en vroeger de afgeleide PowerPC) of daarvoor ook de Sparc (en nu ook RISC-V) die niet specifiek bedoeld zijn voor 'mobiele apparaten'.

Wat ik eigenlijk probeer te zeggen is dat een RISC heel goed is in specifieke toepassingen en een CISC heel goed is in algemene toepassingen.

Dit heeft niets met CISC en RISC te maken...

Dat alles bij elkaar vind ik het verhaal over een ARM mac een beetje vergezocht, maar buiten dat al zou Apple ermee bezig zijn dan zal dat een jaartje of 10/20 in de toekomst liggen.

Gezien de performance van de huidige Ax cores op een mobiel powerbudget, verwacht ik dat Apple daar nog kan verbazen. Ik denk dat de voorspelling dat ze dit jaar al gaan komen met de eerste ARM machines zeer geloofwaardig.

Kijk maar naar Microsoft. Zij zijn al decennia bezig met het bouwen van UWP en allerlei frameworks om dat Windows on ARM gebeuren van de grond te krijgen en dat begint nu pas een beetje de vruchten af te werpen.

Apple is hier ook al jaren mee bezig. Een van de dingen is dat ze in het ontwikkelplatform de LLVM compiler gebruiken.
Deze geeft de mogelijkheid om de LLVM bitcode (soort intermediate compile file format) te uploaden naar de App Store.

Quote van https://thenextweb.com/ap...ys-talking-about-bitcode/ :

This means that apps can automatically “take advantage of new processor capabilities we might be adding in the future, without you re-submitting to the store.

Dit wil zeggen dat je een App kan maken en deze aanbied in bitcode en dat deze dan op het moment dat iemand een download doet de laatste slag wordt gedaan en er een x86, x86_64 of ARM binary uitkomt. Op het moment dat Apple dan een nieuw target of optimalisatie verzint, kunnen ze opnieuw deze laatste slag doen.
Bitcode is verplicht voor een watchOS en tvOS app en optioneel voor de andere targets.

Apple is al twee (en een half) maal overgestapt van processor ISA in de Mac (68K -> PPC -> x86 en nu verplicht x86_64).

[RobbieB]

Het probleem zit hem erin dat alle software voor x86 is geschreven en niet voor ARM. Nadat Apple over was gestapt van PowerPC naar Intel heeft het ook jaren geduurd voordat software echt fatsoenlijk compatibel was. Rosetta hielp, maar was meer een pleister dan een daadwerkelijke oplossing.

Hetzelfde zal ook met ARM gebeuren. Het grote voordeel zal zijn dat veel software tegenwoordig ook in een minimale vorm beschikbaar is voor de iPad (denk aan Office / Photoshop) en dat er echt goede alternatieven beschikbaar zijn, maar deze voelen voor een professional toch echt wel crippled.

Als Apple dus met een ARM-MacBook gaat komen, verwacht ik dat dit in eerste instantie tegenover ChromeBooks zal komen te staan (maar dan 2x zo duur) dan dat we hier echt pro-machines kunnen verwachten.

In dit geval denk ik net als @Knijpoog dat AMD hier een grotere bedreiging is voor Intel. Ook als je nu de Xeon's in de Mac Pro ziet waar de Threadrippers echt rondjes omheen lopen. Een zelfde stap wordt verwacht met Zen3 en Intel heeft nog nergens laten blijken dat ze ook maar enigszins bij kunnen blijven als het multi-core/thread processen betreft.

[aap]

Als Apple dus met een ARM-MacBook gaat komen, verwacht ik dat dit in eerste instantie tegenover ChromeBooks zal komen te staan (maar dan 2x zo duur) dan dat we hier echt pro-machines kunnen verwachten.

Technologisch lijkt dit voor de hand te liggen, maar marketing-technisch lijkt me dit geen slimme zet. Apple zou hiermee het signaal afgeven dat de ARM processoren low-end/"budget" zijn. Als ze ze later dan alsnog naar de Pro modellen uitrollen, dan zouden gebruikers het idee kunnen krijgen dat ze iets gaan krijgen dat inferieur is aan de Intel processoren die ze tot dan toe hadden.

Ik denk daarom dat Apple de ARM processoren pas gaat uitrollen wanneer ze dusdanig uitontwikkeld zijn dat ze beter zijn dan de Intel-processoren van dat moment. En dan eerst naar de Pro modellen brengt en dan een jaar later pas naar de Air modellen.

[Twanekel]

Maar ze kunnen er niet omheen dat huidige x86 software gewoon niet lekker zou lopen op ARM chips, waardoor ze op dat front een x86 processor van intel nooit voorbij zullen gaan. De ARM instuctieset zou er natuurlijk rete snel op lopen, maar ik zie x86 niet sneller zijn dan een i3, laat staan single core waar een heleboel x86 applicaties toch wel van houden.

[RobbieB]

Let wel dat de onderkant van de MacBook lijn ook direct Apple's grootste afzet markt is. De nieuwe Mac Pro voelt echt als een 'moetje' voor de 0,1% van Apple gebruikers die hem ooit aan zou schaffen.

De MacBook Air is by-far de meest verkochte MacBook, heck, het design uit 2010 heeft het bijna 10 jaar vol gehouden en was nog steeds 1 van de best verkopende laptops wereld wijd.

[nils83]

Ik kom de Air bijna nooit tegen in (bedrijfsmatig), bijna altijd 13inch Pro's en (minder vaak) 15inch Pro's. Heel af en toe iemand van management met een Air.

Heb je een link waaruit blijkt dat de Air "by-far" de best verkochte macbook is? Zelfs Apple geeft dat onderscheid niet weer in hun kwartaalcijfers.

[Black_Diamond768]

zolang amd niet kan leveren in de mate dat intel dit kan,
zullen ze nooit serieus genomen worden als OEM leverancier.

dat terzijde is hun driver support heel discutabel,
als ze dit een niveau of 2 omhoog kunnen brengen kunnen ze kans maken.

[kidde]

zolang amd niet kan leveren in de mate dat intel dit kan,
zullen ze nooit serieus genomen worden als OEM leverancier.

Grapjas van de dag award

-Intel blies hoog van de toren wat betreft Atom, dat succesvoller zou worden dan ARM. Bleek allemaal flauwekul natuurlijk want in Brazillie vlogen Atom telefoons in de fik; het hele Atom voor smartfoons project was ondermaats; veel te laat en stierf een langzame en stille dood.
-Alle 4G modems die Intel aan Apple leverden, waren bagger. Slechtere prestaties en vermoedelijk ca 30% hoger stroomverbruik dan die van Qualcomm.
-Alle 5G modems die Intel aan Apple en de wereld had beloofd, waren vapourware. Het enige dat Intel ooit produceerde qua 5G modem was deze fotoshop.
-Het hele 10nm-proces, dat Intel beweerde dat in 2017 aan consumenten geleverd werd, bleek t/m 2018 vapourware.
-De 1068G7, waar het hier om gaat, bleek in 2019 ook al vapourware. Zo erg zelfs, dat 22 december 2019 de 1068G7 van Wikipedia werd verwijderd (!). Dat kwam, omdat die chip toen al uit Intel's ARK verdwenen was! Tweakers bericht dat echter nu pas kennelijk; nou ja beter laat dan nooit.
-Foundry: Intel had verschillende klanten voor 14nm / 10nm. Ze gaven Rockchip geld om 14nm klant te worden, namen Altera over om niet over te lopen naar TSMC; en beloofden LG, Spreadtrum (Intel kocht hier wederom aandelen in) en Nokia, en Ericsson (allebei voor zendmasten) gouden producten. Achronix en Tabula waren ook klanten. Al die klanten zijn weggelopen, omdat Intel absoluut niet kon leveren wat ze beloofd hadden, en daarmee stierf Intel Foundry. Nokia kwam zwaar in de problemen doordat Intel haar klanten (waaronder NOK) zo gruwelijk in de stront liet zakken.
-De aantallen 14nm-producten die Intel had beloofd aan klanten, kon Intel helemaal niet leveren.

Er is maar 1 bedrijf dat absoluut 100% niet meer serieus genomen wordt door Apple als OEM leverancier, en dat is Intel.

Er is maar 1 bedrijf dat ieder jaar, keurig op tijd (!!!), aan Apple op grootte schaal levert wat Apple heeft gevraagd in de juiste aantallen, voor een relatief lage prijs: TSMC. De reden dat Apple zowel Samsung als Intel heeft gedumpt als leverancier, is omdat ze beloften niet nakwamen; TSMC wel.

Toevallig is TSMC ook hofleverancier van AMD, en AMD is alleen een ontwerpbedrijf tegenwoordig. Dus als Apple iemand serieus zou nemen als leverancier, zou het AMD zijn.

Waarom kan Apple wel grote hoeveelheden AMD CPU's krijgen als ze willen, en nota bene AMD zelf niet?

Simpel, de TSMC / Apple samenwerking werkt als volgt:
-Apple betaalt een paar miljard vooruit aan TSMC,
-TSMC reserveert gruwelijk veel productie-capaciteit voor Apple; dat is geen risico want Apple heeft al betaald;
-TSMC maakt voor Apple een chipproductie-proces dat alleen Apple krijgt (AMD, Qualcomm en Huawei dus niet), geoptimaliseerd samen met en voor Apple,
-Uiteindelijk start productie, en wat Apple vooruit heeft betaald aan TSMC krijgt Apple terugbetaald in wafers.
Het enige wat Apple hoeft te doen, is vragen of TSMC in plaats van Apple Bionic A13-maskers even een setje Ryzen-maskers in de machines wil douwen (en wat licentiegeld afdragen aan AMD), en die machines poepen Ryzen CPU's uit. De vraag naar dure iPhones is enorm gedaald, en de capa heeft Apple toch al gereserveerd en betaald.

Waarom kan AMD niet de grote aantallen bestellen, die Apple wel kan?

Simpel: Ze kunnen niet een paar miljard euro vooruit betalen aan TSMC; want dat geld hebben ze niet.

Dus het hele "AMD kan niet aan de vraag" voldoen verhaal gaat niet op voor Apple.

[Reactie gewijzigd door kidde op 22 juli 2024 13:18]

[Black_Diamond768]

grapjas van het jaar ;-)

nergens maak ik melding over design of production errors , maar als je amd's stal gaat opentrekken,
zal je evenveel vinden.

Apple zowel Samsung als Intel heeft gedumpt als leverancier, is omdat ze beloften niet nakwamen; TSMC wel.
appel intel gedumpt? waar kom jij mee af?

Vlizzjeffrey in 'nieuws: Intel lijkt Ice Lake-chips van 28W exclusief aan App...

"Nokia kwam zwaar in de problemen doordat Intel haar klanten (waaronder NOK) zo gruwelijk in de stront liet zakken. "

nokia kwam inderdaad in de problemen door hun leverancier, maar nergens zeggen ze dat dit intel is.
integendeel, intel is zelf nog steeds leverancier
indien intel hun de nek had omgedaan waren ze er toch vanafgestapt ?

https://www.fiercewireles...bles-to-rectify-situation

" daarmee stierf Intel Foundry"
ik snap niet goed wat je hiermee bedoelt, want hier zijn ze nooit mee van de grond geraakt , maar ze draaien nog steeds omzet .

[kidde]

Ok, u kan niet overal van op de hoogte zijn.

Maar goed, dat Apple Intel dumpte gaat natuurlijk over modems, en dat het bij Nokia om Intel gaat kan u vinden door te zoeken naar 'Reefshark 10nm'*. Dat Nokia niet meer met Intel in zee wil, vindt u in de 10-Q formulieren van Nokia, waarin staat dat ze op zoek zijn naar 'andere leveranciers', dat is een politieke manier om te zeggen dat ze van Intel af willen.

* https://newsroom.intel.co...ire-industries/#gs.6jinvn

[Reactie gewijzigd door kidde op 22 juli 2024 13:18]

[Black_Diamond768]

tnx voor de toevoeging!
mag ik nog vragen naar welke 10-Q formulieren u verwijst?
zijn deze recenter dan maart 2020?

heb net het artikel erbij genomen , maar nergens lees ik dat ze van intel weg willen.

integendeel,
omdat het niets opbrengt, te hoge kosten, tegenvallende resultaten,...
hebben ze zopas intel in de ontwikkeling van hun design betrokken.

https://www.fiercewireles...bles-to-rectify-situation
https://telecoms.com/5005...er-5g-weakness-admission/

-Nokia confirmed that it will remain an important customer of Intel for its 5G products despite earlier problems that were blamed by several analysts partly on the US chipmaker.

https://www.lightreading....p-suppliers/d/d-id/758008

-Nokia will also collaborate with Intel on silicon technology and ship Intel Atom-powered variants of its 5G AirScale radio access technology. Nokia will also use Intel’s second generation Xeon scalable processor in its AirFrame data centre kit, allowing for common architecutre from the cloud to the edge of 5G networks.

https://www.techradar.com...ps-with-intel-and-marvell

[kidde]

Opzoeken viel tegen; https://www.nokia.com/sys...nokia_results_2019_q3.pdf

P4, 3e bolletje. Extreem subtiel, oefening in begrijpend lezen:

"Investment areas include System on Chip based 5G hardware, including diversifying and strengthening the related supplier base"

"Diversifying the supplier base" is politieke taal voor: "Onze enige leverancier die we eerst hadden waarvan we 100% afhankelijk waren, heeft ons zo gruwelijk in de stront laten zakken, dat onze hele product-roadmap naar de Gallemiezen is, en we een tweede leverancier nodig hadden om ons te redden; omdat de eerste leverancier ook de komende tijd niet meer ging leveren wat ze beloofden".

[Black_Diamond768]

Tnx voor de referentie.

Is wel heel "begrijpend lezen" als je hieruit de conclusie trekt dat ze intel willen dumpen.

Het is nooit slim om van 1 leverancier af te hangen.
Met een extra leverancier dekken ze een SPOF in hun supply chain.

Net zoals Samsung met 2 verschillende cpu's werkt voor 1 en dezelfde gsm.

Toekomst zal uitwijzen.

[Twanekel]

zolang amd niet kan leveren in de mate dat intel dit kan,
zullen ze nooit serieus genomen worden als OEM leverancier.

In de tussentijd levert AMD voor zo goed als de hele console markt (PS/Xbox)
PS4 x = 108.9 miljoen sinds 2013
XBox One x = 46.9 miljoen sinds 2013
Dus 155,8 miljoen sinds 2013 / 7 wat zo'n 22,25 miljoen per jaar is.

Apple verkoopt zo'n 20 miljoen macbooks per jaar, ofwel AMD levert meer chips aan consoles per jaar dan dat Apple er zou verkopen.

Dan daarbij heeft Intel de laatste jaren met grote tekorten geworsteld waar AMD totaal geen last van had.
Dus onderschat niet hoeveel AMD kan leveren.

Driver support is voor Zen ook al jaren geen probleem meer, in het begin waren er wat BIOS problemen maar die zijn momenteel zo goed als allemaal verholpen. Die van de (RDNA) GPU's zijn onlangs verholpen. AMD heeft vaak wat last van kinderziektes bij compleet nieuwe producten helaas... Maar Zen valt hier niet meer onder.

[Black_Diamond768]

dat amd de console markt wilt bedienen is hun keuze,
toen hadden ze geen performance zoals nu,
dus moet je je producten kunnen afzetten tegen een zo goedkoop mogelijke prijs om mee te kunnen.
misschien hadden ze meer aandeel op de desktop markt als ze hier niet op gesprongen waren.

Console manufacturers have to keep costs low.
They want cheap hardware, which means low margins.
Intel wasn't really willing to do that. Same goes for Nvidia as well.

aantal cpus voor consoles 155,8 miljoen sinds 2013
dit is 1 kwartaal productie voor intel , om het even in vergelijking te zetten.

en ik onderschat amd niet , maar ze zijn volledig afhankelijk van TSMC ,
en bij TSMC hebben ze ook gemeld dat ze hun aantallen niet kunnen leveren (met vertraging)

https://www.techradar.com...ues-could-spoil-the-party
https://www.wepc.com/news/amd-chip-supply/

[Reactie gewijzigd door Black_Diamond768 op 22 juli 2024 13:18]

[Vlizzjeffrey]

Driver support was alleen een probleem voor gpus. Maar we moeten blij zjjn dankzij amd heeft Intel wat prijzen verlaagd.

[kneusteun]

Ik heb liever dat apple weg blijft bij AMD, heeft me al een macpro en een macbookpro gekost.
De geschiedenis AMD en Apple icm solderen is echt drama.....

[Blubkens]

Gok eerder dat het ook te maken heeft dat Intel moeite had met 10nm productie. Volgens mij moesten die ook in de MacBook Pro’s terecht komen maar is dat uiteindelijk mislukt.

https://www.extremetech.c...d-by-being-too-aggressive

[johnbetonschaar]

Dat is het inderdaad denk ik, andere fabrikanten zoals Dell hebben namelijk ook al maanden geleden modellen aangekondigd die de 1068G7 zouden moeten krijgen (XPS13 bijvoorbeeld), en die hadden eigenlijk al begin dit jaar geleverd moeten worden. Dell is ook een enorme klant van Intel, die gaan ze echt geen CPU's beloven en die dan later exclusief aan een andere klant leveren. Ik denk dat de yields gewoon dermate laag zijn voor de hoogste spec Ice Lake chips dat Intel ze simpelweg niet aan meerdere grote klanten tegelijk kan leveren ook al zouden ze het dolgraag willen.

[machiel]

Intel heeft zeker moeite met 10nm productie. Op deze manier hebben ze van een nood een deugd gemaakt. Apple heeft trouwens wel vaker snele CPUs van Intel exclusief.

[ctrl-tab]

Het lijkt me eerder dat intel wil voorkomen dat apple, niet de kleinste, met amd processoren aan de haal gaat.

[Black_Diamond768]

lijkt me eerder dat apple niet wilt afgaan met hun volgende serie vanwege thermal throttle
daarom vragen ze specifiek een cpu die ze wel kunnen koel houden?

[city17]

Lijkt me dat Apple zo'n enorm strategische beslissing niet laat afhangen van een klein voordeeltje op een enkel contract. Dat gaan ze doen (of niet), onafhankelijk van de prijzen die Intel nu vraagt.

[Nieuwevolger]

Volgens mij zij die arm cpu’s om de 15w of lagere modellen te vervangen.

[Jeroen_HD]

Een MacBook Pro met een Ryzen 7 zie ik wel zitten.

[lordawesome]

Precies. Die 28 watt meuk van Intel kunnen ze houden. 7nm AMD cpu's kunnen hetzelfde op 15 watt.

[mikesmit]

Apple heeft heel hun accessoires afgestemd rond thunderbolt. En AMD is nog geen jaar echt competitief in de lage tdp laptop markt. Nieuwe boards zijn niet in een dag ontworpen voor zulke ultra dunne laptops

[lordawesome]

En toch kun je al ryzen 4000 laptops kopen. Dunne ook. Zal wel iets achter zitten, Intel kennende. De Mac Pro had ook een 28 core xenon terwijl ze op Amd 64 cores konden aanbieden.