Bloomberg: "Apple avtäcker ARM-processorer för Mac under WWDC"

Permalänk
Medlem

På lång sikt blir detta nog riktigt bra. Men kortsiktigt så är detta negativt för de som just nu innan ska köpa en mac med Intel cpu. I början när Arm har kommit så är inte mjukvaran den bästa, det kan mjukvarustöd till det ena och det andra.

Angående Hackintosh så går utvecklingen att man mindre bryr sig om vilket operativsystem ens klient har. Det är dock positivt om operativsystemet är lättdrivet, säkert, stabilt, underhållsfritt och en massa fjärrstyrningsprogramvara finns. Det blir säkert jättebra på en Appledator, men köpa en pc med x86 och emulera. Ja det blir nog sämre än att endast köra windows.
Oavsett vad man gör så är det framförallt programvarorna Chrome, Microsoft office, diverse vpn, vnc, ssh, rdp klienter etc som man kör. Så om det är windows, linux, ios, macos, android man kör på sin klient, så går utvecklingen emot att man använder "samma mjukvara" från samma utvecklare. Där den absolut vanligaste mjukvaran är webläsaren chrome, ska man bokföra, släktforska whatever. Så är det webbläsaren chrome som man ofta startar.

Permalänk
Medlem

Ska bli kul att se hur detta urartar sig i verkligheten.
Kommer ARM ta över datormarknaden från x86 processorer inom 10 år?

Permalänk
Inaktiv

En till kul siffra i sammanhanget: Apple har ett marknadsvärde på 1.5 Trillion USD medan Intel ligger på ynka 270 Billion USD, inte mer än att Apple kan köpa Intel rakt av med vad som ligger och skramlar i handkassan hos Apple (enligt halvofficiella beräkningar).

Om någon undrar vem som har mest resurser för processor-utveckling.

Permalänk
Datavetare
Skrivet av Harddrive:

Är inte ARM ganska "klent"?

Du får kika på StrongARM

Skrivet av DasIch:

Är det möjligt att dumpa gammalt legacy-mög och göra en mer renodlad AMD64-arkitektur?

Det skulle inte hjälpa. x86_64 (som är uppdelad i två nästan helt kompatibla varianter: AMD64 och Intel64) är en utökning av IA32.

När AMD designade AMD64 fixade man ändå ett par av de värsta problemen med IA32, något som resulterade i att x86 nästan alltid så samma prestanda eller till och med en liten ökning av att enbart kompilera om program från 32-bit till 64-bit. Andra bättre designade ISA som PowerPC, MIPS och liknande såg ofta samma prestanda eller en liten minskning p.g.a. att pekare och vissa strukturer blir större med 64-bitars stöd -> mer data att skyffla vilket bl.a. ger sämre cache-hit rate.

På assemblernivå påminner 64-bitars ARM (Aarch64) en del om 32-bitars ARM, men på maskinkodsnivå har dessa två lika mycket gemensamt som MIPS har med PowerPC eller RISC-V. 64-bitars ARM är en helt ny ISA designad från grunden utan något legacy-mög från förra årtusendet.

RISC-V designade ungefär samtidigt som Aarch64 och på hög nivå borde även RISC-V ha liknande fördel hos kompilatorer. Men så här långt har inte det realiseras, vilket sannolikt beror på att man inte lagt lika mycket resurser på att optimera kompilatorer där än som för Aarch64 och framförallt inte lika mycket som för x86.

Vet inte om AMD/Intel är intresserade av överge x86 och börja designa ARM64 CPUer. Båda har en ARM-license. StrongARM tillverkades ju av Intel under namnet XScale, AMD planerade initialt att använda Zens back-end både till x86 och ARM och rykten gör gällande att Keller lämnade AMD när de drog pluggen ur på ARM-delen.

Om AMD och/eller Intel går till något nytt gissar jag att de anammar RISC-V då det är en öppen standard, d.v.s. de slipper sitta i knät på något annat företag på ett sätt de inte behövt med x86 (de sitter till viss del i varandras knä där, även om AMD i praktiken inte fått in något sedan man designade AMD64).

En renodlad x86_64 CPU skulle inte heller fungera ihop med dagens operativsystem. Just det skulle nog inte vara superkomplicerat att fixa, men just nu använder de både 16-bitars och 32-bitars delen under startup-fasen.

Permalänk
Medlem
Skrivet av leafbranch:

Ska bli kul att se hur detta urartar sig i verkligheten.
Kommer ARM ta över datormarknaden från x86 processorer inom 10 år?

10år är otroligt kort tid, för vi som är lite äldre så är 10år typ som igår.
Men arm kommer säkert ta över. Utvecklingen går emot Software as a Service (SaaS). Man betalar för att få nyttja en mjukvara, vad den underliggande hårdvaran är har man inte en aning om. Man kan dock få betala mer för bättre prestanda och driftsäkerhet, men man får ej veta den underliggande hårdvaran.
Detta leder till att det blir megastora datacenter som driver allt och det går lägga mycket pengar på utveckling. En mjukvarulösning är ofta inte självständigt, utan den i sin tur använder olika tjänster i molnet som inte utvecklaren har en aning om hur den fungerar eller vilken hårdvara den kör på, det enda utvecklaren vet är resultatet.

