ARM kondigt ARMv8-architectuur met 64bit-instructieset aan
ARM heeft de eerste details vrijgegeven van zijn nieuwe ARMv8-A-processorarchitectuur. De nieuwe architectuur is de eerste van ARM met 64bit-ondersteuning en is volledig compatibel met de huidige ARMv7-A-architectuur.
De belangrijkste twee execution states van de nieuwe ARMv8-architectuur zijn AArch64 en AArch32. De eerste introduceert de nieuwe 64bit-A64-instructieset, terwijl de tweede ondersteuning biedt voor de huidige A32- en Thumb-2-32bit-instructiesets. Onderdelen van de huidige ARMv7-architectuur als Trustzone, virtualisatie en Neon zijn behouden of uitgebreid in ARMv8.
De A64-instructieset maakt onder meer 64bit-verwerking van data en 64bit-adressering van virtueel geheugen mogelijk. Hierdoor kunnen energiezuinige chips op basis van de nieuwe architectuur ingezet worden voor onder meer datacenters, andere servertaken en supercomputers, waar energieverbruik en hitteafgifte hot items zijn.
De chipontwerper wil snel een ecosysteem rond de nieuwe 64bit-instructieset opbouwen. Belangrijke partners van het bedrijf hebben daarom van de chipontwerper al de ARM-compiler met ARMv8-ondersteuning gekregen, terwijl begonnen is met de ondersteuning van de nieuwe architectuur in opensource-besturingssystemen, applicaties en ontwikkeltools.
De specificatie van ARMv8, waarin alle aspecten van de architectuur beschreven worden, is nu al beschikbaar voor partners waarmee licentieovereenkomsten gesloten zijn. ARM maakt de eerste processorontwerpen op basis van ARMv8 in 2012 bekend, terwijl de eerste prototypes van servers op basis van deze processorontwerpen in 2014 getoond worden.
Reacties (53)
Betekend dat dan dat Windows 8 ook een 64 bit ARM versie gaat krijgen? En 64 bit ARM heeft dat dezelfde kenmerken als de x86/x64 architectuur als het gaat om maximaal geheugengebruik? (Dus x86 max. 4GB en x64 max 128GB)De chipontwerper wil snel een ecosysteem rond de nieuwe 64bit-instructieset opbouwen. Belangrijke partners van het bedrijf hebben daarom van de chipontwerper al de ARM-compiler met ARMv8-ondersteuning gekregen, terwijl begonnen is met de ondersteuning van de nieuwe architectuur in opensource-besturingssystemen, applicaties en ontwikkeltools.
[Reactie gewijzigd door LCP op vrijdag 28 oktober 2011 14:02]
eerst moeten de chips nog verschijnen, maar dat zou kunnen.
wat geheugen betreft, dat hangt er vanaf hoe veel bits ze daadwerkelijk gaan gebruiken.
AMD64 bied ondersteuning aan 64bit adres ruimte, maar de huidige CPU's gebruiken 'maar' 48bit daarvan (wat genoeg ruimte bied voor absurd veel geheugen)
in het oogpunt van energy besparing zouden ze voor 36bit of 40 bit kunnen kiezen als voorlopig maximum.
wat geheugen betreft, dat hangt er vanaf hoe veel bits ze daadwerkelijk gaan gebruiken.
AMD64 bied ondersteuning aan 64bit adres ruimte, maar de huidige CPU's gebruiken 'maar' 48bit daarvan (wat genoeg ruimte bied voor absurd veel geheugen)
in het oogpunt van energy besparing zouden ze voor 36bit of 40 bit kunnen kiezen als voorlopig maximum.
Windows 8 is er binnen een jaar al, lang voordat er 64-bit ARM cpu's te koop zijn, dus reken er niet op. Windows 9 (2014) waarschijnlijk wel.
ARM (v7) doet nu al 40-bit fysiek maar "slechts" 32-bit virtueel (dus max 4 GiB per applicatie).
[Reactie gewijzigd door J.J.J. Bokma op vrijdag 28 oktober 2011 19:19]
128GB is limit die MS heeft gesteld, dus ligt aan MS. 64bit adres geeft aan dat je dus 256 TB kan adresseren, of dat beschikbaar is om te adreseren ligt aan overige hardware en software.[...]
Betekend dat dan dat Windows 8 ook een 64 bit ARM versie gaat krijgen? En 64 bit ARM heeft dat dezelfde kenmerken als de x86/x64 architectuur als het gaat om maximaal geheugengebruik? (Dus x86 max. 4GB en x64 max 128GB)
Nee, voor 256TiB heb je je slechts 48 bits adressen nodig: 1 TiB is 240. 256 is 28, dus 256 TiB = 248. Dat is wat huidige x64 implementaties momenteel ondersteunen, maar in de toekomst kan dat groeien tot 52 bits.64bit adres geeft aan dat je dus 256 TB kan adresseren
Met een volledige 64 bits address range kun je 16 EiB (exabyte) = 16.777.216 TiB aanspreken.
[Reactie gewijzigd door .oisyn op vrijdag 28 oktober 2011 14:33]
2^64 = 18.446.744.073.709.551.616
18 Exa byte 256 tb is maar 48 bits (dat is wat de huidige hardware daadwerkelijk support).
18 Exa byte 256 tb is maar 48 bits (dat is wat de huidige hardware daadwerkelijk support).
edit:
oeps ja typo
oeps ja typo
[Reactie gewijzigd door PuzzleSolver op vrijdag 28 oktober 2011 18:40]
Ik neem aan dat je 2^64 bedoelde? Want 2^62 is 4611686018427387904.
En dan kom je uit op wat .oisyn al zei: 16 EiB en niet 18 EiB, aangezien een EiB 2^60 is, ergo: 2^64 / 2^60 = 16 EiB.
En dan kom je uit op wat .oisyn al zei: 16 EiB en niet 18 EiB, aangezien een EiB 2^60 is, ergo: 2^64 / 2^60 = 16 EiB.
Het verhaal over 64 bit geheugen adressering is in principe hetzelfde als bij de x86 architectuur. Ware het niet dat x64 een 48 bit adresbus gebruikt om het fysieke geheugen aan te spreken, en daarmee tot maximaal 128 TB kan ondersteunen.
En ik neem aan dat Windows 8 ondersteuning voor 64bits ARM gaat geven, er is volgens mij geen goede reden om het niet te doen. Er is wel een goede reden om ook een 32 bits ARM versie van Windows te maken: de 64 bits ARM chips zijn nog niet op de markt.
En ik neem aan dat Windows 8 ondersteuning voor 64bits ARM gaat geven, er is volgens mij geen goede reden om het niet te doen. Er is wel een goede reden om ook een 32 bits ARM versie van Windows te maken: de 64 bits ARM chips zijn nog niet op de markt.
Beetje kort door de bocht (naast dat het 256TB is, niet 128TB). In principe ondersteunt het x64 ontwerp 52 bits (en niet meer, want je hebt maar ruimte voor 52 bits adressen in de page table), dus 4 petabyte, maar in de specs is opgenomen dat een implementatie minder adreslijnen mag ondersteunen. In het geval van virtuele adressen betekent dat dat de space in 2'en wordt gehakt, en naar boven groeit vanaf 0 en naar beneden groeit vanaf 0xFFFF FFFF FFFF FFFF. Dit is gedaan zodat het OS zijn kernel en dergelijke altijd op de hoogste adressen kan plaatsen, ongeacht hoeveel adreslijnen de onderliggende architectuur daadwerkelijk ondersteunt. Het adres 0xFFFF FFFF FFFF FFFF (waar je 64 bits voor nodig hebt) is dus altijd geldig, ookal ondersteunt je CPU maar 40 bits adreslijnen.Ware het niet dat x64 een 48 bit adresbus gebruikt om het fysieke geheugen aan te spreken, en daarmee tot maximaal 128 TB kan ondersteunen.
De huidige implementaties hebben 48 bits adreslijnen. De eerste AMD64 implementatie had er maar 40 (1TB adresruimte).
[Reactie gewijzigd door .oisyn op vrijdag 28 oktober 2011 14:38]
Als de spec nu pas af is, dan weet ik wel een goede reden: hoe wil je W8 in vredesnaam binnen een jaar inclusief alle tests en debugging op de markt hebben als je nu nog moet beginnen met alle 32-bit ARMv7 code naar 64-bit ARMv8 porten?En ik neem aan dat Windows 8 ondersteuning voor 64bits ARM gaat geven, er is volgens mij geen goede reden om het niet te doen.
Windows 9 - ander verhaal natuurlijk.
[Reactie gewijzigd door Dreamvoid op vrijdag 28 oktober 2011 17:26]
Lees het artikel eens, volgens mij beantwoord die de vragen:
-Er hoeft helemaal niets geport te worden, want ARMv8a is backwards compatible met ARMv7a, dus alle bestaande instructies blijven werken,
-De compiler / tools zijn nu al bechikbaar, dus ze kunnen al beginnen.
Allicht is het zo dat MSFT achterloopt op Linux, omdat ARM natuurlijk al een poosje aan Linux-ondersteuning heeft (binnen Linaro-initiatief) kunnen werken. Waar echter ARM vermoedelijk de broncode van Windows kernel niet kan inzien / compileren.
MSFT echter heeft een licentie op de ARMv7a instructieset - en ik vermoed dat ze die ook gaan hebben op de 8a instructieset, dus dan weten ze exact hoe ze maximaal kunnen gaan profiteren.
-Er hoeft helemaal niets geport te worden, want ARMv8a is backwards compatible met ARMv7a, dus alle bestaande instructies blijven werken,
-De compiler / tools zijn nu al bechikbaar, dus ze kunnen al beginnen.
Allicht is het zo dat MSFT achterloopt op Linux, omdat ARM natuurlijk al een poosje aan Linux-ondersteuning heeft (binnen Linaro-initiatief) kunnen werken. Waar echter ARM vermoedelijk de broncode van Windows kernel niet kan inzien / compileren.
MSFT echter heeft een licentie op de ARMv7a instructieset - en ik vermoed dat ze die ook gaan hebben op de 8a instructieset, dus dan weten ze exact hoe ze maximaal kunnen gaan profiteren.
Het "feature freeze" stadium zal bij Windows 8 allang voorbij zijn, we hebben nog maar een paar maanden voor de laatste beta ronde. Niks is onmogelijk, maar ik denk dat de kans op 64-bit ARMv8 support in W8 vrijwel nihil is. Natuurlijk zal W8 wel op dit soort SoC's draaien (backwards compatible, idd), maar in 64-bit modus?
[Reactie gewijzigd door Dreamvoid op zaterdag 29 oktober 2011 00:37]
Das waar, misschien zal Microsoft het in een Service Pack stoppen.
Als ik het goed begrijp, kan Microsoft gewoon de huidige broncode nemen, en aan de compiler hoeft alleen maar een 'vlag' (commando-lijn-argumentje) gegeven te worden wat de doel-architectuur is. Nu vult MSFT daar ARMv7a in, maar als ze de nieuwe compiler nemen en gewoon ARMv8a nemen, dan zou die compiler de huidige bestaande code moeten optimaliseren voor ARMv8a.
Een beetje net zoals je vroeger met gcc ook deed met generiek compileren voor i386 en dan kon je i586/i686 aanzetten, en dan maakte het ook optimalisaties voor 'nieuwere' features.
Inderdaad is het zo dat echt prestatie-kritieke programma's vaak wel in ASM geschreven / geoptimaliseerd worden (denk aan de i586-AES encryptie-driver in Linux of MPrime95 voor Windows), maar dat gebeurt denk ik niet zo vaak meer.
Als ik het goed begrijp, kan Microsoft gewoon de huidige broncode nemen, en aan de compiler hoeft alleen maar een 'vlag' (commando-lijn-argumentje) gegeven te worden wat de doel-architectuur is. Nu vult MSFT daar ARMv7a in, maar als ze de nieuwe compiler nemen en gewoon ARMv8a nemen, dan zou die compiler de huidige bestaande code moeten optimaliseren voor ARMv8a.
Een beetje net zoals je vroeger met gcc ook deed met generiek compileren voor i386 en dan kon je i586/i686 aanzetten, en dan maakte het ook optimalisaties voor 'nieuwere' features.
Inderdaad is het zo dat echt prestatie-kritieke programma's vaak wel in ASM geschreven / geoptimaliseerd worden (denk aan de i586-AES encryptie-driver in Linux of MPrime95 voor Windows), maar dat gebeurt denk ik niet zo vaak meer.
klinkt leuk, was het niet zo dat de MS compiler dit dus ook moet ondersteunen. Dus buiten het 'enkel hercompileren' heb je een hele compiler die dit 'ff' moet ondersteunen en getest worden.
Dat gcc dit volgende week heeft b.v., is onwaarschinlijk, maar zou nog kunnen.
Dat gcc dit volgende week heeft b.v., is onwaarschinlijk, maar zou nog kunnen.
Dat lijkt me stug, je kunt je 32 bits Windows niet ineens 64 bits maken door een SP te downloaden. Het zal gewoon een aparte release worden dat een herinstallatie vereist. Dat zag je ook met WinXP x64.Das waar, misschien zal Microsoft het in een Service Pack stoppen.
Uh, volgens mij gooi je wat door elkaar. De 32-bit Windows versies ondersteunen tot 64GB fysiek RAM (hoewel die feature alleen in de server versies actief is, volgens MS is dat omdat veel 32-bit drivers er toch niet goed mee om kunnen gaan), ook al kan een enkel process daar nooit meer dan ~4GB van gebruiken.
de beperkingen zijn licentiegebonden, niet hardware gebonden, inderdaad.
maar ik kan me voorstellen, aangezien de beperkingen licentiegebonden zijn,
deze beperkingen ook voor hetzelfde product op een andere architectuur gelden
Merk wel op dat deze beperkingen pas vanaf XP SP2 zijn ingevoerd, dus XP SP1 en daarvoor konden vrolijk onder 32 bit meer dan 4 GB gebruiken. En aangezien het toen wel werkte, zeg ik dat driver argument is bull, dit is gewoon een manier om mensen te dwingen naar 64 bit over te stappen
maar ik kan me voorstellen, aangezien de beperkingen licentiegebonden zijn,
deze beperkingen ook voor hetzelfde product op een andere architectuur gelden
Merk wel op dat deze beperkingen pas vanaf XP SP2 zijn ingevoerd, dus XP SP1 en daarvoor konden vrolijk onder 32 bit meer dan 4 GB gebruiken. En aangezien het toen wel werkte, zeg ik dat driver argument is bull, dit is gewoon een manier om mensen te dwingen naar 64 bit over te stappen
Dat doen ze via een truukje genaamd PAE, een truukje wat ik vaker fout heb zien gaan dan goed. Een hoop systemen (windows, linux en FreeBSD alike) raakten er hopeloos instabiel van.De 32-bit Windows versies ondersteunen tot 64GB fysiek RAM
Maar goed, waar hebben we 't over, 32-bit is vrijwel uitgeroeid, gelukkig.
99% van de distros hebben standaard pae kernel.. En er is niks instabiels aan... Draai het hier zelf ook[...]
Dat doen ze via een truukje genaamd PAE, een truukje wat ik vaker fout heb zien gaan dan goed. Een hoop systemen (windows, linux en FreeBSD alike) raakten er hopeloos instabiel van.
Maar goed, waar hebben we 't over, 32-bit is vrijwel uitgeroeid, gelukkig.
Ondersteundden, voorzover ik kan zien. Veel drivers hadden er moeite mee, vandaar dat het begon op de server. Daar is 64 bits echter gemeengoed geworden. PAE is dus overbodig geworden op de server, en onstabiel op clients met gekke drivers. Dan is het niet zo gek dat Microsoft de 32 bits limiet weer heeft teruggezet op 4GB zonder hacks.
dit zet vooral de deur open voor windows server.
Ik zou smullen als in de nieuwe nasjes van synology een processor als deze in zou zitten.
Zeker de 64-bit zou goed van pas komen bij zware rekentaken als usenet downloaden en uitpakken
Zeker de 64-bit zou goed van pas komen bij zware rekentaken als usenet downloaden en uitpakken
Mwa, ik denk niet dat het echt iets zou opschieten...
alleen hashes bijv kunnen sneller gaan door de 64bits die je in de zelfde tijd als een 32bits getal kunt berekenen.
Een feit blijft dat de meeste programma's voor het meerendeel gewoon kleine getallen gebruiken, 64bit maakt dat allemaal niks sneller
Wel vind ik het vet dat ARM echt in een goede richting aan het werken is. Op deze manier kunnen ze in de loop van tijd een geduchte tegenstander worden voor intel cpu's
Intel is nu al aan het zweten nu microsoft aan een arm versie van windows werkt
alleen hashes bijv kunnen sneller gaan door de 64bits die je in de zelfde tijd als een 32bits getal kunt berekenen.
Een feit blijft dat de meeste programma's voor het meerendeel gewoon kleine getallen gebruiken, 64bit maakt dat allemaal niks sneller
Wel vind ik het vet dat ARM echt in een goede richting aan het werken is. Op deze manier kunnen ze in de loop van tijd een geduchte tegenstander worden voor intel cpu's
Intel is nu al aan het zweten nu microsoft aan een arm versie van windows werkt
Erger nog: 64 bits maakt het langzamer over het algemeen: alle pointers zijn 2x zo groot, dus moet er meer data van memory<->cpu over die toch al overbelaste bus. 32bits is wat dat betreft beter. Voor x86 geld echter dat men ook het aantal registers verdubbeld heeft om de inherente performance bottleneck van 64bits te compenseren. Het netto resultaat is geen al te groot performance verlies maar wel veel meer geheugen adreseerbaar (wat ook performance verhogend kan werken: geen wazige PAE truken en een grotere heap zodat je app niet in de swap loopt).
De "huidige" architectuur (Cortex A15) kan met 40 bits al 1TB virtueel geheugen addresseren, alleen dat moet met wat 'vertragende' trucjes en vertalingen want de kern denkt nog steeds dat er maar 4GB is.
Ik hoop dat de CRYPTO blokken voor hardware encryptie staan.
Dat is iets wat ik wel toe juich. Want dat mis ik wel in me lowpower servertje.
Dit zou ik zeker als servertje gaan gebruiken.
Dat is iets wat ik wel toe juich. Want dat mis ik wel in me lowpower servertje.
Dit zou ik zeker als servertje gaan gebruiken.
als het woord 'crypto' in deze slide als cryptografie word bedoeld, dan zal het inderdaad encryptie zijn in wat voor vorm dan ook.
echter denk ik dat ze bedoelen dat het ondersteuning heeft voor hardwarematig versnelde encryptie, als zijnde een instructie set. voor versnelling van encryptie op een bepaalde methode.
mijn verwachting is dan ook dat het hier om gaat, net als bij intel:
"Intel® AES-NI", dus alleen versnelling voor AES (Rijndael) encryptie, echter of hierbij ook Two-fish en Serpent encryptie worden inbegrepen betwijfel ik.
hardwarematige encryptie an sich zou in houden dat alle gegevens, ten alle tijde, dat het wegschrijft versleuteld zou zijn, op een vooraf (hardwarematig) vastgestelde manier. zoals ze dat ook bij sommige USB sticks doen.
(beetje spuit-11, want neem aan dat je dit ook bedoelde, maar ter verduidelijking)
echter denk ik dat ze bedoelen dat het ondersteuning heeft voor hardwarematig versnelde encryptie, als zijnde een instructie set. voor versnelling van encryptie op een bepaalde methode.
mijn verwachting is dan ook dat het hier om gaat, net als bij intel:
"Intel® AES-NI", dus alleen versnelling voor AES (Rijndael) encryptie, echter of hierbij ook Two-fish en Serpent encryptie worden inbegrepen betwijfel ik.
hardwarematige encryptie an sich zou in houden dat alle gegevens, ten alle tijde, dat het wegschrijft versleuteld zou zijn, op een vooraf (hardwarematig) vastgestelde manier. zoals ze dat ook bij sommige USB sticks doen.
(beetje spuit-11, want neem aan dat je dit ook bedoelde, maar ter verduidelijking)
[Reactie gewijzigd door un1ty op vrijdag 28 oktober 2011 14:54]
De ARM techcon 2011 presentatie zegt:
- Instruction level support for Cryptography
- Not intended to replace hardware accelerators in an SoC
- AES
- 2 encode and 2 decode instructions
- Work on the Advanced SIMD 128-bit registers
- 2 instructions encode/decode a single round of AES
- SHA-1 and SHA-256 support
- Keep running hash in two 128 bit wide registers
- Hash in 4 new data words each instruction
- Instructions also accelerate key generation
- Instruction level support for Cryptography
- Not intended to replace hardware accelerators in an SoC
- AES
- 2 encode and 2 decode instructions
- Work on the Advanced SIMD 128-bit registers
- 2 instructions encode/decode a single round of AES
- SHA-1 and SHA-256 support
- Keep running hash in two 128 bit wide registers
- Hash in 4 new data words each instruction
- Instructions also accelerate key generation
ik snap hier heel weinig van, maar betekent dit dat windows 7 ook op de 64bit ARM chips kan draaien?
Nee, helaas. ARM heeft een heel andere processorarchitectuur.
Windows 8 zou wel geschikt zijn om op ARM te draaien.
Windows 8 zou wel geschikt zijn om op ARM te draaien.
windows 7 draait sowiso niet op ARM, 32 or 64bit.
windows 7 is geschreven voor x86. een cpu die windows7 wil draaien moeten dus x86 spreken. en dat kunnen alleen intel en AMD CPU's.
ARM cpu's spreken, nouja, ARM en dus moet de software die ze draaien gecompileerd zijn voor ARM.
windows 8 komt zowel in x86 als in ARM variant uit.
windows 7 is geschreven voor x86. een cpu die windows7 wil draaien moeten dus x86 spreken. en dat kunnen alleen intel en AMD CPU's.
ARM cpu's spreken, nouja, ARM en dus moet de software die ze draaien gecompileerd zijn voor ARM.
windows 8 komt zowel in x86 als in ARM variant uit.
ja klinkt leuk allemaal maar ik heb al meer dan 6 jaar een 64 bit chip in mijn pc hangen en nog steeds heb ik zo goed als geen 64 bit software en de 64 bit software die ik heb is vaak even snel ietsje sneller of zelfs trager dan 32 bit software.
dat 64 bit is of flink overhyped of de devs hebben gewoon geen zin om er software voor te schijven.
dus tot nu toe is het enigste voordeel dat 64 bit geefd een paar gig extra ram...
dat 64 bit is of flink overhyped of de devs hebben gewoon geen zin om er software voor te schijven.
dus tot nu toe is het enigste voordeel dat 64 bit geefd een paar gig extra ram...
Je vergeet echter, je software spreekt de hardware niet op 64bits 'wijze' aan, maar de hardware onderling heeft wel baat bij de 64bits instructies, kijk alleen al naar de hoeveelheid geheugen dat een 64bits processor kan aanspreken tov een 32bits variant.
ik zelf draai ook maar een aantal 64bits programmas (photoshop, truecrypt, office en nog een aantal onbekende andere programma's).
ik zelf draai ook maar een aantal 64bits programmas (photoshop, truecrypt, office en nog een aantal onbekende andere programma's).
Huh? Windows, OS X en Linux zijn al een tijd 64-bit, en vrijwel alle programma's die baat hebben bij 64-bit zijn ook allang over.
Nou, standaard werd tot nog niet zo lang geleden altijd de 32-bit versies geinstalleerd ook al was de 64bit versie beschikbaar..
Jij hebt dan ook geen server onder je bureau staan of wel? Voor consumenten is 64 bit software nog steeds niet heel interessant, er zijn maar enkele programma's die meer dan 4GB geheugen gebruiken. Servers daarentegen draaien heel veel 64 bit software. Sterker nog, gebrek aan 64bit ondersteuning zorgt er voor dat ARM bijna niet gebruikt wordt in servers, en dat is nu precies de reden waarom ARM nu met de 64 bit architectuur komt.
3 IBM eSeries. 2 maal een x225, 1 maal een x226. Allemaal met 6 Ultra-320 10K rpm schijven. En nog een Mac Mini server op m'n bureau.Jij hebt dan ook geen server onder je bureau staan of wel?
Ja dus.
Ik denk dat het voor consumenten bijzonder intressant is. Een hele berg is bezig met foto's ( die met de huidige hoeveelheid megapixels, en voorliefde voor RAW formats goed groot worden ) en met Full-HD video's...Voor consumenten is 64 bit software nog steeds niet heel interessant
Dit is vooral leuk voor de servers lijkt me? Een 64bits smartphone lijkt me niet heel erg super interessant.
En juist daar is het dus ook voor bedoeld.. Het is dan ook wel heel toevallig dat HP net ook heeft gezegd dat ze servers gaan uitbrengen gebasseerd op ARM architectuur..
Mag ik me daar bij aansluiten: Imagination Technologies is bezig haar raytracing-engine op termijn naar de PowerVR serie te brengen. Kan nog een paar jaar duren, maar toch.
En die PowerVR ontwerpen zijn onder andere te vinden in jawel hoor, tablets en telefoons. Het oprolbare scherm is nu ook bijna productierijp. De eerste video-bewerkingssoftware voor telefoons is er al. En natuurlijk heeft Samsung het grootste fab ter wereld (lijn 16) geopend voor 20nm-klasse geheugen, maar dat moet ook gaan dienen zoor de 10nm-klasse.
Of er ook echt daadwerkelijk vraag naar is valt nog te bezien, want al dat 3D loopt ook nog niet echt storm, en of 4K2K nou echt nuttig is, is ook maar zeer de vraag. Belangrijkste is dat het allemaal kan, en dat ARM 'klaar voor de toekomst' is.
Dus vooral nuttig voor servers (want hier werd naar gevraagd!), maar vooral 'leuk' voor telefoons.
En die PowerVR ontwerpen zijn onder andere te vinden in jawel hoor, tablets en telefoons. Het oprolbare scherm is nu ook bijna productierijp. De eerste video-bewerkingssoftware voor telefoons is er al. En natuurlijk heeft Samsung het grootste fab ter wereld (lijn 16) geopend voor 20nm-klasse geheugen, maar dat moet ook gaan dienen zoor de 10nm-klasse.
Of er ook echt daadwerkelijk vraag naar is valt nog te bezien, want al dat 3D loopt ook nog niet echt storm, en of 4K2K nou echt nuttig is, is ook maar zeer de vraag. Belangrijkste is dat het allemaal kan, en dat ARM 'klaar voor de toekomst' is.
Dus vooral nuttig voor servers (want hier werd naar gevraagd!), maar vooral 'leuk' voor telefoons.
Zitten nog een paar stapjes tussen server en smartphone. Een low powered 64 bits ARM en Android based nettop PC met 16GB RAM ofzo zou best leuk kunnen zijn denk ik.
ARM is flink bezig. Nog even en ze zitten on par qua prestaties met Intel chips, maar wel de helft aan watts. Schijnt ook dat door de simpelere instructie sets het makelijker is om stabielere software te maken. Al met al perfect voor servers dus.
Dat is wel een behoorlijke aanname.
De x64 ISA is behoorlijk vereenvoudigd. De meeste instructies werken op de meeste registers, bijvoorbeeld.
Anderzijds weten we nog niet precies hoe complex de 32/64 bits interoperabiliteit voor ARM gaat worden.
Je kunt dus niet concluderen dat x86-64 complexer en inefficienter is dan ARM-64.
De x64 ISA is behoorlijk vereenvoudigd. De meeste instructies werken op de meeste registers, bijvoorbeeld.
Anderzijds weten we nog niet precies hoe complex de 32/64 bits interoperabiliteit voor ARM gaat worden.
Je kunt dus niet concluderen dat x86-64 complexer en inefficienter is dan ARM-64.
Hoor meer over ARM recentelijk dan over AMD. Met Win8 maakt het niet meer uit of x86 of ARM processor hebt en zit je niet aan linux vast. Al denk ik niet dat alle oude software nog zal werken, maar of dat voor de doorsnee gebruiker een probleem is denk ik niet. Meer opties brengt hopelijk de prijzen verder naar onder en energie gebruik omlaag. Werk nu sinds vandaag op 64 bit windows 7 en net asl van 16 naar 32 bits jaren geleden merk ik er weinig van. Het moet voor mij a) werken b) zo snel mogelijk en c)zo min mogelijk energie gebruik zodat de laptop lang zonder kabel kan. Geen echte desktop meer thuis! Heb nu een NAS voor de centrale opslag en afhankelijk of ik een groot scherm nodig heb een all in of een laptop eventueel met een extern scherm.
uhh.. Met Windows 8 maakt het dus wel degelijk uit of je x86 of ARM hebt, een programma geschreven voor Windows 8 arm draait in principe niet rechtstreeks op de x86 variant.. En zeker huidige programma's gaan niet draaien op een Windows 8 ARM versie..
Daar heeft Windows 8 de nieuwe WinRT API en de Metro UI voor. Het idee is dat je gewoon code kan schrijven in C/C++, C# of Javascript, en het draait op zowel ARM als x86.
Andersom klopt het idd: ouderwetse Win32/64 applicaties gaan niet draaien op de ARM versie.
Andersom klopt het idd: ouderwetse Win32/64 applicaties gaan niet draaien op de ARM versie.
[Reactie gewijzigd door Dreamvoid op vrijdag 28 oktober 2011 21:03]
Daarom roepen ze ook dat Metro frontend gebaseerd is op HTML. Want wat achter hangt maakt dan niets meer uit, ARM/x86 etc
In de nabije toekomst heel interessant voor notebooks daar ARM chips bekend staan om hun zuinigheid. Het is niet duidelijk of deze chip een of twee cores heeft?
Vermoed 1 64 bit CPU kern.
Afwachten maar
Vermoed 1 64 bit CPU kern.
Afwachten maar
De ARM serverversie is inmiddels ook onderweg en medio volgend jaar op de markt volgen dit bericht http://www.theregister.co...o_arm_x_gene_server_chip/
Op dit item kan niet meer gereageerd worden.
Onderwerpen
Populair: Asus Samsung Mobiele telefoons Laptops Apple Sony Games Microsoft Consoles Microsoft Xbox One
© 1998 - 2013 Tweakers.net B.V. Contact Over Tweakers Jouw privacy Algemene voorwaarden Cookies
Tweakers wordt uitgegeven door De Persgroep en wordt gehost door True
