Bloomberg: Apple werkt aan socs met 32 cpu-cores en 128 gpu-kernen

Apple werkt aan eigen socs met 32 grote cpu-kernen en 128 gpu-kernen, meldt financieel persbureau Bloomberg. De huidige Apple M1 heeft acht cpu- en acht gpu-cores. Die soc met veel kernen is bedoeld voor een Mac Pro die binnen twee jaar moet verschijnen.

Die Mac Pro is half zo groot als het huidige model, meldt Bloomberg op basis van anonieme bronnen. Het financieel persbureau meldt al jaren betrouwbare informatie over onaangekondigde Apple-projecten en heeft een vrijwel vlekkeloos trackrecord op het gebied van Apple-informatie. De huidige Mac Pro heeft maximaal een 28-core Intel Xeon-cpu.

Voor het zover is, moet er nog een soc komen met een 16-core cpu, waarvan Apple er bij release vermoedelijk acht of twaalf inschakelt. In al die gevallen gaat het om de grote kernen in de big.LITTLE-opstelling; alle socs hebben ook vier zuinige kernen voor lichtere taken.

De huidige M1 zit in de goedkoopste Mac-producten: de Mac Mini, MacBook Air en de MacBook Pro-variant met twee Thunderbolt-poorten. Apple zei eerder al binnen twee jaar de overgang van Intel naar ARM te willen afronden. Apple heeft niet gereageerd op het Bloomberg-artikel.

Reacties (157)

[Swerfer]

32 CPU-cores... Kan de huidige software goed omgaan met meerder Cores, laat staan 32? Of is dit nog iets waar developers hun software op moeten gaan aanpassen. Tuurlijk kan je meer applicaties open hebben staan, maar je wilt de volledige power alleen hebben bij bijvoorbeeld Photoshop en kan die al met 32 cores werken?

[Eonfge]

Wisselt heel erg afhankelijk van je software die je gebruikt.

Sommige zaken zijn gewoon principieel moeilijk om over meerdere threads uit te smeren. Denk aan het berekenen van physics in games of het rippen van een CD naar Flac. Andere zaken zijn super geschikt voor multi-threading, zoals web-servers, compilers, databases, of browsers.

Soms wisselt het. Video encoding kan theoretisch heel goed over meerdere threads, maar in de praktijk zitten er nog best wat haken en ogen aan, zeker omdat veel interpolatie-frames sequentieel moeten worden berekend.

Tot slot zijn er nog OS beperkingen. Windows heeft bijvoorbeeld bepaalde CPU klustering technieken waarmee niet elke applicatie overweg kan. Was lang nooit een probleem, maar tegenwoordig zijn er 64-core threadrippers die dus tegen zulke beperkingen aan lopen.

[Reactie gewijzigd door Eonfge op 26 juli 2024 03:22]

[Swerfer]

of het rippen van een CD naar Flac.

Daar is de CD-speler de trage factor. Heb je hem in MP3 staan en je wilt naar flac, dan zou het juist heel goed multi-treaded kunnen zijn. 32 tracks tegelijk converteren, maar daar moet de software dus op aangepast zijn. Dus niet sequentieel converteren en dan ook nog eens gebruik maken van alle cores die aanwezig zijn...

[Eonfge]

Ow, maar daar doe je iets anders. In jouw voorbeeld converteer je meerdere nummers parallel.

Wat Flac niet kan doen, is 1 nummer parallel rippen. Als je een nummer van 15 minuten hebt, kun je het niet in 30 stukjes van 30 seconden converteren. Wat CD rippers vaak doen, is een twee-staps truc: Eerst rippen naar .wav en dan converteren naar meerdere .flac files.

Bron. Ik onderhoud Asunder en Flacon op Flathub.

[Z___Z]

Dat is dan toch een limitatie van de software? Weet niet of moderne compressiemethodes nog met keyframes werken. Zo ja, kan je nog steeds 1 nummer multi-threaded encoderen door simpelweg vooraf het nummer op te knippen en dan over threads verdelen.

[Eonfge]

Het is een beperking van Flac. Flac heeft geen 'key-frames' waarin het nummer wordt opgeknipt voor encoding. Voor maximaal effect wordt het hele nummer ge-encode, en daarna worden er frames gedefinieerd. Zie hier de uitleg van het formaat:

https://xiph.org/flac/format.html

In het stukje over 'Blocking' leggen ze uit dat het 1-voor-1 gebeurd:

Blocked data is passed to the predictor stage one subblock (channel) at a time. Each subblock is independently coded into a subframe, and the subframes are concatenated into a frame. Because each channel is coded separately, it means that one channel of a stereo frame may be encoded as a constant subframe, and the other an LPC subframe.

Multi-channel audio wordt gecombineerd. Op deze manier heb je 1 channel voor alle audio, en vervolgens 2 channels voor de links-rechts verschillen. Omdat hier een afhankelijkheid in zit, kun je dus ook niet links en rechts parallel doen.

[Reactie gewijzigd door Eonfge op 26 juli 2024 03:22]

[Orion64]

Mocht je veel audio bestanden tegelijk willen converteren: XRecode is 100% multi threaded, dus bij 32 cores 32 parallelle conversies, per core de voortgang via een venster representerend. https://xrecode.com/

[Eonfge]

Zie mijn conversatie met @Z___Z, want daar ga ik er al op in. Je kunt prima met Flac meerdere nummers tegelijk converteren, maar je kunt niet 1 nummer converteren met 32 processors.

[Orion64]

Dat is wat ik al eerder begrepen had, ga zelf ook redelijk diep in op audio codecs, je hebt 't goed weergegeven in bovenstaand antwoord btw.
Ik ging in op de situatie die geschetst werd waarin @Swerfer zei : '32 tracks tegelijk converteren, maar daar moet de software dus op aangepast zijn.' Voor dat scenario was mijn reactie en mijn aanbeveling.

[obimk1]

Wat overwegingen:

- Als SW en HW ontwikkelaar heb je veel meer keuzes en kun je naar een bepaalde richting toe, er is een "eeuwen oud" gezegde over PC, bedrijven die hun eigen HW en SW maken, schrijven meestal de beste SW.
- Apple heeft een enorme "berg" van geld, ze kunnen hgier veel geld ntegenaan gooien
- Als ze RISC-V implementeren (200 milliWatt @ 5GHZ), worden ze helemaal "laag verbruik" koning.


https://nl.hardware.info/...g-met-x86-arm-en-apple-m1

[supersnathan94]

Mja het probleem waar grote multinationals tegenaan lopen is dat ze niks kunnen doen met dat geld, zonder hoge kosten te maken.

Een paar jaar geleden is de US bezig geweest met een opzet voor taxreformation en die hebben Apple toe gevraagd waarom ze een lening hadden afgesloten om dividend te betalen. Het antwoord was heel simpel. “De elning die we hebben afgesloten heeft een effectieve rente van 2%. Het terughalen van geld naar de US kost 35% aan belasting. Netto levert een lening ons dus 33% extra geld op”.


Even een fyi tussendoor

[aap]

Mja het probleem waar grote multinationals tegenaan lopen is dat ze niks kunnen willen doen met dat geld, zonder hoge kosten te maken.

Fixed that for you,

Het toont aan dat het kapitalisme in deze economie doorgeschoten is, wanneer bedrijven het betalen van belastingen die ooit normaal waren als een onmogelijkheid ziet. Zeker een bedrijf als Apple die het makkelijk kan missen. Het is niet zo dat zij op de snede op prijs moeten concurreren om competitief te blijven in de markt.

Misschien moet ik mijn salaris ook in een belastingparadijs laten uitbetalen, terwijl ik mezelf in de schulden steek om eten op tafel te zetten.

[Reactie gewijzigd door aap op 26 juli 2024 03:22]

[supersnathan94]

Haha true. “Kunnen” is een groot woord. Echter toch een kanttekening:

Het toont aan dat het kapitalisme in deze economie doorgeschoten is, wanneer bedrijven het betalen van belastingen die ooit normaal waren als een onmogelijkheid ziet.

Dit is belasting op geld wat al belast is geweest. Het gaat dan om de winst die gemaakt is met verkoop in bijvoorbeeld de EU. Daar is dus al BTW en dergelijke al van afgehaald. Inkomsten belasting is dan ook al betaald. Die 35% is dan dus best raar. Dat is eigenlijk een soort invoerheffing. De VS is dan ook heel hard bezig om dat percentage lager te krijgen.

[Cerberus_tm]

