Bloomberg: eerste ARM-soc van Apple voor Macs heeft twaalf cores

Apples eerste Mac met een ARM-processor krijgt naar verluidt een soc die op 5nm wordt gemaakt en twaalf cores bevat. Het gaat om acht krachtige cores en vier zuinige cores. Het is nog niet duidelijk of het om een MacBook of iMac gaat, maar een laptop ligt voor de hand.

Bloomberg geeft voor het eerst technische details van de ARM-soc die Apple zou gaan gebruiken in een Mac. Volgens het financiële persbureau, dat bekend staat om zijn goede bronnen binnen Apple, gaat het om een soc die is gebaseerd op het ontwerp van de komende A14-soc voor iPhones, maar dan met meer cores. De soc zou acht krachtige Firestorm-cores krijgen, aangevuld met vier zuinige Icestorm-cores. Ook is de soc voorzien van een gpu, maar details daarover zijn nog niet bekend.

Volgens de bronnen van Bloomberg is de soc 'veel sneller' dan die voor iPhones en iPads. Het ligt voor de hand dat de soc voor pc's niet alleen meer cores heeft, maar ook hogere kloksnelheden haalt, omdat het energieverbruik hoger kan zijn dan bij passief gekoelde smartphones en tablets. Apple gebruikt in zijn huidige iPad-socs maximaal vier krachtige cores en vier zuinige cores. Bij iPhones is dat twee en vier.

Het is nog niet duidelijk in welk apparaat Apple de ARM-soc stopt. Volgens Bloomberg komt er volgend jaar op zijn minst één Mac met de nieuwe soc. Dat zou zowel een iMac als een MacBook kunnen zijn. Het is aannemelijk dat het om een MacBook gaat, omdat ARM-socs zuinig zijn en ook de configuratie met snelle en zuinige cores lijkt op een laptopprocessor te wijzen. Naar verluidt gaat TSMC de chip maken op een 5nm-procedé.

Volgens Bloomberg werkt Apple onder de codenaam Kalamata aan meerdere socs en worden varianten met meer cores overwogen. Apple zou van plan zijn om jaarlijks een nieuwe soc voor Macs te ontwerpen, net zoals dat nu gebeurt met socs voor iPhones. De ontwikkeling van socs voor iPhones en Macs zou dan gelijk lopen. Apple gebruikt sinds 2005 Intel-processors voor zijn Macs. Door eigen chips te maken is Apple niet meer afhankelijk van de ontwikkelingen bij Intel.

Door Julian Huijbregts

Nieuwsredacteur

23-04-2020 • 14:23

97 Linkedin

Submitter: robcoenen

Reacties (97)

97
91
67
5
0
20
Wijzig sortering
Het grote punt blijft toch: dit zijn geen x86 processoren. Dat betekent dat er of een (trage) emulator gebruikt moet worden of alle software opnieuw gecompileerd zoals dat met de PowerPC naar x86 transitie in 2005 ook gebeurde. Nu zal dat voor Apple zelf niet zo'n probleem zijn vanwege hun iOS ervaring; maar ik vraag me af hoe leuk softwareontwikkelaars voor de toch al kleine markt van Mac PC's gaan vinden.
Dit zal per applicatie van een aantal punten afhangen. Heel veel ontwikkelaars ontwikkelen binnen het Apple ecosysteem (App store en Xcode). Voor deze ontwikkelaars zal het triviaal zijn, waarschijnlijk gewoon een vinkje in de IDE.
Volgens mij is het ook zo dat als je je applicatie distribueert via de App store je de broncode meestuurt naar Apple. Op deze manier is het voor Apple al heel makkelijk om programma's functioneel te testen op hun nieuw systemen en te zorgen dat dingen compatible blijven. Dit testen doen ze vaak ook al voor App store goedkeuring.

Ontwikkelaar binnen het Apple ecosysteem maar dan de wat geavanceerdere/specialistische programma's (drivers, graphics, compute, etc) zal het wat lastiger zijn. Grote delen (zoals UI) zullen makkelijk te porten zijn, maar de kern van hun programma's zal maatwerk worden.

Dan heb je nog een hele berg open source wat buiten het Apple ecosysteem valt (denk Homebrew, MacPorts of zelf gecompileerd spul). Dit zal waarschijnlijk ook triviaal zijn omdat dit soort projecten vanuit een open denkwijze zoals Linux opgezet zijn en daar vaak ook probleemloos op ARM e.d. compileren. Terminal applicaties in b.v. Go kan ik nu ook al op mijn Mac voor Linux en ARM compileren, vanuit dezelfde code in hetzelfde gemak als native. Daarnaast zijn programma's in scripttalen zoals Python ook geen probleem.

