Her er den første Intel-mobilen

[Kaptein...]

Mener å ha sett flere videoer av folk som har kjørt Android på PC-er. Skulle tro det ville være en smal sak mtp at det bare er en stor java blobb.

Endret 23. desember 2011 av Kaptein...

[Qweel]

er det bare jeg som legger merke til at android logoen er opp ned?

[Occi]

er det bare jeg som legger merke til at android logoen er opp ned?

Nei, men det la du vel ikke merke til

[Kaymeerah]

"Medfield-chippen skal være optimalisert for å kjøpe Android-apps..."Wow, en egen chip lagd for å kjøpe apps!

 

Det er noe helt annet å få en x86 til å kjøre kode som i utgangspunktet er laget for ARM. Det kan godt være de faktisk måtte gjøre noen optimaliseringer her og der hvis de kjører gjennom en interpreter.

 

Uansett så er x86 så tregt for små oppgaver at de måtte optimalisert uansett for å konkurrere med strøm/ytelse.

Endret 23. desember 2011 av Kaymeerah

[endrebjo]

Ja, dessverre. http://www.anandtech...hipsets-in-2012

Intel har planer om å forpeste mobil- og tablet-plattformen også.

 

På den andre siden mener jeg å huske at det ikke er en 100% kompatibel x86-arkitektur. Blant annet gjør mangelen på PCI-buss det umulig å kjøre dagens Windowser, og jeg mener det var flere ting som manglet også. Anandtech hadde en grei innføring i forgjengeren (Moorestown), som forøvrig ser ut til å ha floppet ganske greit. Jeg har i hvert fall ikke sett noen store lanseringen som bygger på Moorestown.

Nytt i Medfield er at de har klart å samle mer I/O i én SoC enn de klarte på Moorestown.

 

Har ikke så mye peiling på det, kan du fortelle hva som er galt/problemet med Intel sin nye løsning?

x86-arkitekturen i seg selv er gammel og ineffektiv, både størrelse- og effektmessig. Dette kommer både av CISC-filosofien og ikke minst variabel instruksjonslengde. Store mengder logikk blir brukt bare for å dekode instruksjoner hver eneste klokkeperiode, i tillegg bærer x86 på mye gammel bagasje fra alle instruksjonene som har blitt klattet på i etterkant. Hvor mye av dette gamle rælet de har klart/valgt å fjerne i Moorestown/Medfield vet jeg ikke, men variabel instruksjonslengde og utdaterte prinsipper er vanskelig å komme rundt.

På desktop/laptop og servermarkedet har x86 vært greit nok siden CMOS-teknologien hele tiden har tillatt pushing av ytelse, og kompilatorene har optimalisert seg rundt de verste problemene med x86. På mobil/tablet er det derimot helt andre krav til strømforbruk, og da blir det bare tull å skulle sløse bort masse tid og ressurser på å prøve å holde denne dinosauren i live. Når den nye plattformen (Moorestown/Medfield) i tillegg ikke er kompatibel med tidligere x86 (f.eks pga mangel på PCI-buss) er det tydelig at Intel pusher det for at konkurrende instruksjonssett ikke skal få ta overhånd på det nye markedet. Intel er tross alt verdensledende på CMOS-teknologi og kan dermed levere en dårligere arkitektur (x86) som yter og bruker tilsvarende som konkurrerende instruksjonssett (ARM, MIPS) ene og alene pga. CMOS-teknologi. På den måte holder de live i x86, selv om forbrukerene ville vært bedre tjent med å innføre den gode CMOS-teknologien på en mer effektiv arkitektur (ARM, MIPS).

Det samme gjelder forøvrig i en viss grad på desktop, og det er jo lov å håpe at utbredelsen av ARM og MIPS på små dingser kan smitte over på desktop etter hvert. Vi har desktop-OS som kjører greit på disse (GNU/Linux), men samtidig må all programvare rekompileres (og gjerne skrives litt om), noe som kan bli vanskelig med properitær programvare.

[Revox]

Hurra for google translate

[Snowleopard]

Når det gjelder byggekvalitet så er jeg meget fornøyd med min HTC Desire HD, den har fått en god del juling og funker som ny enda, ikke en ripe i skjermen, men noen hakk i "karosseriet" har den fått, noe jeg tror er aluminium. min bror hadde en sånn Xperia drit den fikk riper i skjermen bare man så på den, og gikk sund da han mista den i bakken... makan til drit skal man lete lenge etter, Sony Ericsson skal ikke jeg ha:pSimens skulle ikke ha sluttet å lage mobiler vettu, de lagde mobiler for arbeidsfolk, min CX75 var riktig nok i plast, men jeg lyger ikke når jeg sier at den var 0.5cm tykk i sidene...

 

