Windows 10 för ARM körs på Apples M1

Permalänk
Medlem
Skrivet av Yoshman:

TL;DR en mycket sannolikare förklaring verkar vara att Intels/AMDs designteam rätt mycket är clowner jämfört med Apples. Åter igen, glaset halvfullt så är det bra för det betyder att det rimligen borde finnas en hel del att hämta även om man är fast på x86_64!!!

Jag tror det snarare handlar om ledning och företagskultur. Intel har sett sig själva som det självklara valet framför andra och har helt enkelt inte ens behövt anstränga sig nämnvärt.

Efter att ha läst företagsekonomi, så tänker jag tillbaka till Kotlers alla visdomsord. Gammalt tillbaka var Hertz den stora ledaren för biluthyrning, varpå Avis (utmanaren) tog fram följande slogan "We try harder". Idag är Hertz nära nog konkursfärdiga. Det finns många liknande exempel där stora framgångsrika företag förlitat sig alltför mycket på tidigare segrar. Nokia och Ericsson kan nämnas som andra exempel på mobilmarknaden.

Min svåger berättade om sitt första jobb som lagerarbetare för 10 år sedan. Han hade upptäckt att de med små medel kunde öka effektiviteten med över 50%. De andra medarbetarna bad honom dock att hålla tyst om detta. Det visade sig att de satt i system att öka effektiviteten med 5% årligen, för att på så sätt motivera en löneökning för samtliga för chefen. Dvs de presterade långt under sin förmåga, bara för att kunna få större del av vinsten i form av lön.

Detta får mig att tänka på Intel, som gör precis vad marknaden förväntar sig. Varken mer eller mindre. På så sätt blir ledningen nöjda och värdet på företaget ökar med glada aktieägare som följd.

Enligt mig är detta kapitalismens baksida.

Sedan kom Apple och kastade om spelreglerna! Om och om igen!

Permalänk

Wow, ett riktigt framsteg inom cpu fronten. Jesus vad trött jag varit på nuvarande tdp med tillhörande ljudnivå för kylning, trodde vi var tvungna att vänta på sci-fi grafen eller något för att ersätta kisel med.

Permalänk
Medlem

Låter mer som virtualisering än emulering?

Permalänk
Medlem
Skrivet av walkir:

Jag försöker slå mig fri från Googles och Facebooks herravälde genom att exempelvis använda DuckDuckGo. Men då DuckDuckGo inte ger önskade resultat vid sökningar på svenska, så faller jag tillbaka till Google och fortsätter min onda cirkel (och föder Google med mer och mer data).

Har du valt Sverige för att begränsa sökningarna?

Även jag föll tillbaka till google i början men nu mer gör jag överskattningsvis endast 1-5% av mina sökningar via google då jag blivit mer van att använda duckduckgo, det blir jobbigt med andra sökmotorer när man vant sig vid bangs.
De google tjänster jag använder mest är !gm (googlemaps) !yt (youtube) !giurl (google image url search) och med firefox även !gturl.
Visst finns det sökningar som ger bättre svar via google men när man blivit van med duckduckgo så blir dom betydligt färre.

Skrivet av walkir:

Ganska skrämmande utveckling att se att exempelvis många svenska myndigheter har Google och Bing som förvalda sökmotorer. Gissar på att övriga företag har en liknande situation. "More data, more power" ...

Många är rädda för Huawei som spionerar på företag, men samtidigt så låter vi Google, Facebook, Microsoft och Apple kartlägga våra liv utan minsta eftertanke.

Jo samt att dessa amerikanska jättar även delar information med amerikanska säkerhetstjänsten.
Det blir lite panik i USA när ett Kinesiskt företag lyckats skapa en app (Tiktok) som kan samla in en del av den information USA verkar vilja ha monopol på.

Permalänk
Datavetare
Skrivet av Weiman:

Låter mer som virtualisering än emulering?

QEMU är i grunden ren emulering (QEMU = Quick EMUlator), det även om du kör x86_64 på x86_64 eller ARM64 på ARM64. I just detta fall användes HW-acceleration i form av Apples inbyggda hypervisor-service, i det läget blir en kombination av emulering (periferienheter) och virtualisering (typ allt som är rent CPU-beroende).

Visa signatur

Care About Your Craft: Why spend your life developing software unless you care about doing it well? - The Pragmatic Programmer

Permalänk
Medlem
Skrivet av Snubb1:

