Microsoft werkt aan emulatie x64-software voor Arm-laptops met Windows 10

Microsoft werkt aan emulatie van x64-apps voor systemen met Windows on Arm. Dat blijkt uit code van Microsoft op GitHub. Daarmee lijken geruchten van vorig jaar over de mogelijke komst van x64-apps naar Windows on Arm bevestigd.

De vermelding van x86_64 voor Arm64-systemen is opgemerkt door Twitter-gebruiker Longhorn, die verwijst naar een Github-pagina met de titel Add linker support for x64 code emulation on ARM64. Het gaat om een Github-pagina voor Microsofts C++/WinRT-project voor de Windows Runtime.

De vermelding bevestigt geruchten van vorig jaar dat de Arm-versie van Windows 10 ondersteuning voor de emulatie van x64-programma's voor de Arm64-architectuur krijgt. Die komst zou een beperking van het huidige Windows on Arm verhelpen.

Windows on Arm kan standaard 32bit- en 64bit-versies van Arm-apps draaien, maar voor de emulatie van x86-code voor Arm gebruikt Windows 10 de WOW64-laag. Dit Windows-on-Windows-subsysteem kan alleen 32bits x86-software emuleren en dat betekent dat 64bit-programma's niet draaien. Veel Windows-software is daarom niet beschikbaar op bijvoorbeeld Windows-laptops met Snapdragon-processors.

Reacties (159)

[FreezeXJ]

Waarom is Microsoft zo bang voor het hercompileren van hun software voor ARM? Is het echt zulke brakke zeut dat dit soort emulatie ze moet redden, of zitten er bedrijfsbelangen die tegen ARM of willekeurig welke andere architectuur zijn?
Gezien hun overgang van x86 naar x86_64 (die nog steeds loopt, en vermoedelijk nog wel een jaar of 5 blijft lopen) verwacht ik dat hun codebase gewoon te groot en gevaarlijk is om aan te zitten, en dat ze er dan maar omheen werken.

[Blokker_1999]

Windows is gewoon compatibel met ARM. Windows heeft eigenlijk altijd wel elementen gehad waarbij het meerdere architecturen ondersteunde en met Windows 10, waarbij alles vanaf 1 uniforme codebase wordt ontwikkeld heb je in die codebase dus ook gewoon volledige compatibiliteit voor alle ondersteunde platformen, waaronder ARM dat vroeger gebruikt werd voor telefoons, maar ook voor embedded apparaten (Windows CE bestaat niet meer).

De reden dat MS bijvoorbeeld nog altijd x86 ondersteund is niet omdat Windows het zelf nodig heeft, maar omdat er enorm veel applicaties bestaan die nooit naar x86_64 zijn gebracht.

[zx9r_mario]

Windows RT was een ARM versie. Heb nog een Surface 2 RT met Office 2013.

[peercoin]

windows 10 werkt op de raspberry pi (maar nog niet helemaal perfect)

https://pi64.win/

[tweazer]

Eind jaren 80 had microsoft overigens ook al een produkt genaamd windows RT. Het was een server versie van windows om realtime files beschikbaar te stellen op een netwerk (wow !). Tegenwoordig vindt je daar weinig van terug. Kennelijk een hippe naam die gerecycled is. Wanneer zou microsoft BOB weer uitkomen ?

[Grauw]

Het gaat met name om 3rd party software, niet om die van Microsoft zelf.

[FreezeXJ]

Die komt vanzelf wel als er een ARM-Windows bestaat (zo lang dat een netjes gesupporte is, en geen Phone-OS dat na een jaar deprecated is). Dit soort overhead wil je gewoon niet als je ergens performance wilt (zie wat Wine doet met performance van de gemiddelde Windows-code)

[rbr320]

Die komt vanzelf wel als er een ARM-Windows bestaat

Dat zou je denken maar de praktijk is vaak anders. Linux bestaat toch ook alweer een tijdje en toch zijn er genoeg software makers die hun software niet op Linux willen aanbieden. En het aloude tegenargument van marktaandeel gaat hier niet op, want het marktaandeel van Windows op ARM zal net zo laag zijn.

Dit soort overhead wil je gewoon niet als je ergens performance wilt (zie wat Wine doet met performance van de gemiddelde Windows-code)

Netto niet zo veel. Het kleine beetje performance verlies dat Wine je geeft wordt vaak weer goed gemaakt doordat Linux iets efficiënter om gaat met resources dan Windows. Bovendien is het een slechte vergelijking want Wine vertaald alleen maar OS API calls en niet een volledige processorarchitectuur.

[Reactie gewijzigd door rbr320 op 24 juli 2024 03:21]

[Eonfge]

Er wordt ook beetje bij beetje gewerkt aan een Wine on ARM oplossing:
https://wiki.winehq.org/ARM

Dan heb je tweede project, waarbij Wine en ARM emulatie worden gebundeld. Eerst wordt er een translatie-laag gebruikt om Windows calls naar Linux over te zetten, en vervolgens worden deze calls aan een emulatie-laag gegeven om op ARM te draaien. Toepasselijke naam, Hangover:

https://github.com/AndreRH/hangover

[Reactie gewijzigd door Eonfge op 24 juli 2024 03:21]

[tweazer]

Jammer dat niet de powerpc/dec methode wordt gebruikt: een executable werd een eerste keer omgezet naar native kode, als de eerste run goed ging werd de executable vervangen (uitgebreid) met de native code waarbij latere runs meteen native opgestart konden worden. Nu blijf je vertalen (met alle voors en tegens)...

[tweaknico]

