Gå til innhold

ARM ser frem til Windows 8


Anbefalte innlegg

Det stemmer at desktop x86 har et stor og avansert decode system, men det er arkitekturvalg for høyere ytelse. Det viser seg at CISC er en fordel i energieffektive design. Du kan gjøre mer per instruksjon og trenger dermed ikke så høy klokke for å oppnå samme ytelse.
Det er ikke gitt at det tar én klokkesyklus å fullføre én instruksjon. Det er vel strengt tatt bare unntaksvis at slikt et tilfelle. Store og kompliserte CISC-instruksjoner er garantert fler-sykel-instruksjoner.

 

Det er riktig at mest mulig utført arbeid pr. klokkesyklus er oppskriften på en effektiv prosessor, men hvordan impliserer CISC dette?

Lenke til kommentar
Videoannonse
Annonse
Vis gjerne til konkret hva i x86-instruksjonssettet som er en betydelig ulempe her. Jeg hører stadig denne påstanden uten at jeg har klart å få en saklig begrunnelse, det kan være at den finnes, men jeg har til gode å se den. De svakhetene jeg vet om er knyttet til prosessorarkitektur og ikke instruksjonssett. Men for all del, ARM er flott til sitt bruk. Uansett så har trolig Intel et fortrinn innen produksjonsteknikk, og AMD kanskje innen integrert grafikk.

Jeg har lest litt om emnet både artikler og foruminnlegg med påstander. Jeg er ikke på solid faglig grunn, men har fått med meg noen av hovedpoengene i argumentasjonen mot x86:

 

- Alle x86-prosessorer har i dag en instruksjonsoversetter fra CISC (x86) til RISC. Denne krever en betydelig del av effektbudsjettet og øker latency på en del oppgaver. Dette gir Intel og AMD en ulempe på ytelse/effekt og litt på ytelse. Rene x86 CISC-prosessorer gikk man bort i fra den dagen originale Pentium ble lansert (1993?) og har ikke vært aktuell senere på grunn av at RISC er så effektivt at det til tross for oversetteren lønner seg å kjøre RISC fremfor CISC i kjernearkitekturen.

 

Det stemmer at desktop x86 har et stor og avansert decode system, men det er arkitekturvalg for høyere ytelse. Det viser seg at CISC er en fordel i energieffektive design. Du kan gjøre mer per instruksjon og trenger dermed ikke så høy klokke for å oppnå samme ytelse.

 

Den dagen det kommer en skikkelig x86 optimalisert for under 1W effekt (AMD?) tror jeg ARM vil få utfordringer på tablets ol. med Windows 8. Men for Android og iOS tror jeg arm vil beholde forsprange pga mye tilgjengelig sw.

 

Hvilken bit av "CISC emuleres I hardware over RISC i x86" var det du ikke leste?

Alt x86 trenger for å bli konkuransedyktig med ARM er å hive all bakoverkompitablitet ut av vinduet.

Og hvem vil være med på det?

Mener Alpha og Itanium var forsøk på dette, men de døde jo?

Var spørsmålet rettet mot meg?

 

Det jeg sier er at CISC er mer energieffektivt, at man ikke MÅ dekode til micro-ops. Dette er ny tenking, de siste årene har man sett at mer komplekse instruksjoner lønner seg. Å si at ARM er RISC begynner vel også å bli litt rart? Det tyter jo på med utvidelser der også...

 

Jeg tror ikke man trenger å droppe noe kompatibilitet. At man trenger mange transistorer for dekode er ikke direkte negativt på energieffektivitet, men det gjør kosten pr enhet (arealbruken) større.

Endret av martiol
Lenke til kommentar
Vis gjerne til konkret hva i x86-instruksjonssettet som er en betydelig ulempe her. Jeg hører stadig denne påstanden uten at jeg har klart å få en saklig begrunnelse, det kan være at den finnes, men jeg har til gode å se den. De svakhetene jeg vet om er knyttet til prosessorarkitektur og ikke instruksjonssett. Men for all del, ARM er flott til sitt bruk. Uansett så har trolig Intel et fortrinn innen produksjonsteknikk, og AMD kanskje innen integrert grafikk.