Säg att man ska skapa en websida där folk kan ladda upp bilder på sig själva, då kan man superlätt lägga till tjänster som analyserar bilden och ger information om vilket kön, ålder, m.m som personen troligen har, även om den är glad eller sur. Om detta inte överensstämmer med vad personen har angivit, så kan man göra en manuell kontroll.
Min poäng i detta exempel är att inte ens utvecklaren behöver inte ett skit veta hur tjänsten fungerar, den behöver endast veta vad resultatet från den blir och hur man ska tolka detta..

Samma är det med allt. Ska man konvertera en film, man använder en tjänst, spara en fil någonstans använd en tjänst, skapa en händelse när något sker använd en tjänst.. Osv.. Vilket leder till att de stora molnföretaget lägger ner otroligt mycket pengar på att tjänsterna ska köras så billigt som möjligt och arm ligger bra till

Permalänk
Medlem
Skrivet av lillaankan_i_dammen:

10år är otroligt kort tid, för vi som är lite äldre så är 10år typ som igår.
Men arm kommer säkert ta över. Utvecklingen går emot Software as a Service (SaaS). Man betalar för att få nyttja en mjukvara, vad den underliggande hårdvaran är har man inte en aning om. Man kan dock få betala mer för bättre prestanda och driftsäkerhet, men man får

10 år är en evighet avseende IT-teknik, vissa skiften har gått extremt fort. Tror tiden är mogen för ett skifte på CPU-sidan nu. Bara titta på Intels Comet Lake lansering... lanseringar med minimal utveckling år efter år, tiden har blivit mogen för att några tänker nytt och det är vad vi ser på HPC (superdator sidan) och även konsument/företagssidan Microsoft (Surface X), Samsung (Galaxy Book) och nu förhoppningsvis Apple.

Det som behövs är att någon drar ur proppen / drar av plåstret och inte gör det halvhjärtat som det varit med Microsoft m.fl.

Permalänk
Medlem
Skrivet av Mindfighter:

10 år är en evighet avseende IT-teknik, vissa skiften har gått extremt fort. Tror tiden är mogen för ett skifte på CPU-sidan nu. Bara titta på Intels Comet Lake lansering... lanseringar med minimal utveckling år efter år, tiden har blivit mogen för att några tänker nytt och det är vad vi ser på HPC (superdator sidan) och även konsument/företagssidan Microsoft (Surface X), Samsung (Galaxy Book) och nu förhoppningsvis Apple.

Det som behövs är att någon drar ur proppen / drar av plåstret och inte gör det halvhjärtat som det varit med Microsoft m.fl.

Som yoshman skrev i en annan tråd så bör nog intel inte räknas ut helt ändå. Får de styr på beräkningsenheterna som ligger och skräpar på den integrerade GPUn, då kan det bli åka av.

Citat ur tråden:
"GPGPU
Varför GPGPU? Därför att GPGPU är det enda som kan ge någon relevans till "stark" iGPU. Faktum är att iGPU har flera fördelar över dGPU i just GPGPU. Då CPU och GPU delar RAM är det otroligt låg kostnad att flytta jobba mellan dessa delar, vidare finns ingen begränsning av storlek (även om Pascal och senare har stöd att även utnyttja system RAM krävs att applikationen också använder en tillräckligt modern version av CUDA för att det ska fungera).

AMD pushade något de kallade "Fusion" rätt hårt efter uppköpet av ATI. Tanken har alltid varit helt rätt, vissa saker utförs långt mer effektivt på en GPU så dessa bör därför utföras på en GPU når sådan finns. Att man aldrig kommit någonstans med detta är primärt ett programvaruproblem, AMD har aldrig lyckats skapa någon vettig programeringsmodell för sina GPUer eller APUer.

Nvidia knäckte dGPU delen med CUDA. Enda problemet med CUDA är att det drar upp kostnaden, man måste alltid skriva två versioner. En för GPUer och en för CPUer om man alls vill kunna köra programmet på system som saknar Nvidia GPU.

Intel har nu knäckt den sista delen av detta. Dels har Intel tagit GPGPU-programmering ännu ett litet steg närmare "vanlig" programmering jämfört med CUDA. CUDA är nästan standard C, men bara nästan då man har en del icke-standard utökningar. OneAPI använder helt standard ISO C++20, självklart med extra bibliotek men språkmässigt finns inga icke-standard utökningar.

Ovanpå det blir normalfallet när man skriver mot oneAPI att programmet kommer automatiskt välja om det ska köra på CPU eller GPU. Det kommer föredra GPU, om kompatibel sådan saknas väljs CPU. Och handlar inte bara om att det "fungerar" på CPU, den testning jag gjort så här långt pekar på att det är riktigt effektiv CPU-kod man får. Det betyder att merkostnaden för att nu använda GPGPU är extremt låg.

