Du kan kjøre vanlige Windows-programmer på nye Windows 10 for ARM

[Harald Brombach (digi.no)]

Lover pc-er som alltid er tilkoblet og som sjelden må lades.

Du kan kjøre vanlige Windows-programmer på nye Windows 10 for ARM

[tommyb]

Hadde dette vært tilgjengelig da de tilbød startsidebrettene Surface RT, hadde jeg nok ikke avskrevet den plattformen like raskt som jeg gjorde. Men det gjenstår jo å se om dette blir en one hit wonder som alle de tidligere mobilsatsningene deres, eller om dette er noe som kommer for å satses videre på. Og ja, jeg kunne godt tenkt meg en 5" PC med dette og telefoni på.

 

Dersom Microsoft gir ARM-støtten lik oppmerksomhet som den tradisjonelle, kunne vi kanskje fått inn den nødvendige konkurransen som Intel trenger på PC-plattformen.

 

At dette er noe Microsoft kommer til å fortsette å satse på, vil jeg kun overbevises om i retrospektiv en gang langt inn i framtiden.

[vidor]

Høres veldig castle in the sky ut dette prosjektet til MS. Tror det når jeg ser det, for å si det sånn.

 

Det blir en rimelig stor overhead på emuleringen av å kjøre X86 til ARM så man trenger mye ytelse på ARM for å få en brøkdel av av ytelsen på X86, og det er ikke så få linjer native X86 kode i de fleste program at det på noen måte utgjør at optimaliserte systemkall er majoriteten av en .exe på flere megabyte. En kan nok optimalisere rimelig bra som utvikler hvis man kompilerer native, men det MS satser på her er jo å lage er jo å lage en transparent emulering av native X86, så da konkurrerer dem jo mot native ARM og ekstremt gode JIT-løsninger som allerede har et stort forsprang.

 

Dette virker mest som usubstansiert PR designet for å overselge Windows 10 ARM.

Det kan sikkert bli et verdifullt produkt for noen som ikke har så store ytelseskrav, men MS burde holde seg for god til å prøve på innsalg sånn som dette.

Endret 6. desember 2017 av vidor

[tommyb]

Dette virker mest som usubstansiert PR designet for å overselge Windows 10 ARM.

Det kan sikkert bli et verdifullt produkt for noen som ikke har så store ytelseskrav, men MS burde holde seg for god til å prøve på innsalg sånn som dette.

 

Det betyr forskjellen mellom å ha en fullstendig uinteressant plattform som kun har noe med Windows-programvare å gjøre i navnet og ikke engang Microsoft selv gadd lage programvare til, og å kjøre programvare fra en av verdens største programvareplattformer, Windows. 

 

Det ene har interesse på tross av åpenbare bakdeler, siden det også gir åpenbare fordeler, det andre har ikke engang interesse som en kuriositet. 

[HKS]

Det blir en rimelig stor overhead på emuleringen av å kjøre X86 til ARM så man trenger mye ytelse på ARM for å få en brøkdel av av ytelsen på X86

Har du noen tall på dette, eller er det bare en påstand du slenger ut?

[vidor]

Har du noen tall på dette, eller er det bare en påstand du slenger ut?

Med tanke på hvor lav ytelse det er på ARM i utgangspunktet så er det ikke en direkte god ide å emulere X86. Emulering spiser jo normalt flere sykler på emulert plattform når den skal oversette den opprinnelige instruksjonen i tillegg til overhead som emulatoren har i form av minne og CPU. Uansett hvor mye man optimaliserer så er grunnlaget temmelig dårlig i forhold til det folk er vant til i dag av X86 og X64.

 

Du kan jo teste litt selv om du ikke tror meg. Last ned Bochs på en ARM-prosessor basert dings og "kos deg".

Endret 6. desember 2017 av vidor

[tommyb]

Det er alt for tidlig for meg å spekulere i ytelsen, da vi ikke vet i hvilken grad man trenger emulere. Ref artikkelens/Microsofts påstand om at "ytelsen til de fleste Windows-programmer skal i liten grad være hemmet av dette, siden de fleste Windows-programmer sender kall til operativsystemet [sic] programmeringsgrensesnitt direkte".

 

 

 

At ytelsen vil være redusert er selvsagt, og forsåvidt noe jeg som tidligere N900/Maemo-bruker har akseptanse for dersom det likevel gir meg merverdi framfor alternativene. 

Endret 6. desember 2017 av tommyb

[vidor]

De kan tweake en del ting og ha en superoptimalisert realtime-kompilator, men det å emulere X86 er ikke det samme som ferdig oversatt bytecode eller native ARM kode som brukes for tidskritiske og kjappe apper. Det er dette folk er vant med på ARM. Et stort steg ytelsesmessig over det igjen ligger X86. MS skal altså da emulere en plattform som folk er vant med skal ha høy ytelse på en plattform som i utgangspunktet er mye tregere med en høy grad av realtime emulering av et komplekst instruksjonssett ? I ytelse slår jo en antikvarisk Celeron 733 MHz en 4 kjernes ARM på 1,4 GHz i praktisk bruk for meg. Slå du sammen kjernene til en logisk prosessor og bruker tråder optimalt har du altså 5,6 GHz til rådighet. Hvis du ser på TDP mellom prosessorene ser du fort at X86 er noe mer krevende som følge av bl.a kompleksiteten.

 