De grootste afvallers gaan waarschijnlijk games worden (ja er zijn mensen die gamen op de Mac). Weinig studio's zullen er heil in zien games opnieuw te compileren voor een andere CPU architectuur (bovenop de al verschillende OS architectuur). Veel oude games zijn de slecht of niet meer speelbaar. Games op meer generieke engines zoals Unity zullen waarschijnlijk wel iets betere support krijgen.

Ook specialistische applicaties buiten het Apple ecosysteem (die geen gebruik maken van Apple frameworks) zullen er denk ik heel lang over doen geport te worden. Die zullen eerst willen zien hoe groot het marktaandeel gaat zijn.

Daarnaast worden steeds meer applicaties in cross-platform frameworks zoals Electron geschreven tegenwoordig. Dat zijn in feite web pagina's als applicatie. Die zullen net als scripttalen makkelijk te porten zijn (dat is ook de hele reden dat dit soort frameworks gebruik worden). Maar die mogen wat mij betreft sterven.
Sterker nog; als je bitcode aan hebt staan kan apple in sommige gevallen ( bij geen gebruik maken van swift/ARC) zelf de app al omzetten naar ARM.

Hier een experimentje:
https://www.highcaffeinec...Intel-macOS-Using-Bitcode
Volgens mij is het ook zo dat als je je applicatie distribueert via de App store je de broncode meestuurt naar Apple
Niet de broncode maar een soort intermediair formaat tussen jouw code en de machinetaal van de processor. Bitcode noemt Apple dat.

Dit is vergelijkbaar met hoe Java en .NET applicaties naar bytecode gecompileerd worden, met als verschil dat bitcode door de App Store naar machinetaal word gecompileerd.
Nee. Bitcode is niet vergelijkbaar met bytecode van Java en .Net. Java en .Net bytecode is machine onafhankelijk.

Oude Java bytecode kan door moderne JVM's vertaald worden en draaien op een 64 bits architectuur. Het is dan ook een relatief high-level formaat.

Bitcode is echter een architectuur specifiek formaat waarin ze eigenlijk alleen binnen de architectuur kleine optimalisaties kunnen doorvoeren. Bijv. het toepassen van een nieuwe instructie. Ook gebruiken ze de bitcode om applicatiecode server-side cryptografisch te kunnen signen zonder de keys aan de ontwikkelaars te hoeven uitleveren.

Zo is met bitcode het niet mogelijk om te wisselen van 32-bit naar 64-bits architectuur: daarvoor moet je alsnog verschillende bitcode files aanleveren. Zie bijv. dit artikel over bitcode.

Het is dus niet mogelijk om te switchen tussen ARM instructieset en x86 instructieset enkel op basis van de bitcode voor één target architectuur.
De grootste afvallers gaan waarschijnlijk games worden (ja er zijn mensen die gamen op de Mac). Weinig studio's zullen er heil in zien games opnieuw te compileren voor een andere CPU architectuur (bovenop de al verschillende OS architectuur). Veel oude games zijn de slecht of niet meer speelbaar. Games op meer generieke engines zoals Unity zullen waarschijnlijk wel iets betere support krijgen.
Dit is al voor een deel gebeurd. Nadat Mac OS 32bit applicaties in de ban deed, zijn veel oude games niet meer ondersteund en zelfs open source en community projecten hebben Mac losgelaten omdat alles naar 64bit herschrijven niet te doen is.

Hier al een eerdere discussie daarover:
reviews: Apple macOS 10.15 Catalina - De iPad wordt Macs schermkompaan
Juist veel, want nu kan je games maken die gelijk voor iOS en MacOS werken, het enige wat anders is is de besturen..

Dit kan juist er voor zorgen dat games (niet alle natuurlijk) meer naar Mac/iOS komen..
10.15 is de eerste versie in jaren waarbij ik niet gelijk ben geupgrade. Als ik bij 'Legacy Software' kijk zou ik alleen wat oude games verliezen die 32bit only zijn. Maar ben huiverig dat er nog andere dingen die opeens niet meer blijken te werken. Zo'n tooltje wat je een keer in de X maanden gebruikt maar op zo'n moment echt onmisbaar is. Dus ik kijk de kat nog even uit de boom.
Ik zit met precies dezelfde gedachten / vrees. Heb ook nog niet geupgrade.
Ditto. Ik heb geen windows game-pc staan en game heel incidenteel op de macbook. Meestal wat oudere indie titels die dus niet 64bit compatible zijn. Bootcamp is net teveel gedoe voor incidenteel maar om nu maar een groot deel van mijn steam catalog als verloren te beschouwen voelt ook niet goed.
Via Systeem Voorkeuren -> Over deze Mac -> dacht verouderde software zie je 32 bits apps etc.