CUDA används i de fall där man får x10 eller något sådant. D.v.s. vinsten är så stor att det är värt extrakostnaden i utveckling. OneAPI har långt mindre tröskel, finns egentligen ingen anledning att inte använda det så länge det är en nettovinst. Givet förväntad prestanda hos Tiger Lakes GPU lär den prestera minst i nivå med välskriven AVX-kod körandes på en 3950X.

Det sista är tyvärr dåliga nyheter för ARM på Windows, för om mycket prestandakritisk kod hanteras av GPGPU har man ju en "work-around" för att x86 inte är lika effekt som ARM64..."

Skarp analys, undrar om Intel hinner i tid. Apple kan de redan ha förlorat, PC-marknaden upplever jag som mer trögrörlig.

Permalänk
Medlem
Skrivet av Yoshman:

Kodsnutten gör följande: ta en sekvens med 100 tal, kvadrera varje tal och summera dessa. Detta är något både x86_64 och ARM64 effektivt kan använda SIMD till, vilket också sker i båda fallen. Men det tar 1/4 så många instruktioner för ARM (man kan komma närmare med x86 om man dumpar stöd för alla CPUer äldre än Broadwell, men fortfarande ändå inte ända fram).

x86_64
ARM64

Ovan är ingen engångsföreteelse. 32-bitars ARM är ofta ännu mer kompakt, men designen där gjorde det i praktiken omöjligt att designa "breda" CPUer med massiv IPC. Just den aspekten är också fixad i 64-bitars ARM, det finns helt enkelt långt mer IPC att extrahera ur en 64-bitars ARM instruktionsström än ur en 32/64-bitars x86 eller 32-bitars ARM.

Fast det är inte så konstigt att kod kompilerad för en 20 år gammal x86 CPU inte är särskilt optimal med dagens mått. Om vi ska jämföra med Aarch64 så bör vi rimligtvis utgå ifrån att bakåtkompatibilitet är irrelevant och låta kompilatorn optimera för en modern x86 CPU istället.

Dessutom så skiljer det en hel del beroende på vilken specifik algoritm som kompileras. Här har du t.ex. ett motexempel: https://godbolt.org/z/CrfV_q

Permalänk
Medlem
Skrivet av Yoshman:

Finns flera förklaringen till hur 64-bitars ARM kan prestera så väl. En väldigt viktig del är att man helt designat instruktionsuppsättningen efter moderna krav, d.v.s. att all maskinkod idag genereras av kompilatorer av något slag. Här är ett väldigt litet exempel på varför prestanda är så fin, CISC vs RISC diskussionen kommer rejält på skam här...

Kodsnutten gör följande: ta en sekvens med 100 tal, kvadrera varje tal och summera dessa. Detta är något både x86_64 och ARM64 effektivt kan använda SIMD till, vilket också sker i båda fallen. Men det tar 1/4 så många instruktioner för ARM (man kan komma närmare med x86 om man dumpar stöd för alla CPUer äldre än Broadwell, men fortfarande ändå inte ända fram).

x86_64
ARM64

Ovan är ingen engångsföreteelse. 32-bitars ARM är ofta ännu mer kompakt, men designen där gjorde det i praktiken omöjligt att designa "breda" CPUer med massiv IPC. Just den aspekten är också fixad i 64-bitars ARM, det finns helt enkelt långt mer IPC att extrahera ur en 64-bitars ARM instruktionsström än ur en 32/64-bitars x86 eller 32-bitars ARM.

Nu är det kanske inte många förutom Gentoo användare som kompilerar all kod optimerad för sin egen cpu.
Men om du targetar de senaste CPU arkitekturerna för AArch64 och X86_64 så vinner X86 med en instruktion.
x86_64 cooperlake
ARM64 cortex-a76

Värt att notera också är att de riktigt breda instruktionerna kräver mycket mer effekt vilket kan sänka klockfrekvensen för en eller flera cpu kärnor [0]. Därför kan det i vissa fall vara värt att köra mindre breda simd instruktioner för att inte sega ner resten av programmet.
Det ska bli intressant att se hur bra ARM arkitekturernas prestanda skalar i frekvens och krestsstorlek.
Vi kommer kanske se ett absolut prestanda race mellan X86 och ARM cpur de kommande 10 åren.

[0] https://stackoverflow.com/questions/56852812/simd-instructions-lowering-cpu-frequency

Permalänk
Medlem

Så mao så blir det ännu en låst plattform där det kommer saknas stöd för program, vill själv inte ha ytterligare ett telefon operativ på stationär dator. Det e nog med den bedrövliga google varianten, nu blir det definitivt farväl till allt med mac (apple)

Permalänk
Medlem

Undrar hur en sån här förändring påverkar priset. Skulle inte tacka nej till en ARM baserad MacBook Air till lägre pris än dagens. Kan en eventuell billigare modell vara på väg för att konkurrera med chromebooks på skolmarknaden?

Permalänk
Medlem
Skrivet av Daz:

Undrar hur en sån här förändring påverkar priset.

Inköpspriset som Apple betalar Intel för dagens processorer är en försumbar del av totalkostnaden. Dessutom är det väl knappast någon som köper en Apple-laptop för att de är prisvärda.

