Windows 10 för ARM kan emulera 64-bitars x86-kod

Det är såklart superbra men samtidigt tänker jag.
Om jag skaffar en superportabel laptop med Arm, så vilken windows x86 mjukvara skulle jag vilja köra direkt på denna?
Det enda jag kommer på är alla 5 miljoner vpn klienter som man måste ha, men det känns som att dessa vpnklienter kommer känna av att de körs virtuellt och ej tillåta uppkoppling. Så frågan är för andra mjukvaror och svaret blir inga.
Skulle jag någon gång behöva köra något litet så fjärrstyr jag bara en dator och installerar det där.

Slutsats blir att emulering av windows x86 är superbra, det underlättar för folk att gå över, nu känner många detta som en nackdel och undviker plattformen. Men i praktiken tror jag folk inte kommer emulera så mycket och jag kan själv inte komma på något windows x86 program som jag skulle vilja köra direkt på den.
Går vi tillbaka i tiden till Windows RT. Ja bokförings, släktforsknings, diverse programmeringsprogram etc. Men tiderna har förändras, det mesta idag gör man direkt i webbläsaren.
*edit*
Riktigt stora krävande windows x86 program vill många såklart köra på laptopparna, det är bara det att de idag inte har prestandan för detta bortsett från Apples M1. I framtiden kommer säkert de andra ikapp och då är det bra att det finns bra virtualiseringsstöd.

Jag tror du har en poäng där. Innan någon skriker rakt ut att de minsann kör 200 X86 applikationer lokalt installerade på sin jobb laptop: Självklart är det inte samma situation för alla.

Men! För den stora massan av tjänstemän idag skulle man nog komma långt med en dagens Surface X innan man behövde emulera ett enda program. Har jag en webbläsare (edge chromium eller Google Chrome) samt Office paketet i native ARM så är jag klar sen. Alla andra applikationer på jobbet kör vi via webben. Till och med dem av oss som kör mer "exotiska" programvaror skulle klara sig, eftersom alla dem idag körs i webbläsaren eller via RDP anslutning till on-prem VPSer.

precis och det är dit utvecklingen går för alla användare. Vissa kör mer lokalt än andra, men alla gör det betydligt mindre än vad de gjorde förr. Bortsett då från terminalerna på 70 och 8talet.

Nu vet jag inte varför man skulle vilja ha Corsair LINK 4 på en ultrabook. Men resten av programvarorna så finns väl dessa redan idag till ens androidmobil och självklart kommer finnas till ens windows arm. Dessa programvaror är dessutom gratis, bara att installera. Så jag tycker din lista på exempelprogram inte var bra. Jag använder för övrigt alla de andra programvarorna förutom Soluno. Jag skulle aldrig komma på tanken att köra x86 versionen av dem när arm finns.

Ett problem är dock dessa miljontals vpnklienter och authorizations programvaror man ska ha. Dessa kommer dock nog aktivt försöka tjäna av virtualisering och ej tillåta det. Så om ens saknas, så hjälper det ej.

Ja i framtiden kommer behovet verkligen finnas. En dag går man över till helt till windows arm och då har man helt andra krav än på sin portabla windowslaptop. Det finns otroligt många programvaror som är svindyra att byta ut, jag vet riktigt kritiska system som idag fortfarande kör med 32 bitars windows 2003. -Med kritiska så att det blir stora tidningsrubriker om de skulle krasha.
Så emulering är ett måste, men jag tänkte mer för den stora skaran. Och för oss just nu så påstår jag att behovet inte är så stort, hade prestandan varit såpass bra i de icke Apple M1 processoerna så det gick att spela, så hade gamers viljat emulerat. Nu blir frågan mer vilka program som man vill emulera.

Kan nämna att jag av liknande anledning tidigare alltid återvänt till Windows, även om jag på det stora hela jobbar lika effektivt i GNU/Linux samt macOS.

Det händer väldigt ofta (speciellt i GNU/Linux) att en liten utility saknas eller helt enkelt fungerar sämre än motsvarande programvara i Windows.
Exempelvis styr jag enkelt min HTPC (gammal laptop kopplad till TV:n) via "Remote Mouse". Fungerar utmärkt i Windows, macOS, Android samt iOS... men i Ubuntu laggar samma programvara något fruktansvärt.

Vid andra fall har jag fått igång mina favoritspel (ofta inte helt utan blod, svett och tårar) i macOS via Wine, men inser att musen i sig beter sig udda då jag saknar Razers programvara.

Men precis som du säger, så kämpar Microsoft sig ifrån Win32-plattformen och Windows i sig är inte längre mitt förstaval av OS. För mig är det UWP-apparna och deras förvirrande systemkrav som fått mig att fly från Windows.

Jag hoppas att Microsoft lärt sig något efter Windows RT samt Windows 10 S, men jag vågar inte hoppas alltför mycket på Windows 10 X.

Ska dock bli kul att testa Windows på min kommande Apple M1, men frågan är varför jag ens skulle vilja göra det? Tycker att Windows 10 gett mig tillräckligt med huvudbry genom uselt stöd för RAW-filer utanför UWP-appar.