Hadde intil noen dager siden en Desire HD, som jeg var veldig fornøyd med. Det eneste "problemet" var at den slukte strøm, slik at den måtte lades hver natt.

 

Fikke et greit tilbud på en HTC Sensation, med samme skjermstørrelse, så siden guttungen trengte ny mobil, så arvet han Desire HD'en.

 

I tillegg til at Sensation nå lades kun annenhver dag, så er den dessuten lettere og ikke fullt så bred (tynnere ramme), samt raskere.

 

Hadde nok sagt nei til tilbudet jeg fikk, hadde det ikke vært for at guttungen trengte tlf, så fornøyd var jeg. Dog angrer ikke et sekund på at jeg byttet.

 

:-)

[Occi]

Sjekk ut JuiceDefender og da særlig betalingstillegget UltimateJuice. Du får gjerne 50-100% mer batteritid, da denne skrur av mobilt nettverk når det ikke er i bruk og masse slike ting. Du kan selv stille det inn. Selv får jeg ca. 70% mer batteritid ved bruk av denne og trenger ikke lade mer enn annenhver, noen ganger hver tredje dag om jeg ikke bruker den noe særlig.

[Kaymeerah]

Hehe, min HTC Desire holder seg i 4-5 dager elns.

 

Kjører Cyanogenmod.

[efikkan]

x86-arkitekturen i seg selv er gammel og ineffektiv, både størrelse- og effektmessig. Dette kommer både av CISC-filosofien og ikke minst variabel instruksjonslengde. Store mengder logikk blir brukt bare for å dekode instruksjoner hver eneste klokkeperiode, i tillegg bærer x86 på mye gammel bagasje fra alle instruksjonene som har blitt klattet på i etterkant. Hvor mye av dette gamle rælet de har klart/valgt å fjerne i Moorestown/Medfield vet jeg ikke, men variabel instruksjonslengde og utdaterte prinsipper er vanskelig å komme rundt.

På desktop/laptop og servermarkedet har x86 vært greit nok siden CMOS-teknologien hele tiden har tillatt pushing av ytelse, og kompilatorene har optimalisert seg rundt de verste problemene med x86. På mobil/tablet er det derimot helt andre krav til strømforbruk, og da blir det bare tull å skulle sløse bort masse tid og ressurser på å prøve å holde denne dinosauren i live. Når den nye plattformen (Moorestown/Medfield) i tillegg ikke er kompatibel med tidligere x86 (f.eks pga mangel på PCI-buss) er det tydelig at Intel pusher det for at konkurrende instruksjonssett ikke skal få ta overhånd på det nye markedet. Intel er tross alt verdensledende på CMOS-teknologi og kan dermed levere en dårligere arkitektur (x86) som yter og bruker tilsvarende som konkurrerende instruksjonssett (ARM, MIPS) ene og alene pga. CMOS-teknologi. På den måte holder de live i x86, selv om forbrukerene ville vært bedre tjent med å innføre den gode CMOS-teknologien på en mer effektiv arkitektur (ARM, MIPS).

Det samme gjelder forøvrig i en viss grad på desktop, og det er jo lov å håpe at utbredelsen av ARM og MIPS på små dingser kan smitte over på desktop etter hvert. Vi har desktop-OS som kjører greit på disse (GNU/Linux), men samtidig må all programvare rekompileres (og gjerne skrives litt om), noe som kan bli vanskelig med properitær programvare.

x86 i seg selv har da ikke så store problemer, problemene ligger heller i at det er en CISC-arkitektur som er implementert i en RISC-prosessor, som har vist seg å være en blindgate siden skaléring på klokkefrekvens har møtt en vegg.

"CISC-filosofien" er derimot ikke noen dårlig idé, og fremtidige arkitekturer bør gå i den retningen for CPUer (i kombinasjon med SIMD eller lignende for parallelisering), fordi ytterligere betydelig skalering på klokkefrekvens er uaktuelt før vi eventuelt får alternativer til dagens halvledermaterialer. ARM-implementasjoner får også lignende effektforbruk som x86-implementasjoner når de skaleres forbi 3 GHz.

