ARM i var fjärde bärbar dator om fem år

Det finns ju dock olika anledningar att vilja isolera/separera tjänster från varandra; dvs bakgrunden behöver inte alltid starta med en fråga om det går att bryta sig ur och hur svårt det isf är...

Håller med att *om* målet är att ha så stark isolering som möjligt så är väl en VM-lösning generellt ett bättre val (men det förekommer ju buggar även i hypervisors, så det är ju inte problemfritt det heller).

Men om det primära målet istället bara är att säkerställa att allehanda olika tjänster var och en körs i en korrekt miljö för den tjänsten och att en ändring för den ena inte råkar påverka den andra, osv, så kan ju containers vara helt utmärkt för detta.

Och ett typfall är "molnet", man vill ha sin "egen" OS-instans mot "alla andra" som kan tänkas köra på samma HW. Fast skulle hävda att det är långt mer av praktiska skäl: val av OS är en del av systemet och det valet ska inte redan vara gjort.

Tar man sig in i hypervisor är alla underliggande OS-instanser helt oskyddade på samma sätt som alla applikationer är helt oskyddade om man tar sig in i OS-kärnan.

Däremot väldigt svårt att se något större värde att inom samma system som hanteras av en och samma organisation ta overhead för varje "microservice" ska köra i en egen VM (blir löjligt overhead). Om man inte tar det för varje microservice, är det bara viktigt ibland?

Enda "hårda" reella begränsningen är kravet på cgroup v2, d.v.s. krävas att host:en har en kärna nyare än år 2016.

Övriga är samma begränsningar vilken applikation som helst utan "root" access får. Som står där går det att lyfta specifika delar vid behov.

Måste ändå nämna, givet vad artikeln handlar om, att HyperV på Windows stöds redan på ARM64, KVM har ARM64 stöd och Parallels Desktop har "Apple Silicon stöd". D.v.s. är inget problem att köra hypervisors på ARM64, stöd för detta är tvärtom något som designades in från start (hypervisor stödet på "gamla" 32-bit ARM patchades däremot in i efterhand, precis som för x86).

WLS2 (som likt Docker desktop kräver HyperV) stöds också under Windows 11 på ARM64.

Så kommande ARM64 baserade Windows laptops kommer ha det stöd man kan förvänta sig inom detta område.

Är väl kanske en definitionsfråga vad ett system är och när det blir ett till system.
Men ta frontend av en applikation vs backend. Eller webbcache framför en applikation.

I dessa scenarion är det rätt smidigt att se till att undvika att dela på samma io/resurser och framförallt om man blandar in nätverksstacken som kommer med flera container-plattformar där man måste trycka trafiken genom samma proxys. Då kan det vara rimligt att separera dessa på helt olika VMar/interface etc. men såklart också annat kan särskiljas. När man lägger allt i samma VM men i olika containrar är det många rätt svårdefinierade resursdelningar man gör och det kan vara rätt komplext att reda ut och sätta bra gränsvärden för alla dessa resurser. Allt från hur många DNS-slagningar får gå från respektive container till hur hög IO mot disken får man ha.

Eller i en fråga om olika känslighet på datat. Du har en inloggad del av en applikation kontra en publik del.
Då kanske kan vill säkerställa att även om någon confat fel, inte patchat eller annan orsak så riskerar man inte att det känsliga datat görs åtkomlig via fel väg. Hängslen och livrem samtidigt.

Ibland är det helt enkelt mer rimligt att ta overhead up front för att man kan se till att skydda eller dedikera resurser.
Allt handlar ju inte om att vara resurseffektiv eller billig.

Det finns flera sätt att få hög effektivitet. Det som 32-bit ARM (vilket är vad du måste mena ovan) är riktigt bra på är att göra väldigt kompakt kod. 32-bit ARM är lite udda för att vara en "RISC" då nästan varje instruktion är villkorad.

Fördelen med 32-bit ARM är att man får ut väldigt hög effektivitet hur single-issue och eventuellt även dual-issue designer. Är precis sådana som var aktuella för den tidsperiod du nämner ovan.

Sedan har 32-bit x86 en akilleshäl mot i stort sett alla RISC:ar, flyttalsdelen är ett totalt tågvrak vilket var ett problem när all rendering gjordes på CPU.

Problemet med Arm 32-bit designen, långt värre än t.ex. x86/x86_64, är att det enorma beroendet av CPU-flaggfält gör det otroligt svårt att extrahera någon större mängd parallellism ur en instruktionsström. Det är som att programmera massivt parallella program med enbart globala variabler...

ARM64/RISC-V är specifikt designad för att undvika detta. RISC-V behöver fortfarande bevisa sig själv, men både Apple ("Apple Silicon") och Arm själva (Cortex X serien) visar att det är möjligt att bygga väsentligt "bredare" designer med ARM64 jämfört med x86_64 och även Arm.

ARM64/RISC-V ISA är designad så att in/ut-register i praktiken är enda som ger beroende mellan instruktioner. Man undviker helt "globala tillstånd" i form av flaggfält som implicit uppdateras och implicit avgör resultatet av en operation (vilket var hur man konsekvent designade CPUer förra årtusendet).

Ett sett att övertyga sig själv om det är att bygga samma problem för ARM64 och 32-bit Arm. Kör det sedan på någon av de 4-issue designer som faktiskt stödjer 32-bit Arm (Apples 8-issue design stödjer bara ARM64), det kommer vara minst 30-40 % högre prestanda med ARM64 jämfört med 32-bit Arm. Det på samma CPU/mikroarkitektur.

Är inte så att AMD/Intel är oförmögna att bygga en lika "bred" mikroarkitektur som Apple, bara det att x86_64 kommer göra det långt mindre effektivt att skala prestanda på den "ledden". AMD/Intel jagar istället frekvens.

Rena 32-bit Arm var under nästa dess hela existens begränsade till 1-issue och på slutet 2-issue (Cortex A15/A17 var den enda 3-issue, men den var inte speciellt lyckad). Apple gick riktigt "på bredden" i samma sekund de droppade 32-bit Arm stödet.

TL;DR 32-bit Arm var helt rätt för de begränsningar och utmaningar man hade på 80-talet och början på 90-talet. Det är helt fel för dagens designer. Samma gäller MIPS och SPARC, de var riktigt bra för 1-issue 5-stage pipeline, men man insåg problemen när man försökte sig på superskalära designer med längre pipeline...