Själv använder jag därför FastPictureViewer Codec Pack (ännu ett beroende till Win32):
https://www.fastpictureviewer.com/codecs/

I både macOS och Ubuntu slipper jag helt detta problemet.

Helt klart verkar Apples intåg med ARM accelererat utvecklingen åt rätt håll även på PC. Har beställt en 5900X och hoppas det blir min sista stationära PC på x86.

Jag tror du skämtar, många har haft samma önskemål av anledningar som att de vill kunna köra windows x86 programvaror. Och jag har då undrat vilka utan fått ett bra svar.

Nej, ingen anledning mer än att jag vill att det ska gå.
Det är säkert väldigt opraktiskt och fullt av massa nackdelar.

För min del känns det som en viktig sak för Microsoft att göra, men också därmed en total o-nyhet. Det hade varit otänkbart att de inte försökte gå över till ARM till slut, speciellt nu när Apple har bevisat att x86 redan nu är föråldrad.

Vad hade alternativet för Microsoft varit? Hade det varit för tre år sedan hade det varit en riktig nyhet, nu är det bara förväntat och lite försenat enligt mig.

Det vill jag också efter att Microsoft övergav Windows Phone 8.1. Har en gammal Nokia Lumia 1020 som Microsoft effektivt förvandlade till en brevpress, då de i sista sekund strök den över mobiler som skulle få Windows 10.

https://www.windowscentral.com/windows-phone-81-store-shuts-d...

Varken Apple eller Google har lika effektivt dödat till synes helt fungerande produkter.

Om Microsoft för 8 år sedan hade släppt Windows arm låt oss kalla den Windows RT, hade det då varit en stor nyhet och inte försenat? Min fråga är ironisk då Microsoft redan riktigt har storsatsat på arm och det floppade värre än bara den, detta av den största anledningen att de var för tidiga. Och nu kritiserade du dem för att vara för sent ute eftersom de inte gjorde en ny omsatsningen direkt. Hade window RT inte floppat utan blivit en succe så hade detta fått otroligt mycket mer fokus av Microsoft idag.

Nu vet jag ej hur exakt de dödade windows Phone som du pratar om. Men självklart måste de spara och dra in på support till produkter som de inte satsar på. Windows Phone var en ekonomisk katastrof och de måste då gå drastisk till och stoppa utgifterna.

Ja timing är allt. Man kan vara för tidig och man vara för sen. Microsoft var ju ganska duktiga med tajmingen när dom släppte Windows i mitten på 80-talet, det måste man ge dom. Sen kan man misslyckas ibland också. Spännande ska det bli i alla fall hur Windows för arm blir.

Intressant val av problem med Linux... Speciellt med tanke på att jag någon vecka sedan började snickra på en mjukvara för virtuell input via exempelvis mobiltelefoner för allt från mus/tangentbord till spelkontroller specifikt för Linux. Du gav mig precis lite motivation att fortsätta med det projektet. (FOSS givetvis) Får återkomma till det projektet när jag gör något annat än att leka med mitt nya Index, kanske under julledigheten. Lite smått relaterat till diskussionsämnet så är givetvis stöd för X86(_64) och ARM(64) med i planen, lyckas jag så vill jag också ha RISC-V stöd men saknar hårdvara för att testa det i dagsläget.

Började projektet då jag ville lära mig lite nya grejer och var redigt trött på hur Virtual Gamepad var byggt. Den fungerar bara med Node 9, vilket är både utdaterat och är orimligt krävande för syftet. Hundratals MB RAM för någonting som bör kunna göras i ett lägre tvåsiffrigt tal, med mycket lägre CPU belastning.

Aldrig förstått x86-kramare, spelar väl ingen roll vad det är för arkitektur så länge man kan köra det man vill med bra prestanda? Det är väl knappast så att det finns en massa x86 assembler programmerare därute? (DÅ hade jag kanske förstått x86-kramandet, det är kanske jobbigt att lära sig nytt)

Du kan väl inte kalla det ”storsatsat”... jag skulle mer kalla det att de stod vid strandbrynet och försiktigt doppade stortån och när det inte var 25 grader varmt vatten så drog de tillbaka foten.

Utifrån mina egna åsikter så tror jag inte det finns några x86-kramare. Utan det är mer att övergången lär bli jobbig. Sett från ett gaming perspektiv så är övergången från 16-32-64 på Windows lite av en mardröm. Finns ingen gudomlig virtualiseringsmjukvara inriktad mot gaming, vilket skulle behövas... Det finns så många alternativ för att få ett spel att (kanske) fungera så man får huvudbry.
Men vem vet, det kanske är någon som sätter sig ned och börjar knacka kod för detta ändamål när arm blir the shit.

Jag skulle som sagt inte ha några som helst problem med att kasta ut x86 genom fönstret, så länge jag vet att övergången är smärtfri.