Jeg har lest litt om emnet både artikler og foruminnlegg med påstander. Jeg er ikke på solid faglig grunn, men har fått med meg noen av hovedpoengene i argumentasjonen mot x86:

 

- Alle x86-prosessorer har i dag en instruksjonsoversetter fra CISC (x86) til RISC. Denne krever en betydelig del av effektbudsjettet og øker latency på en del oppgaver. Dette gir Intel og AMD en ulempe på ytelse/effekt og litt på ytelse. Rene x86 CISC-prosessorer gikk man bort i fra den dagen originale Pentium ble lansert (1993?) og har ikke vært aktuell senere på grunn av at RISC er så effektivt at det til tross for oversetteren lønner seg å kjøre RISC fremfor CISC i kjernearkitekturen.

- Lappverk av instruksjonssett. 32 bit er en påbygning av 16 bit. 64 bit er en påbygning av 32 bit. MMX, SSEx, 3DNow osv. er også lapper. Mye av dette er lite brukt men man kan likevel ikke bare kutte ut kompatibiliteten med gamle og lite brukte systemer. Alt dette spiser av die space og effektbudsjettet. ARM er heller ikke siste skrik, men i hvert fall mye nyere og mer tilpasset dagens bruk enn x86.

- Et av argumentene bak overgangen til en RISC-aktig arkitektur var at dette skulle skalere videre, og det gjorde det veldig godt en stund. Men introduserer problemer som effektforbruk, og etter hvert egenfrekvenser til metall (hvis de skulle skalert langt forbi dagens frekvenser). Til generell bruk er det gjerne best med en balansegang mellom RISC og CISC, eventuelt noe helt nytt.

- AMD64 introduserte en grundig opprydning i instruksjonssettet, og det er særdeles lite areal som eventuelt går bort i gammel ubrukt funksjonalitet, relativt ubetydelig i forhold til f.eks. SSE.

Lenke til kommentar
Det jeg sier er at CISC er mer energieffektivt, at man ikke MÅ dekode til micro-ops. Dette er ny tenking, de siste årene har man sett at mer komplekse instruksjoner lønner seg. Å si at ARM er RISC begynner vel også å bli litt rart? Det tyter jo på med utvidelser der også...

 

Urelevant.

x86 er RISC som dekoder CISC, og det er problemet.

Det handler ikke om utvidelser, men om hvordan selve chipppen og hvordan den brukes.

Det er alltid mer effektivt å ha noe til å gjøre noe, i kontrast til at du har noe som gjør noe for å emulere noen andre for å så gjøre samme jobben.........

 

Jeg tror ikke man trenger å droppe noe kompatibilitet. At man trenger mange transistorer for dekode er ikke direkte negativt på energieffektivitet, men det gjør kosten pr enhet (arealbruken) større.

 

 

Jeg tror du bør ta en liten titt over hvor mye emulering på chippen det er snakk om.

Det er snakk om veldig mye.

Intel sine nye x86 CPUer er meget mye mer energi effektive en hva du får på en ARM chip, men den overlegne teknologien kan bare gi så så mye mer før den møter en vegg.

ARM sitt forsprang på å være strøm effektiv er nettop den biten om RISC som emulerer CISC........

Lenke til kommentar

Prosessorprodusenten ARM ser svært lyst på det fremtidige prosessorsalget.

 

 

Det å kalle ARM en prosessorprodusent medfører vel ikke riktighet? Jeg har forstått det slik at de kun selger rettighetene til sitt design, ikke prosessorene i seg selv.

Endret av Calm
Lenke til kommentar

En av fordelene med Arm er at instruksjonssettet er svært effektivt.

 

ADD PC,R5,R1,LSL #8

 

Dette er 1 enkelt intruksjon som kjører på 1 klokke syklus og den utfører:

PC = R5 + (R1*256)

 