Om något är det väl snarare mer sannolikt att det blir tvärt om, d.v.s. du får betala ett par tusen spänn extra för privilegiet att få ha en CPU med en Apple-logotyp på.

Permalänk
Medlem
Skrivet av Ase:

Så mao så blir det ännu en låst plattform där det kommer saknas stöd för program, vill själv inte ha ytterligare ett telefon operativ på stationär dator. Det e nog med den bedrövliga google varianten, nu blir det definitivt farväl till allt med mac (apple)

Lär fortsätta köra MacOS X.

Vore lite spännande om de släpper en dev image av MacOS X som går att köra på iPad som en snabb lösning för att få utvecklarna att komma igång med MacOS på ARM tills de ”riktiga” datorerna kommer.

Permalänk
Medlem
Skrivet av Gramner:

Om något är det väl snarare mer sannolikt att det blir tvärt om, d.v.s. du får betala ett par tusen spänn extra för privilegiet att få ha en CPU med en Apple-logotyp på.

Antagligen eftersom den nog blir både snabbare och med bättre batteritid än datorn med intel cpu.

Permalänk
Datavetare
Skrivet av xobust:

Nu är det kanske inte många förutom Gentoo användare som kompilerar all kod optimerad för sin egen cpu.
Men om du targetar de senaste CPU arkitekturerna för AArch64 och X86_64 så vinner X86 med en instruktion.
x86_64 cooperlake
ARM64 cortex-a76

Värt att notera också är att de riktigt breda instruktionerna kräver mycket mer effekt vilket kan sänka klockfrekvensen för en eller flera cpu kärnor [0]. Därför kan det i vissa fall vara värt att köra mindre breda simd instruktioner för att inte sega ner resten av programmet.
Det ska bli intressant att se hur bra ARM arkitekturernas prestanda skalar i frekvens och krestsstorlek.
Vi kommer kanske se ett absolut prestanda race mellan X86 och ARM cpur de kommande 10 åren.

[0] https://stackoverflow.com/questions/56852812/simd-instructions-lowering-cpu-frequency

Du belyser faktiskt en annan bra aspekt: om man bara zoomar in på SIMD har faktiskt Intel fått till det rätt bra, framförallt AVX-512 där det finns direkt stöd på instruktionsnivå att hantera divergerande branscher likt hur moderna GPUer hanterar samma sak.

Men som du nämner är ju nackdelen med AVX-512 (redan med 256-bitars AVX) att frekvensen minskas, så det är inte alls självklart att AVX-512 alls är ett bra alternativ ens i detta fall då det minskar prestanda för efterföljande instruktioner. De NEON instruktioner ARM använder är 128-bitars, d.v.s. de är mer lik SSE i hur mycket ström de bränner och SSE har normalt noll påverkan på frekvens!

Vidare på CISC vs RISC spåret. AVX-512 må ha coola finesser, men det kostar också kodstorlek! Om man genererar maskinkoden för dessa två fall så är genomsnittlig instruktionslängd för AVX-512 varianten 5 bytes, d.v.s. 25 % större instruktioner jämfört med ARM64!

Och för att vicka ut sista delen av saltet för just detta fall: då AVX-512 tenderar dra så mycket ström har alla nuvarande modeller som stödjer detta bara halva kapaciteten aktiv i normalfallet, först när "tillräckligt" många AVX-512 har körts kommer andra halvan att aktiveras. Svårt att veta exakt hur många NEON-instruktioner Apples CPUer kan köra per cykel, men är nog ett gäng givet att SPECfp normalt byggs med flaggor specifika för CPU-modellen man kör och man var ju så långt efter AMD/Intel trots att de där kommer använda 256-bitars AVX. Cortex X1 har 4 st NEON-pipelines medan Zen2 och Skylake har båda 4 st asymmetriska SSE/AVX pipelines (vissa instruktioner kan bara köras av vissa pipeliens, rätt mycket en 2/2 split). Kommer nog tillbaka på att NEON är 128-bitars så går att fyra kompletta pipelines utan att spränga strömbudget, medan det inte är rimligt med AVX/AVX-512.

I praktiken är AVX-512 bara vettigt för stora problem där en väldigt stor andel av det man gör drar nytta av instruktionerna. Nu finns flera sådana fall, t.ex. många maskininlärningsfall, matlab, vissa statistiska beräkningar, vissa former av simulering.

Men då ska också nämnas: ARM har också en mer avancerad variant av SIMD som kallas SVE (Scalable Vector Instructions). SVE finns än så länge bara någon enstaka modell tänkt för superdatorer, men SVE kan processa upp till 2048 bitar per instruktion (och de är 4 bytes långa...)!

Men skriv också, "detta är normalfallet". Valde Rust dels för att jag anser det är med råge det bästa programspråk som lanserats sedan C. Förutom att det ger kompileringsfel på många buggar (bl.a. data-race) som är väldigt svåra att hitta och stör för majoriteten av alla säkerhetshål i kod skrivet i C, C++, C# och Java så är Rust designat specifikt med tanke på att kompileratorerna ska kunna optimera koden extremt väl.