Nou, zo raar is dat niet: Apple heeft over die omzet waarschijnlijk geen of nauwelijks vennootschapsbelasting/winstbelasting betaald in Europa. Alle bedrijven moeten in principe btw, inkomstenbelasting, en winstbelasting betalen. Multinationals kunnen onder de winstbelasting uitkomen, waardoor ze een enorm concurrentievoordeel hebben tegenover kleinere bedrijven. Vandaar dat ze alleen nog maar groter en groter worden. En ik durf te wedden dat ze met allerlei trucs ook minder inkomstenbelasting betalen (expats betalen bijvoorbeeld in Nederland veel en veel minder belasting dan Nederlanders, en grote bedrijven kunnen ook allerlei schillen van flexibele krachten inzetten die ook minder belasting betalen).

Dit alles mogelijk gemaakt dankzij onze bizarre belastingwetgeving, bizarre geheime afspraken tussen onze belastingdienst en multinationals, en de enorme hoeveelheid belastingverdragen met andere landen. Die zorgen er samen voor dat multinationals zo veel minder belasting betalen dan onze eigen bedrijven (en hetzelfde geldt in meerdere of mindere mate in andere landen).

[supersnathan94]

Nou, zo raar is dat niet: Apple heeft over die omzet waarschijnlijk geen of nauwelijks vennootschapsbelasting/winstbelasting betaald in Europa. Alle bedrijven moeten in principe btw, inkomstenbelasting, en winstbelasting betalen.

En dus is het ineens minder raar? Dit zijn twee losstaande dingen. Aan de ene kant heb je een land wat op ieder stuk geld dat binnenkomt zegt joehoe daar willen wij 35% van, en aan de andere kant heb je landen als NL en ierland die zeggen weet je. Misschien moet jij maar minder belasting betalen. Want dat is namelijk wat er toentertijd is gebeurd. Ierland heeft letterlijk techbedrijven gerekruteerd met lage belastingen als lokkertje.

Dus dat er daar vrijwel geen vennootschapsbelasting of winstbelasting wordt betaald is de schuld van Ierland zelf. Daar heeft de VS verder niks mee te schaften. En nu doen alsof zij dan de robin hood zijn is dan ook raar. Deze twee dingen staan totaal los van elkaar.

[Cerberus_tm]

America zegt: Apple America, jij krijgt nu allemaal geld binnen van Apple Bahamas/Ireland. Je hebt er zelf voor gekozen om dat als een aparte rechtspersoon neer te zetten. Als jij geld binnenkrijgt, moet je daar gewoon belasting over betalen. Als jij kunt aantonen dat je in een ander land fatsoenlijk belasting hebt betaald, hoef je misschien niet ook nog bij ons te betalen; maar dat heb jij niet, dus betalen. Wij accepteren geen belastingontwijking... wanneer het ons uitkomt.

[supersnathan94]

Nee dat is ondertussen aangepast naar 15% voor cash en cash equivalent en 8% voor non cash.

In 2017 is daar de TCJA voor in het leven geroepen.
https://www.taxpolicycent...-tax-and-how-does-it-work

Daarvoor werd er belast op worldwide income. Ook als daar al lokaal belasting over betaald was.

[Jan Onderwater]

Trek jij je hypotheekrente dan niet af? Dat is precies hetzelfde, gebruik maken van regelingen

[dashorst248]

Als ontwikkelaar kan ik die cores zeker goed gebruiken... Voor huidige klus: schrijven van conversiesoftware van onderwijspakket X naar onderwijspakket Y moet ik twee databases draaien, de conversiesoftware, mijn IDE en ondersteunende software. Een database draait het beste met minimaal 4 cores, de conversie software ook (dat is dus al 12), de IDE liefst met alle overige.

Natuurlijk kan je de databases op remote machines neerzetten, maar dan heb je te maken met enorme latency wat de conversie van ongeveer 2,5 uur naar ongeveer 7 uur trekt.

Of een lokale build draaien van ons pakket, die kan prima overweg met 32 threads ([code]mvn -T 32 package[/code]) aangezien ons pakket uit veel submodules bestaat waarvan er veel naast elkaar gebouwd kunnen worden.

[Cergorach]

Dus je draait nu ook al een 32 of 64 core AMD Epyc?

[dashorst248]

AMD-3950X dus 16 core, 32 threads. Maar had graag een 3970X gehad, alleen budget moet ook nog realistisch blijven.

[Cergorach]

Maar we hebben het hier over Apple, een 18 core mac $7000, een 28 core mac $14000. Waarom zijn de verwachtingen dat dit opeens zeer goedkoop gaat wezen? Een 8 CPU core, 8 GPU core mac mini is al $700, wat verwachten we dan van een 32 CPU core en 128 GPU core Mac?

[supersnathan94]

Waarschijnlijk niet, maar maakt zijn statement niet minder valide. Ik kijk er ook wel naar uit. Zeker icm 64gb unified mem pool.

[Bossie]

Dan zet je de conversiesoftware ook remote bij dezelfde cloud provider als de databases ...

[dashorst248]

Dat debugt erg lekker...

[Icelus]

Apple heeft in 2009 GCD (Grand Central Dispatch) geïntroduceerd (ook beschikbaar voor FreeBSD). Hiermee kunnen blokken code eenvoudiger als lichtgewicht threads over meerdere cores worden verdeeld en schaalt een applicatie op basis van het aantal cores.

[Maarten21]

Met Out of Order (OoO) execution heb je zelfs met single-threaded applicaties voordeel met meerdere cores.
Als ik het goed begrijp is OoO is niet geweldig op de CISC (Intel/AMD) instructieset, maar werkt dit met RISC (ARM/Apple M1) een stuk efficienter. Meerdere cores zouden dan single-threaded toepassingen ook sneller kunnen maken.
Artikel hierover: https://debugger.medium.c...chip-so-fast-3262b158cba2

Edit: @winfriedD geeft aan dat OoO binnen 1 core werkt, dus dat je met 1 thread geen voordeel hebt met meerdere cores.

[Reactie gewijzigd door Maarten21 op 26 juli 2024 03:22]

[winfriedD]

Volgens mij haal je een paar dingen door elkaar. Out of Order execution is een techniek die binnen 1 core werkt. Simpel gezegd zorgt het ervoor dat er meer instructies per tijdseenheid verwerkt worden door die betreffende core.

Single-threaded applicaties zullen door OoO execution geen voordeel hebben van extra cores.

[Maarten21]

Thanks! Ik heb het dan verkeerd begrepen.

[mjz2cool]

Zeker wel, kijk maar eens naar rendersoftware, die heeft het liefst zoveel mogelijk cores. Dit wordt in veel software ook wel leuk gevisualiseerd, vaak wordt het per vakje gerenderd, en elk vakje is dan in principe 1 core (eigenlijk 1 thread, dus bij een quadcore i7 met hyperthreading heb je 8 vakjes tijdens het renderen). Hoe meer threads je tegelijk kunt draaien, hoe sneller het renderen gaat.

[monojack]

We hebben het over de Mac en Apple heeft daar natuurlijk een applicatie voor: Final Cut Pro. Adobe zal logischerwijze volgen vermits Final Cut Pro gebruikers ook potentiele klanten van Adobe zijn.

[Menesis]

Ja deels,
Ik draai 48 cores (2x XEON).
Programma's die daar vol gebruik van maken zijn bijvoorbeeld render programma's (3DS MAX) of het compileren van code (Unity3D).
Bij het programmeren in Unity moet je ook idd actief je code geschikt maken voor multi-core setups wat soms best lastig is.

Maar bijv GTA online gebruikt dat niet allemaal 100%. Er zijn inderdaad genoeg singletread programma's, dus het is wel handig als elke core ook inderdaad snel is!

Vooral bij zoiets als de Mac Pro zal de eindgebruiker vooral multi-core programmas draaien.

[Reactie gewijzigd door Menesis op 26 juli 2024 03:22]

[iAR]

Ik heb er geen verstand van maar doorgaans heeft Apple (macOS) dit soort zaken toch wel goed op een rijtje. Of ze bieden in Xcode de juiste middelen en tools om je app zo geoptimaliseerd mogelijk aan te bieden. Correct me if I'm wrong.

[Niet Henk]

Dat heeft bar weinig met XCode te maken. Multithreaded programmeren is afhankelijk van een hoop dingen, zoals:

Schrijf je zelf low-level code, dan: hoe goed maak je zelf gebruik van meerdere threads waar mogelijk?
Schrijf je meer high-level, dan: hoe goed maken de libraries die je gebruikt gebruik van meerdere threads waar mogelijk?
Wat doe je op de computer, en kan dit makkelijk in parallel? (Bijvoorbeeld: videobewerking gaat heel makkelijk in parallel omdat veel bewerkingen op duizenden pixels/frames onafhankelijk van elkaar zijn, internetbrowsing veel minder omdat de plaatsing van elementen op een website veelal afhankelijk is van voorgaande elementen en het dus één per keer afgehandeld moet worden)