Heb nog niet meegemaakt van tooltjes die niet meer werken en anders kan je voor die ene keer in het jaar een virtuele Mojave draaien via parallels toch :)
haha kan je nog wat toelichting geven op het mogen sterven van de webapps?
Tuurlijk, vaak zijn dit soort apps traag (met opstarten en UI lag) en log (veel CPU en memory verbruik). Daarnaast wijken ze vaak af van de standaard UI elementen van het OS (macOS in mijn geval) wat ik persoonlijk heel storend vind omdat ze verwacht gedrag niet implementeren (zoals elke andere app op macOS dat wel doet). Dit zijn vaak kleine dingen, zoals tab volgorde, file save dialog of keybindings. Maar als je hieraan gewend bent als keyboard poweruser dan voelt het vaak dat je aan het worstelen bent met zo'n applicatie.

Met het risico te veel als een fanboy te klinken, ik merk vaak het verschil tussen een app geschreven door een Mac gebruiker en niet Mac (bv Windows) gebruiker. Die van een Mac gebruiker volgt een bepaald patroon wat je herkend in veel Mac applicaties. Niet dat het andere slechter is, maar gewoon anders dan je gewend bent.
En dit soort electron apps (omdat ze vaak ook cross platform zijn) wijken kwa interactie vaak totaal af van wat ik gewend ben. Deels omdat het niet te veel moet afwijken van hun Windows of Linux tegenhanger maar deels ook omdat de developers niet weten hoe een app op Mac zich gedraagt of gewoon te lui zijn om Mac specifieke frameworks te gebruiken voor standaard dialogen.
Ik denk dat ze er daarom goed aan doen. Gaming op de mac was toch al redelijk dood. (Ik type dit op een Macbook Pro, heb ook een game pc met windows)
Ik heb dus geen windows pc om te gamen. Macbook voldoet prima voor wat indie games.
Apple is ook al bezig om iOS/iPadOS/macOS development dichter bij elkaar te trekken. Het kan dus heel goed zijn dat sommige dingen juist eenvoudiger worden.

Daarnaast maakt het voor de specialistische (zoals development of grafische) software niet zo heel veel uit. Voor hen is het niet een "kleine markt", maar hun voornaamste markt.
Dat de grafische markt voornamelijk op Mac zat is al lang verleden tijd.
Ja, maar dat is ook de andere kant opgeslagen. Je ziet steeds meer Macs in andere type organisaties en deze accepteren het steeds meer, zeker waarbij men BYOD hanteerd...
Moet je wel de software kunnen draaien.
De huidige macs kunnen ook windows draaien.
Een significante hoeveelheid bedrijven hebben alles in de cloud draaie. Het zijn of webapps of het wordt benaderd door Citrix (of iets dergelijks). De Office versie voor Mac is nog niet 100% gelijk aan die van Windows, maar mensen kunnen er prima mee werken (tov. de oude Office for Mac 2008/2011 versies)...
Sterker nog, nu Apple cuda/nvidia weg probeert te jagen van MacOS zie ik om me heen mensen zelfs de overstap van MacOS naar windows maken, de mate van beperkingen die Apple nu inbouwt op MacOS (driver en software beperkingen) zijn zaken waar je als pro gebruiker niet echt blij van wordt.
Helaas is dat nog steeds het geval. Fonts werken nog steeds slecht op Windows. Hele aparte rendering, check bijv. Adobe XD of zelfs in de browser. Daarnaast ook veel apps zoals Sketch, alleen beschikbaar op Mac.

Voor echt grafisch werk is Mac bij uitstek vaak wel beter. Video is mixed. En 3D is toch echt puur Windows en soms voortaan Linux.
Oude klant gebruikt alleen maar Macs met een BIM Server voor grafische designs.
Is dit tegenwoordig al te doen op Windows?

[Reactie gewijzigd door mrooie op 24 april 2020 07:10]

@unglaublich Ik maak me wel zorgen om de ontwikkeling van mijn huidige softwarepakketten. Hier neemt Apple namelijk heel veel regie, terwijl ik niet elk jaar een nieuwe versie van een weer een nieuw OS wil maar ook langer wil door werken met gekochte software pakketten, mogelijk ook buiten de appstore. Hopelijk komt er een model dat je zelf app’s en het OS kunt downloaden en later kunt (her)installeren. Apparatuur verouderd maar dat betekent niet dat het na een paar jaar afgeschreven is. Bepaalde systemen, video, audio, drukwerk, en apparatuur zijn getweaked en updaten ligt hierdoor niet altijd voor de hand.

Ik hoop dan ook dat het mogelijk blijft om het oorspronkelijke OS te kunnen installeren. Met ipadOS is dit “downgraden” niet mogelijk.