Har du valt Sverige för att begränsa sökningarna?

Tack för tipset! Skönt att man kan lära sig nya saker som 45-åring!

Permalänk
Skrivet av Yoshman:

Den beskrivningen jag sett om Rosetta 2 är att den bygger på binary lifting. D.v.s. man tar hela x86_64 programmet och "kompilerar det baklänges" till LLVM-IR. Det man har med LLVM-IR är rätt samma sak som hur shaders distribueras i moderna spel (där kör man SPIR-V med Vulkan eller DXIL med DX12, båda använder internt LLVM så SPIR-V och DXIL är båda varianter av LLVM-IR). När man har LLVM-IR har man egentligen en binär som kan köras på alla CPUer där det finns en LLVM-backend, vilket i stort sätt är alla idag relevanta CPU-arkitekturer.

I framtiden kanske det skulle vara vettigt att även "vanlig" program skeppas som LLVM-IR, för inom ramen av LLVM-IR skulle det vara fullt möjligt att behålla den meta-data som krävs för t.ex. effektiv användning av tagged-pointers på ARM64.

Att gå från källkod->LLVM-IR->ARM64 (vilket är den normala processen för C/C++/Swift på MacOS) är mer effektivt än källkod->LLVM-IR->x86_64->LLVM-IR->ARM64 (vilket är vägen man tar med Rosetta 2). De två LLVM-IR fallen innehåller olika kod, men de representerar samma logik. Det man får från x86_64->LLVM-IR steget är av sämre kvalité då man inte har lika mycket information om saker på högre nivå, t.ex. de du beskrev om pekare i ObjC/Swift.

Apples egna JS motor i Safari har helt klart raketer anslutna, framförallt när den körs på M1. Fast jag körde med NodeJS byggd från source, det är samma C++ källkod baserad på Google V8-motor som används på alla andra system där NodeJS finns.

Prestandan på "emulerad" (översatt) C-kod är i absoluta termer inte fantastisk, både Tiger Lake och Ryzen 5000 presterar bättre. Den är också 60-80 % av motsvarande program direkt kompilerad till ARM64 (d.v.s. kod->LLVM-IR->ARM64, Apples officiella kompilator är LLVM baserad).

Däremot givet att det faktiskt handlar om översatt kod och givet att "ingen" (inklusive jag själv) trodde det var realistiskt att någon skulle skapa en CPU körande något som inte är x86_64 som är kapabel att emulera x86_64 i samma hastighet som toppmodellerna från AMD/Intel (vilket är fallet om man håller sig inom segmentet för bärbara) så är prestandan på saker emulerade genom Rosetta 2 definitivt fantastisk.

Jag trodde definitivt inte själv att Intel/AMD drog benen efter sig. Innan Apple fanns det inte heller något som visade motsatsen.

Apple köpte PA-semi som startskott för deras CPU-satsning. PA-semi hade redan när de pillade med PowerPC designer som radikalt skilde sig från andra, men dels han de inte få ut så mycket av de coola sakerna de jobbade med, dels är PowerPC en ISA som ställd mot x86_64 har för- och nackdelar (ARM64 är rätt unik i att den egentligen inte har någon egenskap som gör den sämre än någon annan existerande ISA, Arm slog verkligen bollen ur stadion) men framförallt var det PA-semi hade tidigt väldigt lågt klockat vilket även längde gällde ARM64 designerna. Ändå var man hela tiden i framkant jämfört med andra mobil SoC.

Huvudpoängen här är: har väldigt svårt att se hur hela Apples försprång kan förklaras med ARM64, de ligger på rätt exakt dubbla prestanda per MHz mot Skylake/Zen2 och tog AMD/Intel två decennier att dubbla deras IPC till var de är idag. Ryktet gör som sagt gällande att Golden Cove ska upp ~50 % mot Skylake medan Ocean Cove (antar att det är första på 7 nm) ska upp ~80 % mot Skylake.

Innan Apples framfart hade jag varit väldigt skeptiskt till att det ens vore möjligt. Nu känns det mer som, det måste vara möjligt och varför har det inte hänt innan?

Om allt går som respektive företag förväntas sig under 2021 kommer ju även Arm, eller rättare sagt de som kommer bygga saker med Arms Neoverse N2, klart kliva förbi AMD/Intel på serversidan. Visst x86_64 är gammalt, men är det verkligen möjligt att förklara hela skillnaden bara genom ISA? Om svaret faktiskt är "ja" så är det verkligen så att ju snabbare x86 dör desto bättre, men har svårt att tro att fördelen verkligen är stor och förklaringen delvis kanske ligger i att AMD och Intel sneglat för mycket på varandra (för vem annan skulle de titta på för 5-10 år sedan?) och missat en den av de trender "uppstickarna" plockat upp.