Apple heeft lang hard ingezet op iMacs en Macbooks met max 4 cores, dus programma's zijn niet noodzakelijkerwijs geoptimaliseerd voor vele cores. Daar kan Apple niks aan veranderen, behalve wachten tot de makers van deze programma's ze aanpassen. En dan alsnog gebruiken sommige taken eigenlijk per definitie weinig cores (bijvoorbeeld browsen van simpele webpagina's, of vele games waarbij één core het gros van het werk doet en meer dan 4/8 cores niet echt helpen afhankelijk van de game).

[Maurits van Baerle]

Hij heeft natuurlijk wel een punt dat het OS een gigantische rol speelt in het gebruik van de cores. Het komt niet alleen neer op een enkele applicatie die veel cores kan gebruiken.

Ik heb op dit moment in macOS een stuk of zeven relatief simpele applicaties open die samen 369 processen met 1820 threads genereren. Een beetje OS kan die last heel efficiënt verdelen over alle beschikbare cores. Zelfs als je applicaties hebt waarbij het voordeel afneemt boven bijvoorbeeld vier cores (ik heb wel eens een grafiek gezien die aangaf dat voor Final Cut Pro bij meer dan 12 of 16 cores het amper nog extra zoden aan de dijk zette) of die überhaupt niet meer dan vier kunnen gebruiken dan kun je met 32 cores dus acht 4MP applicaties allemaal vol hebben draaien voordat je in de knel komt.

Kortom, met een beetje OS (en dat zijn de drie mainstream kernels wel) heb je nog wel flink wat speelruimte aan cores voordat het geen resultaat meer biedt.

[Reactie gewijzigd door Maurits van Baerle op 26 juli 2024 03:22]

[MrHankey]

Ik ben zelf in het bezit van een iMac Pro 2017 en een Macbook Air met M1 late 2020. En ik kan bevestigen dat de prestaties van M1 on par zijn met die van de iMac Pro in reguliere taken. Daar zijn namelijk allemaal geoptimaliseerde Apps voor gekomen met MacOS Big Sur, dat is toch wel mijn verklaring hiervoor. De apps die niet geoptimaliseerd zijn, daarin is de iMac net wat sneller. Maarja, het werkt beiden echt super goed en sneller dan ik zelf werk.

Die Apple silicone lijkt dus echt geweldig. Wat je niet moet onderschatten, is het voordeel wat Apple haalt uit het gegeven dat ze nu al bijna een decennium lang laag-geklokte CPU's leveren in hardware ontwerp met een geringe termal envelope voor premium pricetags. Als ze dan wel een vette i9 Intel chip in een macbook pro zetten, dan throttled deze (duh). De iphone en ipad chips worden echter elke keer sneller, en dat terwijl de devices super dun blijven. Nu zitten die dus in een macbook. Je kan Mac alleen maar met Mac vergelijken, en nu wint M1 van intel (zo lijkt het). Een device op waterkoeling met optimale drivers gaat altijd sneller zijn dan gelijk geprijsde thin-en-lights van Apple. Maar dan moet je ook wel goede software draaien.

Dat zijn de voornaamste redenen waarom ze zulke winsten behalen met Apple silicone. CISC in een super dunne device, dat moet je eigenlijk in conceptuele zin alleen al gewoon niet willen. CISC heeft immers een hogere kloksnelheid nodig om basale instructies te verwerken. En dat terwijl Apple wel (mede) heeft geforceerd dat Intel de energiezuinige portable weg is ingeslagen (al vanaf de ultrabook). Het is echt goed, maar zo verbazingwekkend als ze het presenteren, meh. Dat komt mede door een decennium lange marketingtruc.

Dit bericht is toch wel in het verlengde daarvan. De helft zo groot als de huidige mac pro. Dat is de winst. Combineer je dat met een beetje meer performance, geoptimaliseerde software en handige benchmarks: bijna weer een reden om een nieuwe mac te kopen.

[Janspook]

einde tijdperk x86?

[jdh009]

Hoezo? AMD timmert volgens mij ook nog steeds lekker aan de weg.

[Anoniem: 368883]

AMD zou ook al met ARM bezig zijn (https://www.notebookcheck...n-the-works.507238.0.html)

Persoonlijk denk ik indertijd dat x86 op lange termijn een dood spoor is (dan spreek ik over 10 jaar of zo), en dat we een move gaan zien naar ARM. Als Intel blijft vasthouden aan zijn eigen x86 architectuur, dan wordt dat het einde voor Intel als CPU-fabrikant denk ik.

[Q]

Ik denk dat Intel op de lange termijn gewoon wel eens kan verdwijnen. Ze hebben eigenlijk alleen maar legacy in hun portfolio.

Voor mijn gevoel is de drempel om een cpu te ontwikkelen lager geworden dus ik ben heel benieuwd wat andere partijen gaan doen.

[bdbfz]

en toen ze bij Intel wilden innoveren zonder hun legacy backwards-compatibility, was het AMD die hen dwong toch voor het oude legacy platform te blijven gaan (64-bit: Intel wou Itanium pushen, grote vendors als HP sprongen mee op de kar en lieten er hun eigen chips (PA-RISC) voor doodbloeden. AMD begon met 64-bit extensies bovenop het bestaande 32-bit platform. Legacy applicaties waren veel performanter op de AMD-implementatie, en Intel moest mee. Exit Itanium...)

[Anoniem: 368883]

Je vergeet een belangrijk detail, nl. dat veel programmeurs geen volledig nieuwe instructie-set wilden leren. Vandaag speelt dat argument veel minder aangezien de gemiddelde programmeur geen assembly-language meer hoeft te kennen. Maar begin 2000 werd er nog wel regelmatig wat inline assembly code gebruikt (zeker in de multimedia/gaming wereld).

En misschien moeten we ook eens naar het prijskaartje kijken van Itanium vs AMD64 in die tijd... De eerste Itanium processors hadden een min. prijs van 1200$ in 2001 (neem even de inflatie erbij en reken zelf uit wat dit in 2020 zou zijn ), en dat is echt het goedkoopste type met de laagste specs. No way dat je de "gewone" consument hiervan kunt overtuigen, en dat had AMD heel goed begrepen.

Itanium was te duur en zijn tijd misschien iets te ver vooruit.

[Reactie gewijzigd door Anoniem: 368883 op 26 juli 2024 03:22]

[winfriedD]

En het feit dat de eerste Itanium processors nou niet bepaald erg snel waren hielp ook niet mee.
Quote van Wikipedia:

When first released in 2001, Itanium's performance was disappointing compared to better-established RISC and CISC processors.

[bdbfz]

Intel had de hardware- en OS-makers volledig mee. Windows, Linux, OpenVMS, HP/UX, en een reeks andere Unices waren beschikbaar en ondersteund, IBM, HP en anderen leverden Itanium servers. Op de desktop en laptop markt werd niet gemikt, IIRC. Hoeveel applicatie-programmeurs op (inline) assembly steunden weet ik niet, maar ik denk dat dat er ook in 2000 erg weinig waren.

De prijs was een groot probleem, helemaal mee eens. Ze mikten op de high-end van de x86 markt, plus de Unix markt, en dan mocht het wel wat kosten was blijkbaar de redenering.

Innovatie is voor durvers, maar soms slaan ze de bal mis...

[GekkePrutser]

Dat was natuurlijk ook een inschattingsfout van Intel. Het idee dat ze iedereen (inclusief consumenten en desktops) zonder meer konden laten overgaan naar Itanium, of gewoon op 32-bit laten was gewoon fout. En AMD is daar mooi op ingesprongen.

Jammer dat het zo is gegaan want het was een mooie chip. Voor HP was het ook een strop, die betalen intel nog steeds miljoenen per jaar om Itanium in stand te houden vanwege hun langetermijn contracten.

Zonde ook van PA-RISC inderdaad, was ook heel mooi spul.

[Reactie gewijzigd door GekkePrutser op 26 juli 2024 03:22]

[Spockz]

En hier komt de verticale integratie van Apple om de hoek kijken. Omdat zij focussen op het totaal plaatje kunnen ze dus de emulatie laag van Rosetta maken en daar dan ook nog eens alle features van hun nieuwe chip in gebruiken.

Gebruikersgemak/backwards comparability blijft toch heel belangrijk voor adoptie tenzij je business case zo overdonderend groot is.

[M2M]

Vergeet je niet hoeveel (custom) bedrijfssoftware vastzit op het x86 platform? Niet alles is kantoorsuite / officebewerking. "even" alles herschrijven is een no-go. Ik gok dat x86 nog lang, heel lang zal blijven. Vooral ook omdat bijna alle professionele software een veel langere levensduur heeft dan een paar jaar en blinde updates in sommige sectoren uit den boze zijn.

[Anoniem: 368883]

En daarvoor komen er emulators....

Ik weet maar al te goed hoe software-ontwikkeling werkt hoor, ik zit al 20 jaar in IT. Ik heb zowel bij multinationals als startups gewerkt, en weet maar al te goed het wereldje in mekaar zit.

Aan serverkant wordt er zelden nog in machine-specifieke talen ontwikkeld (toch niet voor custom ontwikkeling). Ofwel wordt er gebruik gemaakt van VM-based programmeertalen (Java/.NET), Scripting (Python/PHP/Ruby), en Go is ook een optie als je pure machinecode wil en die heeft goede ondersteuning voor ARM. Database-servers zullen zowat de laatste zijn om over te zetten omdat hier misschien wat extra tuning nodig is.

En voor Desktop? Een soort van virtualisatie-/emulator-laag? Ik dacht dat Apple inderdaad als zoiets deed, dus dat is niet echt de moeilijkheid. Gaming zal misschien ook wat langer blijven bestaan op x86 vanwege performance (Maar van zodra Unity, UnReal, en ID hun engines porten naar ARM is de kogel door de kerk natuurlijk).

Welk scenario heb je voor ogen dat niet in 1 van bovenstaande valt?

[Niet Henk]

Alleen heeft Apple bewezen dat je prima dit soort software via een vertaallaag op ARM kan draaien, met een beperkte performance hit (2/3de van native, dus op een moderne ARM processor sneller dan op een oude x86 processor van dezelfde prijsklasse).

Het einde van x86 CPUs hoeft dus zeker niet te betekenen dat we geen x86 software kunnen draaien, en daarom hoeft legacy software ons niet tegen te houden.

Een noot daarbij is wel dat de M1 schijnbaar aanpassingen heeft om x86-software via die laag sneller te laten werken, dus het is nog even wachten hoe snel we iets vergelijkbaars op Windows kunnen. Het heeft toch voordelen om zowel hardware als software binnen hetzelfde bedrijf te hebben.

[Snowfall]

Een noot daarbij is wel dat de M1 schijnbaar aanpassingen heeft om x86-software via die laag sneller te laten werken, dus het is nog even wachten hoe snel we iets vergelijkbaars op Windows kunnen. Het heeft toch voordelen om zowel hardware als software binnen hetzelfde bedrijf te hebben.

De M1 van Apple heeft idd hardwarematige versnellingen die x86 code uit kunnen voeren. Hierdoor hoeft Rosetta niet een hele applicatie te vertalen maar kan de M1 zowel ARM als x86 code uitvoeren.

[PPie]

De M1 van Apple heeft idd hardwarematige versnellingen die x86 code uit kunnen voeren. Hierdoor hoeft Rosetta niet een hele applicatie te vertalen maar kan de M1 zowel ARM als x86 code uitvoeren.

Dat is niet hoe het werkt.
De M1 heeft niet de mogelijkheid om x86 code te draaien.
Wat er wel in zit is de mogelijkheid om 4k memory pages te gebruiken (gewoonlijk 16k), strikte memory ordering zoals Intel en schijnbaar een instructie om Intel type status vlaggen te kunnen bepalen.
Dit zijn dingen die anders heel veel tijd kosten.

[Snowfall]

Dat is niet wat Linus beschreef in zijn uitleg hoe Rosetta 2 en de M1 werken.

https://www.youtube.com/watch?v=4MkrEMjPk24&t=1020s

Vanaf 14:00

[PPie]

Ik denk dat hij niet begrijpt wat hij dan beweerd.
De tweet die hij om 15:00 toont ‘Apple implemented the x86 consistency model’ is mijn tweede puntje.
Dat wil niet zeggen dat de M1 x86_64 draait.

Deze link is een manier on met die schakelaar te kunnen spelen:
https://github.com/saagarjha/TSOEnabler
Normaal staat deze voor ARM code uit, omdat dat betere performance levert.

De Apple Developer documentatie schrijft:

If an executable contains only Intel instructions, macOS automatically launches Rosetta and begins the translation process. When translation finishes, the system launches the translated executable in place of the original.

Dit vertalen zou niet nodig zijn als de M1 x86_64 code direct kan draaien.

[Snowfall]

O oke nouja bedankt voor t uitleggen. ik heb zelf nog niet met Rosetta hoeven spelen. Alle software die ik voor Mac heb geschreven kon ik zonder aanpassingen compileren naar de M1. Maar ik za er eens induiken. Dankjewel

[batjes]

Niet om het 1 of ander, maar het was Microsoft die dat aantoonde.

[Niet Henk]

Meh. Microsoft heeft op dit vlak weinig neer gezet.

Je kan al vele jaren x86 emuleren middels QEMU met brakke prestaties.

Microsoft heeft geprobeerd door dit te beperken tot 32-bits applicaties en door bepaalde delen vooraf te berekenen te versnellen om het praktisch toepasbaar te maken, met gematigd succes en een stevige performance impact. Hoewel ik bij de aankondigingen hierover op meer gehoopt had, viel het vies tegen naar mijn mening. Ze zijn wel aan het werken om dit te verbeteren en 64-bits applicaties te kunnen emuleren.

Apple heeft aangetoond dat door ook op hardwarematig gebied trucs toe te passen je x86 wel kan emuleren zonder onacceptabel snelheidsverlies, en zo praktisch alle applicaties kan draaien (incl. 64-bit) zonder in te leveren in user experience.

Klinkt een beetje als iPhone en tablet all over again. Microsoft had al lang smartphones en tablets op de markt zonder grote verkoopsuccessen, Apple maakte er daadwerkelijk een goed werkbaar product van. En dat laatste is het innovatieve ervan en waarom er mogelijk een einde aan x86 voor consumentenproducten aan kan komen, x86 emuleren kan al jaren, en ook lang voordat Microsoft hieraan begon.

[fapkonijntje]

Vergeet ook even niet dat de M1 uit 16miljard transitors bestaat (wel incl GPU, excl ram) en de i5/i7 die ze proberen te emuleren uit 3miljard. Dus ergens is er wel ruimte om wat kwijt te kunnen.

[Snowfall]

Ik neem aan dat je een linkje hebt waaruit blijkt dat "veel software" "in de problemen komen" of "zelfs niet draait"?

Vrijwel alle bekende pakketten zoals de gehele Adobe Creative Cloud, Resolve, Blender, Maya en CAD draaien namelijk allemaal juist super in Rosetta 2 of zijn al Native voor M1 geoptimaliseerd.

Dus ik wacht je linkje of onderzoek wel even af.

[jdh009]

Ik stel ook nergens met mijn opmerking dat ze niet met andere zaken bezig zijn. Ik meld alleen dat er bij de chipontwerpen van AMD met de zen generatie dat ze flinke stappen gemaakt hebben en dus (voor nu) nog niet afgeschreven zijn.

Er komt vast een einde aan het x86 tijdperk en durf ik mijn geld prima op in te zetten.

[Reactie gewijzigd door jdh009 op 26 juli 2024 03:22]

[We.are.cake]

Qualcomm geeft aan dat de Apple M1 chip hun samenwerking met Microsoft om Windows op ARM valideert. En een leaker geeft aan dat AMD hard werkt aan een ARM prototype om te concurreren met de M1 chip. Mensen zien de performance, de zuinigheid, en de integratie van platformen die mogelijk zijn, en gaan om.
https://wccftech.com/qual...ments-on-windows-for-arm/
https://nl.hardware.info/...reren-met-applers-m1-socr

[Janspook]

Dat mag wel zo zijn en dat ga ik niet ontkennen.
Wel is het zo dat x86 niet bepaald efficiënt is.
Er zitten namelijk heeft veel instructies in.
ARM heeft dit (nog) niet en is daar door een stuk efficiënter.
Ook gezien wat Apple nu al doet met een 8core cpu (4 high en 4 low performance cores).
Daardoor denk ik dat het einde van x86 naar is.

[okexox]

Dit is niet het einde van x86 hoor.

Het hele idee van x86 is dat er veel instructies in zitten. Dat is de RISC vs CISC approach. x86 is CISC, wat inhoudt dat het ingewikkelde operaties doet in veel clockcycles, terwijl de RISC approach van Apple/ARM focust op weinig clockcycles met simpele instructies.

Ik ben persoonlijk van mening dat er echt eens een rework van x86 moet komen die zich aanpast op moderne tijden, in plaats van constant doorbouwen op oude technologie, maar goed dat is moeilijk met backward compatibility en het aan latten passen van de industrie (apple is daar beter in dan intel/amd).

Apple heeft iets heel moois hier, maar RISC instructies hebben genoeg toekomst.

[Femme]

We weten al dertig jaar dat x86 een suboptimale instructieset is, maar omdat de hele wereld een paar decennia vast zat aan Wintel-pc's maakten alternatieven geen schijn van kans. Die hegemonie begint nu wel ten einde te lopen. Op de desktop zal de schade nog meevallen (hangt ook af van hoe serieus Microsoft is met Windows on ARM), mobile en embedded is al bijna volledig vergeven aan ARM en in cloud computing maakt ARM nu ook een opkomst. Efficiency is daar ook erg belangrijk omdat energieverbruik een van de grootste kostenposten is van datacenters. Ik denk dat we de verhoudingen in de servermarkt over tien jaar sterk veranderd zullen zijn vergeleken met nu.

Tot nu toe hebben Intel en AMD er dankzij een groot power budget en door het toevoegen van alsmaar meer complexiteit voor kunnen zorgen dat x86 de prestatiekroon in handen hield. Dit blijkt wel ten koste te zijn gegaan van de efficiency, gezien het enorme gat in performance per watt dat er is ten opzichte van de Apple M1. Het is aannemelijk dat de uitstekende performance van de M1 deels te maken heeft met het feit dat ARM-instructies eenvoudiger zijn om te decoderen dan complexere x86-instructies, waardoor er meer instructielevel parallellisme mogelijk is via strategieën zoals out-of-order execution. De M1 heeft één van de breedste execution pipelines in de industrie en is ook nog in staat om deze te voeden. Data alles ook nog super efficiënt. x86 loopt tegen grenzen aan omdat het door de variabele instructiegrootte veel moeilijker is om instructies te analyseren.

Zie voor info:
https://debugger.medium.c...chip-so-fast-3262b158cba2
https://www.anandtech.com.../mac-mini-apple-m1-tested

De vraag is of dit is op te lossen met een rework van de x86-achitectuur en of de wereld daar op zit te wachten. De licentiemodel van ARM biedt veel meer keuze en vrijheid dan het duopolie van Intel en AMD op x86-processors.

[daanb14]

Als het goed is, is daar toen toch IA-64, ook wel Itanium voor ontwikkeld? Zodat alle legacy 8086 instructies achtergelaten werden en we alleen nog verder zouden gaan met 64-bit x86 instructiesets?

[bdbfz]

En Itanium was te traag voor het uitvoeren van legacy code, waardoor AMD een performanter alternatief kon bieden met de 64-bit extensies op het bestaande 32-bit platform: amd64/x86_64. Intel heeft z'n kar moeten keren, en uiteindelijk is Itanium eraan ten onder gegaan.

[daanb14]

Klinkt alsof Itanium gewoon te vroeg uitgebracht is. Ik denk dat het in de huidige tijd meer kans had gehad dan toendertijd.

[benji83]

Het probleem is dat het grootste deel van de wereld op x86 draait. Emulatie zal nooit zo snel zijn als native draaien, waardoor veel bedrijven zullen besluiten niet over te stappen. Zolang de vraag naar x86 hoog blijft zal het erg lastig worden een nieuwe architectuur succesvol te lanceren.
Apple krijgt dit voor elkaar omdat ze enkel hun eigen ecosysteem hoeven te ondersteunen, maar ze bedienen nog altijd een niche markt.
Voor de meeste andere applicaties zal het heel lang duren voor ze echt over kunnen naar een andere architectuur. Pas wanneer er een alternatief is dat x86 code op een acceptabele snelheid kan emuleren maakt het een kans.

[dez11de]

Het grootste deel van de wereld draait op ARM.

[benji83]

Waar zie jij al die serverparken en desktops met ARM processoren?

[dez11de]

Kijk om je heen; je smartphone, je tablet, je streamapparaatje, je tv, allemaal ARM. En dan de PC op je bureau is 1 intel. Dus het grootste probleem is niet dat de wereld op x86 draait, de wereld is al over op ARM.

[Reactie gewijzigd door dez11de op 26 juli 2024 03:22]

[benji83]

De wereld draait niet op je tablet of je smartphone. De servers van de wereld, productiviteit, draait allemaal op x86. Dat je media consumeert met behulp van een ARM processor doet daar niets aan af, en dat is hetgeen waarvoor de meeste devices met ARM gebruikt worden.

[Aaargh!]

Het probleem met CISC en vooral x86, is dat je nooit het niveau van ILP kan halen als je met ARM kan omdat het lastig is CISC instructies parallel te decoderen.

[Pinkys Brain]

ARM is nou ook niet echt load store.

[RobIII]

Ik denk dat we nog héél lang x86 zullen kennen al is 't maar omdat 't zo alomtegenwoordig is. Neemt niet weg dat Apple / ARM / RISC goed hard op weg is. Dit filmpje (aanrader! ) legt het heel mooi uit. Ook eentje om in de gaten te houden is RISC V

[Reactie gewijzigd door RobIII op 26 juli 2024 03:22]

[Eggthud]

Heel informatief filmpje! Bijzonder real-time deze vernieuwing mee te maken!

[afterburn]

De hoeveelheid instructies of de complexiteit van de instructieset zegt niet per definitie iets over de efficiëntie van die ISA. Het is daarbij ook nog eens zo dat ARM erg afhankelijk is van optimalisaties in software, dus voor maximale performance zullen de applicatie ontwikkelaars aan de bak moeten. Maar netjes en geoptimaliseerd programmeren geeft winst op elke architectuur en x86 heeft ontwikkelaars lui gemaakt.

[Master Chieftec]

Het einde van x86 lijkt mij erg voorbarig. Er is heel veel (business) software in de wereld die niet werken op een ARM Windows of MacOS. Het vertalen, als bedrijven dat überhaupt daar aan willen wagen, zou tientallen jaren duren. Emuleren helpt maar dat is een tijdelijke oplossing en zeker niet gewenst in business omgevingen. Apple's M1 is gewoon een chip zoals een chip hoort te presteren in 2020. Heel efficiënt aangezien hij eerst voor mobiele apparaten werd ontwikkeld maar intussen grote stappen in performance heeft gemaakt dat hij veel, maar niet alle, x86 CPU's voorbij is gestreefd. De grote stap in efficiëncy en performance komt eerder doordat de concurrentie (lees: Intel) stil stond of minder hard ging.
Apple heeft een prima CPU afgeleverd maar ik deel de enthousiasme niet wat betreft de huidige M1 apparaten. I know, het is niet des Apple's maar ik denk dat zij een enorme gat hadden kunnen slaan om de M1 apparaten (nog) goedkoper te maken. Zij hoeven nu geen Intel CPU's in te kopen en die R&D kosten hadden zij echt wel uitgehaald met een groter marktaandeel. Zo blijven ze opereren in een niche markt en is x86 here to stay.

[klonic]

Omdat Apple op basis van ARM echt gigantische stappen heeft gezet. Wat mij betreft een stuk steviger dan AMD. Zou dat komen omdat Apple (of de partij die zij rond 2010 geloof ik heeft opgenomen) zo geniaal is of omdat ARM misschien een degelijkere architectuur is? Zelf denk ik dat het een combinatie van beide is.

Als Apple zo doorgaat met de CPU's dan zou het best kunnen dat een Macbook elke Intel chip wegblaast over een paar jaar voor AMD zal het dan een kwestie van tijd zijn. Ik heb net een tweedehands Macbook Pro 16" gekocht met i7-9750h chip, best een potente laptop maar deze en zelfs de i9 variant doet helaas flink onder voor de M1 chip ondanks dat de 16" niet hoeft te throttelen dankzij een (voor het eerst sinds een lange tijd) fatsoenlijk koelsysteem.

[monojack]

Ik denk dat het meer te maken heeft met het feit dat Apple zo'n switch kan maken. Zetten zijn alles op ARM dan zal het platform ARM worden. AMD kan er niet zomaar voor zorgen dat alle Windows gebruikers op ARM overschakelen. Zolang Microsoft niet alles op alles zet om over te stappen op ARM is er genoeg reden voor ARM om te blijven doorontwikkelen op x86

[SunnieNL]

Kip-Ei daar.. Microsoft is klaar voor ARM, ze kregen echter de performance niet uit de ARM chips die nodig is om de overstap te maken.
Wat dat betreft is Apple nu de aanjager. De CPU bouwers zien nu heel goed waar ARM chips in staat zijn en zien nu ook dat de wereld daar door Apple naar toe gaat bewegen. Die gaan dan nu een tegenhanger bouwen voor de M1 chip, die de performance heeft die Microsoft nodig heeft voor Windows. Eerder was daar gewoon geen noodzaak toe.

Microsoft kan dan aan de hand daarvan verder met een overstap en het schrijven van emulators. Voor Windows applicaties geldt dat Microsoft daar weer de kennis kan gebruiken die ze bij de xbox heeft opgedaan. Namelijk het direct omzetten van native API calls van de 'oude software' naar nieuwe calls op het ARM platform.

We gaan dus een zeer interessante tijd tegemoet, waar zeker de toekomst van Intel zeer onduidelijk is als Intel verzuimd ook op de ARM trein te stappen.

[Reactie gewijzigd door SunnieNL op 26 juli 2024 03:22]

[ALittleTooLate]

AMD is al even bezig met ARM (maar hadden tot voor kort te weining financiele middellen). NVIDIA gaat ook inzetten op ARM. Het zal mij benieuwen.

[jj71]

Tja, NVIDIA heeft ARM gekocht dus als ARM echt de mainstream gaat overnemen van Intel x86, dan zit NVIDIA gebakken.

[kamiel299]

Apple licenceerd alleen de ARM command set maar ontwerpt en bakt (laat bakken dus) z'n eigen sillicon. Ze gebruiken dus geen ARM substraat design (meer, deden ze wel) en blijven daarmee aan de bal tov NVIDEA

[jj71]

Ja, dat weet ik wel, ARM maakt zelf helemaal geen chips maar ontwerpt ze alleen, en Apple gaat verder dan de meeste andere bedrijven met het van de grond af ontwerpen van chips (de meeste andere bedrijven gebruiken direkt door ARM ontworpen cores, terwijl Apple die zelf ontwerpt - ze gebruiken alleen de ARM instructieset als basis, waar de ARM ook licentiekosten voor betalen).

Maar ik heb het niet specifiek over Apple, maar over de hele discussie hierboven: als ARM-processors steeds meer gebruikt gaan worden van telefoons, laptops, desktops (niet alleen van Apple maar ook Windows PC's) en ook servers en dus het grootste deel van de fabrikanten van hardware ARM-processors willen hebben of ontwerpen, dan was het een slimme zet van NVIDIA om ARM te kopen - die investering zullen ze dik terug verdienen.

't Gaat er niet om dat NVIDIA die chips maakt, maar ze gaan wel van al die hardwarefabrikanten geld vangen voor licenties voor het gebruiken van de ARM architectuur.

[Reactie gewijzigd door jj71 op 26 juli 2024 03:22]

[D0gtag]

Omdat Apple afstapt van x86? Toen Apple x86 adopteerde was het alleen het begin voor Apple en nu alleen het einde van Apple. Apple was bij lange na niet de grootste klant van Intel (aangezien Apple voor 2/3% van de omzet was).

[bbob]

Aan de andere kant, MS is ook bezig met windows voor arm. Nog niet echt een succes maar langzaam komt er vaart in.

[Blokker_1999]

Maar zij hebben geen invloed op wat OEMs gaan doen. Als die lekker bij x86 blijven mag MS zoveel aan de weg werken als ze willen.

[Yalopa]

Als MSFT ARM voor Windows goed in de vingers gaat hebben dan zal Azure de eerste plek zijn waar ze het inzetten gok ik. Daar hebben ze geen last van oems die al dan niet mee willen. Dan hebben ze een gigantische developer community mee, die het niet interesseert welk cpu hun code draait.

[ATIradeon8500]

Je vraagt je inderdaad af hoe de wereld er uitziet over 5 jaar met dit soort ontwikkelingen.

En ja, het kan maar zo zijn dat Intel en AMD moeten meebewegen in energie-efficiëntie én rekenkracht als ze toekomst willen houden....

[tweazer]

Ik verbaas mij nu al over ARM resultaten. Hier een 5 poorts 10Gbit switch met arm, veel servers met ARM, vmware op ARM, telefoons op ARM, apple op ARM, onbewust is x86 een zinkend schip geworden. Performance, schaalbaarheid en verbruik is waar de "ARM familie" veel meer meters maakt.

[Reactie gewijzigd door tweazer op 26 juli 2024 03:22]

[UdiBenLudi]

Vraag me wel af welke kant de gpu's nu opgaan. Gezien nVidia ARM over wil nemen/overgenomen heeft. ZIjn de gpu's van AMD en nVidia nu al compattible met ARM eigenlijk?

[djdaan]

In theorie moet het gewoon kunnen werken zolang de PCIe drivers compatible zijn gemaakt en natuurlijk de grafische drivers ook op de ARM chips kunnen werken. Deze youtuber heeft een serie waarin hij probeert GPU's werkend te krijgen op de RPi4. Tot nu toe volgens mij nog met weinig succes maar hij heeft een aantal nieuwe kaarten besteld waarmee hij nu aan het exprimenteren is.

[trogdor]

Voor Apple lijkt het daar voorlopig wel op ja.

[P_Tingen]

Leuke podcast van De Technoloog van BNR hierover:

Voor de gemiddelde computergebruiker is het allang niet meer nodig te weten wat voor processor hij onder de motorkap heeft. Toch hebben we het hier over een economische kracht van formaat. Processorfabrikant AMD leeft opeens weer na jaren te hebben gekwijnd. Apple gaat over op de ARM-architectuur ten koste van Intels x86-rekenchips. Intel krijgt in beide gevallen de klappen. Kan het bedrijf dat helpen? En is het hiertegen bestand? Wat merken we ervan in onze gadgets en wat merken we van de veranderende krachtsverhoudingen in de markt? Koen Crijns, oprichter van Hardware.info, geeft tekst en uitleg.

https://www.bnr.nl/podcas...ek-waar-de-klappen-vallen

[WienerBlut]

Herbert!! Gaat ook aardig wat jaren mee die meneer Goede podcast!

[1973booterror]

Kan mij hem nog herinneren bij Teleac volgens mij met de Atari ST

[Anoniem: 474132]

https://youtu.be/Fqfz-k0tRCI

[1973booterror]

Thx..... wordt er nostalgisch van

[Blokker_1999]

Het is welgeteld 1 platform, en dan nog niet eens het grootste computerplatform. Daarnaast moet je met vele cores ook opletten want dat betekend niet automatisch meer performantie. Voor zoveel cores wordt het zeer moeilijk om goed software te schrijven voor velen om het maximale eruit te halen. Soms heb je nood aan vele cores, soms ook gewoon aan ruwe snelheid.

[Cergorach]

Waarom? AMD heeft CPUs met 64 cores, echter ga je die niet snel in je computer doen, niet alleen qua kosten en stroomverbruik, maar ook compatibility (Epyc users ondervinden toch wel wat issues met bv. games).

Leuk dat Apple met een 32 core ARM CPU komt, maar wat heb je daaraan als Windows gebruiker of zelfs Linux gebruiker, de kans is immers groot dat je er niets behalve MacOS op kan draaien. En dan natuurlijk nog prijs, prestatie, verbruik, etc.

En als je kijkt hoe krachtig de low powered AMD mobile CPUs kunnen zijn, zelfs in een desktop environment, dat naast de prijs van een Apple ARM houd, dan zie ik nog niet snel het einde van x86...

[zonoskar]

Dat is er pas wanneer Microsoft Windows 10 naar ARM brengt met een net zo efficiente 'rosetta' implementatie voor legacy X86 software. Ik weet dat Windows 10 er al is voor ARM, maar er is nog niet veel software voor.

[kamerplant]

Op het Apple platform sowieso wel. x86 zal nog een paar jaar ondersteund worden door Rosetta 2, daarna gaat dat gekilled worden. Dan is het de vraag wat PC fabrikanten gaan doen...

[ApexAlpha]

Zolang enkel Apple zo ver is en Qualcomm of andere ARM boeren nog niet zit 'de rest' van de wereld nog met x86.

Ik vind de ARM ontwikkelingen fantastisch, maar als je die prijzen bekijkt van een Apple Macbook Air...begint bij €1200 voor een 256gb HDD en 8gb RAM.

Ik hoop persoonlijk dat het ARM licentiemodel ervoor gaat zorgen dat er flink wat meer producenten ARM chips gaan maken.

[bbob]

Ik vind de ARM ontwikkelingen fantastisch, maar als je die prijzen bekijkt van een Apple Macbook Air...begint bij €1200 voor een 256gb HDD en 8gb RAM.

Ik hoop persoonlijk dat het ARM licentiemodel ervoor gaat zorgen dat er flink wat meer producenten ARM chips gaan maken.

We moeten nog maar zien of de overname van arm door nvidia goedgekeurd wordt en wat dan de gevolgen zijn. Zou dus zo maar kunnen als nvidia nieuwe ontwerpen eerst voor zich houd en dan pas deelt dat arm in de toekomst niet echt het alternatief is.

Risc-v is aan een opmars bezig en kan dat een arm alternatief worden.

[FireStarter]

Wat ik dan echt niet snap is dat Apple ARM niet heeft gekocht, maar Nvidia.

Ze kunnen het uiteraard makkelijk. De reden is waarom hebben ze dit niet gedaan?
Om niet de opper baas te zijn?

[bbob]

Ze kunnen het idd betalen maar de vraag zal zijn of die miljarden ook terugverdiend kunnen worden. Die vraag is er ook voor nvidia die wel besloten hebben te kopen.

[Myaimistrue]

Je vindt al een M1 Air voor 1000€. Dat is voor wat je krijgt beste een zeer concurrentie prijs.

[ATIradeon8500]

snap niet dat je negatief gemodereerd wordt. Een terechte vraag die gesteld mag worden!

[DYX]

Op zeer korte termijn verwacht ik niet, maar of het de toekomst is, is inderdaad de vraag. Er is al lange tijd commentaar opde x86 architectuur ivm de schijnbaar grote hoeveel legacy die in elk ontwerp mee moet. Een AMD of Intel zit ook niet stil natuurlijk en zijn ook allang met ARM CPU's bezig. Zie ook: https://nl.hardware.info/...reren-met-applers-m1-socr

Gaan deze direct de huidige ZEN3 vervangen? Zeker niet, over 5-10 jaar? Wie weet

[iAR]

Of einde Intel? Ik heb de laatste jaren vrij weinig goeds uit die kant gehoord. En het is natuurlijk de reden dat Apple in haar eigen CPU's gaat. Meer bang for battery.

[ELD]

Dit is echt allemaal voorbarig en het is schokkend hoe goed de marketing van Apple heeft gewerkt. De M1 is een zeer goede chip en het is zeker een nieuwe goede concurrent van AMD en Intel op processor gebied. Maar in meerdere benchmarks is ook te zien dat AMD in native vs native het overgrote merendeel van de benchmarks wint zelfs in mobile vs mobile.

[Wolfos]

Valt nog te bezien hoe dit op de desktop gaat werken. De M1 Macbooks steken met kop en schouders boven de concurrentie uit maar voor de prijs van zo'n Mac Mini heb je ook een high-end Ryzen desktop. Dan moet je wel heel veel ruimte tekort komen (of veel waarde aan MacOS hechten) wil de Mac Mini interessant zijn.

[eL_Jay]

Idd, ik denk dat 128 GPU cores wel erg weinig is als je dat vergelijkt met de concurrentie die al voorbij de 10.000 GPU cores gaat.
Dat aantal haal je nu al qua CPU cores met een dual socket systeem.

128 cores VS 10.000 lijkt me nogal een verschil bij parallelle GPU berekeningen

[Reactie gewijzigd door eL_Jay op 26 juli 2024 03:22]

[Carbon]

128 cores VS 10.000 lijkt me nogal een verschil bij parallelle GPU berekeningen

GPU cores van verschillende fabrikanten kun je niet één op één vergelijken.
Voorbeeld:
De M1 GPU (8-cores) is kwa performance vergelijkbaar met een GTX 1050Ti (768 cores)

[6129(15)]

Beetje kort door de bocht niet? Je kunt de ene core niet met de andere vergelijken. Als Apple nu 1-op-1 dezelfde architectuur als Nvidia of AMD zou gebruiken, ja, dan is 128 cores weinig. Nu, het is gegarandeerd dat als als Apple voor die 128 cores ongeveer evenveel transistors gebruikt als die 10000 AMD of Nvidia-cores dat dat minstens even snel zal zijn .

[eL_Jay]

Kun je me het aan de hand van onderstaand voorbeeld misschien verduidelijken?
Stel ik heb 1 top end AMD/Nvidia en 1 top end Apple GPU om te kunnen vergelijken.

Use case:
Van 5000 bestanden gelijktijdig de AES128 encryptie bruteforcen.

Vraag:
Hoe kan Apple die 5000 'threaded' taken sneller of net zo snel uitvoeren als een gpu die voor elke taak 1 of 2 Threads kan reserveren en dat dus parallel kan uitvoeren? Want met 128 of 256 Threads Kun je toch simpelweg minder taken parallel draaien?

Moet Apple dan niet eerste de eerste 128 files bruteforcen en dan door naar de volgende 128?

Disclaimer: puur een voorbeeld ter illustratie, zal vast inhoudelijk iets niet aan kloppen

[Reactie gewijzigd door eL_Jay op 26 juli 2024 03:22]

[Snowfall]

O dit is heel simpel. Zowel AMD als Nvidia gebruiken Core Blocks. Ik neem even de 1050TI als voorbeeld.

We weten nu nog te weinig over de architectuur van de GPU om te weten hoe ze t doen maar we weten wel dat de Apple M1 25.000 concurrent threads doet.

Een 1050TI heeft 768 Cores dus 768 *16 = 12.288 concurrent threads. (een 1050TI doet per Core 16 threads) Dus de M1 heeft 2 x zoveel threads. Dus berekeningen die het tegelijkertijd uit kan voeren. Hier is een kanttekening. Een Nvidia Chip kan maar 1024 threads per GPU Block uitvoeren.

De Apple M1 heeft dus 8 GPU Cores. Dus als we 25.000/8 = 3125. Dus 1 Apple M1 GPU Core doet 3125 threads. Het kan dus zijn dat Apple er voor heeft gekozen om ipv allemaal kleine Cores te bouwen gewoon Massive Cores te bouwen die super veel threads kunnen verwerken. Uiteraard is dit allemaal theorie en kan het ook liggen aan de manier hoe Apple en Nvidia "Cores" aanduiden. Maar Zoals gezegd. Een Nvidia Chip kan maar 1024 threads aan 1 GPU Block toewijzen. Als een Apple "Core" te vergelijken is met een Nvidia GPU Block dan doet 1 Apple Core dus 3x zoveel berekeningen per keer als dat 1 Nvidia GPU Block kan doen.

Dus een Apple "Core" kan dus een stuk sneller klaar zijn dan 1 Nvidia GPU Block gewoon omdat een Core bij Apple 3x zoveel berekeningen kan doen als een GPU Block bij een 1050Ti.

[Reactie gewijzigd door Snowfall op 26 juli 2024 03:22]

[johnbetonschaar]

maar voor de prijs van zo'n Mac Mini heb je ook een high-end Ryzen desktop

De Mac Mini begint by 799 euro, dat is niet goedkoop maar om nou te zeggen dat je daar een super high-end Ryzen systeem mee kan bouwen... Laten we zeggen dat je dan toch minimaal een Ryzen 3700 wil gebruiken, en dan zit je al aan 300 euro voor de CPU alleen. Tel de rest van het systeem + een Windows license erbij op en dan is de meerprijs voor een M1 Mac Mini best te overzien en voor veel mensen prima te verantwoorden als je graag in macOS werkt.

Edit: en ja dan heb je 'maar 8GB' en relatief weinig opslag, en ja Apple upgrades zijn achterlijk duur, maar voor eenvoudig thuisgebruik hoeft dat geen probleem te zijn.

[Reactie gewijzigd door johnbetonschaar op 26 juli 2024 03:22]

[Wolfos]

Tja, als je de opslag wilt verdubbelen naar 512GB (wat nog steeds niet veel is) ben je al €1029 kwijt. Daarvoor heb je toch echt wel een machine die de Mini aan alle kanten voorbij schiet.

[Reactie gewijzigd door Wolfos op 26 juli 2024 03:22]

[Q]

Afgaande op alle benchmarks en reacties van eigenaren is de M1 echt een mijlpaal.

Dus als nieuwe producten uitkomen met deze zwaardere CPU dan ga ik voorspellen dat in de komende jaren Apple voor het eerst sinds tijden meer marktaandeel gaat pakken in de desktop/laptop markt.

Als je naar het grote plaatje kijkt dan lijkt op de lange termijn x86 ten dode opgeschreven. Niet puur door Apple met de M1 en toekomstige processors.

Ook zie je dat de grote cloud boeren zoals AWS hard bezig zijn met eigen ARM-based processoren. Die resources zijn goedkoper voor klanten, dus er is een reden om die dingen te benutten.

En als je app op ARM draait in de cloud, misschien wel fijn dat je developers ook op een ARM-based CPU zitten...

Tweakers werkt momenteel hard aan een Apple M1 producten review maar dat voelt een beetje laat: de rest van het internet heeft alle info al lang en breed gepubliceerd en ‘has moved on’.

[Reactie gewijzigd door Q op 26 juli 2024 03:22]

[himlims_]

vind dit een mijlpaal; https://www.eetimes.com/m...ple-m1-and-arm-cortex-a9/

5ghz op 1.1 volt

[Wolfos]

Alleen indrukwekkend als je naar het stroomverbruik kijkt. Hij mag dan wel op 5GHz draaien maar 10,000 coremarks stelt niks voor.

[watercoolertje]

Wel per watt natuurlijk...

Het valt of staat met het wel/niet kunnen opschalen.

[GENETX]

Wat ook zo interessant is, is dat de AMD Ryzen 4000-serie significant efficienter is dan de Apple M1 in deze test, en dan is dit nog de 4700U ipv een nieuwe 5800U met Zen3!
https://nl.hardware.info/...g-met-x86-arm-en-apple-m1

[madcow22]

Ik denk dat apple voorsprong met die chip meer voorkomt uit dat hun de enigste zijn met 5nm. Terwijl de rest op 7 - 10 nm zit.

[Bigs]

Ik denk dat er wel een interessant versterkend effect kan ontstaan tussen al deze ARM ontwikkelingen. Buiten grote organisaties lijkt de inzet van AWS Graviton instances nog niet echt hard te gaan omdat het gebaande x86-64 pad op dit moment nog voor de hand ligt voor veel mensen. Ik moet zeggen dat ik wisselende ervaringen heb: .NET core applicaties draaien prima met uitstekende performance/€ verhouding (T4g vs T3), maar met Ruby vielen de prestaties tegen en liep ik zelfs tegen een interpreter bug aan die tot segfaults leidde.

Als straks hordes developers een Apple Silicon Mac (met Docker) hebben dan zal ARM nog meer aandacht krijgen dan het nu doet en het zou het me niet verbazen als er van onderuit een push komt om meer op ARM te gaan uitrollen. Voor techneuten leuk nieuw speelgoed, voor managers een bescheiden besparing. De invloed van Apple kennende zou dit zelfs Windows on ARM uit het slop kunnen trekken.

[Q]

Precies, de M1 gaat denk ik om die reden echt als katalysator werken voor veel software om ook goed te werken op ARM-processoren. En dat gaat zichzelf zo versterken, precies zoals jij aangeeft.

[lordawesome]

Klinkt aardig, maar x86 heeft toch echt al een tijdje 64 core cpu's. Laat staan in dual of quad-socket moederborden.

[Carbon]

Klinkt aardig, maar x86 heeft toch echt al een tijdje 64 core cpu's.

Idem voor ARM
Ampere Altra met 80 of 128-cores
Amazon Graviton2 64-cores

Wat is dan wel interessant?
1. Geïntegreerde GPU
2. Unified memory, maw geen dedicated VRAM
3. De ARM cores zijn sneller en efficiënter dan die van de ARM concurrenten
Uitgaande van de M1
4. h264/h265 hardware codecs
5. Neural engine

[Gustaaf437]

Het interessante is dat de single-core performance van de M1 echt top is en dat het erop lijkt dat die performance ook makkelijk vermenigvuldigd kan worden. Bij Intel en AMD wordt de kloksnelheid teruggeschroefd naarmate er meer cores aanwezig zijn vanwege de hitteproductie. Omdat Apple's processoren zo goed omspringen met hitte zal dit veel minder (en misschien wel niet) nodig zijn. Dan heb je met 32 cores al snel een monstermachine.

[lordawesome]

Zijn die dingen interessant? Een 32 core cpu lijkt me bedoeld voor een Mac Pro. Dan kun je vervolgens niks aanpassen. Je geheugen niet, je gpu niet, zelfs je cpu niet. Een losse cpu en gpu en is ook gewoon sneller dan een alles-in-een versie. En stroom maakt niet uit in een workstation.

Kijk, in theorie zou dit goedkoper moeten zijn omdat het een sock is, maar Apple gaat hier natuurlijk weer een echte Appleprijs voor vragen.

[Carbon]

Zijn die dingen interessant?

Niet op zich maar wel als het allemaal in één package zit

Een 32 core cpu lijkt me bedoeld voor een Mac Pro.

Of een iMacPro

• Dan kun je vervolgens niks aanpassen. Je geheugen niet,

Unified memory impliceert niet dat je het geheugen niet kunt uitbreiden!

Een losse cpu en gpu en is ook gewoon sneller dan een alles-in-een versie.

Waarom denk je dat?
Met een losse GPU moet data van/naar de GPU via de PCI-bus en dat is verre van optimaal
Een ander probleem is de beperkte hoeveelheid VRAM en de workarounds zijn allerminst efficient

En stroom maakt niet uit in een workstation.

Meer stroom is meer warmte ontwikkeling en koeling is helaas niet silent

[Reactie gewijzigd door Carbon op 26 juli 2024 03:22]

[wifikabelhuren]

Ben benieuwd wanneer die pro's op de markt komen, degene die ik nu heb (pro 2015) is wel aan vervanging toe maar dan wacht ik liever nog even.

[mkools24]

Het bekende, wachten met een televisie kopen want volgend jaar zijn ze weer beter/goedkoper

[MiesvanderLippe]

Het rumoer is dat er een 14" en 16" model komen in dus nieuwe bodies. Met een 2015 model kun je gerust nog even wachten, dus waarom niet even uit zitten tot het duidelijk is wat ze doen?

[laptopleon]

Het bekende, wachten met een televisie kopen want volgend jaar zijn ze weer beter/goedkoper

Nu wachten op de pro's met een M-chip. Daarna wachten op het tweede model, omdat er altijd kinderziektes in de eerste versie zitten..

[Gustaaf437]

Het zou me niet verbazen als Apple wacht met de 16" MacBook Pro, de iMac en de Mac Pro totdat zo goed als alle pro-level software ook geschikt is voor Apple op ARM. Denk aan Docker, Adobe apps etc. De onderlaag van Apple's productlijn is voor huis-, tuin- en keukengebruik. De software die Apple voor die doelgroep voor ogen heeft kan redelijk makkelijk om en dus konden ze snel hun eigen chips in die hardware zetten zonder dat de gebruiker iets merkt. Als je echter werkt met software die nu nog niet op ARM Macs werkt of verre van ideaal werkt op die modellen, dan wacht je toch al en heeft het voor Apple geen zin om die modellen nu al te upgraden. Grote kans dus dat Apple ergens in september pas met echte pro ARM-Macs komt.

Een tweede dingetje is misschien nog dat Apple de pro-Macs intern iets meer wil optimaliseren. De huidige ARM-Macs zien er intern niet helemaal des Apples uit. Eigenlijk heeft Apple alleen zijn eigen SoC in het huidige ontwerp gezet en daarmee snel nieuwe modellen uitgebracht, zonder bijvoorbeeld de Mac Mini of MacBooks kleiner/platter te maken wat wel zou kunnen.

[6129(15)]

Een tweede dingetje is misschien nog dat Apple de pro-Macs intern iets meer wil optimaliseren. De huidige ARM-Macs zien er intern niet helemaal des Apples uit. Eigenlijk heeft Apple alleen zijn eigen SoC in het huidige ontwerp gezet en daarmee snel nieuwe modellen uitgebracht, zonder bijvoorbeeld de Mac Mini of MacBooks kleiner/platter te maken wat wel zou kunnen.

Dit is dus een van die dingen die me enorm opviel bij de teardowns en waar ik geen enkele pro-reviewer over heeft gebabbeld: De componentendichtheid op de M1 logic boards is bizar laag. In 2015 heeft Apple enorm veel moeite gestoken in het ontwerpen van een logic board met zeer hoge componentendichtheid: De 12" MacBook. In de huidige M1-lineup zie je hier niets van terug. M.a.w. het is duidelijk een kwestie van niet willen i.p.v. niet kunnen. Ik ga niet zeggen dat ze de performance van een Mac Pro in een Mac Mini-behuizing kwijt kunnen maar een Mac Pro die half zo groot is met méér performance? Geen probleem denk ik.

[Henk Poley]

Er is ongeveer een 8x verschil in performance tussen de M1 en Nvidia's RTX 3090.

Van 8 (5848 mW) naar 128 GPU cores is 16x.

Dus ~95W, maar zo'n grotere interconnect bus wil natuurlijk ook nog wat. Wel heeft Nvidia nog even de tijd om hun TDP omlaag te brengen van 350W.

[Reactie gewijzigd door Henk Poley op 26 juli 2024 03:22]

[Hamoudi1995]

Apple is goedbezig, ik ga vanuit dat Macbook pro extreem sterk wordt.