Of blijft Apple toch trouw aan hun MacOS als high-end model?
Je kan een CMD+R opnieuw installeren uitvoeren komt het oorspronkelijk geleverde OS bij de Mac weer tevoorschijn en kan die weer geïnstalleerd worden.

Microsoft en ook Apple willen het distribueren via de Stores toejuichen om zo devices via 1 route apps te updaten en te installeren (Mobile Device Management a la Intune en Apple DEP)

Aan de andere kant de leveranciers (Apple en Microsoft bijv.) blijven de hekkensluiters en hun bepalen de voorwaarden.
Dit is eigenlijk ook weer een slechte zaak door monopolie maar als systeembeheerder is het aan de andere kant fijn om de stores opdrachten te geven installeren xyz.
Ook apps updaten automatisch mee ipv losse software pakketten wat zoekt naar software updates.

Hopelijk blijft het buiten de Stores om mogelijk full desktop apps installere want heb al eens meegemaakt dat een App Store programma weinig functionaliteiten had en heel erg gecomprimeerd was het leek net een web app..

[Reactie gewijzigd door mrooie op 24 april 2020 07:18]

Hun voornaamste markt, maar je moet wel opeens twee stukken software ontwikkelen & bijhouden ipv maar een :p

[Reactie gewijzigd door thomaskoel op 23 april 2020 15:01]

Niet perse:

- macOS x86
- iPad

Straks:

- macOS/iPad Arm
- macOS x86

In de ideale situatie dan.
Een fat binary die zowel x86 als ARM onder MacOS ondersteunt lijkt me waarschijnlijker dan dat. Verreweg de meeste software doet helemaal niks met processor instructies, maar het is de compiler die dat regelt.
Mijn gevoel: dat zal vlot gaan of Apple zou het niet doen. Ze hebben genoeg ervaring met grote moves: PowerPC naar Intel zoals je zegt, maar ook Motorola naar PowerPC, OS 9 naar het Unix-achtige OS X, ach zelfs Objective-C naar Swift.
Met Clang/LLVM als compiler maakt processorarchitectuur sowieso minder uit.
Verder hebben ze voor iOS ook iets als Bitcode waarmee ze zelf je app die je als developer releaset kunnen hercompileren (als je dit niet uitzet), specifiek voor elke cpu.
Rest de vraag of applicatie-ontwikkelaars alweer mee willen gaan. PowerPC > Intel werd alleen gedaan omdat IBM en Motorola/Freescale geen snellere chips meer konden leveren op de gewenste termijn, niet omdat Apple zin had om te switchen vanwege het switchen. De voornaamste reden om de Mac naar ARM te switchen is controle.
Anoniem: 84766
@field33P23 april 2020 15:05
Meeste developers programmeren tegen de SDKs van Apple. Deze zijn al cross-platform, dus opnieuw compileren met x86 en ARM als target is klaar.
dus even voor de duidelijkheid: Je kan geen native Mac OSX x86/x64 apps draaien op een ARM Sock.het word
Alleen gemakkelijker gemaakt om een programma te maken om je x86/x64 te compilen naar het ARM platform van Apple.Dus het zijn geen Desktop Apps zoals je die kent van de macOS.

de versie van OSX x86/x64(macOS) zal opnieuw moeten worden geschreven voor de ARM sockets.


dit is ook Precies wat Microsoft met Windows aan het doen zijn met het Windows Universal Platform, maar is daar al sinds Windows 8 mee bezig.

[Reactie gewijzigd door solozakdoekje op 23 april 2020 15:57]

Wat bedoel je met “zal opnieuw moeten worden geschreven”? Ik verwacht dat het overgrote deel met een recompile klaar is. En als je je app als bytecode hebt gesubmit, is zelfs dat niet nodig.
Byte code draait op een virtual machine. Dat is een interpreter die binaire code accepteerd in plaats van broncode, zeg maar. De byte code is dus geen native code maar iets wat er tegenaan zit. De besturingssystemen en sommige zijn echter wel naar native code gecompileerd en kunnen dus niet zomaar gedraaid worden. Ik hoop dat het nu wat duidelijker voor je is.
Jeetje. Ik snap niet eens wat je probeert te zeggen allemaal.
Volgens mij begrijp je totaal niet wat anderen je proberen duidelijk te maken. Moderne applicaties worden grotendeels in high-level programmeertalen geschreven en de broncode hiervan is derhalve niet specifiek voor welke processorarchitectuur dan ook.

Wat wel het geval zou kunnen zijn, is dat er bepaalde aanames over de instructieset gedaan zijn of dat er bepaalde stukken code in assembly geschreven zijn en dat er daarvoor enige aanpassingen gedaan moeten worden.