Samma snutt skrivet i C++ (kompilerat med g++ 8.2) blir inte alls lika tokoptimerat, ändå betydligt kortare för ARM64 och kompilerar man för icelake-client eller något annan CPU med AVX-512 stöd blir det bara än värre (100 element är inte i närheten tillräckligt många för att kompensera för nackdelarna med att använda AVX-512).

ARM64
x86_64

I detta fall används inte SIMD i något fall, är hyfsat likvärdig inre loop. Man gör lite saker som kan se märkliga ut för x86, men det är med största sannolikhet för att utnyttja något som kom i Core2: macro-op fusion. Det är så vanligt att "cmp" följs av ett villkorat hopp att moderna x86 har interna instruktioner för detta, man slår ihop två x86 instruktioner till en intern. ARM64 har naturligtvis löst detta utan att bränna transistorer på macro-op fusion, via "cOP" (där OP kan vara eq, ne, le, gt etc) samt "csel" (i praktiken hopslagen x86 compare+cmov).

Testa gärna andra saker, t.ex. att sortera m.h.a. "sort". Inget lär ändras om man kör C, C++, Java eller C# utom möjligt att de har färre lägen där de kan använda SIMD jämfört med Rust.

Permalänk
Datavetare
Skrivet av Gramner:

Fast det är inte så konstigt att kod kompilerad för en 20 år gammal x86 CPU inte är särskilt optimal med dagens mått. Om vi ska jämföra med Aarch64 så bör vi rimligtvis utgå ifrån att bakåtkompatibilitet är irrelevant och låta kompilatorn optimera för en modern x86 CPU istället.

Dessutom så skiljer det en hel del beroende på vilken specifik algoritm som kompileras. Här har du t.ex. ett motexempel: https://godbolt.org/z/CrfV_q

  1. Du jämför två olika kompilatorer, väljer man clang för båda är vi tillbaka på att ARM64 tar färre instruktioner, men är då lite äpplen mot päron då ARM versionen inte är unrolled

  2. Att välja AVX-512 är en suboptimering om inte AVX-512 kan användas för majoriteten av alla kod, vilket i fallen vi tittar på här knappast lär vara speciellt vanligt

  3. Vi ignorerar helt att olika kompilatorer kan använda olika heuristik, gissar att GCC mer försöker maximera IPC vilket då kan göra det bättre att ha fler instruktioner fast en mix som maximerar IPC medan clang verkar välja en modell som ger färre instruktioner och därmed sannolikt högre cache-hit-rate fast nog lär ge lägre IPC då de flesta pipelines INTE hanterar SIMD

Vidare är det faktiskt så att majoriteten av all programvara förutsätter inte mer än grundspecifikationen för x86_64, d.v.s SSE2. Spel och andra mer krävande applikationer kan ha flyttat den målstolpen lite, men undrar om det finns något som inte fungerar på Nehalem, d.v.s. SSE4.

Intel är väldigt duktiga på att skapa bibliotek som effektivt utnyttjar AVX och numera också AVX-512, så inom de områden där t.ex. Intels MKL används kommer det vara en klar fördel med AVX-512 stöd. Det är också de fall där man kan räkna med att AVX instruktioner är där man spenderar det mesta av tiden, så inte hela världen att frekvensen sjunker.

Det som inte kan visualiseras på något enkelt sätt är andra aspekter där ARM64 har fördelar mot x86_64. T.ex. så har de flesta moderna programspråk konvergerat på minneskonsistensmodellen mellan olika CPU-trådar i ett och samma program. ARMv8 (så både 32-bitars och 64-bitars ARM) har en perfekt match på instruktionsnivå mot den valda modellen, x86 skjuter över målet i de flesta fall (d.v.s. gör något som är onödigt dyrt då man måste minst uppfylla kraven).

ARM64 instruktionerna är också specifikt designade att påverka samt bero så lite som möjligt på "globalt tillstånd", d.v.s. ändra CPU-status-flaggor. Att i sann RISC anda också inte ha "förstörande" instruktioner (något Intel fixat för VEX kodade AVX/AVX-512 instruktioner, fast mot en kostnad i instruktionslängd) är också något som gör generell heltalskod mer effektiv (att köra -march=icelake-client ändrar ingenting här för x86).

Att skriva en "front-end" som avkodar 6-7 instruktioner (vilket är vad man gissar A13 hanterar) är rätt enkelt när alla instruktioner är 4 bytes. Att göra något liknande för x86 är brutalt mycket svårare, vilket nog förklarar varför både Zen2 och Skylake är fast på 4 instruktioner per cykel (Skylake kan avkoda 5 vid lyckad macro-op fusion).

Att förutsätta AVX-512 är överhuvudtaget inte rimligt 2020, noll desktop-modeller stödjer detta fram till Rocket Lake lanseras och är bara Ice Lake som stödjer det för bärbara. Men Intel kan ha ett ess i rockärmen här med oneAPI, en av fördelarna med oneAPI är att det inte bara kan användas för GPGPU utan man kan också utnyttja det till oftare köra SIMD! Men underliggande tekniken där, SyCL, fungerar ju även på ARM (och på FPGA:er tack vare Xilinx)