Edit: det finns ett rykte kring varför Rosetta 2 presterar så pass bra som det ändå gör, förutom ISA finns en annan sak som radikalt skiljer sig mellan x86_64 och ARM64: minneskonsistensmodell. Är väldigt svårt att effektivt emulera x86_64 på ARM64, det omvända är lättare. Ryktet säger att Apples M1 implementerar två minneskonsistensmodell

  • normalt används ARM64 modellen, den är "optimal" i bemärkelsen att den på instruktionsnivå är en perfekt match till vad språk som C/C++/Java/C#/Rust m.fl. behöver för sina modeller

  • i Rosetta 2 används en modell kompatibel med x86, d.v.s. TSO (en väldigt välstuderad modell då den dels är lätt för människor att förstå, dels används den av x86 och SPARC)

Om det är sant tappas en del av prestandan där, ARM64 modellen tillåter mer parallellism (högre IPC) men finns inget sätt att översätta x86_64 maskinkod till optimal ARM64 då information gått förlorad i översättningen från LLVM-IR till x86_64.

Det är en sak som saknas i din analys, en processors arkitektur påverkar direkt vilken frekvens du kan köra den i och vid vilken frekvens den är som mest effektiv (energimässigt). Intel och Amd's arkitekturer är optimerade för att nå höga frekvenser. För att nå dit så behöver man göra val i arkitekturen som inte är IPC optimerade.

Dvs en del av skillnaden i IPC beror inte på ARM/x86 direkt utan på att arkitekturerna är designade mot olika frekvensmål.

Skall bli intressant att se hur Apple går vidare med större M-processorer om de fortsätter att prioritera IPC och effektivitet eller om de kommer att tweaka lite mot högre frekvenser.

Stavfel
Permalänk
Medlem
Skrivet av SkynetBuilder:

Wow, ett riktigt framsteg inom cpu fronten. Jesus vad trött jag varit på nuvarande tdp med tillhörande ljudnivå för kylning, trodde vi var tvungna att vänta på sci-fi grafen eller något för att ersätta kisel med.

Kanske dags för EU att stoppa energislukande processorer/datorer på samma sätt som Plasma-TV tvingades bort från marknaden? Tyckte inte att plasma-tekniken förtjänade den häxjakten som gjordes runt 2010, men nu när en 10W SoC kan utmana 125W CPU:er, så välkomnar jag något motsvarande för att tvinga fram effektivisering hos AMD och Intel.

Att gå från x86 till ARM är lite som övergången från glödlampan till lysdioder (LED). Själv har jag följt ARM sedan Acorn började utmana Amiga. Tror inte att många idag känner till att ARM en gång i tiden hade betydelsen "Acorn RISC Machine".

Här är ett sevärt klipp för övrigt:

ARM var så strömsnål i början, att processorn fungerade utan att datorn var inkopplad till nätström!

Permalänk
Medlem
Skrivet av Yoshman:

Blir allt mer uppenbart varför Apple var missnöjd med vad de fick från Intel.

Det första man lär inse med Apples M1 är: detta lär vara den långsammaste desktop-CPU vi någonsin lär se komma från Apple, den är mer jämförbar med en 4C/8T x86 än en 8C/8T modell.

Att Firestorm kan emulera x86 snabbare än alla Skylake/Zen2 baserade modeller avsedda för bärbara datorer indikerar rätt mycket att Intel helt tappat initiativet, när den kör ARM64 är den snabbare än någon annan CPU räknat per kärna. Som en vis man en gång sa: allt är relativt, att AMD klivit förbi Intel är primärt mer än effekt av Intels brist på utveckling än något annat.

Sitter man fast i x86 går det ändå att ha en "glaset halvfullt" syn på ovan. Innan Apple lanserade M1 kändes ryktena om att Golden Cove (planerad 2H 2021 i Alder Lake) ska få ~50 % högre IPC jämfört med Skylake lite tveksamt, nu känns det mer som om inte Intel minst fixar det kan man verkligen undra vad de håller på med!