Dan nog is er meestal een generieke code die overal zou moeten werken met weliswaar verminderde prestaties, maar dat is tegenwoordig vaak toch nog snel genoeg.

Misschien verbaast het je, maar buiten de gemeenschap van Windows ontwikkelaars zijn er heel veel ontwikkelaars die al jaren software schrijven voor Android en iOS met ARM als de primaire instructieset. Ook voor Linux wordt er tegenwoordig ontzettend veel aan ontwikkeling voor ARM gedaan.

Dit zou een verklaring kunnen zijn voor het feit dat Windows op ARM maar niet van de grond komt, terwijl het ook in Visual Studio slechts een kwestie is van de target veranderen van x86-64 naar ARM64. Dat dit niet gedaan wordt, zegt inderdaad veel over het momentum dat Windows lijkt te hebben.
"Voor ver ik het begrijp is bytecode een compiler"

In andere woorden, ik heb geen idee waar ik het over heb, maar ik probeer wel mee te lullen.

"Microsoft ouderwets en bekend staat door het krakende geheugen geluiden"

Wauw, dat slaat echt als een tang op een varken.
Volgens mij wil Apple switchen omdat intel al heel lang geen significante vernieuwingen laat zien op hun mobiele platform. En als er een update komt, is dit beschikbaar voor alle vendors, waardoor het onderscheidende vermogen van een macbook erg klein blijft tov van de concurrent.
Voornaamste reden is dat Intel totaal niet innovatief meer is. Nu dat de bean counters aan de macht zijn, ipv de engineers, is hun competitive advantage volledig aan het verdwijnen.

Apple kan daar niet mee leven. Ze worden nu beperkt in hun mogelijkheden, door de afhankelijkheid van externe partijen. Ze hebben inmiddels geld en ervaring genoeg om zelf aan de slag te gaan.

Ik ben geen Mac gebruiker maar ben heel benieuwd waar ze mee gaan komen.
Iets wat de meeste Mac gebruikers totaal geen punt vinden. Bij Windows is 30 jaar backwards compatibility zowaar het enige wat het platform in leven houdt, maar Mac heeft altijd veel minder ruimhartig omgesprongen met gebruikers welke traag updaten.

Daarnaast, dit is ideaal voor Apple, eindelijk eens stoppen met al die software die gebruikers zelf installeren. Liever alleen maar software via hun marketplace verspreiden.
Dat laatste is volstrekte onzin als het om MacOS gaat, een uit de mouw geschudde aanname. Waarom zou Apple dat omgooien voor hun Desktop omgeving? Je hebt hier met een totaal ander apparaat te maken t.o.v een Smartphone of iPad.
Waarom zou Apple dat omgooien voor hun Desktop omgeving?
30%

En inderdaad, dit is speculatie, maar niet zonder gegronde rede. Apple is al langer bezig om ontwikkelaars naar de store te pushen, en over de afgelopen vijf jaar hebben ze het elke keer lastiger gemaakt om niet-goedgekeurde software te installeren. Als Apple dit beleid door zet, dan kun je over 5 jaar niets meer installeren zonder Apple's expliciete goedkeuring. Zoals op hun andere producten.
Okay volgens jou redenatie gaat MS dan ook op Windows deze store only maken, die promoten het ook nadrukkelijk.
Dat Apple de store naar de voorgrond brengt is begrijpelijk omdat het een veilige bron is. Dat zegt nog niet dat men andere mogelijkheden afsluit, dan had men dat al lang kunnen doen. Ze laten het behoorlijk open, ze worden alleen stricter is vereisten wat betreft security, iets wat ook MS doet.
Er is een groot verschil tussen IOS en MacOS,
Okay volgens jou redenatie gaat MS dan ook op Windows deze store only maken, die promoten het ook nadrukkelijk.
Op Windows 10 ARM is de store al verplicht ja en Windows 10 S is daar ook al een voorproefje van.
Er zal wel een hoop breken in het begin, maar dat gebeurt wel vaker bij nieuwe MacOS versies. Als je voor MacOS ontwikkelt moet je gewend zijn om snel te schakelen. Alleen voor games erg naar omdat die meestal niet meer geüpdatet worden.
Blizzard is een van de weinigen die muv Overwatch alle games op de Mac heeft draaien.

Ik vind de Mac prettig werken en ik speel WoW dus ik hoop dat Blizz Mac blijft ondersteunen.
Ik ben geen programmeur maar Apple heeft altijd de nieuwe compilers in de software ingebouwd. Toen men van PowerPC naar X86 ging is dat vrij snel gegaan. (vanuit een gebruiker perspectief)
ook naar 64 bits ging soepel op een enkele applicatie na die niet opnieuw gecompiled is.
Daarnaast gebruikt Apple al ARM op de iPhone/iPad. Ik verwacht dus dat de grens tussen mac software en IOS software gaat vervagen.