Permalänk
Inaktiv

Det ryktas om en stor designförändring på iMac nu till WWDC. Känns rimligt att den designförändringen görs samtidigt med övergången till ARM om inte annat för att den termiska designen påverkas rejält. Så en ny iMac nu till WWDC kan mycket väl vara ARM-baserad.

Kanske kan den köras som skärm också, typ Sidecar. Då skulle man kunna ha en uppställning med en Intel-Baserad MacBook kopplad till en skärm som då är en ARM-baserad iMac. Sedan använder man den Mac med den CPU som mjukvaran kräver, ARM eller Intel, resultatet visas på samma skärm (dvs på nya iMac).

I början handlar det om en iMac baserad på A13 eller A14. Vill man ha en kraftfullare och/eller Intel-baserad stationär finns ju alltid Mac Pro.

Någon ARM-baserad bärbar är inte särskilt bråttom. Finns ju redan iPad Pro. Inte riktigt samma sak men Apple har jobbat hårt för att man skall se det som samma sak.

Det här upplägget har då fördelen att det innebär att både bärbara och stationära finns i både Intel- och ARM-baserad versioner under övergångstiden. Vill man ha det så är det en ARM-baserad stationär som behövs.

Permalänk
Medlem
Skrivet av anon214822:

Det ryktas om en stor designförändring på iMac nu till WWDC. Känns rimligt att den designförändringen görs samtidigt med övergången till ARM om inte annat för att den termiska designen påverkas rejält. Så en ny iMac nu till WWDC kan mycket väl vara ARM-baserad.

Kanske kan den köras som skärm också, typ Sidecar. Då skulle man kunna ha en uppställning med en Intel-Baserad MacBook kopplad till en skärm som då är en ARM-baserad iMac. Sedan använder man den Mac med den CPU som mjukvaran kräver, ARM eller Intel, resultatet visas på samma skärm (dvs på nya iMac).

I början handlar det om en iMac baserad på A13 eller A14. Vill man ha en kraftfullare och/eller Intel-baserad stationär finns ju alltid Mac Pro.

Någon ARM-baserad bärbar är inte särskilt bråttom. Finns ju redan iPad Pro. Inte riktigt samma sak men Apple har jobbat hårt för att man skall se det som samma sak.

Det här upplägget har då fördelen att det innebär att både bärbara och stationära finns i både Intel- och ARM-baserad versioner under övergångstiden. Vill man ha det så är det en ARM-baserad stationär som behövs.

Imac är ju i princip en laptop man hängt en skärm framför. Jag spår att hela laptoputbudet, ink. Imac kommer med arm. Mac pro Will follow Eller också haka på vid nästa iteration.

Permalänk
Medlem
Skrivet av anon214822:

Det ryktas om en stor designförändring på iMac nu till WWDC. Känns rimligt att den designförändringen görs samtidigt med övergången till ARM om inte annat för att den termiska designen påverkas rejält. Så en ny iMac nu till WWDC kan mycket väl vara ARM-baserad.

Kanske kan den köras som skärm också, typ Sidecar. Då skulle man kunna ha en uppställning med en Intel-Baserad MacBook kopplad till en skärm som då är en ARM-baserad iMac. Sedan använder man den Mac med den CPU som mjukvaran kräver, ARM eller Intel, resultatet visas på samma skärm (dvs på nya iMac).

I början handlar det om en iMac baserad på A13 eller A14. Vill man ha en kraftfullare och/eller Intel-baserad stationär finns ju alltid Mac Pro.

Någon ARM-baserad bärbar är inte särskilt bråttom. Finns ju redan iPad Pro. Inte riktigt samma sak men Apple har jobbat hårt för att man skall se det som samma sak.

Det här upplägget har då fördelen att det innebär att både bärbara och stationära finns i både Intel- och ARM-baserad versioner under övergångstiden. Vill man ha det så är det en ARM-baserad stationär som behövs.

Varför skulle den vara A13 baserad? A14X eller i alla fall A13X bör väl vara minimum, men mest troligt känns nog en dubblerad A14/A14X med ännu fler kärnor

Permalänk
Inaktiv
Skrivet av medbor:

Varför skulle den vara A13 baserad? A14X eller i alla fall A13X bör väl vara minimum, men mest troligt känns nog en dubblerad A14/A14X med ännu fler kärnor

Det räcker faktiskt med en A13. Det är det som är det löjliga i situationen. Men visst, ju värre desto roligare.

Permalänk
Medlem
Skrivet av anon214822:

Det ryktas om en stor designförändring på iMac nu till WWDC. Känns rimligt att den designförändringen görs samtidigt med övergången till ARM om inte annat för att den termiska designen påverkas rejält. Så en ny iMac nu till WWDC kan mycket väl vara ARM-baserad.

Hade varit coolt, men det är för tidigt, utvecklarna måste få lite tid på sig så det finns native-applikationer vid lansering också. Vi vill inte ha en Microsoft-mjäää-lansering som enbart förlitar sig på emulering.

