Nvidia doet architectuur 64bit-Denver-soc uit de doeken

Nvidia heeft meer details van zijn komende Denver-soc vrijgegeven. Deze 64bit-ARMv8-soc krijgt onder andere de beschikking over een mechanisme dat dynamic code optimization is gedoopt. Volgens Nvidia is de Denver-soc de snelste 64bit-processor voor Android-hardware.

De plannen voor een 64bit-uitvoering op basis van de Tegra K1-processor werden in januari tijdens de CES geopenbaard. Inmiddels heeft Nvidia in een blogposting en whitepaper meer details over de architectuur van de dualcore-Denver-soc bekendgemaakt.

Bijzonder aan het ontwerp is dat er geen gebruik wordt gemaakt van out of order execution, zoals het geval is bij bijna elke moderne processorachitectuur, maar van in order execution. Bij OoO-execution worden instructies niet altijd in de volgorde verwerkt waarin ze binnenkomen. In gevallen waarin twee opvolgende instructies op elkaar moeten wachten, kan de processor onafhankelijke instructies voorrang geven, wat de efficiëntie ten goede komt. Moderne socs van onder andere Samsung, Qualcomm en Intel maken gebruik van OoO-exeuction.

Om vergelijkbare resultaten te behalen maakt Nvidia gebruik van softwareroutines die de binnenkomende instructies en bijbehorende branch results analyseren en omzetten naar geoptimaliseerde microcode. De geoptimaliseerde instructies worden vervolgens in een 128MB-blok van het werkgeheugen geplaatst, terwijl een kleine cache op de chip een look-up-table bevat, waardoor de processor de geoptimaliseerde code snel moet kunnen terugvinden.

Dankzij die techniek, door Nvidia dynamic code optimization genoemd, worden prestaties behaald die vergelijkbaar zijn met een out of order-architectuur, zonder dat energievretende fix function logic nodig is in het chipontwerp, aldus Nvidia. Een bijkomend voordeel is volgens Nvidia dat zijn softwarematige oplossing een grotere set instructies tegelijk kan analyseren dan de hardware in een OoO-processor.

Het ontwerp komt niet zonder nadelen. Zo levert het softwarematig optimaliseren van de instructies overhead op en daarnaast is de Denver-kern mede door de toevoeging van extra cache een stuk groter dan de Cortex A15-kern in de 32bit-versie van de K1-soc. Waar die versie van de chip vijf Cortex A15-kernen weet te huisvesten, passen op datzelfde oppervlak bij de 64bit-variant slechts twee Denver-cores. De chips zijn overigens wel pin compatible.

Nvidia claimt dat de Denver-soc met een kloksnelheid van 2,5GHz prestaties levert die gelijkwaardig of beter zijn dan die van Apples A7-soc. Volgens Nvidia kunnen ook Celerons uit Intels Haswell-serie in sommige tests worden bijgebeend op ipc-vlak. Daarmee zou het de snelste 64bit-ARM-soc voor de Android-markt zijn. De eerste producten waarin de 64bit-versie van de Tegra K1-soc beschikbaar is, moeten later dit jaar op de markt komen.

Reacties (68)

Grappig wat NVidia hier voor een aanpak heeft; het doet me meteen denken aan de aanpak van Transmeta met hun Crusoe processor een decennium geleden, wat ook eigenlijk een trendsetter en innovator voor low power oplossingen. Hier hadden ze een VLIW core (in feite een hele brede in-order core), en een firmware die x86 intstructies vertaalde naar VLIW instructies. Nu is het optimaliseren voor een VLIW erg lastig, omdat het lastig is om genoeg Instruction Level Parallelism uit de code te krijgen om zo'n brede set executie units bezig te houden. Ik vraag me af wat de issue width van deze processor dan zal zijn... want het grootste probleem van de Crusoe was dat de kracht van de VLIW gewoon niet volledig benut kon worden. Een snelle google search levert een gesuggereerde issue width van 7 instructies op. En niet verwonderlijk, ik zie dat ze in dat artikel ook meteen de Transmeta aanhalen, en de parallellen zijn er zeker Ik ben wel benieuwd of deze in tegenstelling tot de Transmeta processoren wel succesvol kan zijn...