[Reactie gewijzigd door wvdburgt op 23 april 2020 14:51]

Het scheelt dat veel software op MACOS al geprogrammeerd wordt in de Apple programmeertalen,
En dat Apple hierin niet alleen gebruik maakt van de x86 optimalisaties zoals de SSE** instructies.
Daar waar het .net framework van Microsoft nog zwaar leunt op deze instructies. (en dit voorzichtelig begint los te laten met windows for ARM)

MacOS heeft dus de ruimte om te schakelen tussen verschillende platformen en hardware.
Ik vermoed dat de keuze om 32-bit los te laten mee heeft gewogen toen ze begonnen met hun eigen taal meer naar de voorgrond te duwen.
eens, het was een verademing dat ze van PowerPC naar x86 gingen, zoveel meer compatibiliteit en veel meer software die naar Mac werd geport. Dat gooien ze nu weer weg.
Aan de andere kant, ontwikkelaars hebben de afgelopen jaren al veel iOS en Android versies gemaakt van bekende software als Photoshop enzo, dus die transitie is nu minder heftig.
Vergeet niet dat er relatief veel geld wordt verdiend aan software voor Macs. Een Mac gebruiker geeft meer geld uit aan software dan gebruikers van andere platformen. Het is dus, ondanks het lage marktaandeel, lucratieve business.
maar ik vraag me af hoe leuk softwareontwikkelaars voor de toch al kleine markt van Mac PC's gaan vinden.
Wereldwijd is Apple zo'n 20% van de 'PC' (als in desktop/laptop)-markt.

En tsja, hoe groot is de markt voor desktop-applicaties uberhaupt nog? Bijna alles is tegenwoordig een client voor een clouddienst (zie Chromebook, die dat in extremis trekt) Omdat die veel lichter zijn, is hercompileren ook niet zo'n enorm probleem. Dat is vooral irritant voor applicaties waar performance heel belangrijk is.

Sure, dat is dan meteen ook relevant voor de markt va games, maar Games op de Mac was al een niche. Tenminste, ik ken helemaal niemand die denkt "ik wil graag gamen *dus* ik koop een Mac", alleen maar maar mensen met de instelling "ik heb een Mac, zou het wel leuk vinden als er ook wat meer games voor zijn")

Maar daarvoor heeft Apple juist het omgekeerde opgestart, Catalyst. Zodat je iPad app straks ook op de Mac draait.

Ook de 'niche'-softwaremakers zullen wel overstappen. Zo verdienen ze hun brood. Of niet, en dan is er nog geen man overboord, dan is er alleen een niche-app verloren...

Wat vooral belangrijk is (en bepalend voor het succes van ARM op Mac) is of de makers van de traditionele 'pro' tools over gaan stappen. Video- en geluidsbewerking, vormgeving, software-ontwikkelingstools. Als die niet overstappen (en met de komst van Catalina zagen we daar al voorbeelden van), dan heeft het Mac-ARM platform geen toekomst.

Ik verwacht dat Apple daarom een transitie-plan heeft, waarbij ze parallel Intel en ARM-Macs naast elkaar zullen blijven verkopen. Of misschien zelfs wel een onderscheid gaat maken tussen 'ultra-portable' met ARM, maar minder mogelijkheden en de 'pro'/desktop markt, met zwaardere batterijen.
Het meest logische is de goedkope mac mini. Dit is toch altijd de vreemde eend in de bijt, en als apple server (voor KMO) is dit prima en heel zuinig. (Of Apple server toegevoegde waarde heeft boven een NAS van Synology, of QNAP, dat is de vraag)
Kwa CPU power weet ik er niet heel veel van, maar ik weet wel dat het voor mij, als Mac gebruiker, interessant zou zijn een Apple platform te hebben als NAS. Ik gebruik al jaren Synology, naar tevredenheid, maar het cross platform verhaal als je grote files wilt overzetten is een dingetje (je bent gedwongen exFAT te gebruiken).

On-topic: ook ik vraag me af wat de gevolgen zijn voor compatibility met de Intel generatie? Bootcamp/virtualisatie?
Huh? Gedwongen exFat te gebruiken bij een NAS? Die Synology NAS benader je toch via het netwerk? Dan maakt het filesystem niet echt meer uit, want je Mac hoeft alleen maar via NFS/CIFS/AFP te praten. Ik weet niet eens zeker welk filesystem er op mijn oude vertrouwde Synology DS411+II gebruikt wordt, maar ik verwacht ext4. En dat werkt prima vanaf m'n Mac of vanaf een Windows machine, hoewel ze allebei standaard geen ext4 snappen.
> Het meest logische is de goedkope mac mini.