Det er særdeles lite i en x86-prosessor som er gammelt "ræl", det som tar mest plass er SSE og alle andre utvidelser. ARM har på sin side noen slike, og får stadig flere. Personlig synest jeg mange av disse er unødvendige og burde heller vært overlatt til SIMD. Men dette med at det er mye baggasje i x86 er en myte.

Det er ikke kompilatorer eller CMOS-teknologien som driver utviklingen for x86 videre for tiden, faktisk har ting stått ganske stille i flere år nå sett bort ifra lavere effektforbruk(CMOS-tek) og utvidelser. Alternativer som MIPS og PowerPC/Cell har mislykkes med å overta for x86, og det er rett og slett fordi dette ikke er veien å gå. ARM har nok sine fordeler som kan gi litt bedre ytelse, men i det totale bildet er det snakk om marginale forskjeller som ikke gjør at det er verdt å forkaste x86 med gode optimaliseringer, utviklererfaring og stort programvareutvalg. Det trengs noe langt mer nyskapende den dagen x86 skal legges til sides for generelt bruk.

x86 blir hele tiden utskjelt, men det er bestandig implementasjonene av x86 ting konkretiseres til, ikke selve instruksjonssettet. Hvis x86 skal leve i det lange løp må RISC-arkitekturen forlates og fokuseres på utførelse med ferrest mulig klokkesykler, rollen for CPU blir uansett mer og mer styring og mindre regning. Intel burde satset på en god ny CISC-aktig implementasjon av x86.

 

BTW: ARM-prosessorer blir også en del mer kompliserte når de skal støtte 64-bit.

[Simen1]

x86 i seg selv har da ikke så store problemer, problemene ligger heller i at det er en CISC-arkitektur som er implementert i en RISC-prosessor, som har vist seg å være en blindgate siden skaléring på klokkefrekvens har møtt en vegg.

Det blir feil å skylde på CISC som RISC for at klokkefrekvensen har stagnert. Det skyldes andre ting og stagnasjonen kan også sees på andre plattformer og implementasjoner.

 

Per i dag er så og si alt effektbegrenset. x86 er implementert med CISC instruksjonssett på RISC prosessor fordi det er mest effektivt (ytelse/watt). En ren CISC prosessor ville blitt mye mindre effektiv, altså betydelig lavere ytelse/watt. Siden prosessorer er effektbegrenset så betyr det betydelig lavere ytelse.

 

Problemet er altså ikke implementasjonsmåten CISC på RISC og løsningen er slett ikke CISC på CISC. Løsningen er å kaste CISC over ripa og spesielt x86 siden det er langt i fra noe moderne og effektivt instruksjonnsett for CISC. Ren gammeldags RISC er nok heller ingen god løsning, men RISC-implementasjoner kan gi bedre effektivitet og dermed høyere ytelse. Med dagens transistorbudsjetter har man råd til å kombinere flere typer prosessorer i én og ha en rekke støttefunksjoner som blant annet cache for å dekke over noen av svakhetene. Man kan også sortere blokker av kode til ulike prosessorkjerner (hetrogene kjerner), der hver kjerne er spesielt tilpasset en bestemt type kode. CPU + GPU er bare en begynnelse på æraen med multi-hetrogene kjerner.

Endret 29. desember 2011 av Simen1

[efikkan]

x86 i seg selv har da ikke så store problemer, problemene ligger heller i at det er en CISC-arkitektur som er implementert i en RISC-prosessor, som har vist seg å være en blindgate siden skaléring på klokkefrekvens har møtt en vegg.

Det blir feil å skylde på CISC som RISC for at klokkefrekvensen har stagnert. Det skyldes andre ting og stagnasjonen kan også sees på andre plattformer og implementasjoner.

 

Per i dag er så og si alt effektbegrenset. x86 er implementert med CISC instruksjonssett på RISC prosessor fordi det er mest effektivt (ytelse/watt). En ren CISC prosessor ville blitt mye mindre effektiv, altså betydelig lavere ytelse/watt. Siden prosessorer er effektbegrenset så betyr det betydelig lavere ytelse.

 

