Benchmark ger ju förstås alltid en uppfattning om prestandan med den hårdvaran och det OSet, så att om det man ska köra fungerar med dne kombinationen, så kan man kolla på värdena.
Men jag tror att om Apple skrev om MacOS, utan att utesluta några funktioner och stöd i jämförelse med senaste versionen för X86, men för ARM, så är jag skeptisk till att bnechmark skulle ge samma prestanda i den versionen av MacOS, med samma processor som iOS.
Däremot om du säger att det verkar stämma för ubuntu, så talar det väl för att det går att bygga ett OS, där det går att dra nytta även av ARMs fördelar, trots att det är ett fullvärdigt OS.
Kommentaren om att Ios skulle vara så väldigt mycket effektivare ser man rätt ofta. Finns egentligen ingen teknisk bevis för detta + en sak Steve Jobs påpekade när de initialt lanserade Ios var att Iphone kör i praktiken OSX.
Iphones är snabbare jämfört med samtida Android-telefoner i alla där CPU-delen är viktig. Det förklaras enkelt med att Apple legat ungefär tre år före i CPU-prestanda, en ledning som nu verkar krympt till ungefär två år.
MacOS och Ios använder samma OS-kärna och de har nära nog identiska systembibliotek mot applikationer bortsett från UI-lagret där MacOS kör Cocoa (optimerat för mus/tangentbord) medan Ios kör Cocoa-touch (optimerat för touch-skärmar).
MacOS och Ios använder samma "toolchain", LLVM. Företaget jag jobbar använder också LLVM just då designen är perfekt om man har produkter som körs på mer än en CPU-arkitektur.
Med LLVM använder man samma kompilator vare sig man bygger för ARM, x86, MIPS eller vad det nu må vara. Kompilatorns "front-end" (den som förstår det programmeringsspårk du kompilerar, LLVM har stöd för flera stycken) gör exakt samma sak oavsett slutgiltig CPU. Det som kommer ut är en "virtuell" assembler som innehåller betydligt mer meta-data än vad som är fallet om man gått direkt till säg x86-maskinkod.
Sedan finns en "back-end" för varje CPU-arkitektur. Så enda som skiljer är översättningen från den virtuella assembler till maskinkod för den specifika CPUn. Fördelen med detta är att man eliminerar alla fel som kan uppstå skillnader i hur kompilatorn hanterar programspråket, det är ju mer optimerat för människor än för maskiner så har historisk varit en stor felkälla när man ska stödja olika CPUer.
Översättningen från den virtuella assembler till maskinkod låter de som utvecklar den delen fokusera all kraft på att generera optimerad assembler för den aktuella CPUn. Man slipper det väldigt svåra arbetet med att tolka programkod anpassar för människor -> mer tid till coola optimeringar.
Både i det specifika fallet GB4 (som faktiskt knappt använder OSet i single-thread läget mer än att allokera minne), men även det generella fallet för applikationer, är skillnaden mellan Ios och MacOS väldigt liten. Iphone/Ipad är inte snabb p.g.a. Ios, de är snabb för de har en brutalt kraftfull CPU. Enligt Apple själva är A12X snabbare än 95 % av alla bärbara PC på marknaden, finns väldigt lite som tyder på att det skulle vara ett felaktigt påstående.
GB4 är inte en perfekt måttstock av datorer, det är ingen benchmark. Men GB4 är en brutalt mycket bättre måttstock än något som Cinebench. Deltestet "N-Body Physics" i GB4 verkar ge nära nod identisk relativ prestanda mellan system som CB15, men det är ett av 25 deltest i GB4. Det CB testar som GB4 (by-design då fokus är interaktiva laster) inte testar är hur systemen uppför sig om det är lastat under lång tid.
Tittar man på resultat från mobil CPUer (som inte kan överklockas och där RAM-hastighet normalt är samma), helst från NUCs eller liknande så kylningen inte ställer till det, så är resultatet i CB4 för enkeltråd-fallet inom några enstaka procent när man jämför Windows, MacOS, desktop Linux samt Android.
Upp till 4-6 CPU-kärnor är det hyfsat även i multi-trådfallet. Men efter det börjar det divergera rätt snabbt, då blir det Linux > MacOS > Windows. På HEDT, framförallt Threadripper, presterar Linux mycket bättre än Windows (är ~50 % skillnad med 2950X och ungefär ~100 % med 2990WX, >100 % om man jämför multi-socket servers).
Dock så har ju inte Ubuntu (linux) lyckats locka till sig samma 3e parts utvecklare för kommersiella, professionella program, och officiellt stöd för externa enheter, så det är lite svårt att bedöma vad det skulle innebära i realiteten med jämförbara system.
I kontext av GB4 ser jag inte hur detta relevant.
Sant att Linux inte lyckats alls på desktop. Däremot är Linux det dominerade OSet på servers och inom många specialområden (inbyggda system) nära nog det enda OS som är relevant idag.
Inbyggda system kan betyda små system med kraftigt begränsade resurser, dessa kör ytterst sällan Linux. Inbyggda system är extremt vanligt inom fall som många nog inte ens tänker på. Är primärt sådana system jag jobbar med, sådana som folk direkt eller indirekt använder varje dag utan att ens reflektera över det (förutsatt att systemen fungerar...). Inom dessa områden används alla möjliga CPU-arkitekturer, men går allt mer mot x86 och ARM.
Men därav så tänker jag att MS hade och fortfarande har en chans, med Xbox, att bygga för ARM, och sakta bygga upp ett nytt OS parallellt. Tråkig att se att dom inte tagit det steget och inte gör det inför nästa generation heller.
Håller med om att det är trist att nästa generation konsoler inte blir baserade på 64-bitars ARM. Givet att man verkar gå på Zen 2 (som lanseras i sommar) hade man lika gärna kunna använt ARM Deimos (designen är redan släppt till de med ARM-licens). Av allt att döma hamnar CPU-frekvensen på nästa generations konsoler ~3 GHz, i det området är redan Cortex A76 klart förbi i perf/W samt likvärdig i prestanda då den kan klockas strax över 3,0 GHz.
Deimos förväntas ha 15-20 % högre prestanda per kärna jämfört med Cortex A76 och så här långt har ARM varit väldigt bra på att faktiskt leverera de förbättringar de lovat. Tidigare var jag personligen inte så imponerad av det, man låg ju ändå efter x86. Nu är det rätt ordentligt intressant i.o.m. att Cortex A76 drar jämnt med senaste x86 modellerna sett till IPC.
Care About Your Craft: Why spend your life developing software unless you care about doing it well? - The Pragmatic Programmer