Eigenlijk zou je daar gewoon bijna de bestaande ATV voor kunnen gebruiken als je een macOS hebt die op ARM kan draaien.
Snap niet waarom ze in een laptop BigLittle configuratie gaan toepassen.
Steek er toch 8 snelle cores in, je kunt koelen en batterij is ook geen issue meer.

Zodra 100% kracht nodig gaat hebben, gaan je trage cores je toch benadelen?

Je ziet AMD/Intel ook toch geen trage en snelle cores samen gebruiken.
Ik weet wel zeker dat Apple tegelijkertijd voor de MacPro gewoon de niet zuinige cores aan elkaar gaat plakken en waarschijnlijk met een 16 core variant zal komen.

Dat is net als AMD doet de makkelijkste manier om meer performance toe te voegen.

Want ze kunnen moeilijk met de Macbook overstappen op ARM compatible software en de MacPro niet.
Omdat AMD en Intel vooral inzetten op throttling (en runtime disablen van cores) om energie te besparen. Bij ARM doen ze min of meer het zelfde maar dan fysiek. Die kleine cores zijn prima voor achtergrondtaken of bijvoorbeeld voor de "power nap" feature in MacOS.
Minder energieverbruik = langere runtimes.

Rekenvoorbeeld= De Ipad 13 = 36Wh batterij voor 10u surfen = 3,6watt gemiddeld en met de Macbook pro 58Wh batterij kan je ook 10u surfen = 5,8 watt gemiddeld.

De A13 ARM chip heeft al een soort power management om de big cores uitvte schakelen om zo energie te sparen. Waarschijnlijk zijn de 4little cores in deze nieuwe CPU even snel als een dual core i5 van vandaag en voel je dat nooit tijdens het surfen.

Apple is ook al jaren aan het investeren in Microled. Een oled concurrent maar dan zuiniger en hogere piek helderheid. Aangezien de soc + scherm de 2 grootverbruikers zijn (vooral scherm) dan is het perfect mogelijk dat een Macbook pro 13” minder verbruikt als een Ipad 12,9” van vandaag en dat resulteert in 20u rumtime!

Maar je kan ook uw batterij verkleinen en de plaats gebruiken voor meer koeling, zwaardere GPU of simpelweg een dunnere laptop.

En btw: Er zijn ook al roddels dat Intel ook met een Biglittle komt.

[Reactie gewijzigd door Coolstart op 23 april 2020 19:49]

Kunnen ze gelijk de appstore gelijks trekken met ios. Als in: 100% controle op wat kan en mag draaien op je arm mac.
Niet alleen controle, ook 30% winst op alles wat je op je Mac koopt aan software.
Die 30% is natuurlijk niet directe winst. Maar goed, ik snap je punt.
Betekent deze stap eigenlijk dat het gemakkelijker is om gelijkertijd een iOS en een macOS-applicatie te ontwikkelen? Of staat dat los van elkaar?
Het is al erg makkelijk om iOS applicaties naar Mac over te zetten. Software voor een andere processor architectuur compileren is voor de meeste software een kwestie van een compiler flag omzetten.
Ah, juist. Dank voor je toelichting!
hoe gaat dat ooit kunnen concurreren met zen2 en later zen3 mobile?
Nou wat denk je door gewoon meerdere chiplets aan elkaar te knopen?

Apple kan dat ook gewoon doen door 2x 8 cores aan elkaar te plakken.

Of zelfs 4x8 als dat nodig is.

En Apple is best capabel CPU's met hoge performance te ontwikkelen.
AMD heeft technieken als Infinity fabric en voor zover ik weet beschik Apple hier niet hierover. Dit zullen ze dan moeten gaan ontwikkelen(of kopen?). AMD heeft hier veel meer ervaring mee denk ook aan HyperTransport.
Dat lijkt me echt geen uitdaging.

Dat is gewoon een verbindingsprotocol.

Gezien Apple vele malen meer geld kan uitgeven aan R&D zal dat echt geen probleem hoeven te zijn.

De grootste uitdaging ligt juist in een zuinig en goed presterend CPU ontwikkelen.
Apple en AMD komend jaar op 5nm, terwijl Intel nog steeds op 14nm+++ vastzit. Blij om te zien dat er meer dan genoeg ontwikkelingen gebeuren m.b.t. de CPU!
Heel moeilijk te vergelijken. x86 en ARM zijn in veel opzichten verschillend.