Problemet er altså ikke implementasjonsmåten CISC på RISC og løsningen er slett ikke CISC på CISC. Løsningen er å kaste CISC over ripa og spesielt x86 siden det er langt i fra noe moderne og effektivt instruksjonnsett for CISC. Ren gammeldags RISC er nok heller ingen god løsning, men "smartere" RISC-implementasjoner kan gi bedre effektivitet og dermed høyere ytelse. Med dagens transistorbudsjetter har man råd til å kombinere flere typer prosessorer i én og ha en rekke støttefunksjoner som blant annet cache for å dekke over noen av svakhetene.

Du misforstod, det er ikke CISC som RISC som er problemet, men for høye klokkefrekvenser i seg selv, derfor vil ARM også støte på tilsvarende problemer når de kommer høyt nok opp i frekvenser. Effektforbruket vokser eksponentielt med klokkefrekvensen så betydelig skalering videre er ingen god idé. Ved betydelig høyre klokkefrekvenser kan vi også støte på egenfrekvenser til metallene som benyttes. Som jeg nevnte er nøkkelen for betydelig skalering på klokkefrekvens en ny type halvledermateriale (eller noe helt nytt).

 

Legg også merke til at jeg foreslo en CISC-aktig implementasjon av x86, ikke en tradisjonell CISC-prosessor!

[endrebjo]

x86 i seg selv har da ikke så store problemer, problemene ligger heller i at det er en CISC-arkitektur som er implementert i en RISC-prosessor, som har vist seg å være en blindgate siden skaléring på klokkefrekvens har møtt en vegg.

"CISC-filosofien" er derimot ikke noen dårlig idé, og fremtidige arkitekturer bør gå i den retningen for CPUer (i kombinasjon med SIMD eller lignende for parallelisering), fordi ytterligere betydelig skalering på klokkefrekvens er uaktuelt før vi eventuelt får alternativer til dagens halvledermaterialer. ARM-implementasjoner får også lignende effektforbruk som x86-implementasjoner når de skaleres forbi 3 GHz.

Det er særdeles lite i en x86-prosessor som er gammelt "ræl", det som tar mest plass er SSE og alle andre utvidelser. ARM har på sin side noen slike, og får stadig flere. Personlig synest jeg mange av disse er unødvendige og burde heller vært overlatt til SIMD. Men dette med at det er mye baggasje i x86 er en myte.

Finnes det andre oppgaver enn grafikk og fysikk som drar god nytte av SIMD? For etter hvert som både CPU og GPU blir integrert på en APU vil vel overhead i GPGPU bli såpass lav at SIMD blir overflødig i CPU-delen (GPU er jo allerede en stor SIMD-maskin). Eller mener du at APUen bør bli én selvstendig CISC-enhet med felles grensesnitt og instruksjonssett (med både tradisjonelle instruksjoner og nye store SIMD-instruksjoner)?

 

Det er ikke kompilatorer eller CMOS-teknologien som driver utviklingen for x86 videre for tiden, faktisk har ting stått ganske stille i flere år nå sett bort ifra lavere effektforbruk(CMOS-tek) og utvidelser. Alternativer som MIPS og PowerPC/Cell har mislykkes med å overta for x86, og det er rett og slett fordi dette ikke er veien å gå. ARM har nok sine fordeler som kan gi litt bedre ytelse, men i det totale bildet er det snakk om marginale forskjeller som ikke gjør at det er verdt å forkaste x86 med gode optimaliseringer, utviklererfaring og stort programvareutvalg. Det trengs noe langt mer nyskapende den dagen x86 skal legges til sides for generelt bruk.

Jeg ser på lavere effektforbruk (pga. bedre CMOS) som positiv utvikling siden det i prinsippet kan brukes til å presse ytelsen høyere. Det kan jo, som du påpeker, selvfølgelig ikke fortsette i all evighet, og det så vi jo først med NetBurst og nå med Core som har stanget på 3 GHz i 3 år (mens antall kjerner har økt fra 2 til 10).

 

MIPS har vel aldri prøvd seg desktop tidligere, har de? Og PPC fungerte jo godt i PowerBook, men når Intel frister med lavere pris og høyere ytelse (begge pga. CMOS-tek.) og mye x86-optimalisert software (Windows) er det selvfølgelig vanskelig å motstå. PPC lever også i beste velgående i XBox og PS3 der de har nok akseleratorer å leke seg med (der er vi jammen inne på SIMD igjen). Så for meg ser det ikke ut som at RISC som styringsprosessor er feil vei å gå. Men hvis du vil at alt skal gå på samme instruksjonssettet trengs det selvfølgelig noe større.

 