Skal de få dette til må de som minimum engangskonvertere/generere appene slik Android gjør i dag hver gang en ny utgave av OS blir innstallert. Realtime oversetting blir tregere enn det.

 

Som sagt, jeg tror det når jeg ser det. Rett og slett fordi dem har et teknisk utganspunkt som krever at man skviser ut hver minste dråpe for å få noe som er halveis brukbart. Her må nok til med mange flere kjerner, ellers velger nok mange raskere alternativer.

[N o r e n g]

Hvis Microsoft har fått til dette i nærheten av like bra som deres Xbox 360-emulator fungerer på Xbox One er dette rimelig ille for Intel og AMD.
 
Svært mange i dag som stort sett bare bruker nettleser og office fra PC-en sin.
 

I ytelse slår jo en antikvarisk Celeron 733 MHz en 4 kjernes ARM på 1,4 GHz i praktisk bruk for meg.

Hva er det du gjør med en Celeron 733 MHz da?
Min 4.5GHz i7-5930k er omtrent 15 ganger raskere enn min HTC U11 på denne koden:

 

import numpy as np
from time import time
t = time()
list = np.linspace(1,5000000,1000000)
mean = np.sum(list)/np.size(list)
print(1e3*(time()-t))

 

PC-en gjør dette på omtrent 5 ms

Mobilen (Pydroid3) gjør det samme på omtrent 77 ms

EDIT: Min antikvariske HTC One M8 utfører samme koden på 114 ms

 

Jeg har store vanskeligheter for å tro at en Celeron 733 MHz er raskere enn min HTC U11, og ARM-prosessorer har et bra forbedringstempo i forhold til x86 for tiden.

Endret 6. desember 2017 av N o r e n g

[HKS]

Du kan jo teste litt selv om du ikke tror meg. Last ned Bochs på en ARM-prosessor basert dings og "kos deg".

Hva med å "kose deg litt" med en kryssplatform benchmark?

 

https://www.macrumors.com/2017/09/13/a11-bionic-chip-geekbench-scores/

 

Apple A11 er en ARM-prosessor vet du...

[vidor]

Snapdragon 835 er octacore på 2,45 GHz som tilsvarer 19.6 GHz optimistisk ytelse som "single".

Har ikke vurdert dette opp mot Celeron 733 MHz, men det er rimelig heftig for ARM å være, så det burde komme seg. Rent hastighetsmessig er ARM på over 26x, noe som burde ha potensiale selv med begrenset instruksjonssett. X86 er en vesentlig mer komplisert arkitektur.

 

A11 er en godt designet prosessor med 6 kjerner som ser ut til å overgå Snapdragon 835 med grei margin uten å øke frekvensen siden Apple spesialdesigner brikkene sine.

 

Hadde vært interessant å se hvor mye dere hadde giddet å bruke Windows 10 på ytelsen til disse brikkene sånn MS tenker å implementere støtten. Sånn jeg ser det hadde nok vært greit for enkle ting, men neppe større komplekse programmer som virkelig bruker effektive X86 instruksjoner og ikke bare basic ting som lett kompileres på kryssplattform.

[N o r e n g]

Snapdragon 835 er octacore på 2,45 GHz som tilsvarer 19.6 GHz optimistisk ytelse som "single".

 

Du vet det er mer ved prosessorytelse enn instruksjonssett og klokkefrekvens?

Alle dagens x86-prosessorer deler opp instruksjonene i mikro- og makro-operasjoner som så utføres RISC-lignende.

Apropos SD835, så er det bare 4 A73-kjerner som kjører på 2.45GHz, de resterende 4 A53-kjernene kjører på 1.9GHz.

[Gavekort]

Med tanke på hvor lav ytelse det er på ARM i utgangspunktet så er det ikke en direkte god ide å emulere X86. Emulering spiser jo normalt flere sykler på emulert plattform når den skal oversette den opprinnelige instruksjonen i tillegg til overhead som emulatoren har i form av minne og CPU. Uansett hvor mye man optimaliserer så er grunnlaget temmelig dårlig i forhold til det folk er vant til i dag av X86 og X64.

 

Du kan jo teste litt selv om du ikke tror meg. Last ned Bochs på en ARM-prosessor basert dings og "kos deg".

 

Det spørs hva du legger i betydningen av emulering. Det trenger ikke å være en treg interpreter.

[vidor]