Interessant, dit doet me denken aan het HP Dynamo-project jaren geleden: http://www.hpl.hp.com/techreports/1999/HPL-1999-78.html
Daar werd native code (al door een statische compiler geoptimaliseerd) eerst geanalyseerd, en waar mogelijk opnieuw gecompileerd en verder geoptimaliseerd met kennis die tijdens compile-time nog niet beschikbaar was, maar tijdens runtime wel.
Een simpel voorbeeld is het inlinen van calls naar shared libraries.
Een ander voorbeeld is het uitrollen van loops waarbij het aantal iteraties pas at runtime vaststaat.
Hiermee kon HP tot wel 20% snellere code genereren.

In het geval van ARM zou een extra voordeel kunnen zijn dat er veel verschillende varianten van ARM zijn, dus native code is niet per definitie geoptimaliseerd voor het type CPU dat je gebruikt (net als bij x86). Dus hier zou nVidia mogelijk nog meer winst kunnen pakken (en compenseren voor het feit dat er geen out-of-order-execution is: code met de recompiler eenmalig herordenen).

Ik ben erg benieuwd hoe dit in de praktijk uit gaat pakken.

Nvidia claimt dat de Denver-soc met een kloksnelheid van 2,5GHz prestaties levert die gelijkwaardig of beter zijn dan die van Apples A7-soc.

Beetje jammer dat de A7 al een jaar oud is en de A8 er heel binnenkort aankomt, dat de A7 op iets meer dan de helft v/d klokfrequentie loopt. (1.3Ghz), en dat deze SoC nog niet eens beschikbaar is, laat staan in handen van de consument.

Het lijkt er op dat Apple voorlopig een flinke voorsprong heeft op SoC gebied, ze hebben een aantal jaren terug met PA Semiconductor een hele goeie aankoop gedaan.

nVidia concurreert feitelijk niet met Apple - ze concurreren met Intel en Qualcomm. Apple gaat geen nVidia chips kopen, en de OEMs die nVidia chips kopen kunnen geen Apple chips kopen.

De reden dat ze in deze presentaties hun Denver core met Apple's Cyclone vergelijken, is dat dit de enige 64-bit ARM core in productie is.

[Reactie gewijzigd door Dreamvoid op 12 augustus 2014 11:46]

Hoe kan het zijn dat apple wat geen chip ontwerper is het continue voor elkaar krijgt om menig dual en quad core te verslaan. De A7 is inmiddels een jaar oud en veegt nog steeds met elke chip de vloer aan. Waarom zijn de ontwerpers met decennia ervaring niet in staat om dit te evenaren en als ze het lukt dat gebruikt de chip vaak meer energie.

Als ze nu net de A7 kunnen bijbenen dan lopen ze over 30 dagen weer achter als de nieuwe chip van apple gelanceerd zal worden. Ik snap het echt niet aangezien dit niet apple zijn core business in. Waarom kopiëren ze de techniek niet gewoon aangezien dit op elk ander aspect wel gebeurd. Is dit bij een chip niet mogelijk of wat?

Apple en geen ervaring?
Die hebben een paar company's met "decennia ervaring" gekocht, voordat ze aan de A6/A7 begonnen en deze daarna flink wat "resources" gegeven.

http://www.linleygroup.co...etter_detail.php?num=4881

Apple is al een tijd een chip ontwerper. Het komt min of meer voort uit de irritatie die ze destijds hadden over afhankelijk zijn van één leverancier (IBM) voor hun PPC chips. Apple is in het verleden een aantal keer slachtoffer geweest van té grote afhankelijkheid van andere bedrijven en sindsdien zie je dat ze dat zoveel mogelijk proberen te voorkomen.

Dat voorkomen doen ze ofwel door producten afnemen van meerdere bedrijven tegelijk (Nvidia/AMD, Samsung/TSMC, Wolfson/Cirrus Logic, LG/Japan Display/Innolux etc.) ofwel het productontwerp in eigen huis nemen.