Dette ville tatt mange x86 instruksjoner å gjøre det samme, og i tillegg kan Arm instruksjoner velge fritt blandt de 16 32bits registerene.

 

x86 derimot har en betydelig fordel av kraftigere innebygd matteprosessor samt SSE og krypterings intruksjoner. Det blir spennedes å se hvordan 64bits Arm tenker å konkurrere her.

Lenke til kommentar

Noen som vet om man kan kjøre x86 programmer på windows 8 kjørende på ARM?

Nei. Men .NET programmer kan nok i stor grad kjøre på både ARM og x86.

 

zargblatt: "En av fordelene med Arm er at instruksjonssettet er svært effektivt."

Det er vel diskutabelt. Det kommer an på hva du skal gjøre.

Eksempelvis har du stringstore og load instruksjoner i x86, samt at alle prosessorene har hardware divisjon.

Endret av GeirGrusom
  • Liker 1
Lenke til kommentar

Ang. Windiows 8, er det sant at den kun kommer <klipp...> i en versjon? (ikke ultimate, home professional, starter osv)

Det er ikke annonsert noe som helst om dette ennå.

Jeg tipper at det ikke blir veldig ulikt Windows 7 når de gjelder de versjonene som selges over disk eller lisensieres til bedrifter. Når det gjelder de versjonene som kommer forhåndsinstallert på PC'er eller tablets, så tror jeg HW-konfigurasjonen vil avgjøre hva som blir installert og hvordan SW-oppsettet blir. (Hvilke services som startes pr. default, osv.)

Lenke til kommentar

Flisespikkeri, Sony Ericcson lager heller ikke mobiler men blir kalt mobilprodusent.

 

Det er vel heller ikke riktig. Verken Sony eller Ericsson lager telefoner selv lenger, det gjøres av Sony Ericsson Mobile Communications AB. Hvis de ikke lager mobiletelefonene selv, hva bruker de fabrikkene i Frankrike og Kina til da?

 

ARM verken produserer eller selger prosessorer, så selv om du skulle ha rett, så er ikke sammenlikningen noe bedre, all den tid Sony Ericsson i det minste selger mobiltelefoner.

Endret av Calm
Lenke til kommentar

 

Urelevant.

x86 er RISC som dekoder CISC, og det er problemet.

 

...

 

ARM sitt forsprang på å være strøm effektiv er nettop den biten om RISC som emulerer CISC........

 

Dette er bare feil. Det er design du snakker om. x86 instruksjonssettet i seg selv "emulerer" ikke noe som helst. Det er også veldig unøyaktig å si at det "emuleres" (dekodes) til RISC. Fordelen med å dekode til micro-ops er at man kan totalt endre det "interne" språket til prosessoren uten at bruker merker det.

 

Men tilbake til tema: Å dekode x86 til micro-ops er valgfritt. Det er heller ikke alle nye x86-prosessorer som gjør det.

Lenke til kommentar

 

Urelevant.

x86 er RISC som dekoder CISC, og det er problemet.

 

...

 

ARM sitt forsprang på å være strøm effektiv er nettop den biten om RISC som emulerer CISC........

 

Dette er bare feil. Det er design du snakker om. x86 instruksjonssettet i seg selv "emulerer" ikke noe som helst. Det er også veldig unøyaktig å si at det "emuleres" (dekodes) til RISC. Fordelen med å dekode til micro-ops er at man kan totalt endre det "interne" språket til prosessoren uten at bruker merker det.

 

Men tilbake til tema: Å dekode x86 til micro-ops er valgfritt. Det er heller ikke alle nye x86-prosessorer som gjør det.

 

Kilder og logiske sluttninger takk!

Lenke til kommentar

Opprett en konto eller logg inn for å kommentere

Du må være et medlem for å kunne skrive en kommentar

Opprett konto

Det er enkelt å melde seg inn for å starte en ny konto!

Start en konto

Logg inn

Har du allerede en konto? Logg inn her.

Logg inn nå
  • Hvem er aktive   0 medlemmer

    • Ingen innloggede medlemmer aktive
×
×
  • Opprett ny...