Daarnaast werd zodra een call herkent werd die ook native aanwezig was de native versie gebruikt.
(Dus alle Windows eigen DLL's waren effectief native).

[ReneX]

Was dat niet al op de Alpha processor? (OpenVMS)

[tweazer]

Was dat niet al op de Alpha processor? (OpenVMS)

Vax/DEC "=" Dec Alpha

Als ik mij goed herinner werd dat niet zozeer bij het opstarten van de binary gedaan maar bestond een import tool om de distributie media te lezen, bij het installeren/wegschrijven naar schijf werd de juiste binary gekozen/gemaakt. Correct me if I'm wrong of course ... Al dat geklungel met tig time/feature delimited licenties maakt dat ondanks dat het een geweldig os was, ik vax/vms/openvms probeer te vergeten qua detals ... "help help"

[Zezura]

Klinkt intressant. Maar dan heb je wel toegang nodig tot de sourcecode.

[Reactie gewijzigd door Zezura op 24 juli 2024 03:21]

[tweazer]

Nee niet echt. De meeste winst qua hardware (beeldscherm, I/O) zit in system calls native maken die eenzelfde hardware aanspreken. De meeste winst aan gebruikerszijde zit in het vertalen/optimaliseren van de meest gebruikte code. Apple verving per OS upgrade in de Rosetta omgeving steeds meer calls door native calls. Het grootste pijnpunt IMHO was de grafische aansturing, daar hebben (nu ook nog?) OS fabrikanten grote moeite om nieuwe standaarden vrij te geven en toch backwards compatible te zijn (met oude software op nieuwe hardware en vice versa nieuwe software op oude hardware). DirectX, openGL etc lastige materie. Ook was Adobe heel erg ver in de mac pro g5 periode in het behalen van maximaal rendement uit de cpu bij specifeke filters. Als opsteker heb ik zo eens een G5 dual 2Ghz 2005 (?) bijna gratis naar een macpro 2009 dual 2.26 kunnen omruilen: het was voor een klant bij die apple winkel goedkoper en sneller om een g5 te kopen voor specifieke taken en gekochte photoshop filters.

[MSalters]

Tegenwoordig is zo'n vertaling simpel genoeg dat elke moderne x86-64 het altijd doet. AMD is er rond de K6 tijd mee begonnen, Intel na de eerste generatie Pentiums. De native code wordt gecached in de CPU, maar een paar kB per core is genoeg. Daarboven is hervertalen efficienter dan opslaan.

Deze x64-arm vertaling gebeurt in software, dus dat is iets minder efficient. Caching zal daarom aggressiever zijn, maar het zou me verbazen als de vertaalde code op disk bewaard gaat worden. Het grote voordeel van x64 code is dat het compacte code is, dus die vertaling is duidelijk groter dan het origineel.

[Grauw]

Als jij het zegt... als consument ga ik geen computer kopen met een processor waar maar een fractie van de programma’s op draait. En daarmee ontstaat een kip-ei probleem, want ontwikkelaars gaan geen mankracht steken in een platform dat niemand gebruikt. En dan is er nog software die niet meer actief ontwikkeld word. De emulatie lost dat op. Hopelijk voor Microsoft en ARM tenminste .

[bbob]

De emulatie lost het op papier op.

Als je gaat kijken naar het snelheidsverlies door de emulatie is het gewoon huilen. De snelste arm wordt na emulatie een langzame x86.
Dus waarom zou je dan veel geld voor een snelle arm kopen die dan met emulatie een langzame x86 is.

Emulatie is uiteindelijk geen oplossing.

[catfish]

Heel veel software is niet cpu gelimiteerd en is het dus niet belangrijk dat het iets trager gaat.
Emulatie is dus wel degelijk een zeer goede oplossing om een overgang te maken.
Apple heeft zo de overstap van PowerPC naar x86 gemaakt via project Rosetta.
Nu denk ik niet dat MS volledig wil overgaan van x86 naar Arm, maar het lijkt mij niet ondenkbaar dat ze dit voor een aantal toepassingen overwegen.

[bbob]

Dat iets trager vervang dat via emulatie maar als gewoon heel veel trager.

Deze uit uit 2018: https://www.techspot.com/...rm-performance/page2.html
een snapdrogon 835 toen topmodel is daarin als heel veel trager dan een budget intel x86 N3450

hier nog eentje uit 2018: https://mspoweruser.com/w...y-and-with-x86-emulation/

Waarom zou je veel geld uitgeven voor een topmodel arm om dan budget prestaties te krijgen.

Je maakt de vergelijking met apple, leuk maar je vergeet apple maakt zowel software als hardware. MS doet alleen software. Daarnaast apple had veel eigen software, invloed op 3de. De hoeveelheid x86 software is totaal niet te vergelijken met apple.

Daarnaast zie ik x86 niet zo maar verdwijnen. arm zou er naast kunnen komen als alternatief. MS blijft uiteindelijk gewoon een softwarebedrijf

[batjes]

Welkom bij een transitie periode.

Windows is heel hard op weg om volledig platform onafhankelijk te worden. Met de Universal Windows Programs en de Universal Windows Drivers, maakt het eigenlijk niet meer uit op welke CPU architectuur de boel draait.

Microsoft gaat hier verder mee en is nu ook al enige tijd bezig om de Win32 API platform onafhankelijk te maken. Dit gaat wel een stukje lastiger, gezien ze van en voor elk paltform een eigen vertaal/emulatie/virtueel laagje moeten bouwen.

De snelheid van X86 op ARM kan misschien wel om te huilen zijn... Maar wat maakt dat eigenlijk uit voor de gemiddelde kantoorwerklpek of huiscomputer? Die gebruiken een browser, office en ???. Verder kunnen ze hun smartphone-store fix krijgen door de Microsoft Store te gebruiken voor al je dagelijkse idle clicker/run en overige jaren 90 flash spelletjes.

ARM heeft een ontzettende potentie voor desktop/laptop systemen. Niet voor niets dat naast Microsoft, ook Apple en Google zich hier mee bezig houden. Zelfs AMD gebruikt ARM al tegenwoordig en is er ook mee bezig om dit in de toekomst uit te breiden. x86 zal waarschijnlijk niet zo maar verdwijnen, vooral door 30 jaar aan geschiedenis die er aan vast zit. Maar het kan heel hard gaan als MS met Windows een waardig paltform weet op te bouwen op ARM, waar ook die paar X86 applicaties zonder gedoe op draaien, hetzij wat langzaam.

Kijk hoe snel Windows weg viel uit het dagelijks leven van vele mensen door Android en iOS. Binnen 5 jaar tijd ging men van 99% windows in het thuis computergebruik, naar meer dan 90% op een smartphone bezig zijn. ARM heeft al een heleboel terrein gewonnen van X86.

[Reactie gewijzigd door batjes op 24 juli 2024 03:21]

[GHorsie]

Het is toch wel grappig als je je beseft dat Windows vroeger al op meerdere platformen draaide. De oorspronkelijke Windows NT draaide al op ia-32, DEC Alpha en power-pc en later ook op Itanium en MIPS. Dus het is niet echt vreemd dat Microsoft nu ARM gaat ondersteunen. Vanaf het begin werd al gebruik gemaakt van een Hardware Abstraction Layer (HAL)

[bbob]

ARM heeft al een heleboel terrein gewonnen van X86.

Leuk betoog maar x86 is alleen maar gegroeid omdat de markt in zijn geheel gegroeid is. Arm mag op smartphone populair zijn, op de desktop is het nog steeds geen succes, ook niet met linux desktop, android desktop het is nog steeds geen succes.

Maar goed wie weet kan MS met hun arm versie voor iets meer succes op de desktop gaan zorgen of als over een paar jaar smartphone voor iedereen zo snel is dat je smartphone dan je desktop is. Denk als je het zo bekijkt dat MS op de langere termijn nog steeds lokt naar de smartphone markt en misschien met universeel windows lukt ze dat op arm gebaseerde smartphones na heel veel jaren dan alsnog.

[psychicist]

ARM op de Linux desktop is een ontzettend veel groter succes dan op de Windows desktop. Het is logisch dat de aantallen ARM desktops en laptops nog niet in de buurt komen van die van x86 desktops en laptops, maar de hardware was tot voor kort ook nog niet zo krachtig en de softwareondersteuning aan verandering en verbetering onderhevig.

Windows op ARM zie ik niet zo snel slagen. Het is een beetje de omgekeerde situatie van Linux op de x86 desktop, een soort first-mover advantage. Volgens mij blijft het voornamelijk Wintel vs Linaro/Apple zonder al te veel overlap, zoals nu ook al het geval is.

[MSalters]

Nou...

De Win32 API is al sinds het allereerste begin (Intel 860, geen x86 CPU) platform onafhankelijk. De Win32 ABI (B van Binary) daarentegen is bijna per definitie platform-afhankelijk. En daar hebben ze nu dus een uitdaging; die x64 software verwacht ook een x64 ABI. Die zal dus vertaald moeten worden. Daarnaast heb je tot de ABI laag nog een x64 emulator nodig.

Bovendien heeft Microsoft een tweede troef. .Net is nooit afhankelijk geweest van x86, en maar beperkt van de Win32 API. De Win32 ABI is al helemaal irrelevant. C# code draait dus op de normale ARM snelheid.

[Zezura]

Hoe bedoel je niet CPU gelimiteerd als je maar genoeg taken uitvoert zit je zo aan het limiet en dan telt efficiëntie per proces echt wel mee.

[deregtx]

Het is gewoon een tijdelijke oplossing. Apple deed dat ook met hun transitie van PowerPC naar x86. Emulatie zorgt dat applicaties werken totdat er Native ARM applicaties uitkomen.

[bbob]

Apple leuk verhaal maar die maken eigen hard en software en hebben maar fractie van aantal systemen in vergelijking met windows. Windows heeft veelvoud aan software, zie ook mijn commentaar hierboven.

X86 zie ik zo snel niet verdwijnen dus zullen er 2 naast elkaar blijven. Daarnaast hoe gezond is het als MS voor ARM uitsluitend met Qualcom werkt ?

[deregtx]

Ja iedere ARM chip(Die aan een minimale performance spec voldoet) zou ondersteund moeten worden door MS Windows.

[MSalters]

Linus Torvalds heeft rond 2016 nog wel eens uitgehaald naar al de Chinese ARM-ontwerpers die met ongedocumenteerde SoC's op de markt kwamen, die met precies 1 kernelrevisie wilden booten en niet te upgraden waren. Performance was het probleem niet, met die kernel waren ze snel zat. Maar als je al niet eens Linux x.y.z+1 kunt draaien op die ARM chip, dan is Windows 10 helemaal kansloos.

AArch64 helpt een beetje, maar een realistisch minimum zou moeten zijn "elke ARM chip (waarvan de maker blijvend zorgt voor Windows 10 drivers) zou ondersteund moeten worden".

[tweazer]

Daarnaast hoe gezond is het als MS voor ARM uitsluitend met Qualcom werkt ?

Misschien dat in die richting Apple 'aan het vrijen' is voor de nieuwe mac CPU's en weten ze in redmond meer dan de tweakers hier ? Het zou een nieuwe positie tusen apple en qualcomm betekenen qua licenties ... Zelf zou ik liever een kijkje nemen bij de amazon hardware divisie vwb ARM ontwikkelingen....

[Zezura]

Verbaasd me niks als Apple met MacBook ook overgaat op eigen processors.

[Abom]

3rd party software, zoals de Adobe suites, werkte prima met de oplossing van Apple.

[mark8264]

Het probleem dat hierdoor opgelost moet worden is het draaien van oude software die niet meer ondersteunt word. Dan maakt dat snelheidsverschil weinig uit. De emulatie is natuurlijk erg inefficient, maar omdat de nieuwe hardware veel sterker is kan het nog steeds die oude programma's prima draaien. Zo werkt emulatie van video games ook.

De meeste software zal uiteindelijk gewoon een ARM versie krijgen, vooral naarmate andere bedrijven ook weg bewegen van Intel. Als de oude software dan beschikbaar blijft door de emulatie dan zullen consumenten weinig bezwaar hebben tegen een ARM chip, vooral omdat deze chips voor de meeste software gewoon veel betere prestaties voor minder geld zullen leveren dan Intel chips.

[bbob]

De vraag is en blijft wat bereik je hiermee ten opzicht van x86 hardware.

Het ligt helemaal aan de software of de emulatie cpu intensief is of niet. Dat kan het geval zijn maar hoeft niet. Draai je bijv photoshop dan zal de emulatie heel traag zijn.

Dat de meeste software een arm versie krijgt is een aanname. Er is zo veel windows software dat het maar de vraag is of dat zo is. Je kan eerder stellen dat waarschijnlijk de meest populaire software een arm versie zal krijgen, waaronder misschien photoshop word, excel enz.

Het enige voordeel van arm is de nu nog iets langere accuduur bij laptops. Op desktops heeft het verder weinig voordeel. Dus dat massaal op arm gaan, dat is voorlopig nog een illusie.

[aldieaccounts]

Veel mensen werken nog met bar oude x86 software. Die oude software draait vaak prima op arm.

Ik heb recent nog voor een kennis een oud boekhoudtprogramma'tje (Win32) aan de praat gekregen op godbetert een raspberry pi met behulp van een virtuele windows XP install in qemu. Dat ging prima (afgezien van het in mijn ogen onbruikbare boekhoudprogramma, maar ja).

[arjandijk162]

Net zoals Chromebooks in een aantal markten zeer goed verkopen is onder windows de wens om veel programma's te installeren steeds minder aanwezig bij een deel van de consumenten. Als zij Office en een browser kunnen draaien volstaat dat prima. Mocht er een keer iets afwijkends langskomen dan accepteren ze performance verlies en evt de onmogelijkheid om alles met hetzelfde apparaat te kunnen doen. Daar krijgen ze dan wel een energiezuinig (en betaalbaar) apparaat voor terug.

Betaalbaar komt later als de highend apparaten de markt overtuigd hebben van de kwaliteiten. Al lijkt het of MS ook niet zeker weet op welk paard te wedden.

[Reactie gewijzigd door arjandijk162 op 24 juli 2024 03:21]

[x280]

Chromebooks (en andere ARM laptops) zijn lang niet meer betaalbaar, ik zou echt wel een significante prijsverschil eerst moeten zien voordat ik een ARM gebaseerde "laptop" ga nemen in plaats van een x86 laptop.

[arjandijk162]

Als ik bij de mediamarkt zoek onder de 400 euro zie ik veel Chromebook. Ik kan de kwaliteit hiervan verder niet beoordelen, maar wel allemaal geadverteerd met +10 uur batterij. Als je voor hetzelfde geld minder vaak bij een stopcontact hoeft te zijn en de performance is voldoende, zie ik het wel als alternatief.

[theobril]

"Betaalbaar komt later als de highend apparaten de markt overtuigd hebben van de kwaliteiten. Al lijkt het of MS ook niet zeker weet op welk paart te wedden."
Het paard paart.

[arjandijk162]

true

[HooksForFeet]

Nee dus. Er is zat software die niet meer onderhouden wordt omdat de ontwikkelaar niet meer bestaat, de code niet meer vindbaar is, of omdat het gewoon om bedrijfstechnische redenen niet meer het geld waard is om het te onderhouden.

[geoffrey.vl]

dan kopen deze bedrijven voor hun antieke dingetjes een pc met Windows x86 al dan niet 64bit?

[HooksForFeet]

Ah, je hebt bedrijfskunde gestudeerd zie ik. Ja, topadvies, specifieke hardware kopen voor verschillende toepassingen.

[geoffrey.vl]

Ik zie niet in wat je opmerking over m'n studies bijdraagt aan deze discussie. Flauw.

On topic dan maar: het is nu niet dat x86 zomaar verdwijnt, of Windows enkel maar ARM gaat ondersteunen. Je hebt vrije keuze wat je aankoopt, had je vroeger een dependency op x86 dan is er ook geen enkele reden om ineens naar ARM over te schakelen. Bovendien, als deze software voor je bedrijft echt zo nodig is maar je kan het niet eens updaten, dan scheelt er toch wel wat aan je risico-analyse. Dat ze er geen geld in willen investeren, dat gebeurt, maar je kan moeilijk achter die keuze staan. Ik heb het hier niet over al die SAAS oplossingen van tegenwoordig, maar echt gewoon cruciale updates. De praktijk is natuurlijk niet de theorie...
Als MS zich wil bezighouden met deze niet-optimale oplossing dan is dat natuurlijk hun keuze, en uiteindelijk ook een gevolg voor de bedrijven die daarvoor kiezen. Zowel positief (snelle ondersteuning) als negatief (performance). Ik zie het eerder als opstapje om het ARM platform snel "brede" support te geven, zoals we destijds het keuzevakje hadden om software in compatibiliteitsmode te draaien. Maar het is zeker niet de meeste ideale of de correcte oplossing. Daarvoor hebben we de juiste compilers, SDK's, support in IDE's, ondersteuning voor software distributie, support voor open-platformen, ... nodig.

Het is buiten deze kwestie eigenlijk, maar ja voor vele toepassingen is specifieke hardware de beste oplossing: een smartphone != fietgps != laptop != server != workstation enz.

[SkiFan]

Daar zou ik niet vanuit gaan. Veel oude bedrijfssoftware wordt maar nauwelijks meer gesupport, en dan is dit helemaal een stap te ver. Bovendien is het niet alleen een kwestie van opnieuw compileren, ook de frameworks die je gebruikt moeten ARM ondersteunen zonder emulatie.

[Robbaman]

Bovendien maakt het voor dit soort oude software (die dus gemaakt is om te draaien op oude hardware) ook minder van belang dat je performance verliest. Zelfs met emulatie is er een goede kans dat de software op een moderne ARM-chip beter draait dan de software oorspronkelijk deed op native-hardware ten tijde van release. Dan zal het vast niet helemaal onwerkbaar zijn vandaag de dag.

[Clemens123]

Toch helpt het om het platform aan te wakkeren.
Dit is een kip ei verhaal.
Momenteel gebruikt niemand ARM omdat buiten Office en Edge niets compatibel is.
Omdat niemand het gebruikt zullen devs er ook geen tijd insteken.
Resultaat: het platform sterft vroeg of laat.
Emulatie helpt hierbij. Gebruikers zien voordelen aan het nieuwe platform (bv. meer batterijduur, LTE of zelfs 5g ingebouwd), en zien ook dat alles werkt, zei het wat trager, maar daarmee kunnen ze leven voor hun doeleinden. Meer mensen gebruiken dan dit ARM platform en softwarebedrijven zullen dan overwegen om hun apps native te maken.
Cruciaal is wel dat MS ook cross platform ontwikkeling aanmoedigt en zo eenvoudig mogelijk maakt.

[BLACKfm]

Prop in een beetje laptop een WWAN kaartje en je hebt ook 5G (uitgaande dat er een simkaart in kan).
De genoemde 'voordelen' zijn er nu ook al, maar dan op een platform dat native al prima werkt.

Ik zie best wel wat in een lichtvoetig mobiel windows platform. Ik ben voor mijn native x64 windows omgeving nu toegewezen op een RDS omgeving. Dit betekend wel alle prestaties die ik van een volwaardig systeem verlang, maar helaas met een kleine lag. Het enige wat ik er dus nog niet op kan is gamen, voor de rest heb ik gewoon een volwaardige windows syteem in mijn broekzak (zolang ik een internetverbinding heb).

Al jaren heb ik de hoop dat 'dit' (het op dat moment kleinste x86/x64 systeem) mijn ultieme droom is. Maar ik wordt telkens teleurgesteld. En dat is al sinds de Atoms. Netbooks die als een natte krant presteren. Ik heb mij vanwege de prijs nog niet kunnen wagen aan de M serie processors, maar ook daar zal ik zeker teleurgesteld worden.

Wil je een beetje zakformaat systeem hebben kom je al gauw aan de GPD / Gole / Ockel systemen. Maar die liggen nog niet zo lekker in de broekzak als een mobiele telefoon.

Een Windows 'tablet' van 7 inch zou nog kunnen als de bezels niet zo enorm waren (die tablets zijn veelal wel goedkoop, maar traag, en dus te groot door de bezels).
Een 'smartphone' die op een volwaardige versie van windows draait zou ik dus maar wat graag in de armen sluiten, maar prestaties als vanaf mijn RDS zal ik de komende 20 jaar niet hoeven te verwachten denk ik.

[disjfa]

Dat heeft Microsoft al tot 3 keer toe geprobeert zonder enigsinds support van bedrijven, dan flopt het relatief snel ja. Ik gok dat ze daarom nu het van de andere kant proberen en regelen dat alles wel draait op arm, alleen beter als het native gecompiled word.

Mischien is dit een juiste keuze en mischien niet. Ik hoop het wel.

[Jonathan-458]

Omdat ieder leek die Windows ziet, automatisch verwacht dat alle software geinstalleerd & werkt met Windows.

Zie de vele opmerkingen Windows RT, Windows 10 ARM, Continuüm, Windows 10s etc.

Men kan maar niet gewend raken dat Windows applicaties vanuit de Microsoft Store geinstalleerd moeten worden bij die versie, daarnaast ontbreekt er gewoon veel belangrijke software in Microsoft Store.

Daarnaast wordt er gewoon een hele hoop oude legacy software door bedrijven gebruikt.

Vandaar de focus op emulatie.

[Reactie gewijzigd door Jonathan-458 op 24 juli 2024 03:21]

[DCK]

Die komt vanzelf wel als er een ARM-Windows bestaat.

Dit slaat de plank mis. Het gaat maar deels om nieuwe software of huidige actief onderhouden software. Die kan in grote mate worden gehercompileerd.

De verwachtingen die mensen hebben bij het gebruik van Windows is dat random obscure meuk/utilities die misschien al sinds Windows 98 werken gewoon nog door blijven werken. Windows heeft al 25 jaar een enorme bibliotheek aan niche-software opgebouwd. Die bibliotheek niet aan kunnen bieden op kleine laptops die Windows draaien is een afbreukrisico voor Microsoft - het zijn de kleine dingetjes die mensen op Windows houden en niet naar iOS/Android/macOS/Linux/ChromeOS sturen.

Deze emulator stelt ARM hardware in staat om dezelfde staat van dienst die Microsoft of op x86_64 heeft aan te bieden op ARM. En daarnaast helpt het ook een transitiefase voor developers die nog niet voor ARM bouwen.

[dmantione]

Laat ik het zo zeggen: Op een Linuxdesktop wil je van alle serieuze programma's een Linux-native versie draaien, maar, Wine is bijzonder bruikbaar voor het geval je een obscuur Windows-programmaatje wil of moet draaien. Het zijn vaak de kleine lullige zaakjes die voor een een afhankelijkheid aan Windows zorgen en voor die zaakjes is Wine (indien het compatibel is) een prima hulpmiddel om de afhankelijkheid aan Windows te doorbreken. De prestaties zijn dan niet zo van belang, het gaat erom dat het draait.

Voor een Windows op ARM precies hetzelfde: Het wordt pas realistisch als de grote belangrijke applicaties native gedraaid kunnen worden. Zodra dat het geval is, dan is een emulatie als deze een goede oplossing om de laatste touwtjes die iemand aan x86 vasthouden door te knippen.

[_Thanatos_]

Wine is geen emulator van machinecode. Het simuleert Windows API's. Niet te vergelijken dus.

[SuperDre]

Mwa, als producent van bepaalde kantoor software is het helemaal niet interessant/gewenst om een extra versie erbij te moeten onderhouden.

[crankthisup]

Microsoft mag zelf ook wel wat meer voor het Windows on ARM platform doen. Zo is nog steeds geen native versie van Microsoft Teams terwijl Electron al een tijd ARM ondersteuning heeft. Als Microsoft al zo lui is, waarom zouden 3rd parties dan tijd en moeite in een ARM versie steken?

[MSalters]

Teams op x86 valt bij mij ook om de haverklap om, dus zo vreemd is dat niet. Eigenlijk werkt het alleen op x64 een beetje, en ook daar niet geweldig.

[Wolfos]

De ontwikkelaars van Visual Studio zijn anders nog steeds bezig om smoesjes te verzinnen waarom 32-bit beter zou zijn.

[psychicist]

Hebben ze al een versie van Visual Studio uit die native op ARM64 draait? Zo zouden ze al hun eigen software eerst als ARM64 binaries beschikbaar moeten maken alvorens naar andere bedrijven te wijzen voor het ontbreken van goede softwareondersteuning.

[Wolfos]

Ik had het aanvankelijk nog over AMD64, want zelfs dat ondersteunen ze nog niet natively. ARM word al helemaal een mooi verhaal

[SuperDre]

maarja, waarom zou dat nodig zijn voor de IDE zelf? 64bit is niet altijd beter. Naast dat er natuurlijk nog steeds hele delen van VS worden herschreven.

[MSalters]

"set PreferredToolArchitecture=x64".

Werkt sinds VS2015. Dat is dus de architectuur van de compiler zelf, niet van je target. Die stel je nog steeds op de oude manier in. (Configuration Manager).

[TechSupreme]

Dat er een transitie periode moet zijn voor overgang naar het nieuwe platform is alleen gemak voor je bestaande basis. Een harde overgang is voor niemand leuk en daardoor zullen meeste ook bij het oude platform blijven. Apple heeft hetzelfde gedaan met hun overgang van IBM naar Intel.

Zo ook de reden waarom Windows 10 nog x86 ondersteunt. In de wereld zijn er nog genoeg mensen die H81, B85 of Q87 chipsets draaien met en processor die x64 gewoon niet ondersteunen. Als je naar de statistieken kijkt heb je dan 2 keuzes. Of je laat x86 compleet vallen en laat een groot deel van deze computers in de kou, dat wil zeggen dat ze blijven hangen op Windows 7 met alle gevolgen van dien.

Of je verlengt die periode met ondersteuning in Windows 10 in de hoop dat met de tijd het aantal x86 PC's zo klein wordt dat je x86 ondersteuning kan laten vallen.

Daarnaast is er nog de vraag: "waaorm zou je als developer een apart x64 versie ondersteunen?". Veel ontwikkelaars kiezen ervoor om bij x86 te blijven puur omdat ze x64 niet nodig hebben. Valve kiest er vanwege praktische redenen voor om Steam te houden op x86 en gelijk hebben ze. Er zijn geen voordelen voor hun bij het compile en onderhouden van een x64 versie.

[Reactie gewijzigd door TechSupreme op 24 juli 2024 03:21]

[tweazer]

Er zijn geen voordelen voor hun bij het compile en onderhouden van een x64 versie.

Meer geheugen kunnen adresseren en het sneller kunnen gebruiken (snellere instructies, minder emulator overhead om steeds naar 32 bit mode te moeten overstappen voor een 32 bits proces in een 64 bits systeem) !?

[dmantione]

Meer geheugen heeft de Steam-client niet nodig, ook geen snellere instructies. De overhead voor overschakelen naar 32-bit mode die je noemt bestaat niet, 32-bit mode betekent gewoon één bitje zetten, klaar.

[MSalters]

Windows intern is vrijwel altijd 64 bits; de Steam client heeft dus WOW64 nodig (Ja, diezelfde uit het artikel hierboven). Elke API call moet dus vertaald worden. Dat is niet 1 bitje, some moeten er complete blokken geheugen gekopieerd worden om ze onder de 4GB grens te krijgen.

[dmantione]

Dat laatste is onjuist: Applicaties hebben virtuele adresruimtes. Aan de zijde van het besturingssysteem hebben de zgn. "desciptor tables" (indien de processor in 64-bit mode draait) altijd 48-bit pointers, of de applicatie die gedraaid wordt nu 32- of 64-bit is maakt daarvoor niet uit. Een besturingssysteem hoeft dan ook geen data te gaan kopiëren om die voor een 32-bits applicatie beschikbaar te maken, eender welke geheugenpagina van 4KB kan altijd in de 4GB aan virtuele adresruimte van een 32-bit applicatie afgebeeld worden.

Het wordt anders bij 32-bit hardware. Stel je hebt bijvoorbeeld nog een (32-bit) PCI-slot met daarin een kaart, dan kunnen de bronnen op die kaart alleen in de eerste 4GB fysieke adresruimte gezien worden en moeten gegevens van/naar de eerste 4GB gekopieerd worden, omdat alleen dat geheugen voor de kaart bereikbaar is.

[MSalters]

Hele pagina's kun je inderdaad remappen, maar niet elke geheugenoperatie is pagina-aligned. Neem bijvoorbeeld een `LPITEMIDLIST` (Long pointer to an item ID list). Dit is een Win32 object wat je terug krijgt van bijvoorbeeld SHBrowseForFolder( ). Wow64 moet die byte voor byte kopieren. Dat kan niet eens met een simpele memcpy, want de lengte van dat ding is embedded in de structuur ervan.

[TechSupreme]

Er zijn genoeg programma's die niet meer als 4Gb horen te gebruiken, ik durf zelfs te zeggen dat een overgroot deel dat niet hoort te gebruiken en hoeft het ook niet te gebruiken. De Steam client is daar weer een voorbeeld van.

De claim dat het sneller zou zijn is ook weer zoiets, hoe sneller? Het is niet zo dat x64 perse sneller is in alle gevallen. Soms is het sneller en soms weer niet.

Intel CPU's kunnen dynamisch overschakelen tussen verschillende modi, dat is al sinds de 286 tijden. Op oudere Itanium processoren die IA-64 ondersteunen was er wel spraken van emulatie en dat werd eigenlijk alleen ondersteund onder Server. Wat WOW64 in Windows 10 doet is de overschakeling tussen x64 en compatibility mode regelen.

[MSalters]

ASLR is een stuk veiliger als je random adressen boven de 4Gb kunt gebruiken. Alle programma's zouden dat moeten gebruiken, Steam zeker.

[TechSupreme]

Mwah, er zijn manier om ASLR. Een bufferoverflow aanval kan een naastliggende functie overschrijven/aanroepen, maar dat hoeft niet. Kan ook goed zijn dat binnen de bestaande functie iets wordt veranderd. Simpele bufferoverflows zoals vroeger zijn zeldzaam, meestal is een aanval gelaagd waarin de overflow een entrypoint is.

De notie dat je veiliger wordt omdat het bereik groter wordt vind ik maar raar, je zult er alleen langer over doen. Het is niet veiliger, het is alleen beter in verbergen.

Overigens doet WoW64 de 32bit functie relocated binnen het gehele bereik.

Als je nou zou zeggen dat de x64 versie signed drivers verplicht en dat patchguard standaard is, dan zou ik het nog met je eens zijn. ASLR alleen is niet de super beveiligingsfeature die sommige willen dat het is. Als je het icm met andere features gebruikt dan kan het aanvullend zijn tot een totale veiligheid, maar alleenstaand is het niet veel.

[Reactie gewijzigd door TechSupreme op 24 juli 2024 03:21]

[Martin.Air]

Ten eerste, dit gaat niet enkel om Microsoft code. Maar ook om applicaties van derden, bijvoorbeeld Photoshop die jij 8 jaar geleden hebt aangeschaft en nog steeds wilt gebruiken. Of GTA V die je gratis kreeg van Epic games.

Ten tweede, veel applicaties die performance moeten bieden worden geschreven met een specifiek instructieset in gedachten. Deze 'hercompilen' komt dus neer op de hele codebase uit elkaar trekken en alle stukken code die specifiek voor een instructieset geschreven zijn herschrijven naar de 'gelijkwaardige' instructiesets op de nieuwe CPU. Dit is niet een project voor een paar weken, maar eerder jaren per applicatie.
Dit is ook de reden dat je zoveel 'remasters' van games ziet die best veel ontwikkeltijd nodig hebben. Zo waren delen van Age of Empires 2 bijvoorbeeld geschreven voor toenmalig beschikbaren instructiesets. Jaren later draaide de game dus best wel slecht op moderne CPUs toen die specifieke instructiesets niet meer direct ondersteund werden maar door de CPU werden geemuleerd naar moderenere instructies. Vandaar dat de 'Age of Empires 2 HD' versie beter draait, deze is namelijk geupdate met generieke code ipv instructiespecifiek. Echter had het gebruik van generieke code toen der tijd niet gekund, dan was de performance van de game niet goed geweest voor de computers van toen.

[juanita]

Elke nieuwe cpu van Intel bevat toch altijd alle eerdere instructies + uitbreiding? Oude games zouden dus nooit slechter moeten draaien op nieuwe processoren.

[tweazer]

Kleine nuance: de allereerste pc spelletjes waren niet "wallclock" aligned. Niet voor niets zat een turbo knop op de eerste pc's; de spellen werden anders onspeelbaar in turbo mode..Netto draaien ze dan supergoed, alleen het spelplezier ...

[Reactie gewijzigd door tweazer op 24 juli 2024 03:21]

[mae-t.net]

Als je terugkijkt dan zie je dat Apple precies hetzelfde heeft gedaan een tijd geleden, alleen dan van PPC naar x86. Daar was de voornaamste reden de compatibiliteit van de apps. Dat zal bij Windows vrijwel zeker hetzelfde zijn. In tegenstelling tot OSX is Windows NT zelfs altijd al voorbereid geweest op gebruik op meerdere architecturen. Dat is er nooit helemaal uitgesloopt en ook recent nog bewezen dat dat gewoon werkt (Windows RT, Windows Phone).

[field33P]

Sterker nog, het was terug van nooit weggeweest. Windows 2000 werd alleen voor i386 uitgebracht (met uitzondering van een speciale servereditie voor de ItanicItanium), maar intern werd er nog jaren na dato een build voor de DEC Alpha gemaakt om te garanderen dat het OS niet platform-afhankelijk zou worden (iets wat Microsoft goed uitkwam voor XP en Server 2003 voor AMD64)

[tweazer]

Apple had toen een enorm voordeel dat de powerpc ontwikkeling een factor verder was dan de toenmalig intel en motorola series. Leuke G4 reclame hier overigens. Kortom het snelheidsverlies werd gecompenseerd door 2 a 3 keer meer performance. Een ARM met 16 cores (desktopje voor ~ E 800 ), zal een aardige deuk in een pakje boter slaan voor de consument. Als die 16 ..96 core ARM's gaan dalen in prijs zal Intel het zwaar te verduren krijgen...

PS voor apple is het weer een nieuwe desktop OS processor serie, alhoewel ze met ipads, iphones, appletv's en watches al ervaring genoeg met ARM hebben..

6502/65c02/65c816 -> 68000/68020/68030/68(LC)040 (en intel met 'enterprise OS') -> powerpc 601/603/603e/G4/G5 -> intel xeon/i3/i5/i7/(i9) -> ARM

[Reactie gewijzigd door tweazer op 24 juli 2024 03:21]

[SuperDre]

Omdat er nog een hooooooooooop 32bit/64bit x86 native applicaties zijn. En als die dus ook gewoon op Windows on Arm kunnen draaien zonder problemen, dan is dat een extra platform die bedrijven kunnen aanschaffen zonder dat ze zich zorgen hoeven te maken of die legacy applicaties nog wel blijven werken.
Kijk, voor een Apple was het niet zo'n probleem om gewoon compleet 32bit te dumpen, want zoveel applicaties waren er (in verhouding tot windows) toch niet en die paar die dan gingen piepen maakte Apple zich geen zorgen om. Windows is dat dus een heel ander verhaal.

[HooksForFeet]

Het gaat om -alle- x64 software, niet alleen die van Microsoft.

[thommy_99]

Ik vraag me af waarom hier zoveel performance verloren gaat en zoveel negatieve kritiek op komt, terwijl rosetta voor macintosh bij mijn weten vrij vlot ging. Is het omdat performance nu jaarlijks een fractie stijgt tegenover toen?

[Arrigi]

Een van de redenen van Apple om over te stappen was dat de Intel CPUs toen enorm veel meer performance (per Watt) leverden. Als je dit artikel van 2006 leest, zie je dat de Intel CPUs tot wel 2 tot 4x zo snel waren als de PowerPC die eruit ging. Plus, je kreeg een core erbij.
Als je dan zelfs de helft van de snelheid mist door emulatie op een singlethreaded applicatie, draait het nog steeds aan de originele snelheid. En die extra ongebruikte core, die kan het OS en andere applicaties draaiende houden. Dus de algemene indruk is dat je met Rosetta waarschijnlijk heel goede performance had. Iemand heeft een vergelijking gemaakt en komt uit op vaak toch wel een 50% verschil native x86 vs Rosetta.
Daarnaast was Rosetta schijnbaar ook behoorlijk beperkt in de precieze omstandigheden waaronder het kon werken, dat kan helpen bij optimalisatie of het niet opmerken dat je CPU-hongerige applicatie niet vooruit te branden is, als de applicatie toch niet kan starten.

In dit geval zijn x86 en ARM waarschijnlijk om en om aan elkaar gewaagd op gelijk wattage (ik vind niet meteen een goede consument-test), dus heb je door emulatie een hoger energieverbruik én minder performance.

TL;DR: PowerPC was gewoon ver inferieur aan de Intel CPUs van die tijd. De Core architectuur was zó veel sneller, dat zelfs 2x vertraging door emulatie niet opviel.

[Reactie gewijzigd door Arrigi op 24 juli 2024 03:21]

[Gustaaf437]

Op pure kracht was de IBM PowerPC 970 (G5) misschien wel krachtiger dan de Intels van die tijd (de reden misschien ook wel dat er voor een PowerPC werd gekozen als basis voor de Xbox 360 en de PS3). Het was echt een beest, maar qua performance-per-watt was het een ramp. Daardoor kon Apple deze chip ook nooit naar laptops brengen en dat is de reden geweest dat Apple wel een switch moest maken. De performance van de PowerBooks in die tijd was wel behoorlijk achterhaald toen de grote overstap op portables net stond te beginnen. Niet alleen IBM maakte er een zooitje van, maar ook Motorola kon toen het verbruik van de PowerPC 74xx (G4) niet onder controle krijgen, waardoor de PowerBooks bij hun laatste refresh geen processorupgrade kregen, terwijl zo'n beetje alle andere componenten dat wel kregen.

[Arrigi]

Anandtech heeft er een artikel over geschreven indertijd. Core tegen core kon de G5 blijkbaar hier en daar nog wel een puntje winnen inderdaad, maar de Core duo kwam met een tweede core. Daarbovenop was de Core duo zelfs met z'n tweede core een pak zuiniger. Dus inderdaad, per Watt was het een stuk interessanter. Trek dat echter door, als je de Core-architectuur dan in een Mac Pro zet en evenveel als de PPC laat gebruiken.. Tja, voor Apple was het wel duidelijk.

[afterburn]

Misschien dat het PowerPC platform al wat lange tanden begon te krijgen in vergelijking met x86, en dus Rosetta op Intel een best wel positief beeld liet zien omdat het verschil tussen native and emu niet zo groot was daardoor?

Bij ARM is dat meer andersom; het platorm is al minder krachtig als x86 en dan wordt het nog eens vertraagt door emulatie terwijl iedereen weet hoe het hoort te draaien omdat iedereen een PC heeft.

[dmantione]

Dat zou ik niet durven zeggen, de laatste ARM-processoren laten indrukwekkende cijfers zien in de rekenkracht in verhouding tot de kloksnelheid. Een scenario waarbij ARM x86 voorbij streeft is niet onrealistisch.

[_Thanatos_]

Maar dat scenario is er nog lang niet, lijkt me. Ik ben wel benieuwd hoe ver ARM is tegenover x64. Heb je een linkje met vergelijkende benchmarks toevallig?

[dmantione]

Je zou bijvoorbeeld hier kunnen kijken:

https://openbenchmarking.org/result/2001204-HU-5045459751

... je moet het evenwel wel in de juiste context zien: Je ziet dat in de benchmark de x86-laptops van de ARM-laptop in absolute zin winnen met een factor 2 á 3. We vergelijken evenwel een spotgoedkope Pinebook met een volwaardige x86-laptop. In het bijzonder vergelijken we een ARM-processor van 1,51Ghz met x86-processor van 2,9 GHz.

... en als je dat in ogenschouw neemt, dan zijn de prestaties van de ARM per MHz of per watt of per euro meer dan prima.

[kluyze]

Dan moet je er ook wel bij vermelden dat de intel i5-2410M uit 2011 komt waar de Rocketchip ARM cpu pas in 2016 aangekondigd is. En dat de intel een dual core met HT is, waar de ARM cpu een 6-core cpu is.

[hiostu]

Maar rekenkracht tov kloksnelheid is helemaal geen interessante verhouding. Het is veel interessanter om te kijken naar rekenkracht per watt of rekenkracht per euro. Kloksnelheid is een triviaal iets, want niet interessant is voor een eindgebruiker. Stel je hebt een chip met hetzelfde verbruik, de zelfde kosten en de zelfde rekenkracht, dan interesseert niemand het wat of of je nou een chip hebt die op 1GHz loopt of een chip die op 3GHz.

[batjes]

Pure snelheid is niet alles. Verre van

X86 heeft heel veel meer instructies dan ARM. Wat je op X86 in 1 cpucycle kan uitvoeren, kan een dozijn cpucycles kosten op ARM.

[dmantione]

Ben je niet in verwarring met een klassieke RISC zoals de MIPS? Want de ARM is dat nu net niet.

Het klassieke voorbeeld is het algoritme om de grootste gemene deler te bepalen, in ARM-machinetaal kun je dat in maar 4 instructies implementeren:

gcd:
CMP r0, r1
SUBGT r0, r0, r1
SUBLE r1, r1, r0
BNE gcd

Een belangrijke functie waar de x86 zijn rekenkracht per instructie vandaan haalt is de barrel shifter in de operand:

LEA eax,[eax+4*eax]

... kun je gebruiken om eax met 5 te vermenigvuldigen. Uitgerekend de ARM heeft een veel flexibelere barrel shifter dan x86:

ADD r0, r0, r0, LSL #4

... vermenigvuldigt r0 met 17... iets wat de x86 niet kan. Naast shiften naar links met een willekeurig aantal posities kan de ARM ook naar rechts schuiven en ook roteren.

In de regel verzet een ARM per instructie daarom meer werk dan een x86.

[afterburn]

Klopt, en ik zal ik zeker niet durven te zeggen dat in de toekomst ARM mogelijk beter gaat presteren als x86. Maar nu nog niet.

Wij als tweakers kunnen heel goed vergelijkingen maken en daarbij rekening houden met verschil in kloksnelheden etc om de vergelijking eerlijk te houden. Maar laten wel wezen, 'de gebruiker' kijkt niet naar relatieve performance, die kijkt naar absolute performance: ik doe taak X en die doet er Y lang over.op processor A en doet er Z lang over op processor B. B is langzamer, dus die zuigt. Dat is ongeveer hoe de gemiddelde gebruiker denkt.

[MSalters]

Dat kan inderdaad kloppen. Maar Rosetta was een succes omdat de x86 de PPC niet alleen voorbijgestreefd was, maar zelfs ver achterliet. Bovendien, x86 had economy of scale die PPC niet had. Dat voordeel heeft ARM evenmin; x86 wordt nog steeds in onvoorstelbare hoeveelheden geproduceerd. Intel kan de vraag letterlijk niet bijhouden. Dat is misschien wel belangrijker dan het hele performance verhaal: Microsoft wil niet afhankelijk zijn van het duopolie Intel/AMD.

[mae-t.net]

Je kunt met lange tanden eten, maar dat bedoel je zeker niet dus misschien lopen er wat uitdrukkingen doorelkaar. Ik begrijp dat je bedoelt dat PowerPC wat verouderd was of achter begon te lopen?

Opzich wordt een RISC-platform relatief weinig vertraagd door emulatie van CISC-instructies. Verder wordt er nog steeds hard aan doorgebouwd, dus dat zou zomaar nog wel mee kunnen vallen. Concurrentie met de celeron- en pentiumklasse devices zal zonder meer lukken en misschien de betere ook wel.

[psychicist]

Dat verhaal van dat PowerPC achter begon te lopen, geloof ik ook niet echt. Ik heb hier een dualcore Powermac G5 en een desktop met een AMD Athlon64 X2 en tijdens normaal gebruik voelen ze even snel aan. Verder denk ik dat het bij PowerPC lang aan softwareoptimalisaties heeft ontbroken.

Bovendien had PA Semi indertijd een uitstekende en erg zuinige PowerPC chip, waarna Apple het bedrijf heeft gekocht en de werknemers in plaats van aan PowerPC aan ARM chips zijn gaan werken. De situatie qua PowerPC is nu pas aan het verbeteren door de relatief grote aantallen ontwikkelaars met POWER9 desktops en workstations.

[Reactie gewijzigd door psychicist op 24 juli 2024 03:21]

[field33P]

Maar blijkbaar stonden de roadmaps van Freescale, PA Semi en IBM Apple niet aan, anders zouden ze echt niet de moeite gedaan hebben om over te stappen naar Intel. De reden waarom ze dat deden was simpelweg te wijten aan het feit dat geen van de drie in staat bleken om een PowerPC 970 (aka G5) voor laptops te bakken. Dat ligt overigens niet aan de instructieset (immers is de x86-instructieset uit 1978 vrij schaalbaar gebleken voor Intel), maar eerder aan de hoeveelheid R&D die de bedrijven kunnen betalen.

[justice strike]

Ten eerste Dat was risc to cisc emulation
Waarbij 1 instrucie in risc waarschijnlijk 1 op 1 vertaald naar een instructie in cisc. Andersom zul je een cisc instructie moeten vertalen naar 1 of meerdere (vaak meerdere) instructies op een risc processor. De hoeveelheid risc instructies die je nodig hebt per CISC module bepaald dan hoeveel vertraging je zult hebben.

Ten tweede, PowerPC was al zoveel langzamer dan Intel dat de snelheidswinst mede hielp om alles vlot te laten aanvoelen. De hele reden van de overstap naar Intel was nu juist omdat intel zoveel beter performde dan PowerPC. De ARM processoren die microsoft nu gebruiken zijn niet bepaald de desktop monsters die zich lenen voor vlotte emulatie (integendeel het zijn veelal mobile chips)

[Reactie gewijzigd door justice strike op 24 juli 2024 03:21]

[TechSupreme]

Rosetta was ook geen emulator, maar een realtime binary translator met een hoop beperkingen. Het kon G3 en G4 instructies vertalen naar Intel x86. G3 en G4 waren relatief simpel en daardoor ook eenvoudig om te vertalen, de complexere G5 ISA bleef buiten schot.

Performance was zeker niet iets waar Rosetta op uitblinkt. Volgens Apple was Rosetta goed voor applicaties die hoge gebruik interactie hebben, maar lage processing behoefte. Bijvoorbeeld Word. Photoshop of AutoCAD werd afgeraden. Is ook logisch aangezien Rosetta op de achtergrond continu aan het vertalen is.

De moderne ISA's zijn te complex om er zomaar een vertaler op los te laten.

[StefanJanssen]

Gaat hier zoveel performance bij verloren? Ik kan mij testen herinneren van software die net zo vloeiend draaide op een i5 als op een ARM chip.

[_Thanatos_]

Om dit te kunnen zeggen, is het wel belangrijk te weten dat in zo'n test de CPU de bottleneck is. Dus een generieke "software" (jij specificeert niet welke) zou best vergelijkbaar kunnen presteren als bijv I/O of GPU de bottleneck daarvan is.

[Simon Weel]

Volgens mij moet de vraag zijn: Waarom wil je een notebook met ARM processor als je Windows applicaties wilt draaien?

[dmantione]

Vanuit de fabrikant gezien is x86 een duur en energieslurpend platform. Er zijn krachtige ARM-processoren beschikbaar die goedkoper en zuiniger zijn. Als je de nadelen van ARM-processoren weet te pareren, zit daar een hele grote markt.

[_Thanatos_]

Is het scherm en de GPU niet een veel grotere energieslurper dan een zuinige Intel/AMD processor?

[dmantione]

Een scherm zit op iets in de orde van 20W, meer dan een idle cpu, minder dan een cpu op volle kracht. Dus dat kan voor wat het scherm betreft met ja beantwoord worden. Wat betreft de GPU: ARM-socs hebben een GPU aan boord, die zit dus inbegrepen in het financiële budget alsook het energiebudget en zijn juist een argument voor het ARM-platform.

[_Thanatos_]

Als je het over ARM hebt, moet je wel de vergelijking maken met ULV CPU's, en die zijn doorgaans zo'n 15W max. Onder de 10W zelfs als je het met een Atom wil doen.

[psychicist]

De Snapdragon 8cx doet het met 7,5 W en dat zou een eerlijkere vergelijking zijn. Het enige probleem is dat de laptops zo duur in de markt gezet worden met zo'n onvolledige softwareondersteuning, dat er niet meer dan een paar honderdduizend van verkocht zijn.

En je kunt er geen Linux op draaien, want anders waren er veel meer van verkocht voornamelijk aan softwareontwikkelaars. Zelf wacht ik op de komst van SoC's van andere bedrijven die het gebruik met Linux actief ondersteunen of in ieder geval niet tegenhouden.

[_Thanatos_]

Op ARM kun je toch prima Linux draaien? Afaik is er zelfs een speciale ARM-build van Ubuntu, zodat je niet vanalles zelf hoeft te hercompileren. Gewoon installeren en klaar.

[psychicist]

Je kunt inderdaad prima Linux draaien op ARM en dat doe ik ook al 3 jaar (maar voornamelijk Debian in plaats van Ubuntu vanwege een probleem met geluid). Sterker nog, ik gebruik mijn x86 laptop alleen maar voor het zwaardere werk. Maar er is weinig tot geen ondersteuning vanuit Qualcomm zelf om Linux te draaien op Windows on Snapdragon 835/850 laptops en al helemaal niet voor de nieuwste met Snapdragon 8cx, dus alles moet gereverse engineered worden en dat proces verloopt vooralsnog vrij langzaam.

[MSalters]

Je hebt inderdaad een goede kans dat WSL op Arm de beste Linux voor ARM wordt, ironisch genoeg. Dat hadden we in 2015 nooit gezegd, dat Microsoft het beste Linux platform kan gaan bouwen.

[Blokker_1999]

En dat is dus niet helemaal correct. ARM processoren zijn echt niet veel zuiniger als je gaat kijken naar prestaties vs opgenomen vermogen. Intel en AMd hebben de afgelopen jaren enorm hard gewerkt aan het zuinig maken van hun CPUs wanneer ze (bijna) idle draaien.

En of ze goedkoper zijn is nog maar de vraag. Wij zien alleen maar de consumer prijzen van CPUs maar hebben geen enkel zicht op wat bijvoorbeeld een HP of een Apple betalen voor hun CPUs.

De belangrijkste beweegreden voor MS was om Intel onder druk te zetten, iets waar AMD vandaag al een stuk beter in slaagt.

[dmantione]

Kijk naar de chip die op een Raspberry Pi 4 zit: CPU en GPU in één, gebruikt een paar watt. Volledig passief te koelen en zelfs zonder enig koelblok is het enig effect dat 'ie wat trager wordt. Zou je als fabrikant niet een leuke goedkope laptop met die chip kunnen maken? Kost geen drol, draait met groot gemak een werkdag lang op een relatief kleine batterij. Je kunt, zeker met de versie 4, een realistische Linuxdesktop op een Raspberry Pi draaien, maar nog geen Windows-desktop.

Ik denk dat daar de aantrekkingskracht van ARM zit.

[tweazer]

Yep, en die rp4 heeft dual 4k 60 fps output. Voor een paar tientjes een volledige (beginners/develop) computer ..

[MSalters]

In alle eerlijkheid is die 60fps alleen maar 60fps als de frames bijna identiek zijn. De GPU is bepaald geen RTX2080; 3D renderen in 4K gaat eerder richting de 0.6 fps.

[misterTweakers]

Over een paar jaar kan je die vraag misschien omdraaien

[Simon Weel]

Over een paar jaar kan je die vraag misschien omdraaien

Ik vrees van niet... De geschiedenis is een aardige vooruitblik. Eind jaren '80 was RISC de toekomst. Begin jaren '90 was Intels Itanium en IBM's PowerPC de toekomst, net als Sun's Sparc en nog wat exoten. Alles beter dan die kromme x86-architectuur. Volgens mij was Motorola een van de weinigen die de x86 bui zag hangen en hun 68-platform zelf aan de wilgen hing, voordat de markt dat deed....

[field33P]

PowerPC was een gezamenlijk project van IBM en Motorola.

[tweazer]

PowerPC was een gezamenlijk project van IBM en Motorola.

en Apple en DEC en Micro$oft en ik meen ook nog een paar autofabrikanten, het powerpc HRP/Prep platform.

Ooit nog eens met AIX en windows NT op een motorola powerstack mogen spelen, cebit 1992 if memory serves me right. Een dec alpha 160 deed het trouwens supersnel als file server met windows NT als je de gui stopte..

[Reactie gewijzigd door tweazer op 24 juli 2024 03:21]

[ReneX]

Volgens mij hadden DEC en MS hier niks mee te maken. Officiële ondersteuning van Windows NT voor de PPC kwam in 1995. En al had men vast al test versies beschikbaar, ik denk dat '92 nog wat te vroeg was aangezien toen net pas het eerste silicium beschikbaar was.

[tweazer]

Het zou best kunnen dat het een pre-release versie was. Zo heb ik ook ooit sunos/solaris 2.5 voor de PPC voorbij zien komen. Dec gokte zowel op de 21264 en ppc 601. Ik vermoed dat het een stukje zekerheid en marketingstrategie is, pre-release versie die (nog niet alles kunnen maar wel) de markt kunnen polsen. Hetzelfde zie ik nu ook bij vmware, esx 7 op ARM, meerdere jaren gedemo'd, maar nog steeds geen beta te verkrijgen, bloatware, marketing of politiek gevoelige materie ? De verhalen vermelden vmware op rpi3, rpi4, 16 en 80 core arm cpu's, maar helaas nog steeds niets publiekelijk te zien ...

[ReneX]

Apple, IBM en Motorola zelfs (AIM alliance).

[SuperDre]

omdat het tegenwoordig dus kan?

[Simon Weel]

Uh, ik snap 'm niet?

[yade]

Is energie steken in een recompiler niet veel slimmer dan te investeren in een emulator?

[_Thanatos_]

Hoe lang heeft het niet geduurd voordat software-makers es een keer x64 versies van hun software gingen uitgeven? En nóg zijn er 32-bits applicaties in normaal dagelijks gebruik. En dat terwijl x64 de opvolger van x86 is. ARM is geen opvolger, dus denk je niet dat het zeker nóg een 20 jaar gaat duren voordat dezelfde fractie software ook voor ARM uitgegeven wordt?

[zanza006]

32bit tov 64bit leverd opzich geen extra prestatie winst op. Enkel dat het meer RAM kan gebruiken. Als consument zijn vaak 32bit programma's meer dan genoeg.

[mae-t.net]

Je schrijft dat overstappen van 64 bit naar 32 bit geen prestatiewinst oplevert: "32 bit (ten opzichte van 64 bit) levert geen prestatiewinst op". Net als in een wiskundige formule even de haakjes gebruiken om te zien wat er staat. Dat klopt natuurlijk, maar andersom is dat niet persé waar. Dat heeft niet alleen met RAM te maken, maar ook met bewerkingen op grotere getallen. bijvoorbeeld.

[Reactie gewijzigd door mae-t.net op 24 juli 2024 03:21]

[_Thanatos_]

Met zo'n houding hadden we nu nog 16-bits applicaties. Sterker nog, met precies jouw argument heeft het zo lang geduurd. En daardoor heeft het onnodig veel geld en moeite en tijd gekost om 16-bits executables bruikbaar te houden zolang als dat het geval was.

Het houdt ooit op met 32-bits software, en hoe geavanceerder 64-bits wordt, hoe moeilijker het wordt om 32-bits te simuleren/emuleren. Er is nu al een extra laag (WoW) voor nodig. Me dunkt dat Mirosoft niet van plan is die eeuwig in leven te houden.

[field33P]

De WoW-laag is een serie 32-bit libraries die native door de processor gedraaid worden, absoluut geen emulator.

[_Thanatos_]

Nee, simulator dus. Maar wel overhead.
Ik dacht dat er wel *wat* wordt ge-emuleerd, maar idd niet de hele CPU.

[MSalters]

In theorie, ja. Alleen is x86-64 een significant beter ontwerp dan x86-32. Het heeft veel meer registers, bijvoorbeeld. De onhandige x87 FPU is vervangen door vector SSE4. Optionele x86 features als CMOV zijn standaard in x86-64.

[SunnieNL]

Dan moet jij wel de vendor van je applicaties zover krijgen om alles te recompilen.

Voordeel van een emulator is dat je gewoon al je software kan blijven draaien.
Microsoft zal daarnaast wel de calls emuleren, opvangen en vertalen naar ARM waardoor de snelheid ook OK blijft. Beetje wat ze ook doen in de emulator van x360 op een xbox one.

[robbinwehl]

Ik draai nu een maandje Windows 10 op mn Surface 2 (niet officieel supported maar werkt goed)
En ik mis toch heel veel apps hoor..
Gebruik hem voornamelijk voor onderweg, of om documenten te typen bijv.

Maar een simpele conference call gaat niet omdat b.v skype of teams niet op arm draaien.

Ik ben dus wel benieuwd!

[jqv]

Het draait wel op ARM, niet op Windows for ARM.
Maar het zou moeten werken in de emulatie. Maar niet native

[Reactie gewijzigd door jqv op 24 juli 2024 03:21]

[robbinwehl]

Ja dat snap ik!

[Youtoofan]

Ik draai nu een maandje Windows 10 op mn Surface 2 (niet officieel supported maar werkt goed)

Heb je een goede tutorial hiervoor?
Ik heb nog een Surface (1) liggen namelijk.

[robbinwehl]

Ja die heb ik

[Cergorach]

Dit was toch allang bekend?

@The Zep Man Maar die informatie dat dit ging komen stamt toch al van vorig jaar. x86 emulatie werkte al, maar er werd toen al gezegd dat er gewerkt werd aan 64-bit emulatie.

[Reactie gewijzigd door Cergorach op 24 juli 2024 03:21]

[The Zep Man]

Dit was toch allang bekend?

Windows-on-Windows op ARM heeft nu enkel ondersteuning voor x86 (32 bit). Dat x86-64/amd64/x64 (64 bit) ondersteuning wordt toegevoegd is nieuw.

[MrAndy9797]

Dit was toch allang bekend?

@The Zep Man Maar die informatie dat dit ging komen stamt toch al van vorig jaar. x86 emulatie werkte al, maar er werd toen al gezegd dat er gewerkt werd aan 64-bit emulatie.

Het was niet officieel bekend, toen ging het nog om geruchten van diverse bronnen. Met het vinden van 'bewijzen' voor deze geruchten is dit dus eerder een 'bevestiging' dan een 'gerucht'. Dat is het nieuwe eraan vermoed ik.

Verder, als iemand op je reageert, kan je het knopje 'Reageer' gebruiken? Dat leest namelijk veel aangenamer dan een oorspronkelijke comment die aangepast is waardoor je weer naar boven moeten scrollen om discussie te kunnen lezen. Nu beperk je ook nog eens de mogelijkheid om een discussie te voeren over je onderwerp, tenzij we iedere keer onze comments gaan aanpassen?

[Titan_Fox]

Zou mooi zijn als dit een open-source implementatie wordt. Dan zou je eenvoudige X64 applicaties op een Raspberry Pi (ARM(64)-HF) kunnen draaien. De nieuwe RPi 4's hebben 2 micro-HDMI uitgangen waardoor ze handig zijn voor bijvoorbeeld monitoring.

[Reactie gewijzigd door Titan_Fox op 22 juli 2024 21:23]

[Toontje_78]

Compileer dan alvast voor arm.. Dan heb je geen emulatie nodig.

Dit is om compatibiliteit met bestaande windows programmatuur te waarborgen.

[Reactie gewijzigd door Toontje_78 op 24 juli 2024 03:21]

[Titan_Fox]

Het is meer voor bestaande dedicated Windows applicaties. Momenteel werkt het monitoren daarvan met een work-around (RDP sessie op de RPi). Werkt op zich ook prima, maar niet optimaal ;-)