OK att ARM64 är en bättre ISA än x86_64, men den skillnad vi nu ser ISO-frekvens är helt omöjlig att förklara med ISA, Firestorm är rätt mycket dubbel så snabb per MHz som Skylake/Zen2. Det är samma skillnad som mellan ursprungliga Athlon från 1999 till Zen2, ett span på 20 år (Intel "fuskade" här, deras spann för 2x IPC är kortare p.g.a. P4 som hade lägre IPC än P3)!!!

Båda är akterseglade av Apple och på serversidan kan mycket väl samma sak hända från Arms håll. Ställer man Skylake SP, Zen2 och Arm N1 (vilket är de aktuella mikroarkitekturen på serversidan) presterar dessa väldigt jämt sett per MHz och de klockar också väldigt snarlikt. Under 2021 kommer alla gå till nästa mikroarkitektur, AMD och Intel kommer båda få ~20 % högre prestanda per MHz medan Arm N2 förväntas få ~40 % högre prestanda per MHz (fortfarande rejält efter Apples prestanda per MHz, men Apple tillverkar inte server CPUer så är irrelevant).

Inte helt oväntat att QEMU körande ARM64 på ARM64 presterar i nivå med Roseetta 2 körande x86_64 på ARM64. Även med QEMU + HW-stöd (vilket användes här, kör man helt utan HW blir prestanda bedrövlig min 3900X får en ST GB5 poäng om 164 om man kör helt SW-emulerat, trots att det är x86_64 på x86_64) finns ändå delar som emuleras då QEMU måste hantera vissa läsningar/skrivningar mot RAM som minnesmappad I/O.

Med HW-stöd (KVM på Linux och Apples inbyggda hypervisor i fallet i artikeln) kommer man rätt nära native-hastighet då majoriteten av alla minnesaccesser nu hanteras av KVM/Apple-hypervisor som båda använder HW-stöd i CPU för virtualisering. Men till skillnad från en helt paravirtualiserad gäst där man kommer väldigt nära 100 % av native-speed måste QEMU fortfarande emulera periferienheter.

Rent strikt är Rosetta 2 inte emulering, vad man gör är något som kallas "binäry lifting" av x86_64 koden till en virtuell assembler, LLVM IR. Denna virtuella assembler översätts sedan till ARM64, vilket är vad man faktiskt kör. Är denna översättningsprocess som gör att det tar en stund att starta x86_64 program första gången på M1 Mac:arna.