Het probleem is dat de nm geen standaard heeft. 10nm van een fabrikant is niet te vergelijken met de 10nm van de ander. Zo is Intels 10nm vergelijkbaar met AMDs 7nm.
But its bad for marketing ;)
Hopelijk gaan meer volgen zodat er weer wat meer concurrentie komt op de PC markt. Als PC's ARM-socs gaan draaien en de software daarvoor geschikt gemaakt wordt. Gaat dit misschien ook wel een boost geven aan Desktop Mode op telefoons.
WIndows 10 draait al op ARM en sommige versies van Microsoft's Surface apparaten hebben een ARM-processor. Dus het bestaat al enigszins. Maar voor zover ik weet zijn dat alleen de goedkopere / langzamere Surfaces, de duurdere / snellere hebben nog Intel-processors.
Interessant, zeker als je ziet dat een iPhone 11 al even snel (multicore) of sneller (single core) is dan een wat oudere i7-macbook Pro in Geekbench. Meer cores, hogere clocks en invloed op hoe er geprogrammeerd wordt... Interesting times!
Bij Macbooks en iMacs kunnen ze ook nog eens de performance flink opvoeren door meer cores toe te voegen en de kloksnelheid te verhogen.

Tevens is er meer ruimte voor koeling, met het optimalisatie die Apple kan toepassen omdat ze software en hardware in eigen beheer hebben kunnen ze hier flinke performance uit persen is mijn inschatting en waarschijnlijk nog met een zuinig, koel en stil systeem ook.
Ik ben heel erg benieuwd hoe ze dit in de praktijk gaan uitvoeren. Natuurlijk zijn ze sinds de laatste versie van macOS al over naar volledig 64-bit, dus een boel legacy software werkt toch al niet meer, en als er dan een ARM Mac uitkomt doen ze waarschijnlijk alle software die niet portable is de deur uit, en ondersteunen ze alleen software die zonder aanpassingen werkt op x86_64 en ARMv8.

Mogelijk doen ze zoiets niet voor de huidige generatie Macs, of alle toekomstige Macs met Intel-processoren, maar ik zie ze dat eigenlijk ook nog wel doen om te zorgen dat je je als eindgebruiker geen zorgen hoeft te maken over welke Mac je moet kopen om je software te laten werken. Natuurlijk is x86_64-emulatie ook een oplossing, maar dat is traag, en is waarschijnlijk alleen om een transitieperiode te overbruggen.

Een transitieperiode zal er namelijk wel zijn, maar ik denk dat dat na enige tijd de meeste software wel gewoon native op ARMv8 zal werken, zolang je maar geen vreemde assembly probeert te draaien. Maargoed, we zullen zien. Ik ben in elk geval benieuwd!

[Reactie gewijzigd door jvnknvlgl op 23 april 2020 15:02]

Het zal voornamelijk om drivers en low-level software gaan die aanpassingen nodig hebben. De rest zal denk ik prima compilen op Arm.

Onder linux is het heel normaal om packages uit te brengen voor verschillende architecturen.

Op dit item kan niet meer gereageerd worden.

Tweakers maakt gebruik van cookies

Tweakers plaatst functionele en analytische cookies voor het functioneren van de website en het verbeteren van de website-ervaring. Deze cookies zijn noodzakelijk. Om op Tweakers relevantere advertenties te tonen en om ingesloten content van derden te tonen (bijvoorbeeld video's), vragen we je toestemming. Via ingesloten content kunnen derde partijen diensten leveren en verbeteren, bezoekersstatistieken bijhouden, gepersonaliseerde content tonen, gerichte advertenties tonen en gebruikersprofielen opbouwen. Hiervoor worden apparaatgegevens, IP-adres, geolocatie en surfgedrag vastgelegd.

Meer informatie vind je in ons cookiebeleid.

Sluiten

Toestemming beheren

Hieronder kun je per doeleinde of partij toestemming geven of intrekken. Meer informatie vind je in ons cookiebeleid.

Functioneel en analytisch

Deze cookies zijn noodzakelijk voor het functioneren van de website en het verbeteren van de website-ervaring. Klik op het informatie-icoon voor meer informatie. Meer details

janee

    Relevantere advertenties

    Dit beperkt het aantal keer dat dezelfde advertentie getoond wordt (frequency capping) en maakt het mogelijk om binnen Tweakers contextuele advertenties te tonen op basis van pagina's die je hebt bezocht. Meer details

    Tweakers genereert een willekeurige unieke code als identifier. Deze data wordt niet gedeeld met adverteerders of andere derde partijen en je kunt niet buiten Tweakers gevolgd worden. Indien je bent ingelogd, wordt deze identifier gekoppeld aan je account. Indien je niet bent ingelogd, wordt deze identifier gekoppeld aan je sessie die maximaal 4 maanden actief blijft. Je kunt deze toestemming te allen tijde intrekken.

    Ingesloten content van derden

    Deze cookies kunnen door derde partijen geplaatst worden via ingesloten content. Klik op het informatie-icoon voor meer informatie over de verwerkingsdoeleinden. Meer details

    janee