x86 blir hele tiden utskjelt, men det er bestandig implementasjonene av x86 ting konkretiseres til, ikke selve instruksjonssettet. Hvis x86 skal leve i det lange løp må RISC-arkitekturen forlates og fokuseres på utførelse med ferrest mulig klokkesykler, rollen for CPU blir uansett mer og mer styring og mindre regning. Intel burde satset på en god ny CISC-aktig implementasjon av x86.

 

BTW: ARM-prosessorer blir også en del mer kompliserte når de skal støtte 64-bit.

Ja. Jeg burde vært mer spesifikk og påpekt at misnøyen hovedsaklig gjelder dagens implementasjon av x86 med en svær dekodings-blobb. For nå prøver Intel å dra med seg sin gamle og ineffektive implementasjon inn på mobil/tablet-markedet. Hvis man lar dem få fotfeste der er sjansen stor for at vi vil stå og stange i veggen i mange år slik Atom har gjort i netbooks de siste årene (folk ser jo faen meg ut til å være fornøyd med 2002-ytelse(!) i netbookene sine), mens Intel fortsetter å krympe teknologien. Hvis Intel derimot blir utfordret til å tenke helt nytt er sjansen større for at det kommer noe morsomt ut av det. Enten med et nytt instruksjonssett eller en helt ny x86-implementasjon. De sitter tross alt med de beste designerene og den største kapitalen i verden.

 

Som du sier, så er ytelsesforskjellen blant instruksjonssettene egentlig små så lenge de store regnejobbene blir pushet til spesialiserte/parallelle maskiner. Så da ender Intels Atom-satsning til slutt opp som "en i mengden" blant ARM og MIPS på håndholdte dingser så lenge de ikke klarer å komme opp med en revolusjonerende arkitektur som gir dem en stor ytelsesfordel. Satsningen før den tid blir i mine øyne dermed helt meningsløs. Eller mener du at det har noe for seg?

[Simen1]

Det kan jo, som du påpeker, selvfølgelig ikke fortsette i all evighet, og det så vi jo først med NetBurst og nå med Core som har stanget på 3 GHz i 3 år (mens antall kjerner har økt fra 2 til 10).

Ikke noe motargument, men litt perspektiv:

I løpet av 80-tallet økte klokkefrevkensen fra ca 1 til ca 30 MHz. Altså 30x på 10 år.

I løpet av 90-tallet økte klokkefrevkensen fra ca 30 til ca 1000 MHz. Altså 30x på 10 år.

I løpet av de siste 10 år har klokkefrevkensen økt fra ca 3 til ca 4 GHz. Altså 1,25x på 10 år.

 

Det tok ca 4 år fra 3 GHz ble nådd til man begynte å øke antall kjerner. Per i dag topper det ut på 6 kjerner for desktop.

[efikkan]

Nå begynner vi en mer interessant og saklig diskusjon

 

Finnes det andre oppgaver enn grafikk og fysikk som drar god nytte av SIMD? For etter hvert som både CPU og GPU blir integrert på en APU vil vel overhead i GPGPU bli såpass lav at SIMD blir overflødig i CPU-delen (GPU er jo allerede en stor SIMD-maskin). Eller mener du at APUen bør bli én selvstendig CISC-enhet med felles grensesnitt og instruksjonssett (med både tradisjonelle instruksjoner og nye store SIMD-instruksjoner)?

Jeg så for meg noe ala APU med en CISC-aktig modul som styremodul med relativt få kjerner som utfører "kompliserte" instruksjoner, gjerne også innlemme et nivå av threading. Jeg tenkte ikke at SIMD-modulen skulle være CISC, men om instruksjonssettet eksplisitt skal spesifisere hvilken modul som skal utføre beregningen eller om dette skal overlates til f.eks pre-fetcher er en interessant diskusjon.

 

Hovedpoenget mitt er uansett at ARM og annen RISC ikke er løsningen på problemene som prosessorer har i dag, pluss at å lempe på med ørten slike kjerner heller ikke skalerer på mange typer oppgaver. Veldig mange av de tyngre regneoppgavene egner seg nettopp for SIMD, det inkluderer video, grafikk (F.eks. GIMP, Photoshop, Blender, osv., men også skjermbilde for alle programmer), fysikk i spill, osv. Det skjer mer av dette enn du kanskje tror. Men la meg ta et lite eksempel her på hvordan SIMD kan være nyttig for selv den jevne bruker.