Ska vi spekulera så tror jag de lanserar de sin plan för det kommande året och hur utvecklarna ska förbereda sig (wwdc är ändå en utvecklarkonferans). ...men då måste utvecklarna få tillgång till något att börja utveckla/testa på och då ser jag tre varianter i min personliga sannolikhets ordning:

1. Mac Mini eller motsvarande med ARM-cpu som säljs som dev-kit om man har ADC-konto (jämför eGPU som de sålde som dev-kit, även om de valt att inte börja sälja någon egen eGPU)
2. dev-image av MacOS som går att läsa in på iPad Pro (magic keyboard gör den till en underbar laptop och det skulle kunna vara anledningen till ryktena om xcode på iPad. Bekymret med detta alternativ är RAM, 6GB i senaste iPad Pro blir gränsfall, men man kommer i alla fall snabbt igång)
3. xcode släpps för ios, under UI är det ju samma OS i alla apples prylar.

Permalänk
Medlem
Skrivet av Gramner:

Fast det är inte så konstigt att kod kompilerad för en 20 år gammal x86 CPU inte är särskilt optimal med dagens mått. Om vi ska jämföra med Aarch64 så bör vi rimligtvis utgå ifrån att bakåtkompatibilitet är irrelevant och låta kompilatorn optimera för en modern x86 CPU istället.

En del utav problemet med x86 (och dess STORA fördel) är just bakåtkompatibiliteten. Det har inte bara ett teoretiskt arkitekturmässigt pris utan har också ett pris i kostnaden för design och debugging utav nya processorer, i hur olika subenheter behöver vara beskaffade för att det skall vara transparent för gammal kod, osv. Det är svårt att göra en vettig värdering av precis hur mycket det kostar i designtid, processorprestanda och prestanda/W. Min känsla är att de enorma belopp som Intel kunnat investera i x86 och litografi har dolt en del av arkitekturkostnaden, men det är i praktiken omöjligt att sätta en siffra på det. (Vilket naturligtvis inte hindrar någon från att försöka. ) Intel har fortfarande en jättefördel i mantimmar nedlagd på en core-design, och litografiska processer som är optimerade för specifikt deras egna produkter. Att resultatet inte är bättre relativt sett är talande.

Permalänk
Inaktiv
Skrivet av Mindfighter:

Hade varit coolt, men det är för tidigt, utvecklarna måste få lite tid på sig så det finns native-applikationer vid lansering också. Vi vill inte ha en Microsoft-mjäää-lansering som enbart förlitar sig på emulering.

Ska vi spekulera så tror jag de lanserar de sin plan för det kommande året och hur utvecklarna ska förbereda sig (wwdc är ändå en utvecklarkonferans). ...men då måste utvecklarna få tillgång till något att börja utveckla/testa på och då ser jag tre varianter i min personliga sannolikhets ordning:

1. Mac Mini eller motsvarande med ARM-cpu som säljs som dev-kit om man har ADC-konto (jämför eGPU som de sålde som dev-kit, även om de valt att inte börja sälja någon egen eGPU)
2. dev-image av MacOS som går att läsa in på iPad Pro (magic keyboard gör den till en underbar laptop och det skulle kunna vara anledningen till ryktena om xcode på iPad. Bekymret med detta alternativ är RAM, 6GB i senaste iPad Pro blir gränsfall, men man kommer i alla fall snabbt igång)
3. xcode släpps för ios, under UI är det ju samma OS i alla apples prylar.

Håller helt med dig, möjligen med en uppdaterad Apple TV isf Mac mini som hårdvaran i ett dev-kit. Min utgångspunkt var dock uppgifterna om en ny iMac, uppbackat av rapporter om att iMac 27" börjar ta slut hos Apple. Det är det där sista som gör det till något mer än bara ett rykte och då började jag klura på hur "iMac-spåret" skulle kunna se ut.

Att Xcode nu släpps för iPadOS/iOS klassar jag som mycket sannolikt.

Permalänk
Medlem
Skrivet av anon214822:

Håller helt med dig, möjligen med en uppdaterad Apple TV isf Mac mini som hårdvaran i ett dev-kit. Min utgångspunkt var dock uppgifterna om en ny iMac, uppbackat av rapporter om att iMac 27" börjar ta slut hos Apple. Det är det där sista som gör det till något mer än bara ett rykte och då började jag klura på hur "iMac-spåret" skulle kunna se ut.

Att Xcode nu släpps för iPadOS/iOS klassar jag som mycket sannolikt.

450 dagar sen iMac uppdaterades senast, så det är dags och comet lake har ju kommit.

Jo, håller med om xcode på iPadOS, men det är många som önskat det över åren, vore coolt för lite mindre programmeringsprojekt.

Permalänk
Inaktiv
Skrivet av Mindfighter:

450 dagar sen iMac uppdaterades senast, så det är dags och comet lake har ju kommit.

Jo, håller med om xcode på iPadOS, men det är många som önskat det över åren, vore coolt för lite mindre programmeringsprojekt.