Apples M1 verkar ju prestera fint att spela x86-spel med via Rosetta2, jag tror inte MS behöver vara sämre. Det är bara snabbt kisel som saknas nu (och drivrutiner till riktiga grafikkort på ARM64 såklart)

Fördelarna med ARM64 är egentligen inte RISC specifika, finns ju rätt många andra RISC:ar som inte alls har någon genomsnittlig fördel mot x86. Det gäller egentligen alla ISA innan ARM64.

ARM64, och möjligen även RISC-V (vi kan inte vara säkra innan någon faktiskt designar något likt "Apple silicon" för RISC-V), är unika i att i genomsnitt ha en relevant fördel mot egentligen alla tidigare ISA. Anledningen är gissningsvis att ingen kunde skapa en "perfekt" ISA innan programvarusidan hade enats om vilken modell för multicore som passar bäst, det hände rätt mycket perioden ~2000 till ~2010, är bara ARM64 och RISC-V som designats sent nog att ha de besluten som indata.

Vill man specifikt följa utvecklingen kring ARM64 har AnandTech flera bra artiklar och självklart kan man följa nyhetsflödet från Arm själva.

Verkar vara en sak till Apple gjort, utöver den väldigt fina prestandan per kärna: man har lagt in HW-stöd för minneskonsistensmodellen hos x86, viktigt då den modellen skiljer sig en hel del från ARM64. Det är mer effektivt att använda ARM64 minnesmodellen, även den är designad med information från hur multicore faktiskt hanteras i modern programvara.

Men när man emulerar x86_64 har man inget val, då måste saker fungera enligt specifikationen för x86_64. Där används en tidigare populär modell som kallas Total Store Ordering (TSO). Det smarta från Apples sidan är att TSO är inget AMD/Intel kan skydda med patent, finns däremot patent runt x86-specifika saker som SIMD och andra instruktioner.

Genom att översätta alla instruktioner till motsvarande ARM64 samt implementera TSO när man kör under Rosetta 2 duckar man patentproblemet, man kommer runt IPC begränsningen x86 har p.g.a. variabel längd på instruktioner samt man kan hantera extremt vanligt förekommande och prestandakritiska minnesoperationer tack vare TSO stöd. Det sista är huvudvärken för Microsoft, de måste implementera TSO inom ramen för ARM64 normala minnesmodell, fullt möjligt men det blir inte speciellt effektivt

Borde inte x86-laget kunna ta fram en x86-mini med moderna instruktionerna som används och behövs och en rosetta liknande programvara som processar binärerna innan exekvering (översätter alltså). Lite sent nu när översättningar till ARM64 redan existerar dock?

Intel hade både hårdvara för emulering och programvara för emulering på Itaniumtiden. Transmeta körde allt med binäröversättning.

Front-end är en ganska liten del av processorn så det är nog ointressant så länge man inte försöker gå runt patent.

För ett år sedan hade jag sagt: verkar ju vara som att gå över ån efter vatten.

Men nu när man ser Apples M1 faktiskt ha högre IPC när den kör x86_64 kod än någon existerande x86_64 CPU känns det som: det är verkligen en väg AMD/Intel borde kika på!

Jag tror både Itanium och Transmeta hade rätt idé, för dem fallerade det på att de i botten använde en olämplig design.

VLIW, som Transmeta använde på HW-nivå, har visat sig fungera riktigt bra på vissa specifika fall men det verkar vara fel strategi för den typ av kod som man typiskt kör på skrivbordet.

Redan när IA64 designades hade man börja misstänka att VLIW hade en rad begränsningar som gjorde det olämpligt för en traditionell CPU. Man använde något som man kallade EPIC (Explicitly Parallel Instruction Computing), men har själv lite svårt att se hur det egentligen skiljer sig på något relevant sätt från VLIW.

För IA64 var sedan stöd för x86_64 lite av en nödlösning, men i fallet Transmeta var det ju den ISA man designade för att köra. Det som var rätt med idén är att översätta den väldigt komplexa x86_64 ISAn till något som är långt enklare att avkoda. Men tror att det hela föll just på valet av VLIW, vissa saker kan översättas väldigt effektivt till det (Itanium fungera faktiskt rätt bra på vissa HPC laster) men det fungerade öken på branch-tung kod med liten statiskt ILP.

Att översätta från x86_64 till ARM64 är mycket enklare att göra effektivt, det bortsett från den stora miss-match i minneskonsistensmodell. Men givet att Apples M1, som av allt att döma implementerar x86_64 minnesmodellen i HW, faktiskt har högre IPC än någon av AMD/Intels CPUer pekar det på att en statiskt översättning av x86_64 till semantiskt motsvarande "vettig" ISA verkar vara rätt väg framåt.

Frågan är hur mycket effektivare AMD/Intels skulle kunna göra detta om man specifikt designade en modern ISA vars huvudsyfte är att köra kod översatt från x86_64 fast där den nya ISAn har finesser som fast instruktionslängd och uppstädning av de tusentals x86 instruktioner som i praktiken aldrig används idag...