[Toontje_78]

Dat vat ik, maar een rPi lijkt me daar wat licht voor met 4* cortex 53 72 @1,5 MHz.

Bij nader inzien moet er nogal legacy x64 rondgaan, AMD64 gaat ook al weer heel wat jaren mee. En 32 of 64 zegt natuurlijk ook weinig over processorkracht vereist.

[Titan_Fox]

Het zijn 1,5 GHz, maar een kniesoor die daar op let :-D

Ik hoef ook geen zware Windows applicaties te draaien en ze hoeven voor de monitoring ook maar 1x op te starten. Zo'n Pi krijgt eens in de zoveel tijd een keer een reboot 's nachts. Dat 'ie dan een paar minuten nodig heeft om de betreffende applicatie te starten is dan ook niet zo spannend.

[lepel]

Je hebt lang niet altijd de mogelijkheid om zelf te compileren, genoeg applicaties die alleen binaries aanbieden.

[MSalters]

Open source wordt?

De GitHub repository is gelinkt, je kunt gewoon zien dat het MIT-licensed code is. Moet je waarschijnlijk wel Windows 10 op je Pi4 draaien, maar ook dat kan.

[obimk1]

Dus "PC compatibel" bestaat niet meer?

[Terminus]

Dit is dan ook interessant voor de mensen die een Surface Pro X aangeschaft hebben, niet wetende dat deze op ARM gebaseerd is. Microsoft slaat wat dat betreft ook wel een beetje de plank mis qua gebruikersvriendelijkheid. Mensen snappen tegenwoordig wel het verschil tussen diesel en benzine (in de meeste gevallen), maar ARM vs x64 is natuurlijk heel andere koek. Voor veel mensen is 'Windows' één ding (een willekeurige gebruiker heeft geen flauw idee wat x64 is, terwijl het al jaren op zijn PC/notebook draait).

Hopelijk komt Microsoft ooit op een punt dat ze mobiele devices gebaseerd op ARM gewoon kunnen slijten zonder dat de gebruiker rekening hoeft te houden met zaken qua architectuur.

[Toontje_78]

Diesel en benzine enkel omdat het dieselvulpistool een grotere diameter heeft, en de most likely suspects van verkeert tanken benzine rijden.

[Rudie_V]

Intel en amd cpu's zijn intern eigenlijk ook al risc cpu's, de cisc x86 en x86-64 instructies worden vertaald en opgedeeld naar kleinere uops en uitgevoerd op de interne risc cores. Dit trucje zal nu dus in software gedaan moeten worden om x86 en x86-64 software op arm te laten draaien.