Övergången från PowerPC till Intel tog 2 år från att det annonserades på WWDC till att hela produktlinjen var utbytt. Denna gången tror jag det går fortare när man redan har så mycket i produktion runt sina egna Axx-chip. Det enda man behöver göra är ju att trycka ut befintlig iPad Pro i några nya formfaktorer. Jag tror samtliga Mac:ar är uppdaterade innan 2021 är slut.

En helt ny iMac med Intel skulle alltså bli rätt radikalt omgjord redan nästa år. Känns onödigt. En mindre uppdatering till någon nyare Intel-CPU är alltid möjligt men varför göra en stor uppdatering nu när det ändå kommer något helt nytt nästa år?

Iofs svårt att veta hur dom tänker. Mycket bestäms nog av logistiken runt produktionen är där har man som konsument svårt att se vad som pågår. Vi ser bara ytan.

Permalänk
Medlem
Skrivet av anon214822:

Övergången från PowerPC till Intel tog 2 år från att det annonserades på WWDC till att hela produktlinjen var utbytt. Denna gången tror jag det går fortare när man redan har så mycket i produktion runt sina egna Axx-chip. Det enda man behöver göra är ju att trycka ut befintlig iPad Pro i några nya formfaktorer. Jag tror samtliga Mac:ar är uppdaterade innan 2021 är slut.

En helt ny iMac med Intel skulle alltså bli rätt radikalt omgjord redan nästa år. Känns onödigt. En mindre uppdatering till någon nyare Intel-CPU är alltid möjligt men varför göra en stor uppdatering nu när det ändå kommer något helt nytt nästa år?

I see your point, du tänker på Macrumors mock-up:

Apple är ju bra på att förvåna, men jag skulle inte satsa pengar på det.

Permalänk
Medlem

The Apple ChromeBook- Not cheap, but slow and cheerful...

// LZ

Permalänk
Skrivet av Ase:

Så mao så blir det ännu en låst plattform där det kommer saknas stöd för program

Får hoppas det inte går så långt: En del av oss behöver en dator man kan greja med. Med det sagt klarar jag mig långt så länge jag har ett native Unix-skal.

Vad gäller stöd för program: Apple har rätt bra pli på sina utvecklare. Sannolikt blir det i den absoluta majoriteten fall en checkbox i Xcode, och så är programmet kompatibelt med aktuell CPU. Enda riktiga problemet i det sammanhanget är utvecklare som inte har lust att underhålla gamla program - dessa kommer att falla bort om man inte mot förmodan lyckas med bra (nog) emulering.

Undantaget skulle vara den minoritet programvara som har direkt arkitekturberoende kod. Vi som gillar att köra Windows-spel men inte att köra Windows kommer att behöva skaffa (eller hålla liv i) Linuxmaskiner med x86/x64-kompatibla processorer under överskådlig framtid.

Permalänk
Medlem
Skrivet av Ase:

Så mao så blir det ännu en låst plattform där det kommer saknas stöd för program, vill själv inte ha ytterligare ett telefon operativ på stationär dator. Det e nog med den bedrövliga google varianten, nu blir det definitivt farväl till allt med mac (apple)

Skrivet av Det Otroliga Åbäket:

Får hoppas det inte går så långt: En del av oss behöver en dator man kan greja med. Med det sagt klarar jag mig långt så länge jag har ett native Unix-skal.

Vad gäller stöd för program: Apple har rätt bra pli på sina utvecklare. Sannolikt blir det i den absoluta majoriteten fall en checkbox i Xcode, och så är programmet kompatibelt med aktuell CPU. Enda riktiga problemet i det sammanhanget är utvecklare som inte har lust att underhålla gamla program - dessa kommer att falla bort om man inte mot förmodan lyckas med bra (nog) emulering.

Undantaget skulle vara den minoritet programvara som har direkt arkitekturberoende kod. Vi som gillar att köra Windows-spel men inte att köra Windows kommer att behöva skaffa (eller hålla liv i) Linuxmaskiner med x86/x64-kompatibla processorer under överskådlig framtid.

Min kollega verkar rätt övertygad om att Apple förr eller senare kommer gå samma väg som för IOS/IPadOS/TVOS med MacOS, men jag tvivlar. Om datorn ska vara ett verktyg för kreativitet och ge nya möjligheter så måste det gå att – i alla fall som tillval – kunna köra mjukvara som inte måste granskas och godkännas av Apple och Google etc. Jag tror Apple fattar detta och försöker ”säkra upp” saker på annat sätt genom att be användaren om lov för minsta lilla ett program försöker göra. Detta är något som märks tydligt i aktuella MacOS Catalina.

Men, jag kan så klart ha fel - vi får se i framtiden.

Permalänk
Skrivet av star-affinity:

Min kollega verkar rätt övertygad om att Apple förr eller senare kommer gå samma väg som för IOS/IPadOS/TVOS med MacOS, men jag tvivlar.
Men, jag kan så klart ha fel - vi får se i framtiden.

Någon kommer ju alltid hålla liv i de öppna unixarna. Det är en smula mer meckigt och inte lika estetiskt tilltalande, men det är ett utmärkt alternativ om fekalierna träffar rotorbladen och allt annat består av Windows eller iPadOS (i sin nuvarande form).