Vi har nok litt ulikt syn på dette, så det gjenstår å teste i praksis når dette er mulig. Tror nok neppe det blir marketing-ytelse og forhåpentlig ikke så dårlig som det jeg antar. Hvor mange prosent av realistisk gjennomsnittlig ytelse  mener du man beholder på emulert plattform vs å kjøre native på original plattform ?

[Gavekort]

Mitt syn på emulering er at du enten kan oversette instruksjoner i forkant, eller du kan oversette instruksjoner underveis. Du kan oversette instruksjoner i software, eller du kan oversette instruksjoner med dedikert hardware. Nå vet ikke jeg hvilke patenter Intel stikker i hjulene til Qualcomm, men vil anse at ytelsen kan bli tilnærmet native ytelse til ARM om man bruker binary translation eller dedikert hardware, og at dette ikke helt er sammenlignbart med en treg software JIT emulator som Bochs.

Endret 7. desember 2017 av Gavekort

[tommyb]

 Her må nok til med mange flere kjerner, ellers velger nok mange raskere alternativer.

 

Det er ikke akkurat en revolusjonerende spådom. Om ytelsen var 1:1 sammenlignet med f.eks. x86 mobilprosessorer (som den i Zenfone 2) ville mange fortsatt velge raskere alternativer. Spørsmålet om man kan nå mange nok til at produktene har livets rett. Slik som Surface Pro har, mens Surface RT og Windows 10S ikke har. 

 

Det er allerede mange fullmåner siden man begynte å ønske konvergering mellom mobiltelefoner og PC, men hardwaren har ikke vært god nok til at man har kunne lage slike produkter. Vi begynner å komme dit, men disse vil absolutt være et kompromiss. Et kompromiss på ytelse og kanskje på strømforbruk? Men samtidig med egne unike egenskaper som gir klart definert merverdi. 

Endret 7. desember 2017 av tommyb

[fuzzy76]

Vi har nok litt ulikt syn på dette, så det gjenstår å teste i praksis når dette er mulig. Tror nok neppe det blir marketing-ytelse og forhåpentlig ikke så dårlig som det jeg antar. Hvor mange prosent av realistisk gjennomsnittlig ytelse  mener du man beholder på emulert plattform vs å kjøre native på original plattform ?

Poenget her er at det kun er applikasjonskoden som emuleres. Plattformen (Windows) er kompilert native. For de fleste applikasjoner er situasjonen den at operativsystemkall står for mesteparten av CPU-tiden.

 

Dette så man også når Apple gikk fra PPC til Intel. Ytelsen var helt kurant for eldre programmer selv om man emulerte prosessoren.

Endret 8. desember 2017 av fuzzy76

[vidor]

En ting er å emulere RISC med CISC, men det mer krevende å emulere CISC med RISK. Det MS sier er at de optimaliserer endel, men jeg tror de har mer å gå på, og også at de trenger det hvis de ønsker å være konkurransedyktig og ikke ende opp som Windows Phone. Den overheaden de har med å gjøre ting realtime mener jeg det kan kuttes vesentlig i med å heller gjøre den jobben en gang.

Endret 8. desember 2017 av vidor

[HKS]

En ting er å emulere RISC med CISC, men det mer krevende å emulere CISC med RISK.

Arkitekturen i en moderne x86 prosessor (P6 og nyere) har veldig mye mer til felles med en RISC-arkitektur enn en klassisk CISC-arkitektur...

 

En Intel Skylake for eksempel har fire enkle og en kompleks dekoder som dekoder x86-instuksjoner til "micro-op" som er RISC-lignende instruksjonsett. CPU'en vil også prøve å optimere disse "micro-op" videre, ved hjlp av teknikker som "maco-Op fusion", "micro-op fusion", etc.

Det er faktisk noen legacy CISC-instruksjoner som aldri lenger brukes i moderne kompilatorer, men som må støttes grunnet bakoverkompatibilitet som faktisk ikke Skylake sin komplekse dekoder støtter. Disse instruksjonene må "falle tilbake" til en mikrokode i prosessoren som gjør software-oversetting.

Ser du på Zen-arkitekturen til AMD har de i større grad valgt å droppe hardware-støtte for veldig gamle instruksjoner for å få CPU-designet enklere. Intel sin "front-end" på prosessoren er en av de mest kompliserte delene på Core-arkitekturen.

[tommyb]

Nå er det forskjell på konkurransedyktig som Android og konkurransedyktig som Surface Pro. Surface Pro har en plass, et marked, og trenger ikke vinne en betydelig markedsandel for å være et lønnsomt prosjekt, siden økosystemet ikke er avhengig av Surface Pros markedsandel, der de utgjør en ganske liten andel av solgte datamaskiner.

 

Windows Phone trengte en ganske betydelig andel for å være et reelt økosystem. En Microsoft-telefon med Android trenger ikke stor markedsandel. Eller en Microsoft-PC... Spesielt ikke om den er 5 tommer stor og kan brukes til å ringe med. Den trenger bare rettferdiggjøre merkostnadene for ARM-støtte.