Om man nu ska återgå till verkligheten är de flesta (framför allt Apples egna) jämförelser mellan M1 och Intel X86 gjorda på Mac-datorer, där Intels processorer throttlar hejdlöst på grund av Apples bristande förmåga att ta hänsyn till värmeutveckling vid designen av sina datorer. Design går långt före att datorn presterar. Så fungerar det i Apples värld. Sen är inte Apples operativsystem speciellt optimerad för Intels processorer och presterar inte speciellt bra. Därför blir skillnaden mellan M1 och Intel desto större. Jämför man med AMDs 5600X (vilken är AMDs långsammaste nya processor blir M1 väldigt frånkörd för det mesta. Om man ska jämföra GPU-prestanda ligger M1 ungefär i nivå med Nvidias GTX 1050 TI vilket är en fyra år gammal konstruktion som redan när den lanserades var en av Nvidias billigaste och enklaste GPU. AMD kunde ha haft en processor (APU) som slår M1 rejält när det gäller GPU prestanda, men eftersom AMD också säljer lösa grafikkort har de begränsat GPU-prestandan till att bara vara några enstaka procent bättre än förra generationens och lagt allt krut på många CPU-kärnor och trådar i stället. De tror att folk blir tillräckligt imponerade av en kraftig CPU. Tyvärr gjorde detta att jag investerade i en bärbar med Intelprocessor och diskret Nvidia-gpu fast jag hellre köpt en bärbar med AMD-processor. En sak Apple helt klart lyckats med är strömförbrukningen, den är verkligen revolutionerande låg sett till prestandan i datorvärlden. De har ju utgått från mobilprocessorer när de konstruerade M1.
Kolla länken för lite verklig och inte tillrättalagd benchmarking av M1:
https://www.youtube.com/watch?v=bdQ7u0mR570

Permalänk
Medlem
Skrivet av Trihxeem:

"People who are really serious about software should make their own hardware." - Steve Jobs

Jobs har faktiskt både rekryterat Alan Kay till Apple (1984, innan han lämnade) och i praktiken sparkat ut honom (1997, genom att han stängde ATG för att spara pengar) så det finns nog en god sannolikhet att Apples plan i det här fallet kommer från hans idéer.

Skrivet av Yoshman:

I framtiden kanske det skulle vara vettigt att även "vanlig" program skeppas som LLVM-IR, för inom ramen av LLVM-IR skulle det vara fullt möjligt att behålla den meta-data som krävs för t.ex. effektiv användning av tagged-pointers på ARM64.

Apple är inne på det spåret de också:

https://thenextweb.com/apple/2015/06/17/apples-biggest-develo...

Default om man skickar in en app till App Store är att Bitcode är på. Det går dock att stänga av.

Citat:

Apples egna JS motor i Safari har helt klart raketer anslutna, framförallt när den körs på M1. Fast jag körde med NodeJS byggd från source, det är samma C++ källkod baserad på Google V8-motor som används på alla andra system där NodeJS finns.

Den här gången menade jag mer bokstavligt. Firestorm klarar 4 flyttal åt gången, upp från 3 på tidigare generationer. Intel kan fortfarande bara köra flyttal på två av exekveringsportarna (0 och 1), åtminstone t.o.m Sunny Cove. Att Apple gör flyttalsenheten så bred lär vara enbart p.g.a Javascripts ovana att göra allt till doubles. Det finns visst ett helt gäng sådana optimeringar för att jobba runt Javascript.

Citat:

Prestandan på "emulerad" (översatt) C-kod är i absoluta termer inte fantastisk, både Tiger Lake och Ryzen 5000 presterar bättre. Den är också 60-80 % av motsvarande program direkt kompilerad till ARM64 (d.v.s. kod->LLVM-IR->ARM64, Apples officiella kompilator är LLVM baserad).

Det var mer vad jag väntade mig. 60-80% är ju inte dåligt iofs, men prestandan på Objective-C och Swift-kod är ännu mer imponerande.

Visa signatur

5900X | 6700XT

Permalänk
Medlem
Skrivet av Ceji:

Om man nu ska återgå till verkligheten är de flesta (framför allt Apples egna) jämförelser mellan M1 och Intel X86 gjorda på Mac-datorer, där Intels processorer throttlar hejdlöst på grund av Apples bristande förmåga att ta hänsyn till värmeutveckling vid designen av sina datorer. Design går långt före att datorn presterar. Så fungerar det i Apples värld.

Tycker nära nog samtliga ultrabooks har liknande problem, så det är inget unikt för just Apple. En gammal IBM Thinkpad hade också extrema problem med värmeutveckling och är inte mycket bättre idag. Köpte en laptop-kylare (Zalman likt nedan) till min Thinkpad och ser fram emot att använda den med min kommande MacBook Air M1.

Permalänk
Medlem
Skrivet av Teval:

Vad baserar du det på? Eller bara en gissning från din sida?

De 30 procenten hägrar...

Men apple kommer ju hävda att det görs för att se till att användarna inte installerar några program som snor deras information etc, eller andra, enligt apple, olämpliga program.

Och att företag som vill deras program skall finnas i deras ekosystem skall betala för rätten till det, annars så kan de ju söka sig till windows istället.

30%.... 30%.... 30%.... 30%....

Permalänk
Datavetare
Skrivet av Ceji:

Om man nu ska återgå till verkligheten är de flesta (framför allt Apples egna) jämförelser mellan M1 och Intel X86 gjorda på Mac-datorer, där Intels processorer throttlar hejdlöst på grund av Apples bristande förmåga att ta hänsyn till värmeutveckling vid designen av sina datorer. Design går långt före att datorn presterar. Så fungerar det i Apples värld. Sen är inte Apples operativsystem speciellt optimerad för Intels processorer och presterar inte speciellt bra. Därför blir skillnaden mellan M1 och Intel desto större. Jämför man med AMDs 5600X (vilken är AMDs långsammaste nya processor blir M1 väldigt frånkörd för det mesta. Om man ska jämföra GPU-prestanda ligger M1 ungefär i nivå med Nvidias GTX 1050 TI vilket är en fyra år gammal konstruktion som redan när den lanserades var en av Nvidias billigaste och enklaste GPU. AMD kunde ha haft en processor (APU) som slår M1 rejält när det gäller GPU prestanda, men eftersom AMD också säljer lösa grafikkort har de begränsat GPU-prestandan till att bara vara några enstaka procent bättre än förra generationens och lagt allt krut på många CPU-kärnor och trådar i stället. De tror att folk blir tillräckligt imponerade av en kraftig CPU. Tyvärr gjorde detta att jag investerade i en bärbar med Intelprocessor och diskret Nvidia-gpu fast jag hellre köpt en bärbar med AMD-processor. En sak Apple helt klart lyckats med är strömförbrukningen, den är verkligen revolutionerande låg sett till prestandan i datorvärlden. De har ju utgått från mobilprocessorer när de konstruerade M1.
Kolla länken för lite verklig och inte tillrättalagd benchmarking av M1:
https://www.youtube.com/watch?v=bdQ7u0mR570

Är inte hemma just nu så har inte tillgång till min MacMini M1. Men reagerade direkt när jag såg SciMark 2.0, inte en chans i Hälsingland att Firestorm får stryk av i5-9400F i det testet. Gjorde en snabbtest på en RPi4 (också ARM64) bara för att se om det finns något seröst fel med det testet på ARM64.

RPi4 körandes ARM64 Ubuntu 20.04 LTS får 336 Mflops, d.v.s. Firestorm skulle alltså vara mindre än dubbelt så snabb som en Cortex A72 @ 1,5 GHz, tror inte det...

Testade då på min 3900X, bygger jag den benchmark:en helt utan optimeringar får runt 700 Mflops. Det är antagligen just de han gjort, då är det rimligt kontra hans 5600X resultat. Bygger jag med någorlunda rimliga flaggor, d.v.s. i alla fall optimeringar påslagna, ökar resultatet till ~3340 Mflops.

D.v.s. hela videon är totalt värdelös för han har ingen koll på hur man använder Phoronix test suite.

M1 är i de flesta lägen världens snabbast CPU räknat per CPU-kärna. Nu har den bara fyra kärnor, där ligger begränsningen. Eller ja, den har åtta kärnor men fyra är enbart optimerade för maximal perf/W och har medioker heltalsprestanda och mindre än medioker flyttalsprestanda. Just då perf/W, även för de stora kärnor, är så bra handlar total prestanda bara om att trycka in fler kärnor. Man kommer slå i effekttaket betydligt senare än x86-gänget, hur långt man vill gå handlar därför mer om huruvida de är ekonomiskt vettigt att skapa en säg 16 C variant.

Ska köra om SciMark2 testet senare i kväll när jag har access till M1, då med vettiga flaggor. Har ingen Zen3 än (beställt en 5600X för flera veckor sedan, kanske får den till lucia) så får jämföra med 3900X poängen (testet är enkeltrådat så kvittar att 3900X har 12 kärnor).

GPU är naturligtvis inte imponerande ställd mot dGPUer, det är en iGPU som delar minnesbandbredd med CPU. Men den är ändå ungefär dubbelt så snabb som Iris Xe i Tiger Lake U vilket i sin tur är den snabbaste iGPU som finns på x86 sidan just nu.

Edit: körning av SciMark 2 på min MacMini M1

SciMark 2.0: pts/scimark2-1.3.2 Processor Test Configuration 1: Composite 2: Fast Fourier Transform 3: Jacobi Successive Over-Relaxation 4: Monte Carlo 5: Sparse Matrix Multiply 6: Dense LU Matrix Factorization 7: Test All Options ** Multiple items can be selected, delimit by a comma. ** Computational Test: 1 Phoronix Test Suite v10.0.1 System Information PROCESSOR: Apple Core Count: 8 GRAPHICS: Apple M1 Monitor: LG HDR 4K Screen: 3840x2160 MOTHERBOARD: Apple Mac mini MEMORY: 16GB DISK: 458GB File-System: APFS OPERATING SYSTEM: macOS 11.0.1 Kernel: 20.1.0 (arm64) Compiler: GCC 12.0.0 + Clang 12.0.0 + Xcode 12.2 Would you like to save these test results (Y/n): n SciMark 2.0: pts/scimark2-1.3.2 [Computational Test: Composite] Test 1 of 1 Estimated Trial Run Count: 3 Estimated Time To Completion: 2 Minutes [21:02 CET] Started Run 1 @ 21:00:31 Started Run 2 @ 21:01:07 Started Run 3 @ 21:01:40 Computational Test: Composite: 3143.34 3148.5 3163.79 Average: 3151.88 Mflops Deviation: 0.34%

5.4 gånger högre prestandan än vad han fick i videon
Visa signatur

Care About Your Craft: Why spend your life developing software unless you care about doing it well? - The Pragmatic Programmer

Permalänk
Datavetare
Skrivet av mpat:

Den här gången menade jag mer bokstavligt. Firestorm klarar 4 flyttal åt gången, upp från 3 på tidigare generationer. Intel kan fortfarande bara köra flyttal på två av exekveringsportarna (0 och 1), åtminstone t.o.m Sunny Cove. Att Apple gör flyttalsenheten så bred lär vara enbart p.g.a Javascripts ovana att göra allt till doubles. Det finns visst ett helt gäng sådana optimeringar för att jobba runt Javascript.

Anta att det är förklaringen, varför presterar då Zen3 och Tiger Lake U rätt likvärdigt i NodeJS (båda klockar ungefär likvärdigt enkeltrådat)?

Tiger Lake (Willow Cove) är identiskt med Sunny Cove när det kommer till ALUs.
Zen3 har likt Zen/Zen2 fyra exekveringsportar för flyttal, inte lika symmetriska som Firestorm, men man kan t.ex. utföra 2 fadd och 2 fmul per cykel (eller slå ihop det till två FMA per cykel, men även Intel kan göra två FMA per cykel). Zen3 har sedan även fått två extra portar på flyttalsdelen, en för store operationer och en för konvertering mellan heltal/flyttal. Så totalt 6 portar, men som sagt inte symmetriska (Intel har och en separat port för konverteringar och SIMD-lane-swapping + dedicerade load/store så är inte alls enkelt att jämföra).

Visa signatur

Care About Your Craft: Why spend your life developing software unless you care about doing it well? - The Pragmatic Programmer

Permalänk
Medlem
Skrivet av Yoshman:

Anta att det är förklaringen, varför presterar då Zen3 och Tiger Lake U rätt likvärdigt i NodeJS (båda klockar ungefär likvärdigt enkeltrådat)?

För att det finns annat som påverkar Javascript-prestanda? Jag menar absolut inte att fler floats per cykel är hela svaret, mer att det var ett väldigt tydligt exempel på hur Apple har optimerat sina kärnor för att göra det bästa av Javascript. Javascript och Objective-C, och numer också Swift, är språk som de optimerar mot, för det är det som iPhonen primärt kör. Jovisst är kärnan i C och en del bibliotek på låg nivå är i C++, men mycket av tiden spenderas att köra de tre språken. Det är inte tre språk är kända för att vara speciellt snabba (även om Swift blir bättre), så det finns säkert en del att tjäna på att optimera för dem.

Visa signatur

5900X | 6700XT

Permalänk
Medlem
Skrivet av walkir:

Tycker nära nog samtliga ultrabooks har liknande problem, så det är inget unikt för just Apple. En gammal IBM Thinkpad hade också extrema problem med värmeutveckling och är inte mycket bättre idag. Köpte en laptop-kylare (Zalman likt nedan) till min Thinkpad och ser fram emot att använda den med min kommande MacBook Air M1.

Vi har ett gäng HP ultrabooks som klarar ca 20 minuter i Teamsmöte innan dom hänger sig av värmeslag.

Visa signatur

SPELA: 13900K - Gaming X Trio 4090
LEVA: OnePlus 10 Pro - MacBook Air M2 13"
PLÅTA: Canon C70, R3, 1DX mkII, BMPCC6K
LYSSNA: KRK Rokit RP8 G4, Beyerdynamic DT 1990 PRO
FLYGA: DJI FPV, Avata

Permalänk
Medlem
Skrivet av Yoshman:

Rent strikt är Rosetta 2 inte emulering, vad man gör är något som kallas "binäry lifting" av x86_64 koden till en virtuell assembler, LLVM IR. Denna virtuella assembler översätts sedan till ARM64, vilket är vad man faktiskt kör. Är denna översättningsprocess som gör att det tar en stund att starta x86_64 program första gången på M1 Mac:arna.

Det låter som emulering för mig.
Det är väl snarlikt vad moderna snabba emulatorer av spelkonsoler gör, fast de använder med sina JIT-kompilatorer.

Permalänk
Medlem
Permalänk
Medlem
Skrivet av Cocosoft:

Det låter som emulering för mig.
Det är väl snarlikt vad moderna snabba emulatorer av spelkonsoler gör, fast de använder med sina JIT-kompilatorer.

Sker ingen emulering av hårdvara i Apples fall.

Permalänk
Datavetare
Skrivet av Cocosoft:

Det låter som emulering för mig.
Det är väl snarlikt vad moderna snabba emulatorer av spelkonsoler gör, fast de använder med sina JIT-kompilatorer.

Kanske är lite vilken definition folk har, men emulering i min bok är om man faktiskt körde x86-koden genom att tolka den via någon form av emulator. I detta fall översätts x86-koden till semantiskt likvärdig ARM64, den översatta koden kan sedan köras utan emulering.

Skrivet av Petterk:

Sker ingen emulering av hårdvara i Apples fall.

I detta fall emuleras en hel del periferienheter, däremot används Apples inbyggda ramverk för HW-acceleration av virtualiserad CPU (shadow TLB och liknande, det ger rejäl prestandaboost när detta är HW-accelererat).

Detta är vad som skickades till QEMU i just detta fall, alla "-device xxx" är instruktion till QEMU över vilka periferienheter som ska emuleras. "-accel hvf" är det som matchas in, med detta används de funktioner för virtualisering som finns i M1 via MacOS systemservice

./qemu-system-aarch64 \ -monitor stdio \ -M virt,highmem=off \ -accel hvf \ -cpu cortex-a72 \ -smp 4 \ -m 4096 \ -drive file=~/Downloads/pflash0.img,format=raw,if=pflash,readonly=on \ -drive file=~/Downloads/pflash1.img,format=raw,if=pflash \ -device ramfb \ -device qemu-xhci \ -device usb-kbd \ -device usb-tablet \ -device intel-hda \ -device hda-duplex \ -nic user,model=virtio \ -drive file=~/Downloads/Windows10_InsiderPreview_Client_ARM64_en-us_20231.VHDX,if=none,id=boot,cache=writethrough \ -device nvme,drive=boot,serial=boot

Visa signatur

Care About Your Craft: Why spend your life developing software unless you care about doing it well? - The Pragmatic Programmer

Permalänk
Medlem
Skrivet av Rågren:

Vad Apple kallar saker spelar inte så mycket roll. De har något emot ordet emulering med tanke på att de kallar deras egna iOS-enhetsemulator för en "simulator".

Skrivet av Petterk:

Sker ingen emulering av hårdvara i Apples fall.

Korrekt, men det gör inte många emulatorer heller. Jag tog upp ett exempel. HLE handlar för det mesta om att tolka API-anrop etc. Se t ex N64-emulering.

Permalänk
Medlem
Skrivet av Yoshman:

Kanske är lite vilken definition folk har, men emulering i min bok är om man faktiskt körde x86-koden genom att tolka den via någon form av emulator. I detta fall översätts x86-koden till semantiskt likvärdig ARM64, den översatta koden kan sedan köras utan emulering.

Jag håller med om att det blir diffust om man tolkar det lösare, men problemet med en strikt syn på emulering är att frågetecken uppstår, och saker vi idag kallar för emulering skulle inte kunna klassas som det.

Permalänk
Medlem
Skrivet av Cocosoft:

Vad Apple kallar saker spelar inte så mycket roll. De har något emot ordet emulering med tanke på att de kallar deras egna iOS-enhetsemulator för en "simulator".

Korrekt, men det gör inte många emulatorer heller. Jag tog upp ett exempel. HLE handlar för det mesta om att tolka API-anrop etc. Se t ex N64-emulering.

Ja, men i N64-emulatorn tolkas fortfarande hur hårdvaran fungerar. Här är allt nativt.

Permalänk
Medlem

Verkar prestera bra med Windows också
https://9to5mac.com/2020/12/02/windows-on-m1-macs-run-arm-vir...

Citat:

Impressively, the Martin’s M1 Mac mini benchmarked much higher than Microsoft’s Surface Pro X…almost doubling the single-core score, and coming in almost 2,000 higher in the multi-core score. Sure it’s not a desktop like the Mac mini, but you can get about the same performance from the $999 M1 MacBook Air, a closer competitor to the $999 Surface Pro X.

Permalänk

Om Windows 10 funkar hyfsat på Raspberry Pi 4, varför kan inte Microsoft kompilera/optimera/med flaggor/ builds för vilken ARM-silikon som helst?
Ska bli intressant att se vem som först knäcker Apples HW/SW-lås och kan på något sätt undvika Apples avsaknad av BIOS/EFI. För att sedan kunna installera Linux/Windows på M1!