Se for deg et program for grafisk redigering fullstendig rendret på GPU, inkl hele GUI, og med direktemanipulering på GPU. Dette vil gi deg "umiddelbar" respons på effekter og filter, samtidig som CPU avlastes og selv en laptop med relativt beskjeden maskinvare vil kunne ha god flyt, som vil være veldig nyttig hvis du f.eks. er på tur og vil raskt redigere et 15MP bilde på en minibærbar før du sender det til trykk eller slenger det på tryneboka.

 

 

For å ta det litt lenger kunne jeg tenke meg en slags CPU som hadde implementert delivs funksjonaliteten til en kernel, muligens i kombinasjon med noe avansert firmware, dette for å redusere den store overheading som synkronisering i threading over mange CPU-kjerner har.

 

MIPS har vel aldri prøvd seg desktop tidligere, har de? Og PPC fungerte jo godt i PowerBook, men når Intel frister med lavere pris og høyere ytelse (begge pga. CMOS-tek.) og mye x86-optimalisert software (Windows) er det selvfølgelig vanskelig å motstå. PPC lever også i beste velgående i XBox og PS3 der de har nok akseleratorer å leke seg med (der er vi jammen inne på SIMD igjen). Så for meg ser det ikke ut som at RISC som styringsprosessor er feil vei å gå. Men hvis du vil at alt skal gå på samme instruksjonssettet trengs det selvfølgelig noe større.

MIPS har vel bare vært nevnt. Husk at Cell i sin tid ble spådd skulle erstatte x86 på desktopen. Og det står da ikke så mye på produksjonsteknikk heller, IBM er langt fremme, og flere ulike Power-prosessorer har høye klokkefrekvenser uten at de har vist seg overlegne for desktop-bruk.

 

Windows-programvare hadde selvsagt ingen betydning for Apples valg med å gå over til x86, det handlet mer om mangel på fremtidsutsikter for egnede CPUer (dvs. andre ting enn server-CPUer). Intel har fristet med et brett utvalg fra laptop til skrivebord og servere, og da er det selvsagt fristende.

 

Ja. Jeg burde vært mer spesifikk og påpekt at misnøyen hovedsaklig gjelder dagens implementasjon av x86 med en svær dekodings-blobb. For nå prøver Intel å dra med seg sin gamle og ineffektive implementasjon inn på mobil/tablet-markedet. Hvis man lar dem få fotfeste der er sjansen stor for at vi vil stå og stange i veggen i mange år slik Atom har gjort i netbooks de siste årene (folk ser jo faen meg ut til å være fornøyd med 2002-ytelse(!) i netbookene sine), mens Intel fortsetter å krympe teknologien. Hvis Intel derimot blir utfordret til å tenke helt nytt er sjansen større for at det kommer noe morsomt ut av det. Enten med et nytt instruksjonssett eller en helt ny x86-implementasjon. De sitter tross alt med de beste designerene og den største kapitalen i verden.

 

Som du sier, så er ytelsesforskjellen blant instruksjonssettene egentlig små så lenge de store regnejobbene blir pushet til spesialiserte/parallelle maskiner. Så da ender Intels Atom-satsning til slutt opp som "en i mengden" blant ARM og MIPS på håndholdte dingser så lenge de ikke klarer å komme opp med en revolusjonerende arkitektur som gir dem en stor ytelsesfordel. Satsningen før den tid blir i mine øyne dermed helt meningsløs. Eller mener du at det har noe for seg?

For å presisere, jeg er uenig i Intels strategi om å tviholde på "dekodings-arkitekturen" som de benytter i dag. De bør enten bygge en ny arkitektur som benytter x86 eller erstatte x86 med noe helt annet. Selv om Atom har gjerne kuttet ut en del funksjonalitet så drasser den med seg mye funksjonalitet som egentlig er lite brukt, men som den på en måte må ha med fordi det brukes her og der. De burde nesten vurdert å ha en "redusert x86" med en passe stor SIMD-modul.

 

Men jeg er ikke helt pessimistisk til Atom, for jeg ser absolutt genvisten av x86-kompatibilitet. Se for deg et mediesenter der du vil ha mulighet til å kjøre en del spill, hvis du velger ARM så er det svært begrenset hva du kan kjøre, også av Windows-programmer. Med litt mer "smarte" programmer kunne også flere spill og programmer gått fint på Atom + en middels GPU/SIMD-modul.

Endret 31. desember 2011 av efikkan