ARM's nye turbo-processor: Femdobler ydeevnen med konstant effektforbrug

10. september 2010 kl. 14:084
Cortex A15 er ARM's quadcore-design, der er beregnet til design i 32 eller 28 nm procesteknologi.
Artiklen er ældre end 30 dage

ARM har netop løftet sløret for firmaets nyeste processordesign. Det drejer sig Cortex A15, der er en quadcoreprocessor beregnet til fremstilling i 32 eller 28 nm procesteknologi. ARM designer kun processorer, det fremstiller dem ikke selv, hvorfor det er op til de enkelte licenstagere at vælge, hvilken procesteknologi, de vil anvende.

Derfor er det heller ikke på nuværende tidspunkt muligt at komme med effektforbrug for de endelige produkter, men ARM oplyser, at processoren, der arbejder med fire processorkerner, er beregnet til at arbejde med frekvenser i området mellem 1 og 2,5 GHz.

I pressemeddelelsen taler ARM endvidere om en femdobling af den typiske ydeevne i forhold til eksisterende produkter ? og det er vel at mærke med samme effektforbrug.

Foruden øget ydeevne er der også blevet plads til fornyelser som blandt andet komplet understøttelse af virtualisering, der på længere sigt vil gøre det betydeligt nemmere at fremstille operativsystemer og færdige softwarepakker.

Artiklen fortsætter efter annoncen

Det vil således være muligt at levere et stykke hardware med en indbygget hypervisor, der giver hardwaren et virtuelt lsg, således at forskellig hardware ser ens ud for applikationerne og operativsystemerne.

Med det nye processordesign går ARM for alvor Intel i bedene mod dets Atom-processor samt mod AMD, der snart forventes at kunne levere en Bobcat-processor, der er beregnet til samme marked, som blandt andet omfatter tavle-pc'er og lignende udstyr, der blandt andet er baseret på Android eller Windows Phone 7.

Med det store frekvensområde, som A15 dækker over, vil den endvidere i de langsommere udgaver kunne anvendes i smartphones, uden at batteriet lider unødigt under det.

4 kommentarer.  Hop til debatten
Denne artikel er gratis...

...men det er dyrt at lave god journalistik. Derfor beder vi dig overveje at tegne abonnement på Version2.

Digitaliseringen buldrer derudaf, og it-folkene tegner fremtidens Danmark. Derfor er det vigtigere end nogensinde med et kvalificeret bud på, hvordan it bedst kan være med til at udvikle det danske samfund og erhvervsliv.

Og der har aldrig været mere akut brug for en kritisk vagthund, der råber op, når der tages forkerte it-beslutninger.

Den rolle har Version2 indtaget siden 2006 - og det bliver vi ved med.

Debatten
Log ind eller opret en bruger for at deltage i debatten.
settingsDebatindstillinger
1
10. september 2010 kl. 14:33

Med hardwareunderstøttelse af virtualisering og med mulighed for at adressere op til 1TB fysisk RAM (ikke nævnt i denne artikel), er A15 rettet mod serverbrug såvel som (high-end) mobile enheder.

2
10. september 2010 kl. 17:13

Linus Torvaldson brokkede sig over at det ikke var en 64 bit adresserum men kun PAE. Er det ikke et skridt tilbage?

3
10. september 2010 kl. 17:26

Man kan vel ikke sige, at det er et skridt tilbage, når man giver flere muligheder i stedet for færre, men det er er bare ikek så stort et skridt frem, som man måske kunne ønske.

A15s lagermodel er selvfølgelig ikke helt det samme som et fladt 64-bit adresserum. Men på servere er det ret almindeligt, at de enkelte processer er ret små, men at der køres mange af dem. Derfor er en begrænsning til 4GB pr. proces ikke en voldsom hindring. Modsat "extended mode" på x86, så er det ikke meningen, at de fleste processer skal bruge hele det fysiske adresserum og derfor lave alle adresseringer som en kombination af et blokregister og et offsetregister,

Men det er klart, at ARM før eller siden må komme med en 64-bit processor (de er sikkert allerede nu ved at udvikle den), så man kan betragte A15 som en midlertidig løsning. Men en ret fornuftig af slagsen.

Personligt håber jeg, at ARM laver en 64-bit arkitektur, som ikke bærer rundt på så meget baggage som f.eks. Thumb2. Bevares, de kan sagtens lave processormodes, der sikrer bagudkompatibilitet, men jeg håber, at 64-bit instruktionssættet laves fra [i]tabula rasa[/i].

4
11. september 2010 kl. 15:25

Nu er tabula rasa sjældent en god idé, heller ikke inden for filosofi ;)

Fx var det en lykke at AMD64 så tydeligt var en x86, trods de ekstra registre og de ekstra 32 bit. MIPS, SPARC og HPPA havde også stor succes med at gå fra 32 til 64 bit med det samme instruktionssæt -- så vidt jeg ved gjorde de ikke meget andet end at tilføje nogle flere load/store-instruktioner (set fra user space, jeg ved godt at det var mere indviklet fra kernel space).

En rigtig god historie i denne sammenhæng (som jeg er sikker på at du kender ret godt) er Data Generals Eagle-serie fra ca 1980. De havde i forvejen nogle 16-bit maskiner (Nova-serien), efterhånden udvidet med diverse sære himstregimser à la physical address extensions men det var ikke godt nok for kunderne mere. De satte så en gruppe i gang som noget skunk works langt væk fra hvor firmaet normalt arbejdede -- plus et lille reservehold til at lave en nødplan.

Dem der Lavede Tingene Rigtigt leverede aldrig (pageable microcode! instruktioner til sortering af BCD-tal!) men nødplanen lykkedes.

Eagle-maskinerne var fuldt bagudkompatible med Nova, de havde bare også 32-bit instruktioner oven i. Et af trickene var at mikrokoden checkede den første instruktion i hver interruptrutine: hvis det var en Nova-instruktion lavede den en 16-bit stakpakke og hvis det var en 32-bit Eagle-stakpakke ;)

Tracy Kidder fik en velfortjent Pulitzerpris for bogen om holdet bag Eagle.

8088/8086 var i øvrigt også noget der blev smækket sammen på forholdsvis kort tid som en stopgap measure fordi deres andre CPU'er enten var for små (8080, 8048, 8085) eller forsinkede (432, som var Lavet Rigtigt). Der var med vilje ikke nogen smarte tricks i arkitekturen og det blev nok dens redning.