In het geval van hun mobiele processors hebben ze in 2008 chip ontwerper P.A. Semi en in 2010 chip ontwerper Intrinsity ingelijfd (beide chip designers die zich special richtten op erg zuinige processors). Toen bleef het eerst een tijdje stil rondom chip design binnen Apple totdat ze in 2011 de Apple A5 uitbrachten. De eerste Apple chip die niet gebaseerd was op Cortex maar op hun eigen ontwerp.

[Reactie gewijzigd door Maurits van Baerle op 12 augustus 2014 11:54]

Apple heeft de laatste jaren verschillende bedrijfjes gekocht en de juiste mensen aangetrokken.
Ze maken dan misschien geen x86 chips, maar op gebied van Arm doen ze zeker niet onder voor nVidia, Samsung,... sterker nog, ze blijken het beter te doen.
De geruchten waren/zijn er zelf dat van zodra Arm krachtiger wordt, de iMac en Macbooks ook op Arm gaan werken

De A7 is inmiddels een jaar oud en veegt nog steeds met elke chip de vloer aan.

Valt op zich wel mee, de gpu is iets trager dan de Adreno 330 van de Snapdragon 800, en de cpu is trager dan Haswell.

De grootste reden dat de A7 zo snel is, is dat het een grotere chip is dan al zijn concurrenten, meer vergelijkbaar met Haswell dan met Tegra en Snapdragon. Dat maakt hem duur (wat in toch al dure iDevices niet zo'n probleem is). De concurrentie, die op prijs moeten concurreren in de bijzonder competitieve Android markt, kiezen voor kleinere, hoger geklokte chips.

[Reactie gewijzigd door Dreamvoid op 12 augustus 2014 12:12]

Volgens Nvidia kunnen ook Celerons uit Intels Haswell-serie in sommige tests worden bijgebeend op ipc-vlak
Amai, wel een hele ferme claim als ze dit kunnen waarmaken. Ik ben benieuwd of deze SOC dan ook in de nieuwe Nexus gaat zitten . Volgens geruchten inderdaad in de Nexus 9 maar ik vraag me af of de nieuwe smartphone ook deze zou hebben. Anders wachten tot volgend jaar voor een 64-bit SOC in men smartphone.

Ter illustratie over de grootte van de twee kernen ipv vijf kernen: http://blogs.nvidia.com/w.../Denver-Hot-Chips-TK1.png

[Reactie gewijzigd door magatsu op 12 augustus 2014 09:58]

Nou ja dat is niet zo'n hele moeilijke claim eigenlijk. Als je een 7-wide issue core hebt, dan kan je wel een microbenchmark uitzoeken of zelf in elkaar sleutelen wat exact al je executie units benut en een hoge(re) IPC haalt vergeleken met andere architecturen met een smallere issue width. Maar dat zegt natuurlijk weinig over de performance van werkelijke applicaties, dus de vraag is wat deze core doet in meer industrie standaard benchmarks. Ik ben benieuwd bijvoorbeeld hoe het zich zou meten qua IPC tegenover een Haswell in SPECcpu2006, en waarschijnlijk hebben ze wel meer details en dergelijke benchmarks in hun Hot Chips paper. Het is eigenlijk vreemd dat terwijl SPECcpu2006 al ernstig verouderd is, ze blijkbaar SPECcpu2000 (daar genoemd SPECint 2K en SPECfp 2K) lijken te hebben gebruikt in de resultaten die hier boven bij het artikel staan.

Probleem met die SPEC-benches is dat het een stroom van relatief simpele en gelijkaardige berekeningen zijn die getest wordt. In real life op een modern multitasking OS krijgt een cpu een enorme verscheidenheid aan instructies en allerlei vormen van branched code op zich af. SPEC scores zeggen daardoor wel iets, maar niet alles.

Dat de SPECcpu2006 benchmark (laten we specifiek zijn want SPEC heeft nog een hele andere berg verschillende soorten benchmarks) relatief simpel en gelijkaardige berekeningen bevat dat ben ik niet met je eens, en ik werk er bijna dagelijks mee. Dat alle benchmarks voor hedendaagse standaarden een kleine instruction footprint hebben, dat wel. Maar de set is werkelijk redelijk uitgebreid en divers; van benchmarks die geheugen bandbreedte gelimiteerd zijn tot pointer chasing code, integer specifiek of juist floating point intensief, compilers, interpreted languages, het is werkelijk een best interessante en nog steeds relevante mix. Het is dan ook niets voor niets dat het binnen de industrie en de academische wereld nog steeds DE standaard benchmark is. Probeer maar eens een paper te publiceren over een nieuwe architectuur in een top conferentie zonder met SPECcpu resultaten aan te komen, dan krijg je daar vast en zeker commentaar over (en wordt je paper afgewezen... helaas zelf mee gemaakt).

Maar goed, even terug on topic, SPECcpu2006 is normaal inderdaad alleen nuttig om je single thread performance te meten; wat is de maximale snelheid die een enkele draaiende applicatie zal halen, of beter; wat is de werkelijke IPC die je kan verwachten van deze architectuur in 'real life'. Of dat voor je platform interessant is of niet, dat hangt compleet van je use case af. Of je juist veel single thread performance nodig hebt (responsieve applicaties, bijv op een mobiel device), of dat je juist veel meer hebt aan een computing throughput met meer threads (servers of andere paralleliseerbare processing taken). In het tweede geval dan is het interessant om de SPECcpu2006 benchmark in 'rate' modus te draaien waarbij er meerdere instanties van de benchmarks parallel draaien en je op die manier de maximale throughput van je systeem kan meten. Alhoewel je dan nooit meer dan een instantie per core (of hardware thread) zal draaien, omdat dat nooit meer throughput op zal leveren.

Maar er is niet zoiets als een 'golden' benchmark. Als je een nieuwe architectuur ontwikkeld dan heb je daar ook een bepaalde doelgroep/gebruik voor in gedachte en daar zullen bepaalde applicaties of applicatie scenarios bij horen waar je voor zal zorgen dat je architectuur die zo optimaal mogelijk kan afhandelen. Dat zullen ze bij NVidia vast en zeker ook gedaan hebben. Dus ja, met je laatste punt ben ik het met je eens, SPECcpu scores zeggen zeker een belangrijk deel, maar niet alles.

De complete set benches van SPECcpu is idd gevarieerd, maar wat fabrikanten doen is enkel SPECint of fp draaien en dat publiceren.

SPECint en SPECfp zijn de twee subsets van SPECcpu met respectievelijk de 12 integer heavy en 17 floating point heavy benchmarks waar je dan individueel een score voor kan berekenen. Samen zijn ze dus wel degelijk de hele SPECcpu suite, niet maar twee (micro)benchmarks. Mocht je interesse hebben in de details van de individuele benchmarks in de suite dan is dit een handig overzicht.

Nvidia claimt dat de Denver-soc met een kloksnelheid van 2,5GHz prestaties levert die gelijkwaardig of beter zijn dan die van Apples A7-soc.

Nou Nvidia, geniet er deze maand nog maar even van.

Het is grappig dat de nieuwste Apple processor er sneller zal zijn dan deze 64bit processor.
Los daarvan vind ik het een opmerkelijke evolutie om terug naar dual cores te gaan in plaats van octacores.

Dual cores is momenteel de sweetspot voor veel sofware, hogere core counts is moeilijker uit te nutten.

Je kunt dus het energiebudget beter verdelen over 2 cores dan over 4 waarbij je dan de 2 cores dus ook hogere klokfrequentie kunt geven wat de single thread performance en latency van de software ten goede komt.

Je ziet de trend ook komen idd, Intel heeft nu ook meer succes met het naar beneden brengen van Haswell (met 2 'big cores') dan het opschalen van Bay Trail met zijn 4 kleine cores. Apple heeft in de A7 ook twee grote cores, en nu nVidia ook. Zou me niks verbazen als bij Qualcomm de 64-bit opvolger van Krait ook een grotere core wordt.

Ik ben erg benieuwd hoe deze SOC gaat presteren. Tegen de tijd dat hij op de markt is zal hij het wel moeten opnemen tegen de A8 van Apple. Nu is het alleen wel de vraag hoeveel Apple aan gaat passen. De A7 is al erg snel.

Ik ben erg benieuwd hoe deze SOC gaat presteren. Tegen de tijd dat hij op de markt is zal hij het wel moeten opnemen tegen de A8 van Apple. Nu is het alleen wel de vraag hoeveel Apple aan gaat passen. De A7 is al erg snel.

De Denver Tegra K1 zal het niet hoeven op te nemen tegen de Apple A8.
De Apple A8 is helemaal geen concurrerend product, alleen iets waar Intel zich zorgen over moet maken. Wanneer Apple ARM socs in hun laptops gaat gebruiken.
De Tegra zit niet in een Apple device en Apple gebruikt hun SOCs alleen maar intern.

Concurrenten van de Tegra K1 zijn Qualcom, Samsung, Mediatek, Rockchip etc.

IMO is het grootste voordeel vooral voor Linux gebruikers dat het de eerste ARM SOC is met open source GPU drivers. Daarom gaat mijn voorkeur uit naar deze CPU, hopelijk in een Asus Transformer.

NVIDIA Provides Open-Source Tegra K1 Support In Nouveau

[Reactie gewijzigd door Anoniem: 112442 op 12 augustus 2014 15:47]

Het is geen letterlijke concurrent maar wel vanuit hardware / performance point of view. Ik vind dat gewoon interessant.

Apple zal zijn A8 niet aan andere verkopen. Zou wel leuk zijn om een A8 op android te kunnen testen en te vergelijken met wat andere merken hebben.

nVidia gaat net als apple met switft voor twee hele krachtige cores. Ipv 4 of zelfs 8 minder krachtige.

Wat ik dan niet goed snap is dat er zoveel code-optimalisatie 'on-the-fly' verricht kan worden.
Dit zou je verwachten dat een goede compiler reeds afhandelt. Nu kan de de code logisch mischien niet optimaal geprogrammeerd zijn maar dat zie ik de dynamic core optimization niet zomaar oplossen. Intel en AMD hebben echt wel nagedacht sinds de afgelopen decennia over optimisation en branch prediction etc.

Wellicht speciaal iets voor Android apk's??

Een normale CPU doet enorm veel code optimalisatie om out-of-order de opdrachten ui te voeren. De ver doet dat niet en heeft in plaats daarvan deze truck. We gaan zien of het werkt in 'echte' code.

Ik ben toch wel benieuwd wat "objectieve" benchmarks gaan vertellen over deze *In-order* high-end ARM !

Weer een hoop marketing blahblah. Het ding is niet eens verkrijgbaar en maar op een paar vlakken sneller dan Apple's "oude" A7 en dit bij een kloksnelheid die bijna 2x zo hoog ligt.

Zodra het ding op de markt is is ie al weer verouderd en veegt Apple's A8 er de vloer mee aan.

- Volgens mij zijn het benchmarks die ze laten zien, dus neit marketing blaat (je kunt je natuurlijk afvragen hoe representatief de benchmarks zijn, maar dat is een andere kwestie)
- Apple's SOC draait helemaal niet op dit soort kloksnelheden
- deze SOC is dus sneller dan die van Apple (iig in de benchmarks)
- er zullen geen Apple devices zijn met deze SOC, en er zullen geen non-Apple devices zijn met de SOC van Apple, maw, ze concurreren niet direct met elkaar


Verder ben ik erg benieuwd naar de prijsstelling van deze SOC. Gaat ie in telefoons komen, of bv alleen in tablets?

Ik denk dat ze juist wel concureren. Als je één app naar twee platforms port dan kan je de snelheid van die apps wel vergelijken. Als die op iOS lekker loopt, maar op Android niet (of andersom), dan wordt dat duidelijk. Je ziet dat heel goed bij bijvoorbeeld crossplatform games. De gebruikte SoC maakt dan wel degelijk uit.

[Reactie gewijzigd door MadIceXIII op 12 